使用技巧（六）：Superpowers 不是装了就能用！Claude Code 最强插件的 7 阶段工作流，配错了等于白装

Superpowers 不是装了就能用！7 阶段工作流逐帧拆解，从配置到实战

Windows/macOS/Linux · Superpowers v5.1.0 · Claude Code 2.x · 2026-05-10

一、装了 Superpowers，Claude 还是直接写代码？

你有没有遇到这个场景：

你：帮我做一个 Markdown 解析器 Claude：（触发 brainstorming） "在开始之前，我想先确认几个问题……" —— 20 分钟后，你签了一个设计文档 —— 30 分钟后，你收到一份 8 个任务的实现计划 —— 1 小时后，全部测试通过，代码已在 git worktree 里 你：？？？（这和我认识的 Claude 不一样）

Superpowers 是方法论，不是功能包。它不给你加新命令——它改变 Claude 的思考方式。

但它也不是万能的。装完什么都不管，它会过度干预简单任务（改个 typo 也要走计划）。配好了，才知道什么时候该让它管、什么时候该跳过。

这篇解决的就是"Superpowers 怎么配、怎么用、什么时候关"。

速览：七个阶段，三个环节

核心逻辑：不是每次都走完七步。Superpowers 根据任务复杂度自动决定触发哪些阶段。但它的默认行为偏"强制"——你需要知道怎么调。

二、安装：不只是装完就完了

基本安装

# 方式一：官方市场（推荐）/plugininstallsuperpowers@claude-plugins-official# 方式二：Superpowers 专用市场（可用相关配套插件）/plugin marketplaceaddobra/superpowers-marketplace /plugininstallsuperpowers@superpowers-marketplace

退出并重启 Claude Code。不需要手动配置——下次你说"帮我做一个功能"，Superpowers 自动接管。

验证是否生效

启动 Claude Code 后，直接说"帮我规划一个用户登录功能"。如果 Claude 回复的不是代码而是问题（“你想用 JWT 还是 Session？”“有没有现有的认证中间件？”），说明 Superpowers 已生效。

如果 Claude 直接开始写代码，说明没生效。检查：

# 确认插件已启用/plugin list|grepsuperpowers# 确认设置中有 enabledPluginscat~/.claude/settings.json|grepsuperpowers

安装后第一件事：试跑一次完整流程

不要拿玩具项目试。选一个真实需求——哪怕只是"给项目加一个健康检查端点"。完整的七阶段走一遍，你才能建立对其节奏的直觉。

Gautam Khorana（Superpowers 深度用户）的建议：“前 24 小时选一个真实项目（不是玩具），让框架完整跑一遍。读 README 不够，价值会随着使用而累积。”

三、逐阶段拆解：每一步发生了什么、你做什么决策

以下用"开发一个 Markdown 解析器"作为贯穿案例。

阶段 1：brainstorming — 需求澄清，不是选择题

触发时机：你说"帮我做一个 Markdown 解析器"时自动触发。

Claude 做什么：

• Socratic 式追问，把你的模糊想法变成具体设计
• 逐段输出设计文档（不是一次甩 5000 字），每段等你确认
• 如果发现你在描述多个独立子系统，会建议拆成多个子项目

实际对话流程：

你：帮我做一个 Markdown 解析器 Claude：[触发 brainstorming] "在开始之前，我需要先确认几个方向： 1. 你需要的解析深度是什么？ - 只转换标题、加粗、链接这些基础语法？ - 还是需要支持表格、脚注、GFM 扩展？ 2. 输入输出格式呢？ - 输入是 Markdown 字符串？ - 输出只要 HTML，还是也需要 AST？ ……" （你逐一回答） Claude："明白了，你的需求是： - TypeScript 库 - 输入 Markdown 字符串 → 输出 AST + HTML - 支持 CommonMark 标准 + GFM 表格 - 零依赖 这是设计文档的第一部分（数据结构设计）……" （逐段输出设计文档，每段等你确认）

你做决策的时刻：

• 每段设计文档出来后，你需要说"确认"或提出修改。这不是 Claude 自己猜——你在控制方向。
• 如果 Claude 把范围定得太大/太小，直接纠正。

