Superpowers v7.0.1 更新详解：常用命令、工作原理与使用流程，还值得安装吗？

让 AI 给后台加一个导出按钮，它很快写完接口、组件和测试。你打开一看，导出的是当前页，运营要的却是筛选后的全部数据；文件能下载，权限范围却没沿用原来的查询规则。

代码写得挺快，返工也来得挺快。现在用 AI Coding，难处越来越多地出现在这些地方：它理解的目标对不对，过程中有没有偏，最后拿什么证明做完了。

这也是我觉得 Superpowers v7.0.1 值得聊的原因。这次最主要的变化，发生在动手写代码之前的 brainstorming：项目重新设计了 Agent 应该怎样理解人的意图，以及理解之后该走多重的流程。

但问题也随之而来：模型已经越来越能干了，我们还需要安装一套告诉它“怎么干活”的插件吗？这篇我们从版本变化开始，把常用入口、原理和完整使用流程一起说清楚。

版本说明：本文以 Superpowers v7.0.1 为准，与上一代 v6.4.2 对比，统一介绍新版的变化和用法。资料核对截至 2026 年 10 月 25 日；示例为教学设计，未在所有宿主中逐一安装实测。官方更新日志

先认识它：Superpowers 到底给 Agent 加了什么

Superpowers 是给编码 Agent 使用的一套可组合 Skills 和开发方法。它把需求澄清、计划、测试、调试、评审等经验写成可读取的指令，再通过宿主的插件、技能发现和必要的辅助脚本接起来。

可以这样理解它和我们日常使用的几个东西的关系：

它没有给模型重新训练一遍，也不会凭空增加宿主没有的工具。安装以后最直接的变化，是 Agent 更有可能按一套约定的开发过程行动。官方项目说明

这里也要留一个边界：Skill 里的要求仍然需要模型理解和执行，不能等同于程序层面的强制约束。 写了“必须测试”，不代表 CI 已经配置好；写了“必须检查权限”，也不代表权限一定正确。重要规则仍应落实到测试、权限系统和自动化检查中。

对比 v6.4.2，v7.0.1 改了什么：把需求澄清重新放到前面

1. 先理解要做什么，再决定流程有多重

如果只看“v7 更重视用户意图”，很容易以为旧版只会闷头写代码。事实并非如此。

v6.4.2 的 brainstorming 已经要求理解目的、复述理解、区分用户输入与假设。它也已经有三条路径：可行性探索 spike、范围明确的改动 bounded、需要完整设计的 architectural。所以，分轻重处理任务并非 v7 才出现的功能。

区别在于旧版让 Agent 在第一次提问之前就分类，并把分类告诉用户；新版把理解需求放到前面，等目标清楚后再决定工作规模。v6.4.2 源文件

“加个导出”看起来很小，实际可能涉及十万条数据、异步任务、审计记录和租户隔离。也可能项目早已有导出接口，只缺前端入口。还没读代码、没了解用途就判断流程轻重，很容易判断错。

2. 提问更强调具体场景，减少过早给选项

v7.0.1 会先读取已有项目、规格和上下文，避免询问材料里已经有答案的事，再围绕真正缺失的信息提问。澄清过程鼓励用户描述真实场景：什么时候需要这个功能，现在怎样解决，哪些细节做错了最难接受。Agent 在过程中逐步复述理解，并明确标出自己的推测；用户卡住时再提供选项。

这对需求访谈很有价值。你问“要 CSV 还是 Excel”，用户可能马上选一个；你问“上一次为什么需要导出，拿到文件后要做什么”，才可能发现真实诉求是跨系统对账，字段、编码和数据范围比文件扩展名更关键。

不过，别把新版理解成“一定要聊很久”。v7.0.1 同时保留了清楚小任务直接处理、用户主动跳过提问等路径。v7.0.1 brainstorming

3. 设计检查改成站在实施者角度找缺口

