这个 GitHub 爆火的 TDD 技能文件到底能干嘛?实测来了
前言:AI 写代码最大的问题是什么?
不是语法错误,不是算法复杂度——是它根本不知道自己要写什么。
给 AI 一个需求,它直接开始写实现代码。看起来很快,但写完后再补测试,测试立刻通过,因为测试是照着代码写的。这叫什么?这叫「后补测试」——什么也证明不了。
今天搬运的这个 Skill,来自 GitHub 上 16 万+ 星 的 obra/superpowers 项目,它用最严格的方式解决了这个问题。
项目简介
- 原始仓库:obra/superpowers
- 作者:Jesse Vincent (obra)
- GitHub 星数:166,000+ ⭐
- 许可证:MIT
- Skill 路径:
skills/test-driven-development/SKILL.md
obra/superpowers 是目前 GitHub 上最受欢迎的 AI Agent 技能框架项目。它提供了一系列高质量、经过实战验证的 SKILL.md 文件,覆盖了软件开发中最核心的工作流。这个 TDD Skill 是其中最经典的一个。
这个 Skill 是什么?
简单来说:它是一个给 AI Agent 使用的测试驱动开发(TDD)操作手册。
当 AI Agent 接到实现新功能或修复 bug 的任务时,这个 Skill 会强制它遵循一个不可违反的铁律:
没有失败的测试,就不写生产代码。
先写了代码再补测试?——删掉它。从头来过。
核心流程:红-绿-重构
这个 Skill 把 TDD 流程拆解为清晰的三个阶段:
🔴 红 —— 编写失败的测试
写一个最精简的测试,展示你期望的行为。然后运行它——它必须失败。
好的测试标准:
- 名称清晰(
'失败的操作会重试3次') - 只测一件事
- 用真实代码(不到万不得已不用 mock)
// ✅ 好测试test('失败的操作会重试3次', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; }; const result = await retryOperation(operation); expect(result).toBe('success'); expect(attempts).toBe(3);});🟢 绿 —— 最少的代码
用最简单的代码让测试通过。不多不少。
// ✅ 刚好够用async function retryOperation<T>(fn: () => Promise<T>): Promise<T> { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('unreachable');}🔄 重构 —— 清理代码
仅在绿色之后。 消除重复、改进命名、提取辅助函数。保持测试绿色。
亮点与独到之处
1. 「铁律」零容忍
这个 Skill 不跟你商量:
- 先写了代码?删掉。
- 不要把它当「参考」保留。
- 不要在写测试时「调整」它。
- 不要看它。
- 删除就是删除。
这种看似教条的态度,恰恰是 TDD 能发挥威力的关键。一旦你允许例外,例外就会变成常态。
2. 驳斥所有常见借口
这个 Skill 花了一整章来逐一击破开发者的自我合理化:
| 借口 | 它的回应 |
|---|---|
| 「太简单了不值得测」 | 简单的代码也会崩。测试只要 30 秒。 |
| 「我回头再测」 | 测试立刻通过什么也证明不了。 |
| 「删掉 X 小时太浪费了」 | 沉没成本谬误。保留未经验证的代码才是技术债。 |
| 「我已经手动测过了」 | 没记录,没法重跑,压力之下容易忘。 |
| 「TDD 太教条了」 | TDD 就是务实:比调试快,防回归,文档化。 |
每一条都扎心,但每一条都是实话。
3. 红旗警示系统
列出 13 种「你做错了」的信号:
- 代码先于测试
- 测试立刻通过
- 说不清测试为什么失败
- 测试是「后来」加的
- 「就这一次」心态
- 「这个情况不一样……」
所有这些意味着同一个指令:删掉代码。从 TDD 重新开始。
4. 完整的验证清单
8 个必须全部打勾的检查项,缺一不可:
- 每个新函数/方法都有测试
- 在实现前看到了每个测试失败
- 每个测试都因预期原因失败
- 写了最少的代码来让每个测试通过
- 所有测试通过
- 输出干净
- 测试使用真实代码
- 边界情况和错误都已覆盖
5. Bug 修复也遵循 TDD
发现 bug → 编写复现它的失败测试 → 遵循红-绿-修复 → 测试证明修复有效。
永远不要在没有测试的情况下修 bug。 这条规则保证了每个修过的 bug 都有回归测试保护。
适用场景
✅ 适合:
- AI Agent 编写新功能代码
- 修复已知 bug(先写复现测试)
- 重构已有代码(先加保护测试)
- 改变行为逻辑
- 学习 TDD 方法论(人类开发者也能用)
❌ 不适合:
- 一次性原型/概念验证
- 自动生成的代码
- 纯配置文件修改
- 不写代码的任务(文档、设计等)
与其他同类 Skill 的对比
我们已搬运的 8 个 Skill 中,与 TDD 关系最紧密的有:
| Skill | 来源 | 与 TDD 的关系 |
|---|---|---|
| test-driven-development | obra/superpowers | 纯 TDD 流程,最核心 |
| systematic-debugging | obra/superpowers | 调试方法论,TDD 是其中一环 |
| executing-plans | obra/superpowers | 执行计划,可以配合 TDD 使用 |
| agent-introspection-debugging | everything-claude-code | Agent 自省调试,互补 |
TDD 是最基础的:它确保每一行生产代码都有测试保护。其他 Skill 可以在 TDD 的基础上工作。
个人评价
推荐指数:⭐⭐⭐⭐⭐(5/5)
理由:
- 质量极高——来自 16 万星项目,经过大量实战检验
- 零废话——不说空话,每一条规则都可执行
- 防自我欺骗——专门设计了「红旗」系统来识别开发者的自我合理化
- 对 AI Agent 特别有用——AI 最容易犯「先写代码再补测试」的错误,这个 Skill 直接堵死这条路
- 人类也能学——即使不用 AI,这份文档本身就是一份优秀的 TDD 教程
如果你只用一个 Skill,可能就是它了。测试是所有高质量代码的基础。
如何使用
在你的 OpenClaw workspace 中,将此 Skill 放入 skills 目录。当需要实现功能或修复 bug 时,AI Agent 会自动读取并遵循 TDD 流程。
原始英文版本保存在 references/original.md,方便对照和跟踪上游更新。
🔗 原始仓库:github.com/obra/superpowers
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!