先说个我自己的真实经历。早前我用Codex、Claude Code这类AI编码工具最上头的用法就是甩给它一句话“帮我写个XX功能”然后回车。它确实噼里啪啦输出一大段代码我也确实兴冲冲地拿去跑紧接着也确实收获了一堆红色报错。反复几次之后我总结出一个规律这些大模型根本不缺代码能力它们缺的是“工作方法”。它们会非常自信地用一坨代码回你但不会先问需求边界、不会拆步骤、不会自己写测试验证更不会在改坏之后复盘。后来我在GitHub上翻到一个叫superpowers的项目通俗点说就是一套给AI编码助手“补课”的技能包。它的核心思路非常朴素把AI当成一个刚入职的实习生你先给它一份方法论手册再让它动手。这篇文章我就想用实际踩坑和跑通项目的经验聊聊它到底是什么、怎么装、怎么用以及在一个真实的Java项目里它能帮你省多少事。适合已经受够了AI“写得快写不对”的人也适合刚接触Codex、Claude Code、WorBuddy这类工具、想给它们建立工作流的开发者。1. superpowers到底是什么一套给AI编码助手“补课”的技能包1.1 它不是框架也不是插件而是一套“技能文件夹”我第一次接触superpowers时有个误区以为它是个Maven插件或者IDE插件装完就能在侧边栏看到新按钮。后来发现完全不是这么回事。它本质上就是一个Git仓库仓库里按目录组织了一堆“技能”每个技能的核心是一个叫SKILL.md的Markdown文件。这个文件用固定的格式告诉AI你接下来做某类任务时应该遵循什么步骤、输出什么中间产物、在什么节点做检查。举个例子如果你看它的目录会看到类似这种结构superpowers/ ├── skills/ │ ├── WritingPlans/ │ │ └── SKILL.md │ ├── ExecutingPlans/ │ │ └── SKILL.md │ ├── Debugging/ │ │ └── SKILL.md │ ├── Brainstorming/ │ │ └── SKILL.md │ └── ...每个文件夹就是一个技能。SKILL.md开头通常是一段YAML格式的元信息声明这个技能的名字和触发条件后面跟着具体的操作流程。你把这些文件夹丢到AI工具能识别的skills目录后模型在对话中就会读到这些规则并在合适的时候主动“调用”它们。我用一个类比来理解这件事你给实习生一台电脑他当然会写代码但他不知道你们团队的代码规范、不知道改完要跑哪几个测试、不知道什么时候该找人确认需求。superpowers给出的就是这套规范。它不是替你写代码而是告诉AI“你该按什么流程写代码”。1.2 为什么需要技能系统AI最缺的不是代码能力而是“工作方法”你回想一下让AI直接写代码的典型翻车过程需求说“帮我写个工具类”AI一口气生成200行里面有静态方法、有异常处理、有注释乍一看非常专业。但等你接进项目发现它没用你项目里已有的工具类、没遵循你们的包名规范、甚至异常处理吞掉了关键日志。问题出在哪不是AI笨是它压根不知道你的项目有哪些约束。你只给了它一个点状需求它只能基于训练数据里的“平均程序员水平”来发挥。superpowers的做法是把任务拆成阶段先头脑风暴再写计划然后按计划执行最后验证。每个阶段有明确的输入和输出。这其实对应了有经验工程师的工作方式——接到需求先确认范围再设计实现路径最后才写代码。AI缺少的正是这个“先想后做”的习惯。技能系统本质上是在对话上下文里注入了一套工作流指令强制模型改变行为模式。我自己最大的一次体会是让AI直接实现一个功能它可能在15分钟内给你一份能编译但逻辑有漏洞的代码但如果先让它写一份实现计划计划里包含“要修改哪些文件、每个文件改什么、如何验证”它后续的执行成功率高很多。原因很简单计划把大任务切成了小步骤每一步的上下文都更聚焦模型不容易跑偏。1.3 它和Codex、Claude Code、WorBuddy这类工具是什么关系很多人把superpowers误解为一个独立软件其实它更像是“行为准则包”。Codex、Claude Code、WorBuddy这些工具是运行环境负责执行命令、读写文件、和模型交互superpowers负责给这些环境里的AI提供方法论。你可以把前者理解为电脑后者理解为装在电脑里的“工作流程图”。它们之间的连接方式就是skills目录。不同AI工具读取skills目录的路径不太一样但原理一致启动时把技能文件内容作为系统提示或上下文注入。比如Codex CLI会读取~/.codex/skills或者项目下的.codex/skillsClaude Code会读取~/.claude/skills或者项目下的.claude/skills。WorBuddy这类Agent IDE通常也支持类似配置。也就是说你把superpowers克隆下来把里面skills文件夹的内容复制到你所用工具的对应目录重启会话技能就生效了。这里有个关键点技能系统不是“装了就一定触发”。模型需要看到SKILL.md里的触发描述并且在对话中判断当前任务匹配某个技能才会主动进入对应流程。所以装完之后不是万事大吉你得在提需求时用词明确一点让AI知道你希望它按技能走。这一点后面排查部分我会展开说。2. 核心技能拆解从头脑风暴到检查点调试2.1 WritingPlans动手前先把任务“翻译”成步骤清单WritingPlans是superpowers里最核心的一个技能也是我最开始用的时候最不习惯的一个。它要求AI在写代码前先产出一份计划文档把需求转换成“文件级”的操作步骤。一份合格的计划包含哪些内容我按照实际生成的模板给你总结一下任务背景和目标一句话说清楚要做什么、为了什么。涉及文件清单新增哪些文件、修改哪些文件。每个文件的具体改动点比如“在OrderCalculator.java中新增calculateDiscount方法返回BigDecimal”。依赖和风险比如“该改动会影响已有的订单导出功能”。验证方案怎么确认改完了是对的比如“跑mvn test -DtestOrderCalculatorTest”。没有这套流程时AI经常出现“改一个文件发现不够又改第二个改完第二个发现和第一个冲突”的情况。有计划之后它在执行阶段会围绕这份文件清单做事而不是临场发挥。我印象最深的一次是让它给一个Spring Boot项目加接口它先写计划列出了6个要改的文件实际执行时只动了5个最后一个因为计划里列了但后来发现不需要。如果让它直接写大概率会多改几个不相关的类。所以我的建议是所有超过半小时的任务都让AI先调用WritingPlans。哪怕你最终觉得计划写得不行让它重写也比让它直接写代码成本低得多。2.2 ExecutingPlans让AI照着计划执行而不是自由发挥如果说WritingPlans是“开工前画图纸”那ExecutingPlans就是“按图纸施工”。这个技能的作用是让AI在拿到计划后按照计划里的步骤依次执行每完成一步就检查一下是否偏离。实际执行中它会做到几个细节先读取计划文件然后逐条实施每次修改后调用相关命令验证如果发现计划里有不合理的步骤停下来告诉你“这里需要调整”而不是擅自改主意。这些细节单独看都不稀奇但组合起来效果非常明显。以前AI写代码像脱缰野马改了A就顺手改了B最后提交一堆无关改动。有了ExecutingPlans它至少会先问“我只改计划里列出的内容可以吗”用的时候有个小技巧执行阶段不要同时塞太多新需求。AI在执行计划时如果收到额外指示很容易把计划抛到一边。我习惯在对话里明确说“先按计划执行所有额外问题等执行完再讨论”。2.3 Debugging技能与“检查点”思想Debugging技能可能是superpowers里最“值钱”的一个因为大部分AI翻车都翻在调试环节。它的核心思想是“检查点”当AI遇到一个bug时不要立刻猜测原因乱改代码而是先找一个能稳定复现问题的检查点再通过二分定位缩小范围。我举个例子。以前我让AI修一个测试失败它第一反应是“可能是空指针加个判空试试”然后跑测试失败又改又跑反复十来次。用superpowers的Debugging技能后它的行为变成先看测试断言到底期望什么结果再检查被测试方法里哪些分支可能导致这个结果然后新增一个临时测试去验证它怀疑的分支。整个流程像医生问诊先问症状再做检查再开药而不是直接开一堆止痛药。这里还涉及一个“无头调试”的概念让AI用一个独立的临时脚本来复现bug而不是直接在项目里调试。好处是不污染项目代码而且脚本运行更快迭代也更快。遇到那种“报错信息一闪而过”的问题这个办法特别好用。我个人体会是Debugging技能对老手来说帮助可能不明显因为它教的东西很多优秀工程师本来就在做但对AI的默认行为纠偏效果显著。模型天然倾向于“猜”技能把它掰向“验证”。2.4 其他高频技能一览代码审查、重构、写测试除了上面三个superpowers还包含一些对日常开发同样有用的技能我用表格给你列一下技能触发场景核心动作Brainstorming需求不明确需要先梳理方案多轮问答澄清约束输出可选方案而不是直接写码CodeReview完成功能后想检查质量对照变更文件检查逻辑、边界、命名、测试覆盖Refactoring想优化已有代码但不敢乱动先确认行为不变再小步重构每步跑测试WritingTests给已有代码补测试先梳理输入输出再按分支补用例CodeReview技能我几乎每个任务结束后都会触发一次。以前让AI自检它总是客客气气地说“整体质量不错没有明显问题”。但套上技能后它会按照明确checklist逐项过比如“是否有未处理的null输入”“事务边界是否正确”“异常是否被吞掉”提出的问题明显尖锐很多确实是条文式流程逼出来的效果。这里提醒一句技能不是越多越好。同一时刻注入太多技能描述会占用上下文窗口反而降低模型执行效率。我一般只保留当前任务最相关的一两个技能在活跃状态其他的放着备用。这也是为什么我会把superpowers当作一个“工具箱”而不是“全家桶”来用。3. 实操从零安装到在Java项目里跑通3.1 安装与目录挂载Codex、Claude Code、通用方式superpowers的安装方式不复杂本质就是“把仓库拉下来把技能复制到指定目录”。完整流程我拆成三步第一步克隆仓库。你可以放到任意临时目录git clone https://github.com/obra/superpowers.git cd superpowers第二步复制技能到目标目录。不同工具的路径有差异我实测过两种典型情况。如果你用的是Claude Code可以放进项目的.claude/skills或者用户级的~/.claude/skills如果你用的是Codex CLI对应的是.codex/skills或~/.codex/skills。WorBuddy这类Agent IDE一般也会在项目根目录生成类似.agent/skills的目录具体名称看版本原理一样。# 以Codex CLI为例把技能装到用户级目录所有项目生效 mkdir -p ~/.codex/skills cp -r skills/* ~/.codex/skills/ # 如果只想对当前项目生效则放到项目目录下 mkdir -p .codex/skills cp -r skills/* .codex/skills/第三步重启AI工具的会话。一定要重启因为技能文件是在会话初始化时加载的不重启就看不到新技能。我自己更推荐项目级安装而不是用户级尤其是多个项目并行时。用户级会导致所有项目都加载同一套技能虽然省事但有些项目可能不需要那么重的流程。项目级安装的另一好处是技能文件跟着项目走团队成员clone下来就能有一致的工作流。3.2 让superpowers先“接管”你的Java需求从提示词开始装好只是开始真正的难点在于怎么让AI按技能工作。我总结了一个固定的提示词套路基本能稳定触发请使用superpowers里的相关技能来处理这个任务。 任务在现有Maven项目中新增一个订单金额计算模块。 要求先Brainstorming澄清需求再WritingPlans给出实现计划 确认计划后再执行最后补充测试。这个提示词里有几个关键词值得解释。直接点名“使用superpowers里的相关技能”是为了让模型去检索技能文件后续列出的技能名要和SKILL.md里的名字一致不要自己发明叫法。如果模型没有反应我会补一句“你可以在skills目录里查看可用技能”这通常能把它拉回正轨。一旦触发成功你能明显感觉到对话节奏变了。AI不再立刻甩代码而是开始反问“这个模块的输入输出是什么折扣规则是固定值还是可配置金额精度是BigDecimal吗需要支持多币种吗”这些问题看着烦但每一个都是避免返工的关键。Java项目最典型的风险就是金额用double导致精度错乱技能引导下AI会在动手前主动确认这一点。3.3 一次完整的Java实战做一个订单金额计算模块我完整跑过的一个例子是给一个Spring Boot项目增加“订单金额计算”功能要求包括商品折扣、满减优惠、运费三部分。下面我把整个交互过程压缩一下挑关键节点说明。触发技能后AI先输出了一段需求澄清问题包括优惠计算顺序先折扣还是先满减折扣比例是商品维度还是订单维度运费是否参与满减门槛计算金额是否统一用BigDecimal并保留两位小数这个过程大概花了两三轮对话。我回答了“先折扣再满减”“折扣按商品维度”“运费不参与门槛”“用BigDecimal”AI才进入计划阶段。计划输出了一份Markdown文档包含四个文件改动src/main/java/com/example/order/OrderCalculator.java (新增) src/main/java/com/example/order/OrderItem.java (新增) src/main/java/com/example/order/Order.java (新增) src/test/java/com/example/order/OrderCalculatorTest.java (新增)每个文件下面列出了主要方法签名和关键逻辑比如OrderCalculator.calculateTotal(Order order)内部按“商品折扣→小计→满减→加运费”的顺序计算。我确认后说“按计划执行”AI就开始逐个创建文件每创建完一个还顺手跑一次mvn compile确认没有语法错误。这里有一个很值得说的细节在执行阶段AI本来计划给Order类加一个shippingCost字段但写到一半发现运费更应该是计算器的入参而不是订单属性于是停下来问我“是否可以将运费作为calculateTotal的第二参数”。这在以前是不可想象的过去的AI会直接自己改然后留下一堆让我困惑的代码。技能系统给了它“停下来确认”的许可这比技能本身更值钱。测试阶段AI自动生成了基于JUnit的测试类用例覆盖了“折扣后满减门槛”“零元订单”“负数金额抛异常”这几个边界。跑完mvn test全绿。我最后又触发了一次CodeReview技能它检查后提了一个建设性意见建议用Enum定义折扣类型而不是字符串避免魔法值。这个建议本身不算惊艳但问题提得很到位。3.4 我在实操中调整过的关键参数与提示词设置以下是我在真实使用中摸索出的一些设置经验不一定适合所有人但值得参考。第一关于上下文窗口。superpowers的多个技能如果同时激活占用的token不少。Codex、Claude Code这类工具有的会限制单次请求的上下文导致AI“突然失忆”。我的做法是把技能按项目需求做裁剪。比如纯Java后端项目我会保留WritingPlans、ExecutingPlans、Debugging、CodeReview这四样把和前端相关的技能全部删掉减少噪音。第二关于计划粒度。我踩过最大的坑是让AI把计划写得过于细致细致到每个方法内部每一行怎么实现都写出来。这样计划本身占用大量上下文执行时反而束手束脚模型为了和计划措辞一致会写出很别扭的代码。可行的粒度是“文件方法签名关键逻辑”而不是“逐行伪代码”。第三关于自定义技能。如果你发现某个流程反复出现完全可以照着SKILL.md的格式写自己的技能文件放进去。我有一次为了统一团队里“接口联调”的检查步骤自己写了一个ApiCheck技能效果非常好。格式其实就是YAML头部加Markdown正文照着模板改就行。第四关于确认机制。superpowers默认会让AI在关键节点停下等你确认这个对单兵作战是好事但在批量任务时会显得很啰嗦。我通常会在提示词里加一句“除非计划出现重大偏差否则不需要每步都确认”把交互从“步步确认”降成“阶段确认”效率高很多。4. 常见问题与排查速查4.1 技能文件明明装了AI就是不按套路走这是最常遇到的问题我一开始差点因为这个放弃整个项目。排查顺序大概是三层第一检查技能目录到底装对没有。注意有些工具只认项目根目录下的.claude/skills不认用户级目录有些工具反过来。你可以在对话里问AI“你现在能看到哪些skills”让它列出来直接验证。第二检查SKILL.md里的触发描述是不是和你的任务描述匹配。如果技能说“当需要规划复杂任务时触发”你上来就说“帮我写个工具类”模型可能判断这是个简单的即席任务不触发。解决办法就是在提示词里点名要它用哪个技能别让它猜。第三检查模型本身。有些小参数模型对技能指令的遵循能力很弱看到一堆流程要求后直接忽略只当作普通对话。我的建议是技能系统配合强模型使用至少是Claude Sonnet级别或者Codex里中等以上推理档位。弱模型装技能属于浪费感情。4.2 计划文件太长执行到一半模型“断片”这个问题在长任务里特别典型。计划文档写得越长token占用越高模型在后面步骤中就越容易忘记前面的内容。我的实操经验是做到三件事控制计划文件在200行以内关键决策只保留“是什么”不保留“为什么”的长篇解释每完成一个步骤让AI在对话里总结一句“已完成X接下来做Y当前进度Z/5”用文字压缩上下文。如果任务实在太大我会在计划阶段主动拆分先只计划“第一部分模块A”做完了再计划“第二部分模块B”。这个力度和敏捷开发里的迭代很像短周期、可验证、及时反馈。4.3 不同AI工具对skills目录的读取差异这个坑属于典型的“每个工具都有自己的脾气”。Claude Code会读取项目.claude/skills里全部技能启动时加载Codex CLI读取路径类似但技能格式略有差异有些工具希望每个技能目录里必须有SKILL.md而不是任意文件WorBuddy这类IDE则可能在设置面板里额外开关“启用Agent Skills”。我给一个通用解法装好后第一件事不是开工而是问AI“列出你能访问的所有技能”并对比你放进目录的文件夹名确认数量一致。这个自检已经帮我避免过很多次“我以为装了但其实没生效”的尴尬。4.4 Java项目里的特殊注意事项Java项目用superpowers有个独特的坑AI生成代码时经常忽略Maven或Gradle的现有依赖配置。比如它计划里要用Lombok的Slf4j注解但项目里根本没引入Lombok计划里也没有写“修改pom.xml增加依赖”。所以在让AI走WritingPlans时一定要在任务描述里带上约束不允许引入未在pom.xml声明的第三方依赖如确需新增必须在计划中明确列出坐标。另外Java项目的测试框架适配也是一个点。老项目可能还在用JUnit 4但AI默认按JUnit 5生成测试导致跑不起来。我习惯在触发任务时就写明“测试使用JUnit 4运行命令mvn test”。这些看起来是小事但在Agent工作流里提前喂给AI能省掉一整轮返工。最后补一个关于版本的经验superpowers这类技能项目迭代很快建议隔一段时间就拉一次最新代码。它有几次更新直接改了技能触发词如果你还在用旧目录里的文件新版的AI聊天工具可能识别不到。维护好技能文件本身就和你维护项目依赖一样要有版本意识。我在正式把这套东西用进日常开发之前一直觉得“让AI写代码然后我检查”已经是极限了。跑通superpowers之后我发现真正的改变不是AI写的代码质量突然飞跃而是它开始像一个能沟通的同事会问需求、会写方案、会告诉我“这里计划需要调整”而不是闷头生成一坨代码甩给我。这种体验上的变化比省下来的时间更有价值。如果你现在正被“AI写代码快而不稳”折磨我的建议是别急着找更强的模型先给现有模型装上工作流。按我的个人体会技能系统能让一个普通档位的模型发挥出接近强模型的组织能力而强模型配上技能则是另一种竞争力。后面我还会继续折腾自定义技能和团队共享技能库有新的坑再来同步。 
长河君 · 2026/10/17 9:00:01 · 阅读 1.2k superpowers：给AI编码助手装上工作流技能包
先说个我自己的真实经历。早前我用Codex、Claude Code这类AI编码工具最上头的用法就是甩给它一句话“帮我写个XX功能”然后回车。它确实噼里啪啦输出一大段代码我也确实兴冲冲地拿去跑紧接着也确实收获了一堆红色报错。反复几次之后我总结出一个规律这些大模型根本不缺代码能力它们缺的是“工作方法”。它们会非常自信地用一坨代码回你但不会先问需求边界、不会拆步骤、不会自己写测试验证更不会在改坏之后复盘。后来我在GitHub上翻到一个叫superpowers的项目通俗点说就是一套给AI编码助手“补课”的技能包。它的核心思路非常朴素把AI当成一个刚入职的实习生你先给它一份方法论手册再让它动手。这篇文章我就想用实际踩坑和跑通项目的经验聊聊它到底是什么、怎么装、怎么用以及在一个真实的Java项目里它能帮你省多少事。适合已经受够了AI“写得快写不对”的人也适合刚接触Codex、Claude Code、WorBuddy这类工具、想给它们建立工作流的开发者。1. superpowers到底是什么一套给AI编码助手“补课”的技能包1.1 它不是框架也不是插件而是一套“技能文件夹”我第一次接触superpowers时有个误区以为它是个Maven插件或者IDE插件装完就能在侧边栏看到新按钮。后来发现完全不是这么回事。它本质上就是一个Git仓库仓库里按目录组织了一堆“技能”每个技能的核心是一个叫SKILL.md的Markdown文件。这个文件用固定的格式告诉AI你接下来做某类任务时应该遵循什么步骤、输出什么中间产物、在什么节点做检查。举个例子如果你看它的目录会看到类似这种结构superpowers/ ├── skills/ │ ├── WritingPlans/ │ │ └── SKILL.md │ ├── ExecutingPlans/ │ │ └── SKILL.md │ ├── Debugging/ │ │ └── SKILL.md │ ├── Brainstorming/ │ │ └── SKILL.md │ └── ...每个文件夹就是一个技能。SKILL.md开头通常是一段YAML格式的元信息声明这个技能的名字和触发条件后面跟着具体的操作流程。你把这些文件夹丢到AI工具能识别的skills目录后模型在对话中就会读到这些规则并在合适的时候主动“调用”它们。我用一个类比来理解这件事你给实习生一台电脑他当然会写代码但他不知道你们团队的代码规范、不知道改完要跑哪几个测试、不知道什么时候该找人确认需求。superpowers给出的就是这套规范。它不是替你写代码而是告诉AI“你该按什么流程写代码”。1.2 为什么需要技能系统AI最缺的不是代码能力而是“工作方法”你回想一下让AI直接写代码的典型翻车过程需求说“帮我写个工具类”AI一口气生成200行里面有静态方法、有异常处理、有注释乍一看非常专业。但等你接进项目发现它没用你项目里已有的工具类、没遵循你们的包名规范、甚至异常处理吞掉了关键日志。问题出在哪不是AI笨是它压根不知道你的项目有哪些约束。你只给了它一个点状需求它只能基于训练数据里的“平均程序员水平”来发挥。superpowers的做法是把任务拆成阶段先头脑风暴再写计划然后按计划执行最后验证。每个阶段有明确的输入和输出。这其实对应了有经验工程师的工作方式——接到需求先确认范围再设计实现路径最后才写代码。AI缺少的正是这个“先想后做”的习惯。技能系统本质上是在对话上下文里注入了一套工作流指令强制模型改变行为模式。我自己最大的一次体会是让AI直接实现一个功能它可能在15分钟内给你一份能编译但逻辑有漏洞的代码但如果先让它写一份实现计划计划里包含“要修改哪些文件、每个文件改什么、如何验证”它后续的执行成功率高很多。原因很简单计划把大任务切成了小步骤每一步的上下文都更聚焦模型不容易跑偏。1.3 它和Codex、Claude Code、WorBuddy这类工具是什么关系很多人把superpowers误解为一个独立软件其实它更像是“行为准则包”。Codex、Claude Code、WorBuddy这些工具是运行环境负责执行命令、读写文件、和模型交互superpowers负责给这些环境里的AI提供方法论。你可以把前者理解为电脑后者理解为装在电脑里的“工作流程图”。它们之间的连接方式就是skills目录。不同AI工具读取skills目录的路径不太一样但原理一致启动时把技能文件内容作为系统提示或上下文注入。比如Codex CLI会读取~/.codex/skills或者项目下的.codex/skillsClaude Code会读取~/.claude/skills或者项目下的.claude/skills。WorBuddy这类Agent IDE通常也支持类似配置。也就是说你把superpowers克隆下来把里面skills文件夹的内容复制到你所用工具的对应目录重启会话技能就生效了。这里有个关键点技能系统不是“装了就一定触发”。模型需要看到SKILL.md里的触发描述并且在对话中判断当前任务匹配某个技能才会主动进入对应流程。所以装完之后不是万事大吉你得在提需求时用词明确一点让AI知道你希望它按技能走。这一点后面排查部分我会展开说。2. 核心技能拆解从头脑风暴到检查点调试2.1 WritingPlans动手前先把任务“翻译”成步骤清单WritingPlans是superpowers里最核心的一个技能也是我最开始用的时候最不习惯的一个。它要求AI在写代码前先产出一份计划文档把需求转换成“文件级”的操作步骤。一份合格的计划包含哪些内容我按照实际生成的模板给你总结一下任务背景和目标一句话说清楚要做什么、为了什么。涉及文件清单新增哪些文件、修改哪些文件。每个文件的具体改动点比如“在OrderCalculator.java中新增calculateDiscount方法返回BigDecimal”。依赖和风险比如“该改动会影响已有的订单导出功能”。验证方案怎么确认改完了是对的比如“跑mvn test -DtestOrderCalculatorTest”。没有这套流程时AI经常出现“改一个文件发现不够又改第二个改完第二个发现和第一个冲突”的情况。有计划之后它在执行阶段会围绕这份文件清单做事而不是临场发挥。我印象最深的一次是让它给一个Spring Boot项目加接口它先写计划列出了6个要改的文件实际执行时只动了5个最后一个因为计划里列了但后来发现不需要。如果让它直接写大概率会多改几个不相关的类。所以我的建议是所有超过半小时的任务都让AI先调用WritingPlans。哪怕你最终觉得计划写得不行让它重写也比让它直接写代码成本低得多。2.2 ExecutingPlans让AI照着计划执行而不是自由发挥如果说WritingPlans是“开工前画图纸”那ExecutingPlans就是“按图纸施工”。这个技能的作用是让AI在拿到计划后按照计划里的步骤依次执行每完成一步就检查一下是否偏离。实际执行中它会做到几个细节先读取计划文件然后逐条实施每次修改后调用相关命令验证如果发现计划里有不合理的步骤停下来告诉你“这里需要调整”而不是擅自改主意。这些细节单独看都不稀奇但组合起来效果非常明显。以前AI写代码像脱缰野马改了A就顺手改了B最后提交一堆无关改动。有了ExecutingPlans它至少会先问“我只改计划里列出的内容可以吗”用的时候有个小技巧执行阶段不要同时塞太多新需求。AI在执行计划时如果收到额外指示很容易把计划抛到一边。我习惯在对话里明确说“先按计划执行所有额外问题等执行完再讨论”。2.3 Debugging技能与“检查点”思想Debugging技能可能是superpowers里最“值钱”的一个因为大部分AI翻车都翻在调试环节。它的核心思想是“检查点”当AI遇到一个bug时不要立刻猜测原因乱改代码而是先找一个能稳定复现问题的检查点再通过二分定位缩小范围。我举个例子。以前我让AI修一个测试失败它第一反应是“可能是空指针加个判空试试”然后跑测试失败又改又跑反复十来次。用superpowers的Debugging技能后它的行为变成先看测试断言到底期望什么结果再检查被测试方法里哪些分支可能导致这个结果然后新增一个临时测试去验证它怀疑的分支。整个流程像医生问诊先问症状再做检查再开药而不是直接开一堆止痛药。这里还涉及一个“无头调试”的概念让AI用一个独立的临时脚本来复现bug而不是直接在项目里调试。好处是不污染项目代码而且脚本运行更快迭代也更快。遇到那种“报错信息一闪而过”的问题这个办法特别好用。我个人体会是Debugging技能对老手来说帮助可能不明显因为它教的东西很多优秀工程师本来就在做但对AI的默认行为纠偏效果显著。模型天然倾向于“猜”技能把它掰向“验证”。2.4 其他高频技能一览代码审查、重构、写测试除了上面三个superpowers还包含一些对日常开发同样有用的技能我用表格给你列一下技能触发场景核心动作Brainstorming需求不明确需要先梳理方案多轮问答澄清约束输出可选方案而不是直接写码CodeReview完成功能后想检查质量对照变更文件检查逻辑、边界、命名、测试覆盖Refactoring想优化已有代码但不敢乱动先确认行为不变再小步重构每步跑测试WritingTests给已有代码补测试先梳理输入输出再按分支补用例CodeReview技能我几乎每个任务结束后都会触发一次。以前让AI自检它总是客客气气地说“整体质量不错没有明显问题”。但套上技能后它会按照明确checklist逐项过比如“是否有未处理的null输入”“事务边界是否正确”“异常是否被吞掉”提出的问题明显尖锐很多确实是条文式流程逼出来的效果。这里提醒一句技能不是越多越好。同一时刻注入太多技能描述会占用上下文窗口反而降低模型执行效率。我一般只保留当前任务最相关的一两个技能在活跃状态其他的放着备用。这也是为什么我会把superpowers当作一个“工具箱”而不是“全家桶”来用。3. 实操从零安装到在Java项目里跑通3.1 安装与目录挂载Codex、Claude Code、通用方式superpowers的安装方式不复杂本质就是“把仓库拉下来把技能复制到指定目录”。完整流程我拆成三步第一步克隆仓库。你可以放到任意临时目录git clone https://github.com/obra/superpowers.git cd superpowers第二步复制技能到目标目录。不同工具的路径有差异我实测过两种典型情况。如果你用的是Claude Code可以放进项目的.claude/skills或者用户级的~/.claude/skills如果你用的是Codex CLI对应的是.codex/skills或~/.codex/skills。WorBuddy这类Agent IDE一般也会在项目根目录生成类似.agent/skills的目录具体名称看版本原理一样。# 以Codex CLI为例把技能装到用户级目录所有项目生效 mkdir -p ~/.codex/skills cp -r skills/* ~/.codex/skills/ # 如果只想对当前项目生效则放到项目目录下 mkdir -p .codex/skills cp -r skills/* .codex/skills/第三步重启AI工具的会话。一定要重启因为技能文件是在会话初始化时加载的不重启就看不到新技能。我自己更推荐项目级安装而不是用户级尤其是多个项目并行时。用户级会导致所有项目都加载同一套技能虽然省事但有些项目可能不需要那么重的流程。项目级安装的另一好处是技能文件跟着项目走团队成员clone下来就能有一致的工作流。3.2 让superpowers先“接管”你的Java需求从提示词开始装好只是开始真正的难点在于怎么让AI按技能工作。我总结了一个固定的提示词套路基本能稳定触发请使用superpowers里的相关技能来处理这个任务。 任务在现有Maven项目中新增一个订单金额计算模块。 要求先Brainstorming澄清需求再WritingPlans给出实现计划 确认计划后再执行最后补充测试。这个提示词里有几个关键词值得解释。直接点名“使用superpowers里的相关技能”是为了让模型去检索技能文件后续列出的技能名要和SKILL.md里的名字一致不要自己发明叫法。如果模型没有反应我会补一句“你可以在skills目录里查看可用技能”这通常能把它拉回正轨。一旦触发成功你能明显感觉到对话节奏变了。AI不再立刻甩代码而是开始反问“这个模块的输入输出是什么折扣规则是固定值还是可配置金额精度是BigDecimal吗需要支持多币种吗”这些问题看着烦但每一个都是避免返工的关键。Java项目最典型的风险就是金额用double导致精度错乱技能引导下AI会在动手前主动确认这一点。3.3 一次完整的Java实战做一个订单金额计算模块我完整跑过的一个例子是给一个Spring Boot项目增加“订单金额计算”功能要求包括商品折扣、满减优惠、运费三部分。下面我把整个交互过程压缩一下挑关键节点说明。触发技能后AI先输出了一段需求澄清问题包括优惠计算顺序先折扣还是先满减折扣比例是商品维度还是订单维度运费是否参与满减门槛计算金额是否统一用BigDecimal并保留两位小数这个过程大概花了两三轮对话。我回答了“先折扣再满减”“折扣按商品维度”“运费不参与门槛”“用BigDecimal”AI才进入计划阶段。计划输出了一份Markdown文档包含四个文件改动src/main/java/com/example/order/OrderCalculator.java (新增) src/main/java/com/example/order/OrderItem.java (新增) src/main/java/com/example/order/Order.java (新增) src/test/java/com/example/order/OrderCalculatorTest.java (新增)每个文件下面列出了主要方法签名和关键逻辑比如OrderCalculator.calculateTotal(Order order)内部按“商品折扣→小计→满减→加运费”的顺序计算。我确认后说“按计划执行”AI就开始逐个创建文件每创建完一个还顺手跑一次mvn compile确认没有语法错误。这里有一个很值得说的细节在执行阶段AI本来计划给Order类加一个shippingCost字段但写到一半发现运费更应该是计算器的入参而不是订单属性于是停下来问我“是否可以将运费作为calculateTotal的第二参数”。这在以前是不可想象的过去的AI会直接自己改然后留下一堆让我困惑的代码。技能系统给了它“停下来确认”的许可这比技能本身更值钱。测试阶段AI自动生成了基于JUnit的测试类用例覆盖了“折扣后满减门槛”“零元订单”“负数金额抛异常”这几个边界。跑完mvn test全绿。我最后又触发了一次CodeReview技能它检查后提了一个建设性意见建议用Enum定义折扣类型而不是字符串避免魔法值。这个建议本身不算惊艳但问题提得很到位。3.4 我在实操中调整过的关键参数与提示词设置以下是我在真实使用中摸索出的一些设置经验不一定适合所有人但值得参考。第一关于上下文窗口。superpowers的多个技能如果同时激活占用的token不少。Codex、Claude Code这类工具有的会限制单次请求的上下文导致AI“突然失忆”。我的做法是把技能按项目需求做裁剪。比如纯Java后端项目我会保留WritingPlans、ExecutingPlans、Debugging、CodeReview这四样把和前端相关的技能全部删掉减少噪音。第二关于计划粒度。我踩过最大的坑是让AI把计划写得过于细致细致到每个方法内部每一行怎么实现都写出来。这样计划本身占用大量上下文执行时反而束手束脚模型为了和计划措辞一致会写出很别扭的代码。可行的粒度是“文件方法签名关键逻辑”而不是“逐行伪代码”。第三关于自定义技能。如果你发现某个流程反复出现完全可以照着SKILL.md的格式写自己的技能文件放进去。我有一次为了统一团队里“接口联调”的检查步骤自己写了一个ApiCheck技能效果非常好。格式其实就是YAML头部加Markdown正文照着模板改就行。第四关于确认机制。superpowers默认会让AI在关键节点停下等你确认这个对单兵作战是好事但在批量任务时会显得很啰嗦。我通常会在提示词里加一句“除非计划出现重大偏差否则不需要每步都确认”把交互从“步步确认”降成“阶段确认”效率高很多。4. 常见问题与排查速查4.1 技能文件明明装了AI就是不按套路走这是最常遇到的问题我一开始差点因为这个放弃整个项目。排查顺序大概是三层第一检查技能目录到底装对没有。注意有些工具只认项目根目录下的.claude/skills不认用户级目录有些工具反过来。你可以在对话里问AI“你现在能看到哪些skills”让它列出来直接验证。第二检查SKILL.md里的触发描述是不是和你的任务描述匹配。如果技能说“当需要规划复杂任务时触发”你上来就说“帮我写个工具类”模型可能判断这是个简单的即席任务不触发。解决办法就是在提示词里点名要它用哪个技能别让它猜。第三检查模型本身。有些小参数模型对技能指令的遵循能力很弱看到一堆流程要求后直接忽略只当作普通对话。我的建议是技能系统配合强模型使用至少是Claude Sonnet级别或者Codex里中等以上推理档位。弱模型装技能属于浪费感情。4.2 计划文件太长执行到一半模型“断片”这个问题在长任务里特别典型。计划文档写得越长token占用越高模型在后面步骤中就越容易忘记前面的内容。我的实操经验是做到三件事控制计划文件在200行以内关键决策只保留“是什么”不保留“为什么”的长篇解释每完成一个步骤让AI在对话里总结一句“已完成X接下来做Y当前进度Z/5”用文字压缩上下文。如果任务实在太大我会在计划阶段主动拆分先只计划“第一部分模块A”做完了再计划“第二部分模块B”。这个力度和敏捷开发里的迭代很像短周期、可验证、及时反馈。4.3 不同AI工具对skills目录的读取差异这个坑属于典型的“每个工具都有自己的脾气”。Claude Code会读取项目.claude/skills里全部技能启动时加载Codex CLI读取路径类似但技能格式略有差异有些工具希望每个技能目录里必须有SKILL.md而不是任意文件WorBuddy这类IDE则可能在设置面板里额外开关“启用Agent Skills”。我给一个通用解法装好后第一件事不是开工而是问AI“列出你能访问的所有技能”并对比你放进目录的文件夹名确认数量一致。这个自检已经帮我避免过很多次“我以为装了但其实没生效”的尴尬。4.4 Java项目里的特殊注意事项Java项目用superpowers有个独特的坑AI生成代码时经常忽略Maven或Gradle的现有依赖配置。比如它计划里要用Lombok的Slf4j注解但项目里根本没引入Lombok计划里也没有写“修改pom.xml增加依赖”。所以在让AI走WritingPlans时一定要在任务描述里带上约束不允许引入未在pom.xml声明的第三方依赖如确需新增必须在计划中明确列出坐标。另外Java项目的测试框架适配也是一个点。老项目可能还在用JUnit 4但AI默认按JUnit 5生成测试导致跑不起来。我习惯在触发任务时就写明“测试使用JUnit 4运行命令mvn test”。这些看起来是小事但在Agent工作流里提前喂给AI能省掉一整轮返工。最后补一个关于版本的经验superpowers这类技能项目迭代很快建议隔一段时间就拉一次最新代码。它有几次更新直接改了技能触发词如果你还在用旧目录里的文件新版的AI聊天工具可能识别不到。维护好技能文件本身就和你维护项目依赖一样要有版本意识。我在正式把这套东西用进日常开发之前一直觉得“让AI写代码然后我检查”已经是极限了。跑通superpowers之后我发现真正的改变不是AI写的代码质量突然飞跃而是它开始像一个能沟通的同事会问需求、会写方案、会告诉我“这里计划需要调整”而不是闷头生成一坨代码甩给我。这种体验上的变化比省下来的时间更有价值。如果你现在正被“AI写代码快而不稳”折磨我的建议是别急着找更强的模型先给现有模型装上工作流。按我的个人体会技能系统能让一个普通档位的模型发挥出接近强模型的组织能力而强模型配上技能则是另一种竞争力。后面我还会继续折腾自定义技能和团队共享技能库有新的坑再来同步。