superpowers技能包：为Claude Code注入资深工程师工作流

最近有个词在开发者圈子里热度特别高，就是 superpowers。很多人第一次听说它的时候都挺懵：这到底是个新框架？新插件？还是某种炼丹技巧？如果你正在用或者准备入坑 Claude Code，那 superpowers 大概率是绕不开的话题。我大概两个多月前开始把它装进日常开发流程，从最开始的好奇折腾，到后来养成固定习惯，中间踩过不少坑，也总结出一些自己的用法。这篇文章就围绕大家问得最多的几个问题展开：superpowers 具体能干什么、里面有哪些 skills、怎么引入这些技能、以及怎么安装并真正把它用起来。不管你是 AI 编程的老手，还是刚接触终端编码助手的新人，这篇应该都能让你少走弯路。

1. 先搞清楚：superpowers 到底是什么

1.1 它不是魔法，而是一套“技能包”框架

先说结论：superpowers 是一个开源项目，本质上是给 Claude Code（Anthropic 出的终端编码助手）扩展“技能”的框架。它不是某个具体的功能，而是一套预置好的、可复制可修改的技能集合。

打个比方。你雇了一个基础能力很强但经验不足的“新工程师”。他懂编程语言、会读代码、能写代码，但他不知道“接到一个需求之后，应该先做什么再做什么”。这时候你给他一本资深工程师写好的《工作手册》，里面分场景写了标准流程：接到新功能先脑暴方案、再列计划、然后拆任务、先写测试再实现、最后自查和提交。superpowers 干的就是这件事——给 Claude Code 塞进一套高质量的“工作手册”。

这解释了为什么很多人装上之后的第一反应是“哇，它好像变聪明了”。其实底层模型没变，变的是 Claude Code 被引导出一套更接近资深工程师的做事流程：先想清楚再动手，而不是拿到需求就直接噼里啪啦改代码。

1.2 技能的本质：SKILL.md 与斜杠命令

聊到这儿，就得拆一层技术细节。superpowers 里的每个“技能”，在文件系统上就是一个普通的目录，目录里有一个核心文件SKILL.md。这个文件用 Markdown 写的，头部有一段 YAML 格式的 frontmatter，里面声明了技能的名称（name）和描述（description），正文则是具体的操作指令。

frontmatter 长这样：

--- name: brainstorming description: Use this skill when the user wants to explore approaches, design solutions, or think through tradeoffs before writing code. ---

正文就是真正的“实战手册”，通常会包含目标、步骤、检查清单、输出格式要求。Claude Code 在启动时会扫描技能目录，把技能清单加载到上下文里。当你说话的内容和某个技能的 description 匹配上时，模型可以主动建议使用这个技能；你也可以直接输入斜杠命令强制触发，比如/brainstorming、/creating-plans。

这背后还有一个更巧的设计：superpowers 支持一个“元技能”（meta-skill）。你可以把想象成一位“工头”——它自己不直接干活，而是根据你当前的处境，判断该调用哪个具体技能、按什么顺序调用。这也是它和普通插件最大的区别：你不需要记住每个技能怎么用，工头会提示你“这个阶段建议先做计划”。

1.3 谁适合用它

• 每天深度使用 Claude Code 写代码、改代码的开发者，这个是最核心的目标人群。
• 做技术管理的人：想让 AI 的产出流程和团队规范一致，而不是每次行为都随缘。
• 教学相长型选手：想研究“如何把最佳实践显式化写成文档”的人，技能文件本身就是极好的学习材料。

如果你只是偶尔让 AI 补个函数、写个正则，那 superpowers 对你的增益可能没那么明显。但只要是“成体系”的开发任务——加功能、重构、排查问题——它带来的价值是肉眼可见的。

2. 安装 superpowers：两条路线与避坑点

2.1 前提条件：先把 Claude Code 跑起来

装 superpowers 之前，得确保本机已经有可用的 Claude Code。它是通过 npm 安装的：

npm install -g @anthropic-ai/claude-code

装完在终端敲claude，能正常进入交互界面就算通过。另外还需要你有 Anthropic 的账号和 API key，或者可用的订阅额度。这一步没什么捷径，环境没通的话后面都白搭。

