Claude Code技能包superpowers：让AI编程告别越用越乱

刚接触 Claude Code 的人很容易遇到一个瓶颈：单轮对话里让它写个小函数没问题，一旦任务变成"要做一个完整功能、要改十几个文件"，它的表现就开始飘忽。一会思路清晰给你列一二三四，一会又在一个小 bug 上原地打转。superpowers 这个名字中二感十足，但它解决的正巧是这个问题——它把 Claude 的思维方式结构化，等于给模型配了一套工地级别的施工流程。这篇文章不会去复述官方 README，而是以我实际使用两个月、踩过不少坑之后的视角，把 superpowers 到底是什么、具体有哪几个 skills、怎么装、怎么引入、以及实战效果如何，一次性讲清楚。

1. 先说结论：superpowers 实际解决的是"Claude 越用越乱"的问题

1.1 它不是一个代码库，而是一套"行为说明书集合"

第一次看到这个项目的人，十有八九以为它是个工具链或函数库。实际上 superpowers 是一个基于 Claude Code 插机制分发的能力包，里头的核心资产不是代码，而是一批 Markdown 格式的SKILL.md文件。Claude Code 在对话过程中读到这些文件之后，会改变自己的行为方式：遇到复杂需求时先问清楚边界，动手之前先写方案，执行计划时一次只做一个小任务，出错之后按固定套路定位问题，而不是无头苍蝇一样乱改。

用一句话概括：它把"临时抱佛脚地使用 AI 编程"变成了"按施工图干活"。我在没有安装它之前，给 Claude 布置一个跨文件改造任务，经常要反复补充上下文，甚至中途因为对话太长、上下文窗口被各种试探性操作塞满，最后只能新开对话从头讲一遍。superpowers 的思路是让 Claude 在动手前就把方案固化成一个可审查的文档，执行时严格照着文档走，这样就算对话被迫切断，新对话也能基于计划文件快速续上。

1.2 你需要重新看待"技能"这个概念

很多用过 ChatGPT 或 Gemini 的人对"技能"的理解是：像 App 一样装一个插件，然后多出一个功能按钮。superpowers 里的 skills 完全不是这种形态。它更像是给 Claude 的一份"岗位工作手册"，Claude 会在恰当的时机主动阅读这些手册，然后按照手册里的流程来组织自己的思考过程。

举个例子，我让它"帮我 brainstorm 一下这个 CLI 工具的命令参数设计"，它会先加载 brainstorming 这个 skill，然后做一个我之前没想到的动作——先不急着给方案，而是反问我：这个工具面向谁、一次性使用还是长期维护、出错时的容忍度如何。这些追问并不是随机生成的，而是 SKILL.md 里明确要求它做的。换句话说，superpowers 不是给 Claude 增加新功能，而是给 Claude 增加新规矩。这也是它最容易被误解的地方：你以为装了一个工具包，实际上你装了一套"质检流程"。

1.3 什么样的人值得装

如果你只是偶尔让 Claude 写个正则表达式、转个数据格式、问点 API 用法，superpowers 对你来说可能感知很弱。但如果你符合下面任意一条，我建议你认真考虑：

• 日常用 Claude Code 写完整功能模块，一个任务涉及五六个文件以上
• 需要它做代码重构、跨模块改造，又担心改坏原有逻辑
• 经常遇到 Claude 在长对话中"失忆"——前面定的方案，执行到一半被它悄悄改掉了
• 希望 AI 不仅产出代码，还能在动手前与你对齐设计决策
• 团队里有人用 Claude Code 协作同一个仓库，需要留下可追溯的计划和痕迹

我属于前三条全中的重度用户。安装后最大的感受是，Claude 从"一个聪明但毛躁的实习生"变成了"一个虽然没那么快但每一步都先汇报、先确认、留记录的可靠同事"。代价是对话变啰嗦了、执行变慢了，但返工率显著降低，这笔账怎么算都划算。

2. 拆包看货：这套技能包到底装了哪些 skills

2.1 核心目录结构速览

superpowers 的仓库里有一个skills目录，下面每个子目录对应一个独立技能。每个技能目录内部必有一个SKILL.md，里面写着触发场景、工作流程、输入输出格式、注意事项。以当前仓库版本为例，我实际使用中真正发挥作用的主要有这几个：

还有一些辅助类技能我没有全部列出来，它们发挥作用的频率因人而异。核心逻辑是：superpowers 不试图让 Claude"知道更多"，而是让 Claude"更有条理地使用它已经知道的东西"。

2.2 几个主力技能的触发时机与行为差异

