25万 Star 的 Superpowers，为什么要求 AI 写代码前先写测试？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

AI Coding 越来越强之后，一个有意思的现象出现了。

Claude Code、Codex、Cursor 生成代码越来越快，Agent 一次可以修改几十个文件，甚至自己完成需求分析、编码、Debug 和 Code Review。

但 GitHub 上一个已经超过 26.5 万 Star 的 AI Coding 项目，却在反复强调一件看起来很“传统”的事情：

测试。

这个项目叫 Superpowers。

截至目前，obra/superpowers GitHub 仓库已经达到约 26.58 万 Star。它不是一个新的大模型，而是一套面向 Claude Code、Codex、Cursor 等 Coding Agent 的 Agent Skills + 软件开发方法论。

更有意思的是：

Superpowers 明确要求 AI 在实现功能或者修 Bug 时采用 TDD（Test-Driven Development，测试驱动开发）。

它的规则甚至写得非常强硬：

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
也就是：

没有一个先失败的测试，就不要开始写生产代码。

这就很值得测试开发工程师琢磨了。

现在 AI 写代码已经这么快了。

为什么一个专门增强 AI Coding 能力的项目，反而要不断给 Agent 增加测试、验证、Debug、Code Review 这些“限制”？

答案可能恰好说明了 AI Coding 下一阶段真正的瓶颈：

代码越来越容易生成以后，真正昂贵的开始变成——怎么证明这些代码是对的。

目录
一、Superpowers 到底是什么，为什么这么火
二、AI Coding 越快，为什么反而越需要测试
三、Superpowers 是怎么强迫 Agent 做 TDD 的
四、真正关键的不是 Test First，而是验证闭环
五、为什么这套东西值得测试开发工程师研究
六、Superpowers 也不是标准答案，TDD 不能机械套用
七、AI Coding 继续发展，测试可能反而更重要
一、Superpowers 到底是什么，为什么这么火？
先回答一个很多人搜索 Superpowers 时都会问的问题。

Superpowers 是什么？
从工程角度看：

Superpowers 是一套面向 Coding Agent 的软件开发方法论，它通过可组合的 Agent Skills，把需求澄清、方案设计、任务拆解、TDD、Debug、Code Review 和最终验证等工程实践，固化成 Agent 必须遵循的工作流程。

官方 README 对自己的定义也非常直接：

一套构建在可组合 Skills 之上的完整 Coding Agent 软件开发方法论。

它目前已经面向很多主流 Coding Agent：

Claude Code。

Codex。

Cursor。

GitHub Copilot CLI。

OpenCode。

Kimi Code。

以及其他 Agent 开发工具。

但真正让 Superpowers 有意思的，不是“又多了一堆 Skill”。

而是：

它不给 Agent 鼓励，而是给 Agent 纪律。

普通 AI Coding 的路径很容易变成：

图片
Superpowers 把它改造成了：

图片
官方现在的核心 Skill 就包括：

brainstorming

writing-plans

test-driven-development

systematic-debugging

requesting-code-review

verification-before-completion

subagent-driven-development

等等。

你会发现一个很明显的倾向：

Superpowers 并没有研究：

怎么让 AI 一次写更多代码？

它研究的是：

怎么阻止 AI 在没有想清楚、没有测试、没有证据的情况下继续往前跑。

这其实才是它值得测试开发研究的地方。

二、AI Coding 越快，为什么反而越需要测试？
过去软件开发最昂贵的环节之一是什么？

写代码。

一个工程师一天能稳定完成的修改量有限。

所以代码天然存在一个“生产速度上限”。

但 Coding Agent 出现以后，这个上限正在迅速提高。

以前：

1个工程师
↓
几个小时
↓
修改3～5个文件
现在：

1个Agent
↓
几十分钟
↓
修改几十个文件
代码生产速度突然变快。

但另外一边：

人的 Review 能力并没有同步提升几十倍。

于是整个软件研发链路开始出现一个新的瓶颈：

代码生成能力
↑↑↑↑↑

验证能力
↑
以前我们担心：

开发来不及写。

未来越来越可能担心：

AI 写得太快了，我们根本来不及确认它到底写对没有。

这也是为什么测试在 AI Coding 时代反而会变得更重要。

