用 AI 写代码的人，大概都经历过同一个噩梦：你告诉它这里有个 bug，它秒改；改完跑一下，另一个地方炸了；再让它修，第三个问题又冒出来。代码越改越长，token 一轮一轮地烧，问题却越修越多。
知乎上有个提问叫「Claude Code 改一个 bug 就引入另一个 bug，陷入死循环怎么办？」，一千多人点了赞。高赞回答的观察很直接：只用事后验证，AI 经常修一个 bug 引入另一个，形成无限循环。知乎破法是让测试先行——测试成为 AI 必须遵循的规格，而且是一份可执行、可验证的规格。
为什么 AI 修 bug 不收敛
AI 修 bug 的死循环，本质是它没有一个客观的「停下信号」。它判断「修好了没有」的方式，是读完最新一段上下文之后的自我感觉。对话越长，早期指令的权重越低，它眼里只有最近几句话和眼前的代码，直觉就是动手改。
TDD 的红绿循环，补的正是这个缺失的信号。一个会失败的测试，是最干净的机器可读信号：红了就是没修好，绿了就是修好了，不用解析日志，不用猜。有位做 Unity 的开发者把 TDD 驱动器嵌进编辑器、让 AI 自己跑测试循环，他的经验是：AI 读退出码比解析任何输出都可靠，一个数字就是全部信号。知乎AI 有了能读懂的红绿状态，才能一个行为一个行为地往前推，而不是「感觉差不多」。
更隐蔽的坑：别让 AI 连代码带测试一起写
听到「用 TDD 约束 AI」，很多人的第一反应是：那让 AI 写代码的时候顺手把测试也写了，一站式搞定。
这恰恰是最危险的打开方式。
一位在 nginx 团队工作的开发者做过一个实验：让 AI 从零写一个 C 语言压测工具，自己一行代码不写。复盘时他发现，bench 模式里 fetch 根本跑不起来，每一次请求都失败；但测试报告写着：16576 次请求，0 错误，通过。知乎原因是代码把每次调用无条件计入「成功」，而测试只盯着这个数字。
他的总结很扎心：AI 写的代码不检查错误，AI 写的测试也不验证错误，实现和测试出自同一个模型，盲区是一致的。知乎只有人从外部把「什么算对」先定义出来，才能打破这个闭环。
所以 TDD 在 AI 时代的角色变了：它不再是写完代码补的安全网，而是一份先行的验收协议。代码可以交给 AI，但「正确」的定义不能也交给它。
顺序才是关键：先写一个会失败的测试
Claude Code 生态里最火的 skills 框架 Superpowers，有一条被称为「铁律」的规则：没有先失败的测试，就不允许写产品代码，顺序写反了唯一处理方式是删掉重来。知乎
它听上去教条，背后逻辑却很硬：先写测试的价值，在于逼你亲眼看到它失败。知乎一次就通过的测试证明不了任何事——它可能测的是早已存在的行为，可能测的是实现细节，也可能刚好和一个错误实现吻合。「看到它失败」本身，就是测试有效的证明。
这套循环拆开就是三步，TDD 的全部精华，浓缩在三个字里：红、绿、重构。知乎先写一个会失败的测试，运行，看到 FAILED 且符合预期（是功能缺失，不是写错变量名）；再写最少量的代码让它变绿，PASSED 且不多写一行；最后在全绿的前提下重构，重构完依然全绿。修 bug 同理：先写一个能复现 bug 的失败测试，再让 AI 修到绿。不这么做，你永远无法证明 bug 真的被修好，也拦不住它下次回来。
最小行动清单：什么场景用什么强度
TDD 不是所有场景都要全套上。社区已经把适用边界摸得差不多了：业务逻辑、算法、修 bug、会被大量复用的公共工具库、重构旧代码，这几类非常适合；UI 交互、探索性原型、第三方 IO 集成、需求一天三变的早期产品，则要小心，硬套先写测试反而是浪费。
按任务类型分档，可以直接抄：
修 bug：先写复现测试（红），让 AI 修到绿，再跑一遍全量回归。成本几分钟，换回来的是「bug 真的被修好」的证明和一条免费回归护栏，这是 AI 时代 TDD 性价比最高的场景。
小功能：先列行为清单，一个行为一个红绿循环，每次只写刚好通过当前测试的代码，全部绿了再重构。反模式是一次写完所有测试再写所有实现——那种测试会在行为正确时失败、行为错误时通过，测的是结构不是行为。
大重构、多人协作：值得上流程约束，把「先失败测试」写成项目规则，或者按需启用单个 TDD skill，而不是一键全装。
流程工具：按需挂，别全装
Superpowers 刚出来时全社区安利，GitHub 星标一路冲到二十多万，靠的就是把 brainstorm、spec、plan、TDD、review 整套流程焊在 Agent 身上。但今年的风向已经变了：有人实测装全之后，启动就要吃掉 22000 个 token 的上下文，还没干活就先占掉一成窗口。知乎有人让它改个变量名，它先头脑风暴再写 spec 再出 plan，十秒的活干五分钟；还有人发现 prompt 注入的流程约束会随着对话变长而衰减，七八轮之后 Agent 就开始「飘」，根本原因是 system prompt 的约束力随上下文长度衰减。知乎
所以现在更稳的姿势是「按需启用」：CLAUDE.md 写好项目规范和那条铁律，特定场景挂一两个轻量 skill，一个任务一个短会话，每个任务都带可执行的验证标准。今年上半年很火的 SDD（规范驱动开发）其实是同一路思路的另一支：先把可验收的规范立起来，再让 Agent 照着干。工具会换，「先给 AI 一个可验证的规格」这个内核没换。
这笔账：拿什么换什么
TDD 推了二十年没普及，核心原因是测试成本太高。现在 AI 把写测试的成本打下来了，测试的价值反而被抬高了：当代码生成不再是瓶颈，验证就是新的瓶颈。有开发者用 AI 三天写出项目 70% 的代码，之后花了一个月逐页验证——按钮能点不代表流程能走通，接口返回 200 不代表业务正确。知乎
社区把这笔账画成过一张对比图：不用 TDD，编码只占 30%，调试加返工吃掉 70%；用上 TDD，时间前移到测试加编码，早期慢一点，后期省回大量返工。早年的实证研究也给出过方向一致的结论：IBM、微软研究院的案例显示，TDD 能把交付后的缺陷率拉低四成以上，前提是前期付掉测试成本。AI 时代这个前提变便宜了，这笔买卖就成立了。
「TDD 之父」Kent Beck 曾说过：如果有 AI 帮我写测试，TDD 会更流行。知乎当年没几个人当真，如今它正在一天天变成现实。
最后留一个观察信号：新一代模型越来越会自己规划、自己验证，「skill 不用装」的声音确实越来越大。但无论工具怎么进化，「把验收标准用可执行测试的形式交给 AI」这一步短期内不会过时。模型再强，你也需要回答那个问题：什么才算对。
TDD 教你的从来不是怎么写代码更快，而是先定义「对」，再谈实现。这句话在 AI 时代，比过去二十年里的任何时候都更值钱。
