最近一个月我基本上把主要精力都放在折腾一个叫 superpowers 的开源项目上。起因特别简单就是我日常用 Codex CLI 写代码时总有一个不爽的感觉它本身足够聪明但每次对话都像“重新开始”没有固有的工作习惯同一个项目里今天生成的代码风格和昨天对不上关键是它对 Java 这类重型工程的结构约束经常视而不见。后来同事丢给我一句“去试试 superpowers”我就顺着这个线索一路摸了下去结果越挖越深干脆把安装、使用、踩坑的过程全部记了下来。这篇就当是给自己留的一份完整记录也给还在观望的朋友一个参考。如果你还没听说过 superpowers那我先给你一个不绕弯子的回答它不是又一个代码生成器而是一套开源的技术方案专门用来给 AI 编程助手叠加“专业技能包”。你可以把它想象成给一个聪明但缺乏经验的新人程序员配了一套企业级开发规范手册他不需要重新学习语法但知道拿到需求后先干什么、后干什么、在 Java 项目里应该遵守什么模块边界、在多文件改动时应该怎么保持上下文一致。这套方案最适合的受众是两类人一类是重度依赖 AI 写代码、但总觉得输出质量不稳定的开发者另一类是刚接触 Codex 这类 AI 编程工具、希望一上来就建立良好使用习惯的新手。它解决的核心问题就一句话让 AI 的输出从“能用”变成“符合项目规范的好用”。下面我从头开始讲尽量把原理和经验一起说清楚。1. Superpowers 到底是什么给 AI 编程助手上的一层“技能叠加”1.1 它不是又一个代码生成器而是一套“行为规范”很多人第一次听到 superpowers 这个名字第一反应是“这又是个帮我生成代码的工具”。实际上把定位搞错了。它本身不直接生成业务代码也不提供模型能力它更像一个“行为规范注入层”。原理上superpowers 通过一套结构化的技能包文件把项目背景、编码规范、任务拆解流程、质量检查清单等内容组织成 AI 可以稳定读取的指令上下文然后在每次会话开始时注入到 Codex 这类工具里让 AI 在动手之前就“知道自己在哪个项目里、这个项目有什么规矩、做到什么程度才算完成”。我举个例子方便理解。默认状态下你让 Codex 在 Java 项目里“加一个用户列表接口”它往往会直接生成一个 Controller、一个 Service、一个 Mapper外加一堆注解看起来很完整。但放到真实项目里你会发现它可能没遵循你们团队的分层命名、没用统一的返回结果封装、连异常处理都写得五花八门。原因不是 Codex 不行而是它缺乏“项目专属约束”的输入。superpowers 解决的就是这个“输入缺位”问题它提前把团队规范、项目结构、代码风格整理成技能包AI 在生成过程中就会按这个标准来执行。1.2 为什么要叠加技能包AI 默认模式的三个短板我实际对比使用之后总结了默认模式下 AI 编程助手最明显的三个短板这些也是 superpowers 想解决的核心痛点第一个短板是上下文不连续。Codex 本身有上下文窗口但每次会话开启时它对之前项目历史的记忆是有限的。如果没人告诉它这个项目用了 Spring Boot 3.2、Java 17、统一用 Result 类包装返回它就会基于最通用的“最佳实践”来发挥而这些通用实践往往和你的项目并不完全匹配。技能包把这类零散的背景知识固定成档案让 AI 每次都能“回忆”起来。第二个短板是任务拆解能力不稳定。默认模式下AI 对“实现某个需求”的处理方式通常是直接给出答案而不是先拆解问题。遇到步骤多、涉及多个文件、有先后依赖关系的任务时它就容易走一步看一步甚至中途推翻自己之前的决定。superpowers 里包含的“任务拆解类技能”就是在对话开始时强制 AI 先输出执行计划把大任务切成小步骤再逐步确认和实现这对 Java 这类复杂工程尤其重要因为一个功能往往横跨 Controller、Service、Mapper、Entity 多个层级。第三个短板是代码风格漂移。这是我最头疼的问题。同一个项目周一生成的代码用 Lombok周三生成的代码就变成手写 getter/setter 了。superpowers 通过技能包里的风格约束和检查清单把这类规则固化成硬性要求AI 在每次输出前都会自查一遍风格漂移的情况会明显减少。2. 安装前的准备与核心概念2.1 前置环境与依赖我建议在动手安装之前先把两样东西准备好一个是 Node.js 运行环境另一个是 Codex CLI或者其他兼容的 AI 编程命令行工具。因为 superpowers 的安装器是用 Node.js 写的本身负责把技能包文件下载、解压、写入到指定目录并对配置文件做动态更新。没有 Node.js 环境的话安装器跑不起来。具体版本方面Node.js 建议 18 以上太老的版本在解析配置文件时容易出兼容问题。Codex CLI 方面我建议保持较新版本因为 superpowers 的某些注入机制依赖 CLI 对系统提示词的处理方式版本太旧可能会导致注入不生效这个我在后面问题排查部分会详细说。另外如果你和我一样是在公司内网环境使用还要提前确认终端能正常访问 GitHub 仓库或者准备好内网镜像地址否则安装器下载技能包会卡住。2.2 核心概念技能包、触发器、配置优先级安装之前不把核心概念搞清楚后面用起来容易一头雾水。superpowers 最核心的三个概念分别是技能包、触发器和配置优先级。技能包skill pack就是一组文件的集合里面包含了针对某类场景或某个技术栈的完整指令。比如 Java 技能包里面会包含 Java 项目结构规范、Maven/Gradle 构建注意事项、Spring 编程约定、代码检查清单等内容。它可以看成是一本专门的“工作手册”AI 读取之后就知道在这个技术栈里应该怎么输出。触发器trigger是决定技能包在什么条件下被加载的机制。有的技能包是全局的任何会话都会自动生效有的技能包是按项目类型触发的比如检测到项目里有 pom.xml 或 build.gradle 就自动激活 Java 技能包还有的是按关键词触发的比如在对话中提到“写单元测试”就额外加载测试相关技能包。理解触发器很重要因为很多“技能包没生效”的假象其实是触发条件没满足。配置优先级解决的是冲突问题。同一个项目里可能同时有多个技能包生效它们对同一件事可能有不同的说法。superpowers 的配置模型里有一个明确的优先级顺序项目级配置优先于用户级配置用户级配置优先于内置默认配置。这意味着你可以在具体项目里覆盖全局默认的规则实现“一项目一策略”。3. 从零到一安装与启用步骤3.1 一键安装与目录布局安装过程本身不复杂核心命令就一条npx superpowerslatest install这条命令会做三件事拉取最新版本的 superpowers 安装器把核心技能包文件写入你的用户目录如果检测到已经安装过 Codex CLI还会自动更新它的配置文件把 superpowers 的加载入口挂上去。整个安装过程大概一两分钟网络正常情况下不会有什么幺蛾子。装完之后我建议你检查一下目录结构确认安装是否完整。在 macOS/Linux 上技能包文件一般会放在 ~/.superpowers 目录下里面会看到 skills 子目录、config 子目录和 logs 子目录。skills 目录里存放的就是各种技能包文件每个技能包通常是一个子目录里面至少包含一个描述文件和一个或多个规则文件。首次安装只带内置的基础技能包Java、Python 这类扩展技能包需要另外启用这个我们在后面讲。3.2 在 Codex 中启用 superpowers安装器会自动修改 Codex 的配置文件但保险起见我还是建议你手动确认一下。以 Codex CLI 为例配置文件通常在 ~/.codex/config.toml检查里面有没有加载 superpowers 入口配置。如果没有手动加一行配置即可。codex config inspect查看配置输出结果确认类似下面的内容存在[model_providers.superpowers] ...这里我不想写死具体的配置键名因为 superpowers 和各版本的 Codex CLI 绑定方式一直在演进你安装时以安装器实际写入的配置为准。关键验证方法只有一个在任意项目目录下启动 Codex 会话输入superpowers status这类检查命令具体命令名要以你安装的版本帮助信息为准看能不能正常列出当前会话已生效的技能包列表。能列出就说明加载链路已经打通了。3.3 用 Java 项目做一次真实验证光能列出还不够我习惯用一个小项目做端到端验证。我当时的验证场景是这样的在本地拉了一个老项目强制让 Codex 在 superpowers 未启用和启用两种状态下各生成一个用户查询接口然后对比输出差异。先用未启用状态跑生成的代码是一个最普通的 Spring MVC 三层结构Controller、Service、Mapper 各一个文件能跑通但返回结果直接就是实体对象没有统一包装异常也没处理。然后在启用 superpowers 并加载 Java 技能包的状态下跑同一个需求输出就完全不一样了代码开头会先补一个简短的项目上下文说明生成的文件严格落在 com.example.user 相关的包路径下Controller 返回统一使用 Result 包装Service 层单独做了接口与实现分离异常处理也统一归口到了全局异常处理器。这个对比非常直观让我当场就把默认模式输出的那套代码删了换成带技能包的结果。4. 深入使用Java 场景下的技能包实战4.1 Java 技能包到底改了什么Jobs 从目录结构上扒开 Java 技能包的内容你会发现它里面并没有魔法无非是几类规则文件的组合。第一类是项目背景说明描述 Java 生态里最常见的工程结构Maven/Gradle、Controller-Service-Mapper 分层、包名习惯等第二类是代码生成约束比如“所有 Web 层入口必须使用统一响应包装”“禁止在 Controller 里写业务逻辑”“DTO 和 Entity 必须分开”等等第三类是任务执行清单要求 AI 在接到复杂任务时先规划再动手并且明确说明涉及哪些文件、改动范围是什么。这些规则本身每个 Java 团队可能都有自己的版本superpowers 的价值不在于发明规则而在于把规则做成了 AI 能稳定读取、稳定执行的格式并且提供了一套让规则按需加载的机制。你完全可以修改技能包里的规则文件把你自己团队的那套规范灌进去这就是它最灵活的地方。4.2 实测对比开启前后同一个需求的表现我再给你看一个更具体的对比场景是“给用户模块增加导出全部用户 CSV 的功能”。这个需求在默认模式下Codex 生成的是一个写死在 Controller 里的导出逻辑直接把 List 遍历拼成 CSV 字符串用 HttpServletResponse 输出。功能没有问题但放到真实项目里就是灾难数据量大一点就可能 OOM导出逻辑没有复用性几乎没有测试。同样的需求在加载了 superpowers 的 Java 技能包之后AI 的处理路径完全不同。它先生成一个导出服务方法接受查询条件和输出流两个参数内部使用流式查询的方式按批读取数据避免全量加载然后 CSV 的拼装逻辑独立成工具类再在 Controller 层只留一个薄薄的入口。另外它还主动补了一句这类导出功能建议加异步任务和下载链接过期机制问我要不要继续完善。从“能跑的代码”到“按工程标准产出的代码”差距就在这里。4.3 自定义技能包的三个要点superpowers 默认带的技能包是通用的不一定完全符合你的团队规范所以关键技能是自定义。我实践下来有三个要点。第一技能包描述文件要写得足够具体。不要只写“遵循团队 Java 规范”要把规范的核心条目直接列出来比如“所有对外接口使用 Result 包装”“日志必须使用 SLF4J 占位符”“禁止 System.out.println”。AI 是字面理解规则的条目越具体执行越到位。第二合理设置触发条件。团队的公共技能包建议做成全局触发而针对某个特定项目的技能包建议绑定 project 类型触发条件只在包含特定标记文件比如 pom.xml 中特定的 groupId的目录下生效。第三用案例驱动技能包迭代。我发现光写规则还不够最好在技能包里附上一两个“好例子”和“坏例子”。AI 类比学习的能力比抽象理解能力强很多给一个符合规范的真实代码片段比写十条抽象规则更管用。5. 常见问题与排查技巧实录5.1 技能包生效了但效果不明显这是我最开始遇到的问题现象是superpowers status显示技能包已经加载但生成的代码感觉跟没开差不多。排查下来原因是会话里加载了多个技能包其中内置默认技能包里的泛化规则把自定义技能包里的强约束给稀释了。解决方法是确认配置优先级在项目级配置里显式关闭或者精简不必要的默认技能包给自定义规则让出执行空间。还有一个常见原因就是模型本身对长上下文的遵循能力有限。技能包注入的内容会占据上下文的一部分如果模型为了响应核心需求而忽略了规则细节就会出现“好像加载了但没完全执行”的情况。这种情况下需要把关键规则进一步精炼控制技能包文件长度让 AI 更容易命中重点。5.2 Java 项目里老是生成与模块结构不符的代码这个问题的典型表现是你明确指定了包名是 com.company.module但 AI 生成的文件头还是出现了 com.example.demo 之类的默认包名。根因通常是技能包里的包名配置没有实际注入到项目上下文里因为 Codex 的会话上下文可能包含了项目里已有的代码内容这些内容的“示范效应”比技能包规则更强。我的解决办法是两步走。第一步修改技能包里的代码模板把包名占位符改成项目实际值第二步在每轮必要的时候直接在输入里带上包路径比如“在 com.company.module.user 包下创建 UserController”。用技能包兜底用显式指令纠偏双管齐下之后这个问题基本就绝迹了。5.3 混合语言项目如何切换技能包现在很多项目是混合语言架构比如 Java 后端加 TypeScript 前端。superpowers 默认是按项目目录识别技术的如果整个仓库混在一起AI 可能同时加载多个技能包规则之间就容易打架。我的做法是给不同语言设置独立的触发目录Java 技能包绑定到 backend/ 目录前端技能包绑定到 frontend/ 目录让技能包的生效范围收敛到子目录级别。下表是我整理的几个高频问题的速查表问题现象可能原因解决方案技能包显示加载但输出无明显变化多个技能包规则互相稀释精简默认技能包调整配置优先级生成的包名总是 com.example技能包包名配置未命中修改技能包模板显式指定包名同一个需求两次输出风格不一致未启用风格检查清单启用技能包内置的代码风格自查Java 项目中混入了 Python 风格代码技能包触发目录过大按目录拆分技能包触发条件Java 技能包不生效项目未识别为 Java 工程检查 build.gradle/pom.xml 是否在项目根目录修改技能包后无变化未重启 Codex 会话保存技能包文件后重启会话5.4 一个容易忽视的小细节技能包文件修改后的生效机制最后提醒一个非常容易踩坑的细节。很多朋友刚接触 superpowers 时会直接编辑技能包文件改完发现没效果还以为是系统坏了。真实原因是技能包文件的加载时机多数实现是在会话启动时一次性读入的对正在运行中的会话不会热更新。所以每次修改完技能包文件一定要重启 Codex 会话再验证否则你看到的还是旧规则。另外编辑技能包文件时建议保持严格的格式规范一个逗号、一个缩进错了都可能让整个技能包解析失败。我通常改完先跑一遍安装器自带的完整性检查命令再启动新会话。这个小习惯帮我省掉了大量排错时间。如果你现在正纠结“要不要上 superpowers”我的建议是直接试但别指望第一天就完美。先用默认技能包跑一两天把最常见的问题记录下来再逐步调整成你自己团队的规则。这个过程本身其实比工具本身更值钱因为你等于把团队里零散的“代码习惯”第一次系统化了。我个人实际用下来的体会是superpowers 对单人开发者的价值可能比大团队更大。大团队本来就有完善的代码评审和规范文档AI 输出的偏差会被流程兜住但独立开发者没有这层保险AI 生成什么基本就直接进代码库了这时候有一套稳定的技能包约束等于给自己配了一个不知疲倦的代码评审员。现在我已经把自己常用项目的规范都沉淀成技能包了以后新项目启动第一件事不是装依赖而是先把技能包铺好这已经成了我的固定动作。