强制流程也会被重写：Superpowers 四个月从 v5.1 进化到 v6.4

插件市场当然显眼，但 Superpowers 真正改的是编码对话的起手式。任务一旦开始，agent 不该直接写代码，而是先过需求澄清、设计确认、计划拆分、隔离工作区、TDD 和 review 这些环节。README 里那句 “Mandatory workflows, not suggestions” 说的就是这个意思：这些步骤是默认路径，不是点缀。

更有意思的是它接下来的走向。这套强制流程没有停在"发布即定型"：2026 年 6 月的 v6.0.0 把每个任务两轮的审查压成一轮，9 月的 v6.4.2 把"计划里写满代码"改成了"计划只记录决策"。重写的依据不是品味，是评估——官方把技能丢进真实项目里反复跑分，哪个环节又贵又容易被钻空子，就重写哪个环节。把官方 README、v6.4.2 仓库源码和 Jesse Vincent 的发布公告放在一起看，能看清两件事：skills 定义动作，入口提示决定这些动作何时必须触发；而 hooks 和评估负责盯着它们有没有在真实任务里被跳过、被绕开。

如果把这套系统压成一张最小地图，大致会是下面这样：

图里步骤看着不少，真正有用的是这些阶段门。设计没确认，就不该开始拆任务；没有干净基线，就很难判断一次修改到底有没有把问题带进来；测试没先失败一次，后面的通过也缺少约束。Superpowers 做的事很具体：把这些门一道一道摆在前面，逼着 agent 少走捷径。

这篇文章真正要回答什么

1. Superpowers 到底更像插件包，还是一套能落到执行环节的软件工程方法。
2. 为什么它要把 brainstorming、worktree、TDD 和 review 放在默认路径里，v6 又为什么要重写其中两环。
3. 第一次上手时，该看哪些信号，才能判断它是真的接管了流程。

它管的是开发过程里的失控点，不是模型上限

很多 coding agent 的问题，并不出在能力上限，而是出在默认行为。需求还没讲清楚就开始实现，代码写完才想起补测试，做到一半跳过 review，最后用一句"已经完成"收尾。这些失误在人类工程师身上也常见，只是模型把它们放大了。

Superpowers 对准的正是这类失控点。它要让 agent 在有时间压力、已有沉没成本、上下文不完整的情况下，仍然按工程流程走，而不是把 agent 变成更会写某种框架的专家。

这一点也是 Superpowers 和"把提示词写长一点"的区别。后者主要影响回答内容，前者直接改 agent 的工作顺序。

先把这套系统拆开来看

stars 读数顺带交代一句：发文时的 2026 年 5 月中旬，仓库约 19.6 万 stars（Internet Archive 5 月 18 日快照为 196,043）；到本次复核的 2026 年 10 月，已经到约 29.5 万。

如果再往下拆，这套系统至少有四个层面：

容易被安装步骤盖住的一点是：安装只是分发，真正起约束作用的是强制面和执行面。插件市场解决的是"怎么装进去"，skills 和入口引导解决的是"装进去以后 agent 会不会真的照做"。

另外，README 明确写了一个部署边界：如果你同时用多个 harness，需要分别安装。Superpowers 不是"一次安装，全平台生效"的全局层。

为什么技能才是主角，而不是插件市场

把 Superpowers 看成"高级提示词"只说对了一半。更贴近事实的理解是：它把一组工程动作做成了运行时规程，要求 agent 在合适的时点按顺序执行。

先看触发时机。README 写得很直白：agent 会在每个任务前检查相关 skills。也就是说，skill 首先是入口，不是卡住时翻出来的补充材料。

再看 skill 本身的形状。像 test-driven-development、systematic-debugging、verification-before-completion 这几类内容，里面不只是几句建议，通常还带着前置条件、检查清单和退出标准。v6.2.0 还专门做了一轮文本压缩：把面向读者的推销段、回顾段全部删掉，每条还能影响行为的论证都折进"合理化借口对照表"（rationalization table）或挪到使用点上——因为读这些技能的不是人，是正准备抄近路的 agent。

发布公告里还有一层常被忽略的设计：这些 skill 会被丢进时间压力和沉没成本都很高的场景里反复测试。原因很实际。容易失守的是"系统正在烧钱"“代码已经写了 45 分钟"这种时刻，不是演示环境。多平台支持当然重要，但它服务的是同一件事：让这套规程在不同 harness 里接管相同的工作流。

七步主工作流，才是 Superpowers 的骨架

