先讲一个我上个月真实遇到的场景。我用 Codex 实现一个用户积分兑换功能十分钟它就把代码写完了编译也过但有三个问题相当扎眼一个单元测试都没写Maven 依赖引了一堆根本没用到的东西Service 层直接把 SQL 拼进了 Controller。我让它修结果它又因为一个深层的空指针折腾了快一小时改好这边又碰坏那边。后来我把 Superpowers 装进日常流程才意识到问题不在 Codex 笨而是没人给它一套完整的、可执行的“干活规矩”。Superpowers 要解决的就是这个。这篇文章我尽量讲实际体验不做广告。我会聊它是什么、怎么装、装完之后怎么用以及在 Java 项目里遇到的坑。如果你也用 Codex CLI或者同时在折腾 Claude Code这篇应该能帮你少走不少弯路。1. 先搞清楚Superpowers 到底往代理里塞了什么1.1 它不是一个普通插件而是一套“技能协议”编程代理生态里的插件很多只是给工具链加一两个命令入口或者绑几个 API 调用。Superpowers 不太一样它更像给代理补了一整套软技能——包括做事顺序、复盘方式、调试纪律、测试节奏。这些东西不是靠一段提示词就能糊弄过去的它被组织成结构化的技能文件代理在运行时会主动读取并按里面的步骤执行。我打个比方。普通插件像是给你的 AI 员工发了一台新电脑Superpowers 则是给他发了一本《工作手册》。电脑能让它干更多事手册能让它知道“什么活先干、什么活后干、干到什么程度算完”。对很多项目来说后者比前者更能决定交付质量。1.2 项目里到底装了什么skills、protocols、agents在我用的版本里Superpowers 大致分成三类资产skills领域技能。比如 TDD、Boomerang、代码调试、代码审查。每个技能里都有明确的步骤说明告诉代理面对什么场景、按什么顺序做什么。protocols跨场景的流程协议。比如“先拆任务、再动手写代码、最后统一验证”这类更上层的规则。Skills 更像是具体操作手册Protocols 更像总纲。agents带人设的工具集。一些复杂的角色类工作会组合多个技能并带上特定的上下文约束让代理在一个更稳定的“人格视角”里工作。这套结构的好处是你不需要每次都在提示词里写一大段废话。只要技能被加载代理自己就知道“这个场景应该调用哪套流程”。省下来的 token 和精力体感非常明显。1.3 适合谁用谁可以先不急如果你只是偶尔让 Codex 写几个一次性脚本那 Superpowers 暂时帮不上大忙甚至会让你觉得“怎么变笨了”。但如果你正在用它维护一个中长期项目代码有测试、有 CI、有持续迭代节奏那这套东西的价值就会被放大。我目前的使用场景是两类一类是 Java 服务端业务开发另一类是前端组件库维护。前者尤其能体现出 TDD 技能的作用因为 Java 项目往往有成熟的 Maven/Gradle 工程、JUnit 测试和严格的编译流程全凭代理自由发挥容易翻车。2. 安装前必须核对的环境Node、Codex CLI 和那个 Java 热搜2.1 基础依赖Node 18 和能用的 Codex CLISuperpowers 底层跑在 Node 上安装和后续技能执行都依赖 Node 运行时。我本机是 Node 20稳定复现没有问题。如果你还在用 Node 16建议先升级否则 npx 拉包或者技能脚本执行时很容易出奇奇怪怪的报错。Codex CLI 也需要确认版本。插件机制的语法在不同版本之间有变化我踩过的坑是旧版文档里的安装命令在新版 CLI 里并不存在会直接提示 command not found。所以不管看哪篇博客安装前都应先跑一下codex --version再对着仓库 README 对一下命令格式。2.2 为什么 Java 会和 Superpowers 绑在一起搜索“superpowers java”的人不少很多人以为这工具只支持 Java其实不是。它内置了多语言工程的支持Java 只是其中被照顾得比较好的一等公民。TDD 技能里有专门的 Java 上下文包括如何识别 JUnit 5、如何调用 Maven 或 Gradle 跑测试、如何阅读 Surefire 报告。但有一个关键点Superpowers 不替你装 JDK也不帮你配 Maven。它教的是“怎么用”而不是“用什么”。你的机器上还是得有正常的 JDK 和构建环境。否则技能会反复尝试运行mvn test然后因为环境不对而白耗 token。2.3 一次失败安装给我的教训我第一次安装时直接执行完官网的安装命令然后兴冲冲地让 Codex 开始干活。结果代理完全没有任何变化依然是我行我素的风格。我第一个反应是“这破工具没用”后来才发现技能文件根本没被加载到预期的目录。问题出在路径上。某些版本安装后并不是把技能放进~/.codex/skills而是放在自己的插件缓存目录里。如果你也遇到“装完像没装”的情况先别急着卸载用codex plugins list看一下插件状态再确认技能目录挂载点。这属于常见的使用前核对项不算 bug。3. 安装落地实录两条路线我实测的差别3.1 路线一通过 Codex 插件方式安装如果你主力用的是 Codex CLI那最简单的路径是走插件机制。大致命令如下# 在项目根目录执行 codex plugins add obra/superpowers执行完重启 Codex 会话插件就会在每次新会话里被自动加载。我当时还顺手验证了一下codex plugins list能看到superpowers出现在列表里。这种方式的好处是升级路径清晰Codex 的插件管理会帮你处理依赖。缺点是对 Codex 的版本有要求旧版本可能没有 plugins 子命令。3.2 路线二通过 npx 独立安装如果你用的是 Claude Code或者暂时不想依赖 Codex 的插件体系可以用独立安装方式。我当时在另一台机器上跑过npx --yes superpowerslatest install它会把技能文件写到用户级目录并尽可能兼容多个代理。这条路径的好处是不挑代理缺点是后续升级需要自己手动关注而且不同代理对技能的自动发现机制不一样不一定装上就能立刻生效。提示这两条路线的命令在不同版本里可能有变动动手前最好打开仓库 README 再对一下。网上很多文章里的命令已经过时了。3.3 装完怎么判断真的成功了我习惯做一个很轻量的验证在项目目录里新开一个 Codex 会话输入“你现在能用哪些技能”看它能不能列出 TDD、Boomerang 之类的东西。能列全说明技能加载正常列不出来基本就是目录或缓存问题。还有一种情况是技能加载了但代理没法自动响应。这通常和上下文有关需要你显式告诉它“使用 TDD 技能”。代码代理不是人它不会因为工具齐全就主动改变行为触发词往往至关重要。4. 核心技能逐个拆解TDD、Boomerang、调试协议4.1 TDD 技能让 AI 先写测试再写实现TDD 应该是这套工具里最出名的技能也是我把它放到生产项目的直接原因。装上之后代理接到一个功能需求时会走这么一套流程先读代码库理解模块边界写一份测试清单。从清单里挑一个最小用例先写失败测试。跑测试确认红灯。用最简代码让测试变绿。跑全量测试再做小步重构。这个流程图你看着不复杂但对代码代理来说差别非常大。没有这套约束时代理会直接写出一个“看似完整”的大函数然后测试随便补一个 happy path。有约束后它会老老实实一个用例一个用例地推进出问题时定位范围小得多。4.2 Boomerang 技能测试失败时的“回旋镖”Boomerang 是我一开始不理解、后来真香的一个技能。它的思路是当测试失败时代理不要急着改代码而是先把失败信息“回旋”到自己的模型里重新读一遍相关代码找根因再决定改动方案。这个设计非常符合实际调试心理。我自己写代码时也这样——遇到测试挂掉第一反应是赶紧补一行补丁结果经常修出新的问题。而 Boomerang 会强制代理先停下来说清楚根因。我实测下来它显著减少了“这里改好那里坏”的情况。4.3 其他值得留意的技能和协议除了 TDD 和 Boomerang仓库里还有一些我做代码审查时会用到的技能比如 review 类技能。它的触发方式是让代理按照一套固定维度审查变更包括边界条件、异常处理、命名一致性等。对于多人在维护的仓库这个技能能帮你把每次 code review 的注意力从“跟作者争辩风格”拉回到“客观看逻辑漏洞”。当然你不能指望它完全替代人的审查。它更像是给代理装了一套检查单减少低级漏看。真正的架构问题依然需要你拍板。4.4 在 Java 项目里用得最多的组合我在 Java 项目里的日常操作是TDD 技能 Boomerang 技能 项目根目录里的 AGENTS.md 约束。因为 TDD 技能虽然内置了 Java 支持但它还是得知道你这个项目具体用 JUnit 4 还是 JUnit 5用 Maven 还是 Gradle。举例来说如果我什么都不写代理经常会把断言写成 JUnit 4 风格或者干脆用assert关键字。Java 生态的版本差异和构建差异太琐碎了工具必须依赖项目上下文来消除歧义。所以别偷懒把工程规范写进 AGENTS.md再让技能去读效果才会好。5. 在工作流里真正用起来而不是让工具吃灰5.1 给 AGENTS.md 写好“技能触发上下文”Superpowers 的技能不会在所有场景下都硬塞给你很多靠代理自动判断。但自动判断的前提是它知道项目背景。我的做法是在仓库根目录维护一份 AGENTS.md写上本项目使用 Java 17 与 Maven。 实现功能必须使用 TDD 流程先列测试清单再写失败测试再实现最后重构。 运行测试命令mvn test -Dtest模块名。 单元测试使用 JUnit 5。这段描述看着简单但效果极其明显。代理在每次会话开始时都会读到这些信息再配合 Superpowers 的技能文件行为模式稳定很多。5.2 指令写法的差别别只喊“帮我实现”同样一个需求你换两种说法产出的质量完全不同。直接说“帮我实现积分兑换接口”代理多半按自己的理解直接开写。但如果你说请使用 TDD 技能实现积分兑换接口。 先在当前模块列出测试清单确认后再逐步实现。代理会进入一个更收敛的执行路径。它不会跳步也不会在第一步就抛给你一个 600 行的大类。我一开始觉得这样很啰嗦后来习惯了因为代码质量和返工率完全值回这一步操作。5.3 多语言项目里的取舍如果你手里同时有 Java、Python、TypeScript 项目建议不要让 Superpowers 全量加载所有语言上下文。它虽然能用语言标签区分但代理在实际执行中偶尔会拿另一套语言的习惯来套当前项目比如在 Java 里写 Python 风格的列表推导式。我自己是每个大语言栈单独开一个工作目录AGENTS.md 里把语言和构建方式写得死死的避免上下文污染。这个坑不一定人人都会踩但踩一次就够难受的。6. 实战里的坑Token 暴涨、流程僵化和版本漂移6.1 Token 消耗为什么会明显上涨装上 Superpowers 之后最直观的变化是 token 消耗变多了。原因很简单代理每次干活前要多读技能文件干活过程中还要输出测试清单、步骤说明一套流程下来消耗自然上去。我一开始也被吓了一跳后来想明白这是合理的。它不是浪费而是把本来“补丁式返工”的隐性成本提前转化成了“流程性输出”。如果按最终的代码质量和调试时间来算反而是省钱的。但如果你用的是按量计费的 API还是要注意单日消耗我一般会在长任务开始前手动设一下上下文上限。6.2 小任务被“过度流程化”针对一行配置修改或者一个纯文档更新也让它走完整 TDD 流程就非常不合适了。Superpowers 本身也做不到那么智能地判断任务轻重所以你需要自己帮它分流。我的经验是在一个需求里分成 feature 和 chore。涉及业务逻辑、公共接口、数据处理的变更必须走 TDD 技能纯配置、纯文案、纯重构允许代理直接改。这个分类写在 AGENTS.md 里它执行起来就不会显得很呆。6.3 版本漂移和技能名更新Superpowers 迭代速度不慢技能名称和安装方式都可能变。一两个月前的教程里说的技能现在可能已经改名或合并。很多人在社区里抱怨“按教程装完用不了”大概率是版本漂移的问题。我的做法是如果你在用插件方式尽量固定到某个已知稳定的 commit如果不需要新特性就锁住版本不追新。追新没问题但别在项目交付期追。6.4 别忘了一件事CI 不会替你自动变好不管本地代理流程跑得多顺CI 该配还是要配。Superpowers 解决的是“本地开发阶段的行为规范”它不会自动把测试纳入流水线也不会替你处理 Maven 仓库的私服配置。换句话说你仍然需要保证mvn test在干净环境里能跑通这跟工具本身一样重要。我个人现在的标准流程是开新功能先让代理列测试清单再实现本地跑过测试后推代码等 CICI 挂的时候优先让代理用 Boomerang 类技能去分析失败日志而不是浪费人的精力去猜。这套循环跑顺之后我确实少加了很多原本不必要的班。最后分享一点体会这类工具的真正价值不在于某个单点功能有多惊艳而在于它把“一个合格工程师的做事习惯”变成了可以批量复制的执行协议。你可以不叫它 Superpowers也可以只把它当提示词模板用但只要开始用流程约束代理作出的代码质量就会有肉眼可见的差别。