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下面拆解最核心的五个。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 步探索项目现状看文件、commits、文档如果有视觉问题先提供可视化伴侣独立消息逐条问澄清问题每次只问一个提出 2-3 个方案并给出推荐理由按章节展示设计方案每段都要确认把设计写入docs/superpowers/specs/YYYY-MM-DD-topic-design.md并 commit自检 spec扫描 TBD/TODO、内部矛盾、范围、歧义让用户审阅 spec 文件移交 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-debugging15-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 里有一份常见借口对照表码哥觉得写得非常准借口真相这个 issue 很简单不用走流程简单的 bug 也有根因流程对简单问题反而更快紧急情况没时间调查系统性调试比猜测快多了紧急不是理由先试一下再说第一次就确立猜测模式后面就一直猜我已经大概知道问题在哪了知道症状不等于知道根因在 systematic-debugging 的基础上还加了一张「调试决策流程图」来帮读者更直观理解四阶段writing-plans每个步骤 2-5 分钟不许有 TBDbrainstorming 结束后会移交给 writing-plans。这个 skill 的核心职责是把 spec 拆成可以被 AI 或人类一步步执行的任务清单。