Superpowers：AI 编程 Agent 的工程化操作系统

如果你用过 Claude Code、Cursor 或 Copilot 做正经开发，你一定碰到过这种场景：Agent 吭哧吭哧写了 500 行代码，编译通过、逻辑没毛病，但两周后你发现它完全没考虑异常处理、没写测试、架构选择跟你团队规范南辕北辙。不是 Agent 不聪明，是它没有方法论约束。

大部分 AI 编程工具的配置方式是在项目里扔 Markdown 文件写规则——CLAUDE.md、.cursorrules、.windsurfrules。跟 Superpowers 这套硬约束工作流放在一起对比，两者的差异不是程度问题，是范式问题。规则文件是被动参考，Agent 可以读也可以忽略。本质上是靠 Prompt Engineering 来约束 Agent 行为，效果取决于你写了什么、Agent 读了什么、模型当时的心情。

Superpowers 走了另一条路。它不是规则文件，是一套硬编码的工作流引擎。当你对 Agent 说”重构这个模块”，它不会直接改代码，而是触发一个强制 7 步流程：先脑暴需求、再创建工作树隔离环境、写执行计划、子 Agent 驱动实现、TDD 强制测试、代码审查、分支收尾。每一步有明确的输入输出和质量门禁，不通过就回退。12.8 万 Stars 的数字背后，是开发者对 AI 编程质量的集体焦虑。

说白了这篇文章想讲一件事：这套方法论能不能让你的 Agent 从”代码打字员”变成”靠谱工程师”，以及代价有多大。

打动我的几个地方

Superpowers 的设计有一条贯穿始终的逻辑线：让 Agent 无法跳过工程流程。不是”建议你做 TDD”，是”你不做 TDD 就别想提交”。

强制 7 步工作流是它和所有 Agent 配置方案最根本的区别。从 brainstorming（苏格拉底式提问精炼需求）到 finishing-a-development-branch（合并或 PR 决策），每一步都是必选项。Agent 在任何任务前自动检查当前场景适用的技能，而不是等你说”先想想再写”。这个设计把”写代码之前先想清楚”从你的习惯变成了系统的刚性约束。

流程本身看着不复杂，但真正有区分度的是它的不可绕过性。传统的 Agent 配置可以跳过步骤——你让它写测试，它可以先写代码再补测试。Superpowers 的设计不允许这样。brainstorming 没完成，writing-plans 不触发；TDD 的红灯没亮，绿灯就不能走。

TDD 在这里不是”推荐实践”，是硬约束。test-driven-development 技能强制 RED-GREEN-REFACTOR 循环：先写失败测试、看它确实失败、写最小代码通过、提交。还附带了反模式参考——比如”别为了覆盖率写无意义的测试”。注意，这不是教你 TDD，是逼你做 TDD。对于习惯了 AI 一把梭写代码的开发流程，这是个巨大的习惯冲击。

v6.0 的重写把审查机制做成了实打实的效率优化。旧版每个任务跑两个独立审查 Agent，一轮约 25 分钟，Token 消耗巨大。新版合并为一个审查器，同时输出规范合规和代码质量两个裁决，且审查器变为只读模式，不再触碰工作树。据 v6.0 的 evals 测试数据，同等质量结果的速度提升约 2 倍，Token 消耗减少近 50%。审查从形式主义变成了可量化的效能优化。

14 个技能覆盖了软件开发的完整生命周期，分成四个类别。

规划类管”想清楚”——brainstorming 和 writing-plans；

执行类管”做对”——subagent-driven-development、executing-plans 和 test-driven-development；

验证类管”确认对”——requesting-code-review 和 verification-before-completion；

协作类管”不互相踩脚”——using-git-worktrees、finishing-a-development-branch 和 dispatching-parallel-agents。

外加两个元技能 writing-skills 和 using-superpowers 负责教你扩展系统本身。

所有这些设计的核心关键词不是”智能”，是”强制”。Superpowers 对 Agent 的基本态度贯穿始终：不要信任，要验证。

但设计归设计，实际装上跑起来是什么感觉？

跑起来看看

Superpowers 不是 pip install 那种工具库，它是 Agent 技能包，安装方式取决于你用的编程 Agent，目前覆盖了 Claude Code、Codex、Copilot、Gemini、Kimi Code、Pi、Antigravity、OpenCode 和 Cursor 这 9 个主流平台。

最主流的路径是 Claude Code 官方市场安装，一行命令搞定：

/plugin install superpowers@claude-plugins-official

Copilot CLI 用户走插件市场安装，Gemini CLI 和 Kimi Code 也都有原生支持，分别是 gemini extensions install 和 /plugins install。

安装后不需要额外配置。Agent 在每次任务启动时自动加载 using-superpowers 引导技能，然后按场景匹配对应的技能。你不需要记住 14 个技能名——Agent 自己做判断。比如检测到你要改代码但项目里没有测试文件，自动触发 test-driven-development。

从 Issue 区的反馈来看，踩坑集中在两个地方。

一个是旧版 worktree 管理会把工作树放在 ~/.config/superpowers/worktrees/，和用户已有的 Git 工作流冲突，v5.1.0 已修复，统一迁移到项目内 .worktrees/ 目录。

另一个是 v5.0 时代的子 Agent 审查太慢，每轮约 25 分钟，v6.0 重构后降到了 2-3 分钟。

当前版本（v6.0.3）还有个临时文件路径的问题：SDD 的进度账本存在 .superpowers/sdd/ 目录，git clean -fdx 会把它清了，不过可以通过 git log 恢复。

