Vibe Code 之 Superpowers 帮助你写出高质量代码

导语

你有没有过这种经历——对着 AI 编程工具说「帮我写个用户认证模块」，它二话不说就开始吐代码，几百行一气呵成。你看了五分钟，发现它默认假设了 JWT 方案（其实你想用 Session），数据表结构是它自己编的（和你的 schema 对不上），而且一行测试都没有。

你让它改，它又噼里啪啦改了一堆。改完你再看，测试是补了，但中间的逻辑悄悄变了，旧功能被你覆盖掉了。来回三四轮，你终于放弃了，心想「还不如自己写」。

这不是模型不够聪明。这是缺少工程纪律。

Superpowers 是目前最火的编程skills之一，定位非常精准：它不是让 AI 变得更聪明，而是给 AI 编程工具套上一套软件工程的标准作业程序（SOP）[^1]。它用一套强制性的工作流，让 Claude Code、OpenCode、Codex 这些工具在写代码之前先做需求澄清，先做设计，先写失败的测试——就像一个有工程素养的人类开发者那样。

这篇文章会带你完整理解 Superpowers 的理念、机制、14 个核心技能，然后以 OpenCode 为例，手把手完成一个实战项目。读完你会知道：为什么 226K 开发者选择了这套方法论，以及如何用它把 AI 编程从「碰运气」变成「可复现的工程过程」。

---

一、Superpowers 是什么

1.1 一句定义

Superpowers = 一套强制执行的软件工程方法论 + 一组可组合的 Skills，它让 AI 编程助手在写代码之前先做需求澄清、设计确认、任务拆解、TDD、代码审查和验证收尾[^2]。

关键区别：Superpowers 和普通的 Skill 系统，不在同一个层面。普通 Skill 是「建议」——AI 可以根据 description 自主判断是否触发。Superpowers 是「纪律」——入口 Skill 会在每次会话启动时强制注入，确保 AI 必须先查有没有适用技能，再决定怎么做[^3]。

1.2 设计哲学：Process over Prompt

Superpowers 创始人 Jesse Vincent（@obra）是资深软件工程师，他的核心判断是[^4]：

「很多 coding agent 的问题，并不出在能力上限，而是出在默认行为。需求还没讲清楚就开始实现，代码写完才想起补测试，做到一半跳过 review……」

所以 Superpowers 的 5 条设计哲学是[^3]：

1. 管的是过程失控点，不是模型上限 —— AI 能做多好不由 Superpowers 决定，但 Superpowers 保证它不会在最差的时候乱来
2. 把工程纪律写进 agent 的选择架构 —— 不是在旁边贴张「温馨提示」，而是重写 agent 的默认行为路径
3. 技能按压力场景打磨 —— 这些 Skill 被丢进「系统正在烧钱」「代码已经写了 45 分钟」这种真实高压场景里反复测试
4. 慢下来是为了更稳地快 —— 设计阶段多花 15 分钟，实现阶段少返工 2 小时
5. 一次编码请求 = 一个可管理的工程过程 —— 可回看、可复查、可追责，而不是 AI 吐完代码你就得全部自己审

---

二、三条铁律

Superpowers 的 14 个 Skills 背后，有三条不可动摇的铁律。这三条铁律定义了「什么情况下 AI 绝不能直接写代码」[^5]。

铁律 1：无设计，不编码

必须先通过 brainstorming 明确需求并产出设计文档，严禁直接跳进代码实现。

没有 Superpowers 时，你说「做一个用户认证」，AI 默认假设 JWT、默认假设 email+password、默认假设 MySQL。结果是：API 签了却对不上你的现有架构，改都比新建费劲。

有 Superpowers 时，AI 会先问：你要 Session 还是 JWT？第三方登录要不要？密码策略是什么？并发量预估多少？——这些问题问完，设计文档自然就出来了。

铁律 2：无计划，不执行

必须先通过 writing-plans 将任务拆解为清晰可追踪的原子任务。

Superpowers 对计划的粒度要求极其具体：「拆到 2-5 分钟能完成的小任务，每个任务写清楚要碰哪些文件、验证标准是什么」。官方原话是——计划要清楚到「一个热情但品味不佳、没有判断力、没有项目上下文、而且不爱测试的初级工程师」也能照着执行[^3]。