新版对需要完整设计的项目使用 builder check，替代旧版的规格文档 reviewer。它让一个具有新上下文的子代理站在实际实施者的角度读设计，找出“如果现在开始做，还需要问什么”；小改动的短设计则不走这一步。

放到导出功能里，缺口可能是：是否沿用筛选条件、字段顺序是什么、超过上限怎么办、谁有权限下载。检查重点更贴近后续实施需要的信息。

同时，新版更明确地区分技术选择由谁决定。平台、语言、库等如果由用户指定，就需要遵守；交给 Agent 决定，则应说明默认选择，不能悄悄当成双方已经达成的共识。官方提到过一个具体教训：会话设计的是 iOS 应用，最后却实现成了 Web 应用。官方更新日志

4. 还有宿主适配和运行细节修复

相比上一代，新版增加 Antigravity 原生插件清单，并修复 Windows hook 发现、Git Bash 路径、Hermes 技能描述，以及可视化辅助页面中特定字符串的插入问题。

这些修复看起来没有新功能醒目，却直接影响 Skills 能否正确加载。插件安装成功和工作流真正触发，是两件需要分别检查的事。官方更新日志

5. 让规则在长会话中更可靠

v7.0.1 还拆分了几个较长 Skill 的内容。官方记录了 Claude Code 在上下文压缩后重新附加 Skill 时存在截断的情况：有会话因此丢失修复轮数上限，单个任务跑了 18 轮修复。新版将部分细则移到需要时读取的引用文件，并增加 Skill 大小检查。v7.0.1 发布说明

再完整的自然语言规则，如果在长会话中丢失，也无法发挥作用。所以，工作流设计除了说明该做什么，还得考虑规则能不能被持续读取。

把这次对比整理成一张表，会更直观：

这里有个容易误读的地方：轻量处理仍要匹配任务规模。 清楚的小任务可以直接处理；需要设计的小改动，在 v7.0.1 中保留短设计文档，项目则写完整设计。README 的概览可能落后于具体 Skill，实际使用应以当前版本的源文件为准。v7.0.1 brainstorming

为什么要这么改：旧流程开始妨碍它原本的目的

这部分可以直接看维护者在重写 PR 中给出的理由。

在 PR #2463 中，维护者认为 brainstorming 逐渐偏向了任务路由、审批门槛和文档交接，真正引出用户意图的内容反而被挤到了很小的位置。

PR 还公开了项目内部的观察：旧行为在一组测试中频繁用流程术语开场，简单改图标颜色也会变成一段设计说明再请求确认；多轮会话里，选项菜单可能把模拟用户带向“听起来合理、却偏离真实目的”的答案。这些属于项目自己的评估，不能直接当成所有用户的实际体验，但足以解释此次重写的动机。

我的理解是，维护者遇到了流程工具常见的一个问题：最初为了减少错误而加的步骤，后来逐渐成了它衡量“工作有没有做好”的标准。于是，Agent 很认真地分类、写文档、等确认，却没有认真理解这件事究竟要解决什么。

模型越强，这种矛盾越明显。它有能力迅速完成许多小任务，如果插件还让它先讲一遍流程，用户很容易觉得自己在帮工具完成任务。

这次改版值得关注的地方，是它开始重新审视流程本身带来的成本。 至于改得是否足够好，还得继续看实际使用。

常用命令：先别照抄旧版的三个入口

安装命令在哪执行

下面按官方 README 给出两个常见宿主的例子。聊天输入框里的斜杠指令和系统终端里的命令不能混用，也不需要把两种安装来源都装一遍。

Claude Code：在 Claude Code 会话中安装。

/plugin install superpowers@claude-plugins-official

也可以使用项目自己的 marketplace：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Antigravity：在系统终端执行。

agy plugin install https://github.com/obra/superpowers

其他宿主请走对应的安装入口；不同工具的插件体系和更新方式有差异。安装后新开会话，检查已安装版本，再用一个小任务观察技能是否触发。以上命令来自官方安装说明，具体安装包版本仍以宿主显示为准。

