185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能
原文链接185000 星的 Superpowers 插件，90% 的人只用了它 10% 的功能
原文链接：https://mp.weixin.qq.com/s/qKyqvKkz1-KKwKEXbZFWlA
作者：码哥（码哥跳动）｜发布时间：2026-05-12
摘要
Superpowers 是一个 GitHub 185k star 的 Claude Code 插件，核心不是给 AI 加能力，而是加纪律。本质是 14 个纯 Markdown 文件组成的文本约束系统，强制 AI 走完设计→计划→实现→审查→收尾的完整工程流程。文章拆解了最核心的 5 个 skill：brainstorming（9 步硬门）、systematic-debugging（四阶段 + 三次失败规则）、writing-plans（2-5 分钟粒度 + 零占位符）、subagent-driven-development vs executing-plans、finishing-a-development-branch。
核心观点
AI 编程 Agent 缺的不是能力，而是纪律。 Claude 知道该写测试但会被"快速跑一遍"的语境带偏，知道 debug 要找根因但你说"快改"它就猜着改。Superpowers 用纯文本强制执行这些纪律。
五大核心 Skill 拆解
1. brainstorming（9 步硬门）
被滥用最多： 大多数人只走前三步（探索项目、可视化、问问题），跳过了最关键的后六步。
硬门约束（原文）：
<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>
完整 9 步流程： 探索现状 → 可视化 → 逐条澄清 → 提出方案 → 分段确认设计 → 写入 spec 文档并 commit → 自检 spec → 审阅 spec → 移交 writing-plans
最容易被跳过： 步骤 6-8（把设计落到文档 + 自检 + 审阅）
终态只有一个：移交 writing-plans，不允许跳步骤直接写代码。作者实测：第一次走完 9 步花 40 分钟感觉慢，但执行阶段几乎零返工。对比直接上手，"设计"环节省 30 分钟但后续改三轮多花两小时。
2. systematic-debugging（四阶段 + 三次失败规则）
铁律： NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
效果对比： 默认模式平均 2-3 小时；systematic-debugging 15-30 分钟。
四阶段（前一阶段没完成不许进下一阶段）：
- Phase 1：根因调查 — 完整读错误、稳定复现、检查最近 git 变更、多组件系统在每个边界打诊断日志
- Phase 2：模式分析 — 找同 codebase 里类似的能跑通的代码，与坏代码逐项对比每一个差异
- Phase 3：单假设验证 — 一次只验证一个具体假设，不对就换新假设，不叠加改动
- Phase 4：实现修复 — 先写复现测试，只改一处
三次失败规则： 试了 3 次修复都没解决，必须停下来讨论是不是架构问题，不再继续猜第四次。
常见借口对照表：
| 借口 | 真相 |
|---|---|
| "这个 issue 很简单，不用走流程" | 简单 bug 也有根因，流程对简单问题反而更快 |
| "紧急情况，没时间调查" | 系统性调试比猜测快多了 |
| "先试一下再说" | 第一次就确立猜测模式，后面就一直猜 |
| "我已经大概知道问题在哪了" | 知道症状 ≠ 知道根因 |
3. writing-plans（2-5 分钟粒度 + 零占位符）
核心职责： 把 spec 拆成可被 AI 或人类一步步执行的任务清单。
关键设计： 每个步骤 2-5 分钟粒度。
- [ ] Step 1: 写一个失败的测试
- [ ] Step 2: 跑一下，确认它确实失败了
- [ ] Step 3: 写最小实现让测试通过
- [ ] Step 4: 跑测试，确认通过
- [ ] Step 5: Commit
"写测试"和"确认失败"是独立步骤，每一步都有明确完成判定。
零占位符规则： TBD、TODO、"后续实现"、"添加适当的错误处理"、"写上述内容的测试"、类 Task N 引用 → 全部视为计划失败。
两个执行选项： subagent-driven-development（推荐）vs executing-plans
4. subagent-driven-development vs executing-plans
| 维度 | subagent-driven-development | executing-plans |
|---|---|---|
| 上下文 | 每个任务全新 subagent，干净上下文 | 会话累积，越来越长 |
| 审查 | 两轮（spec 合规 + 代码质量） | 无内置审查 |
| 适用 | 支持 subagent 的平台（Claude Code/Codex） | 不支持 subagent 的环境（Cursor） |
| 质量 | 代码质量显著更高，无上下文串扰 | 后期任务可能被前面错误带偏 |
作者实测：8 个任务的功能用 executing-plans 跑到第 5 个时 AI 开始"综合"前面修改，把已通过的测试改坏。换 subagent-driven-development 串扰基本消失。
5. finishing-a-development-branch（干净收尾）
五个步骤： 验证测试通过 → 确定 base branch → 四个选项（本地 merge / Push+PR / 保留分支 / 丢弃）→ 按选择执行 → 清理 worktree
安全设计： 丢弃选项需手动输入 "discard" 才执行，防止误操作。
完整工作流
brainstorming → using-git-worktrees → writing-plans
→ subagent-driven-development / executing-plans
→ test-driven-development（贯穿）→ requesting-code-review
→ finishing-a-development-branch
中途 bug → 插入 systematic-debugging；疑问 → 插入 verification-before-completion。
两个常见坑
- 上下文漂移： 长会话中 AI 逐渐忘记 skill，按默认模式行事。解法：显式喊
/using-superpowers重置 - 把 brainstorming 当问答机： brainstorming 是为了产出 committed spec，不是模糊需求的 AI 产品经理。停在问答阶段，后面执行质量大打折扣
FAQ
- 适合小项目吗？ — spec 可以很短，问题不是项目大小，而是能不能接受返工
- 两个执行模式能混用吗？ — 可以，需要手动操作的步骤自己执行
- 三次失败规则绝对吗？ — 不是不许再改，而是必须先讨论是不是架构问题
- 整套流程要多久？ — 中等功能 brainstorming 30-40min + planning 15-20min + execution，前期投入从返工省回
关键数据
- GitHub：185,000 stars（2026 年 5 月，v5.1.0）
- 14 个 skill，分三类：测试类、调试类、协作/工作流类
- 本质：14 个 Markdown 文件的纯文本行为约束