Superpowers插件上手指南:42000+用户的选择,TDD工作流正确姿势

“我不是伟大的程序员，我只是程序员。” —— Kent Beck

2026年的今天，AI编程工具已经火遍全球。根据最新调查数据，51%的GitHub代码是由AI生成或辅助生成的。但有一个尴尬的事实：大多数AI生成的代码连基本的测试都没有。

我之前也是这么干的：让AI帮我写代码，它咔咔一顿输出，我啪啪啪复制粘贴提交。直到有一天，我维护的一个”AI写的”核心功能在线上炸了——30%的测试失败率，各种边界情况没处理，SQL注入漏洞了解一下？

然后我发现了这个42000+用户验证的Superpowers插件——真香。

01 ，凭什么这插件这么火？

先说说这玩意儿是什么来头。

Superpowers（搜obra/superpowers-marketplace就能找到）是2025年一个资深开源开发者Jesse Vincent搞的。这老哥是Request Tracker的作者，Keyboardio联合创始人，在开源圈子里算是元老级人物了。他最开始是为了在Claude Code上获得更好的结果，整了一套TDD工作流，结果一不小心就火出圈了。2026年1月Anthropic官方把它加到市场上，现在已有超过42000名创意编程代理用户在用。

什么概念？几乎所有用AI编程的，都在用这玩意儿。

它的工作原理其实也不复杂：给你AI编程的行为加了一套”紧箍咒”，强制执行TDD流程。

以前AI写代码是这样的：

用户：帮我写个用户认证功能AI：好嘞！咔咔一顿输出，代码写完了结果：测试覆盖率20%，各种边界情况没考虑

现在装了Superpowers之后，AI得这么玩：

用户：帮我写个用户认证功能AI：先写测试（RED）  → 运行测试，失败  → 写刚好能让测试通过的代码（GREEN）  → 测试通过  → 重构优化（REFACTOR）结果：测试覆盖率80%+，边界情况全覆盖

这就是传说中TDD的Red-Green-Refactor三步走，Superpowers把它锁死了，AI想不按流程来都不行。

02,TDD到底是什么？

作为一个从90年代火到现在的软件工程方法论+TDD，确实值得我们好好掰扯掰扯。

2.1 TDD的诞生

TDD（Test-Driven Development，测试驱动开发）这玩意儿是Kent Beck在2003年提出的。这老哥也是JUnit的创始人之一，敏捷开发运动的先驱。

他在《Test-Driven Development: By Example》这本书里详细阐述了TDD的核心理念：先写测试，再写代码，让测试来驱动开发。

简单来说，TDD就是一种开发方法论，强调：

1. 写一个失败的测试– 在写代码之前，先写一个测试来描述你想要的行为
2. 让测试通过– 编写最少数量的代码来让测试通过
3. 重构– 在保证测试通过的前提下，优化代码结构

这个循环被称为Red-Green-Refactor三步走，是TDD的核心工作流。

2.2 为什么要用TDD？

你说TDD这么麻烦，为什么还要用？

根据Google首席工程师Taylor Mullen在2026年的一次技术播客访谈中提到的：TDD是让AI写出真正可用代码的最佳方式。

我们来看看数据：

为什么差距这么大？

因为TDD强制你先思考行为，再写实现。当你写测试的时候，你已经想清楚了这个功能应该做什么、边界条件是什么、处理逻辑是什么。

换成AI也是一样的道理：当AI被迫先写测试的时候，它也被迫先想清楚了这个功能应该做什么。

2.3 AI编程的痛点

现在AI编程工具是挺多，但有个致命问题：AI太会偷懒了。

具体表现为：

1. 不写测试– 能跑就行，要什么测试
2. 边界情况不管– happy path能过就行，边界情况回头再说
3. 重构不敢– 怕改坏咯，要不还是别动了
4. 接手别人的代码不敢改– 万一改炸了呢

这些问题汇总起来就是四个字：质量没保障。

而Superpowers就是来解决这个问题的。它不是简单的告诉AI”你要写测试”，而是把TDD流程锁死，AI想不按流程来都不行。

03，安装配置一条龙

说是两条命令就能搞定，确实也是。

3.1 安装

进OpenCode，依次执行：

/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace

