Superpowers 是什么
Superpowers 是一套面向 AI 编码工具的工作流方法,主要用来解决一个常见问题:让 AI 写代码时,不能一上来就直接改文件,而是要先把需求、限制、方案和验证方式说清楚。
它不是一种新的编程语言,也不是新的编辑器。更准确地说,它像是给 Claude Code、OpenCode 这类 AI 编码工具加了一套开发纪律:
- 先确认要做什么,而不是凭一句模糊需求开工;
- 先拆出实施计划,而不是一次性改一堆文件;
- 先考虑测试和验证,而不是靠“看起来可以”判断完成;
- 每一步都有明确目标,方便回滚、检查和继续迭代。
Superpowers 技能库地址:
https://github.com/obra/superpowers
它特别适合 vibe coding,也就是用自然语言驱动 AI 生成或修改代码的开发方式。vibe coding 的优势是启动快,但风险也明显:需求没讲清、AI 理解偏了、修改范围失控、代码能跑但后续难维护。Superpowers 的价值就在于把“随口让 AI 写代码”变成“按软件工程流程协作”。
核心思想:让 AI 按开发流程工作
Superpowers 的核心可以压缩成一条链路:
设计驱动 → 计划驱动 → 测试驱动 → 质量驱动
对应到实际使用中,就是让 AI 在不同阶段做不同的事。
| 阶段 | AI 应该做什么 | 避免什么问题 |
|---|---|---|
| 设计驱动 | 先澄清目标、边界、约束和成功标准 | 需求没问清就开始写代码 |
| 计划驱动 | 把任务拆成小步骤,说明要改哪些文件 | 一次性大改,难以检查 |
| 测试驱动 | 先考虑如何验证,再实现功能 | 写完才发现无法证明正确 |
| 质量驱动 | 完成前给出测试、检查、运行结果 | 只口头声明“完成了” |
完整流程可以画成这样:
flowchart TD
A[提出需求] --> B[brainstorm:澄清目标和约束]
B --> C{需求是否清楚}
C -- 否 --> B
C -- 是 --> D[write-plan:拆分实施计划]
D --> E{计划是否可执行}
E -- 否 --> D
E -- 是 --> F[execute-plan:按步骤修改代码]
F --> G[运行测试和验证命令]
G --> H{验证是否通过}
H -- 否 --> I[定位问题并修正]
I --> G
H -- 是 --> J[交付修改说明和验证证据]
这里最重要的不是命令本身,而是顺序。只要顺序乱了,AI 就容易回到“直接改代码”的模式。
适合和不适合使用的场景
Superpowers 不是所有任务都必须用完整流程。它适合有不确定性、有代码影响范围、有后续维护成本的任务。
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 给网站增加暗色模式 | 适合 | 涉及 UI、状态、持久化、样式和验证 |
| 给项目增加搜索功能 | 适合 | 需要确认搜索范围、交互方式、性能和接口 |
| 重构一个复杂组件 | 适合 | 需要控制改动范围,并用测试保证行为不变 |
| 修复偶发 bug | 适合 | 可以结合系统性调试和验证流程 |
| 修改一句文案 | 不必完整使用 | 任务很小,直接改更快 |
| 修正错别字 | 不必完整使用 | 没有复杂设计和验证成本 |
| 写一次性脚本 | 视情况而定 | 如果脚本简单,可以只做简短计划 |
一个实用判断标准是:如果你担心 AI 改完以后不知道改了哪里、为什么这么改、怎么证明没出问题,就适合使用 Superpowers。
在 Claude Code 中安装和使用
Claude Code 可以通过插件方式安装 Superpowers。命令以官方仓库说明为准,常见安装方式如下:
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
安装后,可以用帮助命令检查是否有 Superpowers 相关能力:
/help
常用命令主要是这三个:
/superpowers:brainstorm
/superpowers:write-plan
/superpowers:execute-plan
这三个命令分别对应需求澄清、计划编写、按计划执行。刚开始使用时,记住这三个就够了。
在 OpenCode 中使用 Superpowers 思路
如果没有做深度插件集成,也可以把 Superpowers 当作一套协作约定写进 OpenCode 的设置或项目指令里。关键是明确告诉 AI:遇到开发任务时,不要直接实现,要按固定顺序工作。
可以写成类似这样的项目指令:
当我要求使用 Superpowers 工作流时,请按以下方式协作:
1. 先进行 brainstorm:
- 澄清需求目标
- 询问必要问题
- 识别限制条件
- 给出 2 到 3 个可选方案
2. 再进行 write-plan:
- 写出分步骤实施计划
- 标明每一步要修改或新增的文件
- 每一步都要包含验证方式
- 单步改动保持足够小,方便检查
3. 最后进行 execute-plan:
- 按计划逐步实现
- 每完成一步,说明改动内容
- 提醒需要运行的测试或验证命令
- 不要跳过验证后直接宣称完成
这样即使没有安装专门插件,也能让 OpenCode 按同样的节奏工作。
三个核心步骤
Superpowers 里还有很多偏工程化的技能,例如:
- test-driven-development:测试驱动开发;
- systematic-debugging:系统性调试;
- verification-before-completion:完成前验证;
- dispatching-parallel-agents:分派多个 AI agent 并行处理;
- requesting-code-review:请求代码审查;
- using-git-worktrees:使用 Git worktree 隔离开发分支。
这些能力在中大型项目里很有用,但入门阶段不需要一次学完。日常开发先掌握三个核心步骤就能明显减少混乱:
brainstorm → write-plan → execute-plan
brainstorm:先弄清楚要做什么
brainstorm 的作用是把模糊想法变成可实现需求。
在 Claude Code 中可以直接输入:
/superpowers:brainstorm
也可以用自然语言要求 AI 进入这个阶段:
我想给项目增加一个搜索功能,但细节还没想清楚。
请用 Superpowers 的 brainstorm 阶段先帮我澄清需求,不要直接写代码。
这个阶段 AI 应该重点问这些问题:
| 问题类型 | 示例 |
|---|---|
| 目标 | 这个功能最终要解决什么问题? |
| 使用者 | 谁会用这个功能?管理员、普通用户还是访客? |
| 范围 | 搜索标题、正文、标签,还是全部内容? |
| 约束 | 是否要兼容旧浏览器?是否已有接口? |
| 成功标准 | 什么结果算完成?页面可见、测试通过、性能达标? |
| 方案选择 | 用前端本地搜索,还是后端接口搜索? |
brainstorm 阶段不要急着让 AI 写代码。需求越模糊,越要先问清楚。否则 AI 会自己补全细节,而这些“补全”不一定符合真实需要。
write-plan:把需求拆成能执行的小步骤
需求明确后,进入 write-plan 阶段:
/superpowers:write-plan
也可以直接这样说:
根据刚才确认的需求,写一个 Superpowers 风格的实施计划。
每一步都要很小,说明要改哪些文件、做什么改动、如何验证。
一个好的计划应该具备三个特点:
-
步骤足够小
每一步最好只完成一个明确目标,例如“增加按钮组件”“补充样式变量”“写 localStorage 读取逻辑”。 -
文件范围清楚
AI 需要提前说明预计修改哪些文件,避免执行时突然改一大片无关代码。 -
每一步都有验证方式
验证可以是自动化测试、运行命令、页面检查,也可以是类型检查和 lint 检查。
计划可以长这样:
## 实施计划:增加暗色模式切换
### Step 1:确认现有主题结构
- 查看 `src/App.tsx`
- 查看 `src/styles.css`
- 不修改代码
- 验证:说明当前样式是全局 CSS、CSS Modules 还是组件内样式
### Step 2:增加主题状态
- 修改 `src/App.tsx`
- 增加 `theme` 状态,取值为 `light` 或 `dark`
- 验证:运行类型检查,确保没有 TypeScript 报错
### Step 3:增加切换按钮
- 修改 `src/App.tsx`
- 增加“切换主题”按钮
- 点击后在 `light` 和 `dark` 之间切换
- 验证:本地启动页面,点击按钮后状态发生变化
### Step 4:增加样式变量
- 修改 `src/styles.css`
- 使用 CSS 变量定义亮色和暗色主题
- 验证:切换主题后背景色和文字颜色变化
### Step 5:持久化主题选择
- 修改 `src/App.tsx`
- 使用 `localStorage` 保存主题
- 页面加载时读取上次选择
- 验证:刷新页面后主题保持不变
这种计划看起来比“直接帮我实现暗色模式”慢一点,但它能让每一步都可检查。出错时,也能快速定位是哪一步的问题。
execute-plan:按计划分步实现
计划确认后,再让 AI 执行:
/superpowers:execute-plan
也可以这样约束执行方式:
按刚才的计划执行。
每次只做一个 Step。
完成后停下来,说明:
1. 修改了哪些文件;
2. 为什么这样改;
3. 我需要运行什么命令验证;
4. 验证通过后再继续下一步。
这句话很关键。AI 工具容易一次性把所有步骤做完,结果用户只能面对一堆改动。分步执行可以把风险拆小,每一步都能确认方向是否正确。
执行过程推荐保持这样的节奏:
sequenceDiagram
participant Dev as 开发者
participant AI as AI 编码工具
participant Code as 项目代码
participant Test as 测试/验证
Dev->>AI: 执行计划中的 Step 1
AI->>Code: 修改或检查相关文件
AI-->>Dev: 说明改动和验证方式
Dev->>Test: 运行测试或查看页面
Test-->>Dev: 返回结果
Dev->>AI: 通过,继续 Step 2
如果某一步验证失败,不要直接让 AI 继续后面的步骤,而是先让它定位当前步骤的问题。
示例:给网站增加暗色模式
假设有一个前端网站,需要增加暗色模式切换功能,需求是:
- 默认使用亮色主题;
- 页面上有一个按钮可以切换亮色和暗色;
- 刷新页面后保留上次选择。
可以这样启动 Superpowers 流程:
我有一个网站,想增加暗色模式切换功能:
1. 默认亮色主题;
2. 点击按钮可以切换亮色和暗色;
3. 刷新页面后记住上次选择。
请使用 Superpowers 工作流处理:
先 brainstorm 澄清需求,再 write-plan 写实施计划,最后 execute-plan 分步实现。
在计划确认前不要修改代码。
brainstorm 阶段,AI 可能会问:
1. 项目使用什么框架?React、Vue、纯 HTML,还是其他?
2. 当前样式是 CSS 文件、Tailwind CSS,还是组件库主题?
3. 暗色模式需要覆盖整个页面,还是只覆盖当前组件?
4. 是否需要跟随系统主题 prefers-color-scheme?
5. 是否已有测试框架?
假设项目是 React,并且只需要手动切换主题,不跟随系统主题,可以让 AI 继续写计划。
计划确认后,AI 可能先补一个测试。以 React Testing Library 为例,测试可以表达核心行为:
import { render, screen, fireEvent } from "@testing-library/react";
import App from "./App";
test("can switch theme and persist selection", () => {
render(<App />);
const button = screen.getByRole("button", { name: /切换主题/i });
expect(document.documentElement.dataset.theme).toBe("light");
fireEvent.click(button);
expect(document.documentElement.dataset.theme).toBe("dark");
expect(localStorage.getItem("theme")).toBe("dark");
});
实现时可以使用 data-theme 配合 CSS 变量:
import { useEffect, useState } from "react";
import "./styles.css";
type Theme = "light" | "dark";
export default function App() {
const [theme, setTheme] = useState<Theme>(() => {
return (localStorage.getItem("theme") as Theme) || "light";
});
useEffect(() => {
document.documentElement.dataset.theme = theme;
localStorage.setItem("theme", theme);
}, [theme]);
function toggleTheme() {
setTheme((current) => (current === "light" ? "dark" : "light"));
}
return (
<main className="page">
<button onClick={toggleTheme}>切换主题</button>
<h1>示例页面</h1>
<p>当前主题:{theme}</p>
</main>
);
}
对应 CSS:
:root {
--bg-color: #ffffff;
--text-color: #111827;
}
:root[data-theme="dark"] {
--bg-color: #111827;
--text-color: #f9fafb;
}
body {
margin: 0;
background: var(--bg-color);
color: var(--text-color);
}
.page {
min-height: 100vh;
padding: 24px;
}
验证命令可以写进计划里:
npm test
npm run lint
npm run dev
手动验证项也要明确:
| 验证项 | 期望结果 |
|---|---|
| 初次打开页面 | 默认亮色主题 |
| 点击切换按钮 | 页面切换为暗色主题 |
| 再次点击按钮 | 页面切换回亮色主题 |
| 刷新页面 | 保持刷新前的主题 |
| 运行测试 | 测试通过,无报错 |
这个例子展示了 Superpowers 的关键点:不是让 AI 少写代码,而是让 AI 在写代码前先把需求、计划和验证方法建立起来。
日常使用模板
日常开发不需要每次都写很长的提示词,可以准备一个固定模板。
通用模板
接下来这个任务请使用 Superpowers 工作流。
要求:
1. 先进入 brainstorm 阶段,澄清目标、边界、限制条件和成功标准;
2. 未经确认,不要修改代码;
3. 需求确认后,进入 write-plan 阶段,写出分步骤计划;
4. 每一步都要说明要修改的文件、操作内容和验证方式;
5. 我确认计划后,再进入 execute-plan 阶段;
6. 执行时每次只做一个小步骤,完成后停下来说明改动和验证命令。
小任务模板
适合简单 UI 调整、小功能增强:
这个任务比较小,请用简化版 Superpowers 流程:
先用 brainstorm 问清楚必要问题,然后给一个简短计划。
计划确认后再改代码。
中等任务模板
适合普通业务功能:
请完整使用 brainstorm 和 write-plan。
计划里要包含:
- 涉及文件;
- 每一步改动;
- 测试或验证命令;
- 可能风险。
计划确认后,我再决定是否让你 execute-plan。
大任务模板
适合重构、复杂功能、多文件修改:
请严格使用完整 Superpowers 流程。
限制:
- 不要一次性实现全部功能;
- 每一步只做一个可验证的小改动;
- 优先补测试或说明现有测试覆盖情况;
- 每一步完成后等待确认;
- 完成前必须提供验证结果,不能只说已经完成。
不同规模任务怎么取舍
Superpowers 可以按任务复杂度裁剪,不必每次都走满流程。
| 任务规模 | 推荐用法 | 示例 |
|---|---|---|
| 很小 | 只做简短 brainstorm | 改按钮文案、调整间距 |
| 小功能 | brainstorm + 简单计划 | 增加一个表单字段 |
| 中等功能 | brainstorm + write-plan + 手动确认后执行 | 增加搜索、筛选、分页 |
| 大功能 | 完整流程 + 测试 + 分步验收 | 权限系统、复杂重构、跨模块功能 |
| Bug 修复 | brainstorm + systematic-debugging + verification | 定位接口异常、修复状态错乱 |
使用的核心不是“流程越多越好”,而是让流程匹配风险。改动越大,越应该让 AI 慢下来,把每一步说清楚。
常见问题
要不要记住所有命令
不需要。入门阶段只要记住一个原则:
先想清楚,再写代码。
命令记不住时,可以直接用自然语言:
请用 Superpowers 的方式帮我做这个功能。
你自己选择合适步骤,但必须先澄清需求,再写计划,最后分步实现。
AI 能理解这个协作方式后,命令只是快捷入口。
会不会比直接让 AI 改代码更慢
开始时会慢一点,因为多了澄清和计划步骤。但它减少的是后面的返工成本。
直接让 AI 改代码,经常会出现这些问题:
- AI 理解错需求,改完才发现方向不对;
- 一次性修改很多文件,难以审查;
- 没有测试或验证,只能靠肉眼看;
- 后续继续迭代时,不知道前一次为什么这么改。
Superpowers 把这些问题提前暴露出来。尤其是中等以上功能,前面花几分钟写清计划,通常比后面反复修偏差更省时间。
可以只用 brainstorm 吗
可以。brainstorm 本身就很有价值,尤其适合想法还不完整的时候。
例如:
我想做一个待办事项应用,但还没想清楚功能边界。
请只做 brainstorm,帮我整理 MVP 版本应该包含哪些功能。
暂时不要写计划,也不要写代码。
这里的 MVP 指 Minimum Viable Product,也就是最小可行产品。通过 brainstorm,可以先确定第一版只做任务新增、完成、删除、筛选,暂时不做登录、多端同步、复杂标签等功能。
AI 说完成了就可以信吗
不能只看声明,要看证据。
完成前至少要求 AI 给出这些信息:
请在宣布完成前提供:
1. 修改了哪些文件;
2. 每个文件的核心改动;
3. 运行了哪些验证命令;
4. 验证结果是什么;
5. 还有哪些未覆盖风险。
如果项目里有测试,要求它运行测试;如果是前端界面,要求它说明手动验证路径;如果是类型项目,要求它运行类型检查。
计划写得太大怎么办
让 AI 重新拆小。
可以直接说:
这个计划的步骤太大。
请重新拆分,每一步控制在 2 到 5 分钟内可以完成,并且每一步都有独立验证方式。
好计划不追求一次讲完所有细节,而是让每一步都能被执行、检查和回滚。
使用时容易踩的坑
需求没确认就进入实现
如果 AI 在 brainstorm 阶段就开始改代码,要立刻打断:
停止修改代码。
现在仍然处于 brainstorm 阶段,请只澄清需求和方案,不要实现。
Superpowers 的价值来自阶段边界。阶段混在一起,流程就失效了。
计划没有验证步骤
只有“修改 A、增加 B、调整 C”的计划还不够,每一步都要有验证方式。
不完整的计划:
1. 增加按钮
2. 增加样式
3. 保存主题
更好的计划:
1. 增加按钮
- 修改 src/App.tsx
- 验证:页面出现“切换主题”按钮
2. 增加样式
- 修改 src/styles.css
- 验证:切换 data-theme 后背景和文字颜色变化
3. 保存主题
- 修改 src/App.tsx
- 验证:刷新页面后保持上次主题
一次执行太多步骤
AI 一次执行完整计划,容易让审查变困难。更稳的方式是每次只执行一个小步骤。
只执行 Step 1。
完成后停止,等待我确认后再继续。
忽略已有项目风格
让 AI 在写计划前先观察项目结构和代码风格,避免引入不一致写法。
在写计划前,请先检查项目结构、命名风格、状态管理方式和测试框架。
不要引入与现有项目不一致的新方案,除非先说明理由。
把 Superpowers 当成自动驾驶
Superpowers 能约束 AI,但不能代替开发者判断。关键节点仍然需要人确认:
- 需求是否符合真实目标;
- 方案是否适合项目;
- 修改范围是否合理;
- 验证结果是否可信;
- 是否引入额外复杂度。
AI 负责加速执行和辅助分析,人负责控制方向和验收结果。
一套可直接复制的完整提示词
需要快速开始时,可以直接复制这段:
请使用 Superpowers 工作流处理这个开发任务。
任务描述:
【在这里写你的需求】
工作方式:
1. 先 brainstorm:
- 问清楚需求目标、边界、限制条件和成功标准;
- 如果有多种方案,请给出 2 到 3 个选择,并说明适用场景;
- 在我确认前不要修改代码。
2. 再 write-plan:
- 把任务拆成小步骤;
- 每一步说明要修改或新增的文件;
- 每一步说明具体操作;
- 每一步说明验证方式;
- 控制单步改动范围,方便我审查。
3. 最后 execute-plan:
- 我确认计划后再开始执行;
- 每次只执行一个步骤;
- 每步完成后说明改了什么、为什么这么改、如何验证;
- 如果验证失败,先修复当前步骤,不要继续后续步骤;
- 完成前提供验证结果,不要只口头声明完成。
关键记忆点
Superpowers 入门只需要抓住三句话:
- 不要一上来就让 AI 改代码,先让它澄清需求。
- 不要让 AI 凭感觉动手,先让它写出可检查的实施计划。
- 不要接受“已经完成”的口头结论,要看测试、运行命令或手动验证结果。
当 AI 编码从“直接生成代码”变成“澄清 → 计划 → 实现 → 验证”,代码修改就更容易理解、审查和继续维护。