前阵子我被 Codex CLI 搞到差点崩溃让它给项目加一个导出功能它闷头改了 17 个文件顺手把我原来的分页逻辑整个重构了一遍。代码能跑但 code review 的时候我看着那几百行 diff 真的非常痛苦。后来同事甩给我一个 GitHub 链接名字就叫 superpowers。说实话第一眼看到这名字觉得有点中二但抱着死马当活马医的心态装好后试了一周真香。superpowers 不是一个具体函数库也不是传统意义上的插件而是一套给 AI 编程代理用的 skills 技能集。它解决的是很多 AI 代理最让人头疼的问题模型知道怎么写代码但不知道什么叫好好干活。这篇文章我会从实际使用者的角度讲清楚 superpowers 到底是什么、怎么在 Codex CLI 里装、里面几个核心技能是怎么约束代理的、怎么把它迁移到 Trae Work CN 这类平台以及我踩过的几个坑。1. 初见 superpowers它到底给 Codex 加了什么 buff1.1 为什么我觉得 AI 编程代理“缺根弦”我一开始用 Codex CLI 的时候心态和很多朋友一样觉得它就是个加强版自动补全丢一个任务进去它把代码改完我 review 一下就完事。结果用了两天我就发现问题了——模型确实聪明但它完全没有“工程习惯”。打个比方AI 编程代理就像一个刚毕业、能力很强但没进过正规团队的程序员你让他加一个字段他恨不得把整个数据库结构、接口层、页面样式全改一遍你让他修一个 bug他上来就在你觉得最可疑的地方贴一段新逻辑根本不做最小复现也不确认是不是真正的问题点。这种“能干但不会干活”的状态用久了真的会让人血压升高。后来我意识到这其实不是模型能力的问题而是缺少一套“操作守则”。模型不是不懂代码而是不知道该在什么时候做什么事。它需要有人告诉它接到需求先拆任务改代码前先写测试出问题先定位根因。superpowers 干的就是这件事——把资深工程师的隐性工作习惯变成一段段模型能读、能照做的显性指令。1.2 superpowers 仓库里装的是什么superpowers 本质是一个 GitHub 上的开源项目你搜“superpowers github”就能找到。这个仓库里装的是一堆 skills也就是技能包。每个技能包通常是一个目录里面包含一个 SKILL.md 主文件可能还有示例、模板、辅助脚本。模型在会话中读到这些文件后会被要求按照里面定义的流程来做事情。我从最开始用的版本里挑几个典型技能出来你会发现都是正常开发者最需要的东西planning负责任务拆解和实施计划test-driven-development强制先写测试再写实现debugging引导代理用可复现、可验证的方式排查问题code-review让模型在做完改动后以审查者视角重新看一遍代码甚至还有 memlog 这种东西用来维护项目决策记录。这些技能不是普通的编程教程文档而是给模型看的“行为规范”。比如 SKILL.md 里会写明当用户提出需求时你不能立刻写代码必须先把需求拆成步骤明确每个步骤的输入输出和完成标准等用户确认后再动手。模型读到这些规则后输出的行为模式会明显不一样。1.3 它跟普通提示词模板的区别可能有朋友会说这种规则我自己写在 AGENTS.md 里不也一样吗说实话单看某一条规则确实没有本质差别。superpowers 的价值在于“系统化”和“可组合”。它不是一句“你要先做计划”而是把计划流程、验收标准、异常情况处理都写成一套完整协议。技能之间还能互相调用比如调试的时候如果发现需要新功能它会主动告诉你要不要进入 TDD 流程。另外社区维护也是它比个人提示词强的地方。模型的版本在变API 的行为在变提示词也得跟着变。普通开发者很难持续跟踪这些变化而 superpowers 这类项目会定期更新技能定义跟着模型迭代做调整。你只需要拉最新代码就能保持规则的可用性。2. 在 Codex CLI 里安装 superpowers 的实操流程2.1 安装前的环境检查网上搜“codex cli 安装 superpowers”出来的教程很碎有的说一条命令搞定有的说要改一堆配置。我这里给你一套我实际跑通且验证过的流程至少在我当前用的环境下是可靠的。先做三样准备一个已经登录好的 Codex CLI一个能正常使用的 Node.js 环境还有一个 git。检查命令很简单codex --version codex login node --version git --versionCodex 版本不同技能加载的路径会有细微差别但大部分版本都支持本地技能目录。模型方面我建议至少用指令跟随能力比较强的模型不然技能文件再多也白搭。我自己测试的时候用过 GPT-5 模型和 Claude 系列模型superpowers 都能正常加载只是不同模型的遵守程度会有差异这个后面细说。2.2 clone 技能仓库与目录放置我把 superpowers 仓库 clone 到了 Codex 的用户级技能目录这样所有项目都能用不用每个项目都复制一遍。命令大致是这样的mkdir -p ~/.codex/skills git clone superpowers仓库地址 ~/.codex/skills/superpowers注意这里的仓库地址要以你实际找到的页面为准GitHub 上同名的仓库和 fork 不少直接照抄别人的地址很容易装错版本。我的建议是点进仓库后先看 README确认它确实是你要的那个 skills 集合再复制地址。放在~/.codex/skills目录下还有一个好处后续更新方便直接在目录里执行git pull就能同步最新技能。如果你只想在单个项目里试验也可以 clone 到项目目录里但要记得把项目目录加入 Codex 的搜索范围否则技能永远不生效。2.3 让 Codex 识别技能的关键配置只把仓库 clone 下来是不够的很多教程在这里就结束了导致大家装完发现没效果。关键是要让 Codex 在每次会话中知道去哪里找技能并且知道什么时候该读这些文件。我用了两种方式组合起来效果最稳。第一种是全局配置在~/.codex/config.toml里添加技能路径的注册信息。不同版本的配置项名称不一样新版本可能直接支持skills_path老版本需要在环境变量或配置里手动指定路径。这一行写好后Codex 启动时就会把对应的技能目录纳入扫描范围。第二种是项目级引用在项目根目录的AGENTS.md里写一句明确指令比如“在开始任何任务之前请阅读~/.codex/skills/superpowers/下的核心规划技能并严格按照其中的流程执行”。因为 Codex 每次会话都会自动加载项目根目录的AGENTS.md这相当于把 superpowers 的核心规则固定在了每次对话中。如果你只想写一行配置那就写 AGENTS.md 引用它比纯目录扫描更可靠。模型不一定每次都会主动去翻技能目录但 AGENTS.md 是每次会话必然进入上下文的触发优先级高很多。2.4 安装验证一个最小测试用例安装完先别急着干大活用一个小任务验证一下。我在验证时用的方法是让 Codex“给项目写一个 README”。如果 superpowers 加载成功它不会上来就生成一段漂亮的 markdown而是会先输出自己的任务理解列出 README 需要包含哪些模块然后问我有没有补充需求。它会先做“计划动作”而不是直接“执行动作”。另一个更直接的验证方法是问模型“你当前加载了哪些技能”如果它能说出来 planning、TDD、debugging 这些名字说明技能文件已经进上下文了。如果它一头雾水大概率是路径配置不对或者 AGENTS.md 里的触发词不够明确。这时候我会回退到 2.3 里两种方式逐一排查是目录没注册成功还是引用文件里的表述被模型忽略了。3. 拆开看几个核心技能planning、TDD、debug 到底怎么工作3.1 planning让 AI 先写作战计划在 superpowers 的所有技能里我用的最多、收益最明显的应该是 planning。原因很简单AI 编程代理最大的问题不是写不出代码而是“写得太快”。你刚把需求描述完它代码已经生成了一大半结果方向错了后面全是白干。planning 技能会把“写代码”这个动作强行往后推。它的执行流程大概是第一步解析需求把模糊的表述转化成明确的问题清单第二步定义边界哪些做、哪些不做第三步把任务拆成足够小的实施单元第四步识别每个单元的风险和依赖第五步输出完整的实施计划等用户确认后再开始写代码。这套流程对我的帮助很大。拿之前的导出功能举例如果没装 superpowersCodex 第一版代码大概率是按 CSV 格式直接做的。但装了 planning 之后它会在动手前问我导出格式是 CSV 还是 Excel数据量大概多少是否需要筛选权限这些问题问完需求边界清楚得我都开始怀疑自己是不是漏了什么。整个过程看起来多了几次交互但实际省掉的返工远远超过那点会话成本。3.2 TDD 技能从红到绿的约束TDD 的基本思路一句话就能说清先写一个会失败的测试再写让它通过的最小实现。对真人开发者来说这需要自律对模型来说则需要指令约束。superpowers 里的 TDD 技能本质上就是把这条流程固化成了不可跳过的检查点。为什么这件事对 AI 编程特别重要因为模型生成的代码最容易出现的情况就是“看起来对但没有任何验证”。代码风格像模像样接口也调用了但一旦跑起来就崩。TDD 技能强制模型在实现前先执行测试看到失败输出后再写满足测试的代码最后看到测试通过才算完成。这相当于给模型的输出加了一道“必须有证据”的闸门。我在实际使用中会特意观察 Codex 有没有跳过红灯阶段。如果它直接开始写实现而没有任何测试先行的动作我会打断它让它重新按流程跑。多纠正几次后模型会逐渐习惯这个顺序。你甚至可以把这个技能和 planning 组合起来让模型在计划阶段就把测试用例设计清楚。3.3 debugging 和 code review查错与把关除了开发阶段的规划和控制superpowers 里的调试和审查技能也很实用。debugging 技能的核心是让模型停止“猜答案”。它会要求模型先复现 bug再通过日志、断言或最小样例定位问题范围然后用二分法缩小候选原因最后基于证据给出修复方案而不是凭直觉甩一段代码。这个流程和我平时教新人的思路几乎一样。模型本身对代码库有很强的全局理解但它经常高估自己找到根因的能力。debugging 技能本质上是在给模型的“直觉”加上约束让它每一步都有可复现的输出这样即使一开始方向错了也能通过证据快速纠偏。code-review 技能则适合在改动完成之后触发。我一般会在 Codex 完成一版功能后单独让它切换到审查者模式重新拉一遍 diff从正确性、安全性、可维护性三个角度挑毛病。很多时候它会发现自己前面实现里没处理好的边界条件或者指出某个函数命名和现有代码风格不一致。这个技能不需要全程开启手动触发反而更灵活。3.4 这些技能背后的设计逻辑把 planning、TDD、debugging、code-review 放在一起看你会发现它们有一个共同的内核把资深工程师的工作习惯编码成模型可以遵循的最小流程。模型不具备“常识”但它擅长模式匹配。只要你在流程里定义了“先做什么、后做什么、什么算完成”它就会比散装提示词稳定得多。这也是 superpowers 这个命名真正贴切的地方。它并不是给了模型更强的推理能力而是给了模型一套“老工程师附体”的操作协议。模型还是那个模型但行为表现完全不同。从这个角度看它更像一个行为框架而不是技术库。4. 把 superpowers 迁移到 Trae Work CN 和其他平台4.1 并不是只有 Codex 能用技能每次我聊 superpowers都会有人问“我只用 Trae Work CN能不能装”我的回答是能而且很多主流工具都能装只是叫法不一样。Cursor 里叫 rulesTrae 里可能叫项目规则或技能目录Claude Code 里有专门的 skills 机制。不管叫什么底层逻辑都是把一段结构化的指令注入到模型上下文中影响模型的后续行为。所以 superpowers 虽然最初我是在 Codex CLI 里装的但它本质上是一堆 markdown 文件天然具备跨平台迁移的可能。只要目标平台支持某种形式的角色设定或项目规则你就能把对应的技能内容“贴”进去或者通过引用文件的方式加载。4.2 迁移步骤复制、引用、调整触发以 Trae Work CN 为例我的做法分三步。第一步把 superpowers 仓库 clone 到本地一个固定目录比如~/superpowers方便后续更新。第二步在 Trae 项目里找到项目规则目录新建一个规则文件把核心技能的 SKILL.md 内容复制进去或者直接写一行“读取~/superpowers/planning/SKILL.md并严格遵守”。第三步调整触发方式CLI 工具适合自动加载IDE 工具则建议按需启用避免每次对话都塞一大堆内容。特别提醒一下IDE 类工具有上下文窗口压力直接把整个 superpowers 仓库几十个技能全部加进去并不明智。我自己的经验是只迁移最核心的三个技能planning、TDD、debugging。其他技能作为备用文档放在目录里等需要时再手动让模型读取这样既保证核心行为可控又不会挤占宝贵的上下文空间。4.3 平台间的行为差异与兼容处理不同平台对技能文件的读取方式差异比我想象中大。在 Codex CLI 里写在 AGENTS.md 中的指令几乎每次都会被认真对待但在 Trae Work CN 里如果只是把规则放在项目描述文件里模型不一定每次都会主动读取。我后来把它放进项目规则并开启了“每次对话都读取”的选项效果才和 Codex 下接近。还有一个容易被忽略的坑编辑器在保存文件时可能自动转换格式。superpowers 的 SKILL.md 里有不少代码块和 shell 命令示例如果用带格式的编辑器保存成富文本模型读取后可能会看到一堆渲染标记导致技能不生效。我的解决办法是统一用纯文本方式编辑这些规则文件保持原始 markdown 结构别让 IDE 自作聪明地改格式。5. 用了两周后的真实体感、坑和我的取舍5.1 最明显的收益上下文质量和返工率连续用了大概两周后我对 superpowers 的态度已经从“试试看”变成了“离不开”。最明显的变化是 Codex 的输出不再像一段孤立的代码而更像一个工程方案。它会在动手前给出任务拆解会主动提及风险点甚至会提醒我哪些改动可能影响现有模块。虽然多了一层确认交互但整体返工次数大幅下降。之前最消耗耐心的事情就是看它生成大段无关 diff。装了 planning 和 TDD 之后这类情况减少了很多。模型知道在什么节点该做什么事也知道“完成”的定义是什么。它不再为了追求速度而跳过验证至少在我的项目里代码质量提升了一个档次。5.2 踩过的坑上下文膨胀与技能冲突但superpowers也不是完全没有代价。第一个坑就是上下文爆炸。刚开始我把整个仓库的技能文件全部加载进会话结果模型光读规则就耗掉了大量 token甚至会出现前后技能定义互相干扰的情况。后来我改成只加载核心技能其他技能按需手动读取上下文压力立刻小了很多。第二个坑是技能触发词冲突。比如某个技能要求一遇到“报错”就走调试流程而调试流程里又要求先写测试结果模型在两种规则之间摇摆反而不知道该听谁的。我在 AGENTS.md 里加了明确的优先级顺序“先规划、后测试、再调试”才把行为稳定下来。第三个坑是模型版本带来的波动。同一个技能文件换一个模型版本后遵守程度可能完全不同。有的模型很听话每一流程都走有的模型则会选择性忽略。我的处理方式是在每次重要任务的会话开头先明确说一句“请严格遵循 superpowers 中的规划流程”相当于给技能规则做一次高亮强调。5.3 我现在推荐的启停组合与使用习惯如果你也想试 superpowers我推荐一个最精简的组合planning 全局开启每次任务前强制计划TDD 在写新功能时开启debugging 在遇到故障时开启code-review 在提交前手动触发。这个组合覆盖了开发周期里的关键环节又不会让上下文变得臃肿。日常使用我还有两个小习惯。一是每个重要任务开始前手动确认技能已激活别完全依赖 AGENTS.md因为模型偶尔会忽略默认规则。二是有空就拉一下 superpowers 仓库的最新代码社区更新很快技能文件会随着模型能力迭代不断优化旧版本可能跟不上新模型的行为模式。我现在找 Codex 干活前都会先问一句“今天的流程遵循 superpowers 了吗”这句话看起来多余但很多时候模型的输出质量差异就体现在这里。如果你也在调教 AI 编程代理不妨从这几个核心技能试起找到适合自己项目的组合。