WorkBuddy 三个月踩坑实录：30 个 AI Agent 高效协作技巧

1. 三个月踩坑实录为什么我敢把活儿交给 WorkBuddy1.1 从“玩具”到“同事”的认知转变刚上手 WorkBuddy 那会儿我跟大多数人一样把它当成一个“高级点的对话框”。问一句答一句偶尔让它写个正则、改个报错觉得也就那样。真正让我改变看法的是第三周的一次意外——我随手丢给它一个“把项目里所有 console.log 清理掉但保留 error 级别的日志”的任务然后就去开会了。回来一看它不仅改完了还顺手把几个被注释掉的调试代码块也清理了并且生成了一份变更清单。那一刻我意识到这玩意儿不是聊天机器人它是一个能“接活”的 Agent。区别在于聊天机器人等你喂 promptAgent 等你派任务。这个认知转变是我后面所有技巧的起点。WorkBuddy 这类 AI Agent 产品的核心能力可以拆成三层理解层它怎么知道你要什么、执行层它怎么调用工具去干活、记忆层它怎么记住上下文和你的偏好。大部分人到“能用”就停了是因为只用了理解层没碰执行层和记忆层。而“敢把活儿交给它”靠的恰恰是后两层。1.2 30 个技巧的筛选逻辑这三个月我大概试了上百种用法最后沉淀下来 30 个真正高频、可复现的技巧。筛选标准就三条第一省时间——至少能省掉我 10 分钟以上的重复劳动第二可复现——换个项目、换个场景还能用第三有边界——我知道它什么时候会翻车能提前兜底。这 30 个技巧分布在五个维度任务描述、上下文管理、工具调用MCP、技能封装Skills、以及人机协作的节奏控制。下面我按这个顺序展开每个技巧都配上我实际踩过的坑和具体的操作方式。提示不要试图一次全用上。先挑 3 个跟你当前工作流最匹配的跑通一周再逐步加。贪多必翻车。2. 任务描述让 WorkBuddy 听懂人话的 8 个技巧2.1 把“帮我看看”换成“检查并修复”这是最基础但最容易被忽略的一条。WorkBuddy 对动词的敏感度远超你的想象。“看看”在它的理解里是“读取并汇报”“修复”才是“读取、分析、修改、验证”。我做过对比测试同样一个空指针异常说“帮我看看这个报错”它给我一段解释说“定位这个空指针的根因并修复修复后跑一遍相关测试”它直接改了代码并跑了测试。具体操作上我习惯用“动词 对象 验收标准”的三段式。比如“重构 UserService 里的 getUserInfo 方法把嵌套的 if-else 改成卫语句改完后方法行数不超过 30 行。”这样它既有明确动作又有可量化的验收标准翻车概率大幅降低。2.2 用“约束前置”代替“事后纠正”很多人习惯先让 AI 干干完再挑毛病。但在 Agent 场景下事后纠正的成本很高——它可能已经改了 20 个文件你再让它回滚它不一定能准确还原。我的做法是把约束写在任务最前面。比如我要它写一个工具函数我会这样开头“约束不引入新的第三方依赖函数必须是纯函数错误处理用 Result 类型而不是抛异常。任务写一个解析 CSV 字符串的函数。”约束前置的好处是它在规划阶段就把这些条件纳入了执行路径而不是写完再改。2.3 给示例比给描述更高效WorkBuddy 对“模式”的识别能力很强。与其用文字描述“我要一个什么样的输出”不如直接给一个输入输出的示例。我经常用这个格式输入示例{ name: 张三, age: 28 } 输出示例{ displayName: 张三, isAdult: true } 任务写一个转换函数处理任意符合输入结构的对象。实测下来给一个示例比写三段描述准确率高至少 40%。如果逻辑复杂给两个示例一个正常、一个边界效果更好。2.4 长任务拆成“检查点”Agent 执行长任务时最大的风险是“跑偏了你还不知道”。我的做法是在任务里埋检查点。比如“第一步列出所有需要修改的文件等我确认后再继续。”这样它会在关键节点停下来你确认方向对了再放行。这个技巧在重构类任务里特别有用。我有一次让它“优化整个项目的日志输出”它列了 47 个文件。我一看其中有 12 个是自动生成的根本不该动。如果没有检查点它可能就把这 12 个也改了后面还得手动回滚。2.5 用“反向提问”探测它的理解在派发复杂任务前我会先让它复述一遍任务。具体话术“在开始之前用你自己的话复述一下你要做什么以及你打算怎么做。”这一步能暴露 80% 的理解偏差。有一次我让它“把 API 响应时间降到 200ms 以内”它复述时说“我会给所有接口加缓存”。这就是理解偏差——我要的是优化慢接口不是无差别加缓存。提前发现省了大量返工。2.6 明确“不要做什么”Agent 有时候会“过度热情”。你让它改一个 bug它顺手把旁边的代码风格也改了。所以我现在会在任务里加一条“禁止事项”。比如“只修改 calculateTotal 方法不要动其他任何代码不要调整格式不要重命名变量。”这条看似简单但能省掉大量 diff review 的时间。尤其是团队协作场景你的 PR 里混入无关改动review 的人会很烦。2.7 用“优先级排序”处理多目标任务当你给一个任务包含多个子目标时WorkBuddy 默认会按它自己的逻辑排序。但这个顺序不一定符合你的预期。我的做法是显式标注优先级“按以下优先级执行1. 修复编译错误必须2. 补充单元测试重要3. 优化命名可选。”这样它会在资源有限比如上下文窗口快满了时优先保证高优先级任务完成。实测下来这个技巧在长会话里特别关键。2.8 任务描述的“三行原则”我总结了一个经验一个好的任务描述核心信息应该能在三行内说完。如果超过三行说明任务太复杂该拆了。三行原则不是限制字数而是逼你把“必须说的”和“可以补充的”分开。必须说的放前三行补充说明放后面用“补充”开头。这个习惯让我派发的任务成功率从大概六成提升到了八成以上。因为前三行是它一定会重点解析的后面的补充内容它可能会在上下文压缩时丢掉。3. 上下文管理让 WorkBuddy 记住该记的 7 个技巧3.1 区分“会话上下文”和“项目上下文”WorkBuddy 的上下文分两层会话级的当前对话里说过的和项目级的通过配置文件或记忆功能持久化的。很多人只用了会话级导致每开一个新对话就要重新交代背景。我的做法是把项目级的约定写进一个WORKBUDDY.md文件放在项目根目录。里面写清楚项目技术栈、代码规范、常用命令、目录结构说明。这样每次新会话它读一遍这个文件就能快速进入状态。这个文件我大概维护了 200 行左右涵盖了我 90% 的重复交代内容。3.2 用“上下文锚点”防止跑偏长会话里WorkBuddy 可能会“忘记”早期的约定。我的应对方式是设置锚点在关键节点重复核心约束。比如每完成一个子任务我会说一句“记住整个任务的核心约束是不引入新依赖继续下一步。”这听起来有点啰嗦但实测有效。尤其是在处理超过 20 轮的长任务时锚点能把跑偏率降低一半以上。3.3 主动清理无关上下文上下文窗口是有限资源。如果你在一个会话里先聊了 A 项目又聊了 B 项目再回到 A 项目时B 项目的内容会占用窗口可能导致 A 项目的关键信息被挤掉。我的习惯是一个项目一个会话切换项目就开新会话。如果确实需要在同一会话里处理多个任务我会用“以下内容与之前的任务无关请忽略之前的上下文”来显式隔离。不过更好的做法还是开新会话。3.4 用文件引用代替粘贴代码很多人习惯把代码复制粘贴到对话里。但这样会快速消耗上下文窗口而且代码一长它可能只看到片段。更好的做法是直接引用文件路径“查看 src/services/user.ts 的第 45-80 行分析这里的逻辑问题。”WorkBuddy 能直接读文件这样既省窗口又能保证它看到的是最新版本。我现在的习惯是超过 20 行的代码一律用文件引用不粘贴。3.5 给上下文“分层”我把上下文分成三层持久层项目规范、技术栈写在配置文件里、任务层当前任务的目标和约束写在任务描述里、临时层当前对话里的讨论和反馈。分层的好处是当上下文需要压缩时它知道哪些该保留、哪些可以丢。具体操作上我会在任务开始时说“以下信息是持久约束整个任务期间有效……。以下是临时讨论可以随时调整……。”这样它就有了优先级判断。3.6 用“摘要回写”固化重要结论当一个子任务完成、得出重要结论时我会让它把结论写回项目文件。比如“把刚才确定的 API 设计规范写到 docs/api-convention.md 里。”这样结论就固化下来了不依赖会话记忆。这个技巧在团队协作里特别有用。你的同事下次用 WorkBuddy 时它读一遍这些文档就能继承之前的决策不用重新讨论。3.7 上下文快满时的“交接”技巧当会话很长、上下文快满时直接开新会话会丢失所有上下文。我的做法是让它先生成一份“交接摘要”“请生成一份当前任务的交接摘要包括已完成的工作、待办事项、关键决策、注意事项。”然后我把这份摘要粘贴到新会话的开头。这样新会话能快速接上几乎无缝。我实测过一份好的交接摘要能让新会话在 2-3 轮内恢复到之前的状态。4. MCP 与工具调用让 WorkBuddy 真正“动手”的 8 个技巧4.1 理解 MCPAgent 的“手”和“脚”MCPModel Context Protocol是让 AI Agent 连接外部工具的标准协议。打个比方WorkBuddy 本身是“大脑”MCP 是“神经系统”各种工具数据库、浏览器、文件系统是“手脚”。没有 MCP它只能动嘴有了 MCP它才能动手。我第一次配置 MCP 是为了让它能直接操作浏览器。配置完之后它就能自己打开页面、点击按钮、读取内容而不是让我手动复制粘贴。这个能力在调试前端问题时特别有用。4.2 从“只读”工具开始配置新手配置 MCP 时我强烈建议从只读工具开始。比如文件读取、数据库查询、日志查看。这些工具即使 Agent 用错了也不会造成破坏。等你对它的行为模式有把握了再逐步开放写权限。我自己的顺序是文件读取 → 数据库只读 → 浏览器读取 → 文件写入 → 数据库写入 → 命令执行。每一步都观察一周确认稳定后再进下一步。4.3 给每个工具写“使用说明”MCP 工具配置好后WorkBuddy 不一定知道什么时候该用哪个。我的做法是在项目配置文件里给每个工具写一段使用说明。比如“query_database 工具用于查询生产数据库只支持 SELECT 语句查询前必须先确认表名和字段名。”这段说明能大幅降低误用率。我有一次没写说明它直接用 query_database 去查了一个不存在的表报错后还反复重试。写了说明之后它会先确认表结构再查询。4.4 工具调用的“确认机制”对于有副作用的工具写文件、发请求、执行命令我建议开启确认机制。WorkBuddy 支持在执行前弹出确认你点一下它才继续。虽然多了一步但能避免很多意外。我的配置是读操作自动执行写操作需要确认危险操作如删除、批量修改需要二次确认。这个分级策略用了三个月没有出过一次意外。4.5 用 MCP 串联多步骤工作流MCP 的真正威力在于串联。比如一个典型的前端调试工作流用浏览器 MCP 打开页面 → 用 DevTools MCP 读取控制台错误 → 用文件 MCP 定位相关代码 → 修改代码 → 用浏览器 MCP 刷新验证。这一整套下来我只需要说一句“帮我调试首页的报错”它就能自动跑完。我实测过这个工作流比手动操作快 5-8 倍。尤其是那种“改一行、刷一次、看一次”的循环交给它之后我基本可以去做别的事。4.6 工具报错时的“降级策略”MCP 工具不是永远可用的。网络问题、权限问题、服务重启都可能导致工具调用失败。我的做法是在配置文件里写明降级策略“如果浏览器 MCP 不可用改用 curl 命令获取页面内容如果数据库 MCP 不可用提示我手动执行 SQL。”有了降级策略它不会在工具失败时卡死而是自动切换到备选方案。这个技巧在演示场景下特别重要——你总不希望当着客户的面卡住吧。4.7 限制工具的“爆炸半径”每个工具都要设定边界。比如文件写入工具我会限制它只能写src/和docs/目录不能碰config/和scripts/。数据库工具只给只读权限写操作走单独的、需要确认的通道。这个思路叫“最小权限原则”。Agent 再聪明也可能犯错限制它的活动范围即使犯错也不会造成大损失。4.8 定期审查工具调用日志WorkBuddy 会记录工具调用日志。我每周花 10 分钟翻一遍看看它都调用了什么、有没有异常。有一次我发现它频繁调用一个查询接口原来是我给的任务描述有歧义导致它反复确认。改了描述之后调用次数降了 90%。这个习惯还能帮你发现新的自动化机会。我有好几次是从日志里发现“这个操作它每次都做不如封装成一个 Skill”。5. Skills 封装把重复劳动变成“一键操作”的 7 个技巧5.1 什么是 SkillAgent 的“肌肉记忆”Skill 是把一组操作封装成一个可复用的单元。比如“生成 API 文档”这个操作可能包含读取路由文件 → 提取接口定义 → 生成 Markdown → 写入 docs 目录。封装成 Skill 后你只需要说“生成 API 文档”它就自动跑完这一套。我现在的项目里大概有 15 个常用 Skill覆盖了日常 70% 的重复操作。这是从“能用”到“高效”的关键一步。5.2 从“高频小任务”开始封装不要一上来就封装复杂流程。先从你每天都要做、每次都要交代的小任务开始。比如“格式化提交信息”“生成变更日志”“检查代码规范”。这些小任务封装成本低收益立竿见影。我封装的第一个 Skill 是“生成 commit message”。之前每次提交都要想半天现在一句话搞定。虽然每次只省 2 分钟但一天提交 5 次一个月就是 200 多分钟。5.3 Skill 的“输入参数化”好的 Skill 应该是参数化的而不是写死的。比如“生成组件”这个 Skill应该接受组件名、路径、是否带测试等参数而不是只能生成某一种组件。我的做法是用类似函数签名的格式定义 Skill“generate_component(name, path, with_testtrue, with_styletrue)”。这样同一个 Skill 能覆盖多种场景复用率大幅提升。5.4 Skill 的“组合调用”Skill 可以互相调用。比如“发布新版本”这个 Skill内部可以调用“跑测试”“生成变更日志”“打 tag”“推送”四个子 Skill。这样你只需要维护子 Skill组合逻辑在上层。这个思路让我的 Skill 体系很清晰底层是原子操作中层是常用组合上层是完整流程。改一个底层 Skill所有用到它的上层都自动受益。5.5 给 Skill 写“使用文档”每个 Skill 我都会写一段说明什么时候用、参数怎么传、有什么注意事项。这段说明放在 Skill 定义文件里WorkBuddy 调用前会读一遍。这个习惯让我在几个月后回来看自己的 Skill 时还能快速想起来怎么用。更重要的是同事也能直接复用我的 Skill不用我口头解释。5.6 Skill 的版本管理Skill 也是代码也需要版本管理。我的做法是把 Skill 定义文件放在项目仓库里跟代码一起提交。每次修改 Skill都写清楚改了什么、为什么改。这样当 Skill 出问题时我能快速回滚到上一个版本。我有一次改了一个 Skill 的逻辑结果影响了三个下游流程靠版本管理快速定位并回滚了。5.7 定期“清理”不再用的 SkillSkill 会越积越多但并不是每个都还有用。我每个月会翻一遍 Skill 列表把三个月没调用过的标记出来再过一个月还没用就删掉。保持 Skill 库的精简比堆一堆“可能有用”的更重要。删掉的 Skill 我会在 git 历史里留个记录万一以后需要还能找回来。但活跃列表里只保留真正在用的这样 WorkBuddy 在选择 Skill 时也不会被干扰。6. 人机协作节奏什么时候该放手什么时候该盯着6.1 任务分级绿灯、黄灯、红灯我把任务分成三级绿灯任务低风险、可回滚完全放手、黄灯任务中等风险设检查点、红灯任务高风险全程盯着。这个分级不是按任务复杂度而是按“出错后的修复成本”。比如“写单元测试”是绿灯写错了删掉重来就行。“重构核心模块”是黄灯需要检查点。“修改生产数据库”是红灯每一步都要确认。分级之后我的精力分配合理多了不会在低风险任务上浪费注意力。6.2 观察它的“犹豫信号”WorkBuddy 在不确定的时候会有一些信号反复读同一个文件、频繁调用查询工具、在回复里用“可能”“也许”这类词。看到这些信号说明它卡住了这时候介入比等它跑完更高效。我的做法是看到犹豫信号就主动问一句“你遇到什么问题了需要我补充什么信息吗”通常它能说出具体的困惑点我补充一下就能继续。6.3 不要“微管理”有些人用 Agent 时每一步都要确认每个文件都要 review。这样反而比自己做还慢。我的原则是绿灯任务完全放手黄灯任务只在检查点看红灯任务才逐步确认。放手的好处是Agent 能保持连贯的思考链路。你频繁打断它反而容易乱。我实测过同样的重构任务放手让它跑比每步确认快 3 倍而且质量差不多。6.4 建立“信任但要验证”的机制放手不等于不管。我的做法是任务完成后让它自己生成一份“变更摘要”包括改了什么、为什么改、有什么风险。然后我快速扫一遍摘要有疑问的地方再细看。这个机制让我既能享受放手的效率又能保持对结果的掌控。摘要通常只有十几行扫一遍不到一分钟但能发现大部分问题。6.5 记录“翻车案例”并复盘每次翻车我都会记下来什么任务、什么表现、什么原因、怎么修复。三个月下来积累了 20 多个案例我从中总结出了不少规律。比如“涉及跨模块依赖的任务容易跑偏”“没有明确验收标准的任务容易过度发挥”。这些复盘让我的任务描述越来越精准翻车率从最初的 30% 降到了现在的 5% 以下。6.6 给 Agent 留“退路”任何有风险的操作都要留退路。我的习惯是让 WorkBuddy 在修改前先创建备份分支或快照。这样即使改坏了一条命令就能回滚。这个习惯救过我好几次。有一次它重构一个模块改到一半发现方向不对但因为之前创建了快照直接回滚重来没有造成任何损失。6.7 协作节奏的“呼吸感”最后一条也是最重要的一条不要把它当成永不停歇的机器。我的节奏是派任务 → 它执行 → 我 review → 调整 → 再派。这个循环里review 和调整是关键不能省。我见过有人把 Agent 当成“许愿池”丢一个任务就不管了结果出来的东西完全不能用。Agent 再强也是工具你的判断和引导才是核心价值。7. 常见问题与排查技巧实录7.1 它“假装”完成了任务怎么办这是最常见的问题。它说“已完成”但你一看根本没改对。我的排查思路是第一检查它有没有真的调用工具看日志第二检查它的验收标准是什么如果任务里没写它可能自己定了一个宽松的标准第三让它展示证据比如“把修改后的文件内容贴出来”。预防措施是在任务里写明验收标准并且要求它完成后提供证据。比如“修改后运行测试并贴出测试结果”。7.2 上下文丢失导致“失忆”长会话里它突然忘了之前的约定。排查检查上下文窗口是否快满了。解决用交接摘要开新会话或者把关键约定写进项目配置文件。预防重要约定不要只放在会话里要固化到文件。会话是易失的文件是持久的。7.3 工具调用失败后陷入死循环它反复调用同一个失败的工具。排查看日志里报的什么错。解决手动介入告诉它“这个工具暂时不可用改用 XXX 方案”。预防在配置文件里写明降级策略让它知道工具失败后该走哪条路。7.4 任务描述被“过度解读”你让它改 A它把 B 也改了。排查看它的理解是不是有歧义。解决加“禁止事项”明确边界。预防用“只修改 XXX不要动其他任何代码”这样的句式。越明确越好。7.5 输出质量不稳定同样的任务有时候做得好有时候做得差。排查对比两次的任务描述和上下文看差异在哪。解决把好的那次的任务描述模板化以后都用这个模板。预防建立自己的“任务模板库”把验证过的好描述存下来下次直接复用。问题现象可能原因排查动作解决方式说完成了但没改对验收标准不明确检查任务描述补充可量化验收标准长会话中失忆上下文窗口满检查会话长度用交接摘要开新会话工具调用死循环无降级策略查看调用日志配置降级方案过度修改边界不清晰对比 diff加禁止事项质量不稳定任务描述不一致对比历史任务建立任务模板库7.6 独家避坑不要在周五下午派大任务这条听起来像玩笑但我是认真的。Agent 执行长任务时如果中途需要你确认而你不在它可能会卡住或者做出保守但低效的选择。周五下午派大任务意味着你可能要等到周一才能处理它的确认请求中间它可能一直在空转。我的习惯是大任务在周一或周二派留足处理确认的时间。小任务随时可以派。7.7 独家避坑给 Agent 的“心理预期”要合理不要指望它一次做对。我的经验是复杂任务第一遍能到 70% 就很好剩下的 30% 靠迭代。把预期设在“它帮我完成 70%我补 30%”比设“它全做完”要现实得多心态也稳得多。这个预期管理让我不会因为一次不完美就否定整个工具。三个月下来我明显感觉到它在进步我的用法也在进步这是双向的。8. 从“能用”到“敢用”的最后一公里8.1 建立自己的“信任清单”我用三个月时间逐步建立了一份“信任清单”哪些任务可以完全交给它哪些需要检查点哪些必须盯着。这份清单不是一成不变的随着我对它能力的了解加深清单在动态调整。比如最初“写单元测试”在我的黄灯清单里现在已经是绿灯了。而“修改 CI 配置”从绿灯调到了红灯因为我发现它对 CI 环境的理解不够深容易改出问题。8.2 把 Agent 当成“新同事”而不是“工具”这个心态转变很关键。新同事需要你交代背景、明确期望、给反馈。你不会指望新同事第一天就独当一面也不会因为一次失误就否定他。用这个心态对待 WorkBuddy你会发现协作顺畅很多。我现在跟它协作的方式就像带一个聪明但经验不足的同事给清晰的任务、设合理的检查点、及时给反馈、逐步放权。8.3 持续迭代你的“协作协议”最后一条经验把每次协作都当成一次协议迭代。任务描述是协议Skill 是协议检查点设置也是协议。每次翻车或每次惊喜都是协议优化的机会。三个月下来我的“协作协议”大概迭代了十几版。从最初的“随便说说”到现在的“三段式任务描述 检查点 验收标准”每一步都是踩坑踩出来的。这套协议现在不仅我自己用团队里其他人也在用效果都还不错。提示不要追求一步到位。先跑起来再优化。完美主义是 Agent 协作最大的敌人。8.4 一个具体的“敢用”案例上个月我接了一个紧急需求给一个老项目补一套 API 文档。项目有 60 多个接口手动写至少要两天。我的做法是先让它扫描路由文件生成接口清单检查点 1我确认清单完整然后让它逐个生成文档检查点 2我抽查前 5 个的质量最后让它统一格式并写入 docs 目录检查点 3我扫一遍最终输出。整个过程花了 40 分钟其中我实际参与的时间不到 10 分钟。文档质量比我手动写的还规范因为它的格式一致性更好。这就是“敢把活儿交给它”的状态——不是盲目信任而是有检查点、有验收标准、有退路的信任。8.5 给新手的三个起步建议如果你刚开始用 WorkBuddy我给你三个建议第一从绿灯任务开始先建立信心第二每次任务都写清楚验收标准这是最重要的习惯第三每周花 10 分钟复盘看看哪些任务可以封装成 Skill。不要急着上 MCP 和复杂 Skill。先把基础的任务描述和上下文管理练熟这两项做好了效率已经能提升一大截。MCP 和 Skill 是放大器基础不牢放大器只会放大混乱。8.6 我个人的体会用了三个月我最大的体会是Agent 的能力上限取决于你的协作能力。同样的工具有人用出 10 倍效率有人用出 1.1 倍效率差别不在工具在用法。这 30 个技巧本质上都是“如何更好地跟一个 AI 协作”的具体实践。最后分享一个小技巧每次你觉得“这个任务它肯定做不好”的时候先别下结论试着把它拆成三个更小的任务再派一次。我至少有五次这样的经历拆完之后它不仅做完了还做得挺好。很多时候不是它不行是我们给的任务太粗了。