README 的 Basic Workflow 一共七步，顺序也很重要。很多介绍只记住 brainstorming、planning 和 TDD，实际少掉的那几步恰好是把流程从"好建议"变成"能落地"的部分。

这一套顺序里，有三个细节值得特别记住。

第一，subagent-driven-development 的审查方式在 v6.0.0 整个换过一遍。早先每个任务跑两个 reviewer，先看 spec compliance、再看 code quality；v6.0.0 起换成单个 task-reviewer-prompt.md 把任务 diff 读一遍，同时给出两个 verdict（规格符合度 + 质量），一次修复同时清掉两类问题，跑完后只在最强模型上做一次全分支审查。配套的约束也变硬了：reviewer 只读、禁止 controller 唆使 reviewer 忽略某条发现或预先定级、diff 和任务文本改用 task-brief / review-package 脚本走文件而不是贴进上下文、每次派发必须声明所用模型。README 技能索引里那行"two-stage review"至今没改，以 release notes 和源码为准。

第二，executing-plans 不再是摆设。v6.4.1 的发布说明坦白：这个技能此前只是个 64 行的 stub，实测效果"和不装插件一样"。重建后的它成了正经的 Native 模式——同一个会话里按与子代理模式相同的 workspace、台账和停止规则执行，最后派一次全分支审查。现在计划交接到手时会给出两种方式、各自代价，并基于计划内容推荐一种。

第三，using-git-worktrees 放在 brainstorming 之后，而不是一开始就建工作区。原因很简单：在需求还没定下来之前，隔离分支只是形式；设计一旦确认，隔离工作区立刻就变成了验证与回滚的边界。位置上还有一处变化：worktree 从全局目录改落在项目内——优先复用已有的 .worktrees/ 或 worktrees/，没有就新建 .worktrees/。

计划怎么写，v6 前后也换过标准。README 至今保留着那句流传很广的要求——implementation plan 要清楚到"一个热情但品味不佳、没有判断力、没有项目上下文、而且不爱测试的初级工程师"也能照着执行——但 v6.4.2 的 writing-plans 技能已经把它换成了"一个知道精确接口和测试就能写出地道代码的工程师"，任务粒度也从"2 到 5 分钟"改成"一个有可检查结果的动作"。配套的结构变化更实质：计划必须带 Global Constraints 块（逐字复制约束，保证传到每个执行者和审查者）和每任务的 Interfaces 块（声明消费和生产什么），并且记录的是签名、测试断言、规格取值这类决策，而不是把代码全文抄进计划——官方复现某次报告时发现，某些前沿模型会在写计划时顺手把整个项目实现了，新写法下计划耗时缩到四分之一、token 约三分之一。README 的滞后不碍事：装进 agent 的是技能源码。

一次真实任务，如何流过这套系统

官方用同一个任务验收所有新接入的 harness：让 agent 做一个 React Todo List。v5.1.0 的发布说明写明了验收标准——干净会话里说这句话，必须自动触发 brainstorming，并要求提交完整会话记录。这个例子不复杂，但足够看清 Superpowers 的运行方式。

假设你输入一句：

Let's make a React todo list

在没有 Superpowers 的普通对话里，agent 往往会立刻开始搭项目、写组件、生成样式，顺手替你假设状态管理、数据持久化和交互范围。

Superpowers 生效时，更合理的路径会是下面这样：

1. brainstorming 先分级：请求被分成 spike（可行性问题，产出是结论不是代码）、bounded（仓库里已有代码上的小改动，对话里给几句话的短设计）、architectural（新项目、新子系统，走提问、比较方案、分段设计、书面 spec 的完整流程）三档，分档结果会当场说出来供你否决。一个从零开始的 React todo list 项目，官方技能原话点名归入 architectural——完整走 spec 与计划交接。无论哪一档，动手实现前都会停下来等你确认设计。
2. 设计得到确认后，using-git-worktrees 才进入隔离工作区，并检查当前仓库是不是干净基线。
3. writing-plans 把事情拆开：先搭骨架，再写列表交互，再补存储，每步写清接口、文件和验证方式，而不是把代码写进计划。
4. 你说 “go” 之后，按推荐选 subagent-driven-development 或 executing-plans 推进实现。
5. 每个实现步骤里，test-driven-development 要求先写失败测试，再写最小实现。
6. 子代理模式下，每个任务完成后 requesting-code-review 立刻把关键问题拦下来，不让它滚到后面的步骤。
7. 全部完成后，finishing-a-development-branch 统一验证，并让你决定是合并、开 PR、保留 worktree 还是丢弃。

