185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能

你有没有用 Claude Code 的时候遇到这种情况——

让它帮你加一个功能，三百行代码噼里啪啦就下来了，跑起来一看，逻辑对了七八成，但剩下那两成全是它自己发明的需求。

你说这是测试的 bug，它说好，又改了一通，结果把能跑的地方也顺手改坏了。

这不是 Claude Code 不够聪明。是它太"勤快"了——不问、不验、不收，直接上手干。

Superpowers 解决的就是这个问题。 不是给 Claude 加能力，而是给 Claude 加纪律。

这个插件在 GitHub 上六个月跑到 185,000 stars（v5.1.0，2026 年 5 月），但码哥观察了一下，大多数人装完之后用法是这样的：开一个新功能，喊一句 /brainstorming，然后一路回答问题，最后让它写代码。仅此而已。

相当于买了套瑞士军刀，每次只用开瓶器。

这篇文章从 Superpowers 的 SKILL.md 源文件出发，拆解那些大多数人没认真看过的核心 skill，把完整工作流跑通。

Superpowers 是什么：不是插件，是工程纪律的文本分发

先说一个可能颠覆你认知的事情：Superpowers 里的每一个 skill 本质上是一个 Markdown 文件，里面写的是"当你遇到这类任务时，你必须按这个流程走"。

不是代码，不是工具调用，就是纯文本的行为约束。

这背后有一个很深刻的观察：AI 编程 Agent 缺的从来不是能力，而是纪律。

Claude 知道该写测试，但在"快速给我跑一遍看看"的语境下，它会跳过；Claude 知道 debug 要找根因，但你说"快帮我改一下"，它就直接猜着改了。

Superpowers 做的事情就是——用文本"强制执行"这些工程师该有的纪律，让 Claude 不管你怎么催，都不会绕过应走的流程。

插件目前包含 14 个 skill，分三类：

测试类： test-driven-development

调试类： systematic-debugging、verification-before-completion

协作/工作流类： brainstorming、writing-plans、executing-plans、subagent-driven-development、dispatching-parallel-agents、requesting-code-review、receiving-code-review、using-git-worktrees、finishing-a-development-branch、writing-skills、using-superpowers

下面拆解最核心的五个。

Superpowers 14 个 Skill 分类树状图

Superpowers 14 个 Skill 分类树状图

brainstorming：有一道硬门，过不去就不许写代码

这是大多数人用得最多、也用得最浅的 skill。

多数人的用法是：喊 /brainstorming，回答几个问题，然后……让它直接开写。相当于只走了 brainstorming 的前三步，最关键的后六步全跳过了。

打开 brainstorming 的 SKILL.md，第一个硬约束是这样写的（原文引用）：

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, 
or take any implementation action until you have presented a design 
and the user has approved it.
</HARD-GATE>

注意这是 <HARD-GATE>，不是 "建议"，是"不管你觉得多简单，过不了这道门，一行代码都不许写"。

完整的 brainstorming 流程是 9 步：

1. 探索项目现状（看文件、commits、文档）
2. 如果有视觉问题，先提供可视化伴侣（独立消息）
3. 逐条问澄清问题（每次只问一个）
4. 提出 2-3 个方案并给出推荐理由
5. 按章节展示设计方案，每段都要确认
6. 把设计写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并 commit
7. 自检 spec：扫描 TBD/TODO、内部矛盾、范围、歧义
8. 让用户审阅 spec 文件
9. 移交 writing-plans skill

最容易跳过的是步骤 6-8。

大多数人跑到步骤 4-5 就觉得"差不多了，直接写吧"，结果设计没有落到文档里，后面执行阶段 Claude 的"记忆"就开始漂移，做到一半忘了之前说好的接口怎么定义。

还有一个细节：brainstorming 明确规定，它的终态只有一个——移交 writing-plans。不许调用 frontend-design，不许调用 mcp-builder，只能移交 writing-plans。这强制让你走完整个设计→计划→实现链条，而不是跳着来。

码哥用这个 skill 做过一次重构任务，第一次走完整 9 步花了 40 分钟，感觉很慢。但后面执行阶段几乎没有返工。对比之前直接让 Claude 上手写，"设计"环节省了 30 分钟，但后来改了三轮，总时间反而多了两小时。

有一个反直觉的设计： brainstorming 里说，"如果你觉得这个项目太简单、不需要设计，那更要走流程。简单项目里的隐含假设，是浪费工作的最大来源。"

就连一个配置改动，也必须走完整流程，设计可以短（几句话），但不能省。

systematic-debugging：四阶段，禁止没有根因就动手

这是码哥认为 Superpowers 里价值最被低估的 skill。

普通的调试姿势是：报错了 → 把错误贴给 Claude → 它说"可能是 X，试试改这里" → 你试了 → 没好 → 再贴 → 它说"那可能是 Y" → 反复横跳。

这种模式下，按照 Superpowers 里的数据：系统调试平均耗时 2-3 小时；用 systematic-debugging，15-30 分钟。

