如果你已经开始把 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
    /plugin install superpowers@claude-plugins-official
    方式二：Superpowers Marketplace
    plaintext

先注册 marketplace

/plugin marketplace add obra/superpowers-marketplace

再安装

/plugin install superpowers@superpowers-marketplace
2. Codex CLI 安装
终端执行打开插件面板：
plaintext
/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，而是要用更像 “交付任务” 的方式给它任务。
  8. 错误示范：把它当成普通聊天机器人
    帮我写一个登录页
    因为这句话太短，既没有成功标准，也没有边界，也没有约束。
  9. 更好的提法：把目标、约束和上下文讲出来
    帮我给这个管理后台新增一个登录页。
    要求沿用当前项目的 UI 风格，支持邮箱登录和验证码登录。
    先不要直接写代码，先帮我梳理需求、边界情况和实现方案，再给我一个可执行计划。
    这一类任务描述更容易触发 brainstorming -> writing-plans 的完整节奏。
  10. 如果你想显式提醒它走流程，可以直接这样说
    用 Superpowers 的方式来做这件事，先分析需求，再给方案和实施计划，确认后再开始改代码。
    或者更直接一点：
    请按 brainstorming、writing-plans、implementation、review 的顺序推进。
    虽然很多时候它会自动触发，但在复杂任务里，明确说出来通常更稳。
  11. 一个典型使用范式
    plaintext
    这是一个真实开发任务：
    目标：
    约束：
    现有代码位置：
    我希望你先做的事：

请先不要直接改代码，先用 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 更像一个会按步骤推进工作的开发搭档。