铁律 3：无验证，不交付

必须提供测试通过和运行成功的实际证据，严禁口头「修好了」。

这是 Superpowers 最反直觉也最有价值的一条铁律。test-driven-development 强制 RED → GREEN → REFACTOR 循环：先看到测试失败（证明测试有意义），再写最小实现让它通过，最后重构。verification-before-completion 进一步要求——完成任务时必须贴出运行结果截图或日志，不能只说「搞定了」。

「先看到测试失败，再写最小实现；测试之前写出来的代码该删就删。」——Superpowers 官方文档[^3]

---

三、7 步工作流：Superpowers 如何指挥 AI

把三条铁律具象化，就是 Superpowers 的 7 步主工作流[^3][^5]。这不是建议，是强制执行路径：

用户需求
    │
    ▼
┌──────────────────────────────────────────────┐
│ 第1步：brainstorming（头脑风暴）               │
│ AI 先提问，不写代码。确认需求边界、架构选型、       │
│ 性能要求、约束条件。产出结构化设计文档。             │
├──────────────────────────────────────────────┤
│ 第2步：using-git-worktrees（工作区隔离）         │
│ 为当前功能创建独立 Git Worktree，主线代码绝对安全。 │
├──────────────────────────────────────────────┤
│ 第3步：writing-plans（制定计划）                 │
│ 将设计拆分为 2-5 分钟的原子任务。                │
│ 每个任务包含：文件路径 + 实现内容 + 验证方式。    │
├──────────────────────────────────────────────┤
│ 第4步：executing-plans / subagent-driven       │
│ 按计划批量推进任务。可调度多个子 Agent 并行开发     │
│ 独立模块。每个任务含两阶段审查：                   │
│  ① spec compliance（做没做对）                  │
│  ② code quality（写没写好）                     │
├──────────────────────────────────────────────┤
│ 第5步：test-driven-development（TDD）           │
│ RED → GREEN → REFACTOR 强制循环。               │
│ 必须先看到失败测试，再写代码，最后重构。            │
├──────────────────────────────────────────────┤
│ 第6步：requesting-code-review（代码审查）        │
│ 对照 Plan 逐项核查。Review 是阶段门，不是结尾礼仪。│
├──────────────────────────────────────────────┤
│ 第7步：finishing + verification（收尾验证）     │
│ 测试全绿？lint 通过？commit 规范？                 │
│ 贴出运行截图/日志作为完成证据。                    │
│ 然后 merge / PR / 清理 worktree。              │
└──────────────────────────────────────────────┘
    │
    ▼
 可交付的高质量代码

这 7 步环环相扣，每一步都是下一步的前置条件。跳过任何一步，后续质量都会打折扣。

---

四、实战教程：使用Superpowers 从零完成一个项目

废话不多说，下面我们使用腾讯的Cloud Studio作为云编程环境，opencode作为编程工具，完整走一遍 Superpowers 驱动的开发流程。

我们开发一个番茄钟（Pomodoro Timer）Web 应用——功能不复杂，但足够覆盖 Superpowers 的完整工作流。

5.1 第一步：安装 Superpowers

在 opencode 中安装 Superpowers 非常简单只用一条命令：

npx skills add https://github.com/obra/superpowers --agent opencode -g -y

安装完成后重启 OpenCode，在对话中输入 /superpowers，如果看到 brainstorm、write-plan、execute-plan 等命令列出来，说明安装成功[^1]。 此外，我也在腾讯的Cloud Studio中提供了一个集成opencode、claude、OpenCode和codex的一个环境，链接是： 大家只需要在.zshrc文件中配置一下API Key就好了，不过codex比较特殊需要配置godex。

5.2 第二步：Brainstorming——先想清楚再动手

启动一个新会话，输入需求：

「我想做一个番茄钟 Web 应用，帮我实现。」

有 Superpowers 加持的 OpenCode不会立刻写代码。它会触发 brainstorming Skill，用苏格拉底式提问探索需求：

brainstorming 模式：
在开始实现之前，我需要先和你确认几个关键设计决策：