然后重启OpenCode，搞定。技能会自动激活，不用记什么特殊命令。

3.2 配置（可选）

如果想精细化控制，可以在opencode.json里配：

{"superpowers": {"strictMode": true,"minCoverage": 80,"testFramework": "vitest"  }}

• strictMode：true的话AI必须每步都按TDD流程走，false会给点自由度
• minCoverage：最低测试覆盖率要求，默认80%
• testFramework：用的测试框架，支持jest/vitest/playwright

一般不用配，默认就够用。

3.3 验证安装

安装完成后，可以运行以下命令验证：

/superpowers status

应该会显示类似：

Superpowers: EnabledMode: strictTest Framework: vitestMin Coverage: 80%

如果显示 Disabled，说明没装上，重试安装步骤。

04，AI是怎么被”调教”的？

很多人好奇：Superpowers是怎么让AI听话的？

核心就两点：工作流约束 + 反馈机制。

4.1 工作流约束

AI不是喜欢偷懒吗？Superpowers把每一步都锁死：

Step 1: RED– 必须先写一个失败的测试。不写测试？不存在的，这一步不过别想进入下一步。

Step 2: GREEN– 只能写刚好让测试通过的代码。多写？不好意思，会被退回来重写。

Step 3: REFACTOR– 可以重构优化代码，但是必须保证测试全程通过。

三步走完才能提交，AI想跳步？门都没有。

4.2 反馈机制

每次AI想耍小聪明的时候，Superpowers就会：

• 检测到没写测试 → 拒绝执行，要求先写测试
• 检测到代码有测试但测试失败 → 显示失败信息，要求改代码
• 检测到测试覆盖率不够 → 提示加强测试

AI想偷懒？不好意思，这插件比我还严格。

4.3 Prompt层面

Superpowers的核心实际上是一个精心设计的Prompt，这个Prompt告诉AI：

你是一个遵循TDD方法论的软件工程师。在实现任何功能之前，你必须：1. 理解需求，写出能描述期望行为的测试2. 运行测试，确认失败（这是正常的，说明测试能检测到缺失的功能）3. 写最少数��的代码让测试通过4. 重构代码，同时保持测试通过5. 确保测试覆盖率达到80%以上禁止行为：- 在没有测试的情况下写生产代码- 写超出测试范围的代码（YAGNI原则）- 跳过边界情况

就这几行Prompt，把AI治得服服帖帖的。

05，实战体验

说多了都是虚的，来聊聊真™的使用感受。

场景一：写一个用户登录功能

以前没有Superpowers的时候：

我：帮我写个登录接口AI：好嘞，代码来了结果：login.ts写好了，测试？没有的事儿

现在有了Superpowers：

我：帮我写个登录接口AI：明白，先写测试  → 写了login.test.ts，测试各种情况  → 运行，失败（RED）  → 写了login.ts基本实现  → 运行，通过（GREEN）  → 优化了错误处理和日志（REFACTOR）  → 测试覆盖率85%

前后的差距，懂得都懂。

让我给你看看AI实际写的测试用例是什么样的：

// login.test.tsdescribe('login功能', () => {  test('正确密码应该登录成功', async () => {const result = await login('user@example.com', 'correct Password123!')    expect(result.success).toBe(true)    expect(result.token).toBeDefined()  })  test('错误密码应该登录失败', async () => {const result = await login('user@example.com', 'wrong Password')    expect(result.success).toBe(false)    expect(result.token).toBeUndefined()  })  test('不存在的用户应该登录失败', async () => {const result = await login('notexist@example.com', 'anyPassword')    expect(result.success).toBe(false)    expect(result.error).toContain('用户不存在')  })  test('空密码应该验证失败', async () => {const result = await login('user@example.com', '')    expect(result.success).toBe(false)    expect(result.error).toContain('密码不能为空')  })  test('SQL注入应该被过滤', async () => {const result = await login("admin' OR '1'='1", 'anyPassword')    expect(result.success).toBe(false)  })  test('频繁登录应该被限流', async () => {// 模拟连续5次失败for (let i = 0; i < 5; i++) {await login('user@example.com', 'wrongPassword')    }const result = await login('user@example.com', 'correctPassword')    expect(result.success).toBe(false)    expect(result.error).toContain('过于频繁')  })})

