如果你已经开始把 Claude Code、Codex App 或 Codex CLI 用在真实开发里，你大概率会很快遇到一个问题：

模型本身已经很强了，但真正影响交付质量的，往往不是 “它会不会写代码”，而是 “它会不会按正确流程做事”。

比如很多时候，AI 的问题并不是能力不够，而是节奏不对：

  • 还没搞清需求就开始改代码
  • 方案没定就直接实现
  • 写完没验证就说完成
  • 改动没有拆任务，越写越乱
  • 该并行时没有并行，该 review 时没有 review

Superpowers 想解决的，就是这个层面的问题。

它不是一个 “帮你多装几个命令” 的插件，也不只是几个 prompt 模板，而是一套围绕 coding agent 设计的开发方法论 + skills 工作流。

按照它的设计，AI 不应该一上来就写代码，而应该先：

  • 理清需求
  • 形成方案
  • 拆出实现计划
  • 按任务推进开发
  • 中间穿插测试和审查
  • 最后再收尾和合并

这篇文章就专门把 Superpowers 的使用方式讲清楚，尤其是下面几个问题：

  • 它到底是什么，适合谁用
  • 在 Claude Code、Codex App、Codex CLI 里怎么安装
  • 它的核心 workflow 是怎么跑起来的
  • 常用 skills 到底该怎么理解
  • 实际开发时，怎么把它用得顺手，而不是装完就闲置

本文中的安装方式、技能列表和官方描述，已基于 2026 年 6 月 9 日 的 obra/superpowers 官方仓库信息整理。

一、Superpowers 到底是什么

官方对它的描述很直接：

Superpowers is a complete software development methodology for your coding agents.

翻成更好懂的话就是：

Superpowers 不是单点增强，而是想把你的 coding agent 变成一个会按工程流程推进任务的开发代理。

它的核心不在 “再给模型塞一些提示词”，而在下面三件事：

  • 给 agent 一套明确的开发顺序
  • 把高频工程动作拆成可复用的 skill
  • 让这些 skill 在合适时机自动触发

也就是说，你装上它以后，目标并不是让 AI “回答更花”，而是让 AI 在面对开发任务时更像一个靠谱的工程执行者。

它和普通 prompt 有什么区别

普通 prompt 的思路通常是：

  • 你先想好要怎么要求 AI
  • 再靠一大段规则约束它
  • 然后希望它每次都稳定照做

Superpowers 的思路则更接近：

  • 把需求分析做成 skill
  • 把计划编写做成 skill
  • 把 TDD 做成 skill
  • 把代码审查做成 skill
  • 把分支收尾做成 skill

这样做的好处是，流程被模块化了。

你不需要每次都重新手搓一套长 prompt，只需要让 agent 进入正确 workflow，它就会在该分析时分析、该拆计划时拆计划、该 review 时 review。

二、它适合什么人

如果你只是偶尔让 AI 写一小段脚本，Superpowers 可能会显得有点重。

但如果你已经进入下面这些场景，它会很有价值：

  • 你希望 AI 能连续做 30 分钟到 2 小时以上的开发任务
  • 你希望 AI 在动手前先把方案和边界理清
  • 你希望 AI 改代码时别东一榔头西一棒子
  • 你希望把 review、测试、收尾都纳入流程
  • 你已经开始用多 agent、subagent 或 worktree 协作

一句话总结：

只把 AI 当 “补全工具” 的人，不一定急着上 Superpowers；把 AI 当 “交付伙伴” 的人，会更能体会它的价值。

三、Superpowers 是怎么工作的

先看它最核心的工作流

  • 用户提出开发任务
  • brainstorming：先澄清需求和设计
  • using-git-worktrees：创建隔离工作区
  • writing-plans：拆出明确任务
  • subagent-driven-development /executing-plans：按计划执行开发
  • test-driven-development：先红后绿做测试驱动开发
  • requesting-code-review：做代码审查
  • finishing-a-development-branch：收尾、合并、提 PR

