Superpowers 完全指南：3 步装好 AI 编程代理的技能框架-育师

Superpowers 完全指南：3 步装好 AI 编程代理的技能框架

【免费下载链接】superpowersAn agentic skills framework & software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers

你有没有遇到过这种情况：让编程代理做个功能，它二话不说开始写代码，几轮之后方向偏了，质量也没人把关。Superpowers 是一套给 Claude Code 等 AI 编程代理用的技能框架加开发方法论，装好之后，代理会自动按"先设计、再计划、TDD 实现、逐步审查"的完整流程推进，你不需要额外敲任何技能命令。

它解决的到底是什么问题

Superpowers 不是代码生成器，而是给代理立的一套"工程纪律"。装上之后，三件事会发生改变：

你一提需求，它先不写代码，而是和你确认真实意图，把设计拆成足够短、看得完的段落逐段给你签字确认；
计划被写到"没有项目背景的新手也能照做"的粒度，单个任务只要 2-5 分钟；
你说"开工"之后，每个任务交给子代理（subagent）执行，并做两轮审查——一轮对照计划、一轮查代码质量，关键问题不解决就不往下走。

所有技能都由系统在合适的时机自动触发，会话里不用你手动点名。

最快安装路径：Claude Code 两条命令

🛠 用 Claude Code 的路径最短，在对话框里依次执行两条斜杠命令即可：

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

装完重启会话就能用。其他平台也都有入口，按你实际用的选一个就行：

Codex（App / CLI）：插件市场里搜 "Superpowers" 直接安装；
Cursor：Agent 对话中执行/add-plugin superpowers；
Kimi Code：/plugins打开市场，找到 Superpowers 安装；
Gemini CLI：一条 extensions 安装命令完成；
Antigravity / Pi：各有一条插件安装命令。

注意每个代理平台是独立安装的，同时用两个平台就要装两遍。

OpenCode 安装：克隆仓库再配置

OpenCode 走自己的插件机制，需要单独配置。先把仓库克隆到本地：

git clone https://gitcode.com/GitHub_Trending/su/superpowers ~/.config/opencode/superpowers

然后在opencode.json的plugin数组中加入 superpowers 条目（指向该仓库地址），重启 OpenCode。想确认是否加载成功，直接问一句"Tell me about your superpowers"，能正常回应就说明装好了。详细步骤可看仓库里的 docs/README.opencode.md，Kimi 的完整说明在 docs/README.kimi.md。

一个功能从想法到合并的完整流程

核心工作流共七步，全部自动串联，不用你干预：

brainstorming：用提问打磨想法，产出设计文档；
using-git-worktrees：开独立 worktree 和新分支，确认测试基线干净；
writing-plans：把工作拆成带精确文件路径、完整代码和验证步骤的小任务；
subagent-driven-development（或executing-plans分批执行）：每个任务派一个全新子代理去实现；
test-driven-development：RED-GREEN-REFACTOR 循环，先写会失败的测试；
requesting-code-review：任务之间按严重程度报告问题，Critical 级别直接卡住进度；
finishing-a-development-branch：收尾时决定合并、提 PR 还是丢弃，并清理工作区。

按计划执行顺利的话，代理连续自主工作一两个小时不跑偏，是常态。

值得细读的四个技能

brainstorming：阻止代理"先写后想"

它把模糊的想法变成可验证的设计。价值在于把"需求理解错误"这类最贵的错误挡在写代码之前——设计阶段改一段文字，远比返工几千行代码便宜。

writing-plans：计划细到文件和验证步骤

生成的计划里每个任务都写明要改哪些文件、写什么代码、怎么验证。这保证后面执行阶段的代理不会自行发挥，也让你随时能看懂它下一步要干什么。

subagent-driven-development：每个任务过两道审查

第一道审"是否符合计划"，第二道审"代码质量如何"。子代理每次都是全新上下文，不会带着前面任务的坏习惯继续往下做。这是它和"让代理一口气写完"的最大区别。

test-driven-development 与 systematic-debugging：实现和排错的双重底线

TDD 技能强制执行"先写失败测试、看它失败、再写最小代码"的节奏，甚至会把在测试之前先写好的代码删掉重来。出问题时，systematic-debugging 用四阶段流程做根因分析，而不是逐个试错碰运气；修完还要过verification-before-completion的确认，确保是"真的修好了"。

适合谁、什么时候用它

个人开发者：单人项目也能拿到接近团队规范的产出——设计文档、计划文档、审查记录全程留痕；
团队协作：所有人的代理跑同一套流程和标准，代码风格与质量门槛统一，review 成本下降；
典型场景：跨多文件的功能开发、需要长时间自主运行的任务、以及你不太熟悉的新代码库。

如果你只是想快速改个文案或查个小问题，这套流程反而显得重，不必强行套用。

使用前的 4 个常见坑 ⚠️

多平台要分开装：Claude Code 装过不代表 OpenCode 里也有，每个 harness 独立安装、独立更新；
装完要验证：开一个干净会话，发一句类似"让我们做个 react 待办清单"的请求。如果 brainstorming 技能没有自动触发，说明会话启动引导没加载，技能等于白装；
更新方式：各平台更新方式不一，多数是自动的；手动安装的话进到本地仓库目录执行git pull再重启即可；
遥测可关：brainstorming 的可视化伴侣组件默认会从外部加载一张带版本号的图（不含你的项目内容），介意就把环境变量SUPERPOWERS_DISABLE_TELEMETRY设为任意真值。

另外它本身零第三方依赖，不需要额外安装 Node 包就能跑核心流程（只有 brainstorming 的可选可视化伴侣才需要 Node.js 环境）。