superpowers：让Claude调用技能包，重塑AI编程工作流

前阵子在研究AI编程工作流的时候，偶然翻到一个叫“superpowers”的开源项目，一开始以为只是又一个Agent玩具，真正用下来才发现这是一套切切实实能改变Claude使用方式的东西。简单说，superpowers是一组可以被Claude直接调用的“技能包”（skills），里面涵盖了头脑风暴、技术评审、调试排障、测试驱动开发、Git工作流管理等高频场景。它能解决的痛点是：普通用户和Claude对话时，经常要反复描述需求背景、指定输出格式、要求分步骤执行，而装上superpowers之后，这些高价值的工作方法论会被直接编码成技能，Claude调用时就像点了一个大招。

这篇文章我会从原理、技能清单、安装步骤、实测案例和排障心得几个角度展开，把“怎么引入这些技能”这件事讲透。无论你是刚接触Claude Skills的新手，还是已经在折腾自定义技能的老手，相信都能在里面找到有用的信息。

1. 先搞清楚superpowers的本质：它不是一堆提示词，而是一套结构化技能协议

很多人第一次看superpowers的仓库，会觉得里面不就是一个又一个文件夹、每个文件夹里装着一个Markdown文件吗？这跟我自己写的“提示词收藏夹”有什么区别？区别非常大。Claude引入了一个叫Agent Skills的机制，它允许用一套特定的目录结构和格式，把“技能”打包成一个可被模型自动识别和调用的模块。superpowers正是基于这个机制构建的。

1.1 一个skill文件夹的典型结构

在superpowers里，每个技能对应一个目录，目录名就是技能的slug，比如brainstorming、writing-plans、systematic-debugging。目录里面的核心文件一般叫SKILL.md，它有两个关键组成部分：第一部分是frontmatter（YAML格式的元信息），里面声明了技能的名称、描述、使用场景；第二部分是正文，写的是这个技能完整的工作方法论。有些技能还会带上辅助脚本、模板文件、参考文档。

拿一个我最常用的brainstorming技能举例，它的SKILL.md里描述部分会写明：当用户需要产生创意、评估多个方案、或者面对模糊问题时，请调用这个技能。而正文里会引导Claude按照一套流程来走：先明确目标和约束条件，再分轮次发散想法，每轮之后进行收敛和打分，最后输出一个结构化的建议方案。如果没有这个技能，你得在对话里手打这些步骤；有了它，Claude会在合适的时机自动触发这套流程。

1.2 superpowers的核心理念：把资深工程师的工作方法“蒸馏”成指令

superpowers出自一位资深开发者之手，所以它的技能设计带着非常强烈的“工程师文化”气息。它试图建模的不是“让AI更听话”，而是“让AI像一个有多年经验的同事一样工作”。比如它的调试类技能会要求Claude先复现问题、再提出假设、然后最小化测试用例，而不是一上来就猜答案。这种理念和单纯调Prompt是完全两回事——后者是在教模型说话，前者是在教模型做事。

理解了这一层之后，你再看“怎么引入这些技能”这个问题，答案就很清晰了。引入superpowers本质上是两件事：一是把技能文件放到Claude能够读取的skills目录里，二是在对话中让模型知道可以去调用这些技能。前者解决“技能存在”的问题，后者解决“技能被发现”的问题。两个环节缺一不可，这也是很多人装上之后发现“没效果”的根本原因。

2. 仓库里到底有哪些skills，以及它们各自适合什么场景

superpowers仓库里的技能数量不少，而且还在持续更新。我梳理了其中最有代表性的几类，每类挑一两个典型技能讲清楚，方便你判断哪些是自己真正用得上的。

2.1 前期规划类：从模糊想法到可执行方案

这一组技能主要解决“事情还没想清楚”的阶段。最典型的是brainstorming和writing-plans。brainstorming适合一切需要发散和收敛的场合，比如你想给产品想一个新功能、想设计一个技术方案，甚至想策划一场活动，都可以先让它带着你走一遍头脑风暴流程。writing-plans则负责把头脑风暴的产出进一步细化成可执行的实施计划，它会要求拆解任务、估计依赖关系、标注风险和验收标准。

我自己的用法是：先让Claude用brainstorming陪我聊出两三个候选方案，再指定用writing-plans把其中一个方案落成带时间线的计划表。整个过程不需要我额外告诉它“请分别列出优缺点”“请评估风险”这类指令，技能本身就规定了这些环节。

