2017年，知乎有个老问题叫《TDD（测试驱动开发）是否已死？》，光一条高赞回答就有近30万浏览。那几年的主流结论是：TDD太慢、太重、不划算，是狂热分子的修行。
2026年再看，场面完全反过来了。GitHub上obra/superpowers——一套强制AI按"先写测试、红绿重构"干活的Claude Code工作流框架——星标已经冲到10万+。知乎哔哩哔哩吴恩达公开安利"AI写代码容易失控，TDD能兜底"。知乎B站上《TDD编码在AI时代的价值》这类视频播放已超过两千次。一门被嫌弃了二十年的老手艺，硬是被AI编程抬进了ICU又救活了。
为什么活过来了？不是狂热分子赢了，是AI把TDD的成本结构整个翻了个面。
成本翻了个面：从"昂贵的纪律"变成"便宜的验收"
TDD以前被嫌弃，核心就一个字：贵。先写测试再写代码，测试本身要花大量时间，省下的调试时间往往算不平这笔账。
AI把两个数字改了：
第一，写代码的成本趋近于零。AI一分钟能怼出几百行。按GitHub Octoverse和Sonar、DORA的调查，现在行业里新代码有接近一半是AI参与写出来的。知乎
第二，审查成本爆炸了。知乎问题《AI写了60%的代码，为什么企业研发效率还是没飞起来？》下面1100多赞，高票答案的意思很直白：省掉的是敲代码的时间，没省掉的是搞清楚"该写什么、写得对不对"的时间。知乎AI产出速度快到人眼review根本跟不上，代码堆在那里，没人敢拍板说它是对的。哔哩哔哩人眼审不过来，但测试跑得过来。这就是吴恩达那套玩法火起来的原因：先写测试（人可以写，AI也可以写），再让AI写实现，跑测试，把失败日志直接喂回给AI修——AI读机器日志的能力远强于人类。知乎
于是TDD的角色变了：以前是约束自己的"开发纪律"，现在是验收AI的"质检手段"。你不是在给测试打工，你是在用测试给AI打工的成果盖章。
先别急着上车：实战派已经打起来了
看好的一方，案例很足。
8月初有人完整记录了"SDD+TDD规范驱动开发"：先把需求写成spec，拆出48条前端TDD用例，AI据此生成227个测试，开局全红，逐批转绿。知乎不止个人玩家在搞，B站上专门有人拆解Superpowers怎么把"头脑风暴→方案设计→拆任务→TDD编码→系统化调试"封装成一套强制流程，单条视频1300多人收藏。哔哩哔哩还有评测视频让GSD、Superpowers和原生Claude Code同题竞技，评论区139条吵选哪个。学术界也进场了：Michael Lyu团队今年的论文，主题就是用TDD让AI生成的全栈Web应用从"能跑"变成"能交付"。哔哩哔哩
唱衰的一方，案例同样具体。
5月，一位做底层图形库的作者发了篇378赞的长文：他让Opus用TDD写一个C语言二维码编码渲染库，AI十分钟不到就把代码写出来了，然后跟testcase搏斗了整整半小时——不同version的编码错误接连出现，始终不收敛。知乎他的判断是：正常人类开发，越往后错误应该越少、趋向边界细节，这种连续致命错误说明底层逻辑就有问题。他果断叫停，改走"赛博洗稿"路线：找一个MIT协议的成熟开源二维码库，让AI按自己项目的规范改写适配，人工review，3小时收工，验收一次全过。
他的结论很扎心：稍微复杂一点的逻辑需求，Agent的pass@1率低得可怜，几十轮TDD迭代才过关是常态；而且AI生成的测试用例很少能把边界条件覆盖全，测试之外的输入，翻车率照样很高。知乎B站还有位测试领域UP主更直接，视频标题就是：《测试驱动开发是行不通的，用人工智能搞测试驱动开发更行不通》。哔哩哔哩
分水岭在哪：不是做不做，是哪些场景做
把两方案例摆在一起，边界其实看得很清楚，关键变量就两个。
第一个变量：测试写起来比代码便宜多少。
CRUD接口、数据转换、协议解析、格式校验、工具函数这类"行为契约明确"的活，测试好写、断言好断，AI写错了能低成本被抓住——这是TDD+AI的舒适区。"227个测试全绿"那个案例能成立，前提是spec已经把行为拆成了预期明确的用例。
反过来，编解码、渲染算法、密码学这类"正确性依赖深层领域知识、边界条件爆炸"的活，测试本身就难写，AI一旦没有真正理解，几十轮迭代只是在随机试错——二维码案例正好踩在这里。这种场景，找一个成熟开源实现让AI做适配，成功率反而高得多。
第二个变量：这份代码的资产寿命。
三天就扔的脚本、原型、demo，写两行断言意思一下就够了；要长期维护、持续迭代、还要交接给别人（或者三个月后交接给忘了细节的自己）的代码，测试用例是你唯一能信任的"交接文档"。
三盆冷水
TDD会让token消耗翻倍。每一轮红绿循环都是"生成→运行→喂日志→再生成"，比vibe coding费得多。HackerNews上已经在讨论Claude Code额度烧得快的问题，TDD工作流会放大这笔开销。知乎预算紧的时候，别全量TDD，挑核心模块。
AI写的测试自己也会"假绿"。覆盖率好看，改个参数名却没有一条测试变红——测试本身得先靠谱，TDD才成立。这个坑展开讲过，这里不重复，一句话：验收测试本身，也是验收的一部分。
工具不是护身符。知乎上有句评论说得挺好：这些词火了之后，都会出现一堆狂信者和异教徒。知乎Superpowers、spec-kit都是工具，装上不等于你会做设计。好的设计还是得人来做，AI负责按设计施工。
结论：谁现在值得上车
值得立刻开始的：在用AI辅助开发、项目要长期维护迭代的人。最低成本路径分三步。第一步，在你的CLAUDE.md或规则文件里加一条TDD纪律（先写失败测试，再写实现，小步提交），零成本。第二步，装一个轻量TDD skill（比如mattpocock开源的那个），十分钟的事。哔哩哔哩第三步，拿一个新的非核心项目跑一遍Superpowers完整流程，体会强制纪律和vibe coding的差别，再决定要不要常态化。
可以再观望的：日常工作以一次性脚本和demo为主的人。保持写关键断言的习惯就行，等工具链再成熟一点。
不太建议硬上的：正在跟编解码、算法正确性搏斗的场景。先想想有没有成熟开源实现可以站上去，TDD救不了"AI没真懂"。
后续值得盯三个信号：Superpowers的星标增速和Claude Code官方插件生态的动作；DORA年度报告里会不会出AI代码与测试覆盖的专门数据；以及这轮Claude Code退订争议后，Anthropic对成本问题怎么回应。这三件事任何一件有变化，"值不值得练"的答案都可能跟着变。
