185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能 - 今日头条.md16.9 KBit/ai/185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能 - 今日头条.md
--- title: "185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能 - 今日头条" source_url: "https://www.toutiao.com/article/7650439258843185673/?log_from=03447f942625c8_1782227431740&wid=1782230814164" source_site: "www.toutiao.com" clipped_at: "2026-06-23T16:07:10.697141+00:00" clipper: "aiwiki-url-ingest" extractor: "toutiao_rendered" --- # 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 分类树状图 # 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 里有一份"常见借口对照表"，码哥觉得写得非常准： | **借口** | **真相** | | --- | --- | | "这个 issue 很简单，不用走流程" | 简单的 bug 也有根因，流程对简单问题反而更快 | | "紧急情况，没时间调查" | 系统性调试比猜测快多了，"紧急"不是理由 | | "先试一下再说" | 第一次就确立猜测模式，后面就一直猜 | | "我已经大概知道问题在哪了" | 知道症状不等于知道根因 | 在 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 的工作方式：** - 在当前会话里串行执行所有任务 - 上下文累积，会话越来越长 - 批量执行，定期设置检查点让你介入 **怎么选的规则很简单：** | **情况** | **选哪个** | | --- | --- | | Claude Code / Codex 等支持 subagent 的平台 | subagent\-driven\-development | | Cursor、不支持 subagent 的环境 | executing\-plans | | 任务数量多、上下文容易漂移 | subagent\-driven\-development | | 简单小任务、不想多绕一圈 | 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 对比图 # 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 完整功能开发工作流 # 两个经常踩的坑 # 坑一：上下文漂移 长时间会话里，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 编程工具最大的问题不是智力，是纪律**，而纪律可以用纯文本分发。