GitHub 195K Star，它凭什么被称为Claude Code生态"最具工程价值"的编程插件？

小知2026年05月21日约 7 分钟

用 Claude Code 写代码，相信大家都有一个共同的感受：让 AI 写个独立的小功能，顺滑；一旦项目有点规模，代码就开始烂。测试基本没有，全是一堆能跑但看不懂的屎山，复查的时候发现它根本没按你说的来。

我有段时间觉得这是模型的问题，换个更聪明的模型就好了。后来发现不对，不是模型不够聪明，是它根本没有工程纪律。就像你雇了个能力不差的程序员，但他不写测试、不做设计、拿到需求直接开干，你很难指望他交出什么高质量的东西。

Superpowers 想解决的就是这件事。

这是谁做的

作者叫 Jesse Vincent，GitHub ID 是 obra。如果你在 Perl 圈子或者开源社区混得早一点，这个名字不陌生，他是 Request Tracker（RT） 的创始人，RT 那个时代在开源工单系统里算是顶流，NASA 和很多大学都在用。后来他搞键盘，Keyboardio 那把分体式机械键盘，在键盘圈也算有名气。

怎么说呢，这个人做东西的习惯比较老派，注重流程、注重工程规范。Superpowers 整个设计哲学跟他早年做 RT 那套思路一脉相承，就是：流程对了，产出才稳。

项目在 2025 年下半年开始走红，截至现在 GitHub 上已经有接近20万 Star，被不少人称为 Claude Code 生态里最有价值的插件之一。

它到底在做什么

一句话：Superpowers 是一套强制给 Claude Code 加工程纪律的技能框架。

它的核心设计前提是，AI 编程质量差不是因为模型笨，是因为模型默认没有工程约束。你给它一个需求，它的本能是直接开始生成代码。没有需求澄清、没有方案讨论、没有测试先行、没有代码审查。Superpowers 把这些步骤全都强制加回来。

它用的是 Skills（技能） 做规范。每个 Skill 就是一个 Markdown 文件，里面写清楚：这个阶段你要做什么、怎么做、做完后验什么。Claude Code 装上之后，在对话开始时会自动把当前任务对应的 Skill 注入到上下文，不需要你每次手动提示。

整个系统分了四层：最上面是平台层，兼容 Claude Code、Cursor、Codex、Gemini CLI 等；下面是框架层，靠 Session Hook 机制在会话开始时自动注入；再下面是执行层，管子代理的调度；最底层是输出层，所有产出都用 Git 版本管理。

三个最关键的设计

1. 先问再干：Brainstorming 技能

这个是和普通 AI 编程体验差别最大的地方。

你把需求丢给 Claude，正常情况下它立刻开始写代码。装了 Superpowers 之后，它会先停下来问你问题。一个接一个，把需求里的含糊地方逐一澄清：认证方式支持哪些？OAuth 要接哪几个平台？Token 怎么存、怎么过期？

问完之后，系统会生成一份设计文档，按模块分段展示，你一段一段确认。确认完自动存到 Git，后续可追溯。

澄清完需求后，AI 会连续提问，把每个技术细节挖清楚。

需求收集完，系统通常给 2～3 个方案，各有利弊，让你选一个推进。

确认方案后，生成架构设计文档，按模块展示。

这一步看起来慢，但实际上省后期的时间。需求没搞清楚就上手，等你写到一半发现方向错了，那才是真正的浪费。

2. 测试必须先写：TDD 强制约束

这个设计我觉得是 Superpowers 最狠的地方，也是让很多用 Claude Code 的人没法忍受的地方，因为它直接动了 AI 最懒的那块。

Superpowers 的 TDD 技能要求：每个任务必须先写一个必然失败的测试，再写实现代码，再重构。这个顺序不能反。

Jesse Vincent 在博客里说，如果 Claude 检测到实现代码是在没有测试的情况下先写的，系统会自动把这段代码删掉，要求重来。他的原话大意是：这和跟一个懒得写测试的初级工程师合作的感觉一模一样，系统直接把这个坏习惯掐掉了。

循环是 RED → GREEN → REFACTOR：

• RED：写一个你知道会失败的测试，定义期望行为
• GREEN：写最少量的代码让这个测试通过
• REFACTOR：清理代码，保证测试还是绿的

不是建议，是强制。这点上 Superpowers 不讲客气。

3. 上下文隔离：子代理驱动开发

AI 对话越长，输出质量越容易飘，这个规律我相信大多数人都有感受。早期的设计决策一直压在上下文里，模型会越来越受历史信息干扰。

