用过 Claude Code 一段时间的人多少都会有同一种感觉模型本身是很强但真正拉开效率差距的是“怎么干活”这套方法论有没有被提前讲清楚。拿到一个含糊的需求是先追问还是直接开写写完代码要不要补测试报错之后是瞎试还是有套路地定位这些看着都是常识可真到实操里大多数人是凭感觉走AI 也只能跟着你的感觉走。superpowers 就是冲着这个问题来的。它是 Jesse VincentGitHub 上叫 obra开源的一套 Claude Code skills 技能包装上之后Claude Code 会多出一整套带明确触发条件、按场景组织的工作技能——帮你做头脑风暴、写 PRD、拆实施计划、按 TDD 节奏写代码、系统化排错、做代码审查和项目复盘。社区里聊 Claude Code 插件化、技能加载、Agent 工作流的时候这个项目被反复点名不是没有原因的。这篇文章按实际使用顺序来讲它到底解决了什么问题、怎么安装、里面有哪些 skills、日常怎么把这套技能“引入”到项目里并组合着用最后是我自己踩过的坑和排查记录。不管你是刚听说这个词还是已经装完想深挖读一遍应该都能找到能直接抄的东西。1. superpowers 是什么给 Claude Code 补上一套“职业级工作法”1.1 为什么需要 skills先搞懂技能是怎么工作的装 superpowers 之前得先明白 Claude Code 的 skills 机制到底是怎么运作的。简单说它就是在约定好的目录里放“说明手册”Claude 在会话启动时会扫一遍每本手册的名字和适用场景也就是 YAML 头里的 description 字段然后在任务命中场景时把对应手册的全文读进来按里面的步骤执行。这跟直接把提示词塞进 CLAUDE.md 是两回事。CLAUDE.md 是“每次会话都要读的长期记忆”写太长每轮对话都会占用上下文skill 是“按需加载的操作手册”平时只占一行描述用到的时候才把全文翻出来。打个比方CLAUDE.md 像是贴在工位上的岗位职责skills 像是一整排放在旁边的 SOP 手册遇到对应场景才抽出来读。所以它既省 token又不会被模型当成日常背景噪音忽略掉。superpowers 本质上就是往这个技能目录里放了一批编写质量很高的 SOP。它没有动模型本身也没有改 Claude Code 的源码纯粹是用一套精心组织的说明文档改变了模型的工作习惯。这也是为什么它对新手和老手都友好你不需要理解复杂机制装上就能感受到行为变化。1.2 设计哲学把资深工程师的习惯变成可复用流程我特意去翻过它的源码。作者是 Perl 社区的老牌维护者所以这套技能的编写思路跟普通“AI 提示词合集”很不一样不是那种“你要好好干”的空话而是非常具体的、甚至有点“轴”的操作规程。三个特点让我印象很深。第一步骤具体到有点反直觉。比如 brainstorming 技能里有一条硬性要求一次只问一个问题不要上来就给方案。单独看你会觉得啰嗦可实际协作里这正是防“AI 抢答”的关键——用户还没想清楚模型就急着抛方案最后只会把需求带偏。第二每个技能都解释了“为什么”。SKILL.md 里除了步骤还有设计理由告诉模型这一步是为了防什么。这个设计很妙因为模型遇到边界情况时能根据“为什么要这么做”合理变通而不是机械执行。第三技能之间有明确的衔接关系。brainstorming 的产物刚好喂给 writing-prdwriting-prd 的产物给 writing-plans 拆步骤计划再交给 executing-plans 执行。它们不是孤立的提示词而是一条流水线。把它的任何一个 SKILL.md 打开看一遍都比看十篇“怎么写提示词”的文章有用。这也是我推荐所有想深入玩技能系统的人先读源码的原因。2. 安装 superpowers 的两种方式插件安装与手动复制附验证方法2.1 方式一通过插件机制安装推荐Claude Code 最近几个版本支持插件机制superpowers 也走这条路。在会话里打开插件面板输入/plugin然后添加 obra 的插件源并安装新版 CLI 也可以直接执行claude plugin install obra/superpowers。不同小版本的命令措辞会有一点差异如果你那边命令对不上以仓库 README 为准。插件方式的好处是升级省心。装完之后插件会负责把技能同步到正确位置后续作者更新也能直接通过插件管理拉取不会在本地留下一堆再也更新不了的旧副本。如果你只是想试试水我建议优先用这种方式。需要提醒一句如果你的 Claude Code 版本比较老可能根本没有插件入口。遇到这种情况别急下面的手动方式一样能装不挑版本。2.2 方式二手动克隆并复制到 skills 目录手动装一共三行命令git clone https://github.com/obra/superpowers.git mkdir -p ~/.claude/skills cp -R superpowers/skills/* ~/.claude/skills/~/.claude/skills是用户级技能目录只要账号在这台机器上登录所有项目都能用。如果你只想给某个项目装把技能放进那个项目的.claude/skills/目录即可。这里必须强调一个细节目录结构必须长成下面这样多一层少一层都不行。~/.claude/skills/ brainstorming/ SKILL.md writing-plans/ SKILL.md ...很多人栽在cp -R superpowers ~/.claude/skills/这种写法上结果变成了~/.claude/skills/superpowers/skills/brainstorming/SKILL.md多套了一层目录Claude 根本扫不到。要复制的是仓库里skills/这个子目录下的内容不是整个仓库。2.3 装完怎么验证三步确认技能真的被加载装完别急着开干先花一分钟确认加载状态避免后面浪费几分钟才发现没装上。我的验证顺序是在终端里跑ls ~/.claude/skills/看是不是有一串技能目录名。新开一个 Claude Code 会话直接问“你现在有哪些可用的 skills”它应该会列出各个技能的名称和适用场景。手动点名测一个“请用 brainstorming 技能和我讨论一个想法。”如果它真的按技能套路走比如一次只问一个问题而不是直接给方案说明加载正常。注意如果是在会话进行中才完成安装的必须重启会话再验证。技能的扫描发生在会话启动阶段中途装的在本会话里不会生效。3. superpowers 里有哪些 skills按需求、编码、复盘三阶段整理的清单3.1 需求期的三件套把“想法”变成“能执行的东西”**brainstorming头脑风暴**是入口技能。它专门处理“我有个模糊想法”的场景。它会用连续提问把需求边界一点点勾出来而且严格执行一次一问绝不一口气抛一堆问题或用五页分析砸晕你。用的时候你会觉得节奏慢但需求质量明显比裸聊高。**writing-prd写产品需求文档**负责把聊清楚的想法落成结构化文档通常包含背景、目标、用户故事、验收标准和边界反例。有了这份 PRD后面不管是自己手写还是让 Claude 实现都有一个能对齐的标的。我习惯把 PRD 直接存在项目里当文档用写代码时随手翻。**writing-plans写实施计划**是把 PRD 变成一步步的施工图拆解任务、标注依赖、写明每步产物和测试思路。它的输出格式带着编号和检查点是下一步执行阶段的直接输入不是给人肉眼看个大概的。技能输入输出典型触发词brainstorming模糊想法确认过的需求点“帮我理一下”“还没想清楚”writing-prd确认过的想法产品需求文档“写成 PRD”writing-plansPRD 或需求实施计划“拆个计划”3.2 编码执行期从计划到代码再到排错**executing-plans执行计划**是配合 writing-plans 使用的主执行技能。它会按计划逐步推进每完成一步就检查产物、更新进度不跳步、不擅自扩大范围。长任务里模型特别容易做着做着跑偏这个技能就是用来拴住它的。**tdd测试驱动开发**把红绿重构循环固化成了操作流程先写一个失败的测试再写最小实现让它通过最后重构。技能里还嵌入了驱动者、导航者这类分工模式的建议处理复杂功能时很实用。**debugging系统化排错**是让我对这套技能路转粉的那一个。遇到 bug 时它会强制 Claude 先稳定复现再缩小范围、列出假设、逐个验证、找到根因最后才动手修复。整个过程核心思想是“不猜按流程走”比让模型瞎试高效太多。3.3 审查与复盘期做得完不等于做得好**system-critic系统批评**适合在动手之前用。它会刻意站在反面给方案挑刺边界没覆盖、依赖选得重、风险点没列全。有句话叫“先让 AI 批评你一次再让它帮你写代码”就能少很多返工。**code-review / requesting-code-review代码评审**把代码审查变成有维度的检查正确性、可读性、边界条件、依赖影响、性能隐患都要过一遍。提交大改动之前走一轮能抓住不少肉眼容易漏的问题。**retrospective复盘**在阶段收尾时用回顾哪些做法省了时间、哪些坑浪费了生命总结成改进项。短期看它不产出代码时间拉长它才是提升人机协作效率最关键的一环。老实说技能清单会随版本变化上面列的是我当前环境里实际在用的核心项。给我的整体感觉是这不是一堆命令而是一个经验丰富的工程师把工作习惯拆成了教学手册每个手册解决一类高频场景。4. 怎么引入这些技能自动匹配、手动点名和一条完整使用链路4.1 自动匹配机制把“说明”写清楚技能才会被召唤Claude 每次会话启动时会读取可用技能的 name 和 description形成一张“技能索引”。之后你说的每一句话它都会拿去和索引里的描述做匹配匹配上了就加载技能全文按里面的流程走。所以 description 的写法直接决定技能触发率。superpowers 的写法是很好的模板主语是“什么时候用”而不是“这个技能是什么”。比如某个技能的描述写“当用户需要将模糊想法梳理成清晰需求时使用”比“这是一个头脑风暴工具”要有效得多。如果你以后想写自己的技能description 是第一个要认真打磨的地方。这里还有个常被忽略的点技能索引本身是要占上下文的装得越多索引越大。技能不是越多越好。我的建议是先全量安装跑两三周后再把不常用的裁剪掉只留真正高频的那几个。4.2 手动点名把技能名直接写进你的话里自动匹配再好关键时刻都不如手动点名稳。实用说法参考这些“用 brainstorming 把‘每周自动汇总阅读笔记’这个想法聊清楚。”“把刚才聊的内容用 writing-prd 写成需求文档。”“按 PRD 用 writing-plans 出计划先控制在 8 步以内。”“动手写之前用 system-critic 把方案批一遍。”“这个 bug 用 debugging 技能排查。”“今天的工作收个尾用 retrospective 复盘一下。”我的经验是一旦明确点名Claude 基本不会跑偏靠它自己猜场景偶尔会漏。不确定用哪个技能的时候直接问“我现在这种情况应该用哪个 skill”它也会根据描述给你建议。4.3 一条完整链路从“我有个想法”到“能跑的代码”拿我最近做的一个小工具举例。我想做一个“阅读笔记周报生成器”但需求很毛糙。整个流程是这样的第一步我跟 Claude 说“用 brainstorming 帮我”理一个想法每周自动汇总本周的阅读笔记生成一份周报。“它开始提问周报给谁看想包含哪些字段数据源是什么输出格式是 Markdown 还是邮件一次一个问题聊了大概十分钟需求就清晰了。第二步我说“把刚才的内容用 writing-prd 写成 PRD。”它输出了一份文档里面写了目标、用户故事、验收标准还补了两条我自己没想到的边界场景比如“某周没有笔记时应该怎么样”。第三步说“用 writing-plans 出实施计划。”它把任务拆成了获取笔记数据、定义周报模板、生成 Markdown、输出归档路径、写测试等几个步骤每步还标了依赖关系。第四步说“从第一步开始用 executing-plans 执行。”它按顺序实现每完成一步会停下来确认再继续。中途遇到一个日期解析的 bug我切到 debugging 技能它按流程定位到是时区边界问题而不是库本身的问题。最后让 Claude 用 retrospective 复盘了整个开发过程沉淀了几条对下次有用的经验。这条链路才是 superpowers 真正值钱的地方它把一次开发从头到尾编排成了标准动作每一步都知道自己在哪里、要产出什么、接下来干什么。5. 常见问题与避坑记录技能不生效、命名冲突、自定义自己的 skill5.1 技能装了却没生效按顺序查这四件事现象可能原因解决方式Claude 说没有这个技能目录层级不对用find ~/.claude/skills -name SKILL.md查路径刚装上就测试会话没重启新开一个会话再验证自动匹配总漏description 没命中改成手动点名技能名界面里根本没有技能概念Claude Code 版本太旧claude --version确认后升级目录层级是我见过最多人踩的坑。正确的检查命令是find ~/.claude/skills -name SKILL.md如果输出里出现superpowers/skills/这种多余层级就是复制时把整个仓库拷进去了重新按 2.2 的cp -R superpowers/skills/*来一次就行。5.2 命名冲突与覆盖规则项目级说了算技能也有优先级问题。项目级.claude/skills会覆盖用户级~/.claude/skills里的同名技能。如果你给某个项目放了自己写的同名技能行为会整个替换成你的版本superpowers 的原始技能在这个项目里就等于不生效。另一个坑是卸载不干净。插件安装后如果手动改过目录移除插件时可能会在~/.claude/skills里留下软链或副本。删了插件但技能还在是很常见的“幽灵”现象。清理时先把两个目录都看一眼别只处理一边。5.3 进阶玩法以 superpowers 为模板写一个你自己的 skill技能系统最大的乐趣在于可以自己扩展。借鉴 superpowers 的格式一个最小的自定义技能长这样--- name: commit-message description: 当用户需要生成 git commit message 时使用。 --- 生成 commit message 的步骤 1. 先运行 git diff --stat 和 git diff 查看改动范围。 2. 用“一句主标题 必要时补充正文”的结构。 3. 主标题不超过 50 个字符动词开头使用现在时。把它保存到~/.claude/skills/commit-message/SKILL.md重启会话就能用。写自定义技能有四个经验值得记下来。第一description 决定触发率要写“什么时候用”触发条件越具体越好。第二正文用编号步骤加示例别写“写得清楚一点”这种空原则。第三长度控制在能一口气读完的范围内每触发一次都消耗 token太长的技能不划算。第四拿不准格式时直接打开一个 superpowers 的 SKILL.md 照着抄字段结构是最快的上手方式。最后说点我自己的体会。最初装完 superpowers翻了一遍技能清单第一反应是“就这这些常识我也能写”。真正用起来之后才发现常识和“可执行的常识”之间差着十万八千里。最让我改观的一次是一个 flaky 测试反复失败我自己看半天没头绪让 Claude 用 debugging 技能走了一遍流程先最小复现再列假设再二分定位最后发现是异步状态没等到位。整个过程它没有“猜”而是顺着流程一点点逼近。从那以后我才真的把技能当回事。给还没试过的人一个建议别想着一次性把所有技能都用熟先挑三个——brainstorming、writing-plans、debugging——放进自己的真实项目里跑两周。等你体会到“它居然会按流程来”的感觉之后自然会想把剩下的技能也打开看看。技能不是魔法它只是把一个资深工程师该有的工作习惯原原本本地教给了模型。