顺手提一个很实在的注意点：Claude Code 更新频率不低，技能机制相关的功能也在迭代。建议装 superpowers 之前先看一眼自己的 claude 版本，尽量用最新的：

claude --version

太老的版本，技能加载可能会有兼容性问题，后面排查起来会多花不少时间。

2.2 路线一：通过插件市场安装（推荐）

superpowers 官方支持通过 Claude Code 的插件市场机制安装，这是最省事、最不容易出错的方式。

在 Claude Code 交互界面里，直接输入斜杠命令：

/plugin marketplace add obra/superpowers

这条命令会把obra/superpowers这个仓库注册为你的插件市场。接着再输入：

/plugin install superpowers@superpowers

安装完成后，退出当前会话重新进入，技能就加载好了。整个流程大概一分钟。

之所以推荐这条路：插件市场机制会自动处理技能目录的复制、升级和依赖关系。以后项目有新版本，在插件面板里就能看更新，不用手动去 git pull 然后重设链接。对大多数使用者来说，这就是最优解。

2.3 路线二：手动克隆与软链接

如果你因为某些原因无法使用插件市场，或者想自己魔改技能，那就手动装。思路很简单：把仓库克隆下来，再把里面的skills目录暴露给 Claude Code。

先克隆：

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

然后看你希望技能作用在哪个范围。想让所有项目都能用，就把技能目录软链到用户级目录：