1. 技术栈偏好？
   - 纯前端（React/Vue + localStorage）？
   - 还是需要后端（用户账号、数据同步）？

2. 核心功能范围？
   - 单计时器模式，还是支持任务列表？
   - 是否需要统计面板（今日完成数、专注时长）？

3. 视觉风格？
   - 极简风格，还是拟物化？
   - 是否需要暗色模式？

4. 还有什么我没有问到但你觉得重要的？

你逐一回答后， OpenCode会输出一份结构化设计文档。你在文档上确认「没问题，按这个做」，流程才进入下一步。

这个过程通常 5-10 分钟。

5.3 第三步：Writing Plans——拆成原子任务

设计确认后，writing-plans Skill 启动，将设计拆解为原子任务：

实施计划 —— 番茄钟 Web 应用

├── 任务 1：初始化项目结构
│   文件：package.json, tsconfig.json, vite.config.ts
│   验证：npm run dev 启动成功
│
├── 任务 2：实现计时器核心逻辑（useTimer Hook）
│   文件：src/hooks/useTimer.ts
│   验证：单元测试通过（25分钟倒计时、暂停/恢复、重置）
│
├── 任务 3：实现计时器 UI 组件
│   文件：src/components/Timer.tsx
│   验证：组件渲染测试通过，倒计时显示正确
│
├── 任务 4：实现任务列表功能
│   文件：src/hooks/useTasks.ts, src/components/TaskList.tsx
│   验证：CRUD 操作测试通过
│
├── 任务 5：实现统计面板
│   文件：src/components/Stats.tsx
│   验证：统计数据计算正确
│
└── 任务 6：集成测试 + 样式完善
    文件：src/App.tsx, src/styles/
    验证：端到端流程测试通过

每个任务 2-5 分钟可完成，有明确的文件路径和验证标准。这个粒度保证了任何一步出错都能快速定位和回滚。

5.4 第四步：TDD 执行——先看到测试失败

进入执行阶段，test-driven-development Skill 接管流程。以任务 2（计时器核心逻辑）为例：

// src/hooks/useTimer.test.ts —— 先写测试

import { renderHook, act } from '@testing-library/react';
import { useTimer } from './useTimer';

describe('useTimer', () => {
  it('初始状态为 IDLE，时间为 25 分钟', () => {
    const { result } = renderHook(() => useTimer());
    expect(result.current.status).toBe('IDLE');
    expect(result.current.remainingSeconds).toBe(25 * 60);
  });

  it('开始后状态变为 RUNNING', () => {
    const { result } = renderHook(() => useTimer());
    act(() => result.current.start());
    expect(result.current.status).toBe('RUNNING');
  });

  it('暂停后状态变为 PAUSED，恢复后继续', () => {
    const { result } = renderHook(() => useTimer());
    act(() => result.current.start());
    act(() => result.current.pause());
    expect(result.current.status).toBe('PAUSED');
    act(() => result.current.resume());
    expect(result.current.status).toBe('RUNNING');
  });

  it('倒计时归零后状态变为 FINISHED', async () => {
    // 使用较短的时间进行测试
  });
});

此时运行测试一定会全部失败（因为 useTimer 还不存在）。这正是 Superpowers 要的效果——先证明测试有意义（能检测到「没实现」），再开始写代码。

npm test -- useTimer.test.ts
# ❌ FAIL: useTimer is not defined

看到失败后，OpenCode 才开始写最小实现：

// src/hooks/useTimer.ts —— 最小实现

import { useState, useRef, useCallback } from 'react';

type TimerStatus = 'IDLE' | 'RUNNING' | 'PAUSED' | 'FINISHED';

export function useTimer(defaultMinutes = 25) {
  const [status, setStatus] = useState<TimerStatus>('IDLE');
  const [remainingSeconds, setRemainingSeconds] = useState(defaultMinutes * 60);
  const intervalRef = useRef<number | null>(null);

  const start = useCallback(() => { /* 实现 */ }, []);
  const pause = useCallback(() => { /* 实现 */ }, []);
  const resume = useCallback(() => { /* 实现 */ }, []);
  const reset = useCallback(() => { /* 实现 */ }, []);

  return { status, remainingSeconds, start, pause, resume, reset };
}

