AI-Wiki

文档概览

原文围绕 Superpowers 展开，核心判断非常明确：它不是单纯给 Claude 增加“能力”，而是用一套文本化、可分发、可复用的工程规则，给 AI编程Agent工程纪律文本分发机制 提供落地形态。

文章反复强调，Claude Code 一类 AI 编程 Agent 常见问题并不是不会做事，而是“太勤快”：不先问清楚、不先验证、不先收尾，就直接开始实现。Superpowers 解决的不是智力不足，而是流程纪律不足。

原文给出的关键解释是：Superpowers 中每个 skill 本质上都是一个 Markdown 文件，里面写的是“遇到某类任务时必须遵守的流程”。它不是代码，也不是工具本身，而是纯文本行为约束。作者据此提出一个判断：AI 编程 Agent 缺的从来不是能力，而是纪律，而纪律可以通过文本规则进行分发。

文章还给出热度信息：该插件在 GitHub 上 6 个月增长到 185,000 stars，对应版本信息写为 v5.1.0，时间点为 2026 年 5 月。作者认为，大多数用户实际上只浅用过其中极少部分功能，典型场景只是调用一次 /brainstorming，回答几个问题后就直接让它写代码，相当于只用了整套体系中的一小部分。

关键事实

Superpowers 的总体定位

不是简单“增强能力”的插件，而是“给 Claude 增加工程纪律”的工作流体系。
skill 的载体是 Markdown 文件，不是代码逻辑本身。
每个 skill 的作用是在某类任务中强制执行流程，避免 AI 因赶时间、上下文漂移或用户催促而跳步。
原文的底层观点是：AI 编程 Agent 的核心短板不是智力，而是纪律；Superpowers 用纯文本把工程纪律外显化、流程化、标准化。

这与 AI编程Agent工程纪律文本分发机制 可直接关联，也与 Superpowers 本体条目相关。

文中列出的 14 个 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
systematic-debugging
writing-plans
subagent-driven-development / executing-plans
finishing-a-development-branch

重要细节

brainstorming：先设计、再批准、再实现

作者认为这是大多数人使用最多但也使用得最浅的 skill。常见误用是只做前面几个问题澄清动作，然后马上进入编码，导致设计没有落盘，执行阶段开始“记忆漂移”。

文章引用了 brainstorming 中最重要的硬约束，即 HARD-GATE：

在呈现设计方案并获得用户批准之前，不得调用任何实现型 skill。
在用户批准前，不得写代码。
在用户批准前，不得搭脚手架。
在用户批准前，不得采取任何实现动作。

原文特别强调，这不是建议，而是硬门。无论任务看起来多简单，没有通过这道门，就不允许进入实现阶段。

brainstorming 的 9 步完整流程

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

探索项目现状，包括查看文件、提交记录、已有文档。
如果问题涉及视觉层面，先提供可视化伴侣，并要求是独立消息。
逐条提出澄清问题，而且每次只问一个问题。
提出 2-3 个方案，并说明推荐其中某个方案的理由。
按章节展示设计方案，而且每一段都要确认。
将设计写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，并提交 commit。
对 spec 自检，扫描 TBD、TODO、内部矛盾、范围问题与歧义。
让用户审阅 spec 文件。
将流程移交给 AI编程任务细粒度计划拆解 对应的 writing-plans skill。

作者指出，最容易被跳过的是第 6 到第 8 步，也就是“设计写成文档、提交、再审阅”这一段。用户和 AI 往往在第 4、5 步觉得已经说清楚，于是直接开写，但这样会导致后续实现没有稳定依据，Agent 在中途很容易忘记之前商定的接口、边界和限制。

brainstorming 的终态限制

文章还给出一个很重要的边界条件：brainstorming 的合法终态只有一个，就是移交 writing-plans。原文明确说，不允许直接移交给其他实现型 skill，也不允许跳过计划阶段。这样设计的目的是强制把“设计 → 计划 → 实现”串成完整链路，而不是中途跳转。

简单项目也不能省流程

原文提到一个反直觉设计：如果项目简单到看上去“不需要设计”，反而更应该走完整流程。原因是小改动里的隐含假设最容易被忽略。即便只是一个配置改动，设计文档可以很短，只有几句话，但不能没有。

作者给出的时间对比案例

作者分享过一次重构实践：第一次完整走完 9 步 brainstorming，大约花了 40 分钟，主观感受是变慢了；但后续执行阶段几乎没有返工。相比之下，过去直接让 Claude 上手写，虽然表面上省了大约 30 分钟设计时间，最后却因为来回修改三轮，多花了 2 小时左右。

systematic-debugging：先查根因，再修复

作者认为这是整套 Superpowers 中价值被低估最严重的 skill。它主要约束 系统化调试流程，防止 AI 和人类一起陷入“猜测式修 bug”的模式。

原文给出的核心铁律是：先做根因调查，再谈修复。也就是“NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST”。

文章给出一组效率对比数据：在常规、非系统化的调试模式下，一个系统性问题平均可能耗时 2-3 小时；使用 systematic-debugging，常见可压缩到 15-30 分钟。作者解释，差距不来自模型突然更聪明，而是来自流程强制把“猜”改成“证据驱动”。

systematic-debugging 的四阶段流程

四个阶段必须顺序执行，前一阶段未完成，不能进入下一阶段。

Phase 1：根因调查

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

Phase 2：模式分析

在同一代码库中找到相似且正常工作的代码。
将正常代码与故障代码逐项对比。
所有差异都要列出来，哪怕看起来很小，也不能先假设“这个无关紧要”。
理解相关依赖和前置假设。

Phase 3：单假设验证

明确写出一个具体假设，例如“我认为 X 是根因，因为 Y”。
用最小变更去验证该假设。
如果验证失败，不允许叠加补丁，而是换一个新假设重新验证。

Phase 4：实现修复

先写能够复现问题的测试。
修复时只改一处。
如果三次修复都没有解决问题，必须停下来讨论这是否其实是架构层面的问题。

三次失败规则

文章特别强调第四阶段中的“三次失败规则”。这条规则不是说绝对不准继续改，而是要求：如果连续三次修复尝试都失败，不能顺手进入第四次、第五次“碰碰运气”的修改，而是必须退后一步，讨论问题是否源于架构设计、模式选型或边界划分本身。

原文在常见问题部分进一步说明，这条规则并非绝对禁止后续继续尝试；真正的约束是“三次失败后必须先讨论”，讨论之后如果确认并非架构问题，仍然可以继续新的方向，但不能跳过复盘直接猜第四次。

原文列出的常见借口与反驳

文章摘出了一份“借口对照表”，用来说明为什么很多人会本能跳过系统化调试流程：

借口：“这个 issue 很简单，不用走流程。”
真相：简单 bug 也有根因，流程对简单问题往往更快。
借口：“紧急情况，没时间调查。”
真相：系统性调试通常比猜测更快，“紧急”不是跳过根因分析的理由。
借口：“先试一下再说。”
真相：一旦第一步进入猜测模式，后面就会不断叠加猜测。
借口：“我已经大概知道问题在哪了。”
真相：知道症状不等于知道根因。

writing-plans：把 spec 拆到 2-5 分钟一级

brainstorming 结束后，流程会移交到 writing-plans。它的职责不是再做设计，而是把已经确认的 spec 拆成可以逐步执行的任务清单，对应 AI编程任务细粒度计划拆解。

原文强调一个非常具体的粒度约束：每个步骤都应该是 2-5 分钟级别。

文章举的例子里，一个小任务会被拆成类似以下步骤：