★ FEATURED ARTICLE 做AI辅助开发这两年我最大的一点体会就是工具本身的差异其实没有那么大真正拉开效率差距的是你能不能把AI从“你说一句它答一句”的聊天模式切换成“自己立项、自己拆解、自己验证”的协作模式。superpowers这个技能包体系本质上就是在解决这个问题。它不是一个单独的工具而是一套装进Claude Code也兼容Codex、其他MCP客户端里的技能扩展集让AI助手获得类似TDD开发、系统规划、代码审查、深度研究这些“超能力”。这篇文章就把我实际使用这套技能包的经验、安装配置、核心模块拆解、整个项目生命周期里的实操记录以及踩过的坑都整理出来给正在折腾superpowers安装和使用的同学一份可以直接参考的完整指南。1. 先弄清superpowers在设计上到底解决了什么问题1.1 为什么普通的“对话式编程”总会让人感觉差口气先讲一个我们几乎都会遇到的场景。你用Claude Code或者其他AI编程工具丢给它一个需求“帮我写一个用户注册接口”。它确实会写而且写出来的代码看着挺像回事。但接下来你会陷入一个循环你得不断补上下文“这里参数校验不够”“这里少一个事务”“这里错误处理不对”“这个接口没有考虑并发”……一轮轮聊下去AI改一点你再发现问题它再改一点。到最后代码是能跑了但你心里很清楚这个质量是靠你“人肉陪跑”盯出来的不是AI自己规划和校验出来的。这里面的核心矛盾在于AI本身是“被动响应”的你给什么指令它就干什么活它不会主动去思考“这个需求背后还有哪些边界条件”“这个改动会影响哪些模块”“我写完以后应该怎么验证”。而superpowers做的事情就是把那些资深开发者脑子里的隐性工作流——先想清楚再做、小步测试驱动、事后审查校验——用一套结构化的技能文件固化下来让AI在执行任务的时候主动走这些流程。这个思路其实和设计模式很类似你不需要每次从零开始想怎么干活而是把已经被验证过的“套路”沉淀出来在合适的场景里套用。superpowers把所有技能模块拆成一份份Markdown格式的“技能文件”每个技能文件定义了触发条件、执行步骤、输出要求、质量底线。当你在对话中触发某个技能时Claude Code会读取这份文件按里面的流程来执行而不是自由发挥。1.2 它的核心设计理念把“技能”变成可加载、可复用、可二次开发的工作流我最早接触superpowers的时候其实是被它的目录结构吸引的。它的项目文件组织方式非常清晰——每一个技能就是一个独立的目录里面有SKILL.md作为入口文件里面写明这个技能的用途、激活条件、执行流程如果需要辅助材料还会有references子目录放补充知识如果涉及代码模板会有scripts目录放具体实现。这种设计带来的直接好处是你可以按项目需求挑着加载技能而不是所有功能一锅端。比如我这次做Java项目只需要加载Boss模式、TDD、代码审查这几个核心技能就够了下次做前端重构再加载架构规划相关的技能。不需要的干不加载加载的全是当前项目用得上的这样AI上下文窗口的压力也会小很多。更重要的是这套体系是开放的。你在社区里能找到很多第三方编写的技能文件也可以自己动手写一个专属技能。只要你理解了SKILL.md的YAML frontmatter格式和正文Markdown的编写方式就能把你自己团队里的编码规范、审查清单、发布流程全部固化成一个技能文件。这一点我后面专门有一章展开讲因为这可以说是superpowers最有价值的扩展点。2. 安装与初始化从零到可用的完整配置2.1 安装前的环境准备哪些基础条件要先满足先说结论想跑通superpowers前期环境条件就三个一个能运行Claude Code的环境或者兼容的AI编程工具、Git、以及Node.js环境。很多人会忽略Git这一步直接下载压缩包解压结果后续因为缺少.git元数据导致superpowers的自动更新机制失效。这不是完全不能用但你每次拉取新版本都只能手动覆盖比较麻烦。Claude Code的安装我这里就不展开了官方渠道装好以后在终端里执行claude确认能进入交互界面就行。Node.js主要是用来跑那些配套的辅助脚本比如技能检查、测试辅助这类的工具建议装LTS版本我用的是Node 20没遇到什么兼容问题。还有一个容易踩的坑因为superpowers本质上是一套需要被Claude Code读取外部文件的技能包安装前要确认你的Claude Code版本支持Plugins或External Skills特性。老版本没有这个能力装完以后你会发现技能全部不生效但终端里也没有任何报错非常容易排查半天找不到原因。我的建议是先用claude --version确认版本再去GitHub仓库的README里面看支持的最低版本要求两边对上了再往下走。2.2 5分钟快速安装一份可直接抄的步骤清单假设你已经按照官方文档把Claude Code装好了下面就是一套我自己验证过很多次的标准安装流程。每条命令都按顺序执行中间不要跳# 1. 创建插件的安装目录 mkdir -p ~/.claude/plugins # 2. 从GitHub克隆superpowers仓库到本地 cd ~/.claude/plugins git clone https://github.com/obra/superpowers.git # 3. 设置一个环境变量让Claude Code能识别这个插件位置 export CLAUDE_PLUGIN_ROOT~/.claude/plugins如果是首次安装第3步这个环境变量可以临时在命令行里export但更推荐把它写进shell的配置文件比如~/.zshrc或~/.bashrc避免每次开新终端都要重新设置。你还可以把它写进Claude Code的启动配置文件里这样每次启动Claude Code就会自动加载superpowers的技能集合。装好之后的关键一步是验证。你需要检查两件事第一目录下面是不是出现了完整的skills文件夹里面能看到boss、tdd、code-review这些子目录第二在Claude Code里输入“/plugin”之类的命令看它能不能扫描到这个插件并列出技能清单。第一次加载通常会提示“你希望如何配置这个插件”按提示选择允许权限就行。2.3 验证安装结果与权限设置很多第一次用的人栽在权限上。superpowers里的技能文件要能正常工作Claude Code需要具备对你的项目目录的读写权限以及执行Bash命令的权限。如果你在配置的时候选择了“不授予bash权限”那么TDD技能里面那些自动跑测试的命令、代码审查技能里面那些自动检索文件的命令全部都会罢工。而且罢工的姿势很隐蔽——AI还是会“假装执行”给你看告诉你它跑了测试实际上什么都没发生。我踩过一次就是这个问题。当时我用TDD技能写一个Python排序函数AI告诉我“测试通过”但项目目录里根本没有生成测试文件。后来一查就是权限配置里没有开启bash执行权限。这里给一个自查方法直接在Claude Code里执行一句简单的命令比如pwd如果返回了当前目录路径说明bash权限没问题如果提示没有权限那就需要在设置里开启。还有一个小细节很多教程不会提superpowers的技能文件如果放在同步盘比如iCloud、坚果云、Dropbox里偶尔会因为同步延迟导致Claude Code读到的是旧版文件症状是你的AI行为不稳定有时候有超能力有时候没有。这个情况排查起来非常烦人我最后是把技能包移到本地非同步目录才彻底解决的。3. 核心技能模块拆解Boss模式、TDD与代码审查3.1 Boss模式需求到架构的一次性落盘Boss模式是superpowers里我使用频率最高的一个技能也是我认为整个技能包里最能体现“工作流思维”的模块。它的核心定位是当你给AI一个相对模糊的目标时它不再立即开始写代码而是先进入一个“需求澄清—方案设计—拆解计划”的模式并且把这个过程固化成项目文档。触发方式很简单你在对话里直接说“我要用Boss模式处理XXX需求”然后把你手上的原始描述贴给它。它接下来会做的事情大致是先列出它对这个需求的理解然后针对理解向你提几个关键问题比如“这个功能的用户是谁”“有没有性能指标约束”“当前代码库里有没有可复用的模块”——这些问题都是Boss技能文件里预设好的提问模板是很成熟的澄清框架。等需求边界确认以后它会生成一份项目计划文档详细到每个阶段要做什么、接口怎么设计、数据模型长什么样。这份文档会自动写入你项目目录下的一个固定位置之后你随时可以要求它“读取计划并继续执行”它就知道自己当下处于哪一个阶段该干什么不会做一步忘一步。我实际用下来的感受是Boss模式最大的价值不是帮你写代码而是帮你把不可见的“思考过程”变成了可见的文档。尤其当你接手一个别人留下的老项目一份按Boss模式生成的计划文档比任何口头交接都好用。3.2 严格TDD流程先红后绿再重构如果你对“测试驱动开发”这套方法论只是听说过、但一直没实践起来那superpowers的TDD技能可能是你上手TDD的最好机会。因为它不是跟你讲道理而是把事情拆成了可执行的固定流程AI会严格按“红灯—绿灯—重构”这个节奏来推进。简单来说当你触发TDD技能并提出一个功能需求AI会依次做这些事先根据需求编写一个失败的小测试红灯运行测试确认它确实因为“功能不存在”而失败然后写满足这个测试的最小实现代码绿灯再运行测试确认通过紧接着进入重构阶段看看有没有可以消除的重复代码有没有可以调整的结构每做一次重构就重新跑一遍测试确保功能不退化。这个流程看起来很简单难点在于“小步迭代”。人写代码的时候很容易贪多一上来就想把完整功能整个写完测试也写得像集成测试。而TDD技能的好处是它天生就是“一次只走一步”的它会维护一个待办清单每完成一个测试就勾掉一项最后你看到的是一串非常清晰的提交记录每一步都有对应测试护航。在Java项目里这个优势尤其明显。Java本身有完善的测试生态JUnit、AssertJ用起来很顺手superpowers的TDD技能会指导AI逐步生成这些测试代码并且每次运行都用Maven或Gradle的测试命令来验证。我后面实战部分会具体展示这个过程。3.3 系统化代码审查不止是挑毛病代码审查这个技能很多人会误以为它就是让AI挑错、找bug。真正用起来你会发现自己还是想简单了。它做的不是漫无目的地“看看哪段代码不顺眼”而是按照一份结构化的审查清单逐项过先梳理业务逻辑是否清晰、边界条件是否处理完整再查安全性、性能、可维护性逐条输出发现的问题并按严重程度分级。更关键的是它不只是指出问题还会给出修改建议。而且它的审查过程是基于搜索和全局分析的不只是盯着你贴给它的那几行代码看它会自己去检索相关函数调用、依赖关系然后给出“这个问题存在于第几行影响范围是什么建议怎么改”这种级别的结论。在重构老代码的时候这一步相当于多了一个资深同事帮你过代码。触发审查也很灵活。你可以说“审查一下当前分支最近3次提交的代码”也可以直接把某段代码让它看。它会先加载自己的审查技能文件然后按里面预设的步骤执行不会因为你说“这段代码很重要帮我看看”就只盯着你指定的一段看。4. 实战案例用superpowers推进一个Java项目4.1 从需求描述开始跑通完整生命周期为了把上面这些技能串起来讲清楚我基于实际经验准备了一个Java项目的练手案例。需求非常简单写一个支持增删改查的待办事项管理接口数据存内存就行不接数据库。这个需求足够小但足够把Boss模式、TDD、代码审查整个流程串一遍。我启动Claude Code后第一句话就是“用Boss模式帮我规划一个待办事项管理模块的需求。”然后它开始进入澄清阶段问我是否要区分优先级、是否需要状态流转、接口返回结构有没有偏好。这些其实都是我在规划阶段本来就要考虑的问题但以前我都是写代码写到一半才想起来现在它在动手前就替我把问题排了一遍。确认需求后它按照计划开始拆解。我观察到它创建一个项目计划文件写了模块划分——Controller层、Service层、Model层。关键的是里面还有一份待办清单TO-DO List列出了7个递进的小阶段定义数据模型、创建接口骨架、实现新增、实现查询列表、实现查询详情、实现删除、补充校验与测试。这个清单就是后续TDD执行的路线图。4.2 关键节点的操作记录与效果整个开发过程从头到尾都是TDD技能在推进。我截取几个关键节点说一说。第一个节点定义TodoItem模型。AI先根据需求写了一个失败测试这个测试会先引用一个还不存在的TodoItem类然后运行mvn test确认编译报错。这一步看着像“故意让测试挂掉”实际上是TDD里标准的“红灯”步骤目的就是让AI确认真实地存在测试文件且当前测试确实失败而不是瞎编一个“测过了”。第二个节点实现新增功能。AI再次写一个失败测试这次测试会调用一个尚未实现的addTodo方法确认失败。然后它写这个方法的实现简单到甚至有点“幼稚”——直接往一个列表里塞对象。接着重新跑Maven测试全绿。这一步我特别留意了它有没有真的去执行测试命令因为我前面踩过“假装执行”的坑结果这次它在终端日志里给出了真实的mvn test输出每个测试方法名都清晰可见。第三个节点实现查询列表。这个阶段和前一个类似但多了一个细节AI在处理“排序”需求时先写了测试确认列表返回顺序然后用流式操作实现了排序逻辑又一次运行测试验证。到这里我开始意识到TDD技能在Java生态里的落地是有内置“肌肉记忆”的它对JUnit的常见断言、AssertJ的流畅风格都很熟悉写出的测试不是生硬的模板代码而是带着真实业务语义的。4.3 经验哪些环节最省时间整个流程走完以后我最大的感受是superpowers最省时间的环节不是“写代码”本身而是“不用来回解释”。以前用普通对话式AI写这个模块我需要反复补充“接口返回格式要统一”“排序规则要讲清楚”“参数校验要到位”。这次用superpowers的Boss模式这些要求在澄清阶段就被一次性打入需求文档了后续所有代码和测试的生成都自动符合这些约束。第二个省时间的环节是“验证”它每一步都真的跑测试出错的代码在写出来的瞬间就被发现而不是等最后联调的时候爆一堆问题排查到怀疑人生。Java项目的编译运行本来就比动态语言慢有些开发者懒得每步跑测试觉得“反正最后再统一跑”。但TDD技能强制你每小步都验证反而帮你把出错的成本控制在最小。多出来的那几秒编译时间远小于你后来修一个隐蔽bug消耗的几小时。5. 常见问题与排查技巧实录5.1 技能文件不生效先查触发词和上下文命中用superpowers一段时间后最常见的状况是技能明明装了AI却不按技能走。我遇到过好几种触发失败的原因最隐蔽的一个是“触发词没对上”。每个技能文件的frontmatter里都定义了它的name和descriptionClaude Code匹配技能的机制是基于你的描述来决定是否加载对应技能文件的。如果你用的是自定义表达方式比如把TDD说成“写测试”而没有触发它description里的关键词那技能文件可能靠未被加载AI退回到普通对话模式。解决办法是在关键任务描述里带入技能名比如直接说“用TDD技能帮我实现这个功能”触发概率会高很多。还有一个容易忽略的因素是上下文长度。当你的对话轮次特别多、历史很长的时候Claude Code也可能会跳过技能加载步骤来节省上下文。如果发现AI行为明显“退化”了最简单有效的办法就是把历史清理一下开一个新会话开头直接引用项目计划文档路径让它加载对应技能。5.2 权限配置与多工具共存问题权限问题在第二节里提了一部分这里补充一个多工具共存场景。很多人的机器上装了不只一个AI编程工具Claude Code、Codex、Cursor都在用。superpowers的插件路径如果被多个工具共享需要注意这些工具对环境变量的读取规则可能不一样。可能会出现“明明在Claude Code里配好了环境变量但Claude Code的启动脚本里加载了另一个版本的路径”这种串配置问题。我的建议是给每个工具各自的插件目录不要图省事共享同一个。虽然多占一点磁盘空间但能避免很多诡异的“这个工具能用、那个工具不能用”的灵异事件。另外如果用了Codex还需要确认它读取技能文件的格式和Claude Code是兼容的有些技能文件里写的执行流程可能带了Claude Code特有的命令格式在Codex里跑会有兼容性问题需要手动调整。5.3 上下文过长与Token控制第二个问题里提到上下文过长会跳过技能加载其实它还会引发另一个问题技能流程执行到一半被系统提示“上下文长度超限”。尤其是Boss模式加TDD模式的组合如果项目需求比较复杂几轮澄清加上计划生成加上测试代码上下文消耗是非常快的。针对这个问题我的经验是把Boss模式的规划阶段和执行阶段拆成两个会话。前半段用Boss模式把需求文档和计划文档生成出来然后结束会话。新开会话后直接让它读取计划文档并执行下一步。这样每个会话的上下文压力都集中在当前阶段不会因为前面聊了50轮导致后续技能执行到一半突然失忆。还有一个技巧是手动控制技能生成内容的篇幅。有些技能文件允许你在执行时指定输出范围比如TDD时你可以要求“先只实现第一个待办项不要一口气做完全部”。你明确控制节奏后AI生成的内容量是可控的不会被一次性输出的长代码撑爆上下文。6. 扩展与二次开发动手写自己的技能包6.1 技能文件的结构SKILL.md到底长什么样superpowers之所以能流行起来很大一个原因是它把“AI提词固化”这件事的门槛降到了最低。一个技能本质上就是一个文件夹里面放一个SKILL.md主文件再加上你需要的references、scripts资源目录。理解这个结构你就能写自己的技能。SKILL.md的开头是三段式YAML frontmatter--- name: 技能名称 description: 当用户需要什么的时候使用这个技能 ---description非常关键因为这就是Claude Code判断“什么时候加载这个技能”的依据。描述写得越具体越能减少误触发和漏触发。比如写一个“当用户需要初始化一个符合团队规范的Python项目结构时”就比“创建Python项目”要有用得多——后者太宽泛AI会在很奇怪的场合也试图加载它反而干扰主任务。frontmatter下面是正文正文里要写清楚这个技能的执行步骤。不能只写“帮用户做好XXX”这种废话要拆成可执行的清单第一步做什么第二步做什么每一步的输出产出是什么。你甚至可以要求AI在执行过程中做“自我检查”比如“在结束后逐条对照你的输出是否满足以下验收条件”。6.2 一个自定义技能从0到1的示例我举一个自己写过的技能作为模板自动生成项目提交信息。这个技能解决的是我自己工作里的一个痛点——每次提交代码前整理提交信息都很痛苦写得不够规范又会被项目经理打回。我在技能文件里规定了一个标准的提交信息格式要求AI执行这些步骤查看当前分支的git diff统计、识别改动涉及的模块、按“类型-模块-摘要”的规则生成一条提交信息、检查生成的信息是否超过50个字符。这个技能的目录结构很简单就一个SKILL.md没有引用任何额外脚本。写完之后在对话里输入“用提交信息技能帮我生成这次提交的信息”它就会严格按这个流程来。使用新技能后第一周我明显感觉提交信息的规范度提高了八成。后面我又照着这个思路给团队写了一个“Code Review问题单生成”的技能把团队日常审查的检查项全部固化进去。这类技能并不复杂但带来的规范化收益是实实在在的。6.3 如何做个有用的技能需求、提示语、验收标准写技能容易写出有用的技能不容易。我在尝试写了几个废技能之后总结出三条经验分享给你。第一只写“重复发生且流程稳定”的任务。如果你的某个工作流程每次做的方式都不一样每次都要靠临场判断那它不适合被固化成技能。技能的价值在于一次写成、反复调用如果流程多变你写出来的技能要么经常触发失败要么生成的结果还要大量人工修改反而更费时间。第二把提示语写成“命令式清单”不要写“描述式愿景”。比如“要求AI检查代码中是否所有分支都有else处理”比“要求AI写出健壮的代码”有用得多。技能文件里的正文是执行指导不是面试官打分表要写得让AI看完知道你到底要它怎么操作。第三自己写技能一定要写验收清单。这个验收清单不是给别人看的是给AI在输出完成以后自查用的。比如我写提交信息技能就要求它生成完毕后逐条确认“类型标识是否在允许列表内”“摘要是否不超过50字符”“是否包含了影响模块说明”全部确认通过才把结果展示出来。有了这一步输出质量会稳健得多。写技能这件事说到底就是把你自己从“反复向AI解释”的重复劳动中解放出来。磨刀不误砍柴工花一个下午写一个好技能后面的每一个项目都能受益。最后再分享一个我自己的习惯每次用superpowers跑完一个项目我会顺手把那个项目的Boss计划文档留档。几个月后要维护或者扩展这个项目时翻出计划文档看看当时是怎么拆解的、哪些决策是因为什么原因做的一目了然。这套技能体系带给我最大的变化不是代码写得快了而是让AI辅助开发的整个过程变得有章法、可复盘。你不需要一次把所有技能都铺开先从Boss模式和TDD两个入手跑通一遍项目生命周期你自然会理解为什么这种“结构化工作流”能比单纯提高打字速度更有价值。
阅读完成 · 觉得有帮助？