2.2 编程执行类：从写代码到测试驱动开发

对于做开发的人来说，这组技能是superpowers里最值钱的部分。仓库里有专门针对test-driven-development（TDD）的技能，也有systematic-debugging（系统性调试）技能。TDD技能会强制Claude遵循“先写失败测试、再写最小实现、然后重构”的循环，每一步结束还会停下来等我确认，而不是一口气把所有代码写完。这听起来效率变低了，实际上规避了大量返工。

调试技能则非常硬核。它会引导Claude按照“读取错误信息→建立假设→设计实验→验证假设→定位根因→修复并补测试”的顺序排查问题。当我把一坨报错日志丢给它时，如果检测到场景匹配，Claude会自动调用这个技能，而不是像以前那样直接给一个可能是瞎猜的修复建议。

2.3 沟通协作类：让AI的输出更像“人话”

superpowers里还有一组跟协作、沟通相关的技能，比如talking、request-to-confirm。talking负责调整AI的表达方式，让它更自然、更简洁；request-to-confirm则会在重要决策前主动向我确认约束条件和偏好。这些技能单独看会觉得“这也算技能？”，但组合进工作流之后，整个对话体验的质感会明显提升——AI不再是一个只顾闷头输出的机器，而更像一个会提前确认需求、主动同步信息的协作者。

2.4 计划落地后的复盘与评审类

superpowers也没有忽略“做完之后怎么办”。仓库里包含reviewing和code-review相关的技能，它们会按一套清单去检查产出：有没有遗漏边界条件、有没有安全隐患、测试覆盖够不够、有没有更好的实现路径。这套技能非常适合用来做“第二双眼睛”，尤其是当你准备把代码提交合并或者把方案发给别人评审之前，先让Claude按这套流程过一遍，能挡掉不少低级问题。

我把这些技能的适用场景整理成了一个简单的对照表：

3. 安装与引入：从克隆仓库到让Claude主动调用技能的完整步骤

安装superpowers本身不难，难的是理解每一步到底在做什么。这里我按“环境准备→获取技能包→放置到正确位置→验证加载”四步拆解，读完你就能明白“怎么安装”以及“为什么这样装”。

3.1 环境准备：确认你的Claude版本支持Skills机制

superpowers依赖Claude Skills功能，所以第一步是确认你使用的Claude客户端或者API环境支持这一机制。目前Claude的桌面端、Web端以及支持Agent Skills的API环境都可以使用，但具体版本要求可能会有更新，建议到官方更新日志里确认一下。这一步最容易被忽略——有人辛辛苦苦搭完了，结果发现用的旧版本根本不支持skills目录，自然没有任何效果。

3.2 获取技能包：克隆仓库到本地

获取superpowers最简单的方式是从GitHub克隆仓库，在终端执行：

git clone https://github.com/obra/superpowers.git

执行完之后你会得到一个superpowers文件夹，里面最有价值的就是skills子目录，所有的技能都按文件夹分组放在那里。你也可以用其他方式把skills文件夹下载到本地，本质没有区别，只要最终拿到的是一个包含若干技能目录的文件集合即可。

3.3 放置到Claude能读取的skills目录

这一步是核心。Claude查找技能遵循一个固定逻辑：技能必须存在于Claude配置的skills目录下，每个技能是其中单独的子目录，并且目录内必须有可识别的技能定义文件（如SKILL.md）。一般情况下，用户级别的skills目录位于~/.claude/skills/，项目级别的skills目录则放在当前项目的.claude/skills/下。

你可以把需要的技能复制到用户级目录，让所有项目都能用；或者只复制某几个技能到项目目录，让特定项目拥有专属技能集。我个人的做法是：先把全部技能复制到用户级，实际用的过程中逐渐删除不需要的，留下一个精简集合。

# 将全部技能复制到用户级skills目录（示例路径，以实际环境为准） mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/

提示：如果你只想要其中几个技能，就只复制对应的目录，不必全量安装。技能不是越多越好，目录太杂反而会增加模型识别时的干扰。

3.4 验证加载：确认Claude能看到这些技能

