最近圈子里聊AI编程绕不开一个词superpowers。它不是某个新语言也不是某个新模型而是一套可以装进Claude Code这类AI编码助手的“技能包”。我第一次听说时以为是营销噱头直到自己把一个需求丢进去发现AI居然先给我列了一页计划、反问了我三个问题才动手写代码——那一刻我就知道这东西跟普通“多塞点prompt”的路子完全不一样。这套项目目前社区热度非常高围绕它的安装、使用教程、如何和Codex、Java项目配合讨论一直没停过。我自己的感受是superpowers解决了一个特别真实的问题——现在的AI模型能力不差但行为太随机。同一个问题换个说法结果可能天差地别。superpowers干的不是提升模型智商而是给AI套上一套“专家级工作流程”让它像成熟工程师一样先想清楚、再拆解、再动手、再自检。这篇文章不打算照着README念一遍而是把我从安装到日常使用的完整经验、踩过的坑、以及对它设计逻辑的理解一起写出来。适合谁看正在用Claude Code觉得“AI写代码不够稳”的人在Java、Go、Python等项目里想把TDD和代码审查规范化的团队以及所有好奇“给AI设定工作流”这件事到底怎么落地的人。1. superpowers到底是什么一套给AI编码助手的“工作流程外挂”1.1 一门“行为科学”而非一堆新API很多AI增强工具的思路是“给模型加工具”加个浏览器、加个终端、加个向量数据库能力感觉就上去了。superpowers不是这条路。它的项目作者是Perl社区老将Jesse Vincent他对AI编程的观察很直接模型能力早就够用了真正不可控的是行为。让AI“写个排序算法”它写得又快又好但让它“把这个模块重构一下并保证测试通过”它就容易跑偏——要么直接开干不确认需求要么改到一半忘记验证要么一口气改太多导致review无从下手。superpowers的本质是把人类软件工程里已经被验证过的流程写成一份一份结构化文档塞进AI的“技能库”。每个技能Skill都明确写了什么场景下触发、执行时按什么步骤来、每步要产出什么、做完要怎么自检。AI遇到任务时不是从零开始“自由发挥”而是像员工拿到了一份SOP按流程推进。这套东西最开始是给Claude Code做的采用的就是Claude Code的Skills机制。后来因为方法论太扎实社区里不少人尝试移植到Codex、Cursor等工具里甚至有人专门问它在Java项目上怎么用。这个后面我会细说但核心结论先放在这里superpowers跟语言无关跟框架无关它约束的是行为不是技术栈。1.2 为什么是“技能”跟普通Prompt的本质区别你可能会想这些流程不就是一段写得比较长的prompt吗我自己把“先规划再动手”写进系统提示词不就行了我一开始也这么干试过之后发现完全不是一回事。普通prompt是把所有规则一次性堆给模型比如“你应该先理解需求、再列计划、再写测试、再实现、再重构”。问题在于模型不会自动判断“现在该用哪条规则”。你给它30条规则它的注意力会被稀释遇到简单任务也非要走完整流程遇到复杂任务又不知道该先套哪条。而且prompt一旦写长跟随率急剧下降模型经常写着写着就“忘了”前面的约束。superpowers的机制是按需触发。技能文件里有“when to use”和“how to use”模型读完用户请求后会在自己的技能库里检索匹配项然后把对应技能的内容拉进上下文。我举个例子如果我说“帮我debug一下这个报错”它会去加载Debugging技能而不是去加载TDD技能。这种“场景化加载”比“把所有规则一次性塞进去”要稳定得多也很像人类处理问题的方式——你修水管的时候不会把电工手册也翻出来。另外一个很聪明的设计技能不是只给AI看的规则它还是人和AI之间的“共同上下文”。比如Planning技能生成一份计划文件AI和开发者看的是同一份文档Code Review技能输出结构化评审意见开发者可以拿来直接粘贴到MR评论区。这就让AI的工作过程变得可审查、可追溯而不是神秘地“它自己就把活干了”。2. 核心技能拆解AI“超能力”到底强在哪2.1 测试驱动开发先写会失败的测试再写实现TDD这个技能算是superpowers里含金量最高的一个。平时你让AI“给这个函数补个单元测试”它大概率看一眼源码直接补一个用例测完就交差——这压根不算测试驱动开发或者说这叫“事后补测试”。superpowers的TDD技能会逼着AI走完整的红绿重构循环先澄清预期行为、列出边界条件、写一个注定失败的测试然后写最小实现让测试变绿最后再看要不要重构。听起来慢但实际用起来特别稳。我有一次让它给一个订单状态机写状态切换逻辑它第一步竟然是先问我“订单从待支付到已取消需要校验用户权限吗”“取消后库存要不要回滚”——这些问题直接决定了测试怎么写。普通AI不会问它默认你什么都想好了。如果答案不确定直接写出来的代码即使语法正确业务上也是错的。第1步明确行为预期写测试之前必须清晰。 第2步从最核心的业务规则开始写测试刻意让它先失败。 第3步写恰好能通过测试的最小实现绝不提前设计。 第4步跑绿后停下来审视是否该重构是否要补充异常路径测试。这套循环对AI特别有效因为它把“不确定”显式地暴露在测试失败里而不是藏在最后一大坨代码里。2.2 规划与任务拆解先有Plan才有代码Planning技能解决的是另一个问题AI面对大任务时容易“一口吃个胖子”。你让它“给项目加一个用户积分体系”它能一口气生成2000行代码中间没有任何确认节点。结果大概率方向偏了你还得从头review。superpowers的Planning技能会强制AI先产出计划文档内容包含目标定义、约束条件、涉及的技术模块、实施步骤、每步的风险点、验收标准。计划写完以后AI会主动停下来等你确认你同意后再进入实现阶段。我的经验是这个计划文档本身就是巨大的价值。有一次我让它给老项目加一个缓存层它写出来的计划里提醒我“现有查询散落在三个Repository里建议先统一查询入口再切缓存”这个点我完全没想到。等于是让AI帮你做了一次架构预演。很多“AI写的代码没法维护”的抱怨源头其实就是跳过了规划这一步。除了大规划superpowers还有subagent机制可以把拆解出来的子任务分给专业子代理去执行。比如摸清某个遗留模块的依赖关系这种活可以派一个只读的调研子代理不污染主对话的上下文。这一点对上下文管理简直是救命级的优化。2.3 调试、代码审查与重构让AI当“结对工程师”而不是代码生成器Debugging技能是我日常用得最多的。普通AI遇到报错习惯是“猜”——根据错误信息直接给一个修复方案改完就不管了。superpowers的Debugging技能会要求AI把自己当成一个怀疑论者先复现问题、读取完整的错误堆栈、形成2到3个假设、用排除法验证、找到根因后再改代码最后加一条回归测试防止复发。这套流程看着繁但遇到疑难Bug时效率奇高。我修过一个偶发性的并发问题AI不是直接贴synchronized而是让我开两个终端复现用日志确认竞态窗口最后定位到是懒加载单例在多线程下初始化了两次。如果真的直接“加锁了事”问题压根不会解决。Code Review技能则适合当“第二双眼睛”。它会按清单逐项审查可读性、边界条件、性能、安全隐患、测试覆盖度。输出是结构化评论不会直接改代码这很符合团队协作场景。我现在的习惯是每次合入代码前先让AI用这个技能审一遍再人工看明显能拦下不少低级错误。Refactoring技能和Code Review配合用专门处理“代码能跑但很臭”的情况。它强调小步重构每改一步就跑测试绝不顺手牵羊改无关逻辑。这个“不做无关改动”的自律说实话很多人类开发都做不到。3. 从安装到跑通完整实操流程与配置3.1 三种安装方式与适用场景先说个大前提superpowers官方主要面向Claude Code但核心技能文件本质是Markdown所以只要你的工具支持Skills机制理论上都能借鉴。我自己主用Claude Code所以下面以它为例。方式A通过插件市场安装最省事 在Claude Code对话框里输入以下两条命令/plugin marketplace add obra/superpowers /plugin install superpowerssuperpowers第一条命令把作者的仓库加进插件市场第二条直接安装。装完重启会话输入/superpowers就能看到技能列表。这种装法是全局生效的所有项目都能用。方式B项目级手动安装适合团队共享和离线环境 如果你的团队想统一技能版本或者公司内网不能访问GitHub可以手动clone然后放进项目目录git clone https://github.com/obra/superpowers.git mkdir -p .claude/skills cp -r superpowers/skills/* .claude/skills/然后把.claude/skills提交进Git仓库团队所有人clone项目后自动获得同一套技能。我比较推荐这种因为技能版本跟随项目走不会出现“我这里能用你那里不行”的割裂。方式C使用初始化工具 新版superpowers提供了CLI初始化器一键把技能和配置写入当前项目npx obra/superpowerslatest init这条命令会自动创建.claude/skills目录、写入全局配置、并输出一份使用说明。适合第一次接触、不想记命令的人。3.2 第一次使用从提问到产出装好以后怎么验证它真的生效直接问一句“你会哪些superpowers技能”如果AI开始逐条列技能名和适用场景说明加载成功了。如果回答“我不确定”“我不知道什么superpowers”八成是没装上或者路径不对。我建议第一次实战拿一个小功能练手。比如你有一个订单模块可以这样问“使用你的superpowers技能帮我在订单模块里加上超时自动关闭功能订单超过30分钟未支付自动置为已取消。”正常情况下AI会先加载Planning或TDD技能然后开始反问你需求细节。比如关闭动作要发通知吗取消后库存怎么处理这个“反问”就是技能起效的信号。如果它直接开始贴代码说明技能没触发需要停下来排查。真实会话里它通常会先把计划写入plans/目录下的Markdown文件等你确认后再进入TDD流程先写测试文件再在src/里做最小实现。如果你的AI工具配置了自动运行测试命令它还会自己跑测试并汇报结果而不是把“运行mvn test”这句话甩给你。3.3 进阶配置让“超能力”适应你的项目默认技能是通用的但每个项目的测试命令、代码规范、目录结构都不一样。我强烈建议你花半小时做一次自定义配置效果会翻倍。技能文件本质是Markdown结构大致是frontmatter元信息包含name、description、when to use 正文how to use、步骤、检查表。以TDD技能为例你可以在正文里加上你项目的测试命令--- name: tdd description: 测试驱动开发 when_to_use: 需要为新增功能编写测试或修复缺陷时 --- 1. 与用户确认预期行为 2. 编写失败测试使用 mvn test -DtestOrderServiceTest 运行 3. 实现最小代码逻辑 4. 运行命令确认测试通过 5. 检查代码重复与设计问题重构并重新跑测试如果你想给团队加一个“前端组件验收规范”技能也可以自己新建一个目录写一个SKILL.md扔进.claude/skills/即可。这其实把团队的研发规范给“代码化”了——后来我才反应过来这可能是superpowers最值钱的地方它让组织流程能跟着代码走。4. 常见问题与排查技巧实录4.1 技能不生效先怀疑安装路径和上下文最常被问的就是“装了superpowers但AI根本不按技能来”。我见过的情况90%不是工具没装好而是技能文件没有被AI加载。排查顺序先看.claude/skills目录结构对不对每个技能应该是一个独立子目录里面必须有.md文件且文件名要规范其次是确认技能不是空文件有些用户是只建了目录没复制内容。另一个隐蔽问题同一套prompt里同时要求AI“尽量简短直接”又要求它“严格执行superpowers流程”这种互相矛盾的指令会把AI搞蒙。技能机制是触发式的你说“简单帮我改个变量名”它就不会去走TDD全流程这是正常的不用强求每个请求都走完整流程。还有一个反直觉的坑技能多了之后AI可能加载了不相干的技能。我实际遇到过一次让AI“修一下Bug”它居然同时加载了Code Review技能。后来发现是因为技能描述写得不够清晰导致模型匹配错误。解决办法是修改技能的when_to_use字段把触发条件写得极其具体。4.2 上下文膨胀与成本失控Token消耗比想象中快superpowers的规划、测试、审查流程都会额外消耗Token尤其是大项目里计划文档加上测试代码很容易把上下文塞满。我第一个月账单涨了快一倍吓了一跳。后来总结出几条经验小任务不要上技能一个脚本改个变量这种事直接用普通对话复杂任务分阶段规划确认后可以先开新会话再继续实现用--resume或手动摘要传递上下文子代理技能该用就用它基本不占主对话上下文很划算。另外一个经验是把技能文件的正文写得紧凑。技能文档不是给人看的散文是给AI执行的指令废话越多模型越容易跑偏。我自己维护的团队自定义技能每条指令都尽量控制在20字以内实测跟随率大幅提升。4.3 语言和框架适配Java项目到底能不能用每次有人问“superpowers支持Java吗”我都得说支持但它默认给的TDD命令不是Java的。AI默认假设你在Python或者Node环境会把测试命令写成pytest或npm test。在Java项目里你需要像上面第3.3节那样显式告诉它“用Maven执行测试命令是mvn test”甚至要写清楚测试类命名规范——因为AI可能把测试文件建在奇怪的位置导致Maven根本扫不到。我第一次在Spring Boot项目里用就翻过车AI写了个失败的测试然后找不到测试文件自己在那瞎绕。排查了半天发现它把测试文件扔到了src/main/java下面还按Python的习惯命名。所以强烈建议Java、Go、C这类强构建工具的项目先把技能里的“运行测试”和“测试文件位置”两段改好再让AI开工。还有一个常见误解以为superpowers会给项目装一堆依赖。其实它完全不动你的构建文件不引入任何第三方库它只是改变AI接下来的行为方式。对现有项目可以说非常友好。4.4 速查表我踩过的问题汇总问题现象可能原因解决办法AI不认识superpowers插件未安装或版本过旧重新执行/plugin install superpowerssuperpowers技能加载了但不按流程走prompt指令冲突或模型上下文太挤清空上下文开新会话去掉冲突指令TDD测试命令报错技能里的命令是Python/Node风格在SKILL.md中改成Maven/Gradle命令测试文件位置不对AI不知道你的构建结构在技能里写明测试目录Token消耗突然变大每次任务都走完整流程区分简单/复杂任务小任务不走技能生成的Plan太啰嗦技能描述里没限定篇幅修改技能文件要求“不超过10条”等约束在Cursor/Codex里不生效这些工具不是官方平台手动把技能文件导入对应工具的skills目录5. 一点个人体会别把它当“魔法”当“团队规范”用superpowers两个多月我最真实的感受是AI没有变得“更聪明”但它变得“有纪律”了。以前它像同事指南没读就上手的新人能力很强但方向全看发挥现在像目标感明确、每一步都让你知道它在干嘛的结对工程师虽然偶尔还是需要你纠正方向但至少错误都发生在可监控的环节里。有一个变化特别明显现在AI生成的代码测试覆盖率明显上去了review成本反而降了。因为TDD流程逼着它在写实现之前先把行为定义清楚很多bug在“写失败测试”那一步就被修正了——需求理解不到位时测试根本写不出来。这一点是我一开始没想到的也是我觉得它最值钱的地方。最后分享一个小技巧你可以把superpowers当成团队经验的“沉淀容器”。团队里那些“新人必犯的错误”“这个模块的特殊约定”写成自定义技能丢进.claude/skills从此AI会自动遵守不用你再一遍遍唠叨。我后来把团队代码规范、第三方API的易错点、发布前检查清单都做成了技能文件带新人省了特别多口舌。这套玩法远比“让AI写代码”本身更有长期价值。
