Superpowers 入门科普：把“会写代码的 Agent”变成“按流程交付的软件工程师”（重点：brainstorming 技能）

低调小一

1372人浏览 · 2026-04-14 12:08:13

低调小一 · 2026-04-14 12:08:13 发布

Superpowers 入门科普：把“会写代码的 Agent”变成“按流程交付的软件工程师”（重点：brainstorming 技能）

摘要（先看结论）

Superpowers 不是“更长的提示词”，而是一套面向编码 Agent 的工程化工作流：用可组合 skills 把“从想法到代码交付”的过程拆成强约束步骤，降低随机游走和返工。[1]
你能得到的最直接收益：在动手写代码前先拿到可读的设计（design/spec），再拿到可执行的实施计划（plan），最后用多 Agent 分工 + TDD + Code Review 把计划落实。[1]
最核心的起手式是 brainstorming：它强制你在任何实现动作前先做需求澄清、给出 2–3 个方案权衡、分段展示设计并获得确认，然后写入设计文档并进入计划阶段。[2]
上手方式很轻：在支持插件/扩展的工具里安装 Superpowers；然后只要你提出“要做一个功能/改一个行为”，它就会把你拉回到“先设计后实现”的轨道。[1]

这项目解决了什么问题

写代码的 Agent 很容易“看起来很能干，但交付很脆”：

直接开写：没搞清约束就写实现，最后发现边界条件不满足，只能推倒重来。
没有中间产物：用户（或你自己）很难在“还没写代码”时检视方案，问题只能在代码里暴露。
缺少工程节奏：测试、评审、拆任务、隔离分支这些步骤在 Agent 身上经常变成“可选项”，导致质量不可控。

Superpowers 的思路是：把这些“工程节奏”固化为一组会自动触发的 skills，形成一条强约束流水线。[1] 你可以把它理解为：给 Agent 装上一套“流程护栏（guardrails）”，让它更像一个遵循工程方法的软件工程师，而不是一个只追求快速输出的代码生成器。

产物长什么样（心智模型）

Superpowers 的“产物”不是一个库或框架 API，而是一次次可审阅、可回滚、可验证的交付过程：

用户一句话需求
     |
     v
brainstorming：澄清 + 方案对比 + 设计分段确认
     |
     v
design/spec 文档（可阅读、可讨论、可复用）
     |
     v
writing-plans：拆成可执行的小任务（含文件路径、验证步骤）
     |
     v
subagent-driven-development：多 Agent 分工实现
     |
     v
test-driven-development + requesting-code-review：测试与评审护栏
     |
     v
finishing-a-development-branch：收尾、验证、交付/合并选择

把它和“只让 Agent 写代码”对比，会更直观：

传统：想法 -> 代码（中间没有稳定检查点）
现在：想法 -> 设计 -> 计划 -> 实现 -> 测试/评审 -> 交付

快速上手（最小可复现）

下面给两条最短路径：一条用 Claude Code 插件市场（最快验证），一条用 Codex 的技能发现机制（更贴近“skills 框架”的本质）。

路线 A：Claude Code 插件（最快体验）

在 Claude Code 里安装插件：[1]

/plugin install superpowers@claude-plugins-official

验证安装是否生效（关键不是“装没装”，而是“能不能触发 skill”）：[1]

新开一个会话
问一句会触发流程的问题，例如：help me plan this feature 或 let's debug this issue

如果你想“强制体验 brainstorming”，可以直接提出一个明确的构建请求，例如：

“我想做一个把 CSV 转成 JSON 的命令行工具，我们先做设计再写代码。”

路线 B：OpenAI Codex（用技能发现机制装起来）

让 Codex 按官方指引安装：[1] [3]

Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md

2)（可选）如果你要用多 Agent 的执行技能，打开 Codex 的 multi_agent feature：[3]

[features]
multi_agent = true

路线 C：Trae（用 skills 组合复刻 Superpowers 的节奏）

Trae 不一定“原生带 Superpowers 插件”，但你完全可以用它的 skills 体系，把最关键的工程节奏复刻出来：先澄清与设计，再拆计划，再实现与评审。