brainstorming是我最常主动调用的技能之一。它适合在任务描述还不清晰的时候使用，典型触发话术是"use the brainstorming skill to help me think through this"。加载之后，Claude 会要求我补充背景信息，然后给出多个方案而不是直接选一个。它甚至会在方案后面附上每个方案的适用场景和代价，逼着我想清楚自己到底想要什么。

writing-plans则会做一件让传统编程者非常舒服的事：把方案变成一份带检查点的任务清单。正确的用法不是让 Claude 自己把方案生成完就直接执行，而是你在对话里确认方案没问题之后，再让它 write a plan。生成的计划文件会对齐方案中的每个环节，拆成若干个"一次只做一件"的小任务，并注明验收标准。

executing-plans是让本来容易失控的长任务保持稳定的关键。它读取已有的计划文件，一个任务一个任务地往下执行，每一步做完都会标记完成状态，而不是一口气把所有代码写出来。这非常像我们平时用项目管理软件拆解任务的感觉，只不过干活的是 AI。

2.3 怎么查看当前到底有哪些 skills

装完插件之后，很多人会困惑"技能都在哪"。最直接的办法是打开仓库目录看：如果是通过 Claude Code 插件市场安装的，可以在~/.claude/plugins下面的对应目录里找到 SKILL.md 文件；如果你是手动 clone 到项目里的，通常就在项目的.claude/skills目录下。这些目录里躺着所有技能说明书，完全可以打开当操作手册读。

另外，在实际对话中你还可以直接问 Claude 本身：它可以列出当前可用的技能并说明用途，因为它能读取到这些目录。我习惯在新项目开始时专门问一句"你现在可以用哪些技能，分别什么时候用"，让 Claude 自己复述一遍。这个做法一方面能让我确认安装是否生效，另一方面能让 Claude 在后续对话里更自觉地调用它们——因为它知道我知道它有什么工具。

3. 安装与引入：从零到能跑起来的最短路径

3.1 方式一：通过 Claude Code 插件市场安装

如果你用的是较新版本的 Claude Code，最省事的路径是使用插件市场命令。我当时的安装过程非常顺利，全程两条命令：

/plugin marketplace add obra/superpowers /plugin install superpowers@superpowers

第一条命令把作者的仓库注册为插件市场来源，第二条命令从该市场安装 superpowers 插件。执行完之后，Claude Code 会提示插件已启用。这里有一个容易忽略的细节：启用插件之后，需要重启当前会话，或者至少让 Claude 重新扫描插件目录，否则它可能不会立刻意识到自己已经掌握了新技能。

如果你的 Claude Code 版本还没有内置插件市场命令，也可以直接手动安装。原理非常简单：先 clone 仓库，再把仓库里的skills目录链接到 Claude Code 的配置目录下：

git clone https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers

然后在 Claude Code 的配置文件（通常是~/.claude/settings.json）里确保插件目录被加载。不同版本字段略有差异，但思路一致：让它能读到这个目录下的SKILL.md文件。我自己的经验是，手动安装没有太多技术难度，但每次更新比较麻烦，所以后来还是切回了插件市场方式。

3.2 方式二：把 skills 放进具体项目里

还有第三种更轻量的方案：只把需要的技能塞进单个项目。Claude Code 支持项目级技能目录，也就是项目根目录下的.claude/skills/，里面的技能只在该项目对话中生效。如果你手头已有某个技能的 SKILL.md，直接复制到这个目录里就行。

这种做法适合不想全局引入、只想在某个特定仓库里试验的情况。比如我在公司一个多人协作的仓库里，就没有全局开启 superpowers，因为担心行为变化会影响同事的日常提交风格，只在个人项目里全局使用。项目级引入的另一个好处是：可以和团队约定项目内统一的技能目录，大家共享同一套工作流，这比每人都改全局配置要干净得多。

3.3 安装完成后的第一件事：确认技能确实生效了

装完别急着开工，先做一个"冒烟测试"。我的做法是：新开一个 Claude Code 会话，输入一句很简单但能触发技能的话，比如：

use the brainstorming skill to help me decide between a CLI tool and a web UI for a small internal dashboard

观察 Claude 的反应。如果它开始读文件、然后反过来追问我需求细节，说明技能生效了。如果它只是像平时一样直接给结论，那八成是加载失败或者没有匹配到技能触发条件。顺带一提，Claude 在调用某个技能后通常会在回复里明确提到"我已经读取了 brainstorming 技能"或者类似的话，这是最直观的生效标志。

