Codex Superpowers：给AI编程助手装上技能系统的工作流改造

1. 从“会聊天的助手”到“有手感的队友”：superpowers 到底解决了什么问题

很多把 Codex CLI、Claude Code 这类终端 AI 编程助手当日常工具的人，应该都有过同样的体验：装好之后兴冲冲让它写个功能，它确实能写，但写出来的东西总差点意思。让它改 bug，它能给出“看起来合理”的修改，一跑却冒出新问题；让它做重构，它会老老实实触发大规模改动，改完整个项目风格都不统一；让它按之前的约定继续写代码，它好像完全忘了上一篇对话里我们定下的规则。一句话总结就是：它会聊天，但不会干活。

我一开始以为这是模型能力问题，后来换了好几个更强的新模型，问题依然存在。真正的问题不在“智商”，而在工作方法。AI 编码助手本质上是一个极其聪明但没有“职业习惯”的实习生——你问它问题，它能对答如流；你让它独立负责一件事，它没有自己的节奏、没有检查清单、没有工程纪律，全靠你一步步喂。而 superpowers 这个项目，解决的就是这件事：它给 Codex CLI 这类工具注入了一套“职业习惯”——也就是结构化的技能（skills）和工作流（workflows），让 AI 从“被动回答者”变成“有方法论的协作者”。

我第一次接触 superpowers 是在 GitHub 上，作者是一个长期折腾 AI 编码工具的开发者。当时热词里反复出现“codex superpowers”“superpowers 使用教程”“superpowers 安装”，我一看 commits 还挺活跃，就 clone 下来试了试。它的核心不是某个炫酷的模型，而是一套 Markdown 写的“技能文件”和一个基于技能的交互框架。装上之后，Codex 的行为方式会发生肉眼可见的变化：它写代码之前会先画测试，改大文件的时候会先看结构再动手，遇到 bug 会先复现再定位，而不是直接猜一个原因就改。

这篇文章我会从设计思路、安装配置、核心技能拆解、实战调优、常见问题五个部分，把自己这些天折腾 superpowers 的完整记录分享出来。如果你正在用 Codex CLI、Claude Code，或者任何支持 AGENTS.md/CLAUDE.md 上下文协议的终端 AI 编程工具，这篇文章应该能帮你把工具的真实水平拉高一大截。如果你是刚听说这个项目、完全没装过的新手，也不用担心，我会从零开始把每一步讲清楚。

2. superpowers 的设计思路：为什么 AI 编程助手需要“技能系统”

2.1 “技能”不是一个插件，而是一套工作协议

superpowers 最核心的设计，是把“AI 怎么干活”这件事显式地定义出来。传统用法里，你在终端里敲一句“帮我实现用户注册功能”，Codex 会基于训练数据里的通用模式直接开写。但“直接开写”恰恰是问题所在——它不知道你项目的测试框架是什么，不知道你的代码风格，不知道你更看重可维护性还是快速上线，更不知道“实现一个功能”在你这个项目的上下文里意味着什么。

superpowers 的做法是：预先定义一批“技能文件”，每个技能文件包含该技能的适用场景、核心步骤、验收标准、注意事项，用 Markdown 写好，放在项目的指定目录下。Codex 启动时通过 AGENTS.md 或 CLAUDE.md 引用这些文件，相当于在它的“工作记忆”里预装了一批 SOP。之后你给它下达任务，它会先识别任务属于哪个技能，然后按技能文件里的流程一步步执行。

这个思路本质上和真实团队里“新员工入职培训手册”一模一样。你给新人一本手册，里面写清楚“提交代码前必须跑哪些检查”“数据库迁移该怎么写”“UI 组件遵循什么规范”，新人的产出质量立刻上一个台阶。superpowers 就是把这份手册写给了 AI。

2.2 为什么用 Markdown 文件而不是代码插件

早期有一些工具试图用插件方式给 AI 助手增加能力，但我个人体验下来，问题的本质不在“能不能调用工具”，而在“有没有做事的流程”。插件解决的往往是某个具体动作（比如“读取文件”“执行命令”），但 superpowers 解决的是“面对一个模糊目标时该如何拆解和推进”。这种工作流层面的东西，用自然语言描述反而比硬编码实现更灵活、更透明、更容易被 AI 理解。