现在主要调用 Skill

旧教程里的 /brainstorm、/write-plan、/execute-plan 已在 v5.1 移除，替代的是 superpowers:brainstorming、superpowers:writing-plans、superpowers:executing-plans。这项变化早于 v7，不应算作本次更新。官方移除记录

下表给的是 Skill 标识和聊天示例。它们不是终端可执行程序；宿主是否显示带 / 的补全入口，以实际界面为准。拿不准时，可以在自然语言里明确点名 Skill。

另外几项适合按阶段使用：superpowers:using-git-worktrees 准备隔离的工作区，superpowers:requesting-code-review 发起检查，superpowers:receiving-code-review 处理评审反馈，superpowers:finishing-a-development-branch 收尾开发分支。它们都是已有技能，不是 v7 新增功能；具体用途可查官方技能清单。

日常不必逐个手动点名。using-superpowers 的作用之一，就是让 Agent 先识别应使用的技能，并优先采用澄清、调试这类决定做事方法的技能。技能入口规则

诊断 Skill 则适合处理“计划被忽略”“一直重跑”“花费异常”等会话问题。它读取会话记录并引用具体文件与行号，帮助查明发生了什么；单凭一次异常，不能认定插件就是原因。诊断技能说明

工作原理：指令、上下文和工具怎样接在一起

先看各部分怎样配合。下图是便于理解的概念分层，Skill 由模型读取，实际操作通过宿主工具完成。

第一步是让宿主发现技能。技能文件的 name、description 提供名称与适用场景，具体流程写在 SKILL.md 中。模型选择相关技能后，读取对应内容，再用宿主提供的工具完成工作。

部分宿主还通过会话 hook 注入引导内容。例如 v7.0.1 的 hooks/session-start 会读取 using-superpowers/SKILL.md，转义后装进宿主接受的上下文字段。这段代码做的是把技能使用规则送进会话。会话启动脚本

不同宿主不一定走相同机制。v7.0.1 的 Antigravity 适配就依靠技能发现触发引导，因此不能用“所有平台都有同一个启动 hook”来解释它。

进入实施后，规格和计划把已经决定的事保存下来；执行过程中的记录帮助恢复进度；测试结果和评审结果则提供检查依据。这些材料能降低长会话完全依赖聊天记忆的风险。

以 writing-plans 为例，它要求计划保留实施者无法自行推断的决定：文件、接口、具体值、测试断言和验证命令。简单实现不必在计划里把函数体全部写出来。这种瘦身在 v6.4.2 已经出现，延续到了 v7。计划技能源文件

因此，一份有用的计划应该让后续实施更确定；如果它只是比需求长很多，却没写清验收条件，文档再多也帮不上忙。

跑一遍流程：给后台增加 CSV 导出

下面用一个教学案例，把几个技能连起来。假设项目已有客户列表、筛选和权限系统，运营希望导出数据做对账。

第一步：说清目的，留下最关键的开放问题

可以这样开始：

用 superpowers:brainstorming 帮我梳理客户列表的 CSV 导出。
运营要把筛选后的结果交给财务对账。
请先读取项目现有的列表查询、筛选和租户权限实现。
沿用当前技术栈，只问会改变实现方案的缺失信息。

读过代码后，值得澄清的是“导出当前页还是全部筛选结果”“通常有多少条”“财务需要哪些字段”。项目里已经明确的框架、权限入口和代码风格，就不应再让用户重复回答。

假设最终确定：导出全部筛选结果、沿用租户权限、固定六个字段、暂不支持后台异步导出，并为同步导出设置明确上限。这里的每项决定都会改变实现和验收，所以值得保留下来。

第二步：确认设计，再生成能执行的计划

这里值得停一下：设计文档说明系统怎样组成、为什么这样选；实施计划说明接下来改哪些文件、按什么顺序完成和验证。 两者解决的问题不同，不能用一张待办清单替代设计。

