给编码智能体划定任务与验收

先挑能验收的任务

不是所有代码活都适合交给智能体。好的起点有三个条件：任务定义明确、已经有自动检查能判断做没做对、出了错能回滚。DoorDash 清理过期功能开关就是这样一类活：一个开关可能散在 5 到 20 个文件里，按规则改写的工具覆盖不了，但构建、测试和覆盖率检查都是现成的。

它还把流程分成两段：第一段只读，智能体查仓库、查实验平台、写出报告，由工程师确认目标值；第二段才改代码。先让它说清楚要做什么，再放它动手。

把判卷标准锁起来

负责改实现的智能体，不能同时有权改「什么算对」。GitHub 用智能体把 Copilot 运行时改写成 83 万行 Rust，最重的一条教训就是这个：削弱测试、更新快照、放宽兼容基线、贴豁免标签，都不能在没人看着的情况下发生。具体做法：

1. 行为契约（端到端测试、接口约定）和实现分开存放，改它们要另一个人批准；
2. 检查分几层，每层失效的方式不同，一个错误不足以让大回归上线；
3. 迁移期间端到端测试不许重写，必需测试没过的 PR 不合入。

验收也要看系统最后的状态，而不是智能体自己的汇报。ThinkingBox-Bench 按后端最终状态评分，没通过的运行里有三分之二正常结束、也没有报错。

确定的步骤交给程序，判断交给模型

• Open Code Review 把选文件、打包、匹配规则、对齐行号都交给确定的程序，只把分析留给智能体；GitHub 安全实验室的模糊测试流水线里，智能体决定测什么，编译和运行 AFL 都由工具执行。
• 每个任务跑在隔离的环境里：DoorDash 每个仓库最多同时 4 个相互隔离的 Git 工作树，构建工具禁用守护进程；安全实验室明说它的流水线只应在一次性环境里、不带提升权限运行。
• 指令和工具是一体的。Copilot 代码审查换上维护更好的通用工具后效果反而变差，按审查者读 PR 的方式重写指令才翻过来。换工具就要重写指令，并重跑回归基准。

按任务记账

每类任务记四个数：首次提交就被合并的比例、需要人修改的比例、需要人接手的比例、每次的时间和花费。DoorDash 的 50 个开关里，31 个首次提交即合并、14 个要修改、5 个要工程师介入，平均 13.8 分钟、4.79 美元——拿去和人工的 1 到 2 小时比，才知道值不值。

花费要设上限并每天看。亚马逊一个给网站填充作者信息的智能体项目花了 180 万美元、超预算 860%，五个月后才被发现。

与相邻能力的分工

「智能体工作流设计」讲一般的智能体怎么搭；这一条只管编码智能体的任务边界和验收。智能体交回来的代码怎么审，见「按影响半径审查智能体写的代码」。