Markdown 文件的好处有三个。第一是透明：你能直接打开每个技能文件看里面写了什么，发现某项流程不合理，自己改一行字就行，不需要懂编程。第二是可跨工具复用：不管是 Codex CLI、Claude Code，还是其他遵守 AGENTS.md 协议的终端工具，都可以读取同一套技能文件。第三是容易组合：技能文件之间可以互相引用，一个复杂任务可以拆成“先 A 技能再 B 技能”，AI 会根据上下文自动衔接。

我这里补充一句个人的理解：superpowers 的底层假设是，当前大模型的推理能力已经够用了，缺的是“元认知”层面的约束。给它一套好的工作协议，它立刻从“聪明但毛躁”变成“聪明且有章法”。这也是为什么这个项目没有用什么神秘的黑科技，却能带来看得见的效率提升。

2.3 superpowers 和“上下文工程”的关系

很多人把 superpowers 归类为“上下文工程”工具，这个理解方向是对的，但不完全准确。上下文工程通常讲究“喂给模型的上下文里包含什么信息”，而 superpowers 更进一步，讲究“模型面对任务时的行为边界和推进顺序”。它不仅仅是给模型“知识”，更是给模型“纪律”。

举个例子。原生的 Codex CLI 在接到“修复这个 bug”的指令后，典型反应是读一下报错信息、瞄一眼相关代码，然后直接给出修改建议。superpowers 里有一个“调试器”技能（debugger skill），它规定了一套严格的调试流程：先通过最小化复现确认问题症状、再圈定嫌疑代码范围、每改一处就重新运行验证、最后才写修复说明。表面上看这套流程让 AI“变慢了”，但实际算总账，它大幅减少了“修一个 bug 引出三个新问题”的返工时间。

这种“先定流程再开干”的思路，非常适合那些经常面对模糊需求的场景：重构旧代码、跨模块加功能、从零搭建一个服务。如果你只是写点一次性脚本，superpowers 的价值没那么明显；一旦进入“正经项目”的维护和迭代，它的优势会越来越突出。

3. 安装与初始化：十分钟把 superpowers 跑起来

3.1 环境准备：先确认你的 Codex CLI 是新的

在动 superpowers 之前，先确认你本机的情况。这个项目依赖 OpenAI 的 Codex CLI 作为运行载体，所以第一步是保证 Codex CLI 已经安装并正常可用。如果你的机器上还没有，安装非常简单：

npm install -g @openai/codex

装完先跑一下codex --version，能输出版本号就说明基础环境没问题。然后建议把 Codex 升级到最新版，因为 superpowers 的某些技能文件用到了较新的上下文协议特性，版本太老会读不到技能内容。这一步我踩过坑，第一次装的时候没注意版本，技能文件怎么都不生效，排查半天才发现是 CLI 版本过旧。

另外，如果你日常用的是 Claude Code，superpowers 也能兼容，因为它本质上只是读取 AGENTS.md/CLAUDE.md 里的 Markdown 指令。不过这篇文章的实操部分我会以 Codex CLI 为例来写，因为热词里“codex superpowers”出现频率最高，项目对这个场景的适配也最完善。

3.2 获取 superpowers 项目文件

superpowers 的代码托管在 GitHub 上，获取方式就是标准的 clone 操作：

git clone https://github.com/obra/superpowers.git

clone 下来之后，你会看到一个非常清爽的目录结构。核心内容在skills/目录下，里面按技能类型分好了子目录。另外还有AGENTS.md和CLAUDE.md两个入口文件，它们的作用是把技能目录介绍给 AI 助手，相当于一本书的目录页。

这里我建议先花五分钟把整个仓库的 README 看一遍，尤其是“技能清单”的部分。不是为了别的，而是让你对这套系统能干什么有个整体印象——毕竟你接下来要让 AI 按这些流程干活，你总得知道它手里有哪些牌。

3.3 项目级安装：把技能装进你的目标项目

superpowers 的安装不是全局性的，而是以“项目”为单位。原因很好理解：技能文件要跟着项目走，不同项目可以有自己定制的技能组合。比如你的 Java 后端项目可能需要专门的测试技能配置，而你的前端项目可能更关注组件开发流程。

具体操作分三步。第一步，把你 clone 下来的skills目录整体复制到目标项目的根目录：

cp -r /path/to/superpowers/skills /your/project/root/skills

第二步，把AGENTS.md（或者CLAUDE.md）复制到目标项目根目录。这个文件是 AI 助手启动时第一个会去读的上下文文件。打开它看一眼，你会发现里面写的是类似“本项目使用以下技能，每个技能文件都提供了详细的执行步骤，请在做相应任务时严格遵循”这类指令，然后列出了所有技能文件和它们的定位。

