为什么拆 Superpowers

在 Skill 生态里，obra/superpowers 是最值得研究的案例——它的 Skill 仓库获得了 20 万+ GitHub Stars，定义了「如何用 Skills 让 AI Agent 高效工作」的标准范式。它不是一个工具，而是一套方法论体系。

作为 AI PM，我花了几天时间把 Superpowers 的 13 个 Skill 全部装上一一体验。这篇文章不是技术拆解，而是从产品设计角度，分析这套框架背后的工作流设计哲学，以及它对 AI PM 的启示。

Superpowers 的核心架构：不是 13 个工具，是一条流水线

Superpowers 最巧妙的设计在于：13 个 Skill 不是平铺的，而是按照软件开发的生命周期排列成一条端到端的流水线。

构思 → 规划 → 分解 → 执行 → 测试 → 审查 → 部署
  │       │      │      │      │      │      │
  ▼       ▼      ▼      ▼      ▼      ▼      ▼
brain- execu- sub-   tdd   verifi- code- deploy
storm  tion-  agent-       cation- revie- check-
       plan   driven              wer    list

这条流水线的设计有三个关键原则：

原则一：每个阶段有且只有一个主要 Skill

不是越多越好。Superpowers 刻意避免 Skill 的冗余。Brainstorm 只管构思，Execution-plan 只管规划，TDD 只管开发。职责清晰，用户在对应阶段自然知道该调用哪个。

这和微服务架构的设计哲学一致——一个服务只做一件事，做到极致。

原则二：前一个 Skill 的输出是下一个 Skill 的输入

Brainstorm 产生的约束条件和替代方案，会被 Execution-plan 用来分解任务。Execution-plan 产生的步骤列表，会被 Subagent-driven-dev 用来分配子代理。Subagent 产生的代码，会被 TDD 的测试覆盖，再被 Code-reviewer 审查。

这不是 13 个独立的功能调用。这是一条信息流。

原则三：每个 Skill 不仅定义了「做什么」，更定义了「不做什么」

这是 Superpowers 最值得学习的地方。每个 Skill 都有明确的边界声明——Verification-before-completion 会告诉你它检查什么、不检查什么。Code-reviewer 会声明它的审查维度和审查盲区。

这种设计哲学的根源是：对 AI Agent 来说，「知道何时停下来」比「知道做什么」更难。

三个让我印象最深的设计细节

细节一：Brainstorm 的「反直觉」设计

Brainstorm 这个 Skill 最反直觉的一点是：它不允许 Agent 在构思阶段就跳到实现方案。

它的指令是：「先穷举所有约束条件，再列出所有可能的替代方案，再评估每个方案的 trade-off，最后才是推荐方案。」

这强制了一个「先发散再收敛」的思维过程。我们人类做产品设计时也会这样——但 AI 天然倾向于「找到第一个可行方案就开始做」。Brainstorm 对抗的是 AI 的这个惯性。

PM 启示：设计 AI 工作流时，不要假设 AI 会用最优路径思考。要像设计 SOP 一样，显式地规定思考步骤。

细节二：Verification-before-completion 的「多层校验」

这个 Skill 的指令非常具体：「在声称任务完成前，你必须执行以下检查——代码是否通过了全部测试？所有验收标准是否满足？是否有未处理的 TODO？是否有遗留的调试代码？」

它不是在代码写完后才检查，而是嵌入在 Agent 的工作流末尾作为一个强制环节。Agent 不能跳过它。

这是从「人检查 AI 的输出」到「AI 自己检查自己的输出」的转变。本质上是把 QA 流程自动化了。

PM 启示：AI 产品的质量保证不能完全依赖用户反馈。在设计阶段就应该内置「自检」环节。

细节三：Code-reviewer 的「多 Agent 协同审查」

Code-reviewer 不是让一个 Agent 审查代码然后给意见。它的流程是：

  • Agent A 生成代码并做初步自审查
  • Agent B（独立的子代理）基于事实准确性、工程模式、安全审计、一致性四个维度做独立审查
  • Agent A 和 B 的审查结果交叉比对
  • 有分歧的地方标注为需要人工决策

这个「交叉审查」的设计借鉴了学术界的同行评审机制。一个人的审查有盲区，两个人的交叉审查能发现更多问题。

PM 启示：单个 AI 的输出有「视角盲区」。在关键决策环节引入「多视角交叉验证」，是提升输出质量的有效手段。

从 Superpowers 提炼的 AI PM 工作流设计框架

逆向分析完 Superpowers，我提炼出一个 AI 产品工作流设计的通用框架——「五步法」：

第一步：定义阶段，而非功能。 先拆解用户任务的完整生命周期，然后为每个阶段设计一个「控制点」。

第二步：设计「强制暂停」。 在每个阶段的衔接处，插入一个 QA 环节——不是用户手动触发，而是系统自动执行。

第三步：建立「上下文传递」机制。 确保上一个 Skill 的关键输出不会在下一个 Skill 中被丢失。

第四步：声明「盲区」。 每个 Skill 不仅要写清楚做什么，更要写清楚不做什么。让用户知道 AI 的能力边界。

第五步：设计「人工决策点」。 不是所有环节都让 AI 自主决策。关键的判断节点（架构选择、安全决策、用户体验判断）保留给人类。

不仅仅是开发者的工具

Superpowers 表面上是一套开发工作流工具。但它的设计哲学对任何 AI 产品都有参考价值。

无论是让 AI 写营销文案、分析用户数据、还是管理项目进度，我们都需要回答这几个问题：

  • 用户任务的生命周期分几个阶段？
  • 每个阶段 AI 应该自主到什么程度？
  • 阶段之间如何衔接和校验？
  • 哪些决策必须保留给人类？

Superpowers 用 13 个 Skill 回答了这些问题——不是用理论，而是用可执行的、Agent 能理解和遵循的指令。

这就是 AI PM 应该追求的产出质量：不是「我们打算怎么做」，而是「Agent 已经可以这样做了」。

行动建议：选一个你产品中用户体验最差的环节——比如「用户不知道怎么开始」「输出质量不稳定」「经常需要手动修正」。然后试着用 Superpowers 的设计思路，为这个环节设计一个 Skill 级别的解决方案。重点是：不要写功能需求，要写 AI 可以执行的步骤指令。