AI-Wiki

文档概览

原文的主论点非常明确：Superpowers 的价值不在“替 Claude 增加能力”，而在“替 Claude 增加纪律”。文章强调，Claude Code 缺的往往不是会不会写，而是会不会在被催促时仍然遵守工程流程，例如先做设计、先定位根因、先写测试、先确认计划、最后再收尾。

原文给出的机制也很具体：Superpowers 中的每一个 skill，本质上都是一个 Markdown 文件，写明“遇到某类任务时必须如何行动”。这不是工具层面的魔法，也不是新模型能力，而是通过文本约束来改变 Agent 行为。文章把这种方式概括为“工程纪律的文本分发”。

文中提到，Superpowers 在 GitHub 上六个月达到 185,000 stars，版本语境为 v5.1.0、时间点为 2026 年 5 月。作者认为，多数用户实际上只浅用了其中一小部分，常见模式只是调用 /brainstorming 问几个问题后就直接开写代码，相当于只用到了整套工作流的一小段。

关键事实

Superpowers 的核心定位：不是加能力，而是加纪律

原文反复强调，Superpowers 不是一个让 Claude 获得新编程能力的插件，而是一套把资深工程实践写成强约束流程的 skill 集合。其判断依据是：Claude 本来就“知道”应该做测试、做设计、做根因定位，但在“快点改”“先跑起来”的上下文里，会主动跳过这些步骤，转而直接实现或直接猜测修复。

因此，Superpowers 试图解决的是 AI 工程纪律问题：当用户催促、上下文很长、任务看似简单时，如何仍然强制 Agent 按流程办事。

Skill 是 Markdown 文件，不是代码能力扩展

原文明确说，每个 skill 本质上是 Markdown 文件，内容是行为规范和流程要求。也就是说，Superpowers 的“增强”不是增加底层推理 API，也不是新工具，而是把工作纪律以文本形式嵌入到 Agent 使用过程里。

这个设定的意义在于，纪律本身可以被版本化、分发、审查和团队化复用。文章据此提出一个核心结论：AI 编程时代真正稀缺的不是“多一个会写代码的模型”，而是“把不该跳过的步骤写死”。

插件内 skill 的分类

原文称，插件当时包含 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

虽然原文重点拆的是其中五个，但它把这些 skill 组织成一条完整链路，而不是孤立功能点。

重要细节

brainstorming：必须先设计并获得批准，否则禁止实现

原文把 brainstorming 描述为最常被使用、也最常被误用的 skill。常见误用是：问几个澄清问题、给出大致方案、然后直接开始写代码。但在原始规则里，这其实违反了最关键的硬门。

文章直接引用了它的硬约束：

<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>

这条规则的含义不是“建议先设计”，而是“在设计已经展示且用户已批准之前，不允许调用实现类 skill、不允许写代码、不允许搭脚手架，也不允许采取任何实现动作”。原文特别强调这是 HARD-GATE，不是软提示。

brainstorming 的完整流程是 9 步

原文给出了一套完整 9 步流程：

探索项目现状，包括查看文件、提交记录和文档。
如果任务涉及视觉问题，要先提供可视化伴侣，并且以独立消息给出。
逐条提澄清问题，每次只问一个。
提出 2-3 个可选方案，并说明推荐理由。
按章节展示设计方案，而且每一段都要确认。
把设计写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，然后提交。
对 spec 做自检，扫描 TBD、TODO、内部矛盾、范围问题和歧义。
让用户审阅 spec 文件。
移交给 writing-plans。

原文认为，用户最容易跳过的是第 6 到第 8 步，也就是“把设计落成文档、做自检、让用户审阅”。而这恰恰是后续实现质量的关键，因为如果设计没有成为已提交的 spec，执行阶段 Agent 的上下文记忆会漂移，做到一半就可能忘记之前约定的接口、边界和约束。

brainstorming 的终态被严格限定为 writing-plans

