一场”全绿”的失败
最近一次开发 Reminders/Calendar 工具的过程里，我用规划模型做规划、执行模型做执行。执行模型在开发过程中调用了 TDD skill，严格按”先写红绿测试、再补实现”的范式跑完了整个开发。
工具本身不复杂，但 token 消耗远超预期。执行模型给出的反馈是”红绿测试全部通过”，但实测时仍然有跑不通的地方。
关键在于：并不是测试写错了，是测试本身就在用错误的假设描述系统行为。
为什么 TDD 对 AI 失效
人类做 TDD 时，脑子里有”系统应该长什么样”的先验，测试是从这个先验里倒推出来的。AI 没有这个先验，它只能从代码里倒推测试——结果就是测试和实现相互印证，看起来全绿，实际上都跑偏了。
TDD 适合人类，是因为人能判断”测试写得对不对”；AI 缺这一环，硬套 TDD 只会堆 token + 写出自欺欺人的”通过”。
根因一句话：AI 缺少”判断自己写得对不对”的内省能力。凡是依赖”AI 自己守住边界”的范式，都会失效——因为边界不是 AI 自己想守的。
更适合 AI 的范式
同样的项目，换成这个流程之后顺畅得多：
- 先 plan——规划模型的本职
- 先开发——不写测试，直接写实现
- 再补测试——补测试是为了暴露问题，不是为了证明”我已经写好了”
- 再实测——跑真实场景，人是最后的验证关
- 有错就修、就反馈——反馈是给规划模型的，不是给执行模型的
测试的位置从”开发的先导”移到了”开发的验证”，这个顺序对 AI 才是自然的。
类似的坑：让 AI 自己守住抽象边界
同一个项目里还踩过另一个同根的坑：让执行模型在防腐层（ACL）里实现业务规则，结果它为了”让规则跑通”，本能地去改底层开源工具的源码——因为 ACL 自己”做厚了”但下游没跟着变，抽象边界就破了。
正确的分层应该按 DDD 的标准来：领域模型是心脏，ACL 只是薄薄一层翻译。把业务逻辑塞进适配层，等于让 AI 在没有先验的地方做架构决策。
收束
AI 越强，越需要人来重新校准两件事：范式（选 AI 适合的开发流程，不用人类适合的）和抽象边界（明确分层，不依赖 AI 自觉）。
Human in the loop 不是形式，是因为最后一道验证关——“这个东西真的对吗”——目前只有人能答。