装好了，用不用得上？这是下一个要回答的问题。

什么时候用，什么时候别用

这张表格能帮你快速判断 Superpowers 是不是你的菜：

不适用的情况也很明确。你只是想用 AI 快速生成一个一次性脚本，装 Superpowers 反而拖慢节奏。你的项目已经有成熟的 CI/CD 和代码审查流程，Superpowers 的约束层会跟你现有流程产生双重检查。你用的编程 Agent 不在支持的 9 个平台里，需要自己移植 Harness。

有件事比功能列表更值得想：Superpowers 的最大价值可能不在这些技能本身，在迫使你思考”我的开发流程应该是什么样”。即使你最后不用它，看一遍它的 7 步工作流和 TDD 强制机制，对自己的 AI 编程习惯也会有重新审视。

不过功能说得再清楚，一个开源项目能不能长期用，还得看社区的健康度。

社区怎么样了

先说数据。截至 2026 年 6 月，Superpowers 有约 12.8 万 Stars，609 次提交。从 2026 年 2 月的 v4.3 到 6 月的 v6.0.3，不到四个月迭代了 6 个大版本，肉眼可见的活跃。

Bus Factor 偏低是最大的风险点。项目由 Jesse Vincent 和他的同事 arittr 两人核心推动，Jesse 是主力。但他的背景让人放心——Prime Radiant 创始人，对开源的投入是持续的，目前已经在招 Superpowers 社区工程师。不过如果他突然停下来，14 个跨平台技能的维护不是其他贡献者能轻松接手的。

社区质量两极化严重。维护者对最近 100 个已关闭 PR 做了一次审计，结果是 94% 的拒绝率。原因不是维护者苛刻，是贡献者的 PR 质量太低：没读 PR 模板、重复 PR、伪造问题描述。维护者明确声明”一般不接受新技能贡献”。这种态度在开源社区少见，但从质量控制角度看完全合理——14 个技能要跨 9 个平台保持一致，乱加东西会破坏整个系统的可靠性。

社区讨论集中在 Discord，Issues 区更偏 bug 报告和功能请求。从 Issue #1778 和 #1774 的讨论风格来看，维护者回复快、态度直接、不回避技术债——比如 evals 子模块的发布策略有问题，v6.0.2 果断从主仓库移除，没找借口。这种坦诚在开源项目中不多见。

数据看完了，我得给出我自己的判断了。

我的真实看法

我对 Superpowers 的核心判断是：方向绝对对了，但不要神化它。

方向对，是因为 AI 编程的瓶颈已经从”Agent 能不能写代码”变成了”Agent 写的代码能不能进生产”。在这一点上，Superpowers 是目前唯一一个把软件工程方法论做成硬约束的开源方案。常见的替代方案如 CLAUDE.md 和 .cursorrules 是软约束——Agent 主动读、可选择性遵守。Superpowers 是硬约束——Agent 被动触发、不可跳过。这个差异在复杂项目中会被放大十倍。

但别神化。14 个技能的复杂度是真实的认知负担。我翻了它的 writing-skills 技能文档，光是技能创建规范就涉及”匹配形式到失败类型”的决策表格、微测试措辞方法论、以及跨 9 个平台的兼容性验证流程。这套框架适合已经有工程习惯、想更进一步约束 AI 的开发者，不适合想”装了就变强”的新手。

趋势上看，Superpowers 正在从一个 Claude Code 专属工具变成跨平台标准。v6.0 一口气新增了 Kimi Code、Pi、Antigravity 三个 Harness，加上已有的 Claude Code、Codex、Copilot、Gemini、OpenCode 和 Cursor，覆盖了市面上主流 AI 编程 Agent 的 90% 以上。这个跨平台策略很聪明——它的价值不是绑定在某个 Agent 上，而是作为独立的方法论层存在。你换了 Agent，方法不用换。

还有一个细节让我对它的长期可持续性加分：遥测设计很克制。brainstorming 的可视化组件默认会加载 Prime Radiant logo，包含版本号，但不发送项目细节、不发送 Prompt、不发送 Agent 信息。而且提供了 SUPERPOWERS_DISABLE_TELEMETRY 等三个环境变量做退出。这种隐私意识在开发者工具中并不普遍。

最担心的还是 Bus Factor。两个核心维护者扛一个 128k Stars 的项目，压力显而易见。好消息是 v6.0 把 evals 测试框架分离为独立子模块，技能行为测试可以在真实 Agent 会话中运行并用 LLM 评判——意味着即使核心维护者减少，质量不会失控。但人力瓶颈不会因为自动化测试就消失。这个问题怎么解决，看 v7.0。

资源地址

先用起来再说

如果你已经在用 Claude Code 做正经项目开发，装上 Superpowers，从 brainstorming 和 test-driven-development 两个技能开始。不必一次用全 14 个技能，选两个对质量影响最大的先用起来，习惯流程后再逐步加。从你的下一个 feature branch 入手。

如果你还在观望，盯着两个信号：v7.0 会不会引入社区贡献技能的审核机制——这会解决 Bus Factor 问题；Star 增速能不能在接下来三个月维持——如果能，说明不是营销泡沫而是真实需求。这两个信号比任何评测都更说明问题。

老实说，一个 128k Stars 的项目一年后还在不在你的工作流里，取决于它能不能从”方法论”变成”习惯”。习惯的养成有且只有一个办法：先装再说。