最近我的工作流里多了一个叫 superpowers 的东西它实实在在地改变了我和 Codex CLI 的配合方式。如果你也遇到过这种情况明明机器配置好了、模型也是最新的但让它写个功能代码总是写得快、错得也快一追问就开始瞎改改完还理直气壮——那这篇东西应该对你有用。superpowers 是跑在 Codex 之上的一个技能/工作流集合你可以把它理解为一套资深工程师方法论的手册。它给 Codex 预置了任务拆解、方案设计、TDD 循环、系统化查 bug、代码审查这些标准动作让 AI 不再是想到哪写到哪的愣头青而是按一套稳定流程推进。这篇文章我会从安装开始讲然后拿一个真实的 Java 模块开发过程做演示最后说说我实际踩过的坑和调整出来的用法。1. Superpowers 到底给 Codex 补了什么超能力1.1 痛点Codex 是个有天赋但不稳定的实习生我之前用 Codex CLI 的感受可以浓缩成一个词不稳定。同一个任务有时候它写得飞快、结构也清楚有时候它能在不该动手的地方突然开干一口气改十几个文件把整个项目的风格都带偏。问题的根源其实不在模型能力而在流程缺失。每次新开一个对话Codex 面对的就是一块白板。它知道 Java 语法、知道 Spring Boot 的常见写法但它不知道你希望它先写测试再写实现也不知道改完代码之后要跑一遍完整构建才算完成。这些流程性的知识你不说它就默认不做。你可能觉得那我每次都在 prompt 里写清楚不就行了对我一开始也这么干。但实测下来有俩问题第一prompt 越写越长光是把约束条件列完就占了大量上下文第二即使你写得很详细模型执行到一半也可能跑偏因为你的指令是静态文本它没法在每个关键节点都自动提醒自己按计划来。1.2 Superpowers 的解题思路把方法论写成 Skill 文件superpowers 的解法很朴素它把一套套完整的工作方法论写成了 Markdown 格式的 SKILL.md 文件放进 Codex 能读到的目录里。每个 Skill 文件就是一份操作手册里面定义了角色、输入、步骤、输出物甚至包括什么情况下应该停下来问用户这类约束。当你在 Codex 对话里触发某个工作流时模型会先加载对应的 Skill 手册然后严格按手册里的步骤执行。这就好比你不是雇了一个聪明的实习生而是给这个实习生发了一本 SOP 手册——他不需要每一步都来问你但也绝不会跳过关键环节。这种方式最聪明的地方在于它把个人经验变成了可复用、可版本管理的资产。你今天总结出来的写后端接口之前要先画字段表写成 Skill 之后团队里的任何人在任何机器上都能让 AI 按这个规矩干活。1.3 它自带了哪些核心 Skills打开安装目录你能看到十几个工作流我挑几个常用的列一下Skill 名称适用场景核心步骤brainstorm需求还不清晰时做方案发散澄清目标、列出候选方案、逐个权衡、输出建议writing-plans动手前编写实施计划拆任务、排依赖、定义验收标准tdd测试驱动开发先写失败测试、最小实现、跑绿、重构debugging线上/本地问题排查复现、二分定位、假设验证、修复验证code-review代码审查对照清单逐项检查、按严重程度分类问题implementing-change小范围、受控的实现修改明确改动边界、最小变更、回归测试这里要特别说明一点这些 Skill 不是魔法不会让模型突然变聪明。它的作用是改变模型的工作顺序和检查习惯让每一次对话的输出质量下限被拉高。实际用下来最常见的效果是模型不再跳过测试直接写实现也不会在需求没聊清楚的时候就开始动手。2. 安装与初始化踩平入门的第一道坎2.1 完整安装命令和步骤安装其实非常简单前提是你已经有 Codex CLI 并且登录过。我自己的环境是 macOS Node 18直接通过 npm 装npm install -g obra/superpowers装完先别急着打开 Codex还需要做一步初始化把 Skills 文件释放到 Codex 的配置目录里。在终端执行superpowers这个命令会进入一个交互式引导界面它会检查你的 Codex 安装路径询问要安装哪些工作流然后自动把文件写入对应目录。我建议第一次安装选全部后面用熟了再按需裁剪。如果你用的是较新的 Codex 版本也可以试试一次性命令npx obra/superpowerslatest我实测两种方式效果一致区别只是 npm 全局安装之后后续升级比较方便用npm update -g obra/superpowers就能更新。2.2 它到底改了你机器上的哪些配置这一步是我建议每个用户都花两分钟弄清楚的因为不搞清楚的话出了问题你都不知道去哪里排查。初始化之后superpowers 主要做了两件事第一在 Codex 的配置目录下创建了一个 skills 目录里面按工作流名称放了一堆 SKILL.md 文件。我的机器上路径是这样的~/.codex/skills/ ├── brainstorm/SKILL.md ├── writing-plans/SKILL.md ├── tdd/SKILL.md ├── debugging/SKILL.md └── ...第二它会向 Codex 的config.toml文件追加一段插件声明让 Codex 启动时知道这个用户有一套 skills 可以用。这也是为什么装完后需要完全退出 Codex 再重新打开——插件声明是启动时加载的热更新不生效。我个人建议装完打开 config.toml 亲眼看一眼那几行配置。知道改动在哪以后卸载、调试、甚至手动加自定义 skill 都会顺手很多。2.3 怎么确认安装真的生效了装完最怕的就是以为自己装好了实际上 Codex 根本没加载然后对着空气折腾半天。我的验证方法很简单重启 Codex 之后直接在对话里输入一句你会哪些工作流用列表展示出来。如果安装成功它会列出一串 skills 名字并且简单描述各自的用途。如果它说我没有额外的工作流或者答非所问大概率是插件没加载上按下面三个顺序排查确认 config.toml 里有没有 superpowers 相关的插件声明确认 skills 目录下的 SKILL.md 文件不是空的确认你重启 Codex 的方式是彻底退出进程而不是只关掉当前窗口。我第一次装完就踩了第二个坑用superpowers命令初始化时选了只安装部分 skills结果某个工作流目录是空的触发时模型一脸茫然。后来我重新跑了一次初始化全量安装问题立刻消失。3. 实战用 Superpowers 的 TDD 工作流开发一个 Java 模块3.1 我准备的任务为了讲清楚它工作流和裸 Codex 的差别我准备了一个小任务给一个电商订单模块写折扣计算器。需求是这样的普通会员无折扣银卡会员订单满 1000 元打 95 折金卡会员订单满 500 元打 9 折满 2000 元打 85 折如果有优惠券满 300 减 50、满 500 减 100优惠券与等级折扣不能叠加取更优惠的一个。这个需求不算难但边界条件不少满减和打折的临界值、优惠券取更优的逻辑、不同会员等级叠加后取最小支付金额。是个非常适合演示 TDD 工作流的例子。3.2 我是怎么向 Codex 发号施令的打开 Codex我敲下的第一段指令是我们按 TDD 工作流来实现订单折扣计算器。需求如下 [贴需求] 先不急着写代码先按工作流来。这其实就是触发 Skill 的关键——你必须明确指定用 TDD 工作流。这个项目不会自动猜你要走哪个流程它是按需触发的。一旦它识别到指令就会说好的我将按照 TDD 工作流执行然后开始第一步写失败的测试。这里有个使用细节很重要第一次触发某个 workflow 时最好只点一次名不要同时说用 TDD 然后顺便把代码写了因为 Skill 手册里有明确的步骤顺序你的额外指令可能会干扰它对当前步骤的判断。等它走完一轮流程你再提额外要求也不迟。3.3 工作流执行过程的逐步观察这轮对话我完整盯着看它确实没让我失望。大致经历了这么几个阶段阶段一写测试。它先创建了一个测试类DiscountCalculatorTest.java不是随便写两个 happy path 用例就完事而是用参数化测试把所有边界条件列得清清楚楚999 元银卡不打折、1000 元整银卡打 95 折、金卡 500 元恰好打折、优惠券和等级折扣谁更划算……这一点和裸 Codex 的差异非常明显。我印象里不给它任何约束时它写测试通常是每个方法配一个用例但 TDD 工作流会强迫它在动手前把客户给的需求逐条翻译成可验证的测试用例。测试即需求文档这个理念它执行得很彻底。阶段二跑测试并确认失败。它没有直接开始写实现而是先编译并运行了测试把失败结果摆出来给你看。这一步很多人觉得多余但它实际上是在做两件事一是确认测试真的覆盖了需求二是建立红的状态。我在现场看到它自己把报错信息贴出来并分析目前还没有实现类所以编译失败是预期内的。阶段三最小实现。这一步它写得很克制只实现了让当前测试通过的最小代码没有顺手引入什么设计模式、没有提前抽象接口。我就喜欢它这一点让测试通过就是通过不在这个阶段炫技。阶段四跑绿。它重新跑了一遍测试确认全绿之后简单总结了一句所有测试通过可以进入重构阶段。阶段五重构。这是我个人觉得含金量最高的一步。它把计算逻辑里重复的 if 判断提取成了清晰的小方法并顺手消除了两个魔法数字。重构完成之后又跑了一遍测试确认行为没变。一轮下来它把红-绿-重构这个循环走出了标准示范的味道。3.4 和裸 Codex 相比差别到底在哪我用同样的需求、同样的模型版本另外开了一个不带 superpowers 的裸 Codex 对话做对比结果很有意思。裸 Codex 收到需求后第一反应是直接开写一个DiscountCalculator类带三个方法差不多 80 行代码一次性输出然后很礼貌地问我还需要调整吗。但它的代码里有个致命问题优惠券满 300 减 50 和银卡满 1000 打 95 折同时满足时它直接写了 if-else 取后者根本没做取更优惠的判断。原因很简单——它没在动手前把每个分支列成测试用例。对比项裸 CodexSuperpowers TDD 工作流动手前行为直接输出实现代码先列需求清单和测试用例边界条件覆盖容易漏判取优惠这类分支测试先行强制覆盖是否自动跑测试一般不跑除非要求每个阶段都自动跑代码增量节奏一次写一大坨最小变更逐阶段推进风险控制依赖模型临场发挥靠流程兜底这不是模型变聪明了而是流程让它必须多想一步。我觉得这才是AI 编程助手应该有的打开方式不是让它帮你写更多代码而是让它在写每一行代码之前都先想清楚为什么写。4. 我踩过的三个坑以及对应的解决办法4.1 坑一重装后 Skills 没生效升级 Codex 后直接失联我第一次用这个工具是在一个老版本 Codex 上后来 Codex 升级了一次我发现自己触发工作流时模型开始假装在走流程嘴上说着我们先写测试实际下一句就开始写实现了。我排查了很久最后发现问题出在 Codex 升级后插件目录从~/.codex迁移到了~/.config/codex而 superpowers 初始化时写入的还是旧路径。解决办法也很简单重新跑一遍superpowers初始化命令它会自动检测当前 Codex 使用的配置目录。这里也提醒大家升级 Codex 之后如果发现工作流失效第一件事不是重装模型而是确认配置目录有没有变。4.2 坑二多个工作流互相打架有段时间我在一个项目里既想走 brainstorm 的需求澄清又想让 AI 直接进入 TDD 实现。结果它在同一个对话里同时参考了两个 SKILL.md导致了很尴尬的行为一边追问需求细节一边又把测试写了一半然后停下来问我方向对不对。后来我养成了一个习惯一个对话只激活一个核心工作流。需求澄清走 brainstorm方案确定之后另起一个新的 Codex 对话再触发 TDD。把不同阶段切到不同会话既避免上下文污染也减少 token 消耗。如果你确实想在一个会话里跑完多个流程我会建议显式地告诉它现在切换到下一个 workflow它一般会重置执行状态。4.3 坑三上下文和成本开销变大长任务跑一半缩水这是最现实的问题。加载一个 SKILL.md 要吃掉少则两三千、多则五六千 token加上工作流每个阶段都要停下来总结、确认一轮复杂任务下来token 消耗大概是裸 Codex 的两倍。我自己实际感受是短平快的小任务不值得开工作流。比如给这个工具类加一个方法直接问裸 Codex 就行了。但凡是涉及多文件修改、有明确业务规则、要保证测试覆盖率的任务开工作流的收益远大于那点 token 成本。省下来的不是钱是来回扯皮的时间。5. 我的使用心得和进阶玩法5.1 什么时候必须开、什么时候反而不要开用了一个多月之后我给自己定了一个简单的选择标准必须开工作流的场景有三类。第一需求本身有复杂规则比如多个条件叠加、有不同的优先级判定第二改动范围跨多个文件或模块需要先规划再动手第三代码是要长期维护的核心模块测试不能少。反过来也有两类场景我会刻意不开。一是纯探索性的小实验比如我想看看 Java 的某个新特性怎么用这种时候流程反而碍事。二是代码风格调整、重命名这类机械操作直接下指令更快。5.2 我最常用的组合技如果你已经用了几天想再进步一点我推荐一套组合拳brainstorm加writing-plans加tdd。具体做法是拿到一个不明确的需求时先触发 brainstorm让 AI 围绕目标列出多个实现方案并分别说明优缺点。选定方案之后在同一个项目但新的会话里触发 writing-plans让它把任务拆成带验收标准的实施计划。最后再按计划逐块用 tdd 实现。这套流程走下来我做功能开发时几乎体验不到返工了。因为 brainstorm 阶段已经把坑都填平了writing-plans 阶段把每个阶段的出口定义清楚了tdd 阶段只是按图施工。5.3 自定义你自己的 Skill 并不难最后聊聊扩展。superpowers 允许你往 skills 目录里丢自己的 SKILL.md格式和内置的一样。我举个例子我自己写过一个接口联调检查的 Skill内容大概是先让 AI 检查所有入参的校验逻辑、再对照接口文档核对返回码、最后输出一份调用示例。写下来也就是几十行 Markdown。写自定义 Skill 时记住一句话你要的不是让 AI做得更聪明而是让 AI按固定顺序检查固定东西。所以最好的自定义 Skill 都是把你平时最容易忘的那几步固化下来比如改完数据库表结构后必须检查所有引用这个表的 mapper。最后分享一个我实际用下来的小技巧不要把 superpowers 当成神它真正厉害的地方是把同一套流程稳定地跑一百遍。个人的经验也好、团队的规范也好写进 SKILL.md 里它就不会因为换模型、换对话而丢失。我现在已经把它当成团队代码规范之外的第二本操作规程每个新接手项目的同事我都会让他先把这个装好先让 AI 按规矩干活再去谈创造力。