1. Superpowers 是什么它到底解决了什么问题1.1 先从一次开盲盒式的编码体验说起如果你用过 Codex CLI 或其他 AI 编程代理大概率经历过这种场景同一个需求上午让它写一个函数思路清晰、测试完备简直像身边坐了个高级工程师下午换了个说法再问它就开始东一榔头西一棒子先改配置再改接口最后还把一个本来能跑的模块拆得七零八落。这种时灵时不灵的状态其实是 AI 编程工具目前最大的痛点——模型本身的推理能力不差差的是缺少一套稳定的工作方法。我最早接触到 Superpowers 这个项目就是在被 Codex CLI 的随机性折磨了好几周之后。当时在 GitHub 上闲逛看到别人分享说有个叫 superpowers 的技能集合专门给 Codex CLI 这类工具补充干活的方法论装完之后 AI 的行为会稳定很多。说实话最初我是半信半疑的因为市面上各种提示词包太多了大多数只是把几条指令拼在一起换个模型就失效。但实际用了两周之后我得承认Superpowers 和那些提示词模板完全不是一回事。1.2 核心设计SKILL.md 与 Call-and-Response 机制Superpowers 的本质是一套以SKILL.md文件为载体的技能集合。每个技能对应一个 Markdown 文件里面不是简单写你要怎么做而是用一套严格的格式把 AI 在特定任务中的行为路径固定下来。比如 Planning 技能会强制 AI 先拆解需求、列出约束条件、评估风险然后才允许写代码Debugging 技能会引导 AI 按照复现问题—缩小范围—定位根因—修复—验证这个链路来走而不是遇到 bug 就靠猜。这里最值得说的是它的Call-and-Response呼叫-响应机制。这个机制要求 AI 在每个关键节点都必须用指定格式向用户汇报自己的思路和下一步计划用户确认之后再继续。听起来好像很啰嗦但实际用起来你就会发现它本质上是在给 AI 加了一道刹车——每次大动作之前都有机会把方向扳回来。我实测下来这个机制对那种闷头改了一堆文件最后跑不起来的问题几乎是根治级别的改善。还有一个容易被忽视的细节Superpowers 的技能是叠加式的。它不是一个 monolith 式的超集提示词而是把规划、编码、测试、调试、审查拆成多个独立技能。你可以只启用其中两三个也可以全部启用。这种模块化设计让我可以按项目的实际需要灵活组合而不是被迫接受一套固定的 AI 工作流。1.3 它和普通提示词模板的本质区别很多人第一次看到 superpowers 的效果会以为它只是提示词写得更好。但我实际研究过它的文档和源码之后发现它不是靠几个精心编排的 prompt 来提高模型表现而是靠改变 AI 工作的程序结构。普通提示词模板本质上是一次性指令——给 AI 一段话让它在一次生成中完成尽可能多的逻辑。而 Superpowers 更像是在 AI 的工作环境里装了一套过程协议每个技能不是让 AI 一次做完而是把任务拆成有明确验收标准的多个步骤每个步骤之间需要用户确认。这样一来即使模型在某一步跑偏了损失也被控制在一个很小的范围内。打个比方普通提示词像是给一个新人一张任务清单新人可能一口气干到底错了就全部返工Superpowers 则像是给新人配了一个带检查点的作业指导书每完成一小步都要核验一次。后者看起来效率低实际上总耗时大幅下降因为大部分返工都被提前扼杀了。这也是我在这篇文章里会反复强调的一点——对于 AI 编程工具稳定大于速度可控大于炫技。2. 环境准备与安装从零到能跑通2.1 Codex CLI 的安装与基础配置在安装 Superpowers 之前你需要先有一个可用的 Codex CLI。Codex CLI 是 OpenAI 推出的命令行 AI 编程代理跑在终端里可以直接读取你的项目文件、执行命令、提交改动。安装方式很简单前提是你本机已经有 Node.js 环境然后执行npm install -g openai/codex装完之后建议先跑一次codex命令完成初始化配置它会引导你填入 API Key 或登录账号。这一步必须做否则后面所有技能调用都会卡在认证环节。基础配置里我建议重点关注两个选项一是默认模型选择如果你的账号能访问更强的模型就在配置里指定因为 Superpowers 里很多技能对模型的指令跟随能力有一定要求模型太弱效果会打折扣二是工作目录的权限设置Codex 默认只能在当前目录下操作你可以把常用项目目录加进去省得每次都要确认权限。配置好之后先随便让 Codex 做一个小题比如给这个 README 加一段使用说明确认它能正常读写文件、执行命令。这一步很关键因为 Superpowers 安装完的技能本质上是一堆 Markdown 文件Codex 需要能正常读取并遵循它们所以基础链路通畅是前提。2.2 通过 Codex CLI 安装 Superpowers 技能Codex 初始化完之后安装 Superpowers 就变成了一件很直接的事。Superpowers 项目在 GitHub 上有公开仓库官方提供了一条安装命令你只需要在项目目录下执行codex install superpowers如果是首次安装它会把技能文件拉取到 Codex 的技能目录下通常是~/.codex/skills/或项目内的.codex/skills/目录。装完之后你可以用下面的命令确认技能是否注册成功codex skills list正常的话你会看到一长串技能名字包括但不限于Planning规划、TDD测试驱动开发、Debugging调试、Code Review代码审查、Refactoring重构、Documentation文档撰写等。这里我要多说一句安装路径的问题。Superpowers 既可以全局安装放在用户目录的 skills 目录下也可以按项目安装放在项目自己的.codex/skills/下。我的建议是如果你有多个项目都在用先用全局安装省得每个项目重复配置当你确定某个项目需要自定义技能变体时再把技能复制到项目目录做覆盖。我一开始图省事全用全局后来发现不同项目的技术栈差别很大于是把 React 相关的技能固定在了前端项目的局部目录效果好了不少。另外如果你安装的是较新版本Codex 的配置体系里还有一个codex.toml文件里面可以声明启用哪些技能。默认情况下技能装进去之后就会对所有会话生效但如果你想精细控制可以在这个配置文件里用星号通配符或逐一列举的方式指定[skills] enabled [planning, tdd, debugging, code-review]2.3 在 Trae 等 AI IDE 中安装技能Superpowers 并不是 Codex CLI 的专属很多主流的 AI 编程工具都支持以类似方式加载技能。我目前主力配置里就同时给 Codex CLI 和 Trae 装了不同的技能组合两者互相补充实用度很高。Trae 是字节跳动推出的 AI IDE它底层的技能机制和 Codex 类似也是通过 Markdown 格式的技能文件来约束 AI 的行为。安装方式我在实际操作中试过两种都可行。第一种在 Trae 的扩展市场里直接搜索 superpowers如果网络环境允许它会自动完成下载安装第二种手动把仓库克隆到 Trae 约定的技能目录下然后在配置里声明启用。需要注意一点Trae 的技能目录结构与 Codex 稍有差异它更习惯把技能放在工作区内也就是项目根目录的.trae/skills/或用户目录下。如果你是从 Codex 那边复制技能文件过来最好先确认目录结构是否对应否则会出现文件在但技能不生效的怪问题。我个人的使用习惯是终端里的快速改动、脚本编写、仓库级别的维护用 Codex CLI Superpowers完整功能的开发、代码浏览、多人协作场景用 Trae Superpowers。两者共享同一套技能体系的好处是无论在哪边写代码AI 的工作方式是一致的不需要重新适应。3. 核心技能体系拆解每个技能到底在干嘛3.1 Planning让 AI 先想清楚再动手Planning 技能是我装上之后最先感知到变化的模块。没装之前问 Codex帮我实现一个用户登录功能它会立刻开始写代码几个文件刷刷地蹦出来表面上很爽实际上经常写到一半发现需求理解偏了返工成本极高。装完 Planning 技能后同样的问题Codex 会先进入规划模式它会先复述一遍它理解的需求然后分条列出它准备改哪些文件、每个文件大概怎么改、有没有依赖风险、是否涉及数据库迁移等敏感操作。这一串输出完毕之后它不会立刻动手而是等我确认。我刚开始觉得这个流程多此一举但真正用了一周之后我发现它带来的最大价值不是让 AI 想清楚而是让我想清楚。当我看到 AI 列出的实施计划我会更容易发现自己原本需求描述里的漏洞。比如有次我让它加一个导出功能它在规划里写道需要确认导出文件的编码格式我才想起来确实没考虑过 Excel 打开乱码的问题。这种被 AI 逼着完善需求的体验是普通提示词完全给不了的。Planning 技能还内置了一个变更影响评估的环节。它会在动代码之前先用工具搜索相关引用如果发现你的改动会影响其他模块它会明确提醒。这个功能在改那些老项目的时候特别救急避免了很多次改一处炸一片的惨剧。3.2 TDD 工作流测试先行而不是事后补Superpowers 里的 TDD 技能我愿称之为AI 代码质量救星。它把测试驱动开发这套人类工程师验证过几十年的方法论原封不动地移植到了 AI 的工作流程里。具体工作流是这样的收到编码需求后AI 会先分析需求确定需要什么样的输入输出然后先写一个或一批会失败的测试用这个测试来锁定期望行为接着才开始写实现代码每写一点就跑一次测试等测试通过之后再做一轮小重构确保代码结构干净。整个过程是红-绿-重构Red-Green-Refactor的循环。可能有人会说让 AI 先写测试不就是多写一遍代码吗实际体验下来价值非常大。一方面测试先行的写法逼着 AI 把需求转化成可验证的标准减少了我以为写对了的情况另一方面这轮测试用例会留在项目里成为后续改动的回归保护网。有一次Codex 在加了新功能之后把之前一个接口的行为改了如果是以前这个 bug 可能到我手动测试才发现但那次因为有前面生成的测试它在改完的瞬间就发现测试挂了自己就回退了改动。需要提醒的是TDD 技能对项目的基础设施有一定要求。如果你的项目连最基础的测试框架都没有AI 还得先花一些步骤去搭测试环境。所以我的经验是最好在项目早期就引入这个技能越早越划算。3.3 Debugging 流程治好瞎猜式修 bug我之前用 AI 修 bug 最大的感受是它特别喜欢瞎猜。问它这个接口为什么返回 500它能直接根据错误信息开始改代码完全不看日志、不复现请求。运气好时能蒙对运气差时越改越乱最后代码状态比 bug 之前还糟糕。Superpowers 的 Debugging 技能把这一套流程彻底改变了。它遵循一个严格的链条先要求用户提供完整的错误信息然后主动分析日志再尝试复现问题复现成功之后它会缩小排查范围——可能是定位到某个函数、某个请求参数甚至是某一行代码——然后才提出修复方案。每一步都有明确的输出格式和确认节点。我印象最深的一次是在调试一个并发问题。之前直接让 AI 修它上来就给我改锁的粒度结果问题没解决还引入了死锁风险。用了 Debugging 技能之后它先花时间写了个并发测试脚本来复现问题然后通过打印线程时间线发现问题是共享的可变状态在没有保护的条件下被并发读写。它给出的修复方案不仅在代码层加了保护还建议调整缓存策略从根源上消除了竞争条件。这次经历让我彻底相信AI 调试能力的天花板不取决于模型智商而取决于调试方法的严谨度。3.4 Code Review 与重构让代码质量可传承Code Review 技能在多人协作项目里特别有用。它不满足于这段代码有没有 bug而是会按几个维度去审可读性、可维护性、安全性、性能隐患、测试覆盖度。每次审查完它会产出一份结构化的评论清单每条都标注了严重等级和修改建议。我一般是让 Codex 在我提交 PR 之前先做一轮内部评审很多低级问题比如日志里打出了敏感信息、忘记处理空指针、命名可疑它都能提前揪出来。有一次它在审查里提示我某段 SQL 查询没有加索引限制在大数据量下会全表扫描。这种问题我自己 review 两遍都不一定能发现AI 却能一步到位。重构技能则是配合 TDD 使用的。它的特点是小步重构每次只做一种类型的变化比如重命名变量、提取函数、消除重复代码每做一步都会要求测试保持绿色。这种保守的重构方式让我那些遗留项目的代码质量能稳步提升而不用承担大规模重写的风险。4. 实操用一个真实需求走通完整工作流4.1 输入需求与角色设定为了让你更直观地理解 Superpowers 的实际效果我用一个具体的小需求来演示完整流程。这个需求是给一个 Node.js 的待办事项命令行工具增加按优先级排序展示的功能优先级分为高、中、低三档。有了 Superpowers 之后我不会再用大白话直接问 Codex 要代码而是先让它按照技能体系里的规范来拆解任务。在 Codex CLI 里我输入了这样一段话请使用 Planning 和 TDD 技能为这个项目实现按优先级排序展示待办事项的功能。优先级字段存储在 todo 对象的 priority 属性中排序要求为高 中 低。请先制定计划。注意我明确指定了要使用的技能这是 Superpowers 的一个使用技巧——它在技能之间设计了明确的边界要求用户在合适的时候主动触发而不是被动地等模型自己去选。这个细节很关键。4.2 从计划到 TDD 的完整会话输入完需求之后Codex 进入了 Planning 模式。它首先复述了需求理解列出了三个关键点排序规则、字段缺失时的处理、以及 CLI 输出的格式。然后它给出了实施计划1. 修改 src/todo.js新增 sortTodosByPriority 函数 2. 在 list 命令中调用该函数替换原有的按创建时间排序逻辑 3. 编写单元测试覆盖正常排序、空列表、缺失 priority 字段三种场景 4. 更新 README 中的功能说明。我确认了计划它才进入 TDD 阶段。它先创建了一个测试文件test/todo.test.js里面包含三个用例test(按优先级排序高 中 低, () { const todos [ { id: 1, text: 低优先级任务, priority: 低 }, { id: 2, text: 高优先级任务, priority: 高 }, { id: 3, text: 中优先级任务, priority: 中 }, ]; const sorted sortTodosByPriority(todos); expect(sorted.map(t t.priority)).toEqual([高, 中, 低]); }); test(空列表返回空数组, () { expect(sortTodosByPriority([])).toEqual([]); }); test(缺失 priority 字段时视为低优先级, () { const todos [{ id: 1, text: 无优先级任务 }]; const sorted sortTodosByPriority(todos); expect(sorted[0].priority).toBe(低); });写完好它跑了一次测试确认三个用例全部失败红。然后才开始写实现代码。有意思的是第一个版本的实现里它对缺失 priority 字段的处理有点问题——直接用了undefined参与比较导致排序不稳定。因为测试用例提前锁定了期望行为它跑测试的时候就发现第三个用例挂了于是自己修正了实现把它改成对priority做归一化处理(todo.priority || 低)。整个过程几乎没有我介入测试用例就变成了验收标准AI 自己对着标准改到通过为止。4.3 会话收尾与代码审查测试全部变绿之后Codex 并没有急着宣布完成了而是主动进入了 Code Review 模式。它自己审查了自己刚写的代码产出了几条评论其中一条建议把排序比重抽取成常量避免将来优先级档位变化时到处找魔法字符串。还有一条是建议在list命令中增加--sort-by选项以便用户可以在创建时间和优先级之间切换。这两条建议它都没有自动执行而是列在审查清单里询问我是否采纳。我采纳了第一条拒绝了第二条因为用户没有这个需求YAGNI 原则。这种提建议但不擅自扩大范围的设计让我对它的印象分高了不少——很多 AI 编程工具特别喜欢自作主张加功能Superpowers 的流程约束很好地规避了这个问题。整个流程走完之后我再自己手动验证了一遍运行测试、手动添加几条不同优先级的待办事项、执行list命令看输出。一遍通过没有返工。对比以前直接问 AI 要代码的体验这个流程多花了几分钟的确认时间但省去了至少半小时的调试和改 bug 时间。5. 常见问题与排查技巧实录5.1 技能装了但好像没生效我自己遇到最多的问题就是技能文件明明装好了但 Codex 在会话里完全没表现出技能的约束。这种情况别急着骂工具先按下面几个方向排查第一步确认技能确实被系统加载了。用codex skills list查看如果列表里能看到技能名说明文件位置没问题如果看不到多半是安装路径不对检查一下是否存在全局目录和项目目录的覆盖冲突。第二步检查模型和 API 版本。有些旧版本的 Codex CLI 对技能支持不完整建议升级到最新版本。我踩过一次坑技能文件是最新的但 CLI 还是半年前的版本结果很多新语法和指令格式它根本不认表现就是技能像没装一样。第三步检查需求描述方式。如果你在对话里直接说帮我做某件事模型可能会绕开 Planning 技能直接回答导致你觉得技能没生效。建议带上技能触发的关键词比如使用 Planning 技能按照 TDD 流程。这不是说模型不聪明而是技能的触发机制本身就需要用户在关键节点主动指定这是设计的一部分。5.2 模型跑偏或擅自扩大改动范围Superpowers 本身已经在流程上做了很强的约束但模型毕竟不是程序偶尔还是会跑偏。最常见的是计划里明明只列了三个文件它写着写着突然开始改第四个、第五个文件或者擅自把依赖升级了。遇到这种情况我的处理方法是立即在会话里使用刹车指令明确告诉它停止当前操作回到计划中的第 2 步不要修改未在计划中列出的文件。Superpowers 的机制在这里帮了大忙因为计划是明文的、分步骤的你可以精准地指出它跑到了哪个节点之外模型能准确理解并回退。如果是没有技能约束的裸 Codex你连回到哪一步都说不清楚。这里还有一个技巧在生产项目里建议在让 AI 干活之前先把 git 当前状态提交或 stash保证工作区干净。这样即使 AI 跑偏你也能用git checkout .快速回退所有改动不用担心它改了计划外文件——直接丢弃就行了。5.3 不同工具之间的技能配置差异我用 Codex CLI 和 Trae 同时跑 Superpowers 的时候发现两个工具在技能行为上还是有可感知的差异。Codex CLI 更偏终端工具它的技能执行更加程序化每个步骤之间等待用户确认节奏比较慢但可控性极强。Trae 作为 IDE它的执行更加流畅很多步骤会连续执行不太频繁打断用户整体体验更顺滑但相对的中途纠偏的机会变少了。我的建议是根据任务类型选择工具。如果是重逻辑、多步骤、风险高的任务比如数据库迁移、重构核心模块用 Codex CLI Superpowers严格流程更安心如果是 UI 调整、简单功能迭代用 Trae Superpowers效率更高。两者共用同一套技能文件的好处是工作流一致性有保障你不需要因为切换工具而重新学习一套方法。另外要注意技能文件如果从 Codex 目录复制到 Trae 目录最好用仓库里最新的 release 版本不要用本地已经被你改过的版本因为有些本地修改是针对 CLI 行为的到了 IDE 环境可能水土不服。我在初期踩过这个坑复制了一个改过的技能文件过去结果 Trae 里 AI 的行为变得很奇怪排查了半天才想到是这个原因。5.4 关于模型选择的一点观察最后分享一个我测试了多种模型之后的主观结论Superpowers 这种强流程 结构化输出的设计对不同模型的容错率差异还挺大的。指令跟随能力强的模型套上流程之后表现是如虎添翼输出稳定、计划合理指令跟随弱的模型套上流程之后虽然也会有改善但偶尔会在关键节点漏掉步骤导致流程断裂你需要手动提醒它。所以如果你在某个模型下体验不佳先别急着卸载 Superpowers优先尝试更换更强的模型。就我实测来看性能越靠前的模型和 Superpowers 搭配的收益越明显。这也是为什么官方文档里在安装步骤之前专门花篇幅讲模型配置——流程协议再好也需要一个能听懂指令并严格执行的底座。我个人在实际操作中的体会是Superpowers 这类项目的出现标志着 AI 编程工具正在从会写代码的聊天机器人进化成有职业素养的结对程序员。它不一定能让 AI 变得更聪明但它能让 AI 的能力发挥得更稳定、更可控。如果你也在为 AI 编程的不确定性头疼不妨花半小时装上它用一个真实需求走一遍完整流程你可能会和我一样第一次感觉到AI 终于像个靠谱的同事了。
Superpowers技能集：让Codex CLI告别随机，成为稳定可靠的AI编程搭档
1. Superpowers 是什么它到底解决了什么问题1.1 先从一次开盲盒式的编码体验说起如果你用过 Codex CLI 或其他 AI 编程代理大概率经历过这种场景同一个需求上午让它写一个函数思路清晰、测试完备简直像身边坐了个高级工程师下午换了个说法再问它就开始东一榔头西一棒子先改配置再改接口最后还把一个本来能跑的模块拆得七零八落。这种时灵时不灵的状态其实是 AI 编程工具目前最大的痛点——模型本身的推理能力不差差的是缺少一套稳定的工作方法。我最早接触到 Superpowers 这个项目就是在被 Codex CLI 的随机性折磨了好几周之后。当时在 GitHub 上闲逛看到别人分享说有个叫 superpowers 的技能集合专门给 Codex CLI 这类工具补充干活的方法论装完之后 AI 的行为会稳定很多。说实话最初我是半信半疑的因为市面上各种提示词包太多了大多数只是把几条指令拼在一起换个模型就失效。但实际用了两周之后我得承认Superpowers 和那些提示词模板完全不是一回事。1.2 核心设计SKILL.md 与 Call-and-Response 机制Superpowers 的本质是一套以SKILL.md文件为载体的技能集合。每个技能对应一个 Markdown 文件里面不是简单写你要怎么做而是用一套严格的格式把 AI 在特定任务中的行为路径固定下来。比如 Planning 技能会强制 AI 先拆解需求、列出约束条件、评估风险然后才允许写代码Debugging 技能会引导 AI 按照复现问题—缩小范围—定位根因—修复—验证这个链路来走而不是遇到 bug 就靠猜。这里最值得说的是它的Call-and-Response呼叫-响应机制。这个机制要求 AI 在每个关键节点都必须用指定格式向用户汇报自己的思路和下一步计划用户确认之后再继续。听起来好像很啰嗦但实际用起来你就会发现它本质上是在给 AI 加了一道刹车——每次大动作之前都有机会把方向扳回来。我实测下来这个机制对那种闷头改了一堆文件最后跑不起来的问题几乎是根治级别的改善。还有一个容易被忽视的细节Superpowers 的技能是叠加式的。它不是一个 monolith 式的超集提示词而是把规划、编码、测试、调试、审查拆成多个独立技能。你可以只启用其中两三个也可以全部启用。这种模块化设计让我可以按项目的实际需要灵活组合而不是被迫接受一套固定的 AI 工作流。1.3 它和普通提示词模板的本质区别很多人第一次看到 superpowers 的效果会以为它只是提示词写得更好。但我实际研究过它的文档和源码之后发现它不是靠几个精心编排的 prompt 来提高模型表现而是靠改变 AI 工作的程序结构。普通提示词模板本质上是一次性指令——给 AI 一段话让它在一次生成中完成尽可能多的逻辑。而 Superpowers 更像是在 AI 的工作环境里装了一套过程协议每个技能不是让 AI 一次做完而是把任务拆成有明确验收标准的多个步骤每个步骤之间需要用户确认。这样一来即使模型在某一步跑偏了损失也被控制在一个很小的范围内。打个比方普通提示词像是给一个新人一张任务清单新人可能一口气干到底错了就全部返工Superpowers 则像是给新人配了一个带检查点的作业指导书每完成一小步都要核验一次。后者看起来效率低实际上总耗时大幅下降因为大部分返工都被提前扼杀了。这也是我在这篇文章里会反复强调的一点——对于 AI 编程工具稳定大于速度可控大于炫技。2. 环境准备与安装从零到能跑通2.1 Codex CLI 的安装与基础配置在安装 Superpowers 之前你需要先有一个可用的 Codex CLI。Codex CLI 是 OpenAI 推出的命令行 AI 编程代理跑在终端里可以直接读取你的项目文件、执行命令、提交改动。安装方式很简单前提是你本机已经有 Node.js 环境然后执行npm install -g openai/codex装完之后建议先跑一次codex命令完成初始化配置它会引导你填入 API Key 或登录账号。这一步必须做否则后面所有技能调用都会卡在认证环节。基础配置里我建议重点关注两个选项一是默认模型选择如果你的账号能访问更强的模型就在配置里指定因为 Superpowers 里很多技能对模型的指令跟随能力有一定要求模型太弱效果会打折扣二是工作目录的权限设置Codex 默认只能在当前目录下操作你可以把常用项目目录加进去省得每次都要确认权限。配置好之后先随便让 Codex 做一个小题比如给这个 README 加一段使用说明确认它能正常读写文件、执行命令。这一步很关键因为 Superpowers 安装完的技能本质上是一堆 Markdown 文件Codex 需要能正常读取并遵循它们所以基础链路通畅是前提。2.2 通过 Codex CLI 安装 Superpowers 技能Codex 初始化完之后安装 Superpowers 就变成了一件很直接的事。Superpowers 项目在 GitHub 上有公开仓库官方提供了一条安装命令你只需要在项目目录下执行codex install superpowers如果是首次安装它会把技能文件拉取到 Codex 的技能目录下通常是~/.codex/skills/或项目内的.codex/skills/目录。装完之后你可以用下面的命令确认技能是否注册成功codex skills list正常的话你会看到一长串技能名字包括但不限于Planning规划、TDD测试驱动开发、Debugging调试、Code Review代码审查、Refactoring重构、Documentation文档撰写等。这里我要多说一句安装路径的问题。Superpowers 既可以全局安装放在用户目录的 skills 目录下也可以按项目安装放在项目自己的.codex/skills/下。我的建议是如果你有多个项目都在用先用全局安装省得每个项目重复配置当你确定某个项目需要自定义技能变体时再把技能复制到项目目录做覆盖。我一开始图省事全用全局后来发现不同项目的技术栈差别很大于是把 React 相关的技能固定在了前端项目的局部目录效果好了不少。另外如果你安装的是较新版本Codex 的配置体系里还有一个codex.toml文件里面可以声明启用哪些技能。默认情况下技能装进去之后就会对所有会话生效但如果你想精细控制可以在这个配置文件里用星号通配符或逐一列举的方式指定[skills] enabled [planning, tdd, debugging, code-review]2.3 在 Trae 等 AI IDE 中安装技能Superpowers 并不是 Codex CLI 的专属很多主流的 AI 编程工具都支持以类似方式加载技能。我目前主力配置里就同时给 Codex CLI 和 Trae 装了不同的技能组合两者互相补充实用度很高。Trae 是字节跳动推出的 AI IDE它底层的技能机制和 Codex 类似也是通过 Markdown 格式的技能文件来约束 AI 的行为。安装方式我在实际操作中试过两种都可行。第一种在 Trae 的扩展市场里直接搜索 superpowers如果网络环境允许它会自动完成下载安装第二种手动把仓库克隆到 Trae 约定的技能目录下然后在配置里声明启用。需要注意一点Trae 的技能目录结构与 Codex 稍有差异它更习惯把技能放在工作区内也就是项目根目录的.trae/skills/或用户目录下。如果你是从 Codex 那边复制技能文件过来最好先确认目录结构是否对应否则会出现文件在但技能不生效的怪问题。我个人的使用习惯是终端里的快速改动、脚本编写、仓库级别的维护用 Codex CLI Superpowers完整功能的开发、代码浏览、多人协作场景用 Trae Superpowers。两者共享同一套技能体系的好处是无论在哪边写代码AI 的工作方式是一致的不需要重新适应。3. 核心技能体系拆解每个技能到底在干嘛3.1 Planning让 AI 先想清楚再动手Planning 技能是我装上之后最先感知到变化的模块。没装之前问 Codex帮我实现一个用户登录功能它会立刻开始写代码几个文件刷刷地蹦出来表面上很爽实际上经常写到一半发现需求理解偏了返工成本极高。装完 Planning 技能后同样的问题Codex 会先进入规划模式它会先复述一遍它理解的需求然后分条列出它准备改哪些文件、每个文件大概怎么改、有没有依赖风险、是否涉及数据库迁移等敏感操作。这一串输出完毕之后它不会立刻动手而是等我确认。我刚开始觉得这个流程多此一举但真正用了一周之后我发现它带来的最大价值不是让 AI 想清楚而是让我想清楚。当我看到 AI 列出的实施计划我会更容易发现自己原本需求描述里的漏洞。比如有次我让它加一个导出功能它在规划里写道需要确认导出文件的编码格式我才想起来确实没考虑过 Excel 打开乱码的问题。这种被 AI 逼着完善需求的体验是普通提示词完全给不了的。Planning 技能还内置了一个变更影响评估的环节。它会在动代码之前先用工具搜索相关引用如果发现你的改动会影响其他模块它会明确提醒。这个功能在改那些老项目的时候特别救急避免了很多次改一处炸一片的惨剧。3.2 TDD 工作流测试先行而不是事后补Superpowers 里的 TDD 技能我愿称之为AI 代码质量救星。它把测试驱动开发这套人类工程师验证过几十年的方法论原封不动地移植到了 AI 的工作流程里。具体工作流是这样的收到编码需求后AI 会先分析需求确定需要什么样的输入输出然后先写一个或一批会失败的测试用这个测试来锁定期望行为接着才开始写实现代码每写一点就跑一次测试等测试通过之后再做一轮小重构确保代码结构干净。整个过程是红-绿-重构Red-Green-Refactor的循环。可能有人会说让 AI 先写测试不就是多写一遍代码吗实际体验下来价值非常大。一方面测试先行的写法逼着 AI 把需求转化成可验证的标准减少了我以为写对了的情况另一方面这轮测试用例会留在项目里成为后续改动的回归保护网。有一次Codex 在加了新功能之后把之前一个接口的行为改了如果是以前这个 bug 可能到我手动测试才发现但那次因为有前面生成的测试它在改完的瞬间就发现测试挂了自己就回退了改动。需要提醒的是TDD 技能对项目的基础设施有一定要求。如果你的项目连最基础的测试框架都没有AI 还得先花一些步骤去搭测试环境。所以我的经验是最好在项目早期就引入这个技能越早越划算。3.3 Debugging 流程治好瞎猜式修 bug我之前用 AI 修 bug 最大的感受是它特别喜欢瞎猜。问它这个接口为什么返回 500它能直接根据错误信息开始改代码完全不看日志、不复现请求。运气好时能蒙对运气差时越改越乱最后代码状态比 bug 之前还糟糕。Superpowers 的 Debugging 技能把这一套流程彻底改变了。它遵循一个严格的链条先要求用户提供完整的错误信息然后主动分析日志再尝试复现问题复现成功之后它会缩小排查范围——可能是定位到某个函数、某个请求参数甚至是某一行代码——然后才提出修复方案。每一步都有明确的输出格式和确认节点。我印象最深的一次是在调试一个并发问题。之前直接让 AI 修它上来就给我改锁的粒度结果问题没解决还引入了死锁风险。用了 Debugging 技能之后它先花时间写了个并发测试脚本来复现问题然后通过打印线程时间线发现问题是共享的可变状态在没有保护的条件下被并发读写。它给出的修复方案不仅在代码层加了保护还建议调整缓存策略从根源上消除了竞争条件。这次经历让我彻底相信AI 调试能力的天花板不取决于模型智商而取决于调试方法的严谨度。3.4 Code Review 与重构让代码质量可传承Code Review 技能在多人协作项目里特别有用。它不满足于这段代码有没有 bug而是会按几个维度去审可读性、可维护性、安全性、性能隐患、测试覆盖度。每次审查完它会产出一份结构化的评论清单每条都标注了严重等级和修改建议。我一般是让 Codex 在我提交 PR 之前先做一轮内部评审很多低级问题比如日志里打出了敏感信息、忘记处理空指针、命名可疑它都能提前揪出来。有一次它在审查里提示我某段 SQL 查询没有加索引限制在大数据量下会全表扫描。这种问题我自己 review 两遍都不一定能发现AI 却能一步到位。重构技能则是配合 TDD 使用的。它的特点是小步重构每次只做一种类型的变化比如重命名变量、提取函数、消除重复代码每做一步都会要求测试保持绿色。这种保守的重构方式让我那些遗留项目的代码质量能稳步提升而不用承担大规模重写的风险。4. 实操用一个真实需求走通完整工作流4.1 输入需求与角色设定为了让你更直观地理解 Superpowers 的实际效果我用一个具体的小需求来演示完整流程。这个需求是给一个 Node.js 的待办事项命令行工具增加按优先级排序展示的功能优先级分为高、中、低三档。有了 Superpowers 之后我不会再用大白话直接问 Codex 要代码而是先让它按照技能体系里的规范来拆解任务。在 Codex CLI 里我输入了这样一段话请使用 Planning 和 TDD 技能为这个项目实现按优先级排序展示待办事项的功能。优先级字段存储在 todo 对象的 priority 属性中排序要求为高 中 低。请先制定计划。注意我明确指定了要使用的技能这是 Superpowers 的一个使用技巧——它在技能之间设计了明确的边界要求用户在合适的时候主动触发而不是被动地等模型自己去选。这个细节很关键。4.2 从计划到 TDD 的完整会话输入完需求之后Codex 进入了 Planning 模式。它首先复述了需求理解列出了三个关键点排序规则、字段缺失时的处理、以及 CLI 输出的格式。然后它给出了实施计划1. 修改 src/todo.js新增 sortTodosByPriority 函数 2. 在 list 命令中调用该函数替换原有的按创建时间排序逻辑 3. 编写单元测试覆盖正常排序、空列表、缺失 priority 字段三种场景 4. 更新 README 中的功能说明。我确认了计划它才进入 TDD 阶段。它先创建了一个测试文件test/todo.test.js里面包含三个用例test(按优先级排序高 中 低, () { const todos [ { id: 1, text: 低优先级任务, priority: 低 }, { id: 2, text: 高优先级任务, priority: 高 }, { id: 3, text: 中优先级任务, priority: 中 }, ]; const sorted sortTodosByPriority(todos); expect(sorted.map(t t.priority)).toEqual([高, 中, 低]); }); test(空列表返回空数组, () { expect(sortTodosByPriority([])).toEqual([]); }); test(缺失 priority 字段时视为低优先级, () { const todos [{ id: 1, text: 无优先级任务 }]; const sorted sortTodosByPriority(todos); expect(sorted[0].priority).toBe(低); });写完好它跑了一次测试确认三个用例全部失败红。然后才开始写实现代码。有意思的是第一个版本的实现里它对缺失 priority 字段的处理有点问题——直接用了undefined参与比较导致排序不稳定。因为测试用例提前锁定了期望行为它跑测试的时候就发现第三个用例挂了于是自己修正了实现把它改成对priority做归一化处理(todo.priority || 低)。整个过程几乎没有我介入测试用例就变成了验收标准AI 自己对着标准改到通过为止。4.3 会话收尾与代码审查测试全部变绿之后Codex 并没有急着宣布完成了而是主动进入了 Code Review 模式。它自己审查了自己刚写的代码产出了几条评论其中一条建议把排序比重抽取成常量避免将来优先级档位变化时到处找魔法字符串。还有一条是建议在list命令中增加--sort-by选项以便用户可以在创建时间和优先级之间切换。这两条建议它都没有自动执行而是列在审查清单里询问我是否采纳。我采纳了第一条拒绝了第二条因为用户没有这个需求YAGNI 原则。这种提建议但不擅自扩大范围的设计让我对它的印象分高了不少——很多 AI 编程工具特别喜欢自作主张加功能Superpowers 的流程约束很好地规避了这个问题。整个流程走完之后我再自己手动验证了一遍运行测试、手动添加几条不同优先级的待办事项、执行list命令看输出。一遍通过没有返工。对比以前直接问 AI 要代码的体验这个流程多花了几分钟的确认时间但省去了至少半小时的调试和改 bug 时间。5. 常见问题与排查技巧实录5.1 技能装了但好像没生效我自己遇到最多的问题就是技能文件明明装好了但 Codex 在会话里完全没表现出技能的约束。这种情况别急着骂工具先按下面几个方向排查第一步确认技能确实被系统加载了。用codex skills list查看如果列表里能看到技能名说明文件位置没问题如果看不到多半是安装路径不对检查一下是否存在全局目录和项目目录的覆盖冲突。第二步检查模型和 API 版本。有些旧版本的 Codex CLI 对技能支持不完整建议升级到最新版本。我踩过一次坑技能文件是最新的但 CLI 还是半年前的版本结果很多新语法和指令格式它根本不认表现就是技能像没装一样。第三步检查需求描述方式。如果你在对话里直接说帮我做某件事模型可能会绕开 Planning 技能直接回答导致你觉得技能没生效。建议带上技能触发的关键词比如使用 Planning 技能按照 TDD 流程。这不是说模型不聪明而是技能的触发机制本身就需要用户在关键节点主动指定这是设计的一部分。5.2 模型跑偏或擅自扩大改动范围Superpowers 本身已经在流程上做了很强的约束但模型毕竟不是程序偶尔还是会跑偏。最常见的是计划里明明只列了三个文件它写着写着突然开始改第四个、第五个文件或者擅自把依赖升级了。遇到这种情况我的处理方法是立即在会话里使用刹车指令明确告诉它停止当前操作回到计划中的第 2 步不要修改未在计划中列出的文件。Superpowers 的机制在这里帮了大忙因为计划是明文的、分步骤的你可以精准地指出它跑到了哪个节点之外模型能准确理解并回退。如果是没有技能约束的裸 Codex你连回到哪一步都说不清楚。这里还有一个技巧在生产项目里建议在让 AI 干活之前先把 git 当前状态提交或 stash保证工作区干净。这样即使 AI 跑偏你也能用git checkout .快速回退所有改动不用担心它改了计划外文件——直接丢弃就行了。5.3 不同工具之间的技能配置差异我用 Codex CLI 和 Trae 同时跑 Superpowers 的时候发现两个工具在技能行为上还是有可感知的差异。Codex CLI 更偏终端工具它的技能执行更加程序化每个步骤之间等待用户确认节奏比较慢但可控性极强。Trae 作为 IDE它的执行更加流畅很多步骤会连续执行不太频繁打断用户整体体验更顺滑但相对的中途纠偏的机会变少了。我的建议是根据任务类型选择工具。如果是重逻辑、多步骤、风险高的任务比如数据库迁移、重构核心模块用 Codex CLI Superpowers严格流程更安心如果是 UI 调整、简单功能迭代用 Trae Superpowers效率更高。两者共用同一套技能文件的好处是工作流一致性有保障你不需要因为切换工具而重新学习一套方法。另外要注意技能文件如果从 Codex 目录复制到 Trae 目录最好用仓库里最新的 release 版本不要用本地已经被你改过的版本因为有些本地修改是针对 CLI 行为的到了 IDE 环境可能水土不服。我在初期踩过这个坑复制了一个改过的技能文件过去结果 Trae 里 AI 的行为变得很奇怪排查了半天才想到是这个原因。5.4 关于模型选择的一点观察最后分享一个我测试了多种模型之后的主观结论Superpowers 这种强流程 结构化输出的设计对不同模型的容错率差异还挺大的。指令跟随能力强的模型套上流程之后表现是如虎添翼输出稳定、计划合理指令跟随弱的模型套上流程之后虽然也会有改善但偶尔会在关键节点漏掉步骤导致流程断裂你需要手动提醒它。所以如果你在某个模型下体验不佳先别急着卸载 Superpowers优先尝试更换更强的模型。就我实测来看性能越靠前的模型和 Superpowers 搭配的收益越明显。这也是为什么官方文档里在安装步骤之前专门花篇幅讲模型配置——流程协议再好也需要一个能听懂指令并严格执行的底座。我个人在实际操作中的体会是Superpowers 这类项目的出现标志着 AI 编程工具正在从会写代码的聊天机器人进化成有职业素养的结对程序员。它不一定能让 AI 变得更聪明但它能让 AI 的能力发挥得更稳定、更可控。如果你也在为 AI 编程的不确定性头疼不妨花半小时装上它用一个真实需求走一遍完整流程你可能会和我一样第一次感觉到AI 终于像个靠谱的同事了。