第三步，也是很多人容易忽略的：生成你自己的AGENTS.md补充内容。原版AGENTS.md只是技能入口，它不会自动知道你的项目用什么语言、什么测试框架、代码风格是什么。你需要在这个文件里追加一段“项目专属约定”，比如：

## 项目背景 - 后端：Spring Boot 3.x，Java 17 - 前端：React + TypeScript，使用 Vite 构建 - 测试：JUnit 5 + Mockito，测试文件放在 src/test/java 下 - 数据库：PostgreSQL，所有表结构变更必须通过 Flyway 迁移脚本 ## 项目约定 - 遵循现有代码风格：使用 4 空格缩进，类名用 UpperCamelCase - 新功能必须包含单元测试和必要的集成测试 - 修改公共模块时，必须同步更新相关文档

这段信息对 AI 的行为质量影响非常大。没有这些内容，superpowers 的技能文件是“通用 SOP”；加了这些内容，它就是“为你项目量身定制的 SOP”。我实际测下来，同样一个“给订单模块加导出功能”的需求，有项目约定的 Codex 输出代码的质量和风格匹配度明显更高。

3.4 验证安装是否生效

装完之后怎么确认技能真正被 AI 读到了？最直接的办法是启动 Codex CLI，问它一句“你当前可用的技能有哪些？”。如果安装成功，它会列出一串技能名，比如增量 TDD、文件编辑器、调试器、Agentic 编码等。如果它回答“我没有额外的技能”，说明 AGENTS.md 没有被正确读取，按下面第 5 章的排查步骤去挨个检查。

我第一次装的时候，这里就翻过车。技能文件复制过去了，AGENTS.md 也放了，但 Codex 就是“看不到”技能。后来发现原因是我把技能文件放到了~/skills这种全局路径，而 AGENTS.md 写在项目根目录，两者不匹配。superpowers 的设计思路是技能文件必须和 AGENTS.md 在同一个上下文体系内，不能“一个在东一个在西”。如果你也想让一套技能服务于所有项目，不是不可以，但需要额外配置全局的 AGENTS.md（放在用户主目录或 Codex 的配置目录下），不建议新手一上来就这么干。

4. 核心技能拆解：superpowers 手里那几张王牌

4.1 增量 TDD 技能：让 AI 学会“先写测试再写实现”

superpowers 里我最喜欢、也是日常用最多的是“增量 TDD”（Test-Driven Development）技能。它本质上是在告诉 AI：接到一个开发任务后，不要闷头写实现代码，而是按红-绿-重构的节奏来推进，而且步子要小。

具体的流程大致是：先根据需求拆出最小可验证的行为，为这个行为写一个失败测试（红），跑测试确认它确实失败；然后写刚好能让这个测试通过的最简实现（绿）；接着运行完整测试套件确认没破坏其他功能；最后如果有必要就重构，重构后再次跑测试。整个过程循环往复，直到需求全部完成。

为什么这套流程对 AI 特别有用？因为 AI 最容易犯的两个错误，一是“一次写太多代码，改完连自己都说不清每行代码为什么要存在”，二是“不验证就交付，跑起来才发现在第一步就理解错了需求”。增量 TDD 从机制上强制它小步快跑，每步都有反馈，错误在最早期被暴露，而不是等到最后一次性爆炸。

我自己实测的场景是给一个订单系统加“折扣码支持”。没有 superpowers 的时候，我用 Codex 直接写，它一次性生成了一套包含校验、计算、过期判断的实现，结果测试一跑，过期逻辑和金额计算之间有个隐蔽的边界问题。后来用增量 TDD 技能重新来，Codex 自动拆分成了四个小步骤：先处理折扣码格式校验、再处理金额计算、再处理过期判断、最后处理和原有优惠叠加的逻辑。每一步都有测试护航，最后出来的代码质量和可读性都明显更好。

4.2 文件编辑器技能：解决“大文件改动难追踪”问题

第二个核心技能是“文件编辑器”（file editor）。这名字听起来平平无奇，但实际用起来能避免大量心智负担。它解决的问题是：AI 在处理大型源文件时，经常一口气重写整个文件，导致 diff 巨大、难以 review、还容易无意间改动和需求无关的代码。