把这条路径走顺以后，你会发现 Superpowers 的收益是"把一次编码请求变成了一个可管理、可回看、可复查的工程过程"，不是"更会写 React"。

这些技能是按压力场景打磨，再按评估数据重写的

Jesse Vincent 在 2025 年 10 月的发布公告里专门写了两类测试场景。一类是"生产系统正在出故障，每分钟都在烧钱"；另一类是"你已经花了 45 分钟把东西做完，而且它现在能跑"。这两类场景抓得很准，因为它们刚好对应模型最容易偏离流程的两个时刻：时间压力和沉没成本。

这也解释了为什么 Superpowers 的入口提示会写得那么硬。像"如果有 skill，就必须用 skill"“先去查技能再行动"这类措辞，看起来近乎啰嗦，但它们是为高压下的偏航写的，不是为演示写的。公告里最值得记住的是这一层设计意图：skill 必须在"最想跳过它的时候"仍然能起作用。

v6 把这层设计又推进了一步：压力测试升级成了成规模的评估。官方在 v6.0.0 的说明里给出过一组自述数字——审查重写后，Claude Code 和 Codex 在他们的评估里以大约一半的 token、约两倍的速度拿到相近的质量；writing-plans 的新写法在植入缺陷探针上 9/9 全过。这些数字出自官方自己的评估，没有独立复现，参考即可；但"用评估决定重写哪一环"这个机制本身，比任何单个数字都更能说明这个项目的迭代方式。

Skill 库里真正重要的，不只是那七步

主工作流之外，README 把 15 个技能分成四组。这个分类很有帮助，因为它说明 Superpowers 不只管实现，还管调试、审查和技能自身的维护。

diagnosing-superpowers 是 v6.4.1 新增的：会话出现重复劳动、无视计划、技能没触发、账单异常时，直接让 agent “figure out what went wrong with superpowers in this session”，它会读磁盘上的会话记录，逐条给出 path:line 级证据，还能打包一份脱敏材料用于提 issue。调试技能调试这套流程自身，这个自指位置相当实用。

这也是它和普通"提示词仓库"的根本差别。后者大多停在内容层，Superpowers 已经把设计、实现、调试、审查和收尾装进同一套运行机制里。

安装与支持平台：看的是边界是否清楚，不是命令多少

README 安装节现在列了 16 个 harness，这里挑常用的几个，完整清单以 README 为准：

平台清单本身有一段值得知道的反复：Google 在 2026 年 6 月 18 日宣布 Gemini CLI 停止维护，Superpowers 在 v6.1.0 随即移除了对它的支持，v6.2.0 又认定"移除过早"并恢复了安装文档——快速跟进外部变化的项目，也会有跟错需要回退的时候。

安装命令本身不难，真正需要记住的是两个边界。

第一，安装方式因 harness 而异。Superpowers 是一套要嵌入不同宿主工具的技能体系，不是一个统一二进制。

第二，如果你同时使用多个 harness，需要分别安装。这个细节官方写得很明白，也很容易被忽略。

还有一个安装页面不会主动提醒的细节：brainstorming 的可选视觉伴侣（visual companion，一个随对话打开的小型 web 服务器）默认会从官方站点加载 Prime Radiant 的 logo，请求里带当前 Superpowers 版本号，官方说明不含项目、提示词或 agent 信息。介意的话设置环境变量 SUPERPOWERS_DISABLE_TELEMETRY 即可关闭，Claude Code 侧的 DISABLE_TELEMETRY 与 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 也会被尊重。这是 README 末尾"Visual companion telemetry"一节的原话口径，采用前值得读一遍。

什么时候值得上，什么时候没必要上

Superpowers 的成本主要在流程，不在安装。它会让 agent 慢下来：先问、先拆、先测、先审，再继续。这对中等以上复杂度的任务通常是赚的，对极小任务则未必——v6.3.0 之后，官方自己也承认这一点，brainstorming 会把请求分级，小任务直接跳过完整的两文档仪式。

所以，Superpowers 不是"任何任务都更好"的默认答案。它更适合有维护成本的开发任务；如果拿去覆盖所有对话，只会显得笨重。

更实际一点说，它最适合两类团队：一类已经认同 spec、TDD、review 这些动作重要，但执行总是不稳定；另一类已经开始让 agent 处理多文件、多轮修改，吃过"写得很快，返工更多"这种亏。它并不能替团队补上工程共识。如果项目里本来就没有测试、没有分支纪律，也不打算认真 review，那把这套流程装进去，多半只会把现有混乱写成更正式的样子。