Superpowers 的解法是给每个任务单独起一个子代理。父代理只负责拆任务和审查，子代理从空白上下文启动，只拿到当前任务的描述。做完了，专门再起一个审查子代理来查质量。父代理不参与执行，不污染上下文。

审查分两轮。第一轮只看一件事：功能有没有实现？边界条件有没有覆盖？不管代码写得好不好看。

第二轮才看代码质量：有没有重复代码，命名清不清晰，有没有过度设计。两轮分开，谁也别干扰谁。

第一轮过不了，直接新建子代理重新执行，不在原来那个上下文里继续磨。

完整工作流是什么样的

七个阶段，顺序固定：

Brainstorming → Git Worktree → Writing Plans → Subagent Development → TDD → Code Review → Finish Branch

其中 Git Worktree 这一步值得单独说一下。Superpowers 在设计确认后，会自动用 git worktree add 创建一个隔离的开发目录，在另一个路径下开一个新分支。这样主工作区不受影响，多个功能可以同时在不同目录下并行开发，也不会频繁触发 IDE 重新索引。

# 传统分支切换（会触发 IDE 重新索引）
git checkout -b feature/auth

# Worktree 方式（主目录不动）
git worktree add ../auth-worktree -b feature/auth

Writing Plans 那步，系统会把设计文档拆成一个个 2～5 分钟能完成的小任务，每个任务带上精确的文件路径和验证步骤。

计划拟好之后，按顺序执行，每个任务交给子代理，完成后自动触发两轮审查，审查通过继续，不通过重做。

全部任务完成后，Superpowers 会再跑一遍所有测试，然后让你选：合并到主分支、生成 PR、保留当前状态，或者丢掉这次开发。

怎么安装

Claude Code（最简方式）

/plugin install superpowers@claude-plugins-official

或者走 obra 自己的市场：

# 第一步，注册市场
/plugin marketplace add obra/superpowers-marketplace

# 第二步，安装
/plugin install superpowers@superpowers-marketplace

安装完重启 Claude Code 就好了。

其他平台

• Cursor：在 Agent chat 里搜 "superpowers" 直接装
• Gemini CLI：gemini extensions install https://github.com/obra/superpowers
• Codex：让 Codex 读 https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md 并按说明操作
• OpenCode：同上，路径换成 .opencode/INSTALL.md

核心技能速查

技能	干什么的	什么时候用
`brainstorming`	需求澄清 + 出设计文档	需求不清晰，或大功能开始前
`writing-plans`	把设计拆成 2~5 分钟的小任务	有了设计文档，准备动工前
`subagent-driven-development`	派子代理执行，自动双轮审查	任务明确、想全自动跑
`executing-plans`	按计划执行，中途可介入	需要边做边调整方向
`test-driven-development`	强制 RED-GREEN-REFACTOR	写任何功能代码前
`systematic-debugging`	4 步根因分析：复现→追踪→修复→防守	遇到 Bug 或奇怪行为
`using-git-worktrees`	自动建隔离开发目录	同时做多个功能
`requesting-code-review`	触发代码审查	提交或合并前

技能可以手动触发，也可以组合用。比如：

用 TDD 方式实现用户认证，完成后做代码审查

这条指令会同时触发 test-driven-development 和 requesting-code-review。

几个常见坑

装了但没触发

# 先确认插件列表里有没有
/plugin list

# 手动试一下
使用 brainstorming 技能来规划这个功能

如果还不行，重启当前会话。Session Hook 需要在对话开始时注入，已经开着的会话可能不会生效。

Git Worktree 报错

# 先查 Git 版本，需要 2.5 以上
git --version

# 清理残留
git worktree prune

安装报错

rm -rf ~/.cache/superpowers
/plugin install superpowers@superpowers-marketplace --force

写在最后

说真的，Superpowers 解决的问题是真实的。AI 编程的核心缺陷不是不够聪明，是没有约束。它不会主动问你需求，不会主动写测试，不会主动做审查，但这些事情对于代码质量来说都挺关键。

我自己的感受是，用了 Superpowers 之后，最大的变化不是代码质量有多高，而是过程变得可追溯了。设计文档有，计划有，每步审查记录有，出了问题你能找到是哪个环节断掉的。

它不适合快速原型或一次性脚本，那些场景走完整流程反而低效。但如果你在做一个需要长期维护的项目，Superpowers 这套规范我觉得值得接入。

反正我觉得，与其花时间在烂代码上修修补补，不如一开始就让 AI 走个正经流程。

GitHub：

https://github.com/obra/superpower