输出：docs/superpowers/specs/2026-05-10-markdown-parser-design.md

技术细节：brainstorming 有一个 HARD-GATE——在你说"确认"之前，Claude 不会碰代码。这不是建议，是硬阻断。

阶段 2：using-git-worktrees — 隔离工作区，不污染主分支

触发时机：你确认设计文档后自动触发。

Claude 做什么：

• 创建一个 git worktree（/tmp/superpowers-worktrees/<branch>/）
• 在新 worktree 中运行项目 setup（npm install等）
• 运行现有测试确保基线是绿的

实际输出：

gitworktreeadd-bfeature/markdown-parser\/tmp/superpowers-worktrees/feature-markdown-parsercd/tmp/superpowers-worktrees/feature-markdown-parsernpminstallnpmtest# 确认 127 tests passing

你做决策的时刻：这一步基本不需要你参与。但有两个配置注意点：

• worktree 目录位置默认为/tmp/。如果你的项目很大或 SSD 空间紧张，告诉 Claude “把 worktree 建在 X 目录”
• 如果已经在干净分支上，可以对 Claude 说"直接在当前分支上做，跳过 worktree"

阶段 3：writing-plans — 拆成 2-5 分钟微任务

触发时机：worktree 就绪后自动触发。

Claude 做什么：

• 把设计文档拆成粒度极细的任务列表
• 每个任务 2-5 分钟，精确到文件路径和函数签名
• 先规划文件结构，再定义任务（避免回头改架构）
• 自审查：检查覆盖了所有需求、没有"TODO"占位、类型签名跨任务一致

实际输出（Markdown 解析器案例）：

# Markdown 解析器实现计划 ## 架构：管道模式（Tokenizer → Parser → Renderer） ## 文件结构： - src/types.ts — AST 节点类型定义 - src/tokenizer.ts — 词法分析 - src/parser.ts — 语法分析 - src/html-renderer.ts — HTML 渲染 - src/index.ts — 入口 ## 任务列表： 任务 1：定义 AST 类型（3 分钟） 文件：src/types.ts 内容：Document, Heading, Paragraph, Text, Bold, Italic, Link, CodeBlock, TableBlock 等类型 任务 2：实现 Tokenizer — 标题和段落（3 分钟） 文件：src/tokenizer.ts 输入：Markdown 字符串 输出：Token 列表 任务 3：实现 Tokenizer — 内联语法（3 分钟） ... （共 8 个任务，每个 2-5 分钟）

你做决策的时刻：审查计划，确认任务拆分是否合理。如果有任务范围太大（>5 分钟）或有遗漏的边界情况——现在指出。

红线：如果计划里出现 “TBD”、“implement later”、“TODO: error handling”，这是不合格的计划。Superpowers 的标准是计划里每一个字都必须可执行。

阶段 4：subagent-driven-development — 每个任务独立子代理

触发时机：你说"开始"之后自动触发。

Claude 做什么：

• 主代理（你现在对话的 Claude）变成"调度器"
• 每完成一个任务，启动一个新的独立子代理执行下一个
• 每个子代理有完整任务描述和文件上下文
• 两阶段审查：先看是否符合计划（spec compliance），再看代码质量

实际执行流程：

你说："开始" Claude：[调度器模式] → 子代理 1 执行任务 1（定义 AST 类型） → 审查：spec 合规 ✅ | 代码质量 ✅ → 子代理 2 执行任务 2（Tokenizer — 标题和段落） → 审查：spec 合规 ✅ | 代码质量 ⚠️（遗漏了 # 后面无空格的情况） → 自动修复补上 → 审查通过 ✅ → 子代理 3 执行任务 3…… （你可以切到其他窗口，1-2 小时后回来看结果）

你做决策的时刻：几乎不需要你参与。但审查阶段如果出现 critical 问题（比如子代理偏离了计划方向），Claude 会停下来等你判断。

技术细节：为什么用子代理？两个原因：

1. 上下文隔离：每个任务在干净上下文中执行，不累积干扰
2. 审查客观性：子代理 A 写的代码，主代理审查——不会"自己审自己"

阶段 5：test-driven-development — 强制红-绿-重构

