TDD 不是背概念，是一套能跑的铁律——这个 Skill 把它写成了检查清单

写代码这件事，最难的不是「怎么写」，而是「怎么证明它能跑」。大多数开发者习惯先写实现再补测试，结果呢？测试写完就过了——因为你写的测试，其实是在验证自己脑子里已经跑过的那段逻辑，而不是在验证代码本身。

这个 Skill 把 TDD（测试驱动开发）写成了一套铁律：红→绿→重构，三步循环，不许跳过任何一步。

核心就一条铁律

没有失败的测试，就不能写生产代码。先写测试，看着它挂，再写最少的代码让它通过，然后才允许重构。

听起来很简单对吧？但「先写测试」四个字，大部分人做不到。不是不会，是忍不住——看到功能空着，手比脑子快。这是人的本能，Skill 的做法是直接帮你卡死这条线：测试没失败过，生产代码一行都不许敲。

红→绿→重构，怎么跑

RED 阶段：写一个最小化的测试用例，描述你期望的行为。比如一个重试函数——应该失败 3 次才成功。测试名要清楚到什么行为、什么结果，不要写「retry works」这种模糊名字。

GREEN 阶段：写最少的代码让测试通过。不许加功能，不许优化，不许动其他代码。代码丑？先忍着，过了再说。

REFACTOR 阶段：测试全绿之后，才允许清理——去重、改善命名、提取辅助函数。这个阶段测试必须一直保持绿色，不允许引入新行为。

为什么值得用

最大的价值不是测试覆盖率，而是「迫使你先想清楚要什么」。测试写出来之后，你才知道这段代码的接口应该是什么样的、边界在哪、失败场景是什么——这些在你写实现之前想清楚，成本最低。

其次是信心。改完代码点一下就跑，绿了就是绿了，不用人工盯着验证，也不用担心改 A 坏 B。

安装方式

在 Claude Code 里直接：claude --plugin-dir ./skills/test-driven-development（需要先 clone obra/superpowers 仓库）

这不是教你背 TDD 概念，是给你一套可操作的检查清单。每次实现功能前跑一遍，代码质量会说话。

GitHub 地址 · obra/superpowers · 264k ⭐

GitHub: https://github.com/obra/superpowers/tree/main/skills/test-driven-development