1. 为什么我会给 Codex CLI 装一个叫 Superpowers 的扩展如果你最近用 AI 编程助手比较多一定会有这种感觉它确实能写代码但总差一口气。让它改个 bug它能给出一个中规中矩的补丁让它帮你做代码审查它就简单说过一遍让它规划一个多文件重构它甚至可能直接胡来。你要的不是一个会打字的替代品而是一个能按你工作方式思考的搭档。我前段时间一直在折腾 Codex CLI用下来最大的感受是默认状态下它太老实了。你问什么它答什么执行能力没问题但缺少工程感。后来在社区里翻到一个叫 Superpowers 的技能增强方案简单说就是给 Codex 塞了一整套技能包让它从会写代码变成会按工程规范干活。这个思路完美解决了我的核心痛点不是模型变聪明了而是它的工作流程变规范了。这篇文章不打算写什么玄乎的理念就讲我这两周从安装、配置到实际跑项目的完整经历包括哪些技能包真正有用、哪些我直接关了、还有我踩过的几个坑。先说清楚应用场景Superpowers 适合谁我的判断是——如果你已经用 CLI 版的 AI 编程工具有一段时间并且不满足于对话式补代码而是想让 AI 帮你承担代码审查、测试生成、任务拆解、提交信息规范这类工程化事务那这套技能库值得认真研究。如果你是纯新手刚装好 Codex CLI 还没跑顺我建议先熟悉基础操作再来折腾不然技能包带来的新概念会让你更混乱。先说一个重要的结论Superpowers 不是一个新的 AI 模型它是一套提示词工程化的技能包集合通过改变 AI 处理任务的方式让工具输出更接近资深工程师的工作成果。这和换一个更强的模型是两条完全不同的路线两者可以叠加。2. 安装之前必须想清楚的事技能包的本质是约束很多人在安装 Superpowers 之前有一个误解以为装了之后 AI 会变得更聪明。实际不是。技能包做的事情不是放大模型能力而是缩小模型的自由发挥空间。比如没有技能包时你让 AI 写一个 commit message它倾向于生成fix: update stuff这种毫无信息量的描述。挂了 commit-message 技能包之后它会强制自己先分析改动类型、影响范围、是否包含破坏性变更然后再按规范输出。模型本身的智力没有提升但输出质量提升了因为工作流程变严苛了。所以安装之前你要做一个决定你愿意接受多大程度的流程约束我刚开始没想清楚这个问题一股脑把所有技能包都装上了。结果用起来极其痛苦每次对话它都要先做一堆分析与确认本来两分钟能搞定的小需求被它折腾成十几分钟的拉锯战。后来我才意识到Superpowers 这类技能库在设计上默认用户是在跑正经项目而不是在玩快速 demo。它更适合一个人面对复杂代码库时的深度工作不适合闲聊式编程。这就是安装前最重要的心理建设你不是在给 AI 装一个外挂而是在给它立一套规矩。规矩越多它越稳但代价是响应节奏变慢。下面第三节我会给出我最终保留的技能包清单和理由。安装层面Superpowers 目前是依托 Codex CLI 的配置体系来工作的。也就是说你需要有一个能正常运行的 Codex CLI 环境。如果你还没有先装好 CLI 并至少完成一次基础对话确认 API 配置、网络状况正常再继续下面的步骤。3. 安装与初始化我完整的落地步骤与参数调整Superpowers 的安装并不复杂核心是下载技能包文件、写配置、指定技能加载路径三个环节。网上不少教程写得云里雾里这里我给你一个按顺序执行的版本。3.1 第一步获取技能包我用的是 npm 全局安装这条路线。因为技能包本身是一个包含多个 markdown 技能定义文件的目录用工具链管理更新更方便。执行npm install -g superpowers-skills装完之后确认一下版本superpowers-skills --version如果你用的是 pnpm 或 yarn命令思路一样。注意不要用 npx 临时跑因为技能文件通常需要在全局目录中稳定存在后面 Codex CLI 的配置要指向它。3.2 第二步定位技能包目录这一步很容易被忽略。安装完成后你需要拿到技能包的实际存放路径。在 macOS/Linux 上通常位于 npm 的全局目录下。执行npm root -g然后在输出目录下找 superpowers-skills 相关的文件夹。完整的技能目录看起来像/usr/local/lib/node_modules/superpowers-skills/skills/ ├── code-review/ ├── commit-message/ ├── unit-test-generation/ ├── refactoring-planner/ ├── bug-analysis/ └── ...这里每一个子目录就是一个技能包里面是结构化的 markdown 提示词文件。你可以直接打开看看里面写了什么——相信我这些内容本身就是极佳的学习材料看得出技能包作者是如何拆解一个工程任务的。3.3 第三步在 Codex CLI 中注册技能目录Codex CLI 的配置我以~/.codex/config.toml为例。你需要确认配置里存在指令加载目录的字段然后加入技能包的路径。我的配置长这样[model] provider openai name gpt-4o [instructions] enabled true paths [ /usr/local/lib/node_modules/superpowers-skills/skills ]这里有几个细节enabled true必须打开否则路径配了也不会加载。paths字段填的是包含多个技能子目录的父目录不是单个技能的目录。填错了会导致技能包一个都加载不了。Codex CLI 版本不同字段名可能有差异。我遇到过老版本用[context]的情况升级后改成[instructions]。如果你改了配置不生效先看 CLI 版本和官方配置样例不要盲目照抄别人的博客。3.4 第四步验证技能包是否被加载配置完成后重启 Codex CLI然后直接问它一句你当前加载了哪些技能包请逐条列出它们的名称和用途。如果配置成功它会列出一串技能名并且描述得头头是道。如果它告诉你我没有加载任何技能包那基本就是路径配置错误或者父目录层级不对。另一个快速验证方式是询问某个技能包的具体工作流程比如commit-message 技能包的判断步骤是什么它能背出来就说明加载成功了。3.5 第五步精确控制每个技能的开关这里是我踩坑之后摸索出来的关键调整。不要所有技能包一刀切全部启用Superpowers 的配置支持针对单个技能的启停控制。我最终只保留了六个技能把其余的全关掉了保留技能启用的原因code-review代码审查是我最需要标准化的环节commit-message规范化提交信息让项目历史可读性大幅提升unit-test-generation补测试时不再漫无目的地乱猜bug-analysis排查线上问题时能建立完整的假设链refactoring-planner大改动之前强制做影响面分析learning-explainer读陌生代码库时能按我的提问深度分层解释另外还有执行类、辅助创意类等技能我暂时关闭了。原因后面踩坑部分细说。关闭方式是移除配置路径中的对应子目录或者在技能文件头部设置禁用标记——具体看你想做到什么粒度。4. 核心技能包逐个拆解哪个真正解决了我的痛点4.1 code-review从复读机到挑刺专家没有挂技能包之前我让 AI review 代码它给我的反馈大多是逻辑看起来没问题建议增加注释函数名可以更清晰这类正确但废话的内容。挂了 code-review 技能包之后它的审查流程完全变了先识别本次改动的核心意图再逐文件核对变更是否有超出意图的隐藏改动三检查异常分支处理四评估测试覆盖是否跟上最后才给出优化建议。我用一个实际案例说说区别。有一次我在一个支付回调的函数里顺手改了一条日志记录的字段没动任何逻辑。旧版 Codex 的 review 结果只说日志格式变更不影响功能。挂技能包之后它第一句话是本次改动与代码提交声明的修复并发问题目标不符建议拆分为独立提交另外日志字段变更会影响监控告警的解析规则需要同步检查告警配置。这个反馈深度完全不在一个层面。4.2 commit-message根治了提交信息贫瘠症这个技能包给我带来的收益最直观。它要求 Codex 在生成 commit message 前先执行三个子步骤通过git diff和git status收集完整变更清单。判断是否包含不可分割的多主题改动如果包含主动建议拆分提交。按 Conventional Commits 规范组织 message并在正文里写清楚为什么改而不是只写改了什么。以前我提交代码时最爱写update、fix bug这种毫无营养的信息现在模型会盯着我把为什么改这一栏补全。这个技能还带了一个 commit-narrator 的子模式可以把一次混乱的大提交自动拆分成逻辑清晰的提交序列。对于维护开源项目、或者需要频繁向团队同步进度的场景这个技能包的价值非常高。4.3 unit-test-generation测试生成从凑数变成推演我以前对 AI 生成单测的态度比较抵触因为它生成的测试常常是为了覆盖而覆盖断言软弱极端情况缺失。unit-test-generation 技能包给我的最大改变是它坚持先阅读被测试函数的完整上下文列出可能的分支条件和边界值再开始写测试用例。它甚至会主动问我要不要 mock 外部依赖、期望的覆盖率目标是多少。实际操作中我还总结了一个配合技巧在让技能生成测试之前先让它输出一份测试计划包含用例清单和每个用例要验证的假设。我确认计划无误后再让它填充测试代码。虽然多了一轮交互但测试质量提升了不只一个档次。4.4 bug-analysis排查问题的思路链bug-analysis 技能的触发方式是让我描述现象然后它会先产出一份问题分析框架包含已知信息、假设列表、验证方法、可能根因排序。这个过程本质上是把资深工程师头脑中的排查路径显性化了。举个例子。我之前遇到一个偶发的空指针异常堆栈信息指向一个工具类方法。代码审查半天看不出问题。技能包引导我一步步补充信息触发频率、相关线程模型、最近是否有相关提交、是否与配置项相关。最后把怀疑点引向了一个我完全没想到的并发初始化时序问题。说实话它给出的假设不全是它自己想出来的有一部分是我在回答它问题的过程中自己想到的但这种引导式排查恰恰是 AI 协作的最佳姿势——它不替你思考它逼你按流程思考。4.5 refactoring-planner大型重构前的刹车片我性格比较急遇到坏味道代码经常直接上手改。refactoring-planner 是这个技能包里我最开始最不重视、后来觉得最救命的一个。它强制我在重构前先定义重构目标、约束条件、受影响模块清单、风险点、回滚方案。然后才让我开始动手。用它的方式重构一个模块过程像在做代码手术先评估再切割逐步替换最后验证。它给的六步流程是识别坏味道、分析依赖关系、设计目标结构、制定迁移路径、执行小步重构、持续验证。我照做之后重构过程突然变得可控了——因为你永远知道下一步该干什么以及如果这一步出错怎么退回来。5. 实际使用中的踩坑记录报错、误判与对策5.1 技能包之间的内讧问题技能包加载多了之后模型有时会混淆任务归属。典型的例子是我让 Codex 写测试它却启动了 code-review 的审查流程洋洋洒洒分析代码质量和可维护性就是不写测试。后来我发现原因在于多个技能提示词都包含在开始之前先分析……这类指令模型在执行时容易串场。对策很简单配置里调整上下文优先级同时不在同一条消息里下达两个分属不同技能包的任务。一开始我觉得这很蠢后来想明白了——它毕竟是一个套着提示词外衣的系统技能包之间有指令冲突是必然的。你的使用习惯要跟着调整。5.2 AI 过度确认拖慢节奏加载技能包之后模型变啰嗦了。以前我说给这段代码加上参数校验它会直接开干现在它先回一堆分析你希望校验哪几个参数遇到非法值时抛出异常还是返回错误码需要覆盖边界情况吗如果你手里有十个小改动要做这种交互频率会把人逼疯。我的处理方案是分级使用启动快速改动任务时在开头明确写一句跳过流程分析直接执行启动复杂任务时才有意识地让它输出分析过程。技能包是在你打算用工程化方式做事时才调用的不是每时每刻都开着。5.3 技能目录更新导致的路径失效npm 全局包升级之后路径可能变化最直观的表现是技能包突然全部失效。我第一次升级时被这个问题坑了半天还以为是配置写错了。建议把技能包路径写成一个稳定的软链而不是直接写 node_modules 下的版本化路径ln -s /usr/local/lib/node_modules/superpowers-skills/skills ~/.codex/superpowers-skills然后在配置里指向~/.codex/superpowers-skills。之后升级 npm 包软链依然有效不会再出现路径漂移。5.4 技能包对上下文的消耗远高于预期我使用过程中最明显的性能变化是上下文消耗变大。每个技能包动辄数千字的提示词加载五六个技能包之后一次会话的有效上下文被吃掉不少。遇到超长代码文件时模型经常忘掉早期的技能约束行为退化。对策有两个方向。一是数量控制我已经砍掉了至少一半的技能包只保留最常用的。二是会话管理复杂任务单独开新会话需要技能包开头就给它明确的加载指令而不是每天一个长会话挂着所有事。6. 把它用进日常开发我目前的工作流与建议经过两周调教我现在的日常开发流程基本稳定下来了。每天开工后我会开一个专门的会话用于代码审查把昨天产出的 diff 全部丢给它过一遍再开一个会话做测试补充和重构规划功能开发则用普通会话不加载额外技能包保持轻快。这样分工之后AI 协作的体验变得很有节奏感开发时它是个快速执行者审查时它是个严格评审人重构时它是个风险提示器。同一个模型凭的是不同技能包的切换就实现了不同的工作人格。如果你也想把 Superpowers 引入自己的工作流我给你三条建议第一不要全量安装。花一个小时逐个阅读技能包的 md 文件挑选与你日常工作重叠度最高的三到五个。技能包不是越多越好而是越精准越好。第二把技能包当配置管理而不是当插件。自己有必要维护一份技能包的启用清单记录哪些开启、哪些关闭、为什么。等你积累了经验甚至可以自己修改技能包里的提示词把它调教成符合你个人风格的工具。第三重视它带给你的思维方式而不只是输出。Superpowers 给我最大的启发不是工具本身而是它逼我看清了专家和新手处理任务时的差异——专家在各种节点都会停下来问自己我到底在干什么、有没有遗漏什么。技能包简单粗暴地把这些自问变成了流程逼着 AI 按流程走。这个思路即使哪一天你不用 Superpowers 了也值得迁移到你自己对 AI 的提问方式里。我目前还在持续调教它的技能配置下一步准备把团队编码规范里的特殊要求写进自定义技能让 Codex 的审查更贴合我们项目自己的风格。这个方向我觉得比等一个新模型更有实用价值——毕竟模型隔几个月升级一次而你的工程规范每天都在长。