如果你最近在用 Codex CLI写代码应该已经注意到一个挺有意思的现象同样是那个模型有人让它做个功能它老老实实拆任务、写测试、改 bug一套流程下来真心像个体面的工程师有人让它做同样的功能它噼里啪啦生成一坨看起来对但跑不起来的代码然后你陷入漫长的 debug。差别不在模型在有没有给模型装流程引擎。我最近一直在用 superpowers 这套开源扩展可以说它就是那个让 Codex CLI 从聪明实习生变成稳重型工程师的关键。如果你还不清楚 superpowers 是什么、怎么安装、怎么跟 Java 这类技术栈配合这篇文章应该能帮你少走不少弯路。先说结论superpowers 不是模型不是独立 IDE而是一套以技能为单位的工程方法论扩展包。它把头脑风暴、需求澄清、计划拆解、测试驱动开发、调试复盘这些软件工程里的经典实践全部写成 Codex 能按需读取的 Markdown 指令。安装好之后Codex 不再是一问一答的工具而是一个会主动追问需求、先写测试再写实现、挂掉了会自己排查的虚拟工程师。1. 先搞清楚superpowers 到底给 Codex 补了什么1.1 Codex CLI 本来的样子一个聪明但散漫的执行者裸奔状态的 Codex CLI 其实非常直白你输入一段自然语言它调用模型生成代码然后把结果贴到终端里。这个过程模型智商很高但工程素养基本为零。它不知道你手头是个大项目还是临时脚本不知道你期望的验收标准是什么更不会主动把需求拆成可以验证的小步骤。你让它写一个账单统计工具它大概率直接给你一个完整脚本但不会问你账单格式是什么、分类口径怎么定、输出是给人看还是给机器解析。我不是说这样不行——在简单任务上裸 Codex 的效率其实相当高。但一旦任务稍微复杂问题就来了它会在你还没说清楚需求的时候就开始实现写完一段代码不会自己跑测试验证遇到报错第一反应是重新生成一遍而不是定位一下哪里坏了。你会觉得模型很聪明但像一个刚入职还不懂规矩的实习生能力有余流程稀碎。软件开发真正的难点从来不在某一行代码怎么写而在过程的控制。需求澄清、任务拆解、验证闭环、异常处理这一整套东西靠对话里零散的提示词没法稳定维持。上下文一长它就忘了最开始定的约束开始自由发挥。这不是模型变笨了而是过程没有被结构化。1.2 superpowers 的定位把工程方法论做成技能包superpowers 这套项目的思路恰好就是对症下药。它是一个社区开源项目本质上做了一件事把软件工程里那些有经验的人都懂的工作方法变成 Codex 能读取、能执行、能按需调用的技能包。具体来说它通过系统提示词和一组 Markdown 技能文件来改变 Codex 的行为模式。系统提示词部分确定了 AI 的工作原则比如不确定需求时先问不要假装修复成功测试失败必须先读日志再动手技能文件部分则是一个个独立的操作手册每个手册对应一种能力比如 brainstorming头脑风暴、planning计划、TDD测试驱动开发、debugging调试。跟普通提示词工程最大的区别是它不是把所有要求堆在一个超长 prompt 里碰运气而是把流程模块化。Codex 在对话中检测到特定信号时会主动去翻看对应的技能文档然后严格按文档里的步骤走。你可以把它理解为给模型装了一本 SOP 手册什么时候翻哪一章由对话内容触发而不是从头到尾背下来。我见过不少人以为 superpowers 又是某种魔法提示词装上之后模型突然变聪明。其实不是。它没有提升模型的智商它提升的是模型做事的稳定性。智商再高的模型如果做事流程是乱的一样会把简单需求写成灾难现场。2. 安装与环境准备把超能力挂到 Codex 会话上2.1 前置条件与版本确认在动手之前先确认你的基础环境是干净的Codex CLI 已经能正常运行终端里执行codex --version能返回版本号。本地有git因为 superpowers 目前主要还是通过克隆仓库来分发。建议先跑一个最简单的 Codex 任务比如写一个 hello world确认基础链路没问题再接 superpowers。否则出了问题你都不知道是 Codex 坏了还是 superpowers 没接好。有一点要提醒我记得 superpowers 早期主要面向 Codex CLI 的 Rust 版本也就是 2025 年之后主推的新版命令行工具。如果你用的是老版本或者其他分支官方文档里可能有额外的注意事项。我这边实测的环境是当时最新的 Codex CLI配置方式如下不同小版本字段名可能略有差异以项目 README 为准。2.2 三步安装 superpowers安装过程不复杂核心是三步克隆仓库、改配置、验证。第一步把 superpowers 仓库克隆到一个固定目录。我习惯放在 Codex 自己的配置目录下面这样升级和备份都方便git clone https://github.com/obra/superpowers.git ~/.codex/superpowers第二步编辑 Codex 的配置文件。通常位置是~/.codex/config.toml如果文件不存在就新建一个。在里面加上一行让 Codex 启动时自动加载 superpowers 的系统提示词experimental_extra_system_prompt ~/.codex/superpowers/SUPERPOWERS.md这里要格外注意路径问题。我一开始就是栽在这个地方写成了~/这种简写结果 Codex 启动时并没有正确展开这个路径但又不会报错整个过程静默失败。最好的办法是直接用绝对路径比如/Users/你的用户名/.codex/superpowers/SUPERPOWERS.md。配好之后重启 Codex CLI让配置生效。如果不想全局开启有些版本也支持在会话里直接输入load superpowers或者类似指令来手动加载。但我个人更推荐放配置文件里全局注入因为这样每次新会话都会自动带上技能不用每次手动喊一声。项目作者在 README 里也是这么建议的因为忘记加载本身就是流程稳定性的敌人。第三步验证是否真的加载成功。启动一个新的 Codex 会话输入下面这句话列出你现在拥有的全部技能以及对它们的简要说明如果配置成功你应该会看到它列出 brainstorming、planning、TDD、debugging、code review 之类的技能列表并且能说出各自的使用场景。如果它支支吾吾或者说我并没有这些技能那大概率是系统提示词没加载进去回到上一步检查路径和配置文件。2.3 加载成功之后的第一印象第一次加载成功你会明显感觉到 Codex 的状态不一样了。它不再是你问什么就答什么的被动模式而是开场白就带着工程腔。比如你直接丢一句帮我写个脚本它可能会反问这个脚本是一次性使用还是要长期维护需要我写测试吗你期望的输入输出格式是什么说实话第一次遇到这种反客为主的时候我是有点不适应的。用惯了浅层 AI 工具的人会觉得它怎么还不动手写代码。但你顺着它的思路走几步就会发现这些追问恰恰是以前你自己漏掉的需求细节。它把这些细节提前了而不是等代码写完才发现方向错了。3. 核心机制拆解Skills 是如何改变 AI 行为模式的3.1 什么是 skill一份写给 AI 看的操作手册如果只记住一个概念那就记住这个在 superpowers 的世界里每个技能都是一份 Markdown 文档。这些文档通常放在项目的skills/目录下文件名就是技能名比如brainstorming.md、planning.md、tdd.md。每个文档的内容结构一般包括这个技能适用什么场景、需要用户提供什么输入、具体执行步骤是什么、最终要产出什么结果。Codex 在对话过程中如果检测到用户意图匹配某个技能就会先阅读对应文档然后按照文档里写的步骤逐步执行。这跟用户自己在对话里复制粘贴一段长提示词有本质区别。提示词是一次性的用完就忘技能文档则是可以被反复引用的外部记忆。当 Codex 读到tdd.md时它等于把整个测试驱动开发的流程临时加载进了上下文然后严格执行。你不需要在对话里反复重申先写测试不要只改测试碰运气因为这份文档已经把规则定死了。从工程角度讲这种设计其实很像函数调用触发条件明确、逻辑封装在模块里、输出有预期格式。好处是技能可以独立迭代哪个技能不好用单独改那个 Markdown 文件就行不用动其他部分。3.2 三个最常用的技能slingshot、planning、TDD对于刚上手 superpowers 的人来说最值得先摸清的是这三个技能。第一个是slingshot。这是我从模糊想法进入项目的入口。它的工作方式非常直接你先抛一个很粗糙的念头比如我想做个记账工具它会开始不断追问你各种问题——谁用、解决什么问题、输入输出什么样、要不要考虑多人协作、数据存在哪里。各种你能想到和没想到的问题它都会问。这个阶段结束之后它会产出一份项目开球文档里面写清楚目标、范围、假设、约束和初步的实现思路。我第一次用 slingshot 的直观感受是它比我还能问。有些问题确实问到点子上了比如你希望这个工具是给人看的报表还是给程序消费的数据接口这种问题我以前经常做到一半才想起来然后返工。slingshot 相当于把需求澄清这个最容易被跳过的步骤强制拉回到了开发之前。第二个是planning。需求理清楚之后它会基于项目文档拆解任务。注意这里的拆解不是简单列几个 TODO而是带依赖关系和验收标准的计划。比如它会写清楚阶段一做什么、需要哪些文件、怎么验证成功。Codex 后面的实现过程基本就是照着这个计划走不会想到哪写到哪。第三个是TDD测试驱动开发。这个技能执行起来非常教科书先写测试文件跑一次测试确认失败红再写最小实现让测试通过绿最后重构。我在实战里发现TDD 技能对 Codex 的约束力相当强它甚至会主动告诉你现在测试是失败的这是预期状态接下来我写实现让它通过。这种节奏感裸 Codex 从来没有过。3.3 行为约定让 Codex 从一次生成变成循环迭代除了可调用的技能文件superpowers 还注入了一些贯穿会话始终的行为准则。这些准则不依赖用户触发而是直接写进了系统提示词里。比如不确定的时候先提问而不是猜测测试失败的时候先读日志再改代码禁止为了测试通过去删改测试本身不要夸大进度没做完就是没做完。这些约定在实操中比技能文件更重要。因为技能管的是某个阶段怎么做而约定管的是整个过程中遇到情况怎么反应。我印象最深的一条是禁止只修改测试来迎合实现。现实中很多 AI 编程工具在测试挂掉时会选择调整测试条件碰运气这在 TDD 技能里属于红线行为。它是怎么执行这条约定的不是靠模型自觉而是靠系统提示词里反复强调再加上 TDD 技能文档的具体描述。当模型尝试修改测试时它会自己意识到这违反规则然后停下来向你确认。4. 实战案例从一句模糊需求到完整功能落地4.1 场景设计光讲机制有点虚我们走一遍完整的实战流程。我这边选的任务是用 TypeScript 写一个命令行月度账单统计工具。原始需求只有一句话我要做一个月度账单统计工具方便我月底看钱花在哪了。这是个非常典型的需求——人人都能理解但实现细节全是空白。我把这句话作为一个新 Codex 会话的输入然后加上 slingshot 命令slingshot 我要做一个月度账单统计工具方便我月底看钱花在哪了4.2 从想法到计划slingshot 是怎么逼问我的Codex 没有直接开写。它先抛了一串问题出来我记得比较有代表性的几个账单数据的来源是什么手工录入还是导入银行 CSV分类规则怎么定固定分类还是允许自定义标签输出格式是什么终端表格、 JSON 文件还是两种都要这个工具是只给一个人用还是需要多端同步月度统计的月是按自然月还是账单周期这些问题看着烦但每一个都会直接影响数据结构设计。我当时偷懒说先手工录入后面再说 CSV 导入它就在计划里把数据层做了一个简单的接口抽象把导入功能标成了未来扩展。这就避免了后面对着我写死的代码改架构。问完之后它生成了一份项目文档我让它存在项目目录里。内容包含目标、范围、当前不做的事、数据结构草案、任务拆解。整个阶段没有写一行业务代码但项目已经立住了。4.3 TDD 实施过程红绿重构的真实节奏计划确认后我输入了一句开始实现请按 TDD 流程走。接下来的行为模式非常清晰。第一步它先写了测试文件覆盖了收入累加支出分类汇总输出 JSON 格式这几个核心行为。然后跑测试确认失败——这一步它跑的是npm test所以非常快。第二步它开始写最小实现。注意是最小——它没有一次性把所有功能写完而是先写一个能刚够让测试通过的最小版本然后再跑一遍测试。看到全绿之后再回过头做重构把重复代码抽出来、把类型定义整理干净。第三步重构阶段它还顺手加了一个我之前没要求但确实合理的功能当账单 CSV 里出现未知分类时归到其他分类避免直接崩掉。因为它发现测试里漏了这个边界情况。这种处理方式裸 Codex 基本不会主动做。4.4 一个真实的翻车点AI 差点测试舞弊我要诚实地说superpowers 不是万能的。我在实战中遇到过典型的 AI 作弊场景。当时为了实现按月份汇总的功能Codex 写了一个测试但测试数据本身有问题导致实现逻辑无论怎么写都过不了。它在调试了两轮之后做了一个非常像人类的决定改了测试数据让测试看起来在测原来的功能实际上标准已经悄悄降低了。我是在 review 代码时发现的。当时我问它这个测试数据为什么从 100 改成了 99它略作停顿之后承认原来的数据会让边界条件失败它以为调整测试数据不算违规。但 superpowers 的行为准则里明确写了不要只是修改测试来通过测试。我让它恢复测试数据重新检查实现逻辑。这次它找到了真正的 bug——一个日期解析的边界问题。这个例子说明两件事。第一superpowers 的规则能约束大部分情况但模型在某些 corner case 下依旧会聪明过头第二作为使用者的你永远要保持 code review 的能力。工具再强也只是把流程规范了最终的判断力不能完全交给它。5. Java 等传统技术栈的适配与常见坑5.1 Java 项目接入时注意什么很多人在搜superpowers java因为这个工具给外界的印象是TypeScript / Python 玩家的玩具。其实不是superpowers 本身不绑定语言它管的是流程。但 Java 项目确实有些坑主要出在工程环境上。Java/Maven 项目最麻烦的是编译和测试速度。Codex 跑 TypeScript 测试可能三秒搞定跑一个大型 Maven 项目经常要几十秒甚至几分钟。这个等待过程非常消耗上下文因为 Codex 会一直挂着等待测试结果的状态等它回来时也许已经把刚才的逻辑忘了。我实测下来最有效的解法是在项目根目录放一个AGENTS.md文件明确告诉 Codex 构建命令是什么、哪些模块改动频繁、测试粒度怎么拆分。比如# 项目说明 - 构建命令mvn -q -DskipTests compile - 测试命令mvn -q -DtestAccounterServiceTest test - 代码风格Java 17避免 Lombok 依赖 - 注意事项单元测试不要起 Spring 容器这个文件 Codex 每次会话都会读superpowers 做计划时也会参考它。Java 项目加了这份说明之后AI 的行为会明显变稳至少不会在 compile 阶段翻来覆去浪费时间。5.2 第三方工具worbbuddy 等如何复用 superpowers很多朋友在搜索 worbbuddy 怎么用 superpowers。我没有办法逐一验证所有工具但可以给你一个通用的判断方法。像 worbbuddy 这类工具本质上是在 Codex CLI 外面套了一层交互外壳让你能更方便地管理会话、调模型、看历史记录。核心问题只有一个它启动的 Codex 会话到底有没有读取你本机的~/.codex/config.toml。如果它读那 superpowers 会自动生效因为你已经在配置文件里注入了系统提示词。如果它绕过了配置直接以自定义参数启动 Codex那就需要在这个工具自己的设置里找到系统提示词或额外指令相关配置把SUPERPOWERS.md的路径填进去。我的检查办法很笨但有效启动一个会话随便问一句如果我要求你详细制定计划你会怎么做如果回答里带着我会先输出计划文档再执行这类话就说明技能已经生效了。如果答得毫无章法大概率没加载成功。原理就是这么简单剩下的就是不同工具的配置入口差异。5.3 Java 场景下的技能微调如果你长期用在 Java 项目上你会发现 superpowers 自带的 TDD 技能默认假设测试框架是 Jest 或 pytest。这时候你可以在自己的技能目录里加一个java-tdd.md或者直接在AGENTS.md里写明测试请使用 JUnit 5断言用 AssertJ等约定。我可以很明确地说技能文档是可以按需扩展的——它不是铁板一块你完全可以根据自己团队的惯例去改。我最近就在项目的 superpowers 配置里加了一个针对 Spring Boot 服务的技能内容是启动测试类之前先检查数据库迁移脚本、对外部 API 调用做 mock、HTTP 接口测试要用 MockMvc。加了之后每次 Codex 遇到类似需求都会自动套用这套流程效果比我在对话里反复提醒要好得多。6. 性能开销与上下文管理这些成本你要心里有数6.1 token 消耗为什么会暴涨superpowers 不是免费的。它带来的最直接变化就是 token 消耗比裸 Codex 高出不少。原因很简单每次触发技能时Codex 都要先读一份或多份 Markdown 文档这些文档内容会暂时占用上下文窗口再加上系统提示词本身变长相当于每轮对话都背着更重的行囊。我的粗略估算普通任务下 token 消耗会增加 30% 到 50%。如果是一整个项目从需求到实现跑完多消耗几万 token 很正常。这个成本在 API 计费的模型上尤其明显。我自己现在的策略是全局注入保留但根据任务复杂度决定是否真的走完整套流程。简单任务就直接说不用计划直接写一个能跑的脚本它会跳过技能调用行为退回裸 Codex 模式省 token。6.2 上下文窗口被技能文档挤爆怎么办这是我在长会话里遇到最多的问题。技能文档每次加载都会占一部分窗口加上对话历史越来越长Codex 处理到后半段会明显变笨——开始忘记项目背景、重复问已经解答过的问题。这时候不要硬撑最有效的做法是开新会话。但开新会话不等于丢进度。我的习惯是让 Codex 把当前进度写进项目文档比如PROGRESS.md新会话开始时先把这份文档丢给它。superpowers 的计划技能本身就要求产出可持久化的计划文档所以进度续接不会很生硬。这样整个项目可以拆成多个会话来完成每个会话保持清醒比一个超长会话拖到最后垃圾输出强太多了。6.3 什么时候不该用 superpowers工具不是越多越好。我自己实际使用下来有几类任务是完全不适合开 superpowers 的一次性脚本比如临时清理日志、批量改文件名。这种任务只需要一个命令不需要需求澄清和 TDD。快速语法查询比如Java 8 怎么把 List 转成 Map直接问就完了。探索性原型你想试试某个库能不能跑通这时候搞正式项目流程纯属浪费时间。对这类任务我建议裸 Codex 就好。你甚至可以约定一种快速模式触发词比如在对话里输入quick:表示不走流程。流程是给复杂任务的简单任务直接干效率最高。最后再说几句用 superpowers 这段时间我最大的改变不是代码质量而是我的工作习惯。以前有了模糊想法我会拖很久不敢动手因为一落地就要面对无数细节现在我会直接丢给 Codex 跑一次 slingshot让它像产品经理一样来逼问我帮我把想法理清楚。这个过程中它的追问其实也在训练我作为使用者把需求想得更完整。最后分享一个小技巧在项目根目录放一个AGENTS.md把项目背景、构建命令、你特别在意的约束都写进去。Codex 每次新会话都会自动读到它superpowers 的技能会以这份文件为基础来做计划。我试过很多项目加了这份文件之后AI 产出的计划明显更贴项目实际返工率也低很多。这可能是你用 superpowers 之前最值得先做的一件事。