下面是一份配套的精简架构设计示例。字段、接口和上限是为本文补充的教学约定，不代表某个真实项目已验证的配置。实际使用时，应让 Agent 根据仓库现状整理，再由你确认关键决定。

客户 CSV 导出：精简架构设计

目标与范围。 运营下载当前筛选条件下的全部客户，供财务对账。导出沿用现有访问范围，支持空结果；本次不做异步任务、历史文件存储和自定义字段。

模块与职责。 前端负责收集筛选条件、发起下载和展示状态；导出接口负责身份、导出权限和参数校验；查询服务复用列表的租户及数据访问规则；CSV 模块只处理固定字段映射与文本编码，不自行决定谁能看哪些数据。

接口与数据约定。 示例采用 POST /api/customers/export，请求体使用现有筛选结构，不接受客户端指定租户，也不使用列表页码限制结果。租户和访问范围由服务端登录上下文确定。成功响应为 UTF-8 CSV，设置附件下载文件名；六个固定字段为客户 ID、客户名称、状态、负责人、创建时间、更新时间，时间统一输出 UTC 的 ISO 8601 格式。空结果只返回表头。

关键决策与取舍。 先采用同步下载，减少队列和文件存储的维护成本。示例暂定最多 10,000 条，查询在相同权限范围内最多读取 10,001 条，发现超限就返回错误，不截断成一份看似完整的文件。这个上限只是示例值，上线前要结合行大小、内存、耗时及网关超时验证；如果实际数据规模超出同步处理能力，再设计异步导出。

文本处理。 对逗号、双引号和换行按 CSV 规则转义；文本字段去除前导空白后若以 =、+、-、@ 开头，示例策略是在原字段前加单引号，再做 CSV 转义。该策略会改变原始文本表示，因此需要财务确认，并在实际使用的表格软件中验证按文本打开；若文件还要供程序导入，应另行确认数据保真要求。

异常与交互。 未登录返回 401，无导出权限返回 403，筛选参数错误返回 400，超过条数上限返回带稳定错误码的 422。前端下载期间禁止重复点击；失败后恢复按钮、展示具体原因并保留筛选条件。服务端查询失败时不返回成功文件。

验收边界。 至少覆盖跨页结果完整、越权数据不可见、空结果、恰好达到上限与超限、特殊字符和公式样式文本。还要在浏览器验证下载，在财务实际使用的表格软件中验证文件打开效果。

这份设计把影响行为的决定写清楚了，却没有预先展开每个函数的实现。对于这个小改动，短设计确认后即可进入计划；如果扩展为带队列、存储和通知的完整项目，再补充组件间交互、任务状态和失败恢复，并按前文的流程做设计检查。

接下来再调用计划技能：

按刚才确认的设计使用 superpowers:writing-plans。
把查询权限、CSV 转义、接口返回、前端下载拆成可验证任务。
列出确切文件、测试断言和验证命令。

比如，上面的“复用访问范围”会拆成查询服务改动和跨租户测试；“超限不返回文件”会拆成边界查询、错误响应和前端提示。设计中的每个关键约定，都应该能在计划里找到落实它的任务和检查。

这时应该能看到需求与实现的对应关系。例如“全部筛选结果”需要验证数据超过一页时仍完整；“沿用租户权限”需要验证其他租户的数据不进入结果；“CSV 正确”需要验证逗号、引号、换行以及表格软件相关的输入风险。

这些是本例的工程验收建议，Superpowers 不会自动替你补齐所有领域规则。尤其涉及敏感数据时，业务负责人仍需要确认导出字段与访问边界。

第三步：按成本和检查需要选执行方式

v7 可使用两条实施路径：

前者的源文件直接解释了为何采用当前会话实施：减少每个任务重新付出实施者、评审者读取上下文的成本。后者则强调新上下文实施和逐任务检查，最终还要做整个分支的检查。子代理开发技能

