AI 写代码总返工?Superpowers 让编程助手先想清楚再动手

现在的 AI 编程工具，写代码已经不算难了。

真正麻烦的是另一件事：它们写得太快。

需求还没问清楚，代码已经改了；测试还没跑，Agent 已经宣布完成；中途发现方向不对，又在原来的改动上继续打补丁。最后看起来省了半小时，收拾残局却要花掉半天。

Superpowers 想管住的就是这种“先写再说”。

项目地址：https://github.com/obra/superpowers

一句话概括：

Superpowers 是一套给 AI 编码 Agent 使用的软件开发方法论。它把需求澄清、方案设计、任务拆解、测试驱动开发、代码审查和分支收尾写成可组合的 Skills，让 Agent 按一套固定流程做事。

它不是模型，不是 IDE，也不会替代 Claude Code、Codex 或 Cursor。更准确地说，它像是装在这些 Agent 外面的一套“工程纪律”。

截至 2026 年 8 月 21 日，GitHub 页面显示该项目约有 27.49 万 Star、2.46 万 Fork，最新版本是 8 月 12 日发布的 v6.3.0，采用 MIT 许可证。

它到底是什么

Superpowers 的核心是一组 Markdown 格式的 Skills，以及让不同编码客户端发现并调用这些 Skills 的插件配置、脚本和初始指令。

每个 Skill 负责一类具体工作。例如：

• • brainstorming：写代码前先理解需求，比较方案，拿到用户确认。
• • writing-plans：把设计拆成带文件路径、实现细节和验证步骤的任务。
• • test-driven-development：执行 RED、GREEN、REFACTOR，先看到测试失败，再写最少代码让它通过。
• • systematic-debugging：先找根因，再讨论修复，不允许靠连续试错碰运气。
• • subagent-driven-development：把独立任务交给新的子 Agent，每项任务完成后再审查。
• • verification-before-completion：交付前运行验证，用结果证明“确实修好了”。
• • finishing-a-development-branch：测试通过后，处理合并、PR、保留分支和 worktree 清理。

这些 Skill 不是供人阅读后自行参考的普通文档。安装完成后，Agent 会根据任务判断该调用哪一个，并把其中的规则当作工作约束。

所以它和一份“AI 编程提示词大全”差别很大。

提示词大全通常告诉 Agent 某个时刻该说什么，Superpowers 则试图规定一个软件需求从想法到交付应该按什么顺序推进。

一次完整开发会怎么走

假设你对 Agent 说：

给现有后台增加一个支持断点续传的文件上传功能。

没有流程约束的 Agent 可能会直接搜索上传接口，然后开始改代码。

Superpowers 的标准路径更像一名谨慎的开发负责人在带项目。

第一步是 brainstorming。Agent 会先判断任务属于临时验证、小范围修改，还是涉及接口和架构的较大改动，再询问文件大小、存储位置、失败重试、权限校验等问题。方案得到确认前，不进入实现。

接着，它会创建隔离的 Git worktree，避免新功能污染当前工作目录，然后把设计拆成足够小的实施任务。官方要求计划写清文件路径、代码内容和验证命令，目标是让一个不了解项目背景的人也能照着执行。

进入编码后，Agent 按 TDD 写失败测试、实现最小改动、重新运行测试。任务如果适合拆分，可以交给多个子 Agent；每项工作结束后还要检查是否符合规格和代码质量要求。

最后，它会跑完整验证，再让你选择合并、创建 PR 或保留分支。

这套流程的价值不在于每一步都新鲜。需求评审、测试、Code Review、分支隔离本来就是成熟团队会做的事。Superpowers 做的是把这些习惯翻译成 Agent 能读取并反复执行的规则。

哪些场景适合用

从模糊想法开始做新功能

你只有一句“我想做一个团队知识库”，但数据结构、权限、搜索方式和部署方案都没想好。这时最怕 Agent 自己补齐所有空白，然后交付一个方向完全不同的成品。

