1. 先搞清楚AI 编程助手到底差在哪最近身边好几个人都在问“Superpowers 怎么装”“Superpowers 怎么用”热搜词里还混着“codex superpowers”“superpowers java”这种组合。说实话我第一次看到这个名字也有点懵以为是又一个编程工具或者 IDE结果研究完才发现它解决的是一个非常多人都踩过的坑——AI 编程助手单打独斗的时候能力很强但一旦扔给它一个真实项目特别容易“高开低走”。你可以回想一下自己用 Claude、Codex 这类 AI 写代码的场景开头让 AI 生成一个函数或者一个页面效果惊艳可一旦任务变成“把这个老模块重构掉”或者“给整个服务加上日志和监控”AI 就开始顾头不顾尾。它要么一口气把计划、代码、测试全写出来结果细节全是错的要么写了一半突然开始改无关文件把项目搞得一团糟。说到底问题不是模型不够聪明而是缺少一套明确的“工序”。人写复杂功能的时候会先想清楚需求、拆任务、定验收标准、然后一步步实现、最后自测。但直接对着大模型甩一段需求等于让一个天才员工在没有排期、没有评审、没有验收流程的情况下自由发挥翻车几乎是必然的。Superpowers 做的事就是给 AI 编程助手补上这套“工序”。它不是某个大模型也不是 IDE 插件而是一套可插拔的技能系统把写代码这件事拆成有章法的完整流程。这也是为什么它能跟 Codex、Java 项目这些关键词挂在一起——它关心的是工作方式跟具体语言、具体模型的关系没有想象中那么大。这篇文章我会从安装开始讲把核心技能逐个拆开再拿一个真实的 Java 重构场景完整跑一遍最后说一下我实际使用中踩过的坑。想直接上手的朋友可以按顺序跟着做不需要太多前置知识。2. Superpowers 的本质给 AI 装上一套“工种分工”2.1 不是一个新软件而是一堆“技能文件”Superpowers 的形态可能和你想的不太一样。它不是一个跑起来的服务也不是一个需要常驻内存的进程而是一组Markdown 格式的技能文件。每一个技能都对应一个工作角色比如“规划者”“拆解者”“实现者”“质检者”。这种设计有个很妙的地方AI 编程助手本身就是读文本指令干活的所以技能文件对它来说就是“说明书”。你让 AI 执行plan这个技能它就会打开对应的说明书按照里面写的步骤、输出格式、注意事项来执行。正因为本质上是文本Superpowers 才可以被移植到不同工具上——Claude Code 能直接吃这套技能Codex 也能通过自定义指令来加载只是挂载方式略有区别。如果你用过 Claude Code 的自定义技能Skills功能理解起来就更简单了。技能就是一个目录里面放一个SKILL.md作为入口说明还可以附带一些参考文档。Superpowers 把这种方法论化了它把常用的软件开发流程做成了规范化的技能包批量导入之后AI 就跟“受过正规训练的专业团队”一样懂得克制、懂得按步骤来。2.2 核心技能清单规划、拆解、实现、验收我从实际使用体验出发把最常用的几个技能按工作流顺序列一下技能定位什么时候用它plan制定实施计划接到新需求先不写代码先把目标、步骤、风险列清楚jigsaw把大任务拆成小切片任务太大无法一次完成时拆成可独立开发、可独立验证的小块muse专注完成代码实现计划已经定好需要按计划写具体实现时boss监督执行、检查结果实现完成之后用“上级视角”检查代码是否真的满足要求frenemy代码审阅与改进建议想让 AI 从不同角度挑毛病、提重构建议时这些技能单独用也有价值但真正威力在组合起来的时候。一个完整功能从需求到上线可以看成一条流水线plan定方向 →jigsaw切成可执行切片 →muse逐片实现 →boss验收当前切片 → 循环到所有切片完成。每一次循环只盯一个切片AI 的上下文窗口就不会被撑爆出错概率也会大幅降低。2.3 “Codex Superpowers”到底是什么搜索词很多人搜索“codex superpowers”可能是以为 Superpowers 只有 Claude Code 能用。其实严格说Superpowers 最初确实是为 Claude Code 设计的但技能文件既然是纯文本就存在迁移可能。我的做法是把同一套技能目录拷贝到 Codex 的自定义指令目录里再在启动提示词里加一句“请加载相关技能”效果虽然不能说 100% 一致但核心的“先规划、再拆解、后实现”这套思想完全可以落地。如果你只在 Claude Code 里用当然最简单如果你同时用 Codex不妨记住一句话Superpowers 卖的是方法论方法论是无所谓具体工具的。3. 安装与激活命令行太麻烦WorBuddy 也帮你把这事办了3.1 官方一键安装命令因为我安装的时间比较早当时还是直接用 Git 克隆的方式把技能仓库拉到本地。后来的版本基本都有官方安装脚本了我建议直接到项目主页superpowers.obra.dev复制最新的安装命令因为这类工具更新很频繁网上教程里的命令过期是常态。以我机器上的实际目录结构为例Claude Code 读取自定义技能的路径通常是~/.claude/skills/安装的本质就是把技能文件夹放进去。手动操作大致是这样的# 备份原有技能目录如果有的话 mv ~/.claude/skills ~/.claude/skills.bak # 克隆技能仓库 git clone https://github.com/obra/superpowers.git ~/.claude/skills # 确认目录结构 ls ~/.claude/skills你会看到里面有很多子目录比如plan、jigsaw、muse、boss每个目录下都带有SKILL.md。到这一步安装其实就算完成了Claude Code 启动时会自动扫描这些技能目录。如果你用的是官方脚本它多半还会帮你检查环境依赖比如确认git、curl已安装以及给出卸载方式。3.2 通过 WorBuddy 图形化导入技能不少朋友看到命令行就打怵尤其是 Windows 下 PowerShell 的路径和 Linux 不太一样容易复制命令报错。社区里后来也出现了图形化管理工具让新手可以用界面操作WorBuddy 就是我在这类工具里见得比较多的一款。用 WorBuddy 管理 Superpowers 的核心逻辑很简单它本质上是一个“技能管理器”你可以在界面里浏览本地的技能目录看到哪些技能已经安装哪些还是空的。导入 Superpowers 的时候只需要指定克隆路径或者选择已经下载好的技能文件夹WorBuddy 会帮你把文件复制到 Claude Code 或 Codex 对应的技能目录下。有些版本还支持直接在工具里编辑SKILL.md改完保存就生效对于不想碰命令的人来说确实省事。需要说明的是WorBuddy 不是 Superpowers 官方出的东西它只是一个周边工具。用它的前提是路径配置正确尤其是要搞清楚当前项目是使用“用户级技能目录”还是“项目级技能目录”不然会出现安装成功但实际调不用的诡异情况。关于这个概念我下一节专门说。3.3 项目级还是用户级一个最容易忽略的配置Superpowers 技能可以装在两个层级用户级放在~/.claude/skills对所有项目生效相当于全局安装。项目级放在项目的.claude/skills目录下只对当前项目生效适合团队统一约束工作流程。我的建议是个人使用直接装用户级方便省事。但如果是团队项目最好把 Superpowers 纳入项目级的.claude/skills并提交到 Git 仓库里。这样每个团队成员拉到代码后AI 技能自动就带着了不会出现“你的 AI 会规划、我的 AI 只会乱写”的差异。如果你通过 WorBuddy 装了技能但没有效果先别急着卸载大概率就是层级选错了。查看当前 Claude Code 会话中技能是否被识别可以输入/skills列表命令如果列表里能看到plan、jigsaw说明加载成功否则就检查目录路径和大小写。3.4 验证安装是否真的成功装完之后不要急着开干先做一个最小验证。随便建一个空的测试目录进入 Claude Code 后执行/plan 请帮我规划一个用户登录功能的实现步骤如果 AI 开始按照“需求分析→接口设计→数据库设计→实现顺序→测试方案”这种结构化格式输出说明plan技能生效了。如果它只是像普通对话一样随便回了一段那大概率是技能没有被加载。还有一种验证方式是不带任何技能直接问 AI“你有哪些技能可用”如果 Superpowers 加载成功它会主动列出相关技能如果回答“我不知道有什么技能”那就得回到路径配置的问题上排查。4. 实战走一遍用 Superpowers 重构一个 Java 模块很多人问我“superpowers java”到底怎么用担心这套技能是为 Web 前端或者 Python 准备的。其实不需要有这种顾虑技能是方法论Java 项目完全可以照搬。下面我拿一个非常常见的场景演示把一段又长又乱的订单金额计算逻辑重构为清晰策略模式。假设有一个类叫OrderCalculator里面有几百行if/else判断根据订单类型计算折扣、运费、税费逻辑纠缠在一起。如果用传统方式直接让 AI 重构它极有可能大刀阔斧改一遍然后编译错误一堆测试也全挂。用 Superpowers 就不一样了整个过程会被拆成四步。4.1 规划阶段先出方案不写代码进入 Claude Code 后执行plan技能把需求描述清楚/plan 重构 OrderCalculator 中的订单金额计算逻辑将不同订单类型的折扣、运费、税费计算拆分为策略类。现有代码在 src/main/java/com/example/order/OrderCalculator.java测试在 src/test/java/...AI 在plan技能的控制下不会直接给出重构后的完整代码而是先输出一份方案内容包括现有问题分析、目标状态、改动范围、涉及的风险点、验证方式。这一步非常关键因为它逼着你把“目标”和“手段”先分开。我经常看到有人跳过这一步直接让 AI 改代码结果 AI 的思路和项目实际架构完全是两回事。如果方案里有你不认可的地方这时候直接提出来让 AI 调整计划。改计划比改代码成本低得多。4.2 拆解阶段切成三个可独立验证的切片拿到方案后下一步执行jigsaw让它把大重构拆成小切片。我的实际运行结果类似这样切片一抽取DiscountStrategy接口并把现有的折扣计算逻辑先平移进去保证行为不变。切片二抽取ShippingStrategy接口处理运费计算。切片三抽取TaxStrategy接口并改造OrderCalculator主流程按订单类型组装策略。每个切片都满足一个原则可以独立编译、独立跑测试、独立提交。这比一口气重构完要稳得多因为任何一个切片失败都可以快速定位问题不会出现改动 20 个文件后找不到锅在哪。4.3 实现阶段让 Muse 闷头写代码切片拆好后进入实现阶段。这里我强烈建议用muse技能而不是直接继续用默认对话模式。原因很简单muse的设计是“少废话、多干活”它只专注于当前切片的实现不会突然跑去优化无关变量名也不会长篇大论解释设计模式。对第一个切片我会这么发指令/muse 实现切片一创建 DiscountStrategy 接口和对应的策略类将 OrderCalculator 中现有折扣逻辑原样迁移不改任何计算规则。输出代码和对应单元测试。逻辑迁移保持原样这一点很重要。重构的第一原则是“行为不变”如果要顺手优化逻辑那就混入了第二类变更风险会成倍增加。muse技能会让 AI 聚焦在这个范围里实现完它会展示代码并自动补测试。只要原逻辑里各种if/else分支都能被测试覆盖到重构的安全感马上就上来了。4.4 验收阶段Boss 视角检查成果每个切片实现完切回boss技能做验收相当于找一个经验丰富的技术主管来审代码。我会让它检查是否真的没有改变原有计算规则新增的测试用例覆盖了哪些分支有没有不符合项目规范的地方有一次我处理一个订单模块muse实现完第一个切片后boss就发现了一个隐蔽问题原来代码里某个折扣判断依赖订单创建时间的毫秒数但迁移过程中测试用例没有覆盖这个边界值导致在特定时间戳下结果不一致。这种问题如果靠人肉检查很费精力但让一个“挑剔的管理者”专门审一遍就容易被发现。等所有切片都实现完最后再整个跑一遍全量测试mvn clean test全绿之后这个重构才算真正结束。整个过程下来你会发现 AI 不再是一个“只会猛冲的码农”而是一个“有规划、有节奏、有检查”的协作对象。5. 常见的翻车场景和我的排查经验5.1 技能“隐身”了明明装了却调用失败这是我被问得最多的问题。好几个朋友跑完安装命令也看到技能目录存在但一执行/plan就提示“未知命令”。排查链路一般是确认当前 Claude Code 版本是否支持自定义技能。太老的版本对技能机制的兼容性很差。确认技能目录放置的层级正确。用户级放~/.claude/skills项目级放.claude/skills两个层级不能混。确认SKILL.md文件名大小写。Linux 下大小写敏感写成skill.md会导致识别失败。重启 Claude Code 会话。技能扫描一般在启动时加载运行中新增目录不会热更新。如果你用的是 WorBuddy 这类图形工具还要额外检查它复制文件的时候是不是不小心把目录结构套了一层导致~/.claude/skills/superpowers/plan/SKILL.md变成了~/.claude/skills/superpowers/superpowers/plan/SKILL.md。这种双嵌套非常阴间表面上看目录存在但实际路径根本对不上。5.2 卡在 Plan 循环里出不来还有一种情况AI 太讲究流程了每个小任务都先做规划规划完又继续规划下一步产生一种“永远在开会、永远不写代码”的既视感。这主要是因为技能之间切换得不够坚决。我的做法是给流程加一个“时间盒”。比如小到一个 Bug 修复大到一次模块重构都要明确规则这个任务整体预计只做三轮交互第一轮 plan第二轮 jigsaw后面每一轮只做实现不许回头重新规划。如果实现中发现规划确实有问题记录下来放到任务末尾统一处理而不是当场陷入新的规划循环。5.3 与 Codex 配合时的兼容性问题前面说了 Superpowers 可以迁移到 Codex但实际体验确实有差异。一方面Codex 的自定义指令机制和 Claude Code 的技能机制并不完全等价技能文件的加载方式会受到工具本身限制另一方面Codex 对超长指令的处理逻辑不同有些技能文件里的示例比较多Codex 可能会忽略后半部分。我的建议是如果是日常深度工作优先在 Claude Code 里用 Superpowers偶尔体验 Codex 时只迁移plan和jigsaw两个核心技能就够了不要贪多。因为这两个技能对输出格式的要求最宽松迁移后不容易走样。5.4 别让 AI 自己“定义技能”另一个值得一提的坑是有些人会直接对 AI 说“你先看看这些技能然后自己优化一下技能文件”。听起来很合理但实际执行时AI 很可能会把技能内容改得面目全非有的甚至把原本精炼的步骤扩写成万字长文直接导致技能加载后输出质量严重下降。技能文件本质上是一份稳定可靠的“制度”制度可以定期迭代但不能让执行者随手改制度。真要改也应该把问题收集起来单独开一个对话以“修订技能文件”为明确任务并做好版本备份。我用了一个最土但有效的办法把技能目录初始化为 Git 仓库每次修改前先提交一版改坏了随时回滚。6. 我在实际使用中的体会适合什么不适合什么用了 Superpowers 一段时间后我的整体感受是它最大的价值不是让 AI 写得更快而是让 AI 写得更可控。有些任务比如简单脚本、一次性数据处理、临时调试代码你压根不需要走完整流程直接对话反而更高效而一旦任务涉及多文件、多模块、修改存量代码这套流程的优势就非常明显——因为复杂度上来之后人类的“掌控感”才是第一位。我特别推荐以下几种场景使用老项目重构行为不变的前提下整理代码结构天然适合切片化推进。跨模块功能开发比如给系统加一套新的鉴权机制牵涉面广必须先规划再动手。多人协作前的前置设计让 AI 先产出一份方案作为团队评审的基础材料。接手不熟悉的代码库用plan先让 AI 梳理模块关系比自己从头看到尾快得多。反过来如果是十几个字的临时需求比如“把这段 JSON 转成 Java 对象”强行套流程就是杀鸡用牛刀。最后分享一个我个人的小技巧不要把 Superpowers 的技能当成黑盒里面每个SKILL.md都值得打开读一遍。它不是加密的东西就是一段一段的提示词设计。读懂之后你会对“如何给 AI 下高质量指令”这件事有更深的感觉。哪怕以后这套技能不流行了这套“规划→拆解→实现→验收”的思路你依然可以用在任何 AI 编程工具上。这才是它对我来说最值回票价的地方。
