最先看到这个名字的时候我还以为又是一个炫技的 AI 框架superpowers超级能力。结果翻了一圈才知道它是 Claude Code 生态里非常火的一套技能包skills合集解决的是一个很朴素的问题——同一个模型为什么在不同人手里产出差距这么大答案往往不是模型变聪明了而是有人给它配了一套成熟的工作流程。这套流程就是 Superpowers。简单说它把资深工程师拆解需求、写计划、写测试、定位 Bug、做代码审查的行为固化成一个个 Claude 可以直接读取的技能文件。装完之后Claude 在动手写代码之前会先问清楚问题动工之前会先列计划边写边测提交之前还会自己审一遍 diff。这篇文章就围绕大家搜索最多的几件事展开Superpowers 具体怎么用、里面有哪些 skills、怎么把技能真正引入到自己的工作流里、以及从零开始安装的完整路径。1. Superpowers 是什么与其说是工具不如说是一套行为规范1.1 同样是 Claude Code为什么有人用得像大神我自己最早用 Claude Code 的时候体验是这样的让它改一个小功能它速度很快唰唰就改完了。但稍微复杂一点的需求比如重构某个模块同时保持对外接口不变它就开始自由发挥了——没有先问清楚约束条件没有检查调用方改完也不跑测试甚至有时候改到一半自己换了个实现方案。不是模型不聪明而是它缺少一种做事的章法。普通对话模式下模型的默认行为是你怎么说我怎么答给它一个含糊的需求它就会基于最可能的猜测直接动手。这在写 demo 的时候问题不大但在真实项目里就是灾难。Superpowers 想改变的就是这个默认行为。它通过一组预置的 skills让 Claude 在特定场景下切换到特定的工作模式进入调试状态时它不再东改一行西碰一下而是先复现、再缩小范围、再定位进入计划状态时它会把大目标拆成带验证条件的小步骤。这个项目最初来自一位资深的开发者名字是 obra。他把过去十几年做工程的经验浓缩成技能文件公开分享出来结果在 Claude Code 用户群里迅速火了起来。原因也很简单大家发现装上之后Claude 的输出风格明显变得更像一个有纪律的工程师而不是一个话痨的代码生成器。1.2 底层机制SKILL.md 如何把一个技能教给模型如果你翻过 Claude Code 的目录可能会见过一个叫 skills 的东西。Claude 的 Agent Skills 机制允许你把某种专业能力写成一个 Markdown 文件里面用自然语言详细描述什么情况下使用这个能力、用的时候要做什么、按什么顺序做、输出什么格式。模型在对话中会根据上下文自动加载合适的技能文件然后照着里面的指导来行动。Superpowers 就是建立在这样一个机制上的技能集合。它的每个技能都是独立的目录目录里通常有一个 SKILL.md 作为主说明书外加一些辅助文件比如 checklists检查清单、prompts提问模板、rules行为规则。这些文件不是在教模型新的知识而是在约束模型的行为顺序和思考方式。我打个比方同一个新人工程师你给他一份混乱的 bug 描述他大概率上来就改你给他一份标准的排障 SOP他可能就会先看复现路径、再查日志、再二分定位。模型也是一样它的知识都在那里缺的是操作手册。Superpowers 就是那套操作手册。1.3 哪些人适合用它哪些人可以先观望我用下来觉得这套东西最适合的是已经在用 Claude Code 做真实项目、但觉得输出不稳定的开发者。尤其是涉及多文件改动、重构、新增功能这类需要前后一致性的任务收益非常明显。如果你只是拿 Claude Code 写一次性脚本、跑点临时数据那 Superpowers 属于可用可不用的范畴因为短任务的随机性本来就无所谓。另外要提醒一点Superpowers 不是装上就变强的那种插件它需要你稍微配合它。比如它可能会在动手前多问你几个问题你如果每次都厌烦地跳过那它跟你原来的用法也没太大区别。愿意多花一分钟把需求和约束说清楚的人才能真正把这套东西的价值吃满。2. 安装与引入从想装到跑起来的完整链路2.1 安装前的环境检查先说环境。Superpowers 是 Claude Code 的插件所以前提是你已经装好了 Claude Code而且版本不能太老。技能机制和插件市场机制都是后来才加的如果你装的是几个月前的版本建议先升级到最新版再操作。另外它本身不依赖特定的操作系统macOS、Linux、Windows 的 WSL 都没问题。Node.js 环境一般也是需要的。因为 Claude Code 本身就是跑在 Node.js 上的你既然能用它说明 Node 环境已经就绪所以这一点通常不用额外折腾。真正容易被忽略的是权限Superpowers 需要往你的用户目录下写技能文件如果你的终端环境对权限卡得比较死比如某些公司锁了用户目录安装会卡在写文件的环节。2.2 通过 marketplace 安装的步骤我装的时候使用的是 Claude Code 的插件市场机制。整个过程两步走先添加 marketplace 源再安装插件本体。在 Claude Code 对话里输入/plugin marketplace add obra/superpowers-marketplace回车之后它会拉取市场信息。然后再输入/plugin install superpowerssuperpowers-marketplace装完之后比较稳妥的做法是退出当前会话重新打开 Claude Code。技能文件是在会话启动时加载的不重启的话可能识别不到。这里说一句这个工具的版本迭代非常快命令形式可能会变。如果你打开插件面板发现入口和我写的不一样别硬背命令直接去它的仓库看 README。README 通常会在最前面放最新的安装方式。2.3 装完之后先做三件事验证是否生效第一次装完我建议不要急着丢一个复杂任务给它而是先做三件小事。第一件新开一个会话直接问它你现在有哪些 skills 可用正常情况下它会列出一串技能名比如 brainstorming、writing-plans、debugging、code-review 这些。如果它支支吾吾说明技能没被正确装载。第二件让它用一个具体的技能处理一个很小的请求。比如你故意说请调用 brainstorming 技能帮我理一下周末想学做饭这件事。哪怕需求很生活化只要它开始追问你的目标、约束条件和优先级而不是直接给你列菜谱就说明技能真的生效了。第三件去用户目录下看一眼技能文件是否落地。位置通常在~/.claude/skills下面能看到按技能名命名的目录。如果你在系统里找不到也可以在 Claude Code 里直接问它你的技能目录在哪里它能告诉你实际路径。2.4 我踩过的几个安装坑第一次装的时候我卡在marketplace 添加成功但插件列表是空的。后来发现是版本问题我的 Claude Code 太老插件面板根本还没有加载新市场的功能。升级之后就好了。还有一个坑是目录问题。Claude Code 有全局项目和当前项目两层配置。如果你是在某个项目目录里开的终端插件可能只装到了项目级别换一个项目就没了。这不是 bug是它本身的配置逻辑。所以装完之后你最好确认一下它是装到了全局还是当前项目不然换目录后重新搜教程又是一遍折腾。第三个坑是技能冲突。我自己之前写过一些自定义的 SKILL放在同一个技能目录下。装上 Superpowers 之后发现我的自定义技能加载变得不太稳定。原因倒不是它覆盖了我的文件而是两个技能同时被触发模型不知道该听谁的。解决办法是把自定义技能的触发描述写得更明确或者干脆把很少用的那个先移出目录。3. 官方技能拆解这些 skills 到底在教 Claude 干什么3.1 先看一张速查表很多人问有哪些 skills其实与其记住全部名字不如先理解分类需求阶段、开发阶段、收尾阶段。Superpowers 里的技能基本是按照一个功能从无到有的流程组织的。下面这张表是我印象里官方自带的主要技能按照触发场景整理了一下最新清单以仓库文件为准技能目录名触发时机它会让 Claude 做什么brainstorming需求模糊、方向未定先提问澄清梳理约束、优先级和候选方案而不是直接写代码writing-plans需求清楚了准备动手前把大任务拆成带验证条件的小步骤形成可执行计划executing-plans计划已存在开始执行严格按计划一步步走每步改动前先对照计划writing-tests写实现前或修复 bug 前先写失败测试定义可观察的行为边界debugging出现非预期行为先稳定复现再缩小范围再做根因定位最后补回归测试code-review完成改动后、提交前切换成审查者视角检查边界、副作用、命名和测试覆盖committing准备提交时生成规范的提交信息把相关改动按逻辑分组delivering一个功能或版本要交付整理变更记录、使用说明和可能的回滚方案preflight提交或交付前的最后检查逐项确认测试、lint、文档、破坏性变更等是否遗漏onboarding-new-codebase第一次接触一个陌生仓库建立代码地图弄清入口、数据流、部署方式和关键模块这张表里我实际用得最多的是前四个加 code-review。后面的 committing 和 delivering 对我这种个人项目偏多的人价值没那么大但如果是团队协作那几项反而可能是最有用的。3.2 需求发散与计划类技能的工作方式先说 brainstorming。这个技能的有意思之处在于它要求 Claude 克制住立刻给出答案的冲动。正常情况下你让它帮我想一个文件整理工具它可能马上给你出一个 Python 脚本。但在这个技能约束下它会反过来问你你整理的文件类型有哪些自动分类还是手动打标需要跨平台吗要不要跟云盘同步整个过程很像一个产品经理在做需求访谈。我一开始觉得这套流程有点烦多一步问答。但实践几次后发现绝大多数翻车项目都是因为需求有个隐藏的条件没说出来。比如帮我把图片按时间归档你以为自己说清楚了但它不知道你是不是需要保留原目录结构是不是只处理某几个扩展名。checklist 会把这类问题暴露出来。writing-plans 则是把需求翻译成步骤。它产出的计划不是那种写一个函数、测试一下的流水账而是每一步都有明确的完成标准和验收方式。比如第一步创建测试文件包含三个用例覆盖空列表、单条记录、多条记录三种情况运行当前测试确认全部失败。这种粒度让后续执行变得非常可预期。3.3 写码、调试与审查类技能怎么改变日常体验真正让我感觉到质变的是 writing-tests 和 debugging 这两个技能。以前让 Claude 修 bug它经常是我给一个报错它就把报错相关的那一行改了然后说应该好了但你再跑还是错。用了 debugging 技能之后行为模式完全不同。它会先要求你给我最简复现步骤实在复现不出来就自己造一个最小用例然后通过日志或者二分注释来定位最后修完还会补一个针对根因的回归测试。code-review 是我最快能感知到价值的技能。写完功能后让它用 code-review 技能看看我的 diff它就会从我是写代码的人切换成我是审查代码的人开始问一些你自己可能根本想不到的问题这个分支的边界条件有没有覆盖如果原来是 null 怎么办这个函数被别处引用了会不会受影响测试是不是只测了 happy path4. 实战一次从模糊需求到可交付代码的技能联动4.1 任务设定给 CLI 工具加一个 export 子命令理论说多了容易飘用一个具体例子串一遍。我手头有个内部用的 CLI 工具用来管理待办列表任务存在本地 JSON 文件里。需求是加一个新命令export能把当前任务列表导出成外部 JSON 文件。我在会话里先用一句话把需求抛给 Claude请调用 brainstorming 技能我们想给现有的 CLI 工具增加一个 export 子命令把任务列表导出成 JSON 文件。接下来 Claude 没有直接动手而是连环提问导出的 JSON 格式是和内部存储保持一致还是只保留部分字段输出路径是用户指定还是默认当前目录文件已存在时是覆盖还是报错要不要支持输出缩进格式这些问题我自己确实没有全想清楚尤其是文件已存在时该怎么做——这个不确认后面 code-review 阶段大概率会暴露出来。最后我确定了策略默认覆盖但增加--no-clobber选项字段只保留标题、优先级和截止日期。4.2 第二步让 writing-plans 产出可执行计划需求确定后我用一条指令让它进入计划模式请调用 writing-plans 技能为这个 export 功能写一个执行计划。它给出来的计划分成了四步重点是每一步都带着验证方式。第一步是新增测试文件先写出 export 函数的单元测试覆盖导出内容正确、目标目录不存在时自动创建、no-clobber 模式下不覆盖已有文件运行测试确认这些用例全部失败。第二步是实现最小导出函数让前两条测试通过。第三步接入 CLI 参数把--no-clobber选项接到命令解析上。第四步跑完整测试确认原有功能没有被破坏。这个计划有几个明显的好处。一是它把先写测试放到了写实现之前这保证了实现代码一定有行为约束兜底。二是它每一步都能被验证不会出现做到一半不知道算不算完成的情况。4.3 第三步TDD 技能带着写测试和实现执行计划的时候我直接说使用 writing-tests 技能按计划写第一条失败的测试。Claude 写出来的测试用例里有一个考虑得很让我意外它没有直接把测试目标指向真正的文件系统而是用一个临时目录来跑避免污染真实数据。这其实是一种很基本的测试隔离思路但如果没有技能约束它很可能图省事直接对着真实文件路径写。测试全部失败确认之后再进入实现。这个阶段的体验是Claude 每次都只改到让当前测试通过的程度不再兴致勃勃地顺手重构我的其他代码。这种克制对日常使用来说非常重要减少了很多无谓的 diff 噪音。4.4 第四步debugging 处理一次真实报错中途跑测试的时候挂了一次报错是ENOENT: no such file or directory。如果是在没装 Superpowers 之前Claude 大概率会直接把fs.writeFileSync那一行加一个 try catch 就完事。但这次它调用了 debugging 技能流程明显不同。它先确认了一个最小复现场景执行export --output /nonexistent/dir/result.json发现必然报错。然后它定位到问题不在于写文件逻辑本身而在于我先调用了fs.existsSync判断目录却没创建目录。最终修复是调fs.mkdirSync(path, { recursive: true })同时补了一个新的测试用例目标目录不存在时应该被自动创建。这个案例本身不复杂重要的是它的行为路径复现、缩小、根因、回归测试一步都没跳。这正好对上了 debugging 技能的核心逻辑。4.5 第五步code-review 和 commit 收尾功能做通之后我又让它进入 code-review 状态请调用 code-review 技能检查这次的 export 功能改动。它真的挑出了几个问题。一个是--no-clobber分支下检查文件是否已存在存在时间窗口问题理论上极端并发下仍可能覆盖但在 CLI 场景下可以接受。另一个是我在导出函数里直接依赖全局变量来读取任务列表而这个全局变量在测试里被多个用例共享容易互相污染。最后它建议把任务列表作为参数传入导出函数这样测试也更好写。我按建议做了小重构测试再跑一遍全绿。提交之前再用 committing 技能生成提交信息它没有直接给我一个git commit -m add export完事而是生成了类似feat: add export subcommand with no-clobber support的格式还主动提示我这个改动是否应该拆成两个 commit——一个加功能一个加测试重构。说实话这个提示比很多团队里的代码评审都细致。5. 定制与复用把别人的技能包变成自己的方法论5.1 定位技能文件位置读一遍胜过看十篇介绍用顺手之后我做的第一件事就是去找技能文件到底存在哪。路径一般在~/.claude/skills下面每个技能一个文件夹。直接把SKILL.md打开看一遍你会立刻明白 Claude 刚才那些行为是从哪来的。读这些文件有个额外的好处你会发现自己也能写。它不是那种神秘的算法就是一套写得很细致的指导说明。你能看到它怎么要求模型在动手前先列假设怎么定义完成怎么阻止模型跳步。这些写作思路可以迁移到你自己的行业知识里。5.2 轻量修改改 checklist、模板与语气如果你觉得某个技能的输出和你团队的习惯不搭可以改。比如 code-review 技能默认可能更关注代码边界但你们团队最在意的是性能那你可以在它的 SKILL.md 里追加一段审查时额外关注文件 IO 和循环中的复杂度。我自己就把 committing 技能的规则改成了公司内部使用的提交前缀规范。改动之后效果立竿见影Claude 生成的 commit message 直接就是符合团队格式的省掉了以前每次复制粘贴改模板的时间。5.3 原创一个新技能最小的 SKILL.md 长什么样如果你脑子里已经有一套成熟的处理流程完全可以自己写一个新技能。最小的 SKILL.md 大概长这样--- name: my-custom-skill description: 当用户需要做 X 时使用这个技能按步骤处理。 --- ## 使用时机 当用户提到做 X或遇到 Y时启动本技能。 ## 执行步骤 1. 先确认输入条件A、B、C 是否都是已知。 2. 如果 A 未知向用户提问澄清。 3. 输出标准化模板包含结果和下一步建议。 ## 输出要求 - 必须给出明确的完成状态。 - 如果遇到多选情况列出选项让用户确认不要替用户做决定。写完之后放到技能目录里重开会话模型就能识别到了。我自己用这个方式做了几个小技能比如更新 CHANGELOG和检查数据库迁移脚本顺序都是那种做起来很机械但每次都得花几分钟的事。5.4 团队落地一次性分发与版本管理如果你想把 Superpowers 推到整个团队最简单的做法是让大家各自通过 marketplace 安装因为后续可以收到原作者更新。如果你希望团队用固定版本不想被上游更新打乱节奏那就把整套技能目录复制到自己仓库里配合 CLAUDE.md 写清楚路径然后让队友 clone。我实际采用的方案是混合核心技能用 marketplace 版跟随上游我们自己定制的那几个技能放进项目仓库路径指向仓库下的.claude/skills目录。这样既有上游维护的好处又不影响团队特有流程。6. 一个月实测后的几条真实体会6.1 token 开销明显上升需要学会按需解锁最直接的代价是 token 消耗变多。每次会话它都会加载技能描述文件加上 brainstorming、planning 这些流程本身就会多出好几轮问答一个本来三句话能说清的小需求现在可能要聊上五分钟。我自己实测下来一段简单的功能改动token 用量大概是从前的两倍左右。但不要因此因噎废食。更合理的方式是按需解锁小改动、一次性脚本不用刻意调用技能比较大的功能开发或排障再明确让 Claude 进入对应技能模式。Superpowers 不是非得全程开启它更像我工具箱里的一套专用扳手用到的时候再拿出来。6.2 它和 CLAUDE.md、自定义 agents 的分工我刚开始用的时候有个误区以为装完 Superpowers 就可以不写 CLAUDE.md 了。实际上两者分工完全不同CLAUDE.md 是给项目写上下文信息比如技术栈、目录结构、常用命令Superpowers 是给模型写行为方法比如遇到 bug 应该怎么排查。一个是项目说明书一个是工程师 SOP互相补充不能互相替代。自定义 agents 则是更进阶的东西相当于你做了一套固定角色的对话环境。Superpowers 里的技能可以在 agents 里被调用两者不冲突。我的建议是先把自己的项目 CLAUDE.md 写好再上 Superpowers最后才考虑要不要自定义 agents。顺序反了可能连问题出在哪都分不清。6.3 什么项目收益最大什么项目别硬上以我当前的使用经验收益最大的一类是中小型但需要多步操作的功能开发尤其是涉及先加测试、再改实现的任务行为稳定性的提升非常明显。第二类是排障场景debugging 技能提供的流程约束比任何单条指令都有效。反过来像随手整理 JSON、批量重命名文件这种一次性命令就不太需要让它走全套流程。聊天式的快速问答场景也不适合你问这个正则什么意思它要是先跑一轮 brainstorming 流程你会想骂人。所以关键还是判断场景灵活调用。用了一段时间之后我对这套东西最大的感受反而不是它让 Claude 变强了而是它让 Claude 的行为变稳了。技术圈里常说稳定压倒一切尤其是当你把代码生成交给模型的时候最怕的不是它不会而是它这次会、下次不会。Superpowers 提供的正是这种可复现的工程行为。如果你也正在被 Claude Code不够靠谱困扰与其换更强的模型不如先给它配一套更靠谱的 SOP。