文章提到一个容易被忽视的约束：brainstorming 的唯一合法移交目标是 writing-plans。原文明确说，不允许从这里直接转去别的实现相关 skill，也不允许因为“看起来简单”就跳过计划阶段。

这背后的设计思想是把“设计→计划→实现”强制串成一条链，防止 Agent 直接跨级进入编码。

即使是简单改动，也必须走设计流程

原文还强调一个反直觉点：如果你觉得项目很简单、不需要设计，那反而更应该走流程。理由是，小改动里充满隐含假设，而隐含假设往往是返工来源。

这里不是要求所有项目写很长的设计文档，而是要求“不能省略设计动作”。对于简单改动，spec 可以很短，几句话也可以，但不能没有。

systematic-debugging：没有根因调查，不允许修复

原文把 systematic-debugging 视为最被低估的 skill，并给出一条近乎口号式的铁律：

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

它反对的是最常见的“贴报错→猜原因→改一下试试→再猜”的调试模式。原文认为，Claude 的默认倾向是猜，而这个 skill 的价值在于强制先找到 根因调试|根因，再谈修复。

systematic-debugging 的四个阶段必须顺序执行

原文给出的四阶段如下，而且明确要求按顺序执行，前一阶段没完成不能进入下一阶段。

Phase 1：根因调查

必须完整阅读错误信息，不是扫一眼。
必须稳定复现问题。
必须检查最近的 git 变更。
如果是多组件系统，要在每个边界打诊断日志，先跑一遍收集证据，再分析断点在哪。

这意味着第一阶段的目标不是立刻修，而是建立事实基础和证据链。

Phase 2：模式分析

在同一个代码库中寻找类似且正常工作的实现。
把正常实现与异常实现逐项对比。
每个差异都要列出来，哪怕看上去很小，也不能先入为主地认为“不相关”。
理解依赖关系和隐含前置条件。

这里体现的其实是一种“同类对照法”，而不是孤立地盯着报错点硬改。

Phase 3：单假设验证

写下一个具体假设，格式是“我认为 X 是根因，因为 Y”。
只做最小变更来验证这个假设。
如果假设不成立，就换一个新假设，但不能把多个改动叠加在一起试。

原文特别反对“顺手一起改几个点看看”，因为那会破坏因果判断，导致之后根本分不清哪个改动产生了效果。

Phase 4：实现修复

先写一个能复现问题的测试。
只改一处。
如果连续三次修复都没有解决问题，就必须停下来，回到更高层讨论是否存在架构问题。

三次失败规则：第三次之后必须停，不允许惯性进入第四次猜修

原文认为，systematic-debugging 最实用的设计之一，就是第三次修复失败后必须暂停。它不是说“永远不能继续”，而是说在第三次失败后，不允许直接凭惯性去试第四次、第五次；必须先讨论当前模式是不是错的，问题是不是已经上升到架构层。

文章后面的问答也补充了边界：这个规则不是绝对禁止继续修改，而是要求“先讨论再继续”。如果讨论后确认问题仍然局限于当前层面，可以继续尝试新的方向，但必须中断此前那种连续猜测式修复。

原文给出的效率判断：2-3 小时 vs 15-30 分钟

文章给出一个非常具体的对比数据：传统猜测式调试平均耗时 2-3 小时，而使用 systematic-debugging 后，问题解决时间可压到 15-30 分钟。这个数字在文中作为方法论收益的直接证据出现，核心解释是“系统化比猜更快”，尤其在紧急场景下更如此。

常见借口与反驳

原文列了一张“借口—真相”对照表，针对四类常见逃避流程的说法：

“这个 issue 很简单，不用走流程” → 简单 bug 也有根因，流程对简单问题反而更快。
“紧急情况，没时间调查” → 系统性调试比猜测更快，紧急不是跳过调查的理由。
“先试一下再说” → 第一次试错就会把调试带入猜测模式，后面更难拉回来。
“我已经大概知道问题在哪了” → 知道症状不等于知道根因。

这部分非常贴近根因调试的实践心法：症状定位不等于因果定位。