按照这个技能，AI 会先使用类似grep或find的方式定位到具体需要修改的函数和区域，然后只对那一小部分做精准替换，而不是整文件覆盖。在 Codex 的交互界面上，你会看到它用类似“读取文件的前 50 行和待修改位置附近的内容，然后应用一个 patch”这种操作方式。

这背后的原理是，AI 模型对“局部修改”的把握远比对“全文重写”的把握要准。大文件的全文重写，哪怕模型再强，也可能在重写过程中丢失某些微妙的状态逻辑——比如一个标志位、一个异常处理的 beforeEach。局部 patch 把改动面控制到最小，出错的概率自然就小得多。

用这个技能还有一个附带好处：它的输出 diff 质量高，非常适合代码评审。如果你团队有“人工 review AI 产出”的流程，你会明显感觉到用文件编辑器技能产出的 diff 每一处改动都有明确目的，而以前那种整文件重写的 diff 简直无从审起。

4.3 调试器技能：把“猜 bug”变成“查 bug”

第三个重量级技能是“调试器”（debugger）。这个技能对应的场景不用多说，所有程序员每天都可能遇到。关键是它的处理流程——它明确规定 AI 不能“直接给出修复建议”，必须先走一遍标准排查流程。

具体来说，第一步是复现问题：写一个最小化的复现脚本或测试用例，让 bug 稳定出现。第二步是圈定范围：通过二分搜索或日志输出，定位到具体的函数或模块。第三步是提出假设：基于对代码的理解列出可能的原因，并设计验证方式。第四步是应用修改并验证：每改一处都要重新运行刚才的复现用例，确认问题真的解决，同时跑一遍相关测试确保没引入回归。

这套流程对 AI 的约束力出乎意料地强。原生的 Codex 接到 bug 描述后，经常会“学”训练数据里的模式——比如看到空指针就想到加判空，看到超时就想到加超时配置，但有时候根本原因完全不在表面上。调试器技能逼着它先用测试复现，很多时候在复现过程中就把问题原因暴露了一大半。

有个很典型的例子，我遇到过一个问题：服务偶发性地报“数据库连接池耗尽”，原生 Codex 给的建议是调大连接池大小，听起来合理但治标不治本。用调试器技能后，它先写了一个并发脚本去复现连接池耗尽，然后通过打印线程堆栈发现是某个事务方法内部嵌套调用了自身，导致事务占用的连接迟迟不释放。这个根因如果靠“猜”很难找到，但靠流程可以。

4.4 Agentic 编码与批处理技能：多步任务的“指挥官模式”

除了上面三个，superpowers 还包含一个“Agentic 编码”（Agentic coding）技能，和一系列针对特定技术栈的批处理技能。Agentic 编码技能的设计目标，是让 AI 处理那些需要跨多个文件、多个步骤才能完成的复杂任务，比如“给项目引入一个新的日志框架”这种会牵动配置、工具类、多个模块的改动。

这类任务的特点是：如果让 AI 一股脑做，它经常会中途迷路——改到一半忘了最初目标，或者在某一步陷入细节出不来。Agentic 编码技能的做法是：在开工前先让 AI 制定一个“任务地图”，明确分几步走、每步的输出是什么、如何验证，然后严格按地图逐步推进，每完成一步打一个勾。

这个技能和我之前提的“增量 TDD”搭配起来效果尤其好：Agentic 编码负责“全局路径规划”，TDD 负责“每一步的具体落地质量”。一个管战略，一个管战术，配合默契。

另外，技能目录里还有针对 Java、Spring、前端等不同技术栈的专项技能文件。比如 Java 项目会把“编译错误优先处理”“测试命令用 Maven surefire 的某种格式”“类命名遵循 PascalCase”这些细节写进去。这些内容单独看都算不上什么高深知识，但预置给 AI 之后，它能少犯很多低级的、令人生气的错误——比如明明项目用 Maven 它却让你加 Gradle 依赖，或者生成的类名风格和现有代码完全不一致。

5. 实战演练：一个完整的功能开发跑一遍流程

5.1 场景设定：给图书管理 API 加“软删除”能力

光讲技能是什么，不演示怎么组合用，价值会打折扣。我拿一个自己最近用 superpowers 完整做过的小需求来拆解：给一个现有的 Spring Boot 图书管理 API 增加“软删除”能力，即删除图书不是从数据库物理删除行，而是打一个deleted标记，查询时自动过滤。

