Superpowers插件185000星却仅10%功能被多数人使用

你有没有遇到过这种情况？让Claude帮你写个功能，几百行代码瞬间生成，跑起来一看，逻辑大体没错，但总有两三成是它自己“脑补”出来的需求。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

你说测试没通过，它立刻动手改，结果把原本能跑的部分也改坏了。

这其实不是Claude不够聪明，恰恰相反，是它太“勤快”了——不问清楚、不验证、不收敛，直接上手就干。Superpowers这个插件，解决的正是这个问题。它并非给Claude增添新能力，而是给它加上工程师应有的“纪律”。

这个插件在GitHub上六个月就收获了超过18.5万颗星，但观察下来，很多人的用法仅限于：开启一个新功能，输入/brainstorming，回答几个问题，然后就让Claude开始写代码。这就好比买了一套瑞士军刀，却只用上面的开瓶器。

这篇文章将从Superpowers的SKILL.md源文件出发，拆解那些常被忽略的核心技能，帮你跑通完整的工作流。

Superpowers是什么：工程纪律的文本化分发

首先，一个可能碘伏认知的事实是：Superpowers里的每一个skill，本质上都是一个Markdown文件，里面写的是“当你遇到这类任务时，必须按这个流程走”。

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

这背后有一个深刻的洞察：AI编程助手缺的从来不是能力，而是纪律。Claude知道该写测试，但在“快帮我跑一遍看看”的催促下，它会跳过；Claude知道调试要找根因，但你说“快帮我改一下”，它就直接猜测着改了。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

下面我们来拆解其中最核心的五个。

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

这是使用最广泛，但也用得最浅的技能。多数人的流程止步于输入/brainstorming，回答几个问题，然后就直接让Claude开写。这相当于只走了brainstorming的前三步，最关键的后六步全被跳过了。

打开brainstorming的SKILL.md，第一个硬约束是这样写的：

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you ha ve presented a design and the user has approved it.

注意这是，不是“建议”，而是“不管你觉得多简单，过不了这道门，一行代码都不许写”。

完整的brainstorming流程是9步：

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

最容易跳过的是步骤6-8。很多人走到步骤4-5就觉得“差不多了，直接写吧”，结果设计没有落到文档里，后续执行阶段Claude的“记忆”就开始漂移，做到一半忘了之前说好的接口定义。

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

实际体验中，第一次走完整9步可能会感觉有点慢，比如一次重构任务花了40分钟在设计上。但对比之前直接让Claude上手写，虽然“设计”环节省了30分钟，但后来改了三轮，总时间反而多了两小时。

一个反直觉的设计是：brainstorming里强调，“如果你觉得这个项目太简单、不需要设计，那更要走流程。简单项目里的隐含假设，才是浪费工作的最大来源。”所以，即使是一个配置改动，也必须走完整流程，设计可以简短，但不能省略。

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

这可能是Superpowers里价值最被低估的技能。

普通的调试姿势是：报错了 → 把错误贴给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还提供了一张调试决策流程图：

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

brainstorming结束后，会移交给writing-plans。这个技能的核心职责是：把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的工作方式：

• 每个任务生成一个全新的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效率算，避免一次返工节省的成本远大于这个开销。

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

这是工作流的终点，也是最容易被跳过的技能。很多人跑完任务直接提交推送，或者干脆让Claude帮你合并，没有走这个流程。结果是：测试没跑、工作区没清理、分支没处理，留下一堆烂摊子。

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

1. Step 1：验证测试通过（如果测试失败，直接停止，不进入后续步骤）
2. Step 2：确定基础分支
3. Step 3：给出四个选项：

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

4. Step 4：按选择执行
5. Step 5：清理worktree（选项1和4才清理，选项2和3保留）

这个技能有一个设计细节：丢弃选项（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写得完整，执行阶段的返工率断崖式下降，总时间反而更短。

两个经常踩的坑

坑一：上下文漂移

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

解法：遇到这种情况，显式地输入/using-superpowers，这会帮助Claude“重置”，重新建立skill的优先级。

坑二：把brainstorming当问答机用

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

这本身没问题，但如果停在这一步，没有走到spec文档和writing-plans，后续执行阶段Claude拿不到一个明确的设计依据，质量会大打折扣。brainstorming的核心价值在于产出一个已提交的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这个技能就是教Claude怎么创建新skill的。你可以为自己的团队定制skill，比如加入公司的代码审查规范、部署流程约束等。Superpowers的~/.config/superpowers/skills/目录支持个人skill库。

参考资料

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

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