第一次采用，建议按这个顺序落地

1. 先只在你最常用的一个 harness 里安装，不要同时铺开多套入口。
2. 选一个中等复杂度的小功能做第一次验收，最好满足"有 Git、有测试、至少改 2 到 3 个文件"这三个条件。
3. 第一次只盯三个核心信号：brainstorming 有没有先问清需求，writing-plans 有没有把任务拆到"一个动作一个可检查结果”，test-driven-development 有没有真的先看到失败测试。
4. 这三步稳定以后，再把 using-git-worktrees、subagent-driven-development 和 requesting-code-review 纳入日常流程。
5. 如果某一步没有出现，先查安装和入口注入是否生效，不要急着下结论说"Superpowers 没用"。

这个顺序的好处是，你先验证最核心的收益：agent 有没有从"直接开写"变成"先理解、再规划、后实现"。这件事成立了，后面的并行子 agent、worktree 和分支收尾才值得继续推。

装好了却没感觉，通常卡在这 4 处

不少人第一次装完 Superpowers，会先得出一个误判：代码照样会生成，于是觉得"好像没什么变化"。这种判断常常下得太早。变化主要出现在流程里，不会总是体现在第一屏输出上。如果你装完以后觉得 agent 还是老样子，通常先查这 4 处。

1. 你给的是不是一个真正的"开始任务"信号。README 和发布公告都强调，只有当 agent 识别到你在启动一个项目或具体任务时，它才会默认进入 brainstorming → plan → implement 这条链。问一句语法、改一行文案、补个小样式，往往看不到整套工作流。
2. 会话是不是重新开始了。发布公告里专门提到，Claude Code 安装后要退出并重启，才能看到注入的 session-start prompt。对其他 harness 来说，逻辑也是一样的：入口没重新加载，再完整的 skills 也不会先于对话接管流程。
3. 当前目录是不是 Git 仓库，而且基线是否足够干净。using-git-worktrees 的可见信号依赖 Git 环境；如果你根本不在仓库里，或者当前工作区已经混着一堆未整理改动，隔离工作区与基线验证这两个环节就不容易显出来。
4. 你看的是不是结果而不是过程。Superpowers 最先改变的通常是对话形态，不是代码质量：先问问题、先产 spec、先拆 plan、先让测试失败，再继续实现。如果你判断它有没有生效时只盯着"代码写得快不快"，很容易错过真正的接管信号。

反过来看会更容易判断：如果 agent 一上来就直接实现，没有澄清、没有计划、没有失败测试、没有阶段性 review，那多半还没进入 Superpowers 的节奏。实在拿不准，让 agent 跑一遍 diagnosing-superpowers，用证据代替猜测。

如果还拿不准，用这 3 个问题检查

1. 如果 agent 一上来就开始实现，你最先该怀疑的是安装没成功，还是入口引导没有把 skill 检查放在任务之前？
2. 为什么 using-git-worktrees 出现在 design approval 之后，而不是 brainstorming 之前？
3. v6.0.0 为什么要合掉两个 reviewer？单审双判省下的成本和可能漏掉的问题，分别落在哪里？

如果这 3 个问题都能回答清楚，基本就已经抓住了 Superpowers 的主线：它要解决的是"怎么让 agent 少走错路"，不是"怎么让 agent 多干活"——而且它愿意用评估数据重写自己已经发布的答案。

最后的判断

如果只把 Superpowers 当成一个插件，很容易低估它。现在并不缺会写代码的 agent，缺的是能把设计、测试、review 和收尾守住的 agent。Superpowers 补的正是这块，而且 v6 这四个月证明它补的方式还在进化：审查从两轮收到一轮，执行模式从单一变成双选，计划从抄代码改成记决策。

如果你遇到的主要问题是 agent 爱抢跑、计划写得粗、测试总在最后、做完就急着宣告成功，那它值得试。反过来，如果当前任务只是临时脚本或一次性修改，这套流程就未必划算。

我会把 Superpowers 看成一套把"靠自觉完成的工程动作"改成默认值的框架。它让 agent 在该慢的时候慢下来，而不是让 agent 看起来更聪明。对已经开始依赖 agent 做正经开发的团队，这比再追一轮提示词技巧更有复利。

参考资料

• obra/superpowers
• Superpowers: How I’m using coding agents in October 2025
• Superpowers demo transcript
• Releases · obra/superpowers（v6.0.0 至 v6.4.2 发布说明）