提示：不要一上来就让 Claude"全程使用所有技能"。superpowers 里的每一个 skill 都有明确的适用场景，强制全部用反而会让简单任务变得臃肿。我见过有人为了体验技能，让 Claude 给一个纯展示网页先写三页技术方案，完全是杀鸡用牛刀。

4. 实战记录：用 superpowers 从零完成一个小工具

文字介绍再多，不如跑一遍真实流程来得直观。下面我用最近做的一个实际任务来拆解：写一个 Python 批量重命名工具，要求支持名字映射规则、预览模式、操作日志回滚。这个任务不算大，但足够展示整套技能的协同方式。

4.1 第一阶段：用 brainstorming 把需求边界钉死

一开始我的需求描述非常含糊："写个脚本批量改名，要安全。"如果直接让 Claude 写，它大概率会产生一个看起来能用、但边界一塌糊涂的版本。这次我明确要求它先加载 brainstorming。

Claude 果然没有直接写代码，而是先问了几个关键问题：重命名规则是简单替换还是正则匹配？是否需要处理文件名冲突？预览模式需要展示到什么粒度？"安全"具体指什么——是防止覆盖，还是要能回滚？

这些问题看似普通，但现在回看，它们全都在后续开发中成了分水岭：如果没问"是否处理文件名冲突"，生成的脚本大概率会直接覆盖同名文件；如果没问"预览粒度"，用户可能只能看到新旧文件名列表，看不到具体差异。brainstorming 的价值在于，它把我在需求阶段懒得多想的问题全部给捞了出来。这一轮下来，我们确认了三个方案：纯 Python 脚本、Python + dry-run 参数、以及带变更日志的进阶版。Claude 甚至给了每个方案的推荐场景。

4.2 第二阶段：writing-plans 把方案变成施工图

需求确认后，我让它基于选定方案写计划。关键一步在这里：计划必须写成独立文件，而不是只存在于对话里。我让 Claude 调用writing-plans技能，生成一份计划，并且明确要求它保存成文件，之后执行阶段再调出来。

生成的计划结构大致如下：

# 批量重命名工具实施计划 ## 目标 - 支持前缀/后缀添加、指定字符串替换两种规则 - 支持 dry-run 预览 - 记录变更日志，支持按日志回滚 ## 任务清单 1. 搭建项目结构与入口模块 - 创建 main.py，定义命令行参数 - 验收：`python main.py --help` 能列出所有参数 2. 实现映射规则引擎 - 规则数据结构定义与解析 - 验收：单元测试覆盖替换与前后缀规则 3. 实现 dry-run 预览 - 输出 旧名字 -> 新名字 对照表 - 验收：执行 dry-run 不实际改动文件系统 4. 实现实际重命名与冲突检测 - 冲突时跳过并提示 - 验收：两个文件映射到同一新名字时只保留第一个 5. 实现日志记录与回滚 - 记录到 rename_log.json - 验收：根据日志能还原原文件名

这份计划的每一个条目都带着明确的验收标准。我觉得这比"让 Claude 一口气生成代码"重要的多，因为验收标准意味着 Claude 在执行时知道自己做到什么程度才算完成，而不是自己觉得差不多就收手。

4.3 第三阶段：executing-plans 按图施工

执行计划时，我直接告诉 Claude"读取之前的计划文件并开始执行"。它做了几个我特别满意的动作：第一步是重读了计划全文，然后开始"一个任务一个任务"地推进，每完成一个小任务就用简短的话报告进度，并且对照验收标准自检。

在实现映射规则引擎时，它还主动补写了几个针对边界情况的单元测试，比如空字符串替换、正则特殊字符转义、超长文件名冲突。这让我很意外，因为我并没有要求它写测试，但它从计划里的"验收：单元测试覆盖"读到了隐含要求，于是自作主张把测试补上了。这种"按图施工但不机械照搬"的表现，正是技能文档和模型能力结合得好的结果。

4.4 第四阶段：systematic-debugging 收拾烂摊子

当然，计划再周密也会出问题。实际跑起来的时候，回滚功能在 Windows 路径上出了 bug：日志记录的是绝对路径，但文件名含有特殊字符时 JSON 反序列化报错。我没有直接告诉 Claude 怎么改，而是让它走一遍systematic-debugging流程。

令人欣慰的是，它没有上来就大改代码，而是先复现问题、缩小范围、提了一个临时加日志的命令让我帮忙跑，最终定位到问题根源是json.load时对反斜杠的转义处理不当，而不是回滚逻辑本身出错。整个过程大约 15 分钟，比我在 Stack Overflow 上翻答案再手动验证的方案快得多。更关键的是，它最后在代码注释里写了根因说明，避免后人再踩一遍。

