这个 TDD Skill 硬核到不给”差不多”留活口——RED-GREEN-REFACTOR 三步循环

每次写代码先写测试，这件事说起来容易，做起来……大家都懂。

最近挖到一个挺有意思的 Skill——Test-Driven Development，来自 GitHub 24.6k Star 的 superpowers 项目。这套 Skill 不是什么新概念，但它的执行规则写得极其硬核，几乎不给”差不多得了”留任何口子。

它的核心理念就一条铁律

「NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST」——没有先写一个会失败的测试，就绝对不能写生产代码。

注意”失败”是关键词。你必须亲眼看到测试跑不通，才能证明这个测试真的在测你想要的逻辑。测试一次性通过？说明你在测已经存在的行为，不是你要加的新功能——得重写。

RED-GREEN-REFACTOR 三步循环

这个 Skill 把 TDD 拆成了一个极度具体的操作循环：

• RED：写一个最小化的测试，只测一个行为，让它失败
• GREEN：写最少的代码让测试通过，不多不少
• REFACTOR：在测试保护下清理代码，保持所有测试绿色

每一步都有强制验证：RED 阶段必须运行测试确认失败，GREEN 阶段必须再运行确认通过。它甚至在 SKILL.md 里附了一个 DOT 图，把这个循环画成了一个状态机。

反 rationalization（反自我合理化）写得很有意思

Skill 里专门列了一张「常见借口 vs 现实」的对照表，比如：

• “太简单了不需要测试” → 简单代码也会挂，测试只要 30 秒
• “我之后再补测试” → 测试后写永远会直接通过，等于没测
• “手动测试过了” → 手动测试没有记录，不能重复跑，压力一大就忘

基本上把你可能会说服自己的每一条路都堵死了。

好在哪？

这个 Skill 不是教你”什么是 TDD”，而是直接给你一套可操作的强制流程。你不需要认同它的哲学，它也不跟你讨论——它只要求你按步骤来。它特别适合接在 subagent-driven-development 或 writing-plans 之后，在真正动手写代码的环节卡住你，不让 agent 跳过测试直接实现。

超级硬核，但也正因为硬核，才有价值。

GitHub：https://github.com/obra/superpowers

GitHub: https://github.com/obra/superpowers