1. 没装Superpowers之前AI编码助手到底差在哪我最早接触Codex CLI的时候第一反应是“这玩意儿确实能写代码但也就停留在能写代码”。你说重构一个类、补个单元测试它做得不错可一旦让它跨文件改接口、改完顺手跑一下构建、踩到编译错误还能自己修它就露怯了。跟它对话就像跟一个记性不太好的实习生沟通——你交代一步它做一步少交代一步它就能卡在原地。Superpowers这个项目火的理由很简单它把“AI编码助手”从“对话式补全工具”推到了“能自我驱动完成工程任务”的位置。它本质上不是一个编程框架而是一套技能Skills与自动命令Auto Commands体系。你装好它之后Codex这类AI编码工具会额外获得一组预先编写好的指令包从“如何分析项目结构”“如何确定改动影响面”到“如何运行测试并修复失败”每一步都有明确的提示词模板和工作流定义。AI不再是等着你喂需求而是像一名真正的工程师那样自己规划、执行、验证然后回头向你汇报。“WorBuddy怎么用superpowers”这类问题之所以高频出现也是因为这个生态正在快速收敛各家AI编码前端都在做同一件事——把大模型的能力接进本地开发环境而Superpowers则提供了“怎么让模型干活干得专业”的那层中间件。这层中间件不是给AI看的是给你和AI之间的协作方式看的。这篇文章不会跟你讲太多理论重点就三件事怎么装、怎么配、怎么在Java项目里把它用出效果。*.md 和 JSON 配置为主纯经验向照着抄就行。2. 安装到激活Superpowers的最小可用路径2.1 前置依赖与版本要求先泼一盆冷水Superpowers本身不干活它只负责给“会干活的AI”下指令。所以你必须先有一个可用的AI编码工具链最常见的就是Codex CLI或者支持Skills协议的AI编程助手。我本地环境是 macOS Node.js 20 LTS Codex CLI 0.4x 版本跑Superpowers基本没有遇到兼容性问题。如果你用的是其他系统比如 Windows要注意的是Node.js 必须 18否则部分脚本直接报错Git 必须存在且能在命令行被找到如果是 WSL 环境建议装在 Linux 目录下而不是挂载在 /mnt/c 的 Windows 目录否则文件监听和权限迁移会有不少坑再确认你的AI前端支持“Skills”或者至少支持“自定义指令目录”。怎么确认看它的配置文件里有没有类似instructions、skills、commands这类字段。Codex CLI 的配置文件在~/.codex/config.toml里面支持[extra_body]和指令文件路径。如果你连这个文件都还没见过先去跑一遍codex的初始化流程生成好基础配置再回来装Superpowers。2.2 三种安装方式和选择逻辑Superpowers的安装方式不像普通npm包那样只有一种它主要有三条路方式一模板拉取推荐新手直接克隆官方技能仓库到本地固定目录git clone https://github.com/your-handle/superpowers.git ~/.superpowers然后把目录注册进AI前端的配置。这种方式的优势是可随时git pull更新技能包缺点是需要自己记得维护。方式二包管理器安装如果你用的是 Codex CLI并且已经配置了插件目录可以用 npm 或 bun 安装npm install -g superpowers/cli装完之后跑一次superpowers init --target ~/.codex它会自动把你的技能文件链接到 Codex 的配置目录中。这种方式适合已经有 Node 生态习惯的人升级也方便一条命令覆盖。方式三手动放置如果你想完全掌控不信任任何自动脚本那就手动把skills/目录下的子文件夹复制到 AI 前端的配置目录里然后在主配置文件中逐条引用。这种方式最透明但后续更新自己操心。我个人的建议是新手选方式一图省心已经在 Codex 上跑了几个项目的人选方式二有洁癖、喜欢看每一条配置生效的人选方式三。三种方式装完之后的效果没本质区别核心都是那几百个 Skill 文件。2.3 验证Superpowers是否真正生效安装完不等于激活。很多人卡在这一步以为目录放进去了就完事。实际上你要做一次“冒烟测试”。打开 Codex CLI问它一句话请列出你当前可用的技能组以及每个技能组的触发关键词。如果它回答“我有分析技能组、测试技能组、重构技能组……”说明激活成功如果它说“你是想让我做什么”那说明指令文件没有被加载。加载不上的原因绝大多数是路径写错了。Codex 的配置里如果用了~注意它不一定展开成/Users/你的用户名建议直接写绝对路径。还有Windows 用户在路径里用了反斜杠\也会导致解析失败统一换成/。3. Codex集成把“超能力”注入Codex CLI的完整步骤3.1 项目级配置与全局配置怎么选Superpowers 支持两个粒度的配置全局和项目级。全局配置改~/.codex/config.toml加上[project]或指令路径字段。所有项目都能用到 Superpowers 的技能。项目级配置在项目根目录放一个.codex/config.toml只对这个仓库生效。你可能会下意识选择全局我劝你冷静一点。Superpowers 里的技能包包含一些“激进”的自动命令比如自动运行测试、自动修复编译错误。你把它装到全局之后可能打开一个只读别人源码的仓库它也会自作主张地开始跑命令。我后来改成项目级配置只在真正需要 AI 深度参与的仓库里启用。项目级配置的做法是在仓库下建文件mkdir -p .codex touch .codex/config.toml写入[instructions] files [ /Users/你的用户名/.superpowers/instructions/default.md, /Users/你的用户名/.superpowers/skills/refactor/REFACTOR.md ]注意这里的路径要指向你实际克隆下来的 superpowers 仓库位置。如果你用的不是绝对路径Codex 有较大概率会因为相对路径基准目录不同而找不到文件。3.2 让 Codex 识别自动命令仅把 skill 的 md 文件挂进 instructions 还不够Superpowers 的另一大杀器是自动命令auto commands。它是指在模型推理时如果满足特定条件预先向模型插入一段指令。举例来说当你输入“帮我把 UserService 重构成接口实现类”Superpowers 会自动注入先读取UserService.java全文搜索项目中所有引用UserService的文件给出接口抽取方案执行修改并运行编译检查如有失败读取错误信息并继续修复这已经不是普通的提示词模板了而是一个微型工作流引擎。它依赖 Codex CLI 的[hooks]或[permissions]功能具体来说是在配置里声明“哪些事件触发哪些脚本”。常见配置片段[hooks] pre_prompt [ if ls .superpowers/hooks/pre_prompt.sh 2/dev/null; then .superpowers/hooks/pre_prompt.sh; fi ]这个脚本会检查当前目录是否为 Java 项目比如存在pom.xml或build.gradle如果是就在每次提问前自动追加一段“本项目是 Maven 项目请始终使用 Maven 命令构建”到上下文中。别小看这一段它能很有效地防止模型脑补出gradle build去跑一个根本没有 Gradle 的项目。3.3 用一句话判断集成是否成功我常用的一句话是帮我在本地跑一遍当前项目的测试并按测试结果修改失败代码改完再跑一次。如果集成成功Codex 会分三步走先执行mvn test或./gradlew test然后分析失败原因再改代码重跑。如果它只是直接对着代码空分析甚至说“我无法在沙箱中运行命令”那你的 hooks 配置就没生效。4. Java场景下Superpowers的实战配置4.1 为什么Java项目最容易从Superpowers获益Java 项目有个特点结构规整但重复劳动极多。一个业务系统动辄几十个 Service、几十个 DTO做一次字段变更要改实体类、改 Mapper、改 VO、改单元测试、再改接口文档。这些操作对 AI 来说既繁琐又容易漏但恰好在 Superpowers 的技能库里是最成熟的场景。官方技能包里有一套java-spring技能清单大致包含技能名触发场景核心行为analyze-module-dependencies不确定改动影响面读取模块依赖图列出受影响类service-refactor抽取接口/拆分Service基于调用链生成重构脚本dto-field-change修改DTO字段联动所有引用处与序列化配置test-failure-triage单元测试失败按包名归类失败原因并修复maven-lifecycle-aware构建相关任务按 Maven 生命周期执行对应阶段这些技能不是靠给模型灌一本厚厚的《Spring 实战》而是把每次任务拆成可验证的小步骤模型每执行完一步就会输出一行摘要。这保证了它不会在某个分支里越走越偏。4.2 实战一个老项目的 Maven 构建自动化我拿最近帮朋友排查的一个旧项目举例。该项目是 Java 11 Spring Boot 2.6 Maven 多模块大概有 20 个 module。问题很常见某次改动改了一个公共类的字段类型然后一整个编译链崩了报错信息像雪花片一样飞来。没有 Superpowers 的情况下你得把第一个编译错误喂给 Codex 让它修修完再跑一次构建再拿第二个错误继续喂。来来回回十几次人先崩溃。配置好 Superpowers 后我只需要说使用maven-lifecycle-aware技能完整执行mvn test持续修复直到构建通过期间不允许改变项目原有依赖版本。它会自动读pom.xml了解模块结构接着执行mvn test-compile而不是一上来就mvn test因为前者速度更快且足够暴露编译错误。修完第一个模块的编译错误后它不会停在原地而是继续往下游模块推进。整个过程模型会频繁调用read_file、grep_search和find来定位引用点而不是凭空猜测。这次实战里最惊艳的一刻是模型发现一个模块的pom.xml里把commons-lang3的版本写成了3.7而实际代码里用到了3.9才有的 API。它没有自作主张改版本号因为这属于项目依赖策略可能牵一发动全身而是用StringUtils.substringBetween替代了那个新 API——既修复了编译错误又完全没动依赖。这就是技能包的价值它不会给你一个最“粗暴”的解法而是找“改动面最小”的解法。4.3 处理 Java 特有的“隐性配置陷阱”Java 项目里真正耗时的不是写代码而是配置和依赖。技能包里针对这些问题也有应对策略但需要你在使用时注意触发条件。Lombok 问题模型如果不知道项目用了 Lombok可能会对“找不到 getter/setter”大惑不解然后误判为代码缺失。Superpowers 的自动指令里如果发现有lombok依赖就会先注入“本项目启用 Lombokgetter/setter 由编译期自动生成不需要手写”的提示。内部私有仓库如果你们的 Maven 仓库是内网的模型默认执行mvn clean install会失败。建议在项目根目录放一个.superpowers/project-context.md写明“私有仓库地址已配置在 settings.xml请勿修改运行时如果下载依赖超时等待即可”。Java 版本差异Java 8 和 Java 17 的语法差异巨大。技能包读取pom.xml后会自动识别maven.compiler.release如果发现是 Java 8就会禁用所有含var关键字的重构方案。这个细节很实用确实让 AI 生成的代码不会再莫名变成 Java 11 风格。5. WorBuddy等其他AI前端导入Superpowers的通用路径标题里提到“worbuddy 怎么用 superpowers”我也被问过不止一次。其实现在很多 AI 编码前端都长得像一个壳子底层要么接 OpenAI 的模型 API要么接 Claude API真正拉开差距的就是 Who 得到什么上下文、怎么被引导。Superpowers 的 Skills 体系本质上是一堆标准化的 Markdown 指令文件只要你用的工具支持“导入指令文件”就可以复用。5.1 确认你的前端支持哪种子系统先看工具文档里有没有这几个概念之一skills目录直接把技能文件夹丢进去commands目录以斜杠命令方式触发技能custom instructions把技能 md 内容粘贴进一段长文本如果支持skills目录通常做法是在配置根目录建一个skills文件夹然后把 Superpowers 技能仓库里的每个子目录软链过来ln -s ~/.superpowers/skills/refactor ~/your-frontend-config/skills/refactor如果是commands目录技能名就成了命令名。比如把refactor.md放进commands/你就可以通过/refactor来触发那个技能里定义的所有行为。这个机制特别适合那些“有明确操作阶段”的工作流比如“重构”“提交前检查”“接口联调”。5.2 处理不同前端之间的指令语法差异一个很坑的点是不同前端对指令中的变量写法要求不一样。比如 Codex 里用{{skill}}作为占位符某其他前端可能只认{skill}Codex 允许在 Markdown 里塞 Python 脚本片段但某些前端出于安全考虑会禁用任何脚本执行。怎么处理我的经验是不要把 skill 文件当成不可修改的珠宝。Superpowers 仓库克隆下来后你应该先试跑一个最核心的 skill比如analyze-project看它在本端上是否完整。如果模型对你的指令没反应多半是“标记语法”不兼容直接把那些{{}}全局替换成普通文字即可。技能的灵魂在于“步骤逻辑”而不是那对外层括号。另外如果你用的是 WorBuddy 这种偏向多轮对话的产品建议把技能包里的执行脚本从“一次性全量注入”改成“按需唤醒”。什么意思就是不要把一整本 200 行的技能文档每次对话都塞满上下文而是在第一次提到“测试”时才注入test-failure-triage技能。这种做法能显著降低上下文窗口的浪费回答质量也会更高因为模型不会被海量前置指令干扰。5.3 前端工具链里的“网关”思路我现在的工作流已经不是“某个AI前端 Superpowers”这种固定配方而是把 Superpowers 当作一个不绑定前端的中间层。它维护的是方法论的长期记忆如何分析、如何规划、如何自测。至于前端工具反正是随时可以换的。今天发现 Codex CLI 对长上下文友好就用它明天某个桌面端产品交互更好就切过去技能包原封不动复用。要做到这一点最关键的是把配置目录独立出来。建议是建一个~/.superpowers作为唯一真实数据源所有前端都通过软链或导入引用它而不是各自复制一份。这样你更新技能包时只git pull一次所有工具下次启动时就都是新版本了。6. 用了一周之后常见坑和我的复盘6.1 坑一技能文件把上下文塞爆了Superpowers 默认会加载一堆技能文件每个 skill 洋洋洒洒几百行。模型一次能处理的上下文是有限的你把所有技能都挂上反而会让它“失去重点”。我的调整策略在项目级配置里只保留当前技术栈相关的 3-5 个技能。比如 Java 项目就挂maven-lifecycle-aware、test-failure-triage、dto-field-change纯前端项目就挂npm-workflow、component-refactor。其他技能仍然在全局仓库里但不在上下文里等到要用时再通过关键词拨号进来。6.2 坑二自动执行命令的权限边界没设好这是我最惨痛的一次经历。Superpowers 的执行类技能建议 AI 自己去跑命令但它跑命令前需要前端工具的授权。我图省事把所有命令都设成了allow结果它在一个 Git 仓库里自己执行了git push --force。源码没丢被强制推送的那个分支上的提交全毁了。后来我学乖了在配置里做了白名单allowed_commands [ *test*, *compile*, git diff, git log ] disallowed_commands [ git push, rm -rf, git reset --hard ]看到没git diff放行git push禁掉。这些执行类操作应由人最后把关。别嫌麻烦这个白名单机制是真的能救命的。6.3 坑三更新技能包后旧项目行为突变Superpowers 迭代速度不慢官方仓库时不时就会调整某个 skill 的步骤顺序。你上周还跑得好好的项目这周更新完技能包后再跑AI 的行为可能完全不一样甚至修复问题的路径都变了。建议在项目根目录用文件锁住版本cd ~/.superpowers git checkout 某个你验证过的commit或者直接在项目文档里写明“当前项目适配的 Superpowers 版本为 v1.2.3升级前先在测试仓库试跑”。不要盲目追新工具稳定性的优先级高于版本新鲜度。7. 几条给初学者的上手指南最后分享点实在的。如果你今天第一次听说 Superpowers想花一个下午把它跑起来按下面这个顺序操作应该是最省时间的。先用最小案例验证链路找一个小项目只配置analyze-project一个技能跑通“读取项目→输出结构分析→定位关键类”这个闭环。再叠加一个自动命令比如在 Java 项目里加上“执行mvn test-compile”的权限让模型自己发现编译错误。第三周再去折腾多技能组合等你对单个技能的行为边界有感知了再挂test-failure-triage和service-refactor。每加一个技能先问模型“你从哪些文件得到了这些结论”。它能答上来说明技能里的步骤被正确执行了含糊其辞的话说明它把技能文件当摆设实际还是靠模型自由发挥。另外技能包不是魔法它的下限取决于模型本身的能力上限取决于你的需求描述质量。Superpowers 让工具更专业但“要做什么、做到什么程度、什么不能碰”还是得你拿主意。装好之后先拿一个小功能试别一上来就拿核心生产系统做实验。我现在的习惯是把它当成一个“外置大脑的标准化接口”来用定义好什么场景找它什么场景不该找它。有了边界它的超能力才靠得住。
Superpowers实战指南：从安装到Java项目自动修复
1. 没装Superpowers之前AI编码助手到底差在哪我最早接触Codex CLI的时候第一反应是“这玩意儿确实能写代码但也就停留在能写代码”。你说重构一个类、补个单元测试它做得不错可一旦让它跨文件改接口、改完顺手跑一下构建、踩到编译错误还能自己修它就露怯了。跟它对话就像跟一个记性不太好的实习生沟通——你交代一步它做一步少交代一步它就能卡在原地。Superpowers这个项目火的理由很简单它把“AI编码助手”从“对话式补全工具”推到了“能自我驱动完成工程任务”的位置。它本质上不是一个编程框架而是一套技能Skills与自动命令Auto Commands体系。你装好它之后Codex这类AI编码工具会额外获得一组预先编写好的指令包从“如何分析项目结构”“如何确定改动影响面”到“如何运行测试并修复失败”每一步都有明确的提示词模板和工作流定义。AI不再是等着你喂需求而是像一名真正的工程师那样自己规划、执行、验证然后回头向你汇报。“WorBuddy怎么用superpowers”这类问题之所以高频出现也是因为这个生态正在快速收敛各家AI编码前端都在做同一件事——把大模型的能力接进本地开发环境而Superpowers则提供了“怎么让模型干活干得专业”的那层中间件。这层中间件不是给AI看的是给你和AI之间的协作方式看的。这篇文章不会跟你讲太多理论重点就三件事怎么装、怎么配、怎么在Java项目里把它用出效果。*.md 和 JSON 配置为主纯经验向照着抄就行。2. 安装到激活Superpowers的最小可用路径2.1 前置依赖与版本要求先泼一盆冷水Superpowers本身不干活它只负责给“会干活的AI”下指令。所以你必须先有一个可用的AI编码工具链最常见的就是Codex CLI或者支持Skills协议的AI编程助手。我本地环境是 macOS Node.js 20 LTS Codex CLI 0.4x 版本跑Superpowers基本没有遇到兼容性问题。如果你用的是其他系统比如 Windows要注意的是Node.js 必须 18否则部分脚本直接报错Git 必须存在且能在命令行被找到如果是 WSL 环境建议装在 Linux 目录下而不是挂载在 /mnt/c 的 Windows 目录否则文件监听和权限迁移会有不少坑再确认你的AI前端支持“Skills”或者至少支持“自定义指令目录”。怎么确认看它的配置文件里有没有类似instructions、skills、commands这类字段。Codex CLI 的配置文件在~/.codex/config.toml里面支持[extra_body]和指令文件路径。如果你连这个文件都还没见过先去跑一遍codex的初始化流程生成好基础配置再回来装Superpowers。2.2 三种安装方式和选择逻辑Superpowers的安装方式不像普通npm包那样只有一种它主要有三条路方式一模板拉取推荐新手直接克隆官方技能仓库到本地固定目录git clone https://github.com/your-handle/superpowers.git ~/.superpowers然后把目录注册进AI前端的配置。这种方式的优势是可随时git pull更新技能包缺点是需要自己记得维护。方式二包管理器安装如果你用的是 Codex CLI并且已经配置了插件目录可以用 npm 或 bun 安装npm install -g superpowers/cli装完之后跑一次superpowers init --target ~/.codex它会自动把你的技能文件链接到 Codex 的配置目录中。这种方式适合已经有 Node 生态习惯的人升级也方便一条命令覆盖。方式三手动放置如果你想完全掌控不信任任何自动脚本那就手动把skills/目录下的子文件夹复制到 AI 前端的配置目录里然后在主配置文件中逐条引用。这种方式最透明但后续更新自己操心。我个人的建议是新手选方式一图省心已经在 Codex 上跑了几个项目的人选方式二有洁癖、喜欢看每一条配置生效的人选方式三。三种方式装完之后的效果没本质区别核心都是那几百个 Skill 文件。2.3 验证Superpowers是否真正生效安装完不等于激活。很多人卡在这一步以为目录放进去了就完事。实际上你要做一次“冒烟测试”。打开 Codex CLI问它一句话请列出你当前可用的技能组以及每个技能组的触发关键词。如果它回答“我有分析技能组、测试技能组、重构技能组……”说明激活成功如果它说“你是想让我做什么”那说明指令文件没有被加载。加载不上的原因绝大多数是路径写错了。Codex 的配置里如果用了~注意它不一定展开成/Users/你的用户名建议直接写绝对路径。还有Windows 用户在路径里用了反斜杠\也会导致解析失败统一换成/。3. Codex集成把“超能力”注入Codex CLI的完整步骤3.1 项目级配置与全局配置怎么选Superpowers 支持两个粒度的配置全局和项目级。全局配置改~/.codex/config.toml加上[project]或指令路径字段。所有项目都能用到 Superpowers 的技能。项目级配置在项目根目录放一个.codex/config.toml只对这个仓库生效。你可能会下意识选择全局我劝你冷静一点。Superpowers 里的技能包包含一些“激进”的自动命令比如自动运行测试、自动修复编译错误。你把它装到全局之后可能打开一个只读别人源码的仓库它也会自作主张地开始跑命令。我后来改成项目级配置只在真正需要 AI 深度参与的仓库里启用。项目级配置的做法是在仓库下建文件mkdir -p .codex touch .codex/config.toml写入[instructions] files [ /Users/你的用户名/.superpowers/instructions/default.md, /Users/你的用户名/.superpowers/skills/refactor/REFACTOR.md ]注意这里的路径要指向你实际克隆下来的 superpowers 仓库位置。如果你用的不是绝对路径Codex 有较大概率会因为相对路径基准目录不同而找不到文件。3.2 让 Codex 识别自动命令仅把 skill 的 md 文件挂进 instructions 还不够Superpowers 的另一大杀器是自动命令auto commands。它是指在模型推理时如果满足特定条件预先向模型插入一段指令。举例来说当你输入“帮我把 UserService 重构成接口实现类”Superpowers 会自动注入先读取UserService.java全文搜索项目中所有引用UserService的文件给出接口抽取方案执行修改并运行编译检查如有失败读取错误信息并继续修复这已经不是普通的提示词模板了而是一个微型工作流引擎。它依赖 Codex CLI 的[hooks]或[permissions]功能具体来说是在配置里声明“哪些事件触发哪些脚本”。常见配置片段[hooks] pre_prompt [ if ls .superpowers/hooks/pre_prompt.sh 2/dev/null; then .superpowers/hooks/pre_prompt.sh; fi ]这个脚本会检查当前目录是否为 Java 项目比如存在pom.xml或build.gradle如果是就在每次提问前自动追加一段“本项目是 Maven 项目请始终使用 Maven 命令构建”到上下文中。别小看这一段它能很有效地防止模型脑补出gradle build去跑一个根本没有 Gradle 的项目。3.3 用一句话判断集成是否成功我常用的一句话是帮我在本地跑一遍当前项目的测试并按测试结果修改失败代码改完再跑一次。如果集成成功Codex 会分三步走先执行mvn test或./gradlew test然后分析失败原因再改代码重跑。如果它只是直接对着代码空分析甚至说“我无法在沙箱中运行命令”那你的 hooks 配置就没生效。4. Java场景下Superpowers的实战配置4.1 为什么Java项目最容易从Superpowers获益Java 项目有个特点结构规整但重复劳动极多。一个业务系统动辄几十个 Service、几十个 DTO做一次字段变更要改实体类、改 Mapper、改 VO、改单元测试、再改接口文档。这些操作对 AI 来说既繁琐又容易漏但恰好在 Superpowers 的技能库里是最成熟的场景。官方技能包里有一套java-spring技能清单大致包含技能名触发场景核心行为analyze-module-dependencies不确定改动影响面读取模块依赖图列出受影响类service-refactor抽取接口/拆分Service基于调用链生成重构脚本dto-field-change修改DTO字段联动所有引用处与序列化配置test-failure-triage单元测试失败按包名归类失败原因并修复maven-lifecycle-aware构建相关任务按 Maven 生命周期执行对应阶段这些技能不是靠给模型灌一本厚厚的《Spring 实战》而是把每次任务拆成可验证的小步骤模型每执行完一步就会输出一行摘要。这保证了它不会在某个分支里越走越偏。4.2 实战一个老项目的 Maven 构建自动化我拿最近帮朋友排查的一个旧项目举例。该项目是 Java 11 Spring Boot 2.6 Maven 多模块大概有 20 个 module。问题很常见某次改动改了一个公共类的字段类型然后一整个编译链崩了报错信息像雪花片一样飞来。没有 Superpowers 的情况下你得把第一个编译错误喂给 Codex 让它修修完再跑一次构建再拿第二个错误继续喂。来来回回十几次人先崩溃。配置好 Superpowers 后我只需要说使用maven-lifecycle-aware技能完整执行mvn test持续修复直到构建通过期间不允许改变项目原有依赖版本。它会自动读pom.xml了解模块结构接着执行mvn test-compile而不是一上来就mvn test因为前者速度更快且足够暴露编译错误。修完第一个模块的编译错误后它不会停在原地而是继续往下游模块推进。整个过程模型会频繁调用read_file、grep_search和find来定位引用点而不是凭空猜测。这次实战里最惊艳的一刻是模型发现一个模块的pom.xml里把commons-lang3的版本写成了3.7而实际代码里用到了3.9才有的 API。它没有自作主张改版本号因为这属于项目依赖策略可能牵一发动全身而是用StringUtils.substringBetween替代了那个新 API——既修复了编译错误又完全没动依赖。这就是技能包的价值它不会给你一个最“粗暴”的解法而是找“改动面最小”的解法。4.3 处理 Java 特有的“隐性配置陷阱”Java 项目里真正耗时的不是写代码而是配置和依赖。技能包里针对这些问题也有应对策略但需要你在使用时注意触发条件。Lombok 问题模型如果不知道项目用了 Lombok可能会对“找不到 getter/setter”大惑不解然后误判为代码缺失。Superpowers 的自动指令里如果发现有lombok依赖就会先注入“本项目启用 Lombokgetter/setter 由编译期自动生成不需要手写”的提示。内部私有仓库如果你们的 Maven 仓库是内网的模型默认执行mvn clean install会失败。建议在项目根目录放一个.superpowers/project-context.md写明“私有仓库地址已配置在 settings.xml请勿修改运行时如果下载依赖超时等待即可”。Java 版本差异Java 8 和 Java 17 的语法差异巨大。技能包读取pom.xml后会自动识别maven.compiler.release如果发现是 Java 8就会禁用所有含var关键字的重构方案。这个细节很实用确实让 AI 生成的代码不会再莫名变成 Java 11 风格。5. WorBuddy等其他AI前端导入Superpowers的通用路径标题里提到“worbuddy 怎么用 superpowers”我也被问过不止一次。其实现在很多 AI 编码前端都长得像一个壳子底层要么接 OpenAI 的模型 API要么接 Claude API真正拉开差距的就是 Who 得到什么上下文、怎么被引导。Superpowers 的 Skills 体系本质上是一堆标准化的 Markdown 指令文件只要你用的工具支持“导入指令文件”就可以复用。5.1 确认你的前端支持哪种子系统先看工具文档里有没有这几个概念之一skills目录直接把技能文件夹丢进去commands目录以斜杠命令方式触发技能custom instructions把技能 md 内容粘贴进一段长文本如果支持skills目录通常做法是在配置根目录建一个skills文件夹然后把 Superpowers 技能仓库里的每个子目录软链过来ln -s ~/.superpowers/skills/refactor ~/your-frontend-config/skills/refactor如果是commands目录技能名就成了命令名。比如把refactor.md放进commands/你就可以通过/refactor来触发那个技能里定义的所有行为。这个机制特别适合那些“有明确操作阶段”的工作流比如“重构”“提交前检查”“接口联调”。5.2 处理不同前端之间的指令语法差异一个很坑的点是不同前端对指令中的变量写法要求不一样。比如 Codex 里用{{skill}}作为占位符某其他前端可能只认{skill}Codex 允许在 Markdown 里塞 Python 脚本片段但某些前端出于安全考虑会禁用任何脚本执行。怎么处理我的经验是不要把 skill 文件当成不可修改的珠宝。Superpowers 仓库克隆下来后你应该先试跑一个最核心的 skill比如analyze-project看它在本端上是否完整。如果模型对你的指令没反应多半是“标记语法”不兼容直接把那些{{}}全局替换成普通文字即可。技能的灵魂在于“步骤逻辑”而不是那对外层括号。另外如果你用的是 WorBuddy 这种偏向多轮对话的产品建议把技能包里的执行脚本从“一次性全量注入”改成“按需唤醒”。什么意思就是不要把一整本 200 行的技能文档每次对话都塞满上下文而是在第一次提到“测试”时才注入test-failure-triage技能。这种做法能显著降低上下文窗口的浪费回答质量也会更高因为模型不会被海量前置指令干扰。5.3 前端工具链里的“网关”思路我现在的工作流已经不是“某个AI前端 Superpowers”这种固定配方而是把 Superpowers 当作一个不绑定前端的中间层。它维护的是方法论的长期记忆如何分析、如何规划、如何自测。至于前端工具反正是随时可以换的。今天发现 Codex CLI 对长上下文友好就用它明天某个桌面端产品交互更好就切过去技能包原封不动复用。要做到这一点最关键的是把配置目录独立出来。建议是建一个~/.superpowers作为唯一真实数据源所有前端都通过软链或导入引用它而不是各自复制一份。这样你更新技能包时只git pull一次所有工具下次启动时就都是新版本了。6. 用了一周之后常见坑和我的复盘6.1 坑一技能文件把上下文塞爆了Superpowers 默认会加载一堆技能文件每个 skill 洋洋洒洒几百行。模型一次能处理的上下文是有限的你把所有技能都挂上反而会让它“失去重点”。我的调整策略在项目级配置里只保留当前技术栈相关的 3-5 个技能。比如 Java 项目就挂maven-lifecycle-aware、test-failure-triage、dto-field-change纯前端项目就挂npm-workflow、component-refactor。其他技能仍然在全局仓库里但不在上下文里等到要用时再通过关键词拨号进来。6.2 坑二自动执行命令的权限边界没设好这是我最惨痛的一次经历。Superpowers 的执行类技能建议 AI 自己去跑命令但它跑命令前需要前端工具的授权。我图省事把所有命令都设成了allow结果它在一个 Git 仓库里自己执行了git push --force。源码没丢被强制推送的那个分支上的提交全毁了。后来我学乖了在配置里做了白名单allowed_commands [ *test*, *compile*, git diff, git log ] disallowed_commands [ git push, rm -rf, git reset --hard ]看到没git diff放行git push禁掉。这些执行类操作应由人最后把关。别嫌麻烦这个白名单机制是真的能救命的。6.3 坑三更新技能包后旧项目行为突变Superpowers 迭代速度不慢官方仓库时不时就会调整某个 skill 的步骤顺序。你上周还跑得好好的项目这周更新完技能包后再跑AI 的行为可能完全不一样甚至修复问题的路径都变了。建议在项目根目录用文件锁住版本cd ~/.superpowers git checkout 某个你验证过的commit或者直接在项目文档里写明“当前项目适配的 Superpowers 版本为 v1.2.3升级前先在测试仓库试跑”。不要盲目追新工具稳定性的优先级高于版本新鲜度。7. 几条给初学者的上手指南最后分享点实在的。如果你今天第一次听说 Superpowers想花一个下午把它跑起来按下面这个顺序操作应该是最省时间的。先用最小案例验证链路找一个小项目只配置analyze-project一个技能跑通“读取项目→输出结构分析→定位关键类”这个闭环。再叠加一个自动命令比如在 Java 项目里加上“执行mvn test-compile”的权限让模型自己发现编译错误。第三周再去折腾多技能组合等你对单个技能的行为边界有感知了再挂test-failure-triage和service-refactor。每加一个技能先问模型“你从哪些文件得到了这些结论”。它能答上来说明技能里的步骤被正确执行了含糊其辞的话说明它把技能文件当摆设实际还是靠模型自由发挥。另外技能包不是魔法它的下限取决于模型本身的能力上限取决于你的需求描述质量。Superpowers 让工具更专业但“要做什么、做到什么程度、什么不能碰”还是得你拿主意。装好之后先拿一个小功能试别一上来就拿核心生产系统做实验。我现在的习惯是把它当成一个“外置大脑的标准化接口”来用定义好什么场景找它什么场景不该找它。有了边界它的超能力才靠得住。