触发时机：在每个实现任务内部自动触发。

Claude 做什么：

• 先写测试，跑一遍看它失败（红）
• 再写最小代码让测试通过（绿）
• 提交（重构在下一个循环）
• 如果 Claude 先写了代码再补测试，它会把代码删掉重来

实际执行（任务 2 案例）：

# 子代理：先写测试cat>src/__tests__/tokenizer.test.ts<<'EOF' test('parses H1 heading', () => { const tokens = tokenize('# Hello'); expect(tokens).toEqual([{ type: 'H1', content: 'Hello' }]); }); test('handles heading without space after #', () => { const tokens = tokenize('#Hello'); // 边界情况 expect(tokens).toEqual([{ type: 'H1', content: 'Hello' }]); }); EOFnpmtest-- tokenizer.test.ts# FAIL: 2 tests failed（代码还没写）# 子代理：写最小实现npmtest-- tokenizer.test.ts# PASS: 2 tests passedgitadd-A&&gitcommit-m"feat: tokenize headings"

你做决策的时刻：无。这一步全自动。但如果项目还没有测试框架，TDD 会卡住。补救：先对 Claude 说"先配好测试框架再开始"。

阶段 6：requesting-code-review — 对照计划审查

触发时机：每个任务的两阶段审查完成后。

Claude 做什么：

• 对照实现计划逐项检查
• 按严重程度分类：
  • Critical：偏离计划方向、破坏已有功能 → 阻塞进度
  • Warning：代码风格不一致、缺少边界测试 → 记录但继续
  • Info：命名建议、注释优化 → 记录但继续

实际输出：

### 任务 3 审查报告 ✅ Spec 合规：Tokenizer 输出符合计划定义 ⚠️ Warning：inline tokenizer 未处理转义字符 `\*` 建议：在后续任务中补上转义逻辑 💡 Info：tokenize 函数可考虑改为 generator 以支持流式处理

你做决策的时刻：Claude 会把 critical 问题列给你，等你说如何处理。大多数时候只需说"修"或"已知，跳过"。

阶段 7：finishing-a-development-branch — 收尾与决策

触发时机：所有任务完成后自动触发。

Claude 做什么：

• 跑完整测试套件确认全部通过
• 展示分支统计（提交数、修改文件数、新增行数）
• 给出四个选项：合并到主分支 / 创建 PR / 保留 worktree / 丢弃

你做决策的时刻：选一个选项。

四、完整实战：Markdown 解析器时间线

前置条件：Claude Code 2.x + Superpowers v5.1.0 + TypeScript 项目 +npm test可跑

时间线（实际约 1.5 小时，你参与约 15 分钟）：

00:00 你："帮我做一个 Markdown 解析器" Claude：[触发 brainstorming] 00:02 Claude 提出第一组 Socratic 问题 00:05 你逐一回答，确认范围 00:08 Claude 输出设计文档第一部分（数据结构） 00:10 你："确认" 00:12 设计文档完成 Claude：[触发 using-git-worktrees] 00:14 worktree 就绪，npm install 完成，测试基线绿 Claude：[触发 writing-plans] 00:22 8 个任务规划输出 你审查后："确认，开始" Claude：[触发 subagent-driven-development + TDD] 00:25 子代理 1：定义 AST 类型 → 审查通过 00:28 子代理 2：Tokenizer 标题 → 审查 ⚠️ → 修复 → 通过 00:33 子代理 3：Tokenizer 内联语法 → 审查通过 00:44 子代理 5：HTML Renderer → 审查通过 00:56 子代理 7：入口 index.ts → 审查通过 01:02 子代理 8：集成测试 → 审查通过 Claude：[触发 finishing-a-development-branch] 01:05 完整测试：142 passing（14 new + 128 existing） 01:07 分支统计：8 commits, 6 files changed, +450 lines 你："创建 PR" 01:10 PR 已创建

你实际做的工作：回答 3-4 个问题 → 审查一次设计文档 → 审查一次计划 → 选"创建 PR"。约 15 分钟。

五、配置调优：什么时候让它管，什么时候跳过

5.1 三种任务等级

