AI 辅助 TDD 全流程：从需求到代码的完整防线

这是"用 TDD 驯服 AI 编码代理"系列的第 6 篇。前四篇分别讲了需求层、设计层、测试层和审核层，第 5 篇把审核层升级为程序正义。本篇把它们串成一条可落地的完整管线。

完整流程管线

产品设计 → 技术方案 → 测试方案 → 测试代码 → 业务代码
    ↑           ↑          ↑          ↑          ↑
 Ralph Loop  Ralph Loop  Ralph Loop  Ralph Loop  Ralph Loop

每个阶段有独立的输入、输出和审核规则：

• 需求阶段：输入是原始需求，输出是可测试的验收标准
• 设计阶段：输入是验收标准，输出是有依据的技术方案
• 测试阶段：输入是技术方案，输出是覆盖全场景的测试用例
• 编码阶段：输入是测试用例，输出是通过所有测试的业务代码
• 审核阶段：每个环节结束都跑 Ralph Loop，C/H/M 级问题清零才进入下一环；连续两轮零 C/H/M/L 可早停退出[1]

管线的核心逻辑是优先级传导：产品设计标记哪些验收标准是 key（必须有测试覆盖）、哪些是 peripheral（可以降级测试深度）。这个分类一路传导到测试阶段——key 的 AC 必须有完整的边界测试和错误路径测试，peripheral 的 AC 只需 happy-path。越早阶段的决策，对下游的影响越大。

为什么不能跳环节

这条管线里，错误会向下游传播。需求阶段的歧义，AI 不会帮你澄清——它会用自己的假设填空。设计阶段跳过 API 调研，AI 不会停下来问你——它会基于不存在的 API 写完整方案。测试阶段只写 happy-path，AI 不会提醒你遗漏了边界——它会把 happy-path 跑通就交差。

每一层的防线，拦截的都是上一层没拦住的错误。跳过任何一层，错误会直接进入代码，到审核阶段才发现——修复成本高了十倍。

各阶段 Checklist

需求阶段

• ✅ 验收标准是否可测试？
• ✅ 是否能做二值判定（是/否通过）？
• ✅ 有没有模糊的主观形容词？
• ✅ 是否做了澄清提问（至少 3 个问题）？
• ✅ 平台约束是否显式声明？

完整规则参考：需求层防线

设计阶段

• ✅ 每个 API 调用是否有调研结论支撑？
• ✅ 调研结果是否标注官方文档来源？
• ✅ 是否有不存在的功能假设？
• ✅ 每个组件是否能追溯到验收标准（Serves ACs）？

完整规则参考：设计层防线

测试阶段

• ✅ 每条验收标准是否有对应测试用例？
• ✅ 边界场景是否都覆盖？
• ✅ 异常分支是否有测试？
• ✅ 测试是否锚定在需求而非实现上？

完整规则参考：测试层防线

编码阶段

• ✅ 外部输入是否做了合法性校验？
• ✅ 是否有注入攻击风险？
• ✅ 测试用例是否全部通过？

审核阶段

• ✅ 审查者是否独立于创造者（不同 session）？
• ✅ C/H/M 级问题是否清零（Gate Pass 条件）？
• ✅ 连续两轮零 C/H/M/L 是否触发早停？
• ✅ 所有变更点是否可追溯？
• ✅ 审查者是否按三类结构输出（缺陷/建议/批判）？
• ✅ 主代理是否逐项做了 ADOPT/MODIFY/REJECT 决策并记录理由？
• ✅ 被拒绝的 C/H/M 问题是否在下一轮由审查者回应？
• ✅ 同一理由是否未被重复用于拒绝？
• ✅ 两轮争议未决的问题是否已升级给用户？

完整规则参考：审核层防线、程序正义入协议

Aristotle 项目复盘

这个系列的所有方法，都是我在 Aristotle 项目里踩坑踩出来的。三版迭代，每一版的失败都指向同一个根因：流程缺失。

第一版：一句话需求，371 行上下文污染

需求只有一句话：“给 Aristotle 加反思功能”[2]。AI 按自己的理解生成了 371 行 SKILL.md，全部注入主 session 上下文。功能上 37 个断言全过，但设计原则全部落空——反思任务在主 session 里跑，没有会话隔离，没有人在回路。

根因：需求阶段缺失。一句话需求留了巨大的填空空间，AI 用自己的假设填满了它。

哪层防线本可以拦截：需求层的澄清提问——“反思任务在哪里执行？““规则如何存储？““谁审核规则质量？“这三个问题能在一开始就暴露设计缺陷。

第二版：有 PRD 没做技术调研

写了结构化的 PRD，需求清晰了。但跳过了技术方案中的 API 调研环节。AI 基于不存在的 task(run_in_background=true) 做了完整的异步架构设计[2]，反思模块、通知模块、状态管理全部基于这个假设实现。到集成测试时才发现这个 API 不存在。整体返工。

