用 WorkBuddy 越深入，越能体会到它的强大——但也会遇到一些"坑"。这些坑大多不是因为工具本身有缺陷，而是使用方式与工具设计理念不匹配。本文整理了社区反馈最多的 10 个常见问题，每个都给出原因分析和可操作的解决方案。

1️⃣指令太模糊，结果不符合预期

问题表现

说"帮我优化一下代码"，WorkBuddy 改了不该改的地方，或者优化方向和预期不同。

原因分析

"优化"是一个高度模糊的词——可以是性能优化、可读性优化、安全优化、代码风格优化……WorkBuddy 只能猜测你的意图，猜错概率很高。

解决方案

# ❌ 模糊指令
> 帮我优化一下代码

# ✅ 明确指令
> 帮我优化 src/utils/format.js 的性能，
  这个函数在列表渲染时被高频调用，
  目前每次调用都创建新对象，希望减少内存分配

2️⃣大文件处理超时或截断

问题表现

读取一个 5000 行的日志文件，只返回了前 2000 行，后面的内容丢失了。

原因分析

WorkBuddy 的 Read 工具有单次返回上限（约 2000 行），超过部分自动截断。这是为了防止单次响应过大导致超时。

解决方案

# ❌ 一次性读整个大文件
> 读一下 /var/log/app/error.log

# ✅ 方案1：分段读取
> 先读 error.log 的前 500 行，了解格式
> 再搜索包含 "NullPointerException" 的行

# ✅ 方案2：先过滤再读取
> 从 error.log 中提取今天日期的 ERROR 级别日志

# ✅ 方案3：用搜索代替全读
> 在 error.log 里搜索 "timeout" 关键字及其前后5行

3️⃣网络搜索结果不准确

问题表现

让 WorkBuddy 搜索某个技术问题的解决方案，返回的信息过时或不相关。

原因分析

搜索引擎返回的结果取决于查询关键词。自然语言描述的搜索词可能不够精准，导致搜索结果偏离目标。

解决方案

# ❌ 自然语言搜索
> 搜一下 Redis 连接超时怎么办

# ✅ 精准关键词搜索
> 搜索 "Redis connection timeout sentinel failover 2026"
  限定中文技术博客和官方文档

4️⃣文件路径错误导致操作失败

问题表现

让 WorkBuddy 修改某个文件，报错"文件不存在"，但文件明明在那里。

原因分析

最常见的原因是使用了相对路径，而 WorkBuddy 的当前工作目录与用户预期不同。也可能是路径中的大小写不匹配（Linux 区分大小写）。

解决方案

# ❌ 相对路径
> 修改 src/config.js

# ✅ 绝对路径
> 修改 /home/project/myapp/src/config.js

# ✅ 或者先确认路径
> 找一下项目里叫 config.js 的文件在哪

5️⃣Edit 工具匹配失败

问题表现

用 Edit 修改文件时报错"old_string not found in content"，但肉眼看着明明是对的。

原因分析

Edit 工具要求精确匹配，包括空格、缩进、换行符。最常见的陷阱是：Tab 和空格混用、行尾有多余空格、Windows 换行符（\r\n）vs Unix 换行符（\n）。

解决方案

# ❌ 凭记忆写 old_string
> 把 "port: 3000" 改成 "port: 8080"

# ✅ 先 Read 确认精确内容，再 Edit
> 先读一下 config.json 的第 10-15 行
  （看到实际内容是 "port": 3000, 注意有引号和逗号）
> 把 "port": 3000, 改成 "port": 8080,

6️⃣对话上下文丢失

问题表现

聊了 20 轮后，WorkBuddy 似乎"忘了"之前说过的话，重复提问或给出矛盾的回答。

原因分析

WorkBuddy 的上下文窗口有长度限制（约 128K tokens）。对话轮次过多时，早期的内容会被挤出上下文窗口。

解决方案

# ✅ 方案1：重要信息及时写入文件
> 把刚才讨论的架构方案写入 docs/architecture.md

# ✅ 方案2：长任务拆分为多个短对话
  对话1：需求分析和方案设计 → 输出设计文档
  对话2：基于设计文档实现代码 → 输出代码文件
  对话3：基于代码文件编写测试 → 输出测试文件

# ✅ 方案3：关键决策用 /memory 命令持久化
> /memory 记住：项目使用 Vue3 + Element Plus，API 前缀 /api/v2

