我最近跑五款 Coding Agent、验收它们的补丁时，反复经历一串看似高效的动作：把任务复制给 Agent，把它的“已完成”搬进 PR；reviewer 提出问题，再把反馈搬回 Agent；等模型改完，继续转发下一段结果。
流程跑得很快，人却可能没有做出任何判断。他只是接收字符串、转发字符串，再等待下一个系统返回字符串。看起来是在调度 AI，实际上已经成了两个工具之间的透明接口。
我也因此越来越确定：程序员最容易被 AI 省掉的，不是复制粘贴，而是形成判断的那一步。
测试全绿之后，判断工作才刚开始
我把同一份入账通知处理任务交给五款 Coding Agent。它们读仓库、改处理器、跑测试，最后都报告通过。
我差点把这个结果直接交出去。但那两项公开测试，在故意留下缺陷的原始代码上本来就是绿的。于是我又追测了失败重试、同订单并发、不同订单并发和布尔值金额。四项都通过了，可验证过程又暴露了另一层问题。
DeepSeek 的业务代码是对的，自写脚本却把预期顺序写反了。GLM 的业务代码也是对的，自测脚本却连续错了两次：一次用了永远成功的模拟账本，一次写错异步调用方式。代码正确，不等于 Agent 对正确性的证明也正确。
功能验收结束后，我又连续送入一万个不同订单。四款实现各留下一万把临时协调锁，Codex 的处理中记录回到了 0。这不等于前四款测试失败，也不能直接称为内存泄漏；它只说明，状态生命周期根本没有进入原验收口径。
如果我只转发“测试已通过”，reviewer 还是要重新理解补丁、检查测试来源、寻找未覆盖边界。我省下的工作并没有消失，只是被推给了下游。程序员一旦不再形成自己的判断，就会从 AI 的使用者，退化为工具之间的传输层。
我开始把转交当成一道判断层
这次实测后，我给自己固定了一套转交方法，只有四个动作。
读懂输出。 我需要能解释代码、结论和报错，而不是只知道 Agent 说了什么。
重述决策。 PR 中由我自己写清改了什么、没改什么，以及为什么选这个方案。
标明验证边界。 已执行的测试、尚未覆盖的风险需要分开，验证脚本的编写者也会一并注明。
只传结论与证据。 PR 或群聊里保留决定、关键 diff、执行命令、结果和剩余风险，删掉模型寒暄和未经处理的长文。
我并不抵触让 AI 承担更多任务。恰恰相反，模型越能独立完成任务，人越不能把“已完成”当成工作终点。AI 负责生成候选，程序员负责把候选变成可交付的决定。中间少了这层判断，所谓“用 AI 提效”，很可能只是把验收和责任一起转发给了别人。