差距这么大的原因是：Claude 的默认模式是猜，systematic-debugging 强制它必须找到根因才能提修复。

铁律（原文）：

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

四个阶段（必须按顺序，前一阶段没完成不许进下一阶段）：

Phase 1：根因调查

• 完整读错误信息（不是"看一眼"，是"读完整"）
• 稳定复现步骤
• 检查最近的 git 变更
• 对多组件系统，在每个边界打诊断日志，先跑一次收集证据，再分析哪里断了

Phase 2：模式分析

• 找到同一个 codebase 里类似的、能跑通的代码
• 和坏的代码逐项对比差异（"每一个差异，不管多小，都列出来，不要假设那个没关系"）
• 理解依赖和假设条件

Phase 3：单假设验证

• 写下一个具体的假设（"我认为 X 是根因，因为 Y"）
• 做最小变更验证
• 不对的话：换新假设，不要叠加改动

Phase 4：实现修复

• 先写能复现问题的测试
• 只改一处
• 如果三次修复都没解决问题：停下来，讨论是不是架构层面的问题

这里有一个最实用的设计：Phase 4 有个"三次失败规则"。

如果试了 3 次修复都没有解决，systematic-debugging 要求你停下来，不再尝试第四次，而是退后一步讨论"是不是这个模式本身就有问题"。

这和大多数工程师的直觉是相反的——大多数人在第三次失败之后会更焦虑地试第四次、第五次。但每次额外的猜测修复，都在给代码引入新的不确定性，而且还在浪费时间。

Superpowers 里有一份"常见借口对照表"，码哥觉得写得非常准：

在 systematic-debugging 的基础上，还加了一张「调试决策流程图」来帮读者更直观理解四阶段：

systematic-debugging 四阶段调试流程图

systematic-debugging 四阶段调试流程图

writing-plans：每个步骤 2-5 分钟，不许有 TBD

brainstorming 结束后，会移交给 writing-plans。这个 skill 的核心职责是：把 spec 拆成可以被 AI 或人类一步步执行的任务清单。

关键设计决定：每个步骤的粒度是 2-5 分钟。

具体什么意思？一个任务里的步骤是这样的：

- [ ] Step 1: 写一个失败的测试
- [ ] Step 2: 跑一下，确认它确实失败了
- [ ] Step 3: 写最小实现让测试通过
- [ ] Step 4: 跑测试，确认通过
- [ ] Step 5: Commit

注意，"写一个失败的测试"和"跑一下确认它失败"是两个独立步骤，不是一步。这种粒度设计的目的是：让 subagent 或者你自己在执行时，每一步都有明确的完成判定标准，不会"做了一半，不知道算不算完成"。

writing-plans 还有一个"零占位符"规则：

以下写法会被认为是计划失败，必须修正：

• "TBD"、"TODO"、"后续实现"
• "添加适当的错误处理"（不写具体怎么处理）
• "写上述内容的测试"（不给测试代码）
• "类似 Task N"（重复内容，不允许引用）

这个规则是为了解决一个真实问题：当 Claude 在后续执行计划时，如果遇到 TBD，它要么停下来问，要么自己发挥——两个都是噩梦。

计划写完之后，writing-plans 会给你两个执行选项：

选项 1：subagent-driven-development（推荐） —— 每个任务派一个新的 subagent，带两轮审查

选项 2：executing-plans —— 在当前会话里串行执行，适合没有 subagent 支持的环境

subagent-driven-development vs executing-plans：怎么选

这是很多人困惑的地方，选错了效率差一大截。

subagent-driven-development 的工作方式：

• 每个任务 spawn 一个全新的 subagent
• 新 subagent 拿到计划文件和当前任务，干净的上下文开始工作
• 两轮审查：先看 spec 合规性，再看代码质量
• 完成后回报，主 agent 决定是否继续下一个任务

executing-plans 的工作方式：

• 在当前会话里串行执行所有任务
• 上下文累积，会话越来越长
• 批量执行，定期设置检查点让你介入

怎么选的规则很简单：

Superpowers 的文档里直接说："如果你的环境支持 subagent，就用 subagent-driven-development，代码质量会显著更高。"原因是干净的上下文让 Claude 不会被之前的错误尝试带偏。

实际感受：码哥有一次做一个有 8 个任务的功能，用 executing-plans 跑，跑到第五个任务时 Claude 开始"综合"前面几个任务的修改，把一个已经通过的测试改坏了。换 subagent-driven-development，每个 subagent 只看自己的任务，这种"上下文串扰"就基本消失了。

代价是：subagent-driven-development 每个任务都要重新加载 plan 文件，调用开销略高。但按 token 效率算，避免一次返工节省的成本远大于这个开销。

subagent-driven-development vs executing-plans 对比图

subagent-driven-development vs executing-plans 对比图

finishing-a-development-branch：干净收尾，不留烂摊子