Superpowers 会先把问题问清楚，给出候选方案，再形成设计和实施计划。对于新项目、新模块和会影响公共接口的改动，这层刹车很有用。

处理跨文件、跨模块的改造

数据库迁移、认证系统替换、框架升级、大范围重构，通常包含很多彼此关联的步骤。只靠一段长对话推进，Agent 很容易漏文件、忘验证，或者在上下文变长后偏离最初目标。

计划、任务账本、独立 worktree 和阶段性审查，可以把这种长任务变得更可追踪。

排查难复现的 Bug

AI 很擅长快速提出五种修复方式，却不一定愿意证明根因是哪一个。

systematic-debugging 要求先收集证据、追踪数据流、缩小问题范围，再做最小修复。对于偶发错误、并发问题和多层调用链，比“改一下看看”靠谱。

让多个 Agent 并行工作

当计划里有多项相互独立的任务时，Superpowers 可以调度新的子 Agent 分别实现，再由审查 Agent 检查规格和质量。主 Agent 保留全局上下文，负责协调和最终验收。

这个模式适合测试补齐、多个独立接口、批量迁移等工作。任务之间耦合太紧时，强行并行反而会制造冲突。

给个人或团队统一 AI 开发习惯

同一个模型，换个人提示，工作方式可能完全不同。有人要求先写方案，有人让它直接动手；有人看测试结果，有人看到“已完成”就结束。

Superpowers 提供了一套公开、可修改的默认流程。团队可以以它为起点，再补充自己的目录规范、提交规则和上线检查项。

它的优势

解决的是流程问题，不是继续堆提示词

Superpowers 最有价值的地方，是它承认“模型会写代码”和“模型能稳定交付软件”是两回事。

它把容易被 Agent 跳过的环节设成硬门槛。例如 brainstorming 明确要求，在用户批准方案前不能开始实现；交付前必须拿出新的测试结果，不能用“应该没问题”代替验证。

规则拆得细，可以按任务组合

调试时加载调试 Skill，写计划时加载计划 Skill，做代码审查时再加载审查 Skill。Agent 不必在每次对话里背着一份超长系统提示词。

这种拆法也方便修改。你不认同某条工作规则，可以直接查看对应的 SKILL.md，而不是猜一个黑盒 Agent 为什么这么做。

覆盖的客户端多

官方 README 已列出 Claude Code、Codex App、Codex CLI、Cursor、Devin CLI、Gemini CLI、GitHub Copilot CLI、Kimi Code、OpenCode、Pi、Hermes Agent 等安装方式。

各客户端底层能力并不完全相同，但同一套开发方法可以在多个工具间复用。频繁切换 AI 编程工具的人，不用每换一个客户端就重新整理工作流。

对长任务更友好

隔离分支、细粒度计划、任务级审查和最终验证，会增加前期成本，却能降低长任务做到一半后失控的概率。

尤其是子 Agent 模式，每个执行者只拿到当前任务需要的上下文，不必继承整段混乱的历史对话。主 Agent 则把注意力放在协调、审查和处理冲突上。

开源，可审计，也允许商用

项目使用 MIT 许可证。Skills、脚本、插件配置和测试都在仓库里，个人与团队可以检查规则、复制修改或集成进自己的工作流。

它的缺点

小任务也可能显得啰嗦

Superpowers 对“先确认再实现”很执着。当前 brainstorming 会把任务分成临时验证、小范围修改和架构改动，简单任务可以不写完整规格文档，但用户确认这一步仍然不能跳过。

如果你只是想改一句文案、调整一个常量，或者做一段用完就扔的原型，这套流程可能比任务本身还重。

项目也在处理这个问题。v6.1.0 专门压缩了每次会话都会加载的引导内容，v6.3.0 又让需求讨论的流程随任务规模缩放。说明维护者知道仪式感和 Token 成本不能无限增加。

子 Agent 和多轮审查会消耗更多时间与 Token