4.5 实战体验总结：三个最直观的变化

• 反复横跳明显减少。以前 Claude 可能在方案 A 和方案 B 之间自动切换，现在它只按计划执行，计划外的想法会先提出来征求我的意见，而不是自己悄悄改变方向。
• 验收标准缺位的场景变少。它每完成一个小任务，会自己对照验收标准检查，很多时候不用我再特意说"你测一下"。
• 对话中断可恢复。计划文件独立存在，即使中途新开对话，也能让新会话读计划文件继续执行，不用重新解释需求。这一点在公司里交接给同事新开对话时尤其好用。

5. 用了一段时间后的体会和踩坑清单

5.1 最大的坑：计划文件堆积成山

superpowers 的流程天然会产生计划文件、进度标记、变更日志。我第一个项目跑完，项目目录里多了至少五个 markdown 文件——计划、子计划、执行状态、复盘。这些文件对长期项目来说是好东西，但对一次性小工具来说就是噪音。

我的做法是给"一次性的小实验"单独建临时目录，跑完直接删掉整个目录；只有真正要持续维护的功能才放项目根目录下保存计划。如果你用 git 管理项目，记得把这类自动生成的计划文件纳入版本决策，不要一股脑提交，否则每个 Pull Request 里都混着一堆计划 markdown，reviewer 会抓狂。

5.2 不是所有任务都值得走完整流程

superpowers 让我最犹豫的地方在于它有些过度工程化的倾向。现在我对任务做分级处理：

• 改动一个文件以内的简单改动：直接让 Claude 改，不调任何技能
• 一个功能模块，逻辑清晰但没有太多歧义：让它写计划，但不强制 brainstorming
• 跨文件、或者需求本身还不清晰的任务：完整走 brainstorming → writing-plans → executing-plans

如果不分级，让一个改 README typo 的任务也先来一轮头脑风暴，体验会非常糟糕。技能是给人用的，不是给人表演的，把它当锤子不代表所有东西都是钉子。

5.3 与自定义系统指令的配合方式

如果你在 Claude Code 里已经有自定义的系统指令或项目约定的 CLAUDE.me 文件，注意它们和 superpowers 可能产生指令冲突。我一开始的项目说明里写了一句"尽量直接给出代码不要解释"，结果与 brainstorming 技能要求的"先问问题再给方案"直接打架，导致 Claude 行为变得飘忽不定。

后来我把系统指令改成了与技能兼容的表述：把"直接给代码"调整为"对于简单明确的任务可以直接给代码，对于复杂任务先按可用技能流程处理"。现在两者基本能协同工作，不再互相拆台。

注意：如果你发现安装 superpowers 之后 Claude 的行为和预期不一致，先别卸载，检查一下是不是自己的系统指令在跟技能文档抢方向盘。技能可以通过自然语言说得更具体："这次不要用 brainstorming，直接按你的理解写计划"。

5.4 更新和升级的节奏

作为第三方插件，superpowers 的更新频率并不低，核心技能的流程说明时不时会有调整。我出现过一次问题：版本升级后，旧计划文件里引用了旧的技能行为描述，执行时 Claude 按新版技能流程处理，结果和计划文件里的旧标记格式对不上。

我的经验是：升级插件后不要立刻启动大任务，先跑一个 10 分钟内的小任务试探一下行为变化；跨版本更新的情况，更建议旧项目继续使用旧计划文件，新项目再体验新流程。盲目追求最新版本没有必要，稳定执行比新特性重要得多。

5.5 关于"agent 到底有没有变聪明"的最诚实观察

最后说一点可能和很多人预期不符的体会。superpowers 没有让 Claude 变得更聪明，也没有增加我不知道的新能力，它甚至让对话变得"更笨"——开场总是问东问西，执行总是拆得碎碎的，节奏明显变慢。但它的确让最后交付质量提高了。

原因也很简单：复杂任务翻车通常不是因为模型不够聪明，而是目标没对齐、约束没人记录、方案在中途悄悄漂移。superpowers 提供的全部内容，本质上是给这些"软性问题"装上护栏。对于自己写代码超过十年、习惯先设计再动手的人来说，这套流程非常自然，几乎不需要适应；如果你本身是"先跑起来再说"的风格，那你会觉得它极其啰嗦。我在实际使用中逐渐接受了一种观念：让 AI 干活和带人干活是一样的，你越是把流程说清楚，结果就越可控，superpowers 只是把这件事工业化了而已。