装完之后怎么确认生效？最简单的方式是在对话里直接问Claude：“你现在可以使用哪些skills？”如果配置正确，它会列出已加载的技能清单，包括superpowers里的那些技能名字。另一种验证方式是直接描述一个匹配的场景，比如跟它说“我们来做一个头脑风暴”，观察它是否主动进入技能定义的流程节奏。

这一条验证很重要，因为很多人在第一步就装错了位置，或者复制之后忘了重启客户端，导致Claude依然看不到新技能。装完之后务必做一次验证，再进入正式使用环节。

4. 实测案例：从普通对话到技能驱动的真实变化

文字描述再多，不如看看实际用起来差在哪。我挑两个典型的场景，把“有superpowers”和“没有superpowers”的对话质感做个对比，你能直观感受到引入技能前后的区别。

4.1 场景一：让Claude帮你梳理一个功能想法

没有装技能的时候，我通常要写一大段提示词：“请帮我分析一下这个功能的想法，从用户价值、实现成本、风险几个维度评估，最后给出建议。”装完技能之后，我只需要说：“我想给我们的博客加一个稍后读功能，帮我理一理。”Claude会识别到这是一个brainstorming场景，自动进入发散模式，先问我目标用户是谁、核心场景是什么、有哪些约束条件，然后再给出一轮一轮的候选方向和评估。你会明显感觉到对话从“等待指令”变成了“协同思考”。

4.2 场景二：让Claude定位一个诡异的bug

以前遇到一个奇怪的报错，我会把日志直接贴给Claude，它往往会基于日志给出一个看起来合理但未经验证的猜测。如果你比较较真，需要追问“你确定吗”，它才会重新审视。用上systematic-debugging技能后，Claude会先按流程要求我提供复现步骤、运行环境、最近改动，然后告诉我：“我现在有几个假设，接下来请运行这个命令来验证假设一”，整个过程被严格结构化，每一步都有明确的输入输出。我付出的额外成本是操作更繁琐，但换回来的是排障过程可追溯、结论可靠。

4.3 场景三：用TDD技能写一个工具函数

我试过用TDD技能写一个处理时间戳的工具函数。Claude先写了一个会失败的测试用例，然后问我：“现在运行测试，确认它是红的。”我运行之后告诉它测试结果，它才继续写最小实现代码，再让我跑一遍测试确认转绿，最后进入重构阶段。整个流程走下来，代码质量确实比一口气生成要高，而且测试用例天然齐全。代价是节奏变慢，所以这种模式最适合那些逻辑复杂、后续要长期维护的模块，而不太适合一次性脚本。

这三个场景让我得出的结论是：superpowers的真正价值不是让AI变得更强，而是让AI变得更稳、更可预期。它牺牲掉一部分“快”，换来了“准”和“规范”。使用的时候建议根据任务类型灵活决定要不要启用相应技能，没必要所有对话都走重流程。

5. 安装和调用过程中的常见坑：我替你踩过的几个

安装和使用过程中我踩过不少坑，挑几个最有代表性的写出来，希望你能绕开。

5.1 坑一：所有技能一股脑全装上，反而降低了识别精准度

技能目录里塞了几十个技能之后，Claude在面对一个任务时，需要从大量候选中挑一个匹配的。技能描述写得不够清晰的时候，模型可能会选错，甚至出现多重技能的流程互相打架的情况。我的解决办法是：按“当前正在做的项目类型”维护不同的skills集合，做前端项目的时候就只保留跟前端相关的技能，写方案的时候就只保留规划类的技能。

5.2 坑二：装完技能客户端不重启，模型一直说“没看到”

Claude在读取skills目录时，通常是在会话启动时完成加载的。复制技能文件之后，如果当前对话已经开启，或者客户端一直挂着，它可能不会自动感知到新技能。遇到这种情况，重启一次客户端、新开一个会话，再问一次“你现在有哪些skills”，基本上就能解决。这不是bug，只是加载机制决定的。

5.3 坑三：同时装superpowers和别的第三方技能，流程出现冲突

很多时候你不想只依赖superpowers，可能还装了其他来源的skills。这时要注意不同技能是否有交叠。比如superpowers里有一个调试技能，另一个第三方包可能也带了一个调试技能，模型在选择时会产生困惑。我的建议是：以superpowers作为主技能集，其他第三方技能作为补充，且补充技能尽量选择功能差异大的，避免重叠。

5.4 坑四：多人协作时，项目级技能目录没提交到仓库

