什么活交给 Agent

实战手记第 06 篇

前五篇讲了 Agent 怎样干活、怎样分工、规则写在哪里、证据怎样读，以及出错以后怎样复盘。最后回到最朴素的问题：手上一件事，交不交给 Agent？交出去的话，交到什么程度？

我的判断方法只用两个问题：做错了，能不能很快发现？发现了，能不能退回去？ 前者是可验证性，后者是可撤回性。这一篇用它们把任务分成四类，每类配上项目里的实际例子。读完你应该能为自己手上的任务快速归类，并知道交出去之前要准备什么。

可验证、可撤回：交给 Agent 做完

右上角的任务最适合交出去：结果可以被测试、截图或数据比对证明，改错了用 git 一退就回去。

我交出去的大部分工作都在这里：给服务补回归测试，写构建和打包脚本，重构一个模块，按设计规则改页面，画架构图，整理交付文档和验收报告。博客的项目案例改版、171 项页面检查脚本、SVG 图示和这组文章本身，也都在这一类。

交出去之前要准备的是验收条件。“把页面改好看一点”没法验收；“桌面 1440 和手机 390 宽度下无横向溢出、无失效图片、浅深色截图都要给我看”可以。验收条件写清楚，Agent 的循环就有了明确的终点。

难验证、可撤回：Agent 探索，人来判断

左上角的任务可以撤回，但好坏没有客观标准：界面风格、写作口吻、命名、方案对比。

这类任务让 Agent 多给几个选项，人来挑。作品集改版时，Agent 先给出两三个视觉方向的文字草图，我选了“作品感”的方向，它再动手实现；选错了，换一个方向重做，代价只是时间。

要注意的是，不要让 Agent 自己评价自己的方案好不好。它会给出流畅而肯定的评价，这些评价没有证据价值。

可验证、难撤回：Agent 准备，人批准

右下角的任务结果可以验证，但操作一旦执行就很难退回：生产发布、数据迁移、版本升级、合并到主干、修改线上数据。

这类任务的分工是：Agent 做所有准备工作，包括只读核对目标状态、写变更计划、准备回滚步骤、跑完测试环境的验收；人看完这些材料，对这一项具体操作给出单次授权；Agent 执行后独立回读结果。

公司 GitLab 从 19.4.1 升级到 19.5.1 就是这样做的：Agent 先核对项目数、账号数、合并请求数，准备好检查命令，得到授权后执行升级，再用 gitlab:check、迁移状态和升级前后的数量比对确认结果。海外区域的发布流程也是这个思路：测试环境由 CI 自动部署，生产环境的部署、回滚和重新部署都是手动触发的任务。

难验证、难撤回：人主导

左下角是人必须握在手里的：客户沟通、对外发送、授权和凭据管理、架构取舍。

这里 Agent 仍然能帮忙，但只做起草。私有化交付时，Agent 打包、加密、上传交付文件，并起草给客户的交付邮件；邮件保存为草稿，由我检查后发出。授权文件签发、密钥轮换、对外承诺的时间和指标，都由人决定。

这一类任务难撤回，是因为它的影响落在系统之外：一封发出去的邮件、一个交给客户的承诺，没有 git revert。

分类会随准备工作变化

同一件事，准备工作做得不同，可以落在不同的格子里。

一次数据迁移，如果只能在生产上跑，它在“难撤回”一侧；如果先在一份生产数据的副本上演练，有了回滚脚本和比对方法，它的风险就明显下降。一项界面改动，如果没有设计规则，它是“难验证”的；有了一份写清底线的设计技能和截图检查，它就接近“可验证”。

所以我花在 Agent 身上的很多时间，并不是在写提示词，而是在把任务往右上角推：补测试，建检查脚本，准备演练环境，写清验收条件，缩小授权范围。推得越多，能放心交出去的活就越多。

总结

两个问题决定一件事交给谁：能不能验证，能不能撤回。可验证又可撤回的，交给 Agent 做完；难验证但可撤回的，让它探索、人来判断；可验证但难撤回的，它准备、人批准；两者都难的，人主导，它只起草。

这组手记到这里结束。回头看，Agent 带来的最大变化，不是代码写得更快，而是我的工作从写代码转向了写清楚目标、边界和验收方法。这些本来就是工程里最重要的部分，只是过去常常被省略。想系统了解背后的概念和方法，可以接着读 AI 编程深度系列。