这个流程的价值在于：

  • 它默认你应该先想清楚，再动手
  • 它默认复杂任务应该先拆计划，再执行
  • 它默认实现过程中应该伴随测试和 review
  • 它默认开发结束后还需要一个明确的收尾动作

所以你会发现，Superpowers 并不是在强调 “某一个 skill 多厉害”，而是在强调：

让 agent 走对顺序，比让 agent 多会一点技巧更重要。

四、怎么安装

Superpowers 支持多个 harness。这里重点写和你最相关的三类：Claude Code、Codex CLI、Codex App。

1. Claude Code 安装

官方 README 里给了两种方式。

方式一：官方 Marketplace

plaintext

1
/plugin install superpowers@claude-plugins-official

方式二：Superpowers Marketplace

plaintext

1
2
3
4
# 先注册 marketplace
/plugin marketplace add obra/superpowers-marketplace
# 再安装
/plugin install superpowers@superpowers-marketplace

2. Codex CLI 安装

终端执行打开插件面板：

plaintext

1
/plugins

搜索：superpowers

选择 Install Plugin 完成安装。

3. Codex App 安装

  • 在 Codex App 侧边栏打开 Plugins
  • 在 Coding 分类里找到 Superpowers
  • 点击 +，按提示完成安装即可。

4. 安装后怎么确认生效

装完以后，你通常不需要每次都显式输入 “请使用某某 skill”。

Superpowers 的设计重点就是：

  • 在你开始做开发任务时自动检查相关 skill
  • 在合适阶段切换到对应 workflow
  • 把 “流程约束” 前置到 agent 的默认行为里

也就是说，它更像 “给 agent 装了新的工作习惯”，而不是 “塞了一堆要手动点的按钮”。

五、最重要的 skill：using-superpowers

如果你刚装好 Superpowers，最值得先理解的 skill 不是最复杂的那个，而是：

using-superpowers

它相当于整个系统的入口说明书。

你可以把它理解成两层作用：

  • 告诉 agent：当前应该按 Superpowers 的方法做事
  • 告诉用户：这套方法有哪些关键环节

很多人装完插件后，第一反应是马上试着让 AI 写代码。但更好的方式其实是先跑一个很小的真实任务，观察它有没有出现下面这些变化：

  • 会不会先问澄清问题
  • 会不会先给方案再动手
  • 会不会主动拆任务
  • 会不会在完成前验证

如果这些行为开始稳定出现，说明 Superpowers 已经真正进入工作状态了。

六、最常用的几个 skills，到底分别干什么

官方 README 里列出的核心 skill 很多，但如果你是第一次上手，先抓住下面几个就够了。

1. brainstorming

这是整套系统最关键的起点之一。

它的作用不是 “陪聊”，而是：

  • 在写代码前澄清真正需求
  • 识别约束、边界和成功标准
  • 给出候选方案并解释取舍
  • 把设计拆成可理解的小段和你确认

如果你之前经常遇到 AI 一开口就开始改文件，那 brainstorming 正是在纠正这个问题。

2. writing-plans

这个 skill 的目标，是把 “一个模糊的大任务” 拆成 “足够小、足够明确、可以连续执行的小任务”。

一个好的实现计划通常应该包含：

  • 具体文件路径
  • 要改什么
  • 如何验证
  • 任务之间的顺序关系

这一步做得越清楚，后面执行越稳。

3. subagent-driven-development

这是 Superpowers 很有代表性的一个能力。

它背后的思路是：

  • 不要让同一个上下文无限膨胀
  • 不要让一个 agent 一口气扛完整个大任务
  • 让新鲜上下文的 subagent 按任务分段执行

这样做通常更适合较复杂、较长链路的开发任务。

4. test-driven-development

这个 skill 不是嘴上说 “要重视测试”，而是强调真正的：

  • RED
  • GREEN
  • REFACTOR

