很多人说低成本模型可以写代码只要后面有验证就行。这句话只说对了一半。问题不是“有没有验证”而是验证到底独立于谁。如果同一个模型写代码、写测试、再解释为什么通过那只是看起来省了 review 成本。真正上线时风险可能只是被藏进了测试里。但即使换成人来验也不代表验证就完全独立。一个 reviewer 在看 diff 的同时临时写验收标准也可能被这次 patch 的形状带偏。所以我现在会把验证拆成三层。1. 独立于生成模型最基本的一层写 patch 的模型不应该同时决定什么叫通过。比如patch 是模型写的测试也是模型现写的解释也是模型自己写的。这时我只会把结果当草稿不会直接当“已验证”。更好的做法是用已有测试、人工写好的验收条件、真实 bug 复现或线上日志来验。2. 独立于 reviewer 的即时判断第二层更容易被忽略。有些验收条件虽然是人写的但也是 reviewer 在看完这次 diff 后临时想出来的。这比模型自证更好但仍然可能继承 reviewer 的盲点。例如 reviewer 只看到了正常输入没有想到空配置默认值变化权限边界计费分支fallback 行为数据迁移后的旧状态。如果验收条件是在 review 当下才补的我会标注为“弱独立”而不是强验证。3. 独立证据来源更强的证据通常来自 patch 外部。我会优先找已经存在的测试真实 bug report可复现输入线上日志用户可观察行为产品验收标准历史失败样例。这些证据不是为了证明模型聪明而是为了限制模型和 reviewer 一起想当然。我的任务卡现在会多写一行验证证据 - 证据来源 - 是否独立于生成模型 - 是否独立于 reviewer 即时判断 - 是否在 patch 前已存在 - 是否需要人工验收如果这些字段大多是空的我就不会把任务交给低成本模型直接跑完。低成本模型适合做草稿、补样板、改局部实现。但要进入可合并状态验证证据必须说清楚它到底独立于谁又来自哪里。