1. 先说清楚superpowers 到底是哪门子的超能力1.1 AI 编程助手为什么“总是差一步”最近如果你也在用 Codex CLI大概率已经碰到过这种感觉让它写一个函数写得很利索让它从头到尾实现一个完整功能就开始“指一步走一步”。你让它加个折扣计算它直接打开 OrderService 改起来改完之后你发现没测试跑起来还报错你问它为什么没有测试它道个歉又改了一版还是不测试。这不是模型不够聪明而是它默认的工作模式就是“根据你这句话猜下一段代码”。它不会像资深工程师一样在动手之前自动过一遍需求是否清楚、测试用例有哪些、先做什么后做什么、怎么验证自己有没有做对。它更像一个打字很快但不太会自己安排活儿的实习生你给一句它干一句。superpowers 这个项目就是专门来治这个病的。它不是给你个人用的“效率神器”而是给 Codex 这类 AI 编程助手装的一套技能包让它们在你下达任务之后先按照一套标准流程走先列计划、先写测试、确认失败、再实现、再重构。看起来只是换了个方式说话实际用下来差别非常大。这类工具为什么这几个月忽然火起来还有一个现实背景Codex、Claude Code 这些编码代理已经能读文件、跑命令、看测试结果能力上“手”是齐了但缺一套工作方法。superpowers 补的正是这一块——不是给 AI 加功能而是给 AI 加流程。1.2 “技能包”到底是个什么东西要理解 superpowers得先说清楚这里面的“技能”是什么。一个技能本质上就是一个目录目录里放一个用 Markdown 写成的SKILL.md文件。这个文件里面写着某个能力的完整操作步骤、注意事项、检查清单。比如 TDD 技能文件里可能会写当接到一个“实现新功能”的任务时必须按以下步骤执行列出需求中的边界条件写出至少 3 个测试用例只写第一个测试运行测试确认它是失败的用最少的代码让这个测试通过运行全部测试确认没有回归重构并保持测试全绿。当对话中触发了对应技能AI 会读取文件然后照着这个流程干活。和普通 prompt 的区别在于普通 prompt 是你在对话里临时说一句“你要先写测试啊”AI 可能这一轮记住了几轮之后就被上下文冲掉了。技能文件是稳定存在的每次都能读到而且可以被版本管理、可以团队共享。我用一个不太精准但比较好懂的类比普通 prompt 是你在工位上喊一句“新来的干活记得先测一下”技能包则是你递过去一本操作手册里面不光写了“要测”还写了“怎么测、测挂了怎么办、什么时候可以提交”。AI 的效果自然会不一样。1.3 为什么大家都在搜“codex superpowers”和“superpowers java”从最近的热搜词来看最集中的两类需求就是怎么在 Codex 里装上 superpowers以及在 Java 项目里怎么用。前者好理解很多人已经把 Codex CLI 作为日常工具了装技能包是自然下一步。后者也合理——Java 项目通常有 Maven/Gradle 这种成熟的构建体系有 JUnit 这种强测试惯例代码改动往往牵一发动全身。AI 如果不管三七二十一直接改代码很容易出现“编译过了但业务逻辑错了”的情况。而 superpowers 里的 TDD、系统调试这类流程恰好是 Java 工程化开发里最缺、也最需要的那部分。所以下面我会以 Codex 环境为主线讲清楚安装、配置、实战和踩坑。Claude Code 的安装思路完全一样只是目录和配置字段略有差异你可以对照着来。2. 安装把 superpowers 接到 Codex 上2.1 先确认基础环境在动手之前先确认你已经在用 Codex CLI并且能正常登录使用。这一步跳过的话后面全部白搭。打开终端跑一下codex --version如果你的版本比较老先升级到当前稳定版。原因很简单太老的版本可能还没有开放技能目录读取的机制装了半天读不到白折腾。此外需要一个能用的 git 环境因为技能包本身是一个 git 仓库后面升级、回滚都要靠它。Node.js 版本建议 18 及以上这也是 Codex 官方常见的要求我的话只是帮你确认一下具体以官方 README 为准。2.2 把技能包仓库克隆到本地定位到用户目录把 superpowers 仓库克隆到 Codex 的技能目录下。我目前环境里是这样做的git clone https://github.com/obra/superpowers ~/.codex/skills/superpowers如果你只希望当前项目生效也可以放在项目目录下的.codex/skills/文件夹里。区别在于用户级目录对所有项目生效适合个人长期使用项目级目录方便团队一起维护可以跟着仓库走。新手我建议先用用户级等确定这个流程对你有用再迁到项目级。需要强调一点这种技能类项目迭代很快仓库地址和目录结构也许会变。安装前花三十秒看一下官方 README比我写什么你都信要靠谱。我这里写的是在我自己环境里验证过的通用路径。2.3 让 Codex 知道去哪读技能克隆只是把文件放到本地Codex 还要知道去这个目录加载。目前不同版本给出的配置方式不一样常见的有两种第一种启动时用命令行参数类似codex --skill-dir ~/.codex/skills第二种在 Codex 的配置文件里写死目录。路径一般是~/.codex/config.toml打开之后加一段[skills] dirs [ ~/.codex/skills, ]配置完记得退出当前 Codex 会话再重开。技能文件一般在会话启动时读取你开着一个老会话去改配置、改文件它是感知不到的。这个问题我后来踩过好几次每次都要提醒自己。如果你发现自己的 Codex 版本里既没有--skill-dir也没有[skills]这个配置项不要硬猜直接codex --help看它认哪些参数或者去官方文档查插件和技能相关的说明。不同版本的字段名会有差异这不是你在网上看到的教程错了而是工具本身还没统一。2.4 验证安装到底成没成装完之后别急着开始干活先验证一下。新开一个 Codex 会话输入请列出你当前加载了哪些技能。如果配置没问题输出里应该能看到 test-driven-development、systematic-debugging 之类的名字。看到名字说明技能入口已经通了。如果没看到名字按顺序排查三件事路径对不对ls ~/.codex/skills/superpowers/skills看看里面是不是真的有SKILL.md。会话有没有重启技能快照是会话级别的老会话不会自动发现新文件。目录层级对不对有些版本要求目录名和技能名一致层级不能多套一层。这三条占了安装失败原因的九成剩下那一成是版本兼容问题先升级再试。3. 核心技能包拆解AI 到底多了哪些真本事3.1 看一下技能包目录结构superpowers 装好之后里面并不是一个大文件而是按技能分好的一组目录。大致长这样superpowers/ ├── README.md ├── skills/ │ ├── test-driven-development/ │ │ ├── SKILL.md │ │ └── examples/ │ ├── systematic-debugging/ │ │ └── SKILL.md │ ├── careful-coding/ │ │ └── SKILL.md │ └── ... └── tools/skills目录是核心每一个子目录代表一个技能。examples里面是一些示例对话或示例代码AI 可以通过这些例子理解“这种场景下我该怎么表现”。tools目录通常放一些辅助脚本。我说实话第一次看到这种结构时有点意外——这么火的项目核心竟然只是 Markdown 文件。但用了一周之后我理解了对模型来说结构清晰的文本指令就是最高效的引导方式。你不需要写复杂的插件逻辑你只需要把流程说清楚模型就能照着走。这也是为什么技能包可以快速流行任何一个懂行的人都能直接打开SKILL.md修改。3.2 TDD 技能让 AI 先把测试写给你看在 superpowers 里最值得先试的就是 test-driven-development 技能也就是 TDD。为什么对 AI 特别有效因为模型天生有“抄近路”的倾向。你让它实现一个功能它大概率会顺手把测试也一起写出来而且这测试多半能通过——因为实现和测试是同一个模型在同一个回合里生成出来的等于自己出题自己答看起来“全绿”实际没有验证价值。TDD 技能干的是一件事强制把“先写测试”和“再写实现”拆成两个独立步骤并且中间必须运行一次测试看到失败。你可以在会话里这样要求在这个项目里使用 test-driven-development 技能开发一个功能计算订单折扣。先写测试运行 mvn test 确认失败再实现最后再跑测试。这时候 AI 的行为会和平时明显不一样。它会先列出测试用例让你看边界条件够不够全然后写出第一个测试并执行把失败信息摆在你面前确认“红了”之后才开始动手写实现。整个过程有极强的节奏感。有一点要提醒很多人用了这个技能但感觉没效果问题出在“运行测试”这一步。如果你的 Codex 没有执行mvn test的权限或者项目根目录不对AI 会默认跳过运行直接自己脑补“测试应该能过”。没看到真实的红色就等于没做 TDD。后面我会专门讲权限怎么配。3.3 系统调试技能让 AI 停止“瞎改-道歉”循环另一个我经常用的技能是 systematic-debugging属于调试方法论。AI 调试代码的日常大家都不陌生你给它一段报错日志它看到最后一行开始猜原因改一个地方不行再改一个还不行然后开始道歉。这个循环特别让人高血压因为它根本没有在“调试”它只是在“试探”。systematic-debugging 技能会强制 AI 换一套打法先复现问题确认不是偶发的收集完整的错误信息而不是只看最后一行列出几种可能的根因并给出每一项的判断依据用最小的实验去验证假设确认之后再做改动改动之后重新运行确认问题消失并且没有引入回归。拿 Java 项目举例以前 AI 看到一个 NullPointerException 的堆栈经常直接改调用处加个判空。用了调试技能之后它会先看整个堆栈找到真正传入 null 的源头再问“这个值是从哪里来的为什么这里会是 null”最后根据根因来修。这两种做法结果可能都是加了一个判空但前者可能掩盖了上游的数据问题后者才可能真正把 bug 解决。3.4 别的技能怎么选superpowers 里还包含一些与规划、代码打磨相关的技能。比如动手编码之前先输出一份计划或者完成后做一轮自查看看有没有遗漏边界、有没有删除无用代码。我的建议是刚开始不要一口气全开。先激活 TDD 一个技能用上一周等你在 Codex 的对话里已经习惯了它“先测试后实现”的节奏再加调试技能。技能包这东西和人的习惯一样堆太多反而让 AI 在每一步都要判断“该用哪个”容易混乱。少而精效果反而更好。4. 实战在 Java 项目里用 superpowers 走完一个完整功能4.1 准备一个最小的 Maven 项目前面说了这么多还是得来一个真实的 Java 场景。我挑了一个非常常见的需求OrderService增加一个满减折扣功能规则是满 300 减 50金额不能小于 0。项目结构我直接手写不用 IDE 生成方便你复现order-service/ ├── pom.xml └── src/ ├── main/java/com/example/OrderService.java └── test/java/com/example/OrderServiceTest.javapom.xml里面最关键的依赖是 JUnit 5dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency /dependenciesOrderService.java一开始可以只是一个空壳package com.example; public class OrderService { public double calculateDiscount(double amount) { return amount; } }这么做是为了让后续的“红-绿-重构”过程更完整。如果一开始就写了一大坨实现技能包的流程感就被冲淡了。4.2 在 Codex 会话里让 AI 走一遍 TDD接下来打开 Codex输入这样一段请使用 test-driven-development 技能为 OrderService 增加满减功能满 300 减 50金额不能小于 0。项目根目录是 /path/to/order-service用 Maven 跑测试。加了技能包之后AI 的回复会明显多一个步骤先给测试用例清单。我当时看到它列的是金额 300期望结果 250金额 299期望结果 299金额 0期望结果 0金额为负数应该抛出异常。然后它会在OrderServiceTest.java里先写这几个测试再执行mvn -q test。这一步会报失败因为calculateDiscount目前就是原样返回。AI 会把失败信息贴出来告诉你“测试如预期失败”。这时候才轮到实现。它会在OrderService.java里加上折扣逻辑和参数校验再跑一次测试。如果全绿它还会主动问你要不要做一次小重构把魔法数字 300 和 50 提成常量。整个过程下来你能明显感觉到它不是在“一口气交作业”而是在按流程走每一步。这种体验和没有 superpowers 时的区别用过一次就知道了。4.3 这段过程里我踩过的几个坑你以为装上技能包就万事大吉不是。我在 Java 项目里第一次用就遇到了至少三个问题。第一个是目录问题。Codex 有时候会在它自己认为的项目根目录执行mvn test但那里根本没有pom.xml结果报错它还一脸无辜。解决办法是在 prompt 里把绝对路径写清楚比如“项目根目录是 /Users/me/work/order-service”不要指望它每次都判断对。第二个是Maven 首次运行卡顿。新项目第一次跑mvn test要下载一堆依赖可能卡几十秒AI 有时候会以为命令无响应甚至自己取消掉。我的办法是先手动跑一遍mvn -q test把依赖库预热好再让 AI 去跑测试。第三个是断言风格。AI 默认生成的 JUnit 断言五花八门有assertEquals的有assertThat的如果你们团队统一用 AssertJ建议直接在技能文件里补一句“本团队测试断言统一使用 AssertJ”。不要指望它自己从项目里推断出来你写了这句话它就老实了。4.4 把团队规范写进技能包这也是 superpowers 这类项目最被低估的价值技能文件是可以改的。你可以打开~/.codex/skills/superpowers/skills/test-driven-development/SKILL.md在注意事项部分加上你们团队的约定比如“新功能必须覆盖边界条件”“测试命名统一用 should_xxx 格式”“不允许使用 System.out 调试”。保存之后重启 Codex 会话这些要求就会变成 AI 的默认行为。我自己团队做法是复制了一份技能包到公司内部 git 仓库和项目代码一起版本管理。这样新同事 clone 下来项目技能规范也一并到位AI 的行为在团队内部是统一的。这种“把人的工程规范翻译给 AI”的做法我猜是接下来一两年里很值得投入的方向。5. 常见问题与踩坑记录速查表5.1 技能装好了但 AI 完全不按技能走这是我被问得最多的一个问题。技能能看到但让它做 TDD它还是上来就写实现。原因通常不是没加载而是技能触发不够显式。你可以在 prompt 里直接点技能名比如“使用 test-driven-development 技能”这时候它没法假装没看见。还有一种更稳的做法把技能要求写进项目根目录的AGENTS.md文件里比如开始任何新功能开发时先应用 TDD 技能遵守“红-绿-重构”流程。AGENTS.md是很多编码代理会自动读取的项目级说明文件等于常驻的指令比你每次在对话里重复要稳定得多。5.2 AI 说“已加载技能”但行为没有变化这种情况一般有两个原因。一个原因是技能文件里的流程写得太过笼统模型读了但没有落到行动上。你可以打开SKILL.md检查一下看它里面有没有明确的“必须运行测试命令并展示失败输出”这类硬性要求。没有的话补上。另一个原因是上下文太长技能指令被淹没了。解决方法是把最关键的步骤写进AGENTS.md或者你在任务 prompt 里直接把技能包中最重要的一句话说出来比如“请先写完第一个测试并运行它确认失败后告诉我”。技能是辅助prompt 是主导两头都要有。5.3 Codex 执行mvn test被拦住了Codex 默认对命令执行有确认机制尤其是不在白名单里的命令它会弹确认或者直接拒绝。这种情况下 AI 不会真的去跑测试它可能就嘴上说“测试应该能过”然后继续推进——这就是 TDD 流程失效的根源。解决办法是在 Codex 配置里把mvn加入允许执行的命令或者把项目相关的测试命令放白名单。如果你用的是交互式会话第一次弹确认时选“总是允许”。这里我不展开具体配置字段因为版本差异挺大最简单的方法是测试一下codex --help里看有没有命令白名单相关参数。但安全问题必须强调不要为了省事直接全部允许。技能包本质上是一个对你“注入指令”的来源不可信的技能可能会让 AI 执行危险命令。你自己也要守住底线rm -rf这种命令永远不要让 AI 自动执行。5.4 升级技能包之后AI 行为突然变了技能包是个 git 仓库版本一变行为就可能变。你可能周日升了个级周一让 AI 干活发现它处理流程和你上个月习惯的不一样了。想稳定就锁定版本。在技能目录里跑git log --oneline -5 git checkout commit固定到某个 commit再也不用担心上游变化。需要升级时先看 changelog再在测试项目里试一下没问题再切换。5.5 安全提醒第三方技能包别乱装这一点单独拎出来说因为真的太容易忽略。技能包的本质是 Markdown 指令但它会引导 AI 去执行命令、读写文件。如果你从一个不信任的来源安装技能包就等于让别人替你给 AI 下达了一批指令。这些指令可能是良性的也可能夹带私货。我自己的标准是装之前把SKILL.md从头读一遍不理解的地方就问为什么tools目录里的脚本一定要打开看看懂之后再决定要不要安装。配置命令白名单时只放必要的构建和测试命令。安全这事儿靠别人不如靠自己。最后再说几句实在的superpowers 用下来给我最大冲击的不是某一单次输出质量高了而是 AI 终于开始“有节奏”了。以前它像那种手速飞快但想到哪写到哪的开发者现在它更像一个按着 check-list 推进的工程师先列测试用例、红了、绿了、再重构。你看得到它在做什么也知道下一步是什么心里踏实很多。如果你刚开始接触这套东西我建议不要一把梭把全部技能都开了。就先一个 TDD在一个简单的 Java 项目里跑通“红-绿-重构”的流程感受一下它带来的变化再慢慢加上系统调试、代码审查这些技能。技能不在多用得顺手才是关键。最后再分享一个小技巧技能文件其实是文本你可以把它当成一份给 AI 的“团队新人手册”来维护。凡是 AI 没做好的地方都可以在SKILL.md里补一句硬性要求改完立刻重启会话试一次。这个过程本身就是把自己的工程经验沉淀成可复用资产的过程。 
长河君 · 2026/11/4 10:44:54 · 阅读 1.2k 给 Codex 装上 superpowers：用技能包让 AI 编程助手真正按流程干活
1. 先说清楚superpowers 到底是哪门子的超能力1.1 AI 编程助手为什么“总是差一步”最近如果你也在用 Codex CLI大概率已经碰到过这种感觉让它写一个函数写得很利索让它从头到尾实现一个完整功能就开始“指一步走一步”。你让它加个折扣计算它直接打开 OrderService 改起来改完之后你发现没测试跑起来还报错你问它为什么没有测试它道个歉又改了一版还是不测试。这不是模型不够聪明而是它默认的工作模式就是“根据你这句话猜下一段代码”。它不会像资深工程师一样在动手之前自动过一遍需求是否清楚、测试用例有哪些、先做什么后做什么、怎么验证自己有没有做对。它更像一个打字很快但不太会自己安排活儿的实习生你给一句它干一句。superpowers 这个项目就是专门来治这个病的。它不是给你个人用的“效率神器”而是给 Codex 这类 AI 编程助手装的一套技能包让它们在你下达任务之后先按照一套标准流程走先列计划、先写测试、确认失败、再实现、再重构。看起来只是换了个方式说话实际用下来差别非常大。这类工具为什么这几个月忽然火起来还有一个现实背景Codex、Claude Code 这些编码代理已经能读文件、跑命令、看测试结果能力上“手”是齐了但缺一套工作方法。superpowers 补的正是这一块——不是给 AI 加功能而是给 AI 加流程。1.2 “技能包”到底是个什么东西要理解 superpowers得先说清楚这里面的“技能”是什么。一个技能本质上就是一个目录目录里放一个用 Markdown 写成的SKILL.md文件。这个文件里面写着某个能力的完整操作步骤、注意事项、检查清单。比如 TDD 技能文件里可能会写当接到一个“实现新功能”的任务时必须按以下步骤执行列出需求中的边界条件写出至少 3 个测试用例只写第一个测试运行测试确认它是失败的用最少的代码让这个测试通过运行全部测试确认没有回归重构并保持测试全绿。当对话中触发了对应技能AI 会读取文件然后照着这个流程干活。和普通 prompt 的区别在于普通 prompt 是你在对话里临时说一句“你要先写测试啊”AI 可能这一轮记住了几轮之后就被上下文冲掉了。技能文件是稳定存在的每次都能读到而且可以被版本管理、可以团队共享。我用一个不太精准但比较好懂的类比普通 prompt 是你在工位上喊一句“新来的干活记得先测一下”技能包则是你递过去一本操作手册里面不光写了“要测”还写了“怎么测、测挂了怎么办、什么时候可以提交”。AI 的效果自然会不一样。1.3 为什么大家都在搜“codex superpowers”和“superpowers java”从最近的热搜词来看最集中的两类需求就是怎么在 Codex 里装上 superpowers以及在 Java 项目里怎么用。前者好理解很多人已经把 Codex CLI 作为日常工具了装技能包是自然下一步。后者也合理——Java 项目通常有 Maven/Gradle 这种成熟的构建体系有 JUnit 这种强测试惯例代码改动往往牵一发动全身。AI 如果不管三七二十一直接改代码很容易出现“编译过了但业务逻辑错了”的情况。而 superpowers 里的 TDD、系统调试这类流程恰好是 Java 工程化开发里最缺、也最需要的那部分。所以下面我会以 Codex 环境为主线讲清楚安装、配置、实战和踩坑。Claude Code 的安装思路完全一样只是目录和配置字段略有差异你可以对照着来。2. 安装把 superpowers 接到 Codex 上2.1 先确认基础环境在动手之前先确认你已经在用 Codex CLI并且能正常登录使用。这一步跳过的话后面全部白搭。打开终端跑一下codex --version如果你的版本比较老先升级到当前稳定版。原因很简单太老的版本可能还没有开放技能目录读取的机制装了半天读不到白折腾。此外需要一个能用的 git 环境因为技能包本身是一个 git 仓库后面升级、回滚都要靠它。Node.js 版本建议 18 及以上这也是 Codex 官方常见的要求我的话只是帮你确认一下具体以官方 README 为准。2.2 把技能包仓库克隆到本地定位到用户目录把 superpowers 仓库克隆到 Codex 的技能目录下。我目前环境里是这样做的git clone https://github.com/obra/superpowers ~/.codex/skills/superpowers如果你只希望当前项目生效也可以放在项目目录下的.codex/skills/文件夹里。区别在于用户级目录对所有项目生效适合个人长期使用项目级目录方便团队一起维护可以跟着仓库走。新手我建议先用用户级等确定这个流程对你有用再迁到项目级。需要强调一点这种技能类项目迭代很快仓库地址和目录结构也许会变。安装前花三十秒看一下官方 README比我写什么你都信要靠谱。我这里写的是在我自己环境里验证过的通用路径。2.3 让 Codex 知道去哪读技能克隆只是把文件放到本地Codex 还要知道去这个目录加载。目前不同版本给出的配置方式不一样常见的有两种第一种启动时用命令行参数类似codex --skill-dir ~/.codex/skills第二种在 Codex 的配置文件里写死目录。路径一般是~/.codex/config.toml打开之后加一段[skills] dirs [ ~/.codex/skills, ]配置完记得退出当前 Codex 会话再重开。技能文件一般在会话启动时读取你开着一个老会话去改配置、改文件它是感知不到的。这个问题我后来踩过好几次每次都要提醒自己。如果你发现自己的 Codex 版本里既没有--skill-dir也没有[skills]这个配置项不要硬猜直接codex --help看它认哪些参数或者去官方文档查插件和技能相关的说明。不同版本的字段名会有差异这不是你在网上看到的教程错了而是工具本身还没统一。2.4 验证安装到底成没成装完之后别急着开始干活先验证一下。新开一个 Codex 会话输入请列出你当前加载了哪些技能。如果配置没问题输出里应该能看到 test-driven-development、systematic-debugging 之类的名字。看到名字说明技能入口已经通了。如果没看到名字按顺序排查三件事路径对不对ls ~/.codex/skills/superpowers/skills看看里面是不是真的有SKILL.md。会话有没有重启技能快照是会话级别的老会话不会自动发现新文件。目录层级对不对有些版本要求目录名和技能名一致层级不能多套一层。这三条占了安装失败原因的九成剩下那一成是版本兼容问题先升级再试。3. 核心技能包拆解AI 到底多了哪些真本事3.1 看一下技能包目录结构superpowers 装好之后里面并不是一个大文件而是按技能分好的一组目录。大致长这样superpowers/ ├── README.md ├── skills/ │ ├── test-driven-development/ │ │ ├── SKILL.md │ │ └── examples/ │ ├── systematic-debugging/ │ │ └── SKILL.md │ ├── careful-coding/ │ │ └── SKILL.md │ └── ... └── tools/skills目录是核心每一个子目录代表一个技能。examples里面是一些示例对话或示例代码AI 可以通过这些例子理解“这种场景下我该怎么表现”。tools目录通常放一些辅助脚本。我说实话第一次看到这种结构时有点意外——这么火的项目核心竟然只是 Markdown 文件。但用了一周之后我理解了对模型来说结构清晰的文本指令就是最高效的引导方式。你不需要写复杂的插件逻辑你只需要把流程说清楚模型就能照着走。这也是为什么技能包可以快速流行任何一个懂行的人都能直接打开SKILL.md修改。3.2 TDD 技能让 AI 先把测试写给你看在 superpowers 里最值得先试的就是 test-driven-development 技能也就是 TDD。为什么对 AI 特别有效因为模型天生有“抄近路”的倾向。你让它实现一个功能它大概率会顺手把测试也一起写出来而且这测试多半能通过——因为实现和测试是同一个模型在同一个回合里生成出来的等于自己出题自己答看起来“全绿”实际没有验证价值。TDD 技能干的是一件事强制把“先写测试”和“再写实现”拆成两个独立步骤并且中间必须运行一次测试看到失败。你可以在会话里这样要求在这个项目里使用 test-driven-development 技能开发一个功能计算订单折扣。先写测试运行 mvn test 确认失败再实现最后再跑测试。这时候 AI 的行为会和平时明显不一样。它会先列出测试用例让你看边界条件够不够全然后写出第一个测试并执行把失败信息摆在你面前确认“红了”之后才开始动手写实现。整个过程有极强的节奏感。有一点要提醒很多人用了这个技能但感觉没效果问题出在“运行测试”这一步。如果你的 Codex 没有执行mvn test的权限或者项目根目录不对AI 会默认跳过运行直接自己脑补“测试应该能过”。没看到真实的红色就等于没做 TDD。后面我会专门讲权限怎么配。3.3 系统调试技能让 AI 停止“瞎改-道歉”循环另一个我经常用的技能是 systematic-debugging属于调试方法论。AI 调试代码的日常大家都不陌生你给它一段报错日志它看到最后一行开始猜原因改一个地方不行再改一个还不行然后开始道歉。这个循环特别让人高血压因为它根本没有在“调试”它只是在“试探”。systematic-debugging 技能会强制 AI 换一套打法先复现问题确认不是偶发的收集完整的错误信息而不是只看最后一行列出几种可能的根因并给出每一项的判断依据用最小的实验去验证假设确认之后再做改动改动之后重新运行确认问题消失并且没有引入回归。拿 Java 项目举例以前 AI 看到一个 NullPointerException 的堆栈经常直接改调用处加个判空。用了调试技能之后它会先看整个堆栈找到真正传入 null 的源头再问“这个值是从哪里来的为什么这里会是 null”最后根据根因来修。这两种做法结果可能都是加了一个判空但前者可能掩盖了上游的数据问题后者才可能真正把 bug 解决。3.4 别的技能怎么选superpowers 里还包含一些与规划、代码打磨相关的技能。比如动手编码之前先输出一份计划或者完成后做一轮自查看看有没有遗漏边界、有没有删除无用代码。我的建议是刚开始不要一口气全开。先激活 TDD 一个技能用上一周等你在 Codex 的对话里已经习惯了它“先测试后实现”的节奏再加调试技能。技能包这东西和人的习惯一样堆太多反而让 AI 在每一步都要判断“该用哪个”容易混乱。少而精效果反而更好。4. 实战在 Java 项目里用 superpowers 走完一个完整功能4.1 准备一个最小的 Maven 项目前面说了这么多还是得来一个真实的 Java 场景。我挑了一个非常常见的需求OrderService增加一个满减折扣功能规则是满 300 减 50金额不能小于 0。项目结构我直接手写不用 IDE 生成方便你复现order-service/ ├── pom.xml └── src/ ├── main/java/com/example/OrderService.java └── test/java/com/example/OrderServiceTest.javapom.xml里面最关键的依赖是 JUnit 5dependencies dependency groupIdorg.junit.jupiter/groupId artifactIdjunit-jupiter/artifactId version5.10.0/version scopetest/scope /dependency /dependenciesOrderService.java一开始可以只是一个空壳package com.example; public class OrderService { public double calculateDiscount(double amount) { return amount; } }这么做是为了让后续的“红-绿-重构”过程更完整。如果一开始就写了一大坨实现技能包的流程感就被冲淡了。4.2 在 Codex 会话里让 AI 走一遍 TDD接下来打开 Codex输入这样一段请使用 test-driven-development 技能为 OrderService 增加满减功能满 300 减 50金额不能小于 0。项目根目录是 /path/to/order-service用 Maven 跑测试。加了技能包之后AI 的回复会明显多一个步骤先给测试用例清单。我当时看到它列的是金额 300期望结果 250金额 299期望结果 299金额 0期望结果 0金额为负数应该抛出异常。然后它会在OrderServiceTest.java里先写这几个测试再执行mvn -q test。这一步会报失败因为calculateDiscount目前就是原样返回。AI 会把失败信息贴出来告诉你“测试如预期失败”。这时候才轮到实现。它会在OrderService.java里加上折扣逻辑和参数校验再跑一次测试。如果全绿它还会主动问你要不要做一次小重构把魔法数字 300 和 50 提成常量。整个过程下来你能明显感觉到它不是在“一口气交作业”而是在按流程走每一步。这种体验和没有 superpowers 时的区别用过一次就知道了。4.3 这段过程里我踩过的几个坑你以为装上技能包就万事大吉不是。我在 Java 项目里第一次用就遇到了至少三个问题。第一个是目录问题。Codex 有时候会在它自己认为的项目根目录执行mvn test但那里根本没有pom.xml结果报错它还一脸无辜。解决办法是在 prompt 里把绝对路径写清楚比如“项目根目录是 /Users/me/work/order-service”不要指望它每次都判断对。第二个是Maven 首次运行卡顿。新项目第一次跑mvn test要下载一堆依赖可能卡几十秒AI 有时候会以为命令无响应甚至自己取消掉。我的办法是先手动跑一遍mvn -q test把依赖库预热好再让 AI 去跑测试。第三个是断言风格。AI 默认生成的 JUnit 断言五花八门有assertEquals的有assertThat的如果你们团队统一用 AssertJ建议直接在技能文件里补一句“本团队测试断言统一使用 AssertJ”。不要指望它自己从项目里推断出来你写了这句话它就老实了。4.4 把团队规范写进技能包这也是 superpowers 这类项目最被低估的价值技能文件是可以改的。你可以打开~/.codex/skills/superpowers/skills/test-driven-development/SKILL.md在注意事项部分加上你们团队的约定比如“新功能必须覆盖边界条件”“测试命名统一用 should_xxx 格式”“不允许使用 System.out 调试”。保存之后重启 Codex 会话这些要求就会变成 AI 的默认行为。我自己团队做法是复制了一份技能包到公司内部 git 仓库和项目代码一起版本管理。这样新同事 clone 下来项目技能规范也一并到位AI 的行为在团队内部是统一的。这种“把人的工程规范翻译给 AI”的做法我猜是接下来一两年里很值得投入的方向。5. 常见问题与踩坑记录速查表5.1 技能装好了但 AI 完全不按技能走这是我被问得最多的一个问题。技能能看到但让它做 TDD它还是上来就写实现。原因通常不是没加载而是技能触发不够显式。你可以在 prompt 里直接点技能名比如“使用 test-driven-development 技能”这时候它没法假装没看见。还有一种更稳的做法把技能要求写进项目根目录的AGENTS.md文件里比如开始任何新功能开发时先应用 TDD 技能遵守“红-绿-重构”流程。AGENTS.md是很多编码代理会自动读取的项目级说明文件等于常驻的指令比你每次在对话里重复要稳定得多。5.2 AI 说“已加载技能”但行为没有变化这种情况一般有两个原因。一个原因是技能文件里的流程写得太过笼统模型读了但没有落到行动上。你可以打开SKILL.md检查一下看它里面有没有明确的“必须运行测试命令并展示失败输出”这类硬性要求。没有的话补上。另一个原因是上下文太长技能指令被淹没了。解决方法是把最关键的步骤写进AGENTS.md或者你在任务 prompt 里直接把技能包中最重要的一句话说出来比如“请先写完第一个测试并运行它确认失败后告诉我”。技能是辅助prompt 是主导两头都要有。5.3 Codex 执行mvn test被拦住了Codex 默认对命令执行有确认机制尤其是不在白名单里的命令它会弹确认或者直接拒绝。这种情况下 AI 不会真的去跑测试它可能就嘴上说“测试应该能过”然后继续推进——这就是 TDD 流程失效的根源。解决办法是在 Codex 配置里把mvn加入允许执行的命令或者把项目相关的测试命令放白名单。如果你用的是交互式会话第一次弹确认时选“总是允许”。这里我不展开具体配置字段因为版本差异挺大最简单的方法是测试一下codex --help里看有没有命令白名单相关参数。但安全问题必须强调不要为了省事直接全部允许。技能包本质上是一个对你“注入指令”的来源不可信的技能可能会让 AI 执行危险命令。你自己也要守住底线rm -rf这种命令永远不要让 AI 自动执行。5.4 升级技能包之后AI 行为突然变了技能包是个 git 仓库版本一变行为就可能变。你可能周日升了个级周一让 AI 干活发现它处理流程和你上个月习惯的不一样了。想稳定就锁定版本。在技能目录里跑git log --oneline -5 git checkout commit固定到某个 commit再也不用担心上游变化。需要升级时先看 changelog再在测试项目里试一下没问题再切换。5.5 安全提醒第三方技能包别乱装这一点单独拎出来说因为真的太容易忽略。技能包的本质是 Markdown 指令但它会引导 AI 去执行命令、读写文件。如果你从一个不信任的来源安装技能包就等于让别人替你给 AI 下达了一批指令。这些指令可能是良性的也可能夹带私货。我自己的标准是装之前把SKILL.md从头读一遍不理解的地方就问为什么tools目录里的脚本一定要打开看看懂之后再决定要不要安装。配置命令白名单时只放必要的构建和测试命令。安全这事儿靠别人不如靠自己。最后再说几句实在的superpowers 用下来给我最大冲击的不是某一单次输出质量高了而是 AI 终于开始“有节奏”了。以前它像那种手速飞快但想到哪写到哪的开发者现在它更像一个按着 check-list 推进的工程师先列测试用例、红了、绿了、再重构。你看得到它在做什么也知道下一步是什么心里踏实很多。如果你刚开始接触这套东西我建议不要一把梭把全部技能都开了。就先一个 TDD在一个简单的 Java 项目里跑通“红-绿-重构”的流程感受一下它带来的变化再慢慢加上系统调试、代码审查这些技能。技能不在多用得顺手才是关键。最后再分享一个小技巧技能文件其实是文本你可以把它当成一份给 AI 的“团队新人手册”来维护。凡是 AI 没做好的地方都可以在SKILL.md里补一句硬性要求改完立刻重启会话试一次。这个过程本身就是把自己的工程经验沉淀成可复用资产的过程。