需求没问清就写，边界没拆清就写，用例没先写就写，改完了也不检查直接发——这是当前AI编程翻车最常见的四条路。最近有个叫Superpowers的东西突然火起来，它到底能解决什么问题？
先说几个核心判断。Superpowers不是那种靠一句更强prompt去赌模型状态的“魔法指令”，它做的事情非常朴素：把软件开发流程拆成一批可调用的技能，然后通过初始化指令让agent老老实实按这些技能走。最后看起来快了，实际返工更多？Superpowers恰恰就是为了终结这个恶性循环。
是什么
Superpowers是一套完整的软件开发工作流，建立在一组可组合的skills之上，并通过初始化指令确保agent真正去使用这些skills。它把整套流程拆成了这些可调用的技能：
·
brainstorming：先把需求问清楚，再给方案和设计·
writing-plans：把实现计划拆成可执行的小任务·
test-driven-development：严格走RED-GREEN-REFACTOR·
subagent-driven-development：把任务派给独立子袋里执行·
requesting-code-review：每个阶段都做复核·
using-git-worktrees：隔离分支和工作区，避免互相踩·
finishing-a-development-branch：最后决定合并、发PR还是保留分支
说白了，Superpowers想做的不是“让AI一口气写完代码”。而是让AI像一个流程严格、习惯良好的工程团队那样工作。
它和普通提示词最大的区别
普通提示词，通常只解决一件事：“这一次，怎么让模型表现好一点。”
Superpowers解决的是另一件事：“以后每一次，怎么让agent按同一套规则工作。”
它的核心结构只有两层。
第一层是skills。这些skill本质上是仓库里的SKILL.md文件，是一份份面向agent的操作手册。有的强调流程，有的强调测试，有的强调review，有的强调并行协作。
第二层是bootstrap/discovery。也就是让宿主agent在任务开始前，先检查有没有相关skill，再决定怎么做，而不是先凭直觉行动。
这件事看上去简单，意义却非常大。因为只要agent先“查skill，再行动”，它的行为风格就会稳定下来。
using-superpowers这个核心skill甚至把规则写得非常硬：如果有哪怕1%的概率某个skill适用，就必须先调用skill。但它也没有越界，同一个skill里写得很清楚：用户显式指令始终优先。
也就是说，Superpowers很强，但不夺权。
工作流程
先看官方README里的基本工作流。
第一步是brainstorming。在做新功能、改行为、做设计时，它要求agent先理解项目上下文，再一个问题一个问题把需求问清楚，然后给出2到3种方案与trade-off，最后形成设计稿并让你确认。这一步的价值非常高——很多AI编程翻车，不是实现差，而是一开始就做错题。
第二步是writing-plans。这个skill非常强调“计划必须细到一个没有上下文、品味一般、还不太爱测试的工程师也能执行”。所以它要求每个任务都写清楚文件路径、测试方法、命令、预期输出，甚至要求任务粒度缩到2到5分钟。
第三步是test-driven-development。它的口径极其强硬：NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST。换句话说，没有先看到失败测试，就不允许写生产代码。如果先写了代码再补测试，按它的规则是要删掉重来。
第四步是subagent-driven-development或executing-plans。前者更像“分任务给子袋里逐个实现，再逐个复核”；后者更像“按批次推进，保留人工检查点”。
第五步是requesting-code-review。它不是等到最后才review，而是鼓励阶段性review。每完成一个任务，就先做规格符合性检查，再做代码质量检查，防止问题一路滚到最后。
最后一步是finishing-a-development-branch。把测试、分支处理、PR或merge决策都纳入流程。这说明它追求的不是“写出代码”，而是“把开发闭环走完”。
如果你以前觉得agent经常像一个“聪明但毛躁的实习生”，那Superpowers干的事，其实就是给这个实习生配上一套非常严格的团队SOP。
怎么安装
Superpowers没有单一安装方式，必须按宿主平台来。
如果你用的是Claude Code，当前README给出的做法是先添加marketplace，再安装插件：
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace装完以后，README还建议直接用/help检查是否已经出现这些命令：
/help
# 应该能看到：
# /superpowers:brainstorm
# /superpowers:write-plan
# /superpowers:execute-plan如果你用的是Codex，它走的是原生skill discovery，把仓库clone到本地，将skills/目录通过符号链接暴露给~/.agents/skills/：
git clone https://github.com/obra/superpowers.git ~/.codex/superpowers
mkdir -p ~/.agents/skills
ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers然后重启Codex。还想用并行子袋里能力的话，官方docs/README.codex.md建议在配置里打开：
[features]
multi_agent=true如果你用的是OpenCode，README的推荐方式不是手抄一堆命令，而是让它直接拉取官方安装说明：
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md如果你用的是Gemini CLI，官方README给出的方式是：
gemini extensions install https://github.com/obra/superpowers如果你用的是GitHub Copilot CLI，则是：
copilot plugin marketplace add obra/superpowers-marketplace
copilot plugin install superpowers@superpowers-marketplaceREADME里把Cursor也列进了支持范围，但至少在我这次查阅的一手文档里，安装说明最完整的仍然是Claude Code、Codex、OpenCode、Gemini CLI和GitHub Copilot CLI这几条路径。
装完以后，不是马上看插件列表，而是直接开一个新会话做验证。官方建议你发一个会触发skill的任务，比如：
help me plan this feature或者：
let's debug this issue如果安装生效，agent应该会自动进入对应skill，而不是直接开始乱写代码。
最佳实践
Superpowers最好的用法，不是背一堆命令。而是学会把任务交给它的方式，改成“目标+约束+边界”，而不是“立刻给我代码”。
比如你要做一个新功能，不要一上来就说“把退款功能写出来”。更好的说法是：
先不要写代码。请用superpowers的brainstorming流程帮我把需求问清楚，给出2-3种方案和推荐方案。
目标：给现有支付模块增加退款能力
约束：不能改数据库结构；必须兼容旧接口；一周内上线
成功标准：支持全额退款、部分退款、重复请求幂等这样一来，agent会先进入需求澄清和设计阶段。后面的计划、TDD、子袋里执行和review，才有可靠基础。
如果你是在修bug，也不要直接说“修一下”。更适合的姿势是：
先不要改代码。请用systematic-debugging找root cause，再给我最小修复方案。
现象：支付回调偶发重复入账
线索：只在重试场景出现
要求：必须给出验证修复是否生效的步骤这才是Superpowers的强项。它更像一个“把agent拉回正确工程流程”的框架，而不是一个帮你偷懒的捷径。
写在最后
如果只用一句话概括Superpowers，我会这样说：
它不是在给coding agent增加魔法，而是在给coding agent增加工程纪律。
这套东西未必适合所有人。如果你只是偶尔让AI帮你写几行脚本，它可能显得过重。但如果你已经开始认真把Claude Code、Codex、Copilot CLI这类工具纳入日常开发流程，那Superpowers非常值得系统研究一次。
#AI编程#ClaudeCode#Codex#Superpowers#软件工程#开发效率