再次运行测试：

npm test -- useTimer.test.ts
# ✅ PASS: 4 tests passed

RED → GREEN 完成。如果代码有优化空间，还可以走 REFACTOR 步骤。

5.5 第五步：Code Review——阶段门检查

每个任务完成后，requesting-code-review Skill 自动触发。OpenCode 对照第三步的计划逐项核查：

Code Review —— 任务 2（useTimer Hook）

✅ spec compliance: 实现了 start/pause/resume/reset，符合计划
✅ code quality: 类型定义完整，useCallback 使用恰当
⚠️  minor: cleanup 函数在 unmount 时未清理 setInterval
✅ tests: 4 个测试用例覆盖核心路径

结论：添加 cleanup 后通过。

注意：这里的 review 是阶段门——不是走形式，而是真的阻断问题。如果发现了关键缺陷，任务不会进入下一步。

5.6 第六步：并行执行——多子 Agent 齐头并进

对于可以独立开发的任务（比如 UI 组件和统计面板），Superpowers 的 dispatching-parallel-agents Skill 会调度多个子 Agent 同时工作：

并行调度：
  ├── 子 Agent A → 任务 3（Timer 组件 UI）
  ├── 子 Agent B → 任务 4（任务列表功能）
  └── 子 Agent C → 任务 5（统计面板）

每个子 Agent 独立上下文、独立 worktree、独立 TDD 流程。
完成后统一合并。

5.7 第七步：验证收尾——贴出证据

全部任务完成后，verification-before-completion 要求提供实际运行证据：

npm test
# ✅ 22 tests passed
npm run lint
# ✅ 0 errors, 0 warnings
npm run build
# ✅ built in 3.2s

OpenCode 会展示测试通过记录、lint 零报错、构建成功的输出，而不是口头说「做好了」。

最后 finishing-a-development-branch 做标准化收尾——检查 commit message 规范、确认所有文件已提交、清理 worktree——然后合并到主分支。

---

六、效果对比：Superpowers 带来的真实变化

最反直觉的数据是：看似多花了 Token 在 brainstorm 和 plan 阶段，但因为减少了方向性错误的推倒重来，整体 Token 效率反而大幅提升。一次方向性错误导致的推倒重来，烧掉的 Token 远超设计阶段的「多余」消耗[^1]。

6.2 使用前后行为对比

场景	不用 Superpowers 时的 AI	使用 Superpowers 后的 AI
收到需求后	直接开始写代码	先提问、比较方案、确认设计
遇到 bug	凭直觉改代码，试几次再说	四阶段根因分析，3 次失败自动触发架构审查
实现完成	「做好了，应该没问题」	对照 Plan 逐项 code review
声称修好 bug	「修好了」	贴出复现步骤和修复后的运行截图
多模块开发	串行，上下文越长越歪	并行子 Agent，独立 worktree 隔离
提交代码	随便 commit	跑完 lint + test + commit 规范检查

---

七、多工具协作：Superpowers 跨平台作战

Superpowers 不是绑定某个特定工具的。它的四层架构天然支持多平台分发[^3]：

┌────────────────────────────────────┐
│  分发面：把能力装进不同 harness      │
│  .claude-plugin  .codex-plugin     │
│  .cursor-plugin  .opencode         │
│  gemini-extension.json             │
├────────────────────────────────────┤
│  强制面：入口文件确保 agent 守规矩    │
│  AGENTS.md  CLAUDE.md  GEMINI.md   │
├────────────────────────────────────┤
│  执行面：工作流、调试、测试、元技能    │
│  skills/ 目录                      │
├────────────────────────────────────┤
│  验证面：检查技能是否被遵守           │
│  hooks/  tests/                    │
└────────────────────────────────────┘

各工具安装方式

工具	安装命令	适用场景
Claude Code	/plugin install superpowers@claude-plugins-official	快速迭代、复杂重构
OpenCode	Agent 面板 → 插件 → Skill 管理 → 导入，或直接放入 .OpenCode/skills/	国内生态、全中文交互
Codex CLI	/plugins → 搜索 superpowers → 安装	长时无人值守、内核级沙箱
Cursor	Agent 聊天 → /add-plugin superpowers	IDE 内增强
Gemini CLI	gemini extensions install https://github.com/obra/superpowers	Google 生态