AI 写完代码再补测试，最大的问题是什么？
很多人现在使用 Coding Agent 的方式是：

先实现功能
↓
再生成测试
↓
运行
↓
通过
看起来没问题。

实际上这里存在一个很经典的风险：

测试可能开始迎合实现。

例如真实需求是：

用户连续登录失败 5 次以后，账号锁定 30 分钟。

AI 不小心实现成：

if failed_count >= 3:
lock_user()
然后你再告诉它：

帮这段代码补单元测试。
AI 已经看到了：

failed_count >= 3
于是很容易生成：

def test_user_locked_after_3_failures():
...
最后出现：

错误实现
+
匹配错误实现的测试

全部 PASS
代码通过了。

测试也通过了。

但是：

业务错了。

这就是 Test After 的一个典型问题。

TDD 对 AI Coding 真正有什么价值？
Superpowers 的解释其实很清楚。

测试先写和测试后写，回答的是两个不同的问题：

Tests After：

这段代码现在是怎么工作的？
而：

Tests First：

这段代码应该怎么工作？
Superpowers 官方 TDD Skill 明确指出：如果测试是在实现代码之后写的，它可能只是验证当前实现，而不是验证真正需要的行为；如果没有亲眼看到测试先失败，也无法确认这个测试真的能够捕获缺失的功能。

所以对于 Agent 来说：

Test First 最大的价值并不是提高测试覆盖率。

而是提前建立一个机器可以验证的：

行为约束。

正确路径变成：

测试在这里承担的角色已经发生变化。

它不只是 QA。

也是：

Specification。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

图片
三、Superpowers 是怎么强迫 Agent 做 TDD 的？
Superpowers 的 test-driven-development Skill 基本没有给 AI 留多少讨价还价空间。

它要求新功能、Bug 修复、重构和行为变化原则上都使用 TDD；官方列出的例外包括一次性 Prototype、生成代码和配置文件等，并要求涉及例外时与人确认。

核心流程就是经典的：

RED
↓
GREEN
↓
REFACTOR
但是放进 Agent 以后，它又多了一层工程约束。

RED 不只是“测试红了”
Agent 先写测试。

然后必须：

真的运行它。

并确认：

测试失败了
还不够。

必须确认：

它是因为预期功能不存在而失败
而不是：

ImportError

语法错误

变量拼写错误

测试环境坏了

Mock 配错了
所以真正流程应该是：

这个细节特别重要。

因为：

测试失败，本身不是证据；按预期原因失败，才是证据。

GREEN 也不是“把测试搞绿”
进入 GREEN 以后，Superpowers 要求的是：

写最少的实现，让测试通过。

不是顺便：

重构半个项目。

增加十几个未来可能用到的接口。

引入一个新框架。

把整个模块“顺手优化”。

这是 TDD 里的一个经典原则：

只实现当前测试要求的行为
背后其实在压制 Coding Agent 的另一个典型问题：

过度实现。

AI 特别容易“顺便帮你”。

但真实软件工程里：

多写的代码

多出的复杂度
+
新的维护成本
+
新的潜在 Bug
所以 Superpowers 同时强调了：

TDD。

YAGNI。

降低复杂度。

四、真正关键的不是 Test First，而是验证闭环
如果 Superpowers 只是强制 TDD，我不会觉得它有 26 万 Star 这么值得研究。

真正让我觉得它很符合测试思维的是另外一个 Skill：

verification-before-completion
它的核心规则是：

NO COMPLETION CLAIMS
WITHOUT FRESH VERIFICATION EVIDENCE
也就是：

没有最新的验证证据，不允许宣布完成。

这个规则特别适合 Coding Agent。

因为只要用 Claude Code、Codex 比较多，大概率都见过类似的话：

问题已经修复。
现在应该可以正常运行了。
修改已经完成。
测试工程师看到“应该”两个字，通常就已经开始警觉了。

Superpowers 怎么判断“真的完成”？
它设计了一个很简单的 Gate：

1. 找到能够证明结论的命令

2. 真正执行完整命令

3. 阅读完整输出

4. 检查 Exit Code 和失败数量

5. 结果真的支持结论

6. 才允许宣布完成