如果你在一个团队里用项目级的.claude/skills，记得把技能目录纳入版本管理，不然其他人克隆项目之后会发现技能丢了。还有一个容易踩的点是：有些人把个人偏好的技能放进了项目目录，结果整个团队都被迫使用，这种最好只放大家公认的项目级技能，个人偏好的放在用户级目录。

6. 进阶：把自己常用的工作流也封装成自定义skill

用了一段时间superpowers之后，你大概率会产生一个念头：我能不能把自己平时那套工作方法也做成一个技能？完全可以。而且搞懂了这个过程之后，你才算真正理解了superpowers的设计哲学。

6.1 自定义skill的最小结构

要创建一个自定义技能，先建一个目录，命名用短横线连接的slug，例如weekly-report。在目录里创建SKILL.md，文件顶部写frontmatter，至少要包含name和description。description尤其重要，因为Claude是靠它来判断“什么时候该用这个技能”的，写得太泛会导致模型乱用，写得太窄会导致该用的时候不用。

下面是一个最小示例：

--- name: weekly-report description: 生成每周工作周报，适用于需要汇总本周进展、下周计划、风险阻塞的汇报场景。当用户提到“写周报”或“周报”时使用。 --- # 周报生成技能 - Step 1: 向用户收集本周完成的主要事项 - Step 2: 询问下周计划与优先级 - Step 3: 询问当前阻塞与风险 - Step 4: 输出结构化的周报，包含本周进展、下周计划、风险与求助三部分

把这个文件夹放到skills目录后，重启会话，你的自定义技能就跟superpowers里那些技能平起平坐了。这种自定义能力才是Claude Skills机制最值得投入时间的地方——你其实是在把隐性知识显性化。

6.2 怎么让自建技能和superpowers配合使用

superpowers里的技能提供的是通用方法论，自定义技能承载的是你个人的领域经验。比如我自建了一个rails-migration-review技能，里面规定了很多团队特有的数据库规范；而superpowers自带的reviewing技能提供的是通用的评审维度。两者同时存在时，我会让前者负责“项目特有规则检查”，后者负责“通用质量检查”，形成互补。这种组合使用的方式，比单独依赖任何一套都要好。

7. 结合自身工作流的调优记录

最后聊聊我现在实际跑下来的这套工作流。需要说明的是，这不一定适合所有人，但可以给你提供一个调优参考。

我目前保留的技能集合包括：brainstorming、writing-plans、systematic-debugging、test-driven-development和reviewing，另外加了两个自制技能。其他比如常规的talking类技能，我试过一段时间，最后还是放下了，原因是我自己写的系统提示词里本来就把沟通风格规定得比较细，再让技能叠加反而让输出变得有点“端着”。

在具体使用节奏上，我把技能分成两类。一类是“主动触发型”，比如brainstorming和systematic-debugging，这类技能最好让Claude根据场景自动判断启用，我只要把问题描述清楚就行。另一类是“手动指定型”，比如writing-plans，因为写计划通常发生在我已经确定了大致方向之后，我会直接在追问里说“接下来用writing-plans把这个方案细化一下”，直接点名，但它输出什么取决于你给它喂多少上下文，这一步建议给足相关信息。

还有一个使用心得是：不要迷信任何单一技能的输出，尤其涉及到业务决策时。superpowers的价值是为AI的思考过程提供一个结构化框架，但判断和取舍的最终责任还是在你自己。我在用reviewing检查自己的技术方案时，经常会发现它提出的一些建议过于保守，但如果这个方案是要长期维护的，保守反而是好事；反过来，一些原型验证类的任务，我就会跳过这些重流程，直接开写。

调优这件事没有终点。随着你手上项目的类型变化，你保留的技能集合也会持续变化。我现在的习惯是每过一两个月就重新审视一遍技能目录，删掉不再用的，补上最近高频出现的工作场景对应的技能。superpowers这套体系给了你一个很好的起点，但真正能让它发挥出最大价值的，是你持续围绕自己的工作方式去调整它。

一个很实用的小技巧是，在你准备删掉某个技能之前，先看一看最近十次对话里它被触发了多少次。如果一次都没触发，果断删掉，不用心疼。技能和工具一样，留在手边的应该是那些真正被频繁使用的，而不是那些“看起来以后用得上”的。想清楚了这一点，你的技能目录会越来越精炼，每次Claude的响应质量也会越来越稳。