实操建议：按阶段分工

参考 HagiCode 的多工具编排思路[^7]，一个典型的「Superpowers + 多工具」协作模式：

[Claude Code]             [OpenCode]             [Codex]
  brainstorm ──────────▶ writing-plans ──────────▶ executing-plans
  需求澄清                 任务拆解                 批量执行
  架构设计                 设计文档优化             TDD + Review
                                                    长时运行

• Claude Code（上下文理解最强）→ 负责 brainstorm 阶段，深入探索需求和架构
• OpenCode（性价比高、中文友好）→ 负责 plan 拆解和设计文档优化
• Codex（代码精准、沙箱安全）→ 负责批量 TDD 执行和长时自动化

Superpowers 的 SKILL.md 在三个工具间格式兼容，核心指令不需要重写。

---

九、关于自己使用体验

说实话，因为工作原因我应该不算经常使用AI工具的原因，但是经过自己使用AI工具开发的经验来看，这个插件确实会让使用token数提升，但是由于需求做好了，后续编码阶段会比较顺利，所以整体Token的使用反而是下降的。而且最近我发现了grill-meskills好多人反馈比brainstorm阶段需求澄清比较好，我也正在测试，测试完有时间再写一个记录。

---

附录14 个核心 Skills 全览

除了 7 步主流程，Superpowers 还包含调试、审查收尾、元技能等完整环节。以下是全部 14 个 Skills 的职能矩阵[^5]：

入口层

Skill	一句话作用	触发时机
using-superpowers	每次会话启动强制注入——没走流程不让写代码	每次新会话自动触发

需求与规划层

Skill	一句话作用	核心价值
brainstorming	苏格拉底式提问，把模糊想法 → 结构化设计文档	消灭方向性错误
writing-plans	拆成 2-5 分钟粒度的原子任务，每步有文件路径 + 验证方式	把 spec 变成可执行清单

执行与隔离层

Skill	一句话作用	核心价值
using-git-worktrees	每个功能独立 worktree/分支，互不污染	实验失败不影响主线
executing-plans	按计划批量推进，设人工检查点	有序执行，不跳步
dispatching-parallel-agents	多子 Agent 同时干独立模块	并行加速
subagent-driven-development	子代理独立执行 + 两阶段审查	上下文隔离，质量把关

质量保障层

Skill	一句话作用	核心价值
test-driven-development	RED → GREEN → REFACTOR，必须有失败证明	杜绝「先写代码后补测试」
systematic-debugging	四阶段根因分析，3 次失败自动触发架构审查	不瞎改，找根因
requesting-code-review	对照 Plan 逐项核查	review 成为阶段门
receiving-code-review	接收审查意见并执行改进	审查→改进闭环

收尾与扩展层

Skill	一句话作用	核心价值
verification-before-completion	不让说「修好了」，必须贴运行结果作证	消灭口头完成
finishing-a-development-branch	测试全绿？lint 过了？commit 规范？→ 合并 / PR	标准化收尾
writing-skills	教你给项目写新 Skill	元技能，持续定制

每个 Skill 都可以独立使用，但组合起来才是 Superpowers 的完整威力——从需求到交付的端到端质量闭环。

---

参考资源

[1]: 告别 AI 编程「开盲盒」！226K Star 的 Superpowers 给 AI 装上了「工程纪律」

[2]: Superpowers 官方 GitHub 仓库 — obra/superpowers

[3]: Superpowers 深度解析：把 AI 编程助手纳入软件工程流程

[4]: Superpowers 完整指南 2026 — 5 条开发哲学与安装 FAQ

[5]: Superpowers 结合 Claude Code 浅实战《番茄钟》——14 个核心 Skills 详解

[6]: Superpowers 给 Claude Code 装上「工程大脑」：5 大核心工作流实测

[7]: 打造 AI 冒险团：HagiCode 多 Agent 协作配置实战

[8]: superpowers-zh：AI 编程超能力 · 中文增强版