subagent-driven-development 的默认做法是每项任务派一个实现 Agent，再进行任务审查，最后还要做一次分支级审查。质量检查更密，账单也更长。

仓库的 issue #2054 给过一个具体案例：在一份 14 项任务的计划中，部分完整审查耗时约 5.5 到 9 分钟，并产生 40 到 67 次工具调用。这个数据只是单次用户测量，不能代表所有项目，但足以说明审查本身也需要优化。

如果模型价格高、任务很碎，或平台的子 Agent 能力有限，成本会很明显。

Skills 仍然是“软约束”

大部分规则最终还是自然语言。Agent 可能漏掉 Skill、误判触发条件，或者在长对话中不再严格遵守。

issue #2051 就记录过一个例子：Agent 在进入 brainstorming 后，没有在对话中途重新检查另一个已经满足触发条件的项目 Skill。

所以 Superpowers 可以提高流程一致性，却不能把概率模型变成确定性的 CI 系统。测试、静态检查、权限控制和人工审查仍然要保留。

它对“正确开发方式”有明显偏好

项目把 TDD、YAGNI、DRY、系统化调试和证据优先写进了默认方法论，而且措辞很强。

这套偏好适合业务系统和长期维护的代码，不一定适合所有工作。数据探索、UI 试验、一次性脚本、遗留系统抢修，未必都能舒服地套用严格的测试先行。

如果团队本身不认可这些原则，安装后会经常和 Agent 拉扯。先修改 Skills，往往比每次临时要求它破例更省事。

不同客户端的体验并不完全一致

官方要求：如果同时使用多个编码客户端，需要分别安装。不同客户端对 Skills、插件 Hook、子 Agent 和任务列表的支持也有差异，Superpowers 只能做适配，无法抹平底层能力差别。

它还会在项目里使用 .superpowers 目录保存部分工作状态。issue #1991 指出这个位置目前不能统一配置，对于已经有固定临时目录规范的团队，会多一点清理和适配工作。

有一项默认网络请求需要留意

brainstorming 的可选视觉辅助功能会从 Prime Radiant 网站加载 Logo，并带上 Superpowers 版本，用于粗略统计使用量。官方说明请求不包含项目、提示词或点击内容，也可以通过 SUPERPOWERS_DISABLE_TELEMETRY 等环境变量关闭。

对出网严格的公司环境，安装后应先检查这类默认行为和插件权限。

怎么安装

Superpowers 已经适配了很多客户端，安装方式并不统一。

Claude Code 可以直接从官方插件市场安装：

/plugin install superpowers@claude-plugins-official

Codex App 可以在侧边栏打开 Plugins，在 Coding 分类里找到 Superpowers；Codex CLI 则输入：

/plugins

搜索 superpowers 后选择安装。

Cursor 可以在 Agent 对话里输入：

/add-plugin superpowers

安装后不需要背一套斜杠命令。你照常把开发任务交给 Agent，相关 Skill 会根据任务触发。第一次使用，建议拿一个边界清楚、已有测试的小功能试跑，观察它如何提问、写计划、建 worktree 和验收，再决定是否放进日常项目。

短评

如果你对 AI 编程最不满意的是“它经常没想清楚就开始写”，Superpowers 值得试。

它不会让模型突然变聪明，也不会替你做技术决策。它做的是更朴素的事：让 Agent 在动手前说明准备怎么做，开发中留下可检查的过程，结束时拿测试结果说话。

代价同样清楚。流程会变慢，Token 会增加，某些任务会觉得管得太多，而且自然语言规则不可能百分之百执行。

我的判断是：小修小补未必需要它，复杂功能、长期维护项目和多 Agent 协作更能体现价值。把它当成默认答案不合适，把它当成一套可修改的工程基线，反而更实用。

关注我，持续拆解好用的 AI 编程工具、开源项目和 Agent 工作流，帮你把“能写代码”变成“能稳定交付”。

觉得这套方法对你有用，可以先收藏，也可以转发给那个正在让 AI 直接改代码、却总被返工折腾的朋友。