低成本模型写代码时，验证到底要独立于谁？

很多人说，低成本模型可以写代码，只要后面有验证就行。

这句话只说对了一半。

问题不是“有没有验证”，而是验证到底独立于谁。

如果同一个模型写代码、写测试、再解释为什么通过，那只是看起来省了 review 成本。真正上线时，风险可能只是被藏进了测试里。

但即使换成人来验，也不代表验证就完全独立。一个 reviewer 在看 diff 的同时临时写验收标准，也可能被这次 patch 的形状带偏。

所以我现在会把验证拆成三层。

1. 独立于生成模型

最基本的一层：写 patch 的模型，不应该同时决定什么叫通过。

比如：

• patch 是模型写的；
• 测试也是模型现写的；
• 解释也是模型自己写的。

这时我只会把结果当草稿，不会直接当“已验证”。

更好的做法是用已有测试、人工写好的验收条件、真实 bug 复现或线上日志来验。

2. 独立于 reviewer 的即时判断

第二层更容易被忽略。

有些验收条件虽然是人写的，但也是 reviewer 在看完这次 diff 后临时想出来的。

这比模型自证更好，但仍然可能继承 reviewer 的盲点。

例如 reviewer 只看到了正常输入，没有想到：

• 空配置；
• 默认值变化；
• 权限边界；
• 计费分支；
• fallback 行为；
• 数据迁移后的旧状态。

如果验收条件是在 review 当下才补的，我会标注为“弱独立”，而不是强验证。

3. 独立证据来源

更强的证据通常来自 patch 外部。

我会优先找：

• 已经存在的测试；
• 真实 bug report；
• 可复现输入；
• 线上日志；
• 用户可观察行为；
• 产品验收标准；
• 历史失败样例。

这些证据不是为了证明模型聪明，而是为了限制模型和 reviewer 一起想当然。

我的任务卡现在会多写一行

验证证据： - 证据来源： - 是否独立于生成模型： - 是否独立于 reviewer 即时判断： - 是否在 patch 前已存在： - 是否需要人工验收：

如果这些字段大多是空的，我就不会把任务交给低成本模型直接跑完。

低成本模型适合做草稿、补样板、改局部实现。

但要进入可合并状态，验证证据必须说清楚：它到底独立于谁，又来自哪里。