也就是：

图片

这里面有一句非常重要的工程思想：

Evidence before claims。

先有证据。

再有结论。

为什么这比“多写几个测试”更重要？
因为未来 Agent 最大的问题之一可能不是：

不会测试。

而是：

过早认为自己已经测试好了。

比如：

Lint 通过
≠
编译通过
编译通过
≠
单元测试通过
单元测试通过
≠
集成测试通过
测试通过
≠
需求正确
AI 很容易在某一层得到正反馈以后，直接把结论扩大。

而测试开发做的事情，本质上就是不断问：

你的证据到底能证明多大的结论？

所以我认为 Superpowers 真正值得测试工程师关注的，不只是 TDD。

而是：

它开始把“质量门禁”直接写进 Agent 的行为规则。

五、Superpowers 连 Debug 都要求先找根因
它的另一个核心 Skill 是：

systematic-debugging
这个 Skill 解决的其实也是 AI Coding 一个很典型的问题：

AI 太爱猜。

很多 Agent 遇到 Bug 以后会变成：

看到报错
↓
猜原因A
↓
改
↓
不行
↓
猜原因B
↓
再改
↓
还是不行
↓
继续试
Superpowers 不允许这么做。

它要求：

没有完成 Root Cause Investigation，就不要开始修。

官方把 Debug 分成了四个阶段：

Phase 1
Root Cause Investigation

↓

Phase 2
Pattern Analysis

↓

Phase 3
Hypothesis and Testing

↓

Phase 4
Implementation
在复杂系统里，它甚至要求先在组件边界增加观察能力：

输入是什么？

输出是什么？

环境变量是否正确传递？

状态在哪一层发生变化？

真正在哪一个组件开始失败？
然后再针对具体组件继续排查。

熟悉不熟悉？

这其实就是成熟测试开发、SRE 或后端工程师排障时常用的方法。

真正有意思的是：

Superpowers 把这些东西写成了：

Agent Skill。

六、为什么这套东西特别值得测试开发工程师研究？
我认为这里真正出现了一个非常值得测试行业关注的变化。

过去测试经验主要存在于：

人的脑子

测试规范

Wiki

SOP

Checklist
例如一个高级测试工程师看到支付接口，会天然想到：

幂等

重复请求

超时

重试

状态一致性

资金一致性

并发

补偿
但是这些东西往往只能靠人。

Skill 出现以后，情况开始变化。

这些工程方法有可能进一步变成：

可执行规则
例如接口变更，可以做成一个测试 Skill
目标：

分析本次 API 修改可能带来的回归风险。

必须检查：

Request兼容性
Response兼容性
字段新增/删除
默认值
权限
幂等
超时
重试
历史调用方
错误码
数据一致性
以后 Coding Agent 修改接口时，就可以自动触发：

API Compatibility Skill
先做一次风险分析。

测试工程师的经验就从：

我知道怎么测
变成：

Agent也知道遇到这种问题应该怎么测
这个变化非常重要。

未来高级测试工程师的一部分价值，可能会从“亲自执行测试”，转向“把测试方法设计成 Agent 可以稳定执行的质量能力”。

七、Agent 自主性越高，越需要测试 Agent 本身
这里还有一个更大的问题。

传统软件虽然也很复杂，但同样输入下，大多数程序执行路径相对确定。

Agent 不一样。

它会动态：

理解任务。

制定计划。

调用 Skill。

调用工具。

修改计划。

使用 Subagent。

选择代码路径。

所以：

Agent自主性 ↑
通常也意味着：

潜在行为路径 ↑
未来测试开发要测的，可能就不仅是：

AI生成的代码有没有Bug？
还要继续问：

Agent什么时候调用TDD Skill？

它会不会绕过Skill？

失败以后会不会擅自修改测试？

会不会为了让测试通过而降低断言？

它只跑部分测试会不会宣布成功？

Context变化以后行为会不会漂移？
这就已经从：

Software Testing

进一步进入：

Agent Testing / Agent Eval。

连 Skill 本身都需要测试
这件事非常有意思。

如果 Skill 是：

教Agent怎么工作
那下一个问题自然就是：

怎么证明这个 Skill 真的把 Agent 教对了？

