1. 先说清楚superpowers 到底是个什么东西我最早看到 superpowers 这个词是在几个搞 Java 的朋友的聊天记录里。当时第一反应是又是什么中二命名的新框架后来自己把整套东西摸了一遍才发现这名字起得其实挺贴切——它不是给你写的代码加超能力而是给“你和 AI 编程助手协作的方式”加上超能力。简单说Superpowers 不是一门新语言也不是又一个 IDE 插件。它是一组专门用来“调教” AI 编程助手的规则集和工作流配置最常见的搭配对象就是 Codex 这类能直接读写代码库、执行命令的编程助手。装上它之后AI 的行为模式会发生肉眼可见的变化原本你问一句它就噼里啪啦生成几百行代码装上之后它会先问清楚需求再给方案然后小步执行每次改动之后还会主动去跑测试。这听起来像是“变乖了”实际上是被迫遵守了一套工程纪律。如果你在 Java 这种重类型、重构建、重测试的项目里被 AI 助手“答非所问”折磨过或者你每次让它改代码都要在 prompt 里反复强调“先别写代码、先分析、你确定吗”那你大概率会需要这套东西。它解决的核心痛点就是三个AI 不问需求就开写、一次生成太多导致没法审查、改完不验证就告诉你“完成了”。2. 安装与激活把技能包装进 Codex2.1 前置准备安装 Superpowers 之前先把基础环境理清楚。它本身不是独立程序而是依附在 AI 编程助手上的配置层所以你必须先有一个能用的 Codex 环境。这里的“能用”指三件事命令行工具能正常调用后端模型服务简单发一条指令能拿到回复工作目录是一个真实的、能被 Codex 读取的代码仓库不能是空文件夹本机已经装好 JDK 和 Maven 或 Gradle因为后面验证 Java 场景时AI 需要真正执行编译和测试命令而不是只在脑子里“假装通过”。我见过不少人卡在第一步。Codex 装好之后先跑一条最简单的指令比如让它“列出当前目录结构”确认它能读文件、能执行命令再继续。如果这一步都不稳定后面所有规则加载、技能调用都是空中楼阁。2.2 安装步骤Superpowers 的安装方式很轻本质上就是“把一份规则清单放到 Codex 能读到的地方再在启动配置里告诉它去加载”。我自己的做法是这样的# 1. 创建一个专门放规则集的目录 mkdir -p ~/.codex/rules # 2. 把 superpowers 的主规则文件放进去 # 这里可能是你下载的技能包也可能是一段需要手动保存的 markdown # 核心文件一般叫 superpowers.md 或 skills.md放好之后还要在 Codex 的配置里声明这个规则文件。不同的版本配置方式略有差异但大致思路是在配置文件的“规则列表”或“指令集”区域加一行rules: - ~/.codex/rules/superpowers.md如果你想针对某个 Java 仓库单独启用而不是全局生效可以把规则文件放在仓库的.codex/rules/目录下。这样项目里的协作者拉下来代码后各自本地环境会自动加载同一套规则团队行为就会非常一致这个好处我在后面专门讲。2.3 激活与验证装完之后怎么知道有没有生效不要看启动日志直接做一个行为测试。我建议你新建一个只有两个文件的临时 Java 项目然后对着 Codex 说一句话这里有一个简单的 Java 类请先不要修改任何代码只告诉我它有哪些可以优化的点。如果规则生效了Codex 会先读文件、列出观察结果然后反问你要不要动手。如果没生效它大概率直接甩出一版“优化后”的代码。这个差别非常明显十秒钟就能判断。还有一个细节Superpowers 的规则文件不是越长越好。上下文窗口是有限的你把几十页规则全塞进去真正留给业务代码的空间就少了。我自己用的是精简版只保留了四条核心纪律先探索、再提问、小步改、必验证。那些花哨的“角色扮演”设定实际收益很低不建议加。3. 用对方法superpowers 在 Java 项目里的实战拆解3.1 场景一把一个混乱的业务类拆成职责清晰的模块这是我觉得 Superpowers 最有价值的场景。Java 项目里的老代码动辄一千多行的 Service 类太常见了。以前让 AI 帮忙重构它经常一上来就给你生成十个新文件然后告诉你“重构完成”。你 review 的时候根本看不完也不敢合。有了 Superpowers 的纪律约束整个流程变成这样第一轮只探索。我给它下指令请阅读 OrderService.java先把所有 public 方法列出来标注每个方法依赖的外部服务、事务边界、以及是否被其他类调用。不要修改任何代码。Codex 会老老实实导出一份方法清单。这个过程看起来很慢但非常关键因为拆分重构的本质是梳理依赖而不是“把长类剪短”。第二轮只出方案。我让它基于清单给出拆分建议每个新类的职责、涉及的方法、需要迁移的私有方法都写清楚。注意这里我也要求它不得写实现代码。第三轮确认后小步执行。我挑一个内聚性最强的方法组让它先拆出一个类并且要求“拆完之后运行一下项目里现有的测试”。这种节奏下Codex 的准确率明显上升。原因很简单它每次只需要处理一个明确定义的小任务出错范围被限制住了。3.2 场景二让 Codex 先写测试再写实现Java 开发者对 AI 生成代码最没安全感的地方就是它写出来的方法看起来逻辑完整但边界情况全是坑。Superpowers 的工作流会强制把“测试先行”变成操作顺序而不是一句口号。操作方式是这样的我要新增一个方法根据订单状态和支付渠道计算可退款金额。请先为我编写 JUnit 测试覆盖以下场景已退款状态返回 0、未支付状态抛异常、微信支付与支付宝的费率不同。测试先写好不需要实现。注意这里的关键词是“测试先写好不需要实现”。规则集早就给 Codex 设定好了“测试未编译通过就不得开始写实现”的约束所以它不会偷偷抢跑。等测试文件生成完毕我再补一句现在请实现这个类让测试通过。实现过程中如果发现需求有歧义先列出问题不要自己猜。实测下来这个方法能过滤掉大量“看起来对、跑起来错”的问题。以前我 review AI 代码要自己脑补测试用例现在反过来我先 review 测试逻辑再让 AI 去补齐实现质量高很多。3.3 场景三批量迁移与正则替换讲一个更常见的土活老系统里有一批方法签名要从getXxx()改成xxx()或者某个第三方库的旧 API 要整体替换成新写法。这种工作机械、量大、又容易漏但让 AI 直接全量改往往会把不该碰的地方也改了。我的办法是先用 Superpowers 让它生成一份“迁移影响清单”扫描整个 src/main/java 目录找出所有调用了 oldSdk.process() 的文件按模块分组列出。不要做任何修改。拿到清单后我再指定一个模块让它改。每个模块改完立刻执行编译和单测。一旦某个模块翻车影响范围只有那几行代码回滚也容易。这套“清单先行、分组执行”的流程本质上是把 AI 当作一个很勤奋但容易误伤队友的实习生来管理。你把边界画清楚它效率极高你不画边界它能把整个仓库给你格式化。4. 高频问题与排查思路我自己的踩坑记录4.1 问题速查表用 Superpowers 的过程不是一帆风顺的。我把这半年里遇到的高频问题整理成一张表每条都是实测过的现象可能原因排查方法规则完全不生效AI 依然一上来就写代码规则文件路径没配对或者配置项没被加载在会话里直接问“你现在需要遵守哪些规则”看它能不能复述核心条款AI 会复述规则但行为不变规则太多太泛上下文被稀释精简规则只保留最关键的 4 到 5 条硬约束在 Java 泛型场景下反复翻车泛型推断对 AI 来说是个弱项容易强行套用模式让它先列出泛型边界再写代码坚持“先测试后实现”改完代码说“测试通过”实际没跑规则里“必验证”约束不够强或者缺少可执行命令提示在规则里明确写出“必须运行 mvn test 并贴出结果禁止口头声称通过”上下文丢失做到一半忘了最初目标单轮任务分解得太碎或者信息被后续对话覆盖每个子任务开始时用一句话重申目标重要约束写在固定位置批量迁移时误改无关代码探索阶段没做透AI 靠猜测扩大改动范围强制走“影响清单 → 单模块修改 → 编译测试”三步流程4.2 操作节奏上的三条铁律除了上面这些具体问题我更想说的是操作节奏。很多人把 Superpowers 当作“装上就变强”的神器结果发现 AI 还是经常犯傻原因多半出在你自己没遵守协作纪律。第一条铁律任务颗粒度要小。不要让它一次做完“重构整个服务并补充所有测试”。正确做法是拆成“梳理依赖”、“拆分第一个类”、“迁移第一个方法组”、“跑测试”四个独立回合。AI 的上下文和注意力都有限你把任务拆得越细它越不容易出错。第二条铁律约束条件要写进当前对话而不是只写在全局规则里。全局规则是“宪法”当前对话是“具体命令”。即使是同一套规则每次开始新任务时也要花十几秒把关键约束重申一遍。比如“请记住你现在只做探索不要写代码。”这句话看着多余实际能显著降低翻车率。第三条铁律验证动作必须让 AI 自己执行而不是靠它描述。我踩过最深的坑就是让 Codex“检查有没有问题”它回复“检查过了没有问题”结果编译一跑全是错。后来我在规则里加了硬性要求所有涉及代码改动的任务最终一步必须是执行构建命令并输出结果。宁可让它多花两分钟跑一遍也不能相信它的自我评价。5. 我的真实体会用了一段时间之后我越来越觉得 Superpowers 这类东西的本质不是技术工具而是一套“对话纪律”。我们平时抱怨 AI 编程助手不靠谱大多数时候是协作方式出了问题需求没说清楚、边界没画好、验证没落实。Superpowers 做的就是把这些问题用规则的形式固化成流程逼着使用者和 AI 双方都按工程方式来工作。对老手来说它带来的效率提升不是写代码更快而是 review 更轻松、返工更少。如果你准备在自己的项目里试试我有个小建议不要一口气把网上能找到的规则全装上。先只保留“先探索、再提问、小步改、必验证”这四件事用两周时间把它变成你和 AI 之间的肌肉记忆再根据自己项目的特性去加自定义规则。等这套节奏顺了你再看那些没有纪律约束的 AI 输出会明显感觉到差别。最后再分享一个后续可以扩展的方向把你在项目里沉淀下来的规则文件放进代码仓库让团队成员共用。当整个团队对 AI 的输出质量标准达成一致时Codex 才真正从“个人玩具”变成“团队生产力”。这才是 Superpowers 这个名字最值钱的地方。
Superpowers实战：用规则集驯服Codex，让AI编程助手遵守工程纪律
1. 先说清楚superpowers 到底是个什么东西我最早看到 superpowers 这个词是在几个搞 Java 的朋友的聊天记录里。当时第一反应是又是什么中二命名的新框架后来自己把整套东西摸了一遍才发现这名字起得其实挺贴切——它不是给你写的代码加超能力而是给“你和 AI 编程助手协作的方式”加上超能力。简单说Superpowers 不是一门新语言也不是又一个 IDE 插件。它是一组专门用来“调教” AI 编程助手的规则集和工作流配置最常见的搭配对象就是 Codex 这类能直接读写代码库、执行命令的编程助手。装上它之后AI 的行为模式会发生肉眼可见的变化原本你问一句它就噼里啪啦生成几百行代码装上之后它会先问清楚需求再给方案然后小步执行每次改动之后还会主动去跑测试。这听起来像是“变乖了”实际上是被迫遵守了一套工程纪律。如果你在 Java 这种重类型、重构建、重测试的项目里被 AI 助手“答非所问”折磨过或者你每次让它改代码都要在 prompt 里反复强调“先别写代码、先分析、你确定吗”那你大概率会需要这套东西。它解决的核心痛点就是三个AI 不问需求就开写、一次生成太多导致没法审查、改完不验证就告诉你“完成了”。2. 安装与激活把技能包装进 Codex2.1 前置准备安装 Superpowers 之前先把基础环境理清楚。它本身不是独立程序而是依附在 AI 编程助手上的配置层所以你必须先有一个能用的 Codex 环境。这里的“能用”指三件事命令行工具能正常调用后端模型服务简单发一条指令能拿到回复工作目录是一个真实的、能被 Codex 读取的代码仓库不能是空文件夹本机已经装好 JDK 和 Maven 或 Gradle因为后面验证 Java 场景时AI 需要真正执行编译和测试命令而不是只在脑子里“假装通过”。我见过不少人卡在第一步。Codex 装好之后先跑一条最简单的指令比如让它“列出当前目录结构”确认它能读文件、能执行命令再继续。如果这一步都不稳定后面所有规则加载、技能调用都是空中楼阁。2.2 安装步骤Superpowers 的安装方式很轻本质上就是“把一份规则清单放到 Codex 能读到的地方再在启动配置里告诉它去加载”。我自己的做法是这样的# 1. 创建一个专门放规则集的目录 mkdir -p ~/.codex/rules # 2. 把 superpowers 的主规则文件放进去 # 这里可能是你下载的技能包也可能是一段需要手动保存的 markdown # 核心文件一般叫 superpowers.md 或 skills.md放好之后还要在 Codex 的配置里声明这个规则文件。不同的版本配置方式略有差异但大致思路是在配置文件的“规则列表”或“指令集”区域加一行rules: - ~/.codex/rules/superpowers.md如果你想针对某个 Java 仓库单独启用而不是全局生效可以把规则文件放在仓库的.codex/rules/目录下。这样项目里的协作者拉下来代码后各自本地环境会自动加载同一套规则团队行为就会非常一致这个好处我在后面专门讲。2.3 激活与验证装完之后怎么知道有没有生效不要看启动日志直接做一个行为测试。我建议你新建一个只有两个文件的临时 Java 项目然后对着 Codex 说一句话这里有一个简单的 Java 类请先不要修改任何代码只告诉我它有哪些可以优化的点。如果规则生效了Codex 会先读文件、列出观察结果然后反问你要不要动手。如果没生效它大概率直接甩出一版“优化后”的代码。这个差别非常明显十秒钟就能判断。还有一个细节Superpowers 的规则文件不是越长越好。上下文窗口是有限的你把几十页规则全塞进去真正留给业务代码的空间就少了。我自己用的是精简版只保留了四条核心纪律先探索、再提问、小步改、必验证。那些花哨的“角色扮演”设定实际收益很低不建议加。3. 用对方法superpowers 在 Java 项目里的实战拆解3.1 场景一把一个混乱的业务类拆成职责清晰的模块这是我觉得 Superpowers 最有价值的场景。Java 项目里的老代码动辄一千多行的 Service 类太常见了。以前让 AI 帮忙重构它经常一上来就给你生成十个新文件然后告诉你“重构完成”。你 review 的时候根本看不完也不敢合。有了 Superpowers 的纪律约束整个流程变成这样第一轮只探索。我给它下指令请阅读 OrderService.java先把所有 public 方法列出来标注每个方法依赖的外部服务、事务边界、以及是否被其他类调用。不要修改任何代码。Codex 会老老实实导出一份方法清单。这个过程看起来很慢但非常关键因为拆分重构的本质是梳理依赖而不是“把长类剪短”。第二轮只出方案。我让它基于清单给出拆分建议每个新类的职责、涉及的方法、需要迁移的私有方法都写清楚。注意这里我也要求它不得写实现代码。第三轮确认后小步执行。我挑一个内聚性最强的方法组让它先拆出一个类并且要求“拆完之后运行一下项目里现有的测试”。这种节奏下Codex 的准确率明显上升。原因很简单它每次只需要处理一个明确定义的小任务出错范围被限制住了。3.2 场景二让 Codex 先写测试再写实现Java 开发者对 AI 生成代码最没安全感的地方就是它写出来的方法看起来逻辑完整但边界情况全是坑。Superpowers 的工作流会强制把“测试先行”变成操作顺序而不是一句口号。操作方式是这样的我要新增一个方法根据订单状态和支付渠道计算可退款金额。请先为我编写 JUnit 测试覆盖以下场景已退款状态返回 0、未支付状态抛异常、微信支付与支付宝的费率不同。测试先写好不需要实现。注意这里的关键词是“测试先写好不需要实现”。规则集早就给 Codex 设定好了“测试未编译通过就不得开始写实现”的约束所以它不会偷偷抢跑。等测试文件生成完毕我再补一句现在请实现这个类让测试通过。实现过程中如果发现需求有歧义先列出问题不要自己猜。实测下来这个方法能过滤掉大量“看起来对、跑起来错”的问题。以前我 review AI 代码要自己脑补测试用例现在反过来我先 review 测试逻辑再让 AI 去补齐实现质量高很多。3.3 场景三批量迁移与正则替换讲一个更常见的土活老系统里有一批方法签名要从getXxx()改成xxx()或者某个第三方库的旧 API 要整体替换成新写法。这种工作机械、量大、又容易漏但让 AI 直接全量改往往会把不该碰的地方也改了。我的办法是先用 Superpowers 让它生成一份“迁移影响清单”扫描整个 src/main/java 目录找出所有调用了 oldSdk.process() 的文件按模块分组列出。不要做任何修改。拿到清单后我再指定一个模块让它改。每个模块改完立刻执行编译和单测。一旦某个模块翻车影响范围只有那几行代码回滚也容易。这套“清单先行、分组执行”的流程本质上是把 AI 当作一个很勤奋但容易误伤队友的实习生来管理。你把边界画清楚它效率极高你不画边界它能把整个仓库给你格式化。4. 高频问题与排查思路我自己的踩坑记录4.1 问题速查表用 Superpowers 的过程不是一帆风顺的。我把这半年里遇到的高频问题整理成一张表每条都是实测过的现象可能原因排查方法规则完全不生效AI 依然一上来就写代码规则文件路径没配对或者配置项没被加载在会话里直接问“你现在需要遵守哪些规则”看它能不能复述核心条款AI 会复述规则但行为不变规则太多太泛上下文被稀释精简规则只保留最关键的 4 到 5 条硬约束在 Java 泛型场景下反复翻车泛型推断对 AI 来说是个弱项容易强行套用模式让它先列出泛型边界再写代码坚持“先测试后实现”改完代码说“测试通过”实际没跑规则里“必验证”约束不够强或者缺少可执行命令提示在规则里明确写出“必须运行 mvn test 并贴出结果禁止口头声称通过”上下文丢失做到一半忘了最初目标单轮任务分解得太碎或者信息被后续对话覆盖每个子任务开始时用一句话重申目标重要约束写在固定位置批量迁移时误改无关代码探索阶段没做透AI 靠猜测扩大改动范围强制走“影响清单 → 单模块修改 → 编译测试”三步流程4.2 操作节奏上的三条铁律除了上面这些具体问题我更想说的是操作节奏。很多人把 Superpowers 当作“装上就变强”的神器结果发现 AI 还是经常犯傻原因多半出在你自己没遵守协作纪律。第一条铁律任务颗粒度要小。不要让它一次做完“重构整个服务并补充所有测试”。正确做法是拆成“梳理依赖”、“拆分第一个类”、“迁移第一个方法组”、“跑测试”四个独立回合。AI 的上下文和注意力都有限你把任务拆得越细它越不容易出错。第二条铁律约束条件要写进当前对话而不是只写在全局规则里。全局规则是“宪法”当前对话是“具体命令”。即使是同一套规则每次开始新任务时也要花十几秒把关键约束重申一遍。比如“请记住你现在只做探索不要写代码。”这句话看着多余实际能显著降低翻车率。第三条铁律验证动作必须让 AI 自己执行而不是靠它描述。我踩过最深的坑就是让 Codex“检查有没有问题”它回复“检查过了没有问题”结果编译一跑全是错。后来我在规则里加了硬性要求所有涉及代码改动的任务最终一步必须是执行构建命令并输出结果。宁可让它多花两分钟跑一遍也不能相信它的自我评价。5. 我的真实体会用了一段时间之后我越来越觉得 Superpowers 这类东西的本质不是技术工具而是一套“对话纪律”。我们平时抱怨 AI 编程助手不靠谱大多数时候是协作方式出了问题需求没说清楚、边界没画好、验证没落实。Superpowers 做的就是把这些问题用规则的形式固化成流程逼着使用者和 AI 双方都按工程方式来工作。对老手来说它带来的效率提升不是写代码更快而是 review 更轻松、返工更少。如果你准备在自己的项目里试试我有个小建议不要一口气把网上能找到的规则全装上。先只保留“先探索、再提问、小步改、必验证”这四件事用两周时间把它变成你和 AI 之间的肌肉记忆再根据自己项目的特性去加自定义规则。等这套节奏顺了你再看那些没有纪律约束的 AI 输出会明显感觉到差别。最后再分享一个后续可以扩展的方向把你在项目里沉淀下来的规则文件放进代码仓库让团队成员共用。当整个团队对 AI 的输出质量标准达成一致时Codex 才真正从“个人玩具”变成“团队生产力”。这才是 Superpowers 这个名字最值钱的地方。