这是工作流的终点，也是最容易被跳过的 skill。

很多人跑完任务直接 commit 推上去，或者干脆让 Claude 帮你 merge，没有走这个 skill。结果是：test 没跑、worktree 没清、分支没处理，留一堆烂摊子。

finishing-a-development-branch 的流程是：

Step 1：验证测试通过（如果测试失败，直接停，不进入后续步骤）

Step 2：确定 base branch

Step 3：给出四个选项：

1. 本地 merge 回 <base-branch>
2. Push 并创建 Pull Request
3. 保留分支（我晚点处理）
4. 丢弃这次工作

Step 4：按选择执行

Step 5：清理 worktree（选 1 和 4 才清理，选 2 和 3 保留）

这个 skill 有一个设计细节：丢弃选项（Option 4）需要你手动输入 "discard" 才能执行，不是随便点一下就行。防止误操作删掉本该保留的工作。

完整工作流一张图

把上面说的串起来，一次完整的功能开发是这样的：

brainstorming          ← 设计阶段，产出 spec 文档
    ↓
using-git-worktrees    ← 创建隔离工作区
    ↓
writing-plans          ← 把 spec 拆成 2-5 分钟的可执行任务
    ↓
subagent-driven-development 或 executing-plans   ← 并行或串行实现
    ↓
test-driven-development（贯穿实现阶段）          ← RED-GREEN-REFACTOR
    ↓
requesting-code-review  ← 提审前的自检
    ↓
finishing-a-development-branch  ← 选择 merge/PR/保留/丢弃，清理 worktree

如果中途遇到 bug，插入 systematic-debugging；如果验证有疑问，插入 verification-before-completion。

整套流程第一次跑会觉得"好麻烦啊"。码哥的亲身感受：前两次确实比直接让 Claude 写慢，但从第三次开始，因为 spec 和 plan 写得完整，执行阶段的返工率断崖式下降，总时间反而更短。

Superpowers 完整功能开发工作流

Superpowers 完整功能开发工作流

两个经常踩的坑

坑一：上下文漂移

长时间会话里，Claude 会逐渐"忘记"自己有 skill 可以用，开始按默认模式行事：跳过测试、直接猜 bug、不问设计就写代码。

解法：遇到这种情况，显式喊一下 /using-superpowers，会帮 Claude "重置"，重新建立 skill 优先级。

坑二：把 brainstorming 当问答机用

brainstorming skill 问问题是为了做设计，不是"帮你想清楚功能"。很多人把它当成一个"AI 产品经理"来用——我说一个模糊的需求，你帮我想清楚。

这没问题，但如果停在这一步，没有走到 spec 文档和 writing-plans，后面执行阶段 Claude 拿不到一个明确的设计依据，质量会大打折扣。

brainstorming 的价值在于产出一个 committed spec，这才是后续所有质量的基础。

常见问题

Q：Superpowers 适合小项目吗？感觉流程太重了。

A：brainstorming 的 spec 可以很短，一个改动只需要几句话的设计文档。流程轻重是相对的，问题不是"项目大不大"，而是"你能不能接受返工"。码哥见过很多"5 分钟小改动"，因为没有设计直接上手，结果改了三轮花了两小时。

Q：subagent-driven-development 和 executing-plans 可以混用吗？

A：可以，同一个 plan 里，你可以某些任务用 subagent，某些任务自己手动执行。这在部分任务需要你实际操作（比如手动配置环境变量）时很有用。

Q：systematic-debugging 的"三次失败规则"是绝对的吗？

A：不是"不许再改了"，而是"在第三次失败后，必须停下来讨论是不是架构问题，而不是继续猜"。如果讨论后确认不是架构问题，而是需要再试一个方向，当然可以继续——但要在讨论之后，不是直接冲第四次。

Q：整套 Superpowers 流程跑一遍要多久？

A：取决于项目复杂度。一个中等复杂的功能（4-6 个任务），brainstorming 30-40 分钟，writing-plans 15-20 分钟，execution 时间因任务而异。第一次跑会觉得慢，但执行阶段的返工省下的时间通常能覆盖前期投入。

Q：Superpowers 的 skill 能自定义吗？

A：可以，writing-skills skill 就是教 Claude 怎么创建新 skill 的。你可以为自己的团队定制 skill，比如加入公司的代码审查规范、部署流程约束等。Superpowers 的 ~/.config/superpowers/skills/ 目录支持个人 skill 库。

参考资料

• Superpowers GitHub 仓库
• Superpowers Anthropic 插件页
• Marc Nuri 的 Superpowers 深度解析
• Jesse Vincent 的实战记录（2025 年 10 月）

说到底，Superpowers 这套工作流解决的不是"Claude 能不能做"的问题——Claude 大部分情况下都能做——解决的是"Claude 会不会偷懒跳步骤"的问题。

185,000 stars 背后的共识就是：AI 编程工具最大的问题不是智力，是纪律，而纪律可以用纯文本分发。