我最近把同一项入账通知处理任务交给五款 Coding Agent。它们读仓库、改处理器、跑测试，最后都返回“已完成”。随后若把这句话搬进 PR，再把 reviewer 的意见贴回对话框，流水线会很顺，责任却像一件被改签的快递，继续送往下游。
实测很快呈现出这种角色退化。人一直在复制任务、转交意见、等待重跑；Agent 和 reviewer 都在输出，真正属于人的验收结论却没有出现。消息走完全程，责任没有签收人。
人若只搬运“已完成”和 reviewer 反馈，就没有完成验收，只是把验收责任推给了下游。
公开测试的区分力失效
五款 Agent 的公开测试全部通过。这个结果看上去足以交差，直到我把同一组测试跑在故意保留缺陷的原始代码上：依然全绿。
能够放过已知错误的测试，无法证明新补丁正确。于是我继续追测四类边界：失败后能否重试、同一订单并发是否重复入账、不同订单并发是否互相阻塞，以及布尔值金额是否被误当成数字。到这里，验收才从“Agent 说跑过”变成可复查的证据。
四类补充场景最终全部通过，但它们分别对应真实风险。五次绿灯若共享同一盲区，实际效果只是把同一个遗漏确认五遍。问题未必是 Agent 欺骗，更常见的是它认真完成了一套无效验收。
这也解释了为什么转发测试结果远远不够。下游 reviewer 若还要重新判断测试是否具有区分力，所谓节省的工作并未消失，只是换了收件人。
自测脚本仍需独立审查
进一步追测中，有两个实现的业务代码本身正确，自测脚本却错了。一个把预期执行顺序写反；另一个先使用了永远成功的模拟账本，随后又写错异步调用方式。若只读测试终端的红绿颜色，正确补丁可能被误判，错误验证也可能被当作证据。
测试脚本同样是 Agent 的生成物，必须留在审查范围内。它不能因为名叫“测试”，就自动升格为裁判；至少要核对输入、预期、失败条件和调用路径。
功能验收结束后，我又连续送入一万个不同订单。四个实现各留下了一万把临时协调锁，另一个实现的处理中状态回到 0。这里不能做品牌排名，也不能直接下“内存泄漏”的结论：这些锁是否可达、是否持续增长、是否会被后续机制回收，都需要额外观测。它能证明的只有一件事——状态生命周期此前根本不在验收口径里。
换言之，功能正确与运行期状态可控是两项不同结论。前一项已经有边界测试支撑，后一项当时只能标为待观察。把两者分开，既不会夸大风险，也不会因为功能通过就顺手抹掉风险。
验收责任需要进入转交包
现在我把一次 AI 代码交付压成四格转交包：结论、证据、边界、剩余风险。
“结论”说明改了什么、为何这样改；“证据”保留关键命令、测试对象和结果；“边界”明确哪些场景已验证、哪些没有；“剩余风险”写下仍需观察的状态、并发与生命周期问题。四项都写不清时，“已完成”只是一条通知，不是一份交付。
转交包把人的判断压缩成下游可以复查的最小单位。证据不足就写未知，边界未测就留待办；诚实的不完整，胜过漂亮的“全部完成”。
AI 可以生成代码，也可以生成测试，但验收责任不会因此自动转移给它。程序员不能外包的是证据与结论之间的判断。少了这一层，程序员便退化为消息经过时亮一下的接口灯。
