理解 Superpowers：把 AI 编程从提示词变成工程流程
来源：obra/superpowers 仓库 README、Codex 使用说明、作者发布文章
整理日期：2026-05-20
核心结论：Superpowers 不是“教 AI 多写一点代码”，而是把 AI 编程从一次性提示词，升级成一套有约束、有检查、有分工的工程流程。
1. 一句话结论
如果我是前端开发者，我对 Superpowers 最值得学的不是某一个 skill，而是它背后的流程设计：
- 先澄清需求，再写代码。
- 先写计划，再开始实现。
- 先隔离工作区，再并行推进。
- 先写测试，再补实现。
- 先做评审，再继续下一个任务。
它本质上是在解决一个老问题：
AI 会写代码，但如果没有流程约束，它很容易写快、写散、写偏。
Superpowers 的价值，就是把这些容易失控的地方，全部前置成强制步骤。
2. 这套设计模式到底是什么
从仓库说明看，Superpowers 可以理解成三层结构：
| 层级 | 作用 | 我的理解 |
|---|---|---|
| Skills | 一组可组合的能力说明 | 相当于“标准作业程序” |
| Session bootstrap | 会话启动时注入的初始规则 | 强制 AI 先找技能、按流程办事 |
| Workflow | 从 brainstorm 到 review 的完整链路 | 把 AI 使用方式从聊天变成工程执行 |
它不是在追求一个“万能 Prompt”，而是在做一件更工程化的事：
把复杂任务拆成一组可复用、可触发、可校验的工作流技能。
这也是我理解它为什么叫 Superpowers：
- 技能本身是能力。
- 触发机制是调度器。
- 工作流是约束系统。
三者合起来，AI 才会表现得像一个更可靠的工程协作者，而不是一个随时自由发挥的生成器。
3. Superpowers 的核心工作流
根据官方 README，它的基本流程大致是下面这条链路：
brainstormingusing-git-worktreeswriting-planssubagent-driven-development或executing-planstest-driven-developmentrequesting-code-reviewfinishing-a-development-branch
这条链路最重要的不是“步骤多”，而是每一步都在处理 AI 编程里一个高频失控点。
| 步骤 | 在解决什么问题 | 如果没有这一步会怎样 |
|---|---|---|
| brainstorming | 用户需求模糊 | AI 很快开始写错方向 |
| using-git-worktrees | 多任务互相污染 | 改动串线，回滚困难 |
| writing-plans | 任务太大、太散 | AI 一次改太多，难 Review |
| subagent-driven-development | 单线程效率低 | 大任务推进慢，质量不稳定 |
| test-driven-development | 只顾实现不验真 | “看起来能跑”但实际不稳 |
| requesting-code-review | 自我感觉完成 | 问题积累到最后一起爆 |
| finishing-a-development-branch | 收尾随意 | 分支、提交、结果都混乱 |
4. 它背后的设计思想，我认为有 5 个关键点
4.1 Skill First：先定义做事方式，再让 AI 做事
Superpowers 最核心的模式，不是工具优先，而是技能优先。
也就是说：
- 不是“让 AI 自己临场发挥”
- 而是“先告诉 AI 遇到什么场景该怎么做”
这和前端团队里的规范体系很像：
- ESLint 约束代码风格。
- 组件规范约束抽象方式。
- Git Flow 约束分支协作。
- CI 约束交付标准。
Superpowers 做的是同一件事，只不过约束对象从“人类工程师”扩展到了“AI Agent”。
4.2 Workflow Over Prompt：流程比提示词更重要
很多人优化 AI 编程，思路还是：
- 多写点提示词。
- 多补点上下文。
- 多强调“认真一点”。
但 Superpowers 的思路更工程化：
与其不断优化一句话，不如把完整过程设计出来。
这背后的判断我很认同：
- 提示词解决的是单次表达问题。
- 工作流解决的是持续稳定性问题。
前端项目一旦进入多人协作、长期维护、复杂状态流，就不能只靠“这次说清楚”。必须让过程本身减少失控。
4.3 Small Tasks：任务颗粒度必须足够小
官方文档明确强调，计划要拆成很小的任务块，甚至是几分钟级别的工程任务。
这很关键，因为 AI 一旦面对“大而模糊”的任务，常见结果就是：
- 改动范围过大。
- 夹带无关重构。
- 为了显得完整主动增加抽象。
- 难以验证每一步是否正确。
这套设计本质上是在做“面向 Agent 的任务编排”。
对前端尤其重要，因为前端任务天然容易混在一起：
- 视觉改动
- 交互改动
- 状态管理改动
- 接口联调
- 权限控制
- 埋点补充
如果不切小，AI 很容易在一个任务里同时动五层。
4.4 Review Before Continue：不允许一路写到最后
Superpowers 把 code review 放在任务之间，而不是全部做完后再看。
这个设计非常像大型前端项目里的分阶段门禁：
- 一个任务完成先验收。
- 发现偏差就立刻修。
- 不让错误带着进入下一阶段。
这比“先让 AI 全写完，再统一看”强很多，因为后者的问题是：
- 错了也不知道从哪一步开始错。
- 改起来牵一发而动全身。
- Review 成本指数上升。
4.5 Evidence Over Claims：没有验证，就不算完成
Superpowers 明确强调 TDD、验证和证据优先。
这个理念我特别认同，因为 AI 最危险的点不是不会写，而是会“非常自信地交付错的东西”。
所以这套模式要求：
- 先写失败的测试。
- 再写最小实现。
- 再确认测试变绿。
- 再考虑重构。
本质上，它是在用工程证据替代语言承诺。
5. 前端开发者应该怎么理解这套模式
如果我是前端开发者，我会把 Superpowers 理解成一套“AI 协作工程化框架”，而不是一个插件。
它主要适合下面几类前端工作。
5.1 适合：复杂页面迭代
比如：
- 后台列表页加筛选条件
- 复杂表单拆组件
- 多 tab 页状态同步
- 路由权限和菜单联动调整
这些任务的特点是：
- 需求容易变
- 影响面不止一个文件
- 行为正确比代码写快更重要
Superpowers 的 brainstorm -> plan -> review 模式，刚好能压住这类问题。
5.2 适合：组件库或设计系统维护
比如：
- Button、Table、Form 组件统一 API
- 设计 token 迁移
- 主题能力改造
- 文档和示例同步更新
这类任务最怕“局部看起来合理，全局不一致”。
Superpowers 的价值在于：
- 先统一设计意图
- 再拆子任务
- 再让子 Agent 并行推进
- 每步都做 review 和验证
这很适合中大型前端团队。
5.3 适合：遗留项目重构
比如：
- Options API 向 Composition API 迁移
- JS 文件逐步改成 TS
- 请求层和页面层解耦
- 大组件拆分
遗留项目最怕的不是改不动，而是“边改边坏”。
Superpowers 通过小任务、隔离分支、阶段 review 的方式，能显著降低重构风险。
5.4 不太适合：极小的零碎任务
比如：
- 改一句文案
- 调一个间距
- 改一个图标
这类任务如果也走完整套 brainstorm、plan、TDD、review，成本可能高于收益。
所以我不建议把它理解成“所有任务都必须满流程执行”。
更合理的理解是：
任务越复杂、风险越高、协作越多，这套模式越有价值。
6. 前端场景里，我会怎么具体运用
下面我用一个 Vue 3 中后台场景举例。
6.1 场景：订单列表页增加“按当前筛选条件导出”
如果直接对 AI 说：
给订单页加个导出按钮
大概率会出现这些问题：
- 它自己补一套新状态。
- 导出参数和页面筛选条件不同步。
- 顺手改请求层，影响别的页面。
- 为了“稳一点”加很多兜底分支。
而用 Superpowers 的思路，任务会更像这样：
第一步：brainstorming
先把需求说清楚：
- 导出的是当前筛选结果，不是全量数据。
- 导出参数必须复用现有筛选状态。
- 不允许再维护第二份导出专用查询状态。
- 权限跟列表页查看权限保持一致还是独立控制，要先定清楚。
第二步：writing-plans
拆成几个小任务：
- 确认导出接口参数与页面筛选模型映射。
- 在列表工具栏增加导出按钮和 loading 状态。
- 复用现有筛选参数生成导出请求。
- 补导出流程的交互反馈。
- 验证筛选、分页、重置后的导出行为。
第三步：subagent-driven-development
让不同子任务并行处理，但边界要清楚：
- 一个 Agent 只处理 UI 接入。
- 一个 Agent 只处理参数映射和请求封装。
- 一个 Agent 只补测试或验证脚本。
第四步：requesting-code-review
Review 重点不是“能不能跑”，而是：
- 是否复用了同一份筛选状态
- 是否引入了重复逻辑
- 是否影响了现有列表请求流程
- 是否加了不必要的兼容分支
这就是前端里非常典型的 Superpowers 用法。
7. 如果我要在自己的前端项目里借鉴，我会优先学这 6 个技能
| Skill | 它解决什么问题 | 前端里怎么用 |
|---|---|---|
brainstorming |
需求不清就开写 | 先把页面行为、权限、状态边界问清楚 |
writing-plans |
AI 一次改太多 | 把页面、组件、接口、测试拆成独立任务 |
using-git-worktrees |
多任务开发互相污染 | 并行处理多个页面改动或多个重构分支 |
subagent-driven-development |
单个 Agent 推进太慢 | UI、状态、测试拆给不同 Agent |
test-driven-development |
改完只看表面效果 | 给 hooks、utils、状态逻辑先写失败测试 |
requesting-code-review |
AI 自评偏乐观 | 每个任务完成后先做结构和风险复核 |
如果你不想一次性全部照搬，我建议先学前三个：
brainstormingwriting-plansrequesting-code-review
因为这三个技能最直接影响结果质量，而且对前端项目的适配成本最低。🚀
8. 这套模式对前端架构有什么启发
从前端架构师视角看，Superpowers 最有价值的不是“AI 自动化”，而是它在逼你把隐性经验显式化。
它要求你把这些东西写清楚：
- 什么叫任务完成
- 什么叫不允许修改
- 什么叫高风险改动
- 什么叫组件职责清晰
- 什么叫状态复用而不是复制
这件事非常重要，因为很多前端团队的问题本来就不是技术栈不行，而是工程约束没有写出来。
所以我觉得 Superpowers 有两个层面的价值：
| 层面 | 价值 |
|---|---|
| 对 AI | 提高稳定性和可控性 |
| 对团队 | 倒逼流程、规范、边界更清晰 |
换句话说：
你以为你是在训练 AI，实际上你也在反向整理自己的工程方法论。
9. 我不建议你照搬的地方
虽然我认可这套模式，但也不建议原封不动照搬。
9.1 不要把所有任务都强制 TDD
前端里很多任务是：
- 视觉改版
- 文案调整
- 布局优化
- 交互细节微调
这些任务不一定适合严格测试先行。
更合理的做法是分层：
- 纯逻辑、状态流、工具函数，优先 TDD
- 复杂组件行为，补关键交互测试
- 纯样式调整，以手测和视觉回归为主
9.2 不要为了并行而并行
多 Agent 并行只有在任务边界足够清晰时才有效。
如果前端任务本身强耦合，比如：
- 页面 UI 改动依赖状态结构改造
- 状态改造又依赖接口字段调整
这时候强行并行，结果通常是反复冲突和重复返工。
9.3 不要把 skill 当成“命令菜单”
Skill 的本质不是快捷指令，而是行为约束。
如果只是把它理解成：
- 这个命令用来写计划
- 那个命令用来开评审
那你学到的只是表层。
真正值得借鉴的是：
什么场景下，必须先停下来做哪一步。
10. 我的结论
Superpowers 这套设计模式，本质上是在把 AI 编程从“会写”升级成“会按工程方式交付”。
对前端开发者来说，我最推荐学的不是安装方式，而是下面三件事：
- 学它如何先做需求澄清。
- 学它如何把任务切成可执行的小块。
- 学它如何把 review 和验证前置到过程里。
如果你已经在做中后台、组件库、设计系统、遗留项目重构，这套模式很值得借鉴。💡
如果只用一句话总结它对前端的启发，那就是：
不要再把 AI 当“更快的代码补全”，而要把它当“需要流程约束的协作工程师”。
11. 我建议的落地步骤
如果你想在自己的前端项目里试一轮，我建议按这个顺序落地：
- 先别急着装全套技能，先模仿它的流程。
- 任何中等以上任务，先写
背景 + 目标 + 范围 + 约束 + 验收标准。 - 把任务拆成 2 到 5 分钟级别的小步骤，不让 AI 一次改太多。
- 每完成一个小任务，都单独做一次 review。
- 对状态管理、工具函数、复杂数据转换优先引入测试先行。
- 等流程跑顺后，再考虑把这些规则沉淀成你自己的 skill 或团队规范。
这样做的收益最大，而且最符合前端团队的实际情况。✅