也就是先写失败测试，再写最小实现，再整理代码。

如果你希望 AI 别老是 “先写一大坨实现，再随便补个测试”，这个 skill 很重要。

5. requesting-code-review

很多人让 AI 自己 review，最后得到的是一句 “看起来没问题”。

这个 skill 的目标，是让 review 变成一个独立、结构化、带严重级别判断的阶段。

也就是说，review 在这里不是礼节，而是流程关卡。

6. using-git-worktrees

如果你的开发任务容易互相打架，或者你希望 agent 在隔离环境里工作，这个 skill 会很有帮助。

它的价值主要有三点：

  • 隔离改动
  • 降低误操作风险
  • 方便并行推进不同任务

7. finishing-a-development-branch

这个 skill 很容易被忽略，但在真实开发里很重要。

因为很多 AI 在 “代码看起来差不多了” 之后就会停住，但真正收尾还包括：

  • 测试确认
  • 分支整理
  • 合并或开 PR 的决策
  • 是否保留工作区

有了这个 skill，结尾就不会太随意。

七、Superpowers 到底怎么用

这一段最关键。因为很多人装完插件后，最容易卡在一句话：

所以我平时到底怎么和它交互？

答案是：

你不用一直显式点 skill，而是要用更像 “交付任务” 的方式给它任务。

1. 错误示范：把它当成普通聊天机器人

帮我写一个登录页

因为这句话太短，既没有成功标准，也没有边界，也没有约束。

2. 更好的提法：把目标、约束和上下文讲出来

帮我给这个管理后台新增一个登录页。

要求沿用当前项目的 UI 风格，支持邮箱登录和验证码登录。

先不要直接写代码，先帮我梳理需求、边界情况和实现方案，再给我一个可执行计划。

这一类任务描述更容易触发 brainstorming -> writing-plans 的完整节奏。

3. 如果你想显式提醒它走流程，可以直接这样说

用 Superpowers 的方式来做这件事，先分析需求，再给方案和实施计划，确认后再开始改代码。

或者更直接一点：

请按 brainstorming、writing-plans、implementation、review 的顺序推进。

虽然很多时候它会自动触发，但在复杂任务里，明确说出来通常更稳。

4. 一个典型使用范式

plaintext

1
2
3
4
5
6
7
这是一个真实开发任务：
目标：
约束：
现有代码位置：
我希望你先做的事：

请先不要直接改代码，先用 Superpowers 的 workflow 帮我完成需求澄清和方案设计。

这类写法的好处是，agent 很容易知道自己当前应该先进入哪个阶段。

八、一个完整示例：从想法到交付

假设你现在有一个任务：

给博客后台新增 “文章归档统计卡片” 功能。

如果用 Superpowers 来推进，理想节奏通常会像这样。

第一步：触发需求分析

我想给博客后台加一个文章归档统计卡片。

请先不要改代码，先分析这个功能的目标、边界、数据来源和 UI 展示方式，

然后给我 2 到 3 个实现思路，并推荐一个方案。

这一步主要在触发 brainstorming。

第二步：确认方案后要求拆计划

方案 2 可以，继续把它拆成一个实现计划。

每个任务尽量控制在几分钟到十几分钟内，写清楚涉及文件和验证方式。

这一步主要在触发 writing-plans。

第三步：开始实施

可以开始执行。

按计划逐项推进，过程中保持测试和验证。

如果某一步有不确定性，先停下来说明。

这里通常就会进入 subagent-driven-development 或 executing-plans。

第四步：完成后要求 review 和收尾

实现完成后请先自测，再做一轮结构化 code review，

最后告诉我是否适合直接合并，还是应该先开一个 PR。

这一步会把 requesting-code-review 和 finishing-a-development-branch 串起来。

你会发现，这个过程和 “直接说一句帮我做掉” 相比，稳定性会高很多。

九、它和 Agent Team、Tmux、并行协作是什么关系