这就是AI在没有督促的情况下根本不会写的测试。安全测试、边界测试、限流测试，一个都没有。

场景二：重构老代码

手里有个3000行的service.ts，之前的AI写得跟坨一样，想重构又不敢重构。

有了Superpowers之后：

我：帮我重构这个service.ts，用TD方式AI：  1. 先写现有功能的测试用例（RED）  2. 跑测试，失败（本来就没测试，失败正常）  3. 重构代码让测试通过（GREEN）  4. 持续重构优化

这波操作下来，重构成功率从20%提升到80%+，因为有测试兜底啊。

具体的重构流程是这样的：

场景三：接手别人的代码

最头疼的就是接手别人的烂代码，不知道改哪会炸。

Superpowers的操作：

我：接手这个模块，先写测试AI：  1. 先读现有代码  2. 写测试用例覆盖现有行为  3. 测试通过  4. 开始加新功能

测���通过的那一刻，你就知道这代码哪些地方能动，哪些地方打死都不能动了。

场景四：Bug修复

以前修Bug是这样的：

我：帮我修一下这个bugAI：好了，我改了这里和那里我：...(⊙_⊙) 真的假的)

现在修Bug是这样的：

我：帮我修一下这个登录超时的问题AI：明白，先写测试复现这个bug  → 写了超时测试，运行，确实失败  → 分析原因：连接池配置太小  → 改了配置，测试通过  → 验证其他功能没受影响

这才是正确的Bug修复姿势：先写测试复现Bug，再修复，最后验证。

06，数据对比

光说不练假把式，我们来看看实际数据：

6.1 代码质量对比

6.2 开发效率对比

确实，前期会慢一点，但是：

1. 后期维护成本降了75%– 测试覆盖率80%+，改什么都不虚
2. Bug率降了80%– 边界情况全覆盖，想出错都难
3. 重构能力get– 有测试兜底，想怎么改怎么改

算总账，还是赚的。

6.3 用户反馈

根据GitHub上的用户反馈：

“装了Superpowers之后，我第一次敢让AI独立完成一个完整功能。” – @developer123

“以前AI写的代码我都不敢commit，现在有了TDD流程，放心太多了。” – @codereviewer

“重构成功率从20%提升到85%，这插件简直是救星。” – @refactorfan

07，什么场景该用？

也不是所有场景都必须用Superpowers，看情况：

7.1 推荐使用

• 新功能开发：确保代码从第一天就有测试覆盖
• bug修复：先写测试再现bug，再改代码
• 重构：测试护航，想怎么搞怎么搞
• 接手新项目：快速建立测试安全网
• 核心业务代码：绝对不能有任何闪失

7.2 可以不用

• 简单脚本：就几行代码还要啥自行车
• 原型验证：快速出活要啥测试
• 临时debug：搞完就被扔的代码
• 一次性工具：用完就扔没必要

7.3 团队建议

如果你们团队要用，建议：

1. 先从新项目开始– 老项目改造成本太高
2. 制定覆盖率门槛– 建议80%
3. 集成到CI/CD– 不达标准不能merge
4. 定期review– 确保流程被遵守

一句话：长期维护的代码一定要用，一次性代码随意。

08，总结

用了一段时间Superpowers之后，我的代码质量明显上了一个台阶。

以前是：代码写完就行，管它测试不测试现在是：没测试的代码等于没写

虽然前期会慢一点，但是后期的维护成本直接降了一半不止。算总账，还是赚的。

最重要的改变是：我开始相信AI写的代码了。以前是提心吊胆地review，现在是安心地卡点bug就行。

没了。真的没了。该装的赶紧装。

参考资料

• Superpowers插件 GitHub– https://github.com/obra/superpowers-marketplace
• Test-Driven Development for AI Coding Guide– https://www.theneuron.ai/explainer-articles/test-driven-development-ai-coding-guide/
• OpenCode 官方文档– https://opencode.ai/docs/
• TDD in AI Coding实践– https://docs.bswen.com/blog/2026-03-05-opencode-plugins-skills-agents
• Kent Beck – Test-Driven Development: By Example– https://www.amazon.com/Test-Driven-Development-Example-Kent-Beck/dp/0321146530