在 Claude Code 这个圈子里，最近有个词被反复刷屏：superpowers。它不是个比喻，而是一套真实存在的技能框架，可以让你手头的 AI 助手从"你问一句、它答一句"的被动工具，变成能主动拆任务、定计划、写代码、查 bug、做复盘的多面手。我在自己的项目里折腾了两周，最大的感受是：大多数人装完它之后并不会用，因为它真正改变的不是你的操作方式，而是你和 AI 之间的协作流程。这篇文章就把我实际踩过的坑、摸索出来的用法，以及 superpowers 里面那些 skills 到底各自管什么，完整梳理一遍。
1. superpowers 的本质：AI 的技能系统，而不是又一个大模型
先花点时间说清楚 superpowers 到底是个什么东西。很多人第一次听说它，以为是个新的模型或者新的命令行工具，其实都不对。它是运行在 Claude Code 这类支持 skills 机制的客户端之上的一套技能集合，用一套标准化的文件结构给 AI 预定义各种"工作模式"。
1.1 技能（skill）和普通提示词有什么区别
普通提示词是一次性的，你让 AI 干什么，它就在当前这轮对话里干什么，换个任务又要重新写。而 skill 是一段可复用的结构化指令，包含触发条件、执行步骤、输出格式和约束规则。
举个例子。我平时让 AI 写代码，通常会说"帮我给某个函数加个单元测试"。AI 确实会写，但它不会主动去考虑测试覆盖率、边界条件、异常处理这些细节，因为它不知道你的期望标准是什么。如果你给这套环境安装了一个 TDD 技能，AI 一旦识别到你在做功能开发，就会自动加载 TDD 技能里的流程：先分析用户故事、再确定验收标准、然后写失败测试、最后才实现代码。这就不是"回答一个问题"，而是"进入一套工作流程"。
superpowers 项目的核心就是把这些工作流程固化成一个个 skill 文件。每个 skill 文件遵循统一的格式，通常是 Markdown 文件配合 YAML 头信息，头信息里写明这个技能的名称和描述，正文里则是 AI 需要遵循的详细步骤、方法和工具调用规范。
1.2 为什么说它是"超能力"
我是这样理解的：默认状态下，AI 像一个很聪明但被动的新员工，你下达一条指令，它给你反馈一条结果。而装好 superpowers 之后，AI 变成了一个自带方法论的老手，遇到什么类型的任务，就自动套用对应的成熟流程。
我自己印象最深的是 brainstorming 技能。以前让 AI 帮我设计一个解决方案，它基本是直接给出一个答案，哪怕我说"多想想"也就是多列几条。而 brainstorming 技能加载后，整个流程完全不一样了：
- 先明确问题的背景和约束条件
- 然后从不同角度分别展开思考，每个角度独立成篇
- 最后才汇总成多个候选方案
- 甚至还要区分短期方案、中期方案和长期方案
这个体验的差异，就像一个是"你帮我写个方案"，一个是"你带我做一场结构化的头脑风暴"。
1.3 不挑特定领域的通用骨架
我特意试过把它用在非编程任务上也成立。比如我用它做过一次产品调研的规划，planning 技能会根据我的目标自动拆解成：调研对象、信息来源清单、访谈提纲、成果形态、里程碑节点。这说明 superpowers 并不是一个"编程专属"工具，它提供的是任务执行的方法论骨架，编程只是最适合它发挥的领域之一。
2. 核心技能清单：superpowers 里到底有哪些 skill
要真正用好 superpowers，第一步是搞清楚它自带哪些技能，每个技能什么时候触发、干什么活。我安装之后逐一翻过这些技能文件，这里按使用场景分组拆解一下。
2.1 研究与规划类
- brainstorming：这是我用得最频繁的一个。适合在动手之前做思路发散，它会强迫你先把问题定义清楚，再做多角度探讨，最后再收敛成可执行的选项。我发现它特别适合解决那种"脑子里有个模糊想法，但说不清楚具体要做什么"的场景。
- planning：负责把目标拆解为可执行的任务清单。它会要求你明确最终的成果物形态、完成标准、每一步的前置条件和输出结果。用大白话说，就是把"我要做一件事"翻译成"第一步做什么、第二步做什么、每一步做完怎么验收"。
- research：用于做信息收集和知识点梳理。适合写技术方案之前查资料、了解一个陌生框架、做竞品分析等。它会要求明确信息来源、记录结论和证据之间的对应关系，避免 AI 随口瞎编。
2.2 编码与工程类
- executing：这是执行类技能，负责把 plan 好的任务落到代码层面。它讲究"按部就班、逐文件修改"，并且每完成一小步就停下来汇报进展，而不是一口气把全部代码吐出来。
- TDD：测试驱动开发技能。我在给老项目补测试的时候用过一次，它的流程是严格的 red-green-refactor：先写失败测试，再跑出失败结果，接着写最简实现让它通过，最后重构。AI 在这个模式下不会跳过测试直接给你实现，这对代码质量是一种实打实的约束。
- debugging：系统化排错技能。以前 AI 排错就是"让看看哪里有问题"，而 debugging 技能会要求 AI 先复现问题、再提假设、接着验证假设、最后修复并验证。每一步都有明确的输出物，不会再出现 AI 信口猜测一个原因就直接改代码的情况。
- code-review：代码审查技能。我拿它审查过自己写的模块，它会从可读性、安全性、性能、边界条件等多个维度逐条提问题，而且会给出优先级，告诉我哪些必须改、哪些建议改。
2.3 写作与文档类
- writing：通用写作技能。它强调先定义读者对象和文字目的，再搭大纲、逐段写作、最后统一润色。我用它写过一个项目 README，结构和逻辑确实比自己闷头写要清楚。
- blogging：写博客专用的技能。和 writing 相比，它更关注主题的切入角度、段落节奏、标题吸引力这些内容。你给它一个主题，它会先帮你规划文章骨架。
你可能会注意到，这些技能之间存在明显的配合关系。实际项目中，先 research 收集信息，再 brainstorming 发散方案，然后 planning 做计划，接着 executing 执行，最后 code-review 收尾。这是很典型的组合链路。
2.4 第三方技能：生态的扩展玩法
superpowers 本身是一套技能合集，但它的机制是开放的。只要建一个目录，里面放一个带规范格式的 SKILL.md 文件，它就是一个全新的技能。我看到社区里有人上传了自己定制的技能，内容五花八门，有专门做数据清洗的，有专门做 API 接口文档生成的，还有专门做面试模拟的。
所以你可以把 superpowers 理解成一个技能管理框架，它自带的那些技能只是"官方示例"，更大的想象力在于你自己定义技能。这个过程门槛不高，核心就是写清楚：触发条件是什么、执行步骤是什么、最终要产出什么。
3. 安装与配置：如何把 superpowers 引入你的工作流
安装 superpowers 本身不复杂，但有几个环节容易被文档忽略，导致装上之后"没反应"，误以为失败了。我按自己的实际安装和验证过程，把步骤完整梳理一遍。
3.1 确认基础环境
superpowers 不是独立运行的软件，它依赖支持 skills 机制的 AI 客户端。我目前是在 Claude Code 环境里用的，这也是目前支持情况最好、社区资料最多的客户端。安装之前先把 Claude Code 升级到较新版本，因为旧版本对 skills 目录的自动发现支持并不完善。
3.2 安装步骤：从克隆仓库到放置技能目录
第一步是把 superpowers 的项目内容拉取到本地。不同安装方式的区别主要在于文件放置的位置。如果你用的是 Claude Code，常见的做法是克隆仓库到全局配置目录下的 skills 文件夹中。
# 进入 Claude Code 的配置目录，没有就手动创建 mkdir -p ~/.claude/skills # 把 superpowers 项目拉取到 skills 目录下 git clone https://github.com/obra/superpowers ~/.claude/skills/superpowers如果你想把官方默认技能全部加载，这个操作就够了。但我个人更推荐先只拉取一部分内容，因为你不需要也不应该把几十个技能全部塞给 AI。技能也是要占用上下文的，加载太多了反而干扰 AI 的判断。
按需启用的方式也很简单：在 skills 目录下只保留你想用的那几个技能文件夹，把不需要的移走或删除。我自己目前只保留了六个：brainstorming、planning、research、executing、debugging、code-review。
3.3 验证是否加载成功
装完之后怎么确认有没有生效？有几种方式。最基本的一种是直接打开 Claude Code，在交互界面输入一条和技能相关的指令，比如问它"你有能力使用哪些技能"，如果它能说出一串技能名称并附带说明，说明技能已经被扫描到了。
还有一种更直接的验证方式是查看日志。Claude Code 的启动日志里会打印 skills 扫描结果，我每次改动技能目录后都会看一眼日志，确认新技能是否被正确识别。如果加了新技能但日志里没出现，基本就是文件路径或格式出了问题。
3.4 验证技能是否真的被触发
加载成功不等于使用成功。真正要确认的是：在任务的合适节点，AI 是否会自动调用某个技能。
我的测试方法是给它一个明确的任务："我需要把当前项目的用户登录接口加一个防暴力破解的限流策略，先帮我做个计划再动手。"正常情况下，加了 planning 技能的 AI 会先输出执行计划，包含限流方案对比、影响范围评估。如果它直接开始改代码，说明 planning 技能没有被触发，这时候你需要检查技能的描述字段是否足够明确。
一个常见的问题是技能描述写得太笼统，AI 根本识别不出这个任务应该调用它。这时候可以在对话里明确说"请使用 planning 技能来处理这个任务"，强制触发。如果这样有效，说明技能文件本身没问题，只是描述不够精准，修改 description 字段重新加载即可。
3.5 不同客户端的安装差异
需要注意，不同客户端对 skills 目录的约定可能不同。有的版本用~/.claude/skills，有的用项目目录下的.claude/skills，还有的支持通过插件市场一键安装。我的建议是优先看你自己所用客户端的官方文档，以文档为准，网上的通用教程只能作为参考思路。我一开始就是照着旧教程把文件放到了错误的目录，白白折腾了半小时，最后看了一眼日志才发现问题。
4. 实战演示：让 AI 从"回答问题"到"执行任务"的完整过程
这一章节我拿一个真实的例子来还原使用 superpowers 工作流的完整过程。这个例子我整理过很多次，很有代表性。
4.1 一个典型任务的拆解过程
假设我现在要对一个开源项目增加一个新功能：为数据导出功能增加 CSV 格式支持。没有 superpowers 时，我大概会直接跟 AI 说"帮我加个 CSV 导出功能"，然后它可能就直接给出几段代码，让我自己去粘贴。用 superpowers 的链路时，过程是这样的：
第一步：研究现有代码结构
我先输入一句指令让 AI 进入研究模式："使用 research 技能，分析当前项目的数据导出模块，梳理现有的导出格式、代码结构、依赖情况。"此时 AI 会主动去读相关源码文件，输出一份结构说明，指出 CSV 支持需要改动哪些位置。
这个步骤的价值在于：你没有让 AI 直接写代码，而是先了解自己要改动的对象。特别是别人写的项目，代码结构不熟悉的情况下，跳过这一步直接写代码，AI 很容易在错误的位置做改动，或者漏掉关键依赖。
第二步：制定实施计划
结构摸清之后，我会输入"使用 planning 技能，制定实现 CSV 导出的详细计划，包括接口设计、改动文件清单、测试策略、兼容性考虑。"AI 输出的计划会是一个分步执行的文档——先改动数据转换层、再改接口层、然后写测试，每个步骤都带验收标准。
第三步：执行计划并写测试
计划确认无误后，我用"使用 TDD 技能，按计划实现 CSV 导出功能"触发执行。AI 会先为新增的转换函数写测试用例，再运行测试看失败结果，然后实现代码。这里有个细节：AI 每一步做完都会停下来等待我确认，而不是一口气写完所有文件。这种节奏感，正是 plan 和 execute 技能带来的。
4.2 过程中的决策点：为什么不直接让 AI 一口气完成
有朋友问过我：既然最终都是要 AI 写代码，为什么要拆这么多步？直接让它写不就行了。
我的体会是：当任务复杂到一定程度，直接让 AI 写其实是最低效的方式。没有 plan 直接 execute，AI 对"完整的需求"理解是模糊的，它会自己脑补一堆你没说的规则，而且一旦写错，返工成本非常高——改一个接口的代价，远大于在计划阶段多花五分钟。superpowers 的这套流程本质上是在逼你"先把事想清楚"，只是这次逼你的是 AI 本身。
4.3 多个技能的组合使用是真正的杀手锏
我后来慢慢发现，单个技能的使用价值有限，真正让效率产生质变的是技能之间的编排。我自己沉淀了一套常用链路：遇到一个新任务时，固定走research → brainstorming → planning → executing → debugging/code-review这个顺序。
这个过程有点像传统团队里的"需求分析 → 方案设计 → 进度排期 → 开发 → 测试"。每个技能对应团队里的一个角色，只不过现在这些角色全是 AI 一个人在扮演，而它切换角色的信号就藏在任务描述里。
4.4 手动触发与自动触发的权衡
用了一段时间后，我形成了自己的使用习惯：关键时刻手动触发，日常简单任务让 AI 自动判断。因为自动触发虽然方便，但在任务描述不够清晰时，AI 可能调用了错误的技能，反而把事情复杂化。
比如你只是想快速改一个变量名，没必要让 AI 走一遍 planning 的完整流程。反过来，一个跨多文件、涉及数据迁移的大改动，如果 AI 没有自动触发 planning，我会立刻手动指定。判断标准就一条：这个任务的复杂程度，值不值得走一遍完整流程。
5. 深度使用后的避坑清单与个人优化经验
没有哪个工具是装上就完美的，superpowers 也一样。下面这些坑和优化经验，是我在真实项目里一点点积累出来的。
5.1 避坑：技能不是越多越好
我第一次安装时把项目里所有技能都保留着，结果发现 AI 在对话中频繁做出奇怪的反应，比如用户随口问个问题，它也触发 brainstorming 技能，走一遍"多角度分析"的流程，回答拖沓无比。
根源很简单：上下文窗口是有限资源，技能越多，AI 越难判断"现在到底该用哪个"。解决方案是只留高频技能，把长尾技能放进一个备用目录，需要时再临时启用。我现在默认只留六个核心技能，已经覆盖了我 90% 以上的日常使用。
5.2 避坑：技能描述的质量直接影响触发准确性
技能能不能被正确触发，关键在 SKILL.md 文件头部那个 description 字段。这个字段写得好不好，决定了 AI 判断"要不要用这个技能"准确率。
我踩过一个具体的坑：自建的一个技能只写了一句话描述"用于处理数据相关任务"，结果任何涉及数据的模糊对话都会触发它，包括让 AI 总结分析数据这种压根不需要技能的指令。后来我把描述改成了带明确场景和目标的版本，比如"当用户需要将一种数据格式转换为另一种格式、或者需要清洗、标准化数据集时使用本技能"，触发准确率立刻上来了。
5.3 避坑：注意技能目录路径和缓存的问题
修改技能文件后，AI 可能不会立刻生效。我遇到过两次改了 SKILL.md 但 AI 行为完全没变化的情况，最后定位到是缓存问题。解决方案是：每次改动技能文件后，重启 AI 客户端，并确认日志里扫描到了新的文件内容。
另外，部分客户端允许多个 skills 目录路径，如果你明明放了文件却一直没被扫描到，十有八九是路径不对。做一个快速验证：用命令行查看客户端扫描的目录有哪些，把你放技能文件的路径和它对比一下就清楚了。
5.4 优化：按自己的项目类型定制私有技能
官方技能覆盖的是通用场景，你完全可以根据自己的高频项目自定义技能。我自己就建了一个后端 API 项目专用技能，内容包括：项目结构约定、文件命名规范、接口返回格式定义、异常处理的统一写法、日志规范。这样的话，我每次启动新项目或者让 AI 维护老项目时，它都会自动遵循这套规则。
创建技能的流程很简单，三步就够：
1. 在 skills 目录下新建一个文件夹，用技能名命名，比如 api-starter 2. 在文件夹内创建 SKILL.md 文件 3. 文件头部写 YAML 格式的 name 和 description 4. 正文写清楚使用场景、执行步骤、输出要求和示例有个小技巧：文件里的示例对话很有价值。让 AI 照着某个语气、某个风格的输出来做，远比抽象描述几百字更有效。我第一个自定义技能就偷懒没写示例，AI 输出的风格和我预期差很远，补上示例之后就正常了。
5.5 优化：把技能使用记录纳入你的项目复盘
我现在每次做完一个较大的迭代，都会让 AI 输出一份"本次使用了哪些技能、哪些环节最有效、哪些技能未触发导致走了弯路"的复盘记录。这个记录可以帮你持续优化技能配置——你会发现某些技能在你的工作流里利用率极低，某些技能总在关键时刻被错误触发，这些都是可以优化的信号。
有一次复盘我发现 code-review 技能触发率很高，但 review 出的都是小格式问题。后来我在技能的描述里补充了一句"当需要检查逻辑正确性、边界条件和安全性时使用"，又给它加了一个检查清单，之后的 review 输出明显更有针对性。
6. 聊聊我对 superpowers 未来的一些使用心得
写到这里，想以个人的实际体验收个尾。superpowers 对我最大的改变，不是让 AI 写出了更好的代码，而是改变了我自己思考和下达任务的习惯。以前我总是把需求想得差不多就开始做，做到一半才发现漏洞。现在因为 AI 自带 planning、research 这些流程环节，我会下意识地在动手之前把目标、约束、验收标准想清楚——因为你描述得越清楚，AI 走完流程后的产出就越接近你想要的结果。
还有一点体会是：工具越强大，越要克制。技能种类那么多，真正高频用到的其实就那几个。把核心技能理解透彻、配合自己的项目做微调，效果远好于一次性塞进几十个技能然后期待 AI 自动做出最优选择。刚开始使用 superpowers 的朋友，我建议先完整走一遍"安装 → 验证 → 简单任务试跑 → 看日志 → 调技能"这个闭环，不要急着加自定义技能。等核心链路跑顺了，再去扩展自己的技能库，那时候你会更有感知力——什么样的技能真正有用，什么样的技能只是花架子。
我自己的下一步计划，是把公司项目的编码规范固化成几个内部技能，让 AI 在所有相关任务里自动遵循。这个思路一旦跑通，等于把团队的工程最佳实践沉淀进了工具本身，不管换谁来维护，都能保持同样的水准。这也是我对 superpowers 这类技能框架最看好的一点：Code 之外，它本质上是在做"方法论工程化"这件事。
