最近在开发者社区刷到一个高频词superpowers。一开始我以为又是某部超级英雄电影的热搜点进去才发现它其实是用来增强AI编程助手能力的一套技能工作流尤其是和Codex这类工具配合起来效果比默认的问答式写代码明显上了一个台阶。这篇文章从一个普通后端开发者的视角聊聊superpowers到底是什么、怎么装、怎么在Java工程里用起来以及我实际踩过的几个坑。它不是银弹也不会让AI一夜之间变成高级工程师但如果你愿意花半小时把规则、技能和验收循环搭起来它确实能把“AI帮你写函数”提升到“AI帮你交付需求”的层面。1. superpowers到底改了什么从单轮聊天到可执行的工程工作流先说结论superpowers不是一个具体的编程语言框架也不是某个IDE插件它更像是一套“给AI编程代理用的技能包和工作流规范”。你可以把它理解成给AI配了一份新员工入职手册——里面写清楚了遇到需求时要先干什么、再干什么、什么时候该问人、什么时候该自己验证。1.1 AI写代码的真正短板不是“不会写”而是“不会干活”过去我们用ChatGPT或Copilot最常用的方式是复制一段报错丢进去或者把某个方法的需求描述一遍让AI给你生成一段代码。这种方式对单点问题很有效但一旦面对一个完整需求——比如“给订单模块加一个按状态统计的接口顺便补单元测试”AI容易犯三个毛病上下文不够完整它不知道项目里Controller长什么样、异常怎么处理、数据库字段是什么风格。缺少拆解任务的能力容易一次生成一大堆代码结果一半用不上。没有自测和验收意识代码写完了不跑测试也不检查是否真的满足需求。superpowers这类技能组的核心思路就是把“干活”这件事拆成AI能理解的显式步骤先侦察再规划然后实施最后验证。它通过一系列预置的技能文件skill、规则文件AGENTS.md和目录结构告诉AI在什么场景下该调用什么策略。1.2 它的“超能力”其实是结构化的工程纪律我刚开始也觉得这名字太夸张了。但用下来发现真正让它起作用的不是某个魔法函数而是它强迫AI和人类开发者都遵守一套纪律。举个最简单的例子默认情况下你让AI“写一个订单统计接口”它可能直接生成一个Controller类扔给你。但如果你在项目里挂上superpowers的规则它收到这个需求后会先输出一份“理解和计划”列出需要读取哪些现有文件接口路径和返回结构应该对齐哪个已有接口需要新增的类和改动点有哪些用什么方式验证比如mvn test或者curl调接口。这个过程在工程上叫“任务前置分析”。你会发现它生成的代码质量并没有突飞猛进但最终交给你的东西更符合项目现有风格而且不需要你来来回回返工。1.3 适合谁用不适合谁用如果你平时只是让AI帮你写一个算法片段、解释一段报错那superpowers有点重没必要。它更适合这几类人已经在用Codex、Claude这类能跑多轮任务的AI编程代理但觉得输出质量和稳定性忽高忽低的人负责需求交付的开发者需要AI从“写代码工具”变成“能理解需求并完成闭环”的助手团队里想统一AI协作规范、减少碎碎念式提示词的人。反过来说如果你希望AI完全自主跑几个小时然后把一个完整功能写好现在的superpowers还不够别指望它做到。它能做到的是每一步都让你看得见、可干预。2. 安装和初始化比想象中简单但依赖检查别跳过安装部分网上教程不少但很多讲得都比较简略。我这边把自己实际操作时的情况说一下重点是依赖环境因为这里最容易翻车。2.1 需要提前装好的依赖以我用的环境为例主要依赖是三样依赖项版本要求用途Node.js18或更高运行CLI工具和技能加载脚本Git2.30以上克隆技能库、管理版本更新Codex CLI0.x最新版作为AI代理的执行终端Java/JDK17看你的工程实际版本编译跑测试验证Java代码这里提醒一句Node版本不要太老。我第一次用16.14结果安装依赖时直接报错提示node:internal/modules/cjs/loader找不到模块换到20之后一路畅通。如果你在安装时遇到类似的模块加载问题优先检查Node版本不要一上来就怀疑是项目本身有bug。2.2 安装基本步骤我现在用的方式是直接从GitHub把项目Clone到本地然后做一次全局挂载大致命令如下git clone https://github.com/你的superpowers技能库地址.git cd superpowers npm install npm run setupsetup脚本会自动检查环境变量、生成默认配置文件同时把任务技能skills目录和规则文件链接到你的AI代理配置目录。这一步如果提示权限问题通常是你的用户目录下~/.codex还没有创建手动mkdir -p ~/.codex以后再跑一次就行。装完之后随便进入一个已有项目目录运行类似这样的命令验证superpowers status正常情况下它会显示当前的技能数量、规则文件是否加载、以及有没有检测到Codex CLI。看到类似“Skills ready”的输出说明初始化基本成功。2.3 初始化时最值得改的配置文件安装完以后默认配置能直接用但我不建议你直接用默认配置应付真实项目。重点是每个项目根目录下的AGENTS.md它的作用和以前的.env有点像是这个项目给AI代理看的“说明书”。我会在里面写明这样几条项目是Spring Boot 3.xJava 17构建工具是MavenController层的返回统一走ApiResponseT包装类新增依赖必须经开发者确认不能自己往pom.xml里塞东西生成代码后必须跑mvn -q test并把结果反馈回来。有了这些规则AI在项目里干活的方式会立刻收敛很多不再是一副“通用编程助手”的腔调而是像一个熟悉这个项目的老成员。3. 在Java工程里跑通一个真实需求订单统计接口的完整拆解这一部分是整个使用体验里最能体现superpowers价值的地方。我用一个实际做过的需求来走一遍流程给订单模块增加一个按状态统计订单数量的接口并补单元测试。3.1 任务拆解不要一句话丢给AI很多人的习惯是把需求一句话丢给AI“在订单模块加一个状态统计接口”。我一开始也这样干AI确实能给出代码但总是差点意思——要么没测试要么接口路径跟项目现有风格对不上。后来按superpowers的技能流程我把需求拆成了五条先读pom.xml和OrderController.java搞清楚现有接口风格阅读OrderService和OrderRepository确认查询能力和命名习惯设计一个返回结构包含状态码和订单数量字段实现Service、Repository和Controller三个层的改动编写一个MockMvc单元测试验证接口返回。拆解的过程其实就是把人类开发者的工作习惯翻译给AI。AI拿到一条清晰的任务链之后执行效率和输出质量都明显提升。3.2 让AI先“侦察”再写代码在superpowers的技能列表里有一个技能专门用来做代码库侦察。我直接让AI执行类似这样的指令explore the order module and summarize: - existing controller endpoints and URL patterns - service layer method naming conventions - repository query style (JPQL or derived queries)它会自动列出OrderController.java中已有的接口格式、Controller层的注解风格、Service层的调用方式等。这份侦察报告很有用它确保后面生成的代码在结构上和项目现有风格一致而不是搞出一个“看起来正确但实际上格格不入”的东西。比如我项目里Controller统一返回ApiResponse.ok()但如果我不让AI侦察它大概率会直接返回ResponseEntityMap或者裸对象。只要有这一步前置侦察这种风格不一致问题基本不会出现。3.3 实施环节AI生成的代码长这样侦察之后AI生成的代码大致如下GetMapping(/status/count) public ApiResponseListOrderStatusCountVO countByStatus() { ListOrderStatusCountVO list orderService.countByStatus(); return ApiResponse.ok(list); }配套的Service实现public ListOrderStatusCountVO countByStatus() { return orderRepository.findAll() .stream() .collect(Collectors.groupingBy(Order::getStatus, Collectors.counting())) .entrySet() .stream() .map(e - new OrderStatusCountVO(e.getKey(), e.getValue())) .toList(); }说实话这份代码只能算中等偏上但它有个很重要的特点接口路径和返回结构和项目现有风格完美对齐。原因是AI在动手前已经看过同模块的其他接口它们都长这个样子。对团队来说风格一致往往比代码本身炫酷更重要。3.4 验证闭环把测试结果当成继续对话的凭证代码生成后我没有直接说“完成”而是让AI自己跑测试然后要求它把测试结果贴出来。superpowers的规则文件里有一条我很喜欢任何实现必须附带验证输出。于是AI执行了mvn -q test -DtestOrderStatusCountControllerTest然后在回答里贴出了测试通过的结果。这一步的意义非常大。它逼着AI从“生成代码”切换到“交付功能”的状态。测试一旦失败它会继续回去改直到绿灯为止。这比人工一条条review覆盖率高得多。4. 和Codex深度配合AGENTS.md、技能循环与上下文管理标题里的codex superpowers是我这段时间研究最多的一块因为superpowers的价值要真正发挥出来离不开Codex这种能执行多步操作、调用本地命令的Agent环境。4.1 Codex里怎么把superpowers挂上去在Codex CLI的交互模式下可以直接指定让AI加载某个技能目录。我通常是用配置方式在~/.codex/config.toml里加一段类似这样的配置把superpowers的skills目录引入[project] skills_path /path/to/superpowers/skills加完之后在Codex会话里执行superpowers相关的指令AI就能识别并调用技能库中的具体技能。你也可以在每次对话开始时带上superpowers让AI先去读取技能索引再开始干活。4.2 优先级最高的规则文件怎么写很多项目里的AGENTS.md写了等于没写因为都是空话比如“请写出高质量代码”这种。我现在的写法很具体# AGENTS.md – order-service ## 项目背景 - Spring Boot 3.2Java 17Maven。 ## 硬性规则 - 不要修改pom.xml除非用户明确要求。 - 所有新增接口必须使用ApiResponse包装类。 - 数据库查询优先使用Spring Data派生查询复杂SQL可写在Query里。 - 完成后必须运行 mvn -q test 并输出结果摘要。 ## 用户偏好 - Controller层保持精简逻辑写在Service层。 - 变量命名用camelCase常量用UPPER_SNAKE_CASE。 ## 禁止事项 - 不要学着写一个全新的异常体系。 - 不要在无测试的情况下说“已完成”。这些规则写得越具体AI就越不需要靠猜。它的行为稳定性会有极大提升。4.3 “研究 → 规划 → 实施 → 验证”四步循环superpowers给AI定义了一个基本的任务循环我实际执行时是这样调的研究阶段AI读取相关文件、调研现有实现产出摘要规划阶段列出改动清单、测试方案、风险点等你确认实施阶段逐项实现每完成一项就在上下文里做标记验证阶段跑测试、跑编译、给出验证结果。这四步看起来很基础但它解决的是AI对话里最烦人的“做着做着就忘了上下文”的问题。每次进入下一步前AI都会把上一步的结论再总结一遍避免在长对话中迷失。4.4 长任务下如何管理上下文和记忆Codex执行复杂任务时Chat窗口的上下文会越拉越长越到后面AI越容易“犯迷糊”开始重复做已经完成的工作或者忘记之前定下的接口规范。这里有个小技巧维护一个进程文件。我在项目里常用.prod.md或者docs/progress.md这样的文件让AI每完成一个步骤就更新一次## 任务进度 - [x] 侦察order模块接口风格确认 - [x] Service层实现countByStatus - [x] Controller层新增API端点 - [x] 编写MockMvc测试 - [ ] 全量回归测试这样即使对话上下文被压缩AI也能通过读取进度文件快速恢复“记忆”不会把前面做的决定全部丢掉。这算是纯提示词工程之外比之前更稳定的状态管理方案。5. 用了三周后想说的四类坑和它的能力边界这部分是我最想写的因为网上分享大多数都在讲怎么装、怎么用很少有人讲真实使用中的不顺。这里把踩过的坑一次性说全。5.1 坑一任务拆得不够小AI开始“假装完成”有一次我让AI做一个需求拆的任务稍微大了一点“改造订单查询接口支持多条件筛选包含分页写测试”。AI在一轮里生成了四个文件的改动看起来很高效结果一跑测试Controller层编译错误Service层逻辑还有一处陈旧规则。后来我把任务拆成三步先加查询参数、再做分页、最后写测试。每步都让AI停下来给我看diff。执行质量和返工率立刻改善。所以记住一个原则AI不是不能干活而是不能一口气干太多活。5.2 坑二AI会“脑补”不存在的依赖在Java项目里最典型的场景是AI想用一个工具类比如StringUtils但没有确认项目是否引入Apache Commons Lang就直接import。编译一跑才发现不存在。以前我都是自己手动加依赖现在我在AGENTS.md里写了一条硬性规定禁止修改pom.xml如果发现需要新依赖先停下来问用户。有了这条规则AI遇到这种情况会主动问“当前项目未包含commons-lang3是否引入”这时候决策权就到了人手里避免AI自作主张。5.3 坑三上下文过期导致AI“复明式失明”这是我这段时间遇到过最诡异的问题。AI第一次读代码时记住了一个Service类在com.example.service包下但跑了一段时间、改了文件名后它的旧记忆还留着于是后续代码还在按旧的路径导入类。明明类已经不存在了它仍然执拗地引用。解决方式很简单让AI在关键改动后重新读一遍目录结构或者利用进度文件记录最新状态。不要相信AI的长期记忆它的记忆窗口有限而且刷新不及时。5.4 坑四不要迷信“全自动交付”最后这点可能有些泼冷水但我还是想说superpowers和Codex的组合目前更适合做一个“高效率的结对编程伙伴”而不是“无人值守的代驾司机”。它能帮你省掉大量机械劳动比如写模板代码、补单元测试、查API用法甚至能做初步重构。但涉及业务边界的判断、技术方案选型、跨模块影响分析还是得人来拍板。比如订单状态枚举的含义、某个字段为空的业务解释AI不可能替代你去问产品经理。5.5 一个小技巧设定“先问不做”的触发词我后来在AGENTS.md里加了一条当需求描述里包含“不确定”“看情况”“两种方案”这类词时AI要先输出选项并停下来等我选择后再动手。这一招在需求模糊的时候特别好用能避免AI按自己的想象瞎实现。比如它想用数据库冗余统计而产品实际想要的是实时聚合查询线上环境数据量完全不同它自己决定就是一场事故。别看这只是一句话规则它对AI工作的方向性和需求对齐很有帮助。配置好以后每天我只需要用几分钟做 review然后像踩刹车一样控制节奏它干活的方向基本不会偏。这就是superpowers真正“超能力”的地方不是让AI替我做决定而是让它更准确地执行我的决定。