最近几个月我一直在折腾 AI 辅助编程工具尤其是 OpenAI 的 Codex CLI。说实话刚上手的时候Codex 给我的感觉是“能写代码但像个刚毕业的实习生”——你扔给它一个任务它能写出一堆代码来但缺乏章法踩到坑了也不会自己回头找原因改了两轮还在原地打转。直到我在社区里看到有人提到一个叫 “superpowers” 的提示词配置包专门用来给 Codex CLI“开光”让它从“写代码的实习生”变成“能规划、会测试、能自查的研发搭档”我才真正觉得这玩意儿值得认真研究一下。这篇文章就是我实际安装、配置、用了几个星期之后的完整记录。内容会覆盖 superpowers 的核心设计思路、安装步骤、配置细节还会用 Java 项目作为一个完整示例演示它到底是怎么改变 Codex CLI 的工作方式的。适合已经装了 Codex CLI、但对输出质量不太满意的人也适合刚接触 AI 编程助手、想知道提示词工程到底能起多大作用的新手。1. superpowers 到底是什么为什么值得用先说结论superpowers 不是一个插件也不是一个独立的编程框架它本质上是一份精心编写的系统提示词system prompt配置文件。它的目标非常明确——把 OpenAI Codex CLI 从“一个被动的代码生成器”提升为“一个主动的、讲方法的研发协作者”。按我自己的理解Codex CLI 本身的能力上限并不低它用的是很新的模型能理解上下文、会改文件、能执行命令。但默认状态下它缺少工作方法。就像一个很聪明但没受过训练的新人聪明是真的聪明做事全靠临场发挥没有自己的节奏。而 superpowers 提供的就是一套完整的工作方法论它把研发流程拆成了几个清晰的阶段要求 Codex 在每个阶段都按特定的方式来思考和行动。这种方式的效果我在实际项目中体会很深。之前我让默认的 Codex CLI 写一个 Java 工具类它会直接给你扔出一个完整的文件看起来像模像样但你仔细一看没考虑边界条件没写测试甚至有些方法根本没被调用。同样的任务套上 superpowers 之后它会先问我要需求文档、检查项目现状自己规划任务清单然后一步一步地写代码、写测试、跑测试、再重构。整个过程的专业程度完全不像同一个工具。这项技术解决了几个非常实际的痛点代码质量不稳定。默认的 Codex 喜欢一口气生成大量代码但缺少验证和迭代。superpowers 强迫它小步前进每步都被验证。上下文管理混乱。Codex 的上下文窗口再大也是有限的把所有文件都塞进去不现实。superpowers 教它用tree、find、grep这类命令按需拉取信息而不是盲目读取。缺少自我检查机制。它会推动 Codex 养成“写完代码就跑测试、跑完测试再重构”的习惯形成一个闭环。如果你是那种只想让 AI 快速生成一段代码、然后自己手动收拾残局的人superpowers 可能反而会让你觉得“多此一举”。但如果你希望 AI 真的帮你干活从规划到实现再到验证都靠谱那这套配置就是刚需。2. 设计思路拆解interleaved 开发方法是怎么起作用的superpowers 最核心的思想是它称之为 “interleaved development”交错式开发的方法。这个概念说白了就是不要试图让 AI 一口气完成一个大任务而是让它按照“规划 → 小步实现 → 验证 → 再规划”的节奏像人类程序员一样工作。我一开始觉得这套流程有点“多此一举”但实际用下来真的不一样。默认 Codex 的处理方式是你给它一个需求它在脑子里过一遍然后吐代码而 superpowers 会不断在“思考”和“行动”之间切换模拟一个真实开发者在 IDE 里的工作状态。它不急着写文件先去看项目里有什么、当前代码怎么组织的、有哪些约束然后再动手。2.1 角色设定把 Codex 当成“初中级研发搭档”在 superpowers 的提示词里Codex 被明确设定为一个“junior developer”的角色。这不是贬低而是一种巧妙的引导方式。junior developer 的特点是什么经验不足但态度好会勤快地查阅资料、写测试、遇到不确定的事会问。这个设定带来的实际影响是Codex 不再“自作主张”地做一些大型架构决策而是倾向于向用户确认需求、给出多种方案、在重要节点上请求反馈。特别是当你给它一个模糊任务时它不会瞎猜而是会先问清楚输入输出、边界条件、技术栈限制。这套逻辑在复杂项目里尤为重要因为模糊需求直接开工的后果就是返工。2.2 自述文件驱动的规划模式superpowers 的另一个关键设计是“README-driven development”。它要求 Codex 在动手前先写或更新一个 README 文件用自然语言描述你要构建的东西它是什么、解决什么问题、怎么用、有哪些功能模块。这个 README 不是给用户看的文档而是给 AI 自己的“作战地图”。你可能觉得“让 AI 写文档太浪费时间了”但我实际的体验是让 AI 先写 README本质上是逼它先做设计。一个连功能清单和边界条件都说不清楚的程序代码写得再快也是白搭。而且 README 文件是持久化的就算上下文被清空、对话被打断下次重新开始任务时Codex 只要读一下 README 就能快速恢复状态。这个思路非常值得借鉴——它解决了 AI 编程里最让人头疼的“状态丢失”问题。2.3 测试驱动RED-GREEN-REFACTOR 循环凡是认真做过工程的人都知道测试不是可选项而是程序员的“安全网”。superpowers 把测试驱动开发TDD直接写进了提示词里要求 Codex 按照 RED-GREEN-REFACTOR 的循环来工作RED先写一个失败的测试明确新功能应该表现为什么。GREEN用最少的代码让测试通过不追求完美。REFACTOR在不改变外部行为的前提下重构代码去掉重复和坏味道。这个循环的威力在于它让 AI 的每一步都有明确的“完成定义”。写代码之前先写测试相当于给任务加了一个验收标准Codex 不会跑偏。而且每完成一个功能点它都会跑一遍全部测试确保没有把之前好的功能改坏掉。这种迭代方式让代码质量稳定得多。2.4 分块工作与上下文压缩大模型的上下文窗口是有限的哪怕是现在很长的上下文也架不住项目文件一多就爆掉。superpowers 的提示词里明确要求 Codex 使用“bits and pieces”的工作方式——即一次只处理一个功能点或一个模块不要试图同时修改十几个文件。与此同时它还教 Codex 更聪明地利用 Shell 工具。比如不再直接cat一个巨大的文件而是先用grep定位关键代码行再精准提取片段用tree查看项目结构而不是盲目猜测用find查找文件路径。这些是每个有经验的程序员日常都会做的事情但对 AI 而言如果不写进提示词里它真的会忘记。从这个角度来说superpowers 本质上是把一个成熟开发者的工作习惯翻译成了模型能理解的语言。它不是魔法而是方法论。3. 安装与配置实测让 Codex CLI 加载 superpowers接下来是重头戏——怎么把 superpowers 装到你的 Codex CLI 里。整个流程并不复杂但有几个细节没搞对的话配置不会生效。我先说一遍思路再给具体步骤。先交代一下我的环境macOS已安装 Node.js版本 20Codex CLI 已通过 npm 安装并完成了登录认证。Windows 和 Linux 上的操作大同小异主要是路径写法略有不同。3.1 获取 superpowers 配置文件superpowers 是以开源配置仓库的形式发布的最稳妥的方式是从 GitHub 上克隆一份到本地。你需要找到社区维护的codex-superpowers项目把它克隆到一个你方便管理的目录里比如~/.codex/superpowers。git clone https://github.com/obra/codex-superpowers.git ~/.codex/superpowers克隆下来之后建议先看一下目录结构。一般会有一个核心的提示词文件比如AGENTS.md或superpowers.md以及一些示例配置文件和辅助工具脚本。你不用全看懂只需要确认核心提示词文件存在就行。3.2 修改 Codex CLI 的配置文件Codex CLI 的配置文件一般在~/.codex/config.toml。如果没有这个文件可以先运行一次codex命令让它自动生成或者手动新建。配置文件里需要指定一个extra_body或者system_prompt之类的字段把 superpowers 的内容注入进去。不过不同版本的 Codex CLI 配置结构略有不同最直接的方式是看代码库里的安装说明。我当时的做法是编辑config.toml添加model_prompt path/to/superpowers.md之类的配置项。如果版本不支持这个字段就在启动 Codex 时通过参数手动指定提示词文件。我在实测中发现最稳妥的方式其实是先用最小配置验证能不能生效。你可以先做一个简单测试在配置文件里指定 superpowers 的提示词路径然后在任意目录执行codex问一句“你现在的工作方式是什么”。如果回复里出现了“junior developer”“interleaved development”等关键词说明配置生效了。3.3 用 codex 命令手动加载提示词如果你不想动全局配置也可以用更直接的方式每次启动时手动指定提示词文件。比如codex --prompt-file ~/.codex/superpowers/superpowers.md这个方式的好处是灵活不同项目可以用不同的提示词配置。缺点是每次都要带参数容易忘。我个人的习惯是全局配置里放一份通用的 superpowers特殊情况再手动追加项目专属的提示词。3.4 验证安装成功与否的三种方式验证配置是否生效光看配置文件的路径还不够建议按下面三种方式逐一确认方式一对话试探。直接问 Codex 它的工作方式看它是否会提到“测试驱动”“README 规划”等关键词。方式二行为测试。让它完成一个简单的编码任务然后看它是否先写测试再写实现。如果它仍然直接甩代码说明配置没加载成功。方式三日志确认。Codex CLI 有调试日志可以用 verbose 模式启动看启动时是否加载了你指定的提示词文件。我第一次配置的时候就踩过坑配置文件路径写错了但 Codex CLI 没有报错只是悄悄忽略掉了无效路径。所以验证那一步千万别省。4. Java 项目实操用 superpowers 开发一个数据处理工具前面的安装和配置只是热身真正有意思的是把 superpowers 用在实际项目里。因为热词里出现了“superpowers java”我就以 Java 项目为例完整演示一遍从需求到测试通过的实际流程。为了让大家看得更清楚我会用一个非常典型但不无聊的场景写一个 CSV 数据清洗工具。4.1 项目需求与初始状态假设我们有这样一个需求读取一个 CSV 文件过滤掉无效行空行、字段数量不对的行对指定列做去重最后输出清洗后的 CSV 文件。这个需求看起来简单但边界条件其实很多文件不存在怎么办、CSV 字段里有逗号怎么办、去重依据是哪一列、输出编码是什么。我在实操时项目目录是空白的只放了一个示例 CSV 文件用来测试。启动 Codex 时我先告诉它完整的需求描述然后看它怎么规划。4.2 Codex 的第一次响应不是写代码而是做规划套上 superpowers 之后Codex 的第一反应不是创建 Java 类而是先做规划。它看了项目目录确认了 JDK 版本和构建工具我的环境里只有 JDK没有 Maven 或 Gradle它决定用纯 JDK 编译顺便把构建脚本也写了。然后它给出了一套任务清单创建 README记录项目目标和命令用法。设计核心类CsvCleaner定义输入输出结构。编写测试类覆盖有效行保留、无效行过滤、重复行去重、文件缺失异常等场景。实现核心逻辑跑通测试。最后提供一个命令行入口类Main。这个规划看着不惊艳但和默认 Codex 的差别已经出来了——它没有再问我“你想要什么”而是直接给了完整的实施方案并且每一项都对应一个可验证的结果。4.3 测试先行核心逻辑的 TDD 过程在真正写实现之前Codex 先创建了CsvCleanerTest.java。测试用例覆盖了这些场景输入两行重复数据输出只有一行输入含空行和错误字段数的记录输出自动过滤文件不存在时抛出带提示信息的异常包含逗号的字段带引号包裹能正确解析。写完测试后它运行了一次编译和测试毫无疑问测试失败了。这正是 RED 阶段的正常状态。然后它才动手写CsvCleaner的实现。实现过程中它手动解析 CSV 而不是直接引入 OpenCSV 依赖这在没有 Maven 的纯 JDK 环境里是合理选择。代码写完后它重新运行测试全绿。接着进入 REFACTOR 阶段把解析逻辑单独抽成一个私有方法去掉重复代码优化异常信息。整个过程行云流水每一步它都会贴出关键命令和运行结果我能清楚看到它在做什么、为什么这么做。4.4 命令行入口与联调验证实现完核心类之后Codex 创建了Main.java负责接收命令行参数输入文件、输出文件、去重列索引然后调用CsvCleaner完成清洗。它还在 README 里写了完整的运行示例javac -encoding UTF-8 *.java java Main input.csv output.csv 0我照着命令跑了一遍输入的是一个包含空行、重复行和脏数据的 CSV输出文件干净整齐。整个流程从规划到实现再到验证大概十分钟中间我几乎没有动手。这种体验和之前“让 AI 写个类然后自己返工”的体验完全是两回事。4.5 Java 项目中使用 superpowers 的注意事项在 Java 项目里用这套流程有几个问题值得留意构建工具差异Codex 默认可能会假设项目用 Maven 或 Gradle但如果你的环境是纯 JDK一定要在需求里明确交代。否则它生成一堆依赖管理文件反而增加复杂度。Java 版本相关特性如果你的项目用的是 Java 8而 Codex 默认生成 Java 17 的语法编译就会报错。建议在项目描述里写清楚source/target版本。测试框架选择superpowers 默认倾向于使用 JUnit但如果项目里没有 JUnit 依赖它会建议用简单的main方法断言来替代。这个灵活度还不错但如果你自己有偏好最好一开始就跟它说清楚。5. 常见问题与排查技巧实录用了 superpowers 这段时间我在实践里积累了不少避坑经验。这里整理几个最容易遇到的问题以及对应的排查思路方便你少走弯路。5.1 配置文件加载不生效这是最常踩的坑。具体表现是你以为已经配置好了但 Codex 的行为没有任何变化。排查思路如下第一步检查配置文件路径是否真实存在。Codex 不会因为你写了一个不存在的路径就报错它只是静默忽略。第二步检查配置文件里是否写错了字段名。不同版本配置字段不一致建议查看 Codex 官方文档确认当前版本支持的配置方式。第三步用codex --verbose启动看日志里的提示词加载记录。日志里没有 superpowers 关键词就说明没加载成功。5.2 上下文太长导致任务中断superpowers 会引导 Codex 用 Shell 精准获取信息但当项目特别大时还是有上下文超限的风险。我的经验是给 Codex 指定一个“工作目录”范围让它只关注相关模块。比如直接把工作目录指定到某个子项目目录而不是整个仓库的根目录。另外不要让 Codex 一次性把多个大文件塞进上下文。如果任务必须涉及多个文件试着提醒它“只读关键行”或者用具体指令让它提取特定函数。superpowers 本身的提示词里已经包含这些约束但模型偶尔还是会“越界”这时你的提醒就是最后一道防线。5.3 测试跑得慢或依赖外部服务superpowers 强迫 Codex 写测试、跑测试这是好事但遇到需要访问数据库、外部 API 的模块时单元测试可能会变成集成测试速度慢还容易失败。我的做法是在任务描述里明确“不要为外部依赖编写联机测试使用 mock 或本地模拟”。Codex 很听话只要在需求阶段把边界标清楚它不会硬着头皮去写一个需要 Redis 的测试。5.4 Codex 陷入修改循环无法收敛偶尔会遇到 Codex 在某个问题上反复修改比如测试一直不通过它不断调整实现但始终没找到根因。这种时候我建议直接打断它让它先停下来用 grep 或日志找出真正的报错信息。或者干脆让它“停止修改回到最近一次通过的代码重新分析问题”。superpowers 的提示词里其实已经内置了“停止不必要的修改”的约束但模型不是机器偶尔还是会有“屡败屡战”的情况。作为人类搭档你需要适时踩一下刹车告诉它“别试了先分析”。这恰恰说明这套配置永远没法完全替代一个清醒的头脑。5.5 superpowers 与其它 AI 工具的兼容性这套提示词配置虽然是为 Codex CLI 设计的但核心思路也可以迁移到其他 AI 编程工具。比如你在 Cursor 或 Continue 里也可以手动粘贴核心指令让它们以同样的节奏工作。不过效果可能略有差异因为不同工具的模型配置和上下文管理策略不一样。我在别的工具上只做过轻量测试结论是模型能力越强提示词发挥的空间越大。如果底层模型本身很弱再好的提示词也救不回来。5.6 快速排查表症状可能原因推荐操作行为无变化像没装一样配置路径或字段名错误用 verbose 日志查看加载情况生成的 Java 代码编译失败Java 版本不匹配明确写明当前 JDK 版本项目文件被大范围修改没有限定任务范围明确指出“只改某模块”测试长期不通过需求边界不清或环境依赖停止修改先查根因上下文窗口超限读取了过多大文件提醒它用 grep 精准定位6. 使用边界与个人经验补充到这里superpowers 的主要内容和实操流程都讲完了。最后我想多聊几句自己的感受和边界认知这部分可能比技术细节更有参考价值。6.1 它不是银弹但它极大降低了“返工率”superpowers 给我最深的印象是它能显著降低 AI 编程的返工率。默认的 Codex 经常给你一个“看起来能跑但完全不想 review”的一坨代码而 superpowers 驱动的 Codex每一步都有明确节奏测试也是同步写好的你 review 起来心里有底因为关键行为已经被测试锁住了。当然如果你只想要一个快速原型不想关心测试不想写 README那 superpowers 的流程确实会显得“重”。我的建议是分场景探索性代码可以直接用默认模式正式的、要长期维护的业务代码请务必挂上 superpowers。6.2 提示词工程的上限与下限从一个更广的视角看superpowers 让我重新理解了提示词工程的价值。以前我以为提示词工程就是“把需求写清楚一点”但 superpowers 展示的是提示词可以把一个工具的工作方式整个扭转过来。它不改变模型权重却能改变模型的实际输出质量这种“软的升级”效果非常惊人。同时也要务实一点提示词工程解决的是“怎么把能力用好”的问题不是“能力从无到有”的问题。如果模型根本没有相关的知识储备再精妙的提示词也没法让它凭空生成正确代码。所以 superpowers 不是万能灵药它是让本来就强大的模型充分发挥潜力的催化剂。6.3 最后分享一个我亲身实践的小技巧我在用 superpowers 的时候养成了一个习惯每个项目的第一条指令先不讲需求而是让 Codex 描述一下项目现状。比如“先用 tree 看一下项目结构然后告诉我你打算怎么完成这个任务”。这个简单的开场等于在变相提醒 Codex 按照规划-实施-验证的思路走。尤其是复杂项目里这一句很顶用能避免它一头扎进代码里出不来。如果有朋友想在团队里推广这套做法我的建议是别一上来就全员要求“必须用超级提示词”。先从一两个不太紧急、但有一定复杂度的项目试点把整个流程跑顺了再慢慢扩大范围。这东西用好了确实能提升效率但要是把它当成理所当然的“自动化硅基员工”团队成员没有一个懂底层原理出了问题都不知道怎么排查反而容易翻车。