这个需求看起来不复杂，但涉及的点其实不少：实体类要加字段、查询接口要过滤、删除接口要改逻辑、已有测试要更新、还要考虑“软删除后再次创建同 ISBN 的书”这种边界情况。我用原生命令做惯了，这次故意用 superpowers 从头走一遍，看它能不能把流程hold住。

5.2 从任务输入到 Codex 的响应

我在 Codex CLI 里输入的任务描述大致是：

给图书模块实现软删除功能。要求： 1. Book 实体增加 deleted 字段，默认为 false 2. 删除操作改为设置 deleted=true 3. 所有查询接口自动过滤已删除的图书 4. 保留物理删除方法，仅供内部清理任务使用 5. 使用 TDD 方式开发，先写测试再写实现

然后重点来了：因为 AGENTS.md 里已经声明了 superpowers 的技能目录，Codex 看到“使用 TDD 方式开发”这句话时，会自动去定位到增量 TDD 技能文件。它的第一步不是写代码，而是输出了一份简短的“执行计划”，大意是：“我将按照增量 TDD 流程依次完成以下步骤：先为实体类字段添加写迁移测试、再为查询过滤写集成测试、再为删除逻辑写单元测试、最后处理边界情况。”并且明确说明了它会在每一步完成后运行对应的测试命令。

这一步在原生的 Codex 上几乎看不到——它通常直接就开始写代码了。倒不是说原生有什么不对，而是少了这层“规划+承诺”，后续的执行就会缺少锚点，容易跑偏。

5.3 逐技能的流程记录

第一个推进的是增量 TDD。Codex 第一步写了一个测试，验证在 BookRepository 里调用findAll()时，被软删除的图书不会出现在结果集中。跑测试，当然失败——因为deleted字段还不存在。然后它给实体类和数据库迁移脚本加了字段，再跑测试，这次通过了。

这时候它没有继续往下写查询过滤逻辑，而是先停了下来，运行了整个模块的测试套件，看这个新字段有没有破坏现有功能。确认没问题，才继续下一步：改删除接口。它用文件编辑器技能精准定位到BookController.delete()和BookService.delete()两个方法，只改了那两个方法体，把原来的物理删除调用换成了设置deleted=true，完全没动其他无关代码。

接着再补一个测试，验证重复创建相同 ISBN 的图书不受软删除记录影响。这一步我本来以为它会用一个复杂的方式处理，结果它按批处理技能里的“数据库唯一索引升级”提示，把唯一索引从单列 ISBN 改成了(isbn, deleted)的联合索引——这个方案其实非常合理，既解决了冲突，又保留了历史记录。

整个流程走下来，给我的感受是：它每一步的目标都很小、验证都很直接，而且不会越过当前步骤去抢跑后面的工作。这种“克制”对一个会写代码的 AI 来说太难得了。

5.4 实测结果与效率评估

同样这个需求，我用原生的 Codex CLI 也试着写过一次。对比一下两边的差异：

当然这个对比不算严格的 benchmark，毕竟同一个模型在不同上下文下的表现受很多变量影响。但多次实验下来，我的经验是：**superpowers 不一定能让 AI 写出更聪明的代码，但一定能让它写出更好维护的代码。**它给 AI 建立了一个“工程技术纪律”的护栏，把产出稳定在合格线以上。

6. 常见问题排查与经验避坑

6.1 技能文件“没生效”怎么办

这个问题我遇到不止一次，也是社区论坛里最常见的求助帖。症状是：AGENTS.md 和 skills 目录都放好了，问 Codex“你有什么技能”，它说没有。排查思路按顺序来：

第一，检查 Codex CLI 的版本。superpowers 对上下文协议的依赖比较新，codex --version如果低于某个版本（具体看项目 README 的说明），确实会读不到 AGENTS.md 里引用的技能文件。升级到最新版通常能解决。

第二，检查文件路径。AGENTS.md 必须放在 Codex 启动时的工作目录（也就是你的项目根目录）下，skills 目录必须和 AGENTS.md 在同一个项目树内。如果你把 skills 放在了子目录里、而 AGENTS.md 在根目录，需要在 AGENTS.md 里写明相对路径，否则 AI 找不到。

第三，检查 AGENTS.md 的语法。有些技能描述里用了相对复杂的 Markdown 格式，比如嵌套列表、表格，老版本协议解析器对这种结构的支持不稳定。解决方法是参照项目原版的格式精简一下你的自定义内容，别搞太复杂。

6.2 技能之间发生“冲突”怎么处理

