最近我一直在用的AI编程辅助工作流里多了一个叫 superpowers 的东西。它不是IDE插件也不像Copilot那样弹提示补全代码而是一套跑在Claude Code、Codex这类终端Agent工具里的“技能包”。说白了它通过一组设计得很讲究的skill文件给AI规定了干活的套路接到任务先做规划、动手改代码前先写测试、遇到bug先找根因而不是瞎试。我把它接进自己的Java项目工作流里跑了小半个月最直观的感受是AI不再像一个手速很快但没经验的新人而更像一个按正规军流程办事的工程师。这篇文章我把自己的使用过程完整拆开讲superpowers到底是什么、它给AI装了哪些核心技能、怎么装到Claude Code / Codex / Workbuddy里、以及在真实Java项目里排查一个空指针问题的完整经过。最后附上我踩过的坑和排查清单希望能让你少走点弯路。1. superpowers是什么它不是插件而是一套“工作方法”1.1 项目来源与基本构成superpowers的作者是开发者社区里挺活跃的ObraJesse Vincent这个项目最初的定位很明确给Claude Code装上“资深工程师的工作习惯”。它不是传统意义上的插件也不涉及模型微调而是一堆Markdown格式的skill文件。每个skill文件就是一个操作手册里面写了这个技能适用的场景、触发条件、执行步骤和输出格式。项目在GitHub上开源仓库结构里有明确的skills目录里面按功能拆成了好多子目录。比如debugging、test-driven-development、planning、scoping、code-review、subagent-driven-development等等。每个子目录下都有核心的SKILL.md文件Claude Code这类工具在启动时会把这些文件读进上下文中。当对话里出现匹配的问题类型时AI会自动加载对应的skill按里面的流程来执行。这就是它跟普通提示词prompt最大的区别。普通提示词是一次性的对话开始扔进去之后AI记不记得全看心情。而skill是持续存在于工作记忆里的操作规范AI遇到相应场景时会主动遵循。我一开始以为这就是个“高级system prompt”实际用下来发现差别很大它的流程设计是模块化的每个技能之间还能组合调用比如debugging过程中会自然切换到test-driven-development。1.2 设计哲学为什么AI需要“操作规范”聊这个之前先想一个问题一个刚毕业的实习生和一个十年经验的工程师面对同一个bug差别在哪实习生大概率直接改代码改完发现不行再改越改越乱。工程师会先复现、再定位、看最近改动、列假设、逐个验证最后才动手。现在的AI编程工具基础能力已经很强了读代码、写代码、重构都很快。但它的默认行为模式恰恰像那个实习生你丢一个问题给它它恨不得马上给出“看起来最靠谱”的改动。在简单场景下这么做没问题但遇到复杂业务逻辑、历史包袱重的项目这种“快思考”就会翻车。superpowers的设计思路就是给AI强行套上“慢思考”的流程让它像资深工程师那样按步骤办事。这个思路其实跟认知科学里系统1和系统2的概念很接近。AI默认走的是系统1快但不严谨superpowers逼它走系统2慢但可靠。我在实际项目中体会特别深以前让AI直接改一个Spring Bean初始化顺序的问题它给出的方案在单测里没问题一上线就炸。后来按superpowers的流程走先让我复现稳定触发条件再看git提交历史最后给出的是一个改动点极小的修复。2. 核心技能拆解superpowers到底给了AI哪些能力2.1 debugging把“乱试修bug”变成“系统化排障”debugging是superpowers里我最常用的技能也是我认为价值最高的一个。它规定AI在接到bug报告后不允许直接改代码必须先完成一系列规定动作确认触发条件、复现问题、检查最近的代码改动、列出可能导致问题的假设清单、为每个假设设计最小验证方案、验证后再实施修复。这个流程看着简单但执行起来对AI的约束力非常强。以前我问“这个功能怎么不工作了”AI会直接给一段修改建议有时候还配上“你试试这样改”。用了debugging技能之后它会反过来问我这个bug是必现还是偶发有没有报错堆栈最近改过什么相关代码我先自己复现一下。有一说一这个转变对开发者来说体验很微妙。一开始你会觉得“我是让你解决问题你怎么老问我问题”。但用久了就明白这是在逼你把问题描述清楚。就像你去医院医生先问诊而不是直接开刀。特别是那些偶现bug你连稳定复现步骤都不给AI它怎么可能定位准确。2.2 test-driven-development逼AI先写测试再写代码test-driven-development技能简称TDD是我一开始最抗拒、后来越用越香的一个。它的核心是红绿重构循环先写一个会失败的测试跑一遍确认它是红的然后用最小代码改动让它变绿最后重构优化。在Java项目里这套流程其实特别合适。Java有JUnit、AssertJ这套成熟的测试生态跑测试也很快。但以前的AI编程工具是“代码导向”的你让它实现一个功能它直接给你写实现代码测试可能连提都不提。用了TDD技能后AI会先跟我确认这个方法的预期行为是什么边界条件怎么处理然后它会先写测试再写实现。这里我想重点说一下为什么这个对Java项目格外有价值。Java是编译型语言改完代码要重新编译、部署、跑测试周期比Python、JavaScript长得多。如果AI直接写实现代码很可能写了个能编译但逻辑错的方案你要反复编译验证。而先写测试等于先把期望行为固化成可执行的断言再用最快路径实现。虽然前期多了一步但总体验证时间反而少很多尤其对老项目特别友好。2.3 planning与scoping动手之前先交方案planning和scoping这两个技能解决的是同一个问题的两个层面任务太大怎么办。我见过太多人一上来就丢给AI一个巨型需求比如“把这个订单模块改成微服务”然后AI硬着头皮开始写代码写到一半发现前后矛盾只能推翻重来。superpowers的planning技能会让AI在动手前先产出一份方案文档内容包括任务拆解、依赖关系、风险点、实施顺序。它不急着写代码而是先跟你对齐思路。每完成一个阶段它会回到计划里更新进度保证整个任务在可控范围内推进。scoping技能则更偏“任务拆分”它会把一个大需求拆成一个个独立的、可验证的小任务。每个小任务都遵循“实现-测试-提交”的完整闭环。我在一个支付接口改造项目里试过原来AI经常改到一半告诉我它把前面的逻辑忘了用了scoping之后每个小模块独立提交上下文压力小了很多出错率明显下降。2.4 code-review让AI自己审自己的代码code-review技能是在代码改完之后触发的。它让AI切换视角从“写代码的人”变成“审查代码的人”以diff为单位审查改动检查逻辑漏洞、边界条件、并发安全隐患、命名规范等问题。这个技能最有意思的地方在于它强制AI输出审查意见而不是直接修改。也就是说AI会把问题列给你告诉你哪里可能出问题、为什么是问题、建议怎么改但最终改不改、怎么改由你决定。这个体验非常接近真实代码评审。我给AI试过一次它审视自己刚改完的一段缓存代码指出存在并发下重复加载的风险建议加锁或改用原子操作。这个建议在review场景下很有价值因为人很容易对AI刚写的代码放松警惕。2.5 对Java开发者的特殊价值说回热搜词里的“superpowers java”。Java项目可能是最适合superpowers的土壤之一原因有三点第一Java项目普遍历史包袱重。我见过的很多Java服务代码里有大量遗留逻辑和隐式约定。AI直接改代码的风险很高它可能只看到眼前这段逻辑没意识到这背后还有其他模块在依赖。superpowers里的scoping和planning流程能在一定程度上强迫AI先了解全貌。第二Java的类型系统和异常体系复杂。空指针、类型转换、并发问题、Spring Bean初始化顺序问题这些bug几乎每个Java开发者都遇到过。这些问题的共同规律是不能靠肉眼和经验硬猜需要系统化排查。而debugging技能恰好就是干这个的。第三Java生态的测试工具成熟。JUnit与Mockito的普及让TDD流程在Java里落地的成本很低。superpowers的TDD技能几乎是为这种“有成熟单测框架”的语言量身定做的。3. 安装与接入Claude Code、Codex、Workbuddy三种玩法3.1 Claude Code下安装最省事如果你是Claude Code用户安装最直接。Claude Code启动时会自动扫描本机的skills目录superpowers项目正好利用了这一点。我当时的做法是先把项目clone到本地然后把它里面的skills目录下的内容放到Claude Code的skills目录里。具体路径一般是~/.claude/skills/。打开终端执行git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowersclones之后我会建议你把项目里的skills子目录里的内容统一放到~/.claude/skills/下确保每个skill都是独立可识别的一个子目录。实际操作时每个人环境不一样如果你的Claude Code安装路径不同需要自己找到对应的skills目录位置。装完以后重启Claude Code在对话里直接问“你现在有哪些skills可以用”或者输入斜杠命令列表如果能看见superpowers相关的技能就说明加载成功了。这一步建议一定要做很多人以为clone完就生效了其实很多情况下Claude Code启动时根本没扫到对应目录。3.2 Codex下接入热词codex superpowers的出处最近“codex superpowers”这个热搜词热度不低说明不少人想让Codex也获得同款工作流能力。Codex虽然不像Claude Code那样原生内置skills扫描机制但它的工作目录里支持AGENTS.md之类的说明文件这套机制同样可以用来引导AI遵循superpowers的流程。我在Codex里接入的做法是先把superpowers仓库clone到一个固定目录比如~/superpowers然后在Codex项目的AGENTS.md里明确写一段说明告诉它在遇到bug、写测试、做规划等场景时先去对应的SKILL.md里读取工作流程严格按里面的步骤执行。# 工作流约定 - 遇到bug时先读取 ~/superpowers/skills/debugging/SKILL.md按其中的步骤排查。 - 实现新功能时先读取 ~/superpowers/skills/test-driven-development/SKILL.md先写测试再实现。 - 任务复杂时先读取 ~/superpowers/skills/planning/SKILL.md产出实施计划再动手。需要承认这种接入方式没有Claude Code那样“原生态”AI遵守流程的严格度会打折扣。但实测下来Codex在读到明确指令后确实会在相关场景主动加载skill内容整体行为模式有可见改善。如果你对裁剪要求高也可以直接把SKILL.md里的步骤精简成你自己的AGENTS.md规则。3.3 Workbuddy等工具的接入方式很多人搜“worbuddy 怎么用 superpowers”这里应该指的是Workbuddy。它是一款挺有可玩性的终端AI编程Agent支持自定义slash command这给接入superpowers留了很灵活的口子。Workbuddy里最重要的概念是命令目录它支持用户自定义Markdown格式的指令文件。你需要做的是把superpowers的每个skill映射成Workbuddy的一个自定义命令。常见做法是把核心的SKILL.md软链到Workbuddy的命令目录里这样你在对话中输入对应命令时它就能读取这个流程文件并按步骤执行。ln -s ~/superpowers/skills/debugging/SKILL.md ~/.workbuddy/commands/debugging.md ln -s ~/superpowers/skills/test-driven-development/SKILL.md ~/.workbuddy/commands/tdd.md用这种软链方式的好处是superpowers更新时你不需要重新复制文件Workbuddy读取到的永远是最新版本。坏处是如果你不了解它命令目录的机制遇到加载失败会一头雾水。要注意不同工具的配置路径可能不完全一样具体命令目录以你自己的安装路径为准。3.4 验证技能是否被成功加载装好不等于能用我见过太多人装上以后没验证然后在真正需要的时候发现AI根本没按流程走。验证其实很简单就两招第一招直接问AI“你现在掌握了哪些技能”让它列出来。如果能说出superpowers相关技能并且能描述出大致流程说明已经加载成功。第二招给它一个真实bug场景观察它的第一反应。如果它开始问你要复现步骤、看git提交记录而不是直接给修改方案说明debugging技能已经生效。如果验证后发现没生效先别急着怀疑项目有问题。九成情况是路径不对或者工具启动时扫描目录时没有包含你的skills目录。逐一检查路径大小写、目录层级、是否需要重启进程基本都能解决。剩下的情况我会在后面常见问题里讲。4. 实战演练用superpowers排查一个Java空指针问题4.1 场景还原与初始对话说一个我实际遇到的案例。上个月我负责的一个订单服务出现了偶发空指针异常日志里只看到NPE但不知道具体哪一行。项目是典型的Spring Boot MyBatis结构代码量不小全靠肉眼翻根本不现实。以前这种情况我都是自己花半天时间排查这次我决定让superpowers的debugging技能跑一遍完整流程。一开始我并没有直接说“用debugging技能”只是自然地把异常堆栈发给了Claude Code然后说“偶尔会报这个错帮我查一下”。让我很意外的是AI没有直接给出“可能原因”列表而是按debugging流程发出了三连问这个异常是必现还是偶发复现频率大概多少最近一次出现前有没有发过版本或改过配置我当时还觉得它有点“不干脆”但想了想这确实是我自己排查时本该先确认的信息。于是乎我把现象描述补齐偶发、高频时更容易出现、最近的版本里改过库存扣减逻辑。然后我提供了一个关键线索只有特定商品ID会出现这个错误。4.2 排障过程中的技能切换AI拿到这些信息后开始按debugging技能的规定动作推进。它先让我提供了相关的堆栈文件和最近一次改动的git diff特别注意了库存扣减逻辑相关的代码改动。在仔细读完diff之后它列出三个假设第一个是缓存空值导致的NPE第二个是数据库查询结果为空后续逻辑没做空值判断第三个是并发下出现的脏读问题。这个过程以前在普通对话里几乎不可能出现。以前的AI会直接说“可能是缓存问题你加个空判断试试”不给假设清单也不给验证优先级。而现在它把假设列出来之后主动进入了TDD技能模式建议我给这段扣减逻辑补一个测试传入一个不存在的商品ID观察是否复现同样的NPE路径。实际执行下来非常高效。我根据它的建议写了一个触发用例跑了两次稳定复现了同一个NPE位置定位到问题出在商品价格读取之后直接做乘法读取到的值在特定条件下是null。整个排查过程从开始的漫无目的变成了一次有明确假设和验证步骤的定位工作。4.3 复盘哪些环节是“人”在起作用这次实战之后我做了个简单复盘superpowers在这次排查里的价值是什么它没有提供什么神秘智能而是强制AI遵循了一套本来就应该遵守的排查流程。比如“先看最近改动再动手”这完全是高效工程师的本能习惯AI靠提示词未必记得住但靠skill文件就能稳定执行。再比如“用测试去验证假设而不是直接改”这个在以前得靠你自己盯着才靠谱现在成了流程的一部分。但要说完全不需要人那也不现实。整个过程中我提供了“特定商品ID才出现”这个关键线索这个线索不在任何日志里只有对业务熟悉的人才给得出来。所以我的结论是superpowers不是替代你做判断而是把AI的“执行下限”拉高让它在你的判断基础上跑出更稳定的结果。5. 常见问题与避坑清单5.1 症状与对策对照表我把自己和身边人用superpowers时遇到过的问题整理成了一张表先看症状再找对策能省不少时间。症状可能原因对策AI完全不提skill行为跟没装一样技能目录没被正确扫描检查目录路径重启工具进程确认技能文件结构完整技能加载了但AI不严格遵循对AI的指令约束力不够在项目AGENTS.md或规则文件中显式声明“遇到对应场景必须先读取SKILL.md”对话上下文很快被耗尽skill里的流程步骤把上下文占满了控制任务粒度先做scoping拆小任务不要把整个项目文件全丢进上下文每次修bug都要走全流程太重技能组合配置过宽裁剪技能只保留debugging和scoping必要时关掉TDDclone项目时网络很慢或失败网络波动多次重试或改用镜像源下载不要焦虑修改了SKILL.md后不生效工具缓存了旧版本重启工具进程必要时清除工具缓存目录5.2 几条独家使用技巧第一个技巧是“显式点名调用”。虽然superpowers设计的是AI自主选择技能但实际使用中显式指定往往效果更稳。在对话里明确说“用debugging技能处理这个问题”比让AI自己决定要可靠得多。尤其是任务描述比较模糊的时候AI的自主选择可能会“跑偏”。第二个技巧是“给技能排序”。superpowers的技能很多但没必要全部启用。我这个习惯持续到现在日常只保留debugging、test-driven-development、scoping三个核心技能。planning只在大任务里临时启用。技能开太多AI反而会因为流程选择困难而行为不可控这跟人一样方法论太多等于没有方法论。第三个技巧是“fork它改造成自己的”这也是最容易被忽视的一点。superpowers本质是Markdown文件完全可以改成符合你自己团队习惯的版本。比如我在工作里就把debugging的SKILL.md里加了一条“必须先问出复现步骤再进入下一步”。自己维护一份规则文件比原样使用更能融入团队现有的开发规范。第四个技巧是关于“关系维护”的把MCP外部工具和superpowers分开理解。MCP解决的是“AI能访问什么”superpowers解决的是“AI该怎么做”。不要指望它能替代数据库查询或浏览器操作它的任务只有一个就是把AI的工作方式拉到及格线以上。6. 用了一段时间之后superpowers对我开发方式的影响说实话我一开始对这类“技能包”是持怀疑态度的总觉得给AI加规则是件很不靠谱的事毕竟它就是个概率模型你写再详细的步骤它也未必照做。但用完这一段时间之后我的看法变了。它的效果不是让AI每次100%按流程走而是把“遵守流程”这件事从偶然变成常态。一个很直观的对比以前我用AI改代码上线后心理总有一丝不踏实因为它改起来太轻松了反而让人不放心。现在走了debugging、TDD这套流程之后它改完代码我是真想给它做个code review再合入。这个转变其实说明一个问题让我放心的不是AI变聪明了而是AI的行为变规范了。规则的约束力感知上比能力本身更重要。如果你想开始尝试我的建议很简单先只启用debugging一个技能找一个真实的、困扰过你的bug走一遍流程。感受一下AI从“直接给方案”变成“先问我要复现步骤”的那个过程然后你再决定要不要把TDD、planning这些技能也加进工作流。最后分享一个小技巧把superpowers的repo更新列入日常习惯隔两周pull一次新版本。这个项目迭代很活跃社区会往里加新的技能和工作流改进保持更新才能吃到最新的优化。当然如果你fork过并做了自己的定制记得在pull前先确认有没有冲突。