7️⃣执行危险操作没有确认

问题表现

让 WorkBuddy 清理临时文件，结果把重要数据也删了。

原因分析

在 Code 模式下，WorkBuddy 默认直接执行终端命令，不会像人类那样对危险操作（rm -rf、DROP TABLE 等）二次确认。

解决方案

# ✅ 方案1：使用 Plan 模式先预览
> /plan 清理 /tmp 下7天前的临时文件
  （先看计划，确认后再执行）

# ✅ 方案2：明确约束条件
> 清理 /tmp 下7天前的 .log 文件，只删 .log 后缀的，
  其他文件不要动

# ✅ 方案3：先备份再操作
> 先把 /data/important 备份到 /backup/，再执行清理

8️⃣生成的代码不符合项目规范

问题表现

WorkBuddy 生成的代码风格和项目现有代码不一致——用了不同的命名规范、缺少项目特有的工具函数、引入了项目没用过的库。

原因分析

WorkBuddy 默认按"通用最佳实践"生成代码，但每个项目有自己的约定。如果没告诉它项目规范，它只能按默认风格写。

解决方案

# ✅ 方案1：让它先读项目代码再写
> 先看一下 src/ 下现有的组件代码风格，
  然后按同样的风格写新组件

# ✅ 方案2：使用 /memory 持久化项目规范
> /memory 记住项目规范：
  - 命名：组件用 PascalCase，函数用 camelCase
  - 样式：使用 Tailwind CSS，不用 styled-components
  - 状态管理：用 Pinia，不用 Vuex
  - API：用 axios，baseURL 从 env 读取

# ✅ 方案3：提供参考文件
> 参考 src/components/UserCard.vue 的写法，
  创建一个类似的 ProductCard.vue

9️⃣多步骤任务中途出错，前功尽弃

问题表现

让 WorkBuddy 执行一个 10 步的任务，第 7 步报错，前面 6 步的修改已经生效但任务没完成，处于半完成状态。

原因分析

WorkBuddy 按顺序执行步骤，中间某步失败后不会自动回滚之前的操作。这和人类操作一样——改了 3 个文件后第 4 个改错了，前 3 个不会自动还原。

解决方案

# ✅ 方案1：复杂任务用 Git 保护
> 在开始修改前先 git commit，这样出错可以回退
  （WorkBuddy 会自动在操作前创建 Git 检查点）

# ✅ 方案2：拆分为小任务逐步执行
  不要一次性说"重构整个模块"，而是：
  第1轮：只重构 utils.js
  第2轮：只重构 api.js
  第3轮：只更新调用方

# ✅ 方案3：让 WorkBuddy 生成执行计划
> /plan 先列出完整的执行步骤，
  我确认后再开始执行

🔟Ask 模式下无法执行操作

问题表现

在 Ask 模式下让 WorkBuddy 修改文件或执行命令，它只给出建议但不执行。

原因分析

Ask 模式是纯对话模式，只读不写——这是设计如此，不是 bug。Ask 模式下 WorkBuddy 不能执行写操作（Write/Edit/Bash），只能读取和分析。

解决方案

# ✅ 切换到 Code 模式
> /code  切换到代码模式，现在可以执行操作了

# ✅ 或者在 Ask 模式下先获取方案，再切换执行
  Ask 模式：分析问题，给出方案 →
  /code →
  Code 模式：执行方案

📋踩坑速查表

问题                  │ 根因              │ 一句话解决
━━━━━━━━━━━━━━━━━━━━━│━━━━━━━━━━━━━━━━━━│━━━━━━━━━━━━━━━━━━
指令模糊结果不对      │ 意图不明确        │ 说清做什么+为什么+约束
大文件读取截断        │ 单次返回上限      │ 分段读或先过滤再读
搜索结果不准确        │ 搜索词不精准      │ 用精准关键词+限定范围
文件路径错误          │ 相对路径歧义      │ 始终用绝对路径
Edit 匹配失败         │ 精确匹配要求      │ 先 Read 确认再 Edit
上下文丢失            │ 窗口长度限制      │ 重要信息写入文件
危险操作无确认        │ Code模式直接执行  │ 用 Plan 模式先预览
代码风格不一致        │ 缺少项目规范      │ 先读现有代码再写
中途出错前功尽弃      │ 无自动回滚       │ Git 保护+拆小任务
Ask模式无法操作       │ 设计如此          │ 切换到 Code 模式