superpowers 的技能文件数量不少，有时候会覆盖同一个场景。比如“增量 TDD”技能和“Agentic 编码”技能都可能涉及“任务开始前先规划”的指令，AI 同时读到两套表达不完全一致的流程时，偶尔会混乱——表现为代码写到一半突然问“我是该先写测试还是先做任务地图”。

遇到这种情况，我的解决办法是在 AGENTS.md 里加一条优先级说明。比如明确写：“当任务需要在多个文件中实现新功能时，优先遵循 Agentic Coding 技能进行路径规划；当任务聚焦于单个模块的行为变化时，优先遵循 Incremental TDD 技能。”这等于给了 AI 一个“当规则冲突时听谁的”的裁决机制，效果立竿见影。

6.3 上下文窗口被撑爆怎么办

superpowers 会在 Codex 的上下文里注入相当多的技能描述，再加上你的项目自定义信息，确实有可能在长对话中把上下文塞满。症状是：对话进行到一半，Codex 开始“忘记”开头的技能指令，行为退化回没有技能的状态。

两个应对思路。一个是“减负”：在 AGENTS.md 里只声明你当前需要的技能，不用把全部技能文件都挂上来。另一个是“分段”：把大的任务拆成几个独立的 Codex 会话，每个会话只聚焦一个技能。比如先开一个 TDD 会话把测试骨架写好，再开一个文件编辑器会话实现具体逻辑。会话之间通过 git 提交传递上下文，反而更干净。

6.4 与 worbuddy 等工具配合的注意点

热词里出现了“worbuddy 怎么用 superpowers”，这里我多说一嘴。worbuddy 这类工具本质上是 AI 编程助手的“前端壳”或“工作流编排器”，它们通常也走 AGENTS.md 协议。如果你是在 worbuddy 里使用 superpowers，大部分流程和直接用 Codex CLI 是一样的。

但有一个坑需要留意：这类工具有时会往上下文里注入自己的系统提示词，这些提示词可能会和 superpowers 的技能指令在行为约束层面产生冲突。我的建议是，如果发现 AI 的行为“既不像 worbuddy 默认的、也不像 superpowers 的”，优先检查工具本身的设置里是不是有独立的“项目指令”字段，把 superpowers 入口文件的关键内容也粘贴一份过去，双保险。

6.5 完整排错速查表

7. 我的真实体会：什么项目适合引入 superpowers，什么项目没必要

最后聊一点个人化的感受。大概是在这个项目上折腾了十来天之后，我对它的定位有了更清晰的认识——它并不是一个“装了就能让你的 AI 变强十倍”的魔法插件，它是一个“工作方法论强制约束器”。它的价值曲线和项目的复杂度强相关。

如果只是写一次性脚本、临时数据分析、几十行的小工具，说实话没必要装 superpowers。这些场景需要的是“快速、直接”，技能文件里那套流程反而显得繁琐，徒增无意义的步骤。但如果是正经的工程化项目——有多模块架构、有长期积累的代码库、有团队协作和代码评审、有测试规范——那 superpowers 带来的价值就非常明显。它让 AI 的行为方式从“哪个实习生来了都会干的毛躁样”变成“待过一年、熟悉团队规范的中级工程师”。

它也不是银弹。模型本身的水平仍然决定了最终产出质量的上限，superpowers 能做的只是帮你把下限抬高。如果你的 Codex 本身就是一本正经的“老黄牛”，装上后它会更有章法；如果它原来就是个“乱冲锋的愣头青”，装上后至少能把它约束在正确的跑道上。

我自己现在的工作流是：所有交给 Codex 的任务都会先过一遍“这个任务需不需要流程化管理”的判断题。需要的话，就给它明确指定用哪个技能；不需要的话，就当普通对话使。这种“该严肃时严肃，该随意时随意”的分工，反而让 superpowers 的威力发挥得最充分。

最后分享一个小经验：不要一次性把所有技能文件全挂在 AGENTS.md 里。技能多了之后，AI 在做“技能选择”这件事上会出现选择困难。我推荐的配置是“4+3”——四个总在用的通用技能（增量 TDD、文件编辑器、调试器、Agentic 编码）加三四个针对你当前项目技术栈的专项技能，其他的留在目录里备用但不声明。这个数量级下，Codex 的技能触发率和执行质量是最好的。你可以把它当成一个免费的“团队新人入职培训”，培训内容少而精，比厚厚一大本手册更有用。