昨天知乎上有个问题火了：「TDD（测试驱动开发）是否已死？」29 万浏览量。一位做了十几年软件测试的老手回答：他最近用 AI 当助手，花 18 个小时跟着《测试驱动开发：入门、实战与进阶》走了一遍核心章节，结论有点反直觉——TDD 以前被嫌弃太慢，但 AI 时代，"慢"反而成了优势。知乎
这个问题能吵起来，是因为 TDD 真的"死"过一次。2014 年，DHH（Ruby on Rails 之父）说过一句著名的话：TDD is dead. Long live testing。从那以后，程序员圈子里的主流论调基本是：TDD 好，但它太慢、太教条，不适合快速迭代。知乎
而现在，AI 把它捞了回来。但我翻了一圈最近知乎、B站、微博上的讨论，发现：复活是真的，坑也是真的。
复活派：AI 太快了，快到你更需要先定义"什么是对的"
复活派的逻辑一句话能说清：AI 写代码太快，快到"错的方向"变得特别贵。
知乎那篇高浏览量的回答说得很直白：AI 生成代码很快，但它不清楚"产出的东西到底是不是我真正想要的"。需求定义模糊时，AI 输出越快，方向错了返工成本越高。TDD 刚好补上这个缺口——人先用测试把接口行为定义清楚，再交给 AI 填实现。测试不再只是用来验证对错，而是用来定义"什么才是正确"。知乎
这不是空谈。B站技术蛋老师那条《新手也能上手的AI终端开发模式-AI测试驱动开发(AI+TDD)》，去年 9 月发的，播放量近 10 万，收藏 1200+。哔哩哔哩更典型的是 GitHub 上的开源项目 obra/superpowers——一套给 AI 编程助手用的"工程习惯技能包"，把"先写测试、看它失败、再写代码"列成铁律，今年 2 月的视频里它的星标已经超过 6 万，知乎上还有专门拆解它 TDD skill 的文章：红-绿-重构循环、"好测试"的标准，以及一长串用来反驳"这次就跳过 TDD 吧"的理由清单。哔哩哔哩知乎
反方也不是抬杠：写测试的和写代码的，是同一个 AI
但反方的火力同样猛。微博博主爱可可-爱生活 6 月直接开炮：「别再逼 AI 做 TDD 了，这是在用人类的拐杖折磨机器」。微博观点概括一下：强制 AI 写代码前先写测试，非但没提高质量，还增加 token 消耗——这条引用的"最新研究"没给出具体出处，我没能核实到原始论文，先按单方说法存疑；但后面这条是真扎心：AI 写测试和写代码遵循同一个概率模型，一个可能写错代码的 AI，同样会写出有漏洞的测试。
这一下就打在 TDD 的命门上。TDD 的隐含假设是"测试是可信的裁判"。当裁判和选手是同一个 AI，就成了自己给自己批改作业。
真正的争论点：不是写不写，而是"绿"值不值钱
往下翻我越来越觉得，两派其实在打同一个靶：TDD 之争的核心从来不是"要不要写测试"，而是"你的绿，有没有含金量"。
8 月 7 日知乎一篇《AI 写的单元测试，绿得没有含金量》，作者是大厂做质量方向的，全是翻车现场。知乎
AI 写了个下单接口测试，断言 status == 200，过了。但返回体里金额是 null，订单状态还停在 created——功能早挂了，测试还绿着；
支付服务全 Mock，测试"完美通过"，上线后才发现真实网关返回的金额是字符串，Mock 把真实的坑全盖住了；
assertTrue(user != null)，可 user 是刚 new 出来的，这断言永远为真；
正常路径测出 90%+ 覆盖率，“库存不足”"余额不够"这些异常分支一条用例没有，生产上第一次触发就是 500。
更扎心的是另一个帖子：一位开发者让 Codex 给存量计费模块补单测，覆盖率从 50% 冲到 90%，报告一片绿。知乎他不放心，把核心费率计算函数里的一个乘号改成加号，重跑——所有测试全过，一个没红。那几十个测试压根没在验算出来的钱对不对，全在断言"函数能调通、返回不是 null"。测的是"程序没崩"，不是"算得对"。
知乎上还有篇拆解 vertical-tdd 的文章，把这事说得更透：你让 Agent 实现功能并带上测试，它会生成所有 service 的单元测试，覆盖率 90%，一片绿；可你把 service 和 repository 之间的一个参数名改了——没有一条测试变红。知乎原因很简单：每一层都 mock 掉下一层，每条测试只证明了一件事——“我正确地调用了下一层的 mock”。测试从没让这两层真正握过手。
今天就能用的一招：把代码故意改坏一行
那怎么办？社区已经摸出了一套共识，核心就一句话：别信"全绿"，信"戳一下"。知乎
方法很土，一分钟上手：把被测代码故意改错一行——把 + 改成 -、> 改成 >=、返回值改个数——然后重跑测试。测试挂了，说明它真在测；还是一片绿，这堆测试删了都不可惜。知乎这招在测试领域有个正式名字叫变异测试（mutation testing），AI 时代它从学术概念变成了人人可用的土法抽检。
再配上几条自查项（直接从经验帖里提炼，可以贴进你的提示词或 PR 清单）：
每个用例是否断言了"业务结果"：返回值关键字段、数据库副作用、状态的真实变更，而不只是状态码；
Mock 是否只用在外部不可控依赖（网络、第三方、时间），被测逻辑本身一律不 Mock；
异常分支有没有对应用例，还是只测了一条 happy path；
断言里的预期值是不是手算出来的，而不是从实现里抄的。
给不同人的判断
这场争论对不同人答案其实不一样：
Vibe coding 做原型、一次性脚本的：别硬上 TDD，这点两派没有分歧。但交付前保留"戳一下"的手感——手改一行看测试红不红，成本极低。
用 AI 写正经项目的（个人或小团队）：更稳的姿势不是"让 AI 写完代码顺手补测试"，而是先让 AI 出一份测试矩阵——哪些正常路径、哪些异常路径、哪些边界路径，你确认矩阵后再让它填实现。知乎知乎有篇文章的标题就是判断：不要只让 Agent 写测试，要让测试约束 Agent。不然测试失败时，Agent 为了让结果变绿，可能会改弱测试、跳过测试、甚至动 CI。知乎
守着存量项目、想让 AI 补测试的：可以，AI 搭测试架子、写模板是真快。知乎但合入前做变异抽检，重点审异常分支和断言内容。覆盖率数字好看的时候多问一句：我改这行代码，哪条测试会红？
回到那个 29 万浏览的问题：TDD 死了吗？
那篇回答说：TDD 以前被嫌弃太慢，但 AI 时代，慢在前面把方向搞对，后面 AI 才能快得有价值。知乎我想补一句：AI 复活的不是 TDD 的仪式，是 TDD 的原始问题——写代码之前，你到底知不知道什么叫"对"。
仪式可以变，红绿循环可以压缩，测试的体力活可以交给 AI。但"验证测试本身"这件事，暂时还没人能替你做。
