代理循环中的TDD——是表演还是实际价值？
内容提要
作者通过实验评估AI编码代理在TDD（测试驱动开发）与非TDD工作流下的表现，发现两者在代码质量上无显著差异，非TDD甚至略优。TDD指令常被代理忽略或执行不当，且增加成本。作者建议放弃强制代理使用TDD，转而通过突变测试、静态分析等替代方法保障质量，并强调监控结果比规定流程更有效。
延伸解读
实验局限与解读提醒
作者强调这是一次探索性评估，样本量小，且依赖AI（Opus）对结果的主观判断，因此结论不宜过度推广。TDD指令的执行质量参差不齐，部分会话并未严格遵循红-绿-重构流程，可能影响对比的公平性。读者应将这些发现视为初步假设，而非定论。
TDD在代理循环中的失效机制
实验显示，非TDD和测试优先的代理倾向于在编码前先完成整体设计，而TDD指令阻碍了这一前置设计步骤，导致设计由局部决策拼凑而成。此外，代理常跳过或伪造红步，或过度实现，使TDD的核心价值（如小步前进、设计驱动）难以实现。这提示TDD的某些好处依赖于人类的认知过程，无法直接迁移到AI代理。
成本与收益的权衡
TDD工作流显著增加了会话轮次和令牌消耗，尽管缓存命中可能降低实际成本，但总体开销仍高于非TDD。鉴于实验未显示TDD在代码质量或突变分数上的优势，作者认为强制代理使用TDD的投入产出比不佳。建议将精力转向结果监控（如突变测试、静态分析）而非流程规定。
Q&A
AI编码代理在TDD与非TDD工作流下的代码质量有显著差异吗？
根据作者的实验，基于Opus对结果的判断，TDD与非TDD工作流在代码质量上没有明显差异，非TDD甚至略优。突变测试分数也没有显著差异。
为什么TDD指令在AI编码代理中常常被忽略或执行不当？
作者发现代理经常先写实现再生成测试，跳过确认红步，或过度实现。这可能是因为LLM的训练数据中，完整的函数和描述占主导，而逐步的TDD示例很少，导致模型更倾向于直接将需求转化为代码，而不是遵循TDD流程。
TDD在代理循环中无法有效实现哪些好处？
TDD的许多好处在代理循环中无法有效实现，包括：管理恐惧（心理机制）、小步前进（约束和反馈）、设计驱动（通过测试驱动设计）、以及测试先行带来的实现与断言解耦等。这些好处依赖于人类的心理和认知过程，而代理不具备这些。
作者建议用哪些替代方法来保障代码质量？
作者建议放弃强制代理使用TDD，转而通过突变测试、静态代码分析、定期审查结构和模块化、以及监控结果（如每次变更涉及的文件数）等替代方法来保障质量。此外，还提到了Approved Scenarios方法。
为什么非TDD运行在实验中表现更好？
Opus分析发现，非TDD和测试优先的运行在编写代码或测试前会先创建完整设计（包括架构、数据类型、边界情况、契约），而TDD指令阻碍了这种前期设计步骤。完整设计有助于更好的数据模型、更全面的边界情况和功能完整性。
作者个人对AI编码代理使用TDD的态度是什么？
作者个人已停止让编码代理使用TDD，转而关注TDD在代理循环外的使用，并探索替代方法。他认为在代理循环中强制TDD可能不是有效的方法，除非有更强的证据支持。
