芥末
发布于 2026-02-07 / 0 阅读
0
0

Superpowers 工作流入门:让 AI 编码先澄清需求、再计划、再实现

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 风格的实施计划。
每一步都要很小,说明要改哪些文件、做什么改动、如何验证。

一个好的计划应该具备三个特点:

  1. 步骤足够小
    每一步最好只完成一个明确目标,例如“增加按钮组件”“补充样式变量”“写 localStorage 读取逻辑”。

  2. 文件范围清楚
    AI 需要提前说明预计修改哪些文件,避免执行时突然改一大片无关代码。

  3. 每一步都有验证方式
    验证可以是自动化测试、运行命令、页面检查,也可以是类型检查和 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 继续后面的步骤,而是先让它定位当前步骤的问题。

示例:给网站增加暗色模式

假设有一个前端网站,需要增加暗色模式切换功能,需求是:

  1. 默认使用亮色主题;
  2. 页面上有一个按钮可以切换亮色和暗色;
  3. 刷新页面后保留上次选择。

可以这样启动 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 入门只需要抓住三句话:

  1. 不要一上来就让 AI 改代码,先让它澄清需求。
  2. 不要让 AI 凭感觉动手,先让它写出可检查的实施计划。
  3. 不要接受“已经完成”的口头结论,要看测试、运行命令或手动验证结果。

当 AI 编码从“直接生成代码”变成“澄清 → 计划 → 实现 → 验证”,代码修改就更容易理解、审查和继续维护。


评论