准备：在 Trae 打开你的代码仓库，并确保能用 skills（如果你还没装/没用过 skills，先看这篇指南：blog/ai/skills-openclaw/trae/find-skills-install-and-use-in-trae.md）。
触发 brainstorming（用提示词硬门禁，先设计不写代码）：在对话里直接这样说：

我要做一个功能：<一句话需求>。
先做 brainstorming：请先问清关键约束，并给出 2-3 个方案对比 + 推荐方案。
在我确认设计前，不要写任何代码，不要生成脚手架，不要输出具体实现细节。

固化 spec（把对话产物写成可复用文档）：让 Trae 把确认后的设计整理成一份 spec.md（你可以用 markdown-refiner 把讨论稿整理成结构化 Markdown），至少包含：

目标与非目标（scope）
输入/输出与边界条件
成功标准（验收/指标）
风险点与回滚策略（如果有）

写 plan（把 spec 变成“可执行任务清单”）：让 Trae 输出一个实现计划，要求每条任务都包含：

要改哪些文件（路径）
如何验证（命令/测试/检查点）
完成条件（done definition）

实现与评审（把流程护栏跑完整）：实现完成后，用 TRAE-code-review 做一次代码审查；需要提交时用 git-quick-commit 只提交本次相关变更。

关键机制（深入但不晦涩）

只抓 3 个你最该理解的机制点：为什么它能让 Agent “更像工程师”。

1) Skills 不是“建议”，而是“强制门禁”

Superpowers 的 README 明确写了：当 Agent 识别到你在“要构建东西”时，它不会直接写代码，而是先把你带进 spec/plan 的节奏里。[1]

其中 brainstorming 甚至写了一个硬门禁（HARD-GATE）：在设计获得批准前，不允许调用实现型 skill、不允许写代码、不允许脚手架、不允许做任何实现动作。[2]

这对 Agent 非常关键：它把“先写点东西再说”的冲动变成了“先把设计说清楚再动手”的强约束。

2) “分段展示设计 + 每段确认”降低沟通成本

brainstorming 不要求你一次性把所有细节都想清楚，它更像一个“交互式设计评审”：

先理解上下文与目标
一次只问一个关键问题
给 2–3 个方案对比（并推荐）
把设计按复杂度切成几段展示，每段都问“是否正确”[2]

这解决了两个常见问题：

设计太长没人看：分段确认，强制可读。
需求变更晚才出现：每段确认，尽早暴露分歧。

3) 设计文档与计划文档把“过程”变成“可复用资产”

brainstorming 规定：设计通过后要写入 spec 文档（默认路径 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md），并进入 spec review loop；然后才进入 writing-plans。[2]

对团队来说，这意味着：

你不是“让 Agent 帮你写了一次代码”，而是沉淀了可复盘的设计决策。
下一次相似需求，先复用 spec/plan，再实现。

brainstorming 技能：你应该怎么用（带一个完整示例）

下面用一个“非常典型、但容易返工”的需求做演示：做一个 CSV→JSON 的命令行工具。

1) 它会怎么问问题（一次一个，逼你把关键约束说清）

你输入：

我想做一个把 CSV 转成 JSON 的命令行工具。

brainstorming 的典型追问会围绕“目的 / 约束 / 成功标准”展开：[2]

Q1：目标用户是谁？（你自己/团队/开源）
Q2：输入 CSV 的规模与编码？（MB/GB，UTF-8/GBK）
Q3：输出 JSON 形态？（数组/按列映射/按主键聚合）
Q4：错误处理怎么做？（遇到坏行跳过/失败退出/记录行号）
Q5：成功标准是什么？（速度/内存/可读性/兼容性）

这种“一次一个问题”的节奏，是为了避免把你丢进一长串问卷里而失焦。[2]

2) 它会给出 2–3 种方案，并让你选

举例（简化版）：

A) Python 脚本：最快写完，适合小文件/内部用
B) Node CLI：生态好，适合前端团队与跨平台分发
C) Go 单文件二进制：性能好、部署简单，适合大文件与 CI
推荐：如果你要在 CI 里批处理大量数据，选 C；如果只是个人工具，选 A。

