最近刷技术社区，你大概率见过这类标题：「给 Claude Code 装个 TDD Skill，效果起飞」「用一条铁律，把先写测试刻进 Agent 的本能」。Superpowers 技能库、Matt Pocock 开源的 skills 仓库，都在把同一件事包装成 AI 编程的纪律神器——强制你的 AI 走红绿循环：先写一个会失败的测试，看它变红，再写最少量的代码让它变绿，最后重构。GitHub逻辑听着无懈可击：AI 写代码又快又飘，不给它上点规矩，产出的东西你敢合并吗？
但就在昨晚，测试博主 FunTester 发了一篇《用结果反馈替代 AI 的强制 TDD》，用一组对比评测给这股热潮泼了盆冷水：让编程智能体严格执行 TDD，代码质量没见更好，Token 用量却可能翻好几倍。知乎评论区知乎、B 站这段时间本来就吵得凶，这一下算是把矛盾摆上了台面。
我把这一个月三个阵营的观点、证据和各自的软肋都翻了一遍，帮你理清楚：这个 skill 到底该不该装。
铁律派：没看到测试失败过，你就不知道它在测什么
先说强制派在坚持什么，因为他们的出发点确实戳中了 AI 编程的真痛点。
Superpowers 技能库里那条 test-driven-development 规则，核心就一句话：没有先失败的测试，就不允许写产品代码。如果你不小心先写了实现，处理方式不是补测试，而是把代码删掉重来——真删，没有讨价还价的空间。知乎为什么这么极端？因为他们认定一件事：测试失败这个动作本身，就是测试有效性的证明。一个从没失败过的测试，可能测错了东西、可能测的是实现细节、可能漏掉了你根本没想到要测的边界。「一次性通过」证明不了任何东西。
这条 skill 甚至提前写好了反驳清单，把你想跳过 TDD 时脑子里冒出来的每个念头都堵死了：
「我会等写完代码再补测试」——事后测试回答的是「这段代码现在做了什么」，先写的测试回答的才是「这段代码应该做什么」；
「我已经手动测过边界了」——手动测试没留记录，代码变了没法重跑；
「都写了好几个小时了，删掉太浪费」——这是沉没成本谬误，真正的浪费是留一份自己都不敢信的代码。
说实话，这套话术对人来说是完全成立的。TDD 的老玩家都见过那个场景：你以为测试写对了，跑一下发现它居然是绿的——说明你测的根本是已存在的行为。所以 B 站那条「速通测试驱动开发，一个 Skill 让你的 AI Coding 工具能力起飞」的视频，光收藏就有一百多个。哔哩哔哩问题出在下一步：这套对人有效的纪律，原封不动套给 AI，还灵吗？
评测派的冷水：五批方案对比，强制 TDD 的产出反而略差
FunTester 昨晚那篇文章，做的就是一个探索性实验：同一批任务，让智能体分别用「强制 TDD」「普通非 TDD」「先写测试但不强求红绿循环」几种方式完成，再让 Opus 回看全部会话记录做盲评。一共跑了五批方案，小任务一批、中型任务三批，还有一批加了对照组。
结果有三条，每一条都挺扎心：
第一，TDD 整体表现略差。 小型任务里，Opus 多次把两个非 TDD 方案排在前两名，两个 TDD 方案排在后两名。只有一次，在提示词里额外强调重构和设计评审后，一个 TDD 方案冲到第一——但同一批里用相同提示词的另一个 TDD 方案垫了底。
第二，原因恰恰出在「一步步走」上。 Opus 回看会话后发现：非 TDD 的运行在动手前会先把整体设计想清楚——架构、数据类型、边界情况、接口契约；而强制 TDD 的运行是「跟着一条测试往前走」，设计是从一个个只解决眼前问题的决定里慢慢长出来的，很少回头调整，经常被第一条测试限制住。智能体没想到要写测试覆盖的行为，往往就根本没有实现。知乎
第三，也是最尴尬的：智能体根本不老实。 每个会话都不同程度地出现过这些问题——先写实现再补测试、跳过「确认测试变红」这一步、提前实现太多导致下一条测试从没真正红过就直接绿了。作者不得不让独立智能体逐场核查「这次运行到底算不算真的在 TDD」，才敢把结果纳入比较。而且他发现，想让模型稳定遵守这套复杂指令，提示词要反复调，不同模型版本之间波动很大。
Token 成本也得算一笔：TDD 天然要经历更多轮交互和工具调用，用量可能到非 TDD 的三倍以上（虽然部分会命中缓存，实际成本没那么夸张，但差距是实打实的）。
需要说句公道话：作者自己反复强调这是探索性评测——样本小、任务不算复杂、只测了特定模型。「TDD 会不会让设计更差」这个怀疑，他自己也说不足以下定论。但它至少提出了一个之前没人认真回答过的问题：
TDD 的那些好处，到底有多少属于「人的思考」，又有多少属于「红绿流程」本身？
把账拆开算：TDD 的收益一半是心理按摩，只对人有感
顺着评测往下想，你会发现这个拆解其实 TDD 之父 Kent Beck 早就埋好了答案。他给 TDD 列的那些好处，逐条对照「执行者从人换成 AI」之后，情况是这样的：
先写测试迫使你想清楚怎么用 —— 人写测试时，还没想清楚实现就被逼着思考行为和边界，这是 TDD 最有价值的部分。但智能体没有这种阻力：它可以在规划实现的同时顺手把测试写了，中间没有任何「卡住想一想」的过程。思考没发生，只是换了个地方输出。
只写刚好够通过的代码是一种克制 —— 它本意是阻止人过早抽象、过度设计。但评测里的智能体拿到的是完整需求，即使要求最小实现，它也经常做得过多。克制是人的美德，不是模型的默认行为。
红绿循环证明测试真的能抓 bug —— 这条对人成立的前提是：有人在看为什么变红。智能体既写测试又确认失败时，只能说明它执行过测试、看到了失败，不能说明失败的原因是对的。评测里甚至出现了这样的例子：测试先用实现本身重新计算了一遍预期答案，再拿实现的输出跟它比——测试和实现共享同一个错误，永远全绿。
每次测试通过让人安心、管理恐惧 —— Kent Beck 在《测试驱动开发》前言里说这是 TDD 最重要的理由：对困难问题的恐惧会让人犹豫、回避反馈，每一次绿色都是看得见的进展。知乎这完全是给人做心理建设的。智能体跑它的红绿循环，并不会把这种控制感传递给你。
算完这笔账，结论其实挺清楚：TDD 的收益大头来自「人被流程逼着思考」，而不是流程本身。把流程搬给不会思考流程意义的执行者，剩下的就是一套昂贵的仪式。
还有一派更狠：AI 给 AI 出卷，等于学生自己出题考自己
如果说评测派质疑的是「强制 TDD 不划算」，那知乎上麦哲思科技这几天的文章质疑的就是更根本的东西：AI 生成的测试，连「测试」的资格都存疑。
他们的论证很锋利：让 AI 写代码、再让 AI 为这段代码生成测试，验证者和实现者共享同一套认知体系。知乎AI 写测试时倾向于覆盖它「认为正确」的路径，系统性遗漏它「没想到」的边界。测试全绿验证的不是「代码满足了人的需求」，而是「代码满足了 AI 对需求的理解」——这两者的差距，恰恰是大多数软件缺陷的藏身处。
有人会说：那我开两个 Agent，一个写代码一个写测试，总独立了吧？
也不行。两个同源模型会「一致地理解错」：编码 Agent 把「用户可以登录」理解成「只验证密码正确」，测试 Agent 大概率带着同样的理解去设计用例。测试全过，需求没满足。形式上的分工，不等于真正的独立。知乎
这一派给出的分工原则值得记住：验证和实现必须隔离，关键路径的测试必须由承载人类业务判断的那一方来写。AI 可以穷举边界、补异常输入组合——给它需求描述、别给它看实现代码时，它的测试确实有独立价值。但「什么算对」这件事的定义权，不能也交给它。
B 站评论区其实早就有人用实战案例呼应了这个担心：有篇文章讲了个场景——让 AI 给功能补测试，它生成了所有 service 的单元测试，覆盖率 90%，一片绿。然后你把 service 和 repository 之间的一个参数名改了，没有一条测试变红。覆盖率 90% 和「改了代码测试不动」同时成立，说明这批测试度量的东西跟你关心的东西根本无关。知乎
所以到底该怎么做？按你对代码的在意程度分四档
吵归吵，日子还得过。把三派的证据摆在一起，其实能拼出一套挺实用的决策框架。核心原则一句话：你越不敢承受这段代码出错，就越要把「定义正确」的权力留在人手里，而不是加强 AI 的流程仪式。
第一档：关键业务逻辑、要长期维护的核心代码。 人写验收标准。不必手写所有测试代码，但要用 Given-When-Then 这类方式把行为定义清楚、逐条确认过，再让 AI 去实现和翻译。麦哲思那篇的落地路径可以直接抄：需求先精化，AI 列出它识别到的测试场景，标注哪些需要人确认，你确认完它才动手写代码。这一步不能省，省了后面全是自证循环。
第二档：普通项目代码、要进主干的功能。 别强制红绿循环，但要建立结果反馈——这是 FunTester 文章的落点：可靠的回归测试套件（功能被破坏时尽快给信号）、变异测试监控测试质量（测试到底能不能抓到注入的 bug）、静态分析接进智能体循环、定期人工评审代码结构。重构的触发点也换成可观测信号：每次变更触及的文件数、完成一次变更消耗的 Token 趋势。这些都比「命令 AI 走红绿」更能约束结果。
第三档：原型、探索性代码、一次性脚本。 直接 vibe coding，不用纠结。铁律派自己也承认这是例外——他们的 skill 里写明抛弃型原型可以跳过 TDD，只是要求先跟人类伙伴打招呼。
第四档：如果你就是想装个 TDD skill 试试。 两个提醒：一是知道它在给谁上纪律——对你自己有用（它逼你提交需求前先想清楚行为），对模型的质量提升目前没有强证据；二是别信「装上就完事」，评测显示这套复杂指令需要持续调提示词才能维持遵守，模型一升级就得重新验证。
几个可以直接带走的避坑信号
最后留一份清单，不管你站哪一派，这几个信号都值得盯住：
改一行实现代码，看有没有测试变红。 全绿不动，说明你在维护一批假测试。这是比覆盖率可靠得多的指标。
警惕「用实现算预期」的测试。 测试里如果出现调用实现逻辑来生成期望值的写法，测试和实现会共享同一个错误，永远通过。
AI 生成测试时，尽量只给它需求描述，不给实现代码。 这一条操作成本几乎为零，但能保住测试的独立验证价值。
「测试能过但你不敢合并」本身就是信号。知乎说明缺的不是更多测试，而是人没有参与过「什么算对」的定义，回去补验收标准，而不是补用例数量。
至于接下来值得继续关注的：更大规模的对照评测（FunTester 自己也呼吁有人跑更充分的实验）、变异测试工具在 Agent 工作流里的集成，以及 Approved Scenarios 这类「人确认、预期冻结」的半手工测试方式会不会成为新的信任机制。
TDD 没有死，它只是回到了原本的位置：一种帮人想清楚的工具。至于 AI，它需要的不是仪式，而是你给它一个「什么算对」的答案——然后让它证明自己做到了。