mkdir -p ~/.claude/skills ln -s ~/superpowers/skills/* ~/.claude/skills/

只想让某个项目用，就在项目根目录创建.claude/skills，同样做软链：

mkdir -p .claude/skills ln -s ~/superpowers/skills/* .claude/skills/

Windows 用户注意：软链接在 Windows 上要么用管理员权限，要么直接复制目录过去，省得折腾权限问题。复制的话以后更新就要手动再覆盖一次，这是手动路线的缺点，不介意就没关系。

2.4 安装后必做的验证

装完别急着开干，先花 30 秒验证一下技能确实加载了。在 Claude Code 会话里输入：

/help skills

或者直接问一句“你现在有哪些可用的技能”，它会列出当前加载的技能清单。如果列出来的名单里能看到 brainstorming、creating-plans、test-driven-development 这些，说明加载成功。

还有一个更直接的验证方式：随便输一个斜杠命令，比如/brainstorming，如果它开始按技能模板和你互动，那就是没问题。

注意：如果验证时提示找不到命令或者技能列表为空，优先检查技能目录路径是否被正确扫描到。项目级技能目录必须位于项目根目录的.claude/skills下，用户级则必须在~/.claude/skills下，路径差一点都不行。

3. 核心技能逐个拆解：这些 skills 到底怎么用

3.1 大脑类：brainstorming 与 creating-plans

brainstorming是 superpowers 里最常用、也最出彩的技能之一。它解决的问题是：面对一个模糊需求时，AI 不该直接跳进代码里。

举个例子，你说“我想给这个项目加个缓存层”，没有技能时，Claude 可能直接就开始写 Redis 连接代码了。但有了 brainstorming，它会先和你确认约束条件：缓存什么数据？一致性要求高不高？过期策略倾向什么方案？然后列出几个候选方案，分析各自的优缺点，最后还会主动指出你原需求里的隐含假设。

creating-plans则是把脑暴的结果落成可执行的计划。它会按照“背景—目标—方案—分阶段任务—风险点—验收标准”的结构输出一份计划文档。我的体感是，它生成的计划比很多团队内部写的设计文档还规整，甚至可以直接拿去做排期参考。

这里有一个核心技巧：先/brainstorming再/creating-plans，顺序不能反。脑暴负责把方向跑宽、跑清楚，计划负责把路收窄、变成可执行步骤。跳过错题直接做计划，产出的往往只是一个很漂亮的“空架子”。

3.2 执行类：test-driven-development、debugging 与 making-changes

test-driven-development是 superpowers 里含金量很高的技能。它会把 TDD 的节奏掰开揉碎地执行：先要求你描述清楚期望行为，再生成一个会失败（红）的测试，然后引导你写出足够让测试通过（绿）的最简实现，最后再进入重构环节。它对“不要让自己偷懒跳过红-绿循环”这一点有很强的坚持。

我第一次用的时候还挺不适应，因为它会拦住我：“你还没写失败的测试，确定要直接实现吗？”但事后复盘，这个“拦住”的动作恰恰是价值所在。开发里很多 bug 的根源，就是跳过测试直接写实现。

debugging则是另一套完全不同思路的流程。它不让你瞎猜，而是先输出一个“问题复现步骤”，再收集证据，建立假设，逐个验证假设，最后定位根因。说白了，它把程序员调试时那种“随便改一下试试”的坏习惯，强行扭成了科学家做实验的思路。

如果要用一个词概括这三类执行技能，那就是“纪律”。它们不提供什么黑科技，只是把优秀工程师默认的行为准则，变成了 AI 强制执行的标准流程。

3.3 收尾类：reviewing-code、writing-commits 与 writing-and-editing

写完代码不等于完事。reviewing-code技能会在你提交之前，以 code review 的视角重新审视本次改动。它检查的东西包括：逻辑边界、异常处理、命名的一致性、测试覆盖是否到位、是否有顺手留下的调试代码。最实用的一点是，它会按“必须修改 / 建议修改 / 可选优化”三个等级输出，这样你就能判断哪些要跟，哪些可以先放。

writing-commits则是个低成本高回报的技能。我团队里不少人之前写 commit message 都是“fix bug”这种敷衍级别，装了之后，AI 会基于你暂存的 diff 生成规范的提交信息，按 Conventional Commits 的格式，写清楚这次改动为什么发生、影响范围是什么。说实话，光这一个技能，长期下来就值回安装成本。

writing-and-editing主要面向文案类工作——技术文档、README、发布公告。它会让 AI 先和你确认读者、目的、风格，再动笔，而不是上来就给你一段充斥着“赋能、抓手”的塑料文档。你要是让它写给你的同事看的技术方案，它甚至会主动切换成更克制、更口语化的表达。

3.4 技能速查表

提醒：不同版本的实际技能名和命令可能有细微差异，以你本地/help skills列出的为准。别死记命令，核心是记住“什么阶段用什么技能”。

4. 从零到一跑通一个需求：完整实操流程

4.1 实操案例：给一个 Python Web 项目加用户注册接口

空谈概念没意思，我用一个具体场景展示 superpowers 全流程怎么跑。假设我有一个项目，是一个简单的 FastAPI 服务，现在要加一个用户注册接口。

第一步，我会先启动 Claude Code，然后输入：

/brainstorming

它先问我几个问题：注册需要哪些字段？密码要不要加密存储？要不要做邮箱验证？用户名是否允许重复？我逐一回答后，它给出两个候选方案：方案 A 是简单实现，用内置数据库存数据，适合快速迭代；方案 B 是接上独立的用户表并预留认证模块，结构上更完整但短期成本更高。它还会指出我需求里没考虑到的点，比如错误码设计和请求频率限制。

第二步，我接受方案 B 的思路，然后输入：

/creating-plans

它会生成一份计划，大致包含：定义用户模型、写注册接口、做密码哈希、补个最小的验证逻辑、更新测试。每个阶段都带验收标准。我确认计划后，它自动进入下一步。

第三步，用 todo 类技能把计划拆成任务清单，每完成一项就勾掉一项。整个开发过程的可见性强了很多，回头写周报的时候直接抄清单就行。

第四步，进入 TDD 节奏。它会先让我确认期望行为，然后基于行为描述生成一个测试文件：

# test_user_registration.py def test_register_new_user(): client = TestClient(app) resp = client.post("/register", json={"username": "alice", "password": "secret"}) assert resp.status_code == 200

我跑一下，测试自然是红的，因为接口还没写。然后它才引导我写实现：

@app.post("/register") def register(username: str, password: str): hashed = hash_password(password) save_user(username, hashed) return {"status": "ok"}

测试通过后，提示做重构。流程走到这里，功能代码、测试、重构三个环节都齐了。

第五步，输入/reviewing-code对本次改动做审查。它还真的挑出两个值得注意的点：一是 write 操作没做事务保护，二是测试缺少重复用户名的用例。我顺势补掉了。

第六步，输入/writing-commits，它根据 diff 生成了一段规范的提交信息，包括主题、正文和为什么改。提交完成，整个需求闭环跑完。

4.2 技能串联的节奏感

这一段流程走下来，最核心的一条经验是：不要一口气把所有技能一股脑叠上去。很多人刚上手时喜欢连环触发，脑暴完立刻计划、计划完立刻 TDD、TDD 完立刻 review，结果上下文窗口塞满各种模板提示，模型反而容易“看花眼”，产出质量下降。

我的习惯是：每个技能之间，先停下来看一眼产出，确认方向没问题再进入下一步。这个“人为确认点”看似啰嗦，却是防止 AI 跑偏的最有效手段。如果有任何一个中间产出的质量你不满意，哪怕只是觉得方向有点歪，都值得先退回去调整，而不是带着一个糟糕假设往下走。

另外，如果你不想手动控制节奏，可以直接观察元技能的行为。它会主动说类似“基于当前状态，我建议下一步使用 creating-plans”这样的话。在早期，你也可以让它只管指挥、自己只负责确认，体验会相当顺手。

4.3 让产出质量更高的几个习惯

• 给足上下文：superpowers 再怎么厉害，也需要项目背景。开工前让 Claude 先读一遍项目 README 和核心模块的代码，产出质量会明显上一个台阶。
• 修改技能本身：所有 SKILL.md 都是普通文本，你完全可以把团队规范写进去。比如要求代码里必须带注释、禁止在接口里 print 日志，直接加进对应技能的指令里，效果立竿见影。
• 按阶段清理上下文：长会话里上下文会越塞越满，技能工具也会变得不灵敏。做完一个阶段，果断开新会话，用 todo 清单和计划文档作为上下文传给新会话继续干。

5. 常见问题与排查实录

5.1 技能不生效怎么办

这是出现频率最高的问题。装上之后输入/brainstorming，结果提示不可用或者根本没反应。排查思路按照下面的顺序走：

第一步，确认加载路径。运行/help skills，看看技能列表里到底有没有。如果没有，回查 2.3 节的目录结构，别靠猜，直接ls看目录是否存在。

第二步，确认命令拼写。技能名可能和你想的不一样，比如可能是brainstorming而不是brainstorm。以列表为准。

第三步，确认插件安装状态。如果你是走插件市场安装的，输入/plugin打开面板看 superpowers 是否显示已启用，有的版本安装后还需要手动启用。

第四步，重启会话。技能加载在部分版本中是在会话启动阶段完成的，装完插件不重启就立刻用，踩空概率很高。这是一个很蠢但非常常见的坑。

5.2 质量不稳定怎么排查

同样是/brainstorming，有时候输出质量惊艳，有时候就感觉在走过场。这种情况多半出在“上下文状态”上。

如果当前会话已经聊了很久，上下文窗口被各种历史话题占满，技能能发挥的空间自然就小。处理办法就是我前面说的：新开会话，把必要信息重新喂进去。

还有一类原因是“约束不清晰”。技能本身只是流程引导，被你输入的模糊信息带着走，结果自然模糊。你给出的背景、约束越具体，技能的产出越扎实。

5.3 问题速查表

排查的核心原则就一条：先确认加载，再确认触发，最后才怀疑质量问题。

最后再分享一个我自己的体会。superpowers 刚出来的时候，我也觉得它不过是给提示词套了个壳，但用久了才发现，它最大的价值不是让 AI 多写几行代码，而是让 AI 的“做事方式”变得可以预期、可以审查、可以持续改进。你不再面对一个每次行为都随缘的黑盒，而是有一个能讲清楚“接下来该干什么、为什么这么干”的同事。如果你还没试过，建议挑一个最小的项目，把安装、验证、跑一遍完整流程走通。刚开始可能会不习惯它那些“繁琐”的确认步骤，但等你体会到少踩坑、少返工的好处，大概率就回不去了。