否则非常容易出现：

写了一份SKILL.md

↓

跑一个例子效果不错

↓

感觉这个Skill很好
这和：

我手工点了一次

↓

功能正常

↓

系统没有Bug
有什么本质区别？

没有。

真正工程化以后应该是：

没有Skill时
Agent表现怎样？

↓

加入Skill

↓

Agent表现有没有提升？

↓

换20个场景

↓

还能不能稳定生效？

↓

模型升级以后有没有回归？
这就是：

Skill Eval。

所以 Agent 越发展，我反而越觉得测试背景的人在这里很有优势。

因为测试工程师最熟悉的一件事情就是：

不要因为一次成功，就宣布系统稳定。

八、Superpowers 也不是标准答案，TDD 不能机械套用
看到这里容易出现一个误区：

Superpowers 26 万 Star，所以以后所有 AI Coding 都必须严格 TDD。

没必要走到这个极端。

Superpowers 自己也明确列出了部分例外，比如一次性 Prototype、生成代码和配置文件等场景，需要与人讨论是否采用严格 TDD。

现实项目也会遇到很多复杂情况：

Legacy Code。

没有测试基础的老系统。

快速验证 Prototype。

一次性迁移脚本。

数据修复任务。

探索性开发。

这些场景机械执行：

任何代码
必须严格RED-GREEN-REFACTOR
未必是成本收益最优解。

真正值得借鉴的，其实不是：

必须 TDD。

而是 Superpowers 背后的约束逻辑：

而不是：

AI生成代码
↓
看起来不错
↓
Merge
AI Coding 时代真正不能丢掉的，不一定是某一种固定测试方法，而是“没有验证证据，就不能相信生成结果”的工程原则。

这一点比 TDD 本身更加重要。

九、AI Coding 越强，测试会不会反而更重要？
这是我觉得 Superpowers 走红以后，测试工程师最值得思考的问题。

很多测试从业者现在最大的焦虑是：

AI都会写代码了。

AI也会写测试了。

以后测试工程师还有价值吗？
但换一个角度看：

Agent 能修改的代码越来越多。

自主运行时间越来越长。

能调用的工具越来越多。

能够完成的任务越来越复杂。

那么随之增加的其实还有：

错误代码。

错误决策。

错误工具调用。

错误假设。

回归风险。

不可预测行为。

以前软件测试解决的是：

人写的代码到底对不对？

未来还会多一个问题：

Agent 做出的决策到底能不能相信？

这恰好就是 Superpowers 一直在解决的事情。

它给 Coding Agent 加：

TDD。

Systematic Debugging。

Code Review。

Verification。

Evidence。

不是因为 Agent 不会写代码。

恰恰相反。

正是因为 Agent 太会写代码了。

代码生产速度越快：

质量验证能力就必须同步升级。

否则最后得到的不是开发效率。

而是：

更高速度地产生技术债和 Bug。

测试开发真正值得关注的，可能不是“AI 会不会替代测试”
Superpowers 目前的 GitHub Star 已经超过 26.5 万，它的核心理念里明确包含：

Test-Driven Development

Systematic over ad-hoc

Complexity reduction

Evidence over claims

这几个词放在一起，其实已经说明了它真正想解决的问题。

AI Coding 的下一阶段，很可能不再只是：

更强的模型
+
更大的Context
+
更多工具
还必须补上：

测试约束
+
工程规范
+
验证机制
+
Eval
+
质量门禁
对于测试开发工程师来说，这可能反而是一个值得提前研究的方向。

因为未来最稀缺的能力，未必是：

谁最会让 AI 写代码。

而可能是：

谁知道应该怎样约束 AI、验证 AI，并建立一套证据证明它真的做对了。

Superpowers 给出的答案其实非常朴素：

不要因为Agent说完成了，就相信它。

先跑测试。

拿出证据。

再说完成。
而这恰恰就是软件测试几十年来一直在做的事情。

如果未来你们团队 70% 的代码真的开始由 Coding Agent 完成：

你觉得测试工程师最应该测试的，是 AI 生成出来的代码，还是这个 Agent 本身？

推荐学习
智能化测试-测试用例生成公益训练营，从行业大模型特性讲起，带你搞懂AI测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。