这个导出需求如果范围清楚，可以先选当前会话实施；如果跨越多个相对独立的模块，又希望逐项独立检查，则考虑子代理方式。子代理数量并不能直接代表交付质量，也不意味着所有任务都能安全并行。

第四步：让测试证明改动解决了问题

TDD 在这里的关键，是先写出行为测试，观察它因为目标行为尚未实现而失败，再实现到通过。比如先证明超过一页的筛选结果没有全部导出，再修改导出查询。这样才能知道测试确实能捕捉这个缺陷。TDD 技能

遇到下载乱码、权限遗漏或 CI 失败时，再进入 systematic-debugging：读完整错误、稳定复现、检查近期变化、提出可验证的根因假设。一次改三种猜测，很难知道究竟哪项修复起了作用。系统化调试技能

第五步：交付时给证据和剩余边界

交付前使用 superpowers:verification-before-completion。
执行本项目实际存在的测试、类型检查和构建命令。
报告导出范围、权限、字段转义的验证结果。
说明浏览器下载和目标表格软件打开文件是否已实测。

“已补测试”只说明文件发生了变化；“测试通过”需要当前运行结果；“运营可以使用”还涉及下载交互与文件打开。不能把这些状态合并成一句“已完成”。

verification-before-completion 要求先确定什么命令能证明结论，再执行、读完整输出，并根据证据报告状态。对我们来说，最实用的习惯就是：结论说到哪一层，证据就跟到哪一层。 完成前验证技能

模型越来越强，还有必要安装吗

我的判断是：它仍然有价值，但已经不适合被当成每个人、每个任务都必须安装的默认答案。

强模型减少了很多“怎么写”的困难，却不会自动知道你没有说出口的业务目的。它可能很熟练地写出同步导出，而你的真实问题是大批量异步任务；也可能代码都写对了，但你希望的只是解释问题，根本没打算改仓库。

另一方面，模型和宿主已经能完成的事，也没必要再靠冗长说明重复一遍。流程越多，上下文、等待、文档维护和确认的成本就越明显。若它提供的主要是你本来就会遵守的提醒，收益自然有限。

下面是我的使用建议，并非官方收益承诺：

尤其不建议同时堆几套都要求“必须先规划、必须再评审”的工作流。重复步骤未必增加发现问题的机会，却会增加协调成本。把目标、项目规则和检查责任说清楚，比插件数量更重要。

怎样判断它在你这里有没有用

找几类难度相近的小任务，在相同模型、相近上下文和同等工具权限下，比较使用与不使用工作流的结果。至少记录四项：总耗时、消耗、人工纠正次数、最终缺陷和验收结果。

不要只看写代码用了几分钟。多花五分钟澄清，少返工半小时，有价值；多聊十轮却没有解决一个真正的不确定点，就该减流程。同一任务第二次执行还会受到已有答案影响，别把这种练习效应当成插件带来的提升。

写在最后：先判断你缺的到底是哪一环

看完 v7.0.1，我更愿意把这次变化理解为一次工作方法的校正：需求澄清需要回到人的真实目的，同时也要读取已有上下文、尊重清楚的请求，并控制流程本身的负担。

如果你准备用它，先挑一个有明确验收条件的小功能试试。确认当前版本，别再照搬旧命令；把需求、计划和验证连起来，看看它有没有提前发现遗漏。如果已经有成熟的项目流程，就从最薄弱的一环开始。值得留下的流程，应该让你少返工、少猜测，并且更容易判断交付是否可靠。

参考资料

• Superpowers v7.0.1 发布说明
• Brainstorming 重写的动机与评估：PR #2463
• v6.4.2 brainstorming 源文件
• v7.0.1 brainstorming 源文件
• 安装方式与项目概览
• 历史更新记录：旧命令移除、执行和计划演进

本文基于官方发布说明与源码阅读；有关是否安装、成本取舍和案例验收的建议属于作者分析，不代表已完成跨宿主效果评测。