重点不在“推荐哪个”，而在“你在写代码前就做了 trade-off”，返工率会显著下降。

3) 它会把设计分段给你确认（一个可复用的设计模板）

你可以期待它输出类似这样的设计分段（你每段都能说“对/不对/改哪里”）：[2]

设计 1/4：CLI 形态
- 命令：csv2json <input.csv> --out <output.json>
- 可选：--delimiter ,  --header true/false

设计 2/4：数据模型
- 默认：输出 JSON array，每行一个 object
- header=false 时：按 column_1, column_2 命名

设计 3/4：错误处理
- 行解析失败：记录行号到 stderr，默认跳过；--strict 则直接失败退出

设计 4/4：测试与验证
- 用 3 组 fixture：正常/缺列/包含引号与逗号
- 验证：输出 JSON 可被 jq 解析；strict 模式对坏行必须失败

4) 它把“要不要用可视化”当成一个明确的开关

如果接下来会讨论 UI、布局、图形化交互，brainstorming 要求先单独征求你是否启用 Visual Companion（浏览器展示草图/对比图）。并且这条消息必须“只包含征求同意”，不能夹带其他问题。[2]

这很像产品评审里的“要不要开白板”，减少了无效的视觉输出成本。

示例与行业案例：把“模糊想法”变成可交付的工程节奏

案例：团队内部工具自动化（可迁移套路）

背景：你们有很多重复的“数据格式转换/日志清洗/批量校验”小需求，工程师经常临时写脚本，几周后没人敢改。
方案：用 Superpowers 把这类需求固定成“先设计、再计划、再实现”的短闭环：brainstorming 把需求边界说清；writing-plans 把任务拆到可验证；TDD 把脚本变成可长期维护的工具。[1] [2]
落地关键步骤：
- 统一输出 spec/plan 的存放位置与命名规则（方便复用与检索）
- 明确每个小工具的“成功标准”必须在 brainstorming 阶段写进设计
- 强制每个任务都有验证命令（例如 jq、fixture 对比、退出码）
风险/边界：
- 如果需求本质是探索性研究（没有明确成功标准），brainstorming 依然有价值，但设计可能需要允许“分阶段验证”，否则会陷入过度设计。
- 如果你没有测试文化，TDD skill 的硬门槛可能让流程推进变慢；建议先从“关键路径有测试”开始。

常见坑与排障

按“现象 → 原因 → 检查点 → 修复”来。

1) 现象：Agent 直接开始写代码，没有先做设计

原因：Superpowers 没有正确安装/加载；或你在对话里提出的请求不够“像是在构建东西”，触发条件没被命中。[1]
检查点：
- 按 README 的方式重新验证安装：新开会话，问一个会触发 skill 的问题。[1]
- 直接点名：明确说“先 brainstorm 再写代码”。
修复：
- 重新安装插件/扩展；确保是在支持的平台上按对应方式安装。[1]

2) 现象：设计讨论很顺，但总感觉“没产出”，下一次又从头聊

原因：没有把设计写成可复用文档，或者文档没有进入 review gate。
检查点：
- brainstorming 明确要求：设计通过后写入 spec 文档并提交，再进入后续阶段。[2]
修复：
- 固化 spec 的存放位置，并把它纳入日常协作（比如 PR/评审的输入）。

3) 现象：讨论 UI/交互时，Agent 反复输出大段文字，难以对齐

原因：视觉问题用纯文本沟通成本高。
检查点：
- brainstorming 有 Visual Companion 的专门机制，需要先征求同意再使用。[2]
修复：
- 启用 Visual Companion，把关键布局/对比图用可视化方式讲清，再回到文本做约束与验收标准。

参考资料

Superpowers 仓库与 README：https://github.com/obra/superpowers
brainstorming skill 原文（SKILL.md）：https://github.com/obra/superpowers/blob/8ea39819/skills/brainstorming/SKILL.md
Superpowers for Codex 文档：https://github.com/obra/superpowers/blob/main/docs/README.codex.md