Superpowers 内部按复杂度把任务分三级（社区版本REPOZY/superpowers-optimized在此基础上增加了自动路由）：

实际怎么用：在描述需求时带一句暗示。比如"改一个 typo（很小的改动）"——Claude 会自动选 micro 级别。不是命令开关，而是通过上下文路由。

5.2 跳过特定阶段

如果明确知道某个阶段不需要，直接告诉 Claude：

"我已经有设计文档了，跳过 brainstorming，直接从写计划开始" "这个改动很小，跳过 worktree，直接在当前分支上做" "这个项目还没有测试框架，先跳过 TDD，配好测试再补"

Superpowers 尊重这些显式指令。

5.3 两个配置优化

1. Worktree 目录位置

/tmp/在机械硬盘上很慢。告诉 Claude “把 worktree 建在 X 目录”，或用环境变量：

exportSUPERPOWERS_WORKTREE_BASE=/mnt/ssd/superpowers-worktrees

2. 全局启用

/plugininstallsuperpowers@claude-plugins-official--scopeuser

换机器不需要重新配，插件自动更新。

5.4 什么时候该关掉

• 纯探索（“帮我看看这个库的架构”）—— 不需要 TDD
• 紧急 bug（“生产 down 了，快找”）—— 跳过 brainstorming
• 文档写作（“帮我写 README”）—— 跳过审查

在这些场景下对 Claude 说"这是探索任务，不全流程走"——它理解。用两周，建立"什么时候让它管"的直觉。

六、常见问题

Q: 和 ECC/Night Market 冲突吗？

不冲突。Superpowers 是方法论层（“怎么做”），ECC 和 Night Market 是功能层（“做什么”）：

Superpowers：强制 TDD → 写计划 → 子代理 → 审查 ECC：增加多语言审查、安全扫描、文档更新 Night Market：增加 Git 自动化、PR 准备

Q: 子代理用的什么模型？

exportCLAUDE_CODE_SUBAGENT_MODEL=haiku# 省 token，适合简单任务exportCLAUDE_CODE_SUBAGENT_MODEL=sonnet# 默认推荐

Q: worktree 会越积越多吗？

finishing-a-development-branch自动清理已合并的。偶尔手动清理：

gitworktree listgitworktree remove /tmp/superpowers-worktrees/<old-branch>

Q: 改一个 typo 也要走全流程？

不需要。Superpowers 自动识别，单文件小改只跑简化 planning。如果没识别对，说"这是 micro 级别"。

七、收尾

一句话：Superpowers 把 Claude 从"会写代码的助手"变成"会按规矩干活的下属"——但你得知道什么时候让它管。

装完第一天，选一个真实项目功能走完七个阶段。两周后，这种纪律不再是约束，而会变成你的默认期望。

本文推荐安装速查

# 安装/plugininstallsuperpowers@claude-plugins-official# 全局启用/plugininstallsuperpowers@claude-plugins-official--scopeuser# 验证/plugin list|grepsuperpowers

本系列相关文章

• 上一篇：使用技巧（五）：插件市场全景游 —— Superpowers、Night Market、ECC 横向对比 — 三个市场定位与选型
• 下一篇：使用技巧（七）：MCP 服务器精选包 —— GitHub + Context7 + Playwright + PostgreSQL — 即将发布

扩展阅读

• Superpowers 官方 README — 完整的技能清单和工作流说明
• How I use obra/superpowers — Gautam Khorana 实战深度评测
• DeepWiki: Superpowers Configuration Files — 配置文件详解
• DeepWiki: Complete Workflow Pipeline — 三阶段管道技术文档

参考文献

1. obra/superpowers — GitHub — Superpowers 官方仓库，v5.1.0
2. How I use obra/superpowers — Gautam Khorana 实战评测（2026-05-06）
3. Superpowers: Configuration Files — DeepWiki — 跨平台配置文件详解
4. Superpowers: Complete Workflow Pipeline — DeepWiki — brainstorming → plans → SDD 三阶段管道
5. REPOZY/superpowers-optimized — GitHub — 生产级分支，增加安全 Hook、3 层路由
6. Superpowers: Composable coding-agent skills — Refft — 结构化分析