夜雨聆风
Superpowers 源码拆解:Claude Code 最火插件的 14 个 Skill 工作机制
一个结论先说清楚：Superpowers 不是一个”帮你写代码”的插件。它是一套强制执行工程纪律的工作流——先想清楚再动手（brainstorming）、先写测试再写代码（TDD）、先找根因再修 bug（systematic-debugging）。它的价值不在于让 Claude “更聪明”，而在于让 Claude “更守规矩”。
网上关于 Superpowers 的介绍文章不少，但多数停留在功能列表和使用感受。本文从 SKILL.md 源码层面拆解它的四个核心 Skill，看看每个 Skill 内部的硬门禁（Hard Gate）、工作流程和设计哲学。
核心要点
-
Superpowers 包含 14 个 Skill，每个是一份 Markdown 指令文件，通过 Claude Code 的 Skill 加载机制注入到会话中 -
核心设计哲学：TDD（先测试后代码）、YAGNI（不写用不到的代码）、DRY（不重复） -
brainstorming 有硬门禁——不出设计方案不允许写代码，即使是”简单”项目 -
systematic-debugging 的铁律：没有根因分析就不允许修 bug -
安装方式是 superpowers-marketplace，不是某些文章说的claude-plugins-official
Superpowers 的本质：Markdown 指令集
Claude Code 的 Skill 系统本质很简单——每个 Skill 是一个 .md 文件，放在 ~/.claude/plugins/superpowers/skills/ 目录下。当你触发一个 Skill 时，Claude Code 把这个 .md 文件的内容注入到当前会话的系统提示中，Claude 就按照文件里的指令行事。
输出：
14 个目录，每个里面有一个 SKILL.md。这些 .md 文件就是 Superpowers 的全部源码——没有 Python，没有 TypeScript，没有可执行文件。纯文本指令。
纠正一个常见误解
网上有文章说 Superpowers 有一个叫 root-cause-tracing 的独立 Skill。这是不准确的——根因追踪是 systematic-debugging Skill 内部的一个阶段，不是独立 Skill。14 个 Skill 的完整列表就是上面这些。
核心 Skill 拆解一：brainstorming
打开 brainstorming/SKILL.md，第一眼看到的是这段：
这是一个硬门禁（Hard Gate）。意思是：在 brainstorming 阶段，Claude 被明确禁止写任何代码、创建任何文件、调用任何实现类工具。不管你怎么催，不管任务看起来多简单，它都不会动手——直到你确认了设计方案。
为什么要这么极端？因为 Superpowers 的作者观察到一个反模式：
我在实际使用中确认了这个判断。有一次我让 Claude 加一个”简单的”日志功能，跳过了 brainstorming 直接写代码——结果它默认用了 console.log，但项目用的是 pino。重写花的时间比先花两分钟讨论一下还多。
brainstorming 的工作流程分四步：
- 理解项目上下文
：读取 CLAUDE.md、目录结构、关键配置文件 - 逐个提问
：不是一次抛出所有问题，而是一个接一个，每个问题基于上一个答案 - 输出设计方案
：包含技术选型、数据流、文件结构、边界条件 - 等待用户确认
：用户说 OK 才能进入下一阶段
关键词是”逐个提问”。很多 AI 助手一上来就问你 10 个问题，用户被问懵了，随便回答，质量反而更差。brainstorming 的设计是渐进式的——它先问最关键的问题，根据你的回答决定下一个问题是什么。
核心 Skill 拆解二：test-driven-development
TDD Skill 的开头一句话定义了它的灵魂：
紧接着是一句看起来像废话但极其重要的话：
为什么先看测试失败很重要？因为如果你写了一个测试，它直接通过了——说明这个测试要么在测一个已经存在的功能（白写了），要么测的条件永远为真（假测试）。只有先看到红色（失败），再看到绿色（通过），你才能确认：测试在测你想测的东西，而且代码确实修复了问题。
TDD Skill 强制执行三阶段循环：
RED — 写一个测试，运行它，确认它失败。如果测试直接通过了，说明测试写错了或功能已存在，不允许进入下一步。
GREEN — 写最少的代码让测试通过。注意是”最少”——不是写一个完美的实现，而是写刚好够让测试通过的代码。YAGNI 原则在这里体现得最明显。
REFACTOR — 测试全部通过后，才允许重构代码。重构期间测试必须始终保持绿色。
我在实际项目中用了三个月 TDD Skill，最大的体会是：它改变了我写代码的节奏。以前是”想一大堆 → 写一大堆 → 跑一下看看”，现在是”写一个测试 → 写几行代码 → 绿了 → 下一个测试”。每个循环不超过 5 分钟，心智负担明显降低。
TDD Skill 还有一个隐藏规则——如果 Claude 写的代码导致已有测试失败，它会被要求先恢复测试通过，再继续新功能开发。不允许”先把所有功能写完再修测试”。
核心 Skill 拆解三：systematic-debugging
这个 Skill 有一条铁律，用代码块格式强调：
翻译过来：没有根因分析，禁止修 bug。
这条规则针对的是 AI 编码工具最常见的问题——Claude 看到一个报错，立刻”修”了它。表面上 bug 消失了，但根因没找到，过两天同样的问题换个形式又出现了。或者更糟——Claude 的”修复”引入了新 bug。
systematic-debugging 定义了四个阶段：
阶段一：现象收集 — 不写任何代码。只做三件事：看日志、复现问题、记录环境信息。Claude 被要求在这个阶段只使用 Read 和 Bash（只读命令），不允许使用 Edit 或 Write。
阶段二：假设生成 — 基于收集到的现象，列出所有可能的根因，按可能性排序。每个假设必须附带验证方法——怎么证明或证伪这个假设。
阶段三：假设验证 — 逐个验证假设。可以加调试日志，但不能修改业务逻辑。如果第一个假设被证伪了，转向第二个，而不是”试试改一下看看”。
阶段四：定向修复 — 根因确认后，才开始写修复代码。修复必须附带回归测试，证明 bug 确实被修了。
我见过太多次这样的场景：开发者看到 TypeError: Cannot read properties of undefined，直接加了一个 ?. 可选链。bug 消失了，但 undefined 的根源——一个竞态条件——没人处理。systematic-debugging 的价值就在于逼你回答那个问题：为什么这个值是 undefined？
核心 Skill 拆解四：requesting-code-review
Code Review 在 Superpowers 中被拆成了两个 Skill——requesting-code-review（提交审查）和 receiving-code-review（接收反馈）。拆成两个的原因是：提交审查和接收反馈是两种完全不同的思维模式。
requesting-code-review 的核心机制：
它要求 Claude 在声称工作完成之前，必须拿出证据——跑过的测试输出、构建日志、实际运行截图。不允许”我写完了”这种空口声明。
receiving-code-review 更有意思——它教 Claude 怎么正确地接收代码审查反馈：
这三条规则解决一个微妙的问题：当 reviewer 给了反馈，AI 的默认行为是全盘接受并立刻执行。但好的工程师不会这样——他会先评估反馈是否正确，再决定是否采纳。receiving-code-review 要求 Claude 对每条反馈做技术评估，如果反馈本身有问题（比如 reviewer 误解了代码意图），Claude 应该指出而不是盲从。
14 个 Skill 的完整速查
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
安装和配置
纠正一个广泛流传的错误信息：Superpowers 的安装不是 /plugin install superpowers@claude-plugins-official。正确的来源是 superpowers-marketplace。
实际安装后，它的文件结构是：
在 ~/.claude/settings.json 中，Superpowers 注册了一个 SessionStart 同步 hook，确保每次会话开始时 Skills 都被正确加载：
async: false 意味着这个 hook 是同步执行的——Claude Code 会等它执行完才开始会话。这保证了 Skills 一定在你开始对话之前就绑定好了。
什么时候不该用 Superpowers
Superpowers 的设计哲学是”强制工程纪律”。这在正式项目中是优点，但在某些场景下会成为累赘：
快速原型验证——你只是想试试一个想法可不可行，不需要测试、不需要设计文档。brainstorming 的硬门禁会强制你走完设计流程，这时候反而拖慢速度。
一次性脚本——写个数据迁移脚本、写个日志分析脚本，用完就扔。TDD 的 Red-Green-Refactor 循环对一次性代码没有回报。
学习探索——你在学一个新框架，到处试、到处改。systematic-debugging 的四阶段流程会打断你的探索节奏。
我的做法是：正式项目全程加载 Superpowers，原型验证和学习探索时不加载。Claude Code 的 Skill 是按需加载的，不用就不加载，不会有性能开销。
与其他插件的关系
Superpowers 可以和其他插件共存。在我的配置中，Superpowers 和以下插件同时运行：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Skill 冲突的情况很少见，因为 Superpowers 的 Skills 设计为按需加载——你不会同时触发 brainstorming 和 systematic-debugging。如果确实遇到冲突（两个 Skill 对同一个行为给出矛盾指令），优先级取决于加载顺序，后加载的覆盖先加载的。
三个值得关注的方向：Superpowers 的 writing-skills Skill 允许你用 Superpowers 的设计模式编写自己的 Skill——这意味着你可以把团队的编码规范打包成 Skill，让 Claude 按规范执行。dispatching-parallel-agents 和 Claude Code 的 Agent Teams 功能结合后，可以实现真正的多 Agent 并行开发。作者 @obra 在 GitHub Issues 中保持活跃，社区反馈的 bug 通常在一两周内修复。
相关的文章