根因：设计阶段缺失。PRD 锁定了"做什么”，但没锁定"怎么做”。AI 在"怎么做"的环节自由发挥，基于一个不存在的平台能力建了整座大厦。

哪层防线本可以拦截：设计层的 API 调研清单——“每个涉及平台 API 的决策，是否有调研结论支撑？“这条规则能在写第一行代码之前就拦住错误。

第三版：全流程执行

严格按 tdd-pipeline 五阶段走完：产品设计 → 技术方案（含 API 调研）→ 测试方案 → 测试代码 → 业务代码。每个阶段结束跑 Ralph Loop 审核。

人工测试阶段仍然发现了 16 个 bug。这套方法的价值不在于"零 bug”，而在于这 16 个 bug 全部准确定位到了根因，每个 bug 都有合理的解决方案，修复过程中没有引入新问题，也没有导致旧 bug 回归。AI 产出的代码质量可控了，问题能解决了，项目能交付了[2]。

在最近一次功能迭代中，这套流程的效果更加明显。各阶段的交付物和审核轮次：

一个趋势：测试方案阶段 R1 就通过了（前期的严格流程锁定了范围），测试代码和业务代码的审核都在 2 轮内收敛。越早的阶段投入越多轮审核（产品设计 R4、技术方案 R4+Council+Oracle×2），下游就越干净。

适用边界

这套方法不是银弹，要看场景用。

适合用的场景

• AI 参与度超过 50%：超过一半的代码由 AI 生成，人类做审核和方向决策。AI 写的代码越多，系统性错误传播面越广
• 需求有歧义空间的复杂业务：比如"系统应该支持高并发”——AI 会把"高并发"理解成它训练数据里最常见的方案，而不是追问你具体指标
• 技术方案涉及不确定的平台 API：AI 对平台 API 的知识可能过时或编造，必须显式验证
• 需要长期维护的生产级项目：流程文档本身就是最好的 onboarding 材料

不值得用的场景

• 逻辑确定的小工具：一个 50 行的 shell 脚本做日志清洗，需求无歧义，不存在 API 不确定的问题
• 人类完全手写的代码：没有 AI 参与，系统性错误传播的前提不存在
• 探索性原型：目标是快速验证想法，不需要流程约束

核心判断：

严格流程的边际成本，随项目复杂度下降。严格流程的必要性，随 AI 参与度上升而增加。

越复杂的项目，流程帮你省的返工时间远超流程本身的成本。AI 写的代码越多，系统性错误传播的风险越高，越需要结构化的防线来拦截。

与现有方法论的关系

这套方法不是凭空发明的。它是需求跟踪矩阵（RTM）、实例化需求（SBE）、验收测试驱动开发（ATDD）在 AI 辅助开发场景下的组合应用。详见第 3 篇的详细论述。

和传统 TDD 最大的区别是：

• 传统 TDD：开发者在脑子里做"需求→测试→代码"的映射
• AI 辅助 TDD：这个映射必须显式写下来。AI 没有"脑子里的理解”，只有写出来的文字才是它能准确理解的约束

传统开发中，一个经验丰富的工程师可以在脑子里完成"验收标准不够具体"“这个 API 需要验证"的判断。AI 不行。它不会主动质疑需求，不会主动验证假设。所以必须把人的隐性判断变成显性文档——这就是流程的必要性。

系列总结

这个系列写了六篇，其实只在讲一个原则：

AI 编码代理不是银弹。它是放大器。 既放大你的工程能力，也放大你的工程债务。要驯服它，需要比传统开发更严格的流程纪律。

回顾四层防线，每层解决一个 AI 特有的问题：

1. 需求层：AI 不会追问需求。结构化的澄清提问堵死歧义。
2. 设计层：AI 会基于不存在的 API 做设计。显式的调研清单验证每个假设。
3. 测试层：AI 会写 happy-path 跳过边界。测试文档锚定在需求上，不锚定在实现上。
4. 审核层：AI 审查自己的工作有确认偏误。独立的审查者 + 争议协议 + 连续两轮零 C/H/M/L 确认收敛——审核的每一步都有证据、有记录、有规则约束。

流程不是束缚你的枷锁，是帮你挡住 AI 胡来的防线。

参考

1. Ralph Loop 审核协议：github.com/alexwwang/tdd-pipeline, ralph-review-loop.md
2. Aristotle 项目源码：github.com/alexwwang/aristotle
3. 第 1 篇 需求层防线：为什么 AI 开发必须从 GEAR 协议开始
4. 第 2 篇 设计层防线：PRD → 技术方案
5. 第 3 篇 测试层防线：先写测试文档再写测试代码
6. 第 4 篇 审核层防线：Ralph Loop
7. 第 5 篇 程序正义层防线：程序正义入协议

Aristotle 项目在 GitHub 开源，MIT 协议。欢迎提交 Issue 和 PR。