在 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 直接 executeAI 对完整的需求理解是模糊的它会自己脑补一堆你没说的规则而且一旦写错返工成本非常高——改一个接口的代价远大于在计划阶段多花五分钟。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 之外它本质上是在做方法论工程化这件事。