如果你之前看过我写的 Agent Team 或 Tmux 相关文章，会很容易把这些东西联起来。

1. Superpowers 解决的是「流程」

它关心的是：

  • 需求先分析还是先写代码
  • 要不要拆计划
  • 要不要测试
  • 要不要 review
  • 怎么收尾

2. Tmux 解决的是「观察和分屏」

它关心的是：

  • 多个 pane 怎么摆
  • 多个 agent 的输出怎么同时看

3. Agent Team 解决的是「角色分工」

它关心的是：

  • 谁负责分析
  • 谁负责实现
  • 谁负责 review
  • 怎么在多个 agent 之间传递任务

所以它们并不是互相替代，而是可以叠加：

  • Superpowers：流程方法 → 更稳的开发节奏
  • Agent Team：角色协作
  • Tmux：可视化分屏

你完全可以这样理解：

  • Superpowers 给每个 agent 装 “工作方法”
  • Agent Team 负责把多个 agent 组织起来
  • Tmux 负责让你看清它们在干嘛

十、我建议的新手使用姿势

如果你是第一次用 Superpowers，我不建议一上来就让它做特别大的任务。

更稳的方式是这样：

第 1 阶段：先用在中小任务上

比如：

  • 新增一个表单字段
  • 修一个边界 bug
  • 给某个页面补一个简单模块

目标不是看它能不能 “一口气写完”，而是观察它会不会：

  • 主动澄清需求
  • 给出取舍
  • 拆出计划
  • 做完验证

第 2 阶段：再尝试更长任务

比如：

  • 一个完整页面
  • 一个小功能闭环
  • 一组相关联的重构

这个阶段重点看的是，它在长链路里会不会失控。

第 3 阶段：最后再叠加并行和多 agent

等你确认基础 workflow 稳定之后，再考虑：

  • worktree
  • subagent
  • 多 pane
  • Team Lead 协调

不要反过来做。

因为如果基础流程还没稳，多 agent 只会把混乱放大。

十一、几个很实际的使用建议

任务越真实，效果越好

Superpowers 更擅长真实工程任务，而不是抽象脑洞题。

所以尽量给：真实目录、真实约束、真实目标、真实验收标准。

主动说 “先别改代码”

即使它有自动 workflow，我还是很建议在重要任务开头明确一句：

先不要直接改代码，先分析和出方案。

这句话会显著提高前半段的稳定性。

复杂任务一定要先让它出计划

如果任务超过十几分钟，或者会改多个文件、多个模块，就别直接让它开干。

先让它：设计 → 拆任务 → 明确验证，后面会省掉很多返工。

别把 “自动触发” 理解成 “完全不用管”

自动触发很方便，但你仍然要做两件事：

  • 看它现在处于哪个阶段
  • 在关键节点确认方向有没有偏

Superpowers 让流程更稳，不等于你可以完全不看路。

十二、适合拿来搭配的工作流

如果你已经在用下面这些方式，Superpowers 基本都能很好融进去：

  • Claude Code 的本地开发工作流
  • Codex App 的项目协作工作流
  • Codex CLI 的命令行开发节奏
  • Tmux 多 pane 观察模式
  • Agent Team 多角色协作
  • Git worktree 的隔离式开发

在这些场景里，它最有价值的地方不是 “替你点按钮”，而是：

把原本只存在于优秀工程师脑子里的开发顺序，变成 agent 也能稳定复现的流程资产。

十三、最后一句话：为什么我觉得它值得写

我越来越觉得，AI Coding 真正拉开差距的，不会只是模型本身。

更关键的是三件事：

  • 你怎么组织上下文
  • 你怎么约束执行顺序
  • 你怎么把经验沉淀成可复用 workflow

Superpowers 的价值，恰恰就在这里。

它不是让 agent “更像聊天机器人”，而是让 agent 更像一个会按步骤推进工作的开发搭档。