传统 AI 生成代码的致命弱点
直接让 AI “写一个复杂的订单结算模块”，模型生成的代码往往在表面上语法正确，但在边界条件（如浮点数精度、并发扣减、优惠券互斥）上漏洞百出。
人类难以逐行审查长篇代码，而计算机测试引擎可以。
AI TDD 的三步铁律
- Phase 1 (Red)：给 Agent 详细的需求文档，命令其只编写测试用例，测试用例必须覆盖正常流、异常流与边界值。此时运行测试，必须全部失败（证明断言有效）；
- Phase 2 (Green)：命令 Agent 编写业务代码实现，并驱动测试 MCP 运行测试。若有失败，将报错输出喂回给 Agent 自愈，直至全部测试 Pass；
- Phase 3 (Refactor)：在保证测试全绿的前提下，让 Agent 优化性能、提取通用逻辑、去除重复代码。
把需求写成可测的契约
三步铁律能否执行，取决于需求文档是否给出了可断言的行为契约。推荐用 Given/When/Then 逐条描述场景，并把边界值直接列出（比如"金额为 0、负数、超上限"三类各至少一条用例），而不是写"处理各种异常情况"这类无法判定通过与否的句子。契约中每条 Then 应当恰好对应一个断言；写不出断言的需求，说明本身还不够明确，先补需求再开工。
三阶段执行卡
| 阶段 | Agent 的输入 | 通过标准 | 失败时动作 |
|---|---|---|---|
| Red | 需求契约，禁改业务代码 | 全部用例失败且失败原因符合预期 | 用例未失败说明断言太弱，重写 |
| Green | 仅测试文件与报错输出 | 全部 Pass | 报错原文喂回，禁止改测试迁就实现 |
| Refactor | 全绿的测试套件 | 仍全绿且复杂度不升 | 回滚本步改动重新执行 |
防副作用清单
Agent 在 Green 阶段最常见的作弊路径是反过来改测试：放宽断言、删除难过的用例、给失败测试加跳过标记。对策是把测试文件设为审查焦点：CI 中单独输出测试文件的 diff 并要求人工确认；同时禁止 Agent 提交包含 skip、todo 或断言数量减少的变更。自愈循环的退避与重试策略可参考长链路 Agent 任务的错误自愈与容错重试设计模式，整体工作流的组织见打造高效可靠的 AI 编程工作流：从单轮提示到工程级上下文闭环。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| Red 阶段部分测试直接通过 | 被测代码已存在或断言过弱 | 核对测试目标函数名并强化断言 |
| Green 耗时异常长 | 报错未完整回喂，Agent 盲改 | 把栈信息与期望值差异全文喂回 |
| 全绿但覆盖率极低 | Agent 只写能过的浅用例 | 用变异测试筛掉无效断言 |
| Refactor 后测试被删 | 无护栏约束测试文件 | 测试 diff 单独审查并禁止减少断言 |
小结
这套流程是否被正确执行，一条标准即可判定：任意抽取一次任务的过程记录，Green 阶段的测试文件与 Red 阶段定稿的版本必须逐字节一致——实现代码可以重写，测试契约不可让步。做不到这一点，说明 Agent 在"为通过而改题"，需要先收紧测试文件的变更权限，再谈放权写业务代码。