最近在技术社区里刷屏的 superpowers让我身边的开发者群每天都有人问同一个三连它具体怎么用里面到底有哪些 skills想装的话从哪一步开始有人在群里误以为这是什么玄乎的超能力术语其实它是一个真实存在的开源项目——由 GitHub 上的 obraJesse Vincent维护的一套 Claude Code 技能扩展包。和网上那些动不动就几千字的单文件提示词不同superpowers 把一整套工程师工作流拆成了一个个结构化的技能文件让 Claude Code 在接到需求之后能像带过很多项目的老师傅一样先澄清、再计划、按步骤执行、出错时系统排查。这篇文章就把大家最关心的安装方式、技能清单、引入路径和踩坑过程一次拆完想上手的照着操作就行。1. 从答非所问的助手到会走流程的工程师superpowers 想解决的问题1.1 为什么裸奔状态的 Claude Code 经常把活干砸我不止一次在群里看到有人发同一个困惑Claude Code 明明上下文窗口很大模型能力也很强为什么一到真实业务里就像换了个人——你说给登录模块加个记住我功能它可能连 token 过期时间、cookie 还是 localstorage、前端要不要弹窗这些基本约束都不问直接闷头改代码。几轮之后你发现自己想要的跟它做的完全是两回事返工成本比手工写还高。这不是模型笨而是模型在默认状态下没有工程流程纪律。它的训练目标决定了它天生倾向顺着你的话一路往下说、往下写而不是像成熟工程师那样先澄清需求、再做方案、再动手。你给它一个模糊指令它会选择最短路径去完成看起来最像答案的东西遇到报错它也倾向于连续试几种不同写法而不是先停下来看日志、缩小范围、复现最小案例。这种差异在简单 demo 上几乎感觉不到一旦进入真实项目立刻变成立刻兑现的返工时间。superpowers 想解决的正是这个模型很强但工程很飘的断档。它不试图教模型更多知识而是给模型一套可以按步骤执行的行为框架。你可以把它想成一个天才实习生入职后收到了一本公司内部的《标准作业手册》——里面写清楚了接到需求先问什么、动手前要出什么文档、编码时怎么配测试、出错以后按什么顺序排查。实习生的智力本身没变但行为方式变得可预测了质量自然就稳了。1.2 技能体系的本质把优秀工程师的工作流固化进提示词我见过很多人第一次接触 superpowers 时误以为它是某个具体功能比如自动生成代码的插件或者记忆增强工具其实都不是。它的核心机制非常简单把优秀工程师的隐形经验显性化写成一个又一个 Markdown 格式的技能文件每个技能文件里包含了触发条件、操作步骤、输出格式、约束规则。当 Claude Code 在对话里识别到某个任务符合技能描述时就按这个技能规定的流程去执行而不是自由发挥。打个比方你给一个懒散但聪明的同事做培训与其给他讲一百遍方法论不如给他一套先写方案再动手、出错先看日志再改、提交前先自测的强制流程卡。superpowers 干的就是这件事只不过把流程卡变成了模型能直接读取的 skill 文件。这个定位决定了后续所有操作逻辑你安装的并不是某个具体功能模块而是一整套做事方法。理解了这一点你就明白为什么很多人反馈装完以后最大的变化不是代码写得更好看而是整个开发过程终于有了节奏感。2. 揭开技能的盒子SKILL.md 长什么样、Claude 靠什么识别它2.1 从目录到文件所谓技能其实全是一堆 Markdown把 superpowers 克隆到本地之后你会看到它的目录结构其实非常朴素没有任何二进制文件也不依赖独立的服务进程。整体大概是这样的~/.claude/skills/ ├── brainstorming/ │ └── SKILL.md ├── writing-plans/ │ └── SKILL.md ├── executing-plans/ │ └── SKILL.md ├── test-driven-development/ │ └── SKILL.md ├── debugging/ │ └── SKILL.md ├── requesting-code-review/ │ └── SKILL.md └── creating-commit-messages/ └── SKILL.md每个技能目录对应一个独立技能核心文件就是SKILL.md。打开一个 SKILL.md 你会发现结构非常清爽开头有一段 YAML 格式的 frontmatter包含name和description两个关键字段正文则是给模型的人类可读指令一般包含目标、操作步骤、输入输出格式、注意事项和完成标准。举个例子brainstorming 这个技能的描述大意是当用户的需求还模糊、可能涉及多个方案、或需要收集更多信息时使用本技能逐步澄清需求。正文里则规定了严格的行为准则不要直接给出答案每次只提一个关键问题直到所有必要信息都收集齐备才能进入下一步。也就是说这个技能文件本身就是一段完整的提示词工程只是被标准化、模块化地存了下来。2.2 description 是技能的路由表触发全靠它有个问题隔三差五就会在社区里被翻出来Claude Code 装了这么多技能它是怎么知道什么时候该用哪一个的我的理解是它并不会把这几十个技能文件的内容全部塞进上下文——那样上下文很快就爆了。真正起关键作用的是每个技能 frontmatter 里的description字段。Claude 在对话过程中会把用户当前的任务特征和这些描述进行匹配就像后端服务里先读路由表再决定把请求分发给哪个处理函数。如果描述写得精准任务一旦沾边它就会自动进入对应技能流程如果描述写得模糊或者和你的真实任务语言不匹配那技能可能一直沉睡你怎么问它都不触发。这也是我为什么不建议你随便修改技能文件的 description——改乱了技能就等于失联了。如果你非要说 superpowers 有什么魔法这个路由表机制算是最接近魔法的一层。2.3 和普通自定义提示词的区别在哪有些朋友一直手动维护着一套自己的角色扮演提示词觉得和 superpowers 差不多都是让模型按固定格式办事。但用下来之后你会发现差异很大。单文件提示词最大的问题是为了覆盖所有场景你得把所有规则塞进一段提示词里写得越长在长对话里被稀释、遗忘、偏移的风险就越高。今天模型记得后半段规则明天它可能只记得前半段行为一致性很差。superpowers 的做法是反过来的——一个大问题被拆成多个小而专的技能文件按需加载、用完即走。需要澄清需求时只激活 brainstorming需要写计划时只激活 writing-plans编码阶段只激活 TDD 和 executing-plans。每个技能职责单一互相之间没有干扰。把一个大提示词拆成微服务式的技能集群反而比把一个巨型提示词常驻在上下文里稳定得多。我自己实测下来的感受是行为的一致性明显更好了而且出问题的时候知道该去检查哪个文件而不是在一段三千字提示词里大海捞针。3. 安装与引入从 git clone 到插件市场一次讲清3.1 传统方式把整个仓库放进 skills 目录先讲最简单直接的方式也是早期教程里最常见的做法。在命令行里执行克隆命令把 superpowers 仓库放到 Claude Code 的技能目录下git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowersWindows 用户需要注意路径对应的实际位置是%USERPROFILE%\.claude\skills\superpowers在 PowerShell 里可以直接用上面的路径格式。克隆完成之后先别急着开干建议先看一眼目录结构确认仓库根目录下直接就是各个含 SKILL.md 的子目录还是多嵌套了一层目录。因为不同时期的仓库结构调整过有些教程让你克隆到~/.claude/skills下仓库内部就是各个技能目录有些则建议克隆到带仓库名的子目录里。判断标准很简单看最终能不能在~/.claude/skills下面直接看到一系列带 SKILL.md 的文件夹。路径不对后面一切白搭。3.2 插件方式通过 Claude Code 的 /plugin 交互安装如果你的 Claude Code 版本比较新我建议优先走插件方式。和手动克隆相比插件方式的管理更集中后续更新也更方便。操作步骤一般是这样的在 Claude Code 会话里输入/plugin打开插件管理交互界面选择添加 marketplace填入 superpowers 的仓库地址通常是github.com/obra/superpowers然后选择安装插件在列表里勾选 superpowers 并确认。不同的小版本界面文字可能稍有差异我自己在某个版本里看到的选项叫marketplace add换一个版本可能就叫添加市场但大方向一致。插件方式的另一个好处是后续想要更新技能时不需要自己跑到目录里git pull直接在/plugin界面里就能统一更新。如果你是刚接触 Claude Code 的新手直接走这个方式能省掉很多手工维护的麻烦。3.3 CLAUDE.md 的引导配置这一步最容易被忽略我发现一个规律十个装 superpowers 的人里至少有四个会在装完以后跑来问为什么感觉没生效。大多数情况下问题都出在大家没有在CLAUDE.md里写下引导配置。简单说克隆完仓库只代表技能文件存在了但如果一个项目没有告诉 Claude 去关注这套技能它在处理问题时未必会自动想起来去检索这些技能尤其是项目里如果还有大量其他配置说明技能很容易被淹没。建议在项目根目录的CLAUDE.md或者全局的~/.claude/CLAUDE.md末尾追加一段说明内容大意如下本项目安装了一组基于技能的开发流程扩展。开始复杂任务前 先查看 ~/.claude/skills/ 下的技能列表涉及需求澄清时使用 brainstorming 技能动手编码前先使用 writing-plans 制定计划 计划获批后使用 executing-plans 逐步执行编写代码时必须遵循 test-driven-development 技能遇到错误使用 debugging 技能。不要小看这段说明它的作用不是加载技能而是给模型一张项目内部的地图相当于向新人介绍团队里有哪几位老师傅、遇到什么情况该找谁。没有这张地图模型就算手里有技能列表也会优先走自己默认的老路。3.4 安装完成之后怎么验证生效验证其实可以分两步。第一步是确认文件层面没问题直接检查技能目录是否存在且包含预期的子目录ls ~/.claude/skills如果你用的是插件方式安装还可以在/plugin界面里看到 superpowers 的启用状态。第二步是对话层面验证New 一个会话问 Claude Code你现在掌握了哪些技能看它能不能列出 superpowers 相关技能名称。更稳妥的做法是直接给它一个小任务比如用 brainstorming 技能帮我梳理一个给个人网站加搜索功能的需求然后观察它是否进入了连环提问的澄清模式。如果它做到了说明整条链路已经通了。4. 内置技能逐个看哪些值得日常用什么时候触发4.1 brainstorming把模糊想法逼成清晰需求brainstorming 是 superpowers 里最有辨识度的一个技能也是我向新手推荐第一个试用的技能。它的行为模式非常有特点一旦触发它就不会再顺着你的话直接给方案而是开始连环提问。它会每次只问一个关键问题等你的回答之后继续追问下一个直到它认为需求已经足够清晰才会输出一份需求摘要和待确认项列表。第一次用的时候你会觉得有点烦我就想要个 RSS 功能你问我内容范围、更新频率、要不要全文输出干什么但等到需求梳理完你会发现后面写代码时几乎不需要反复改需求了。这套技能本质上是在强迫你用最低的成本把模糊的想法逼成可执行的需求文档省下的是后面写错方向的返工成本。我自己的建议是任何新功能、改需求、思路不清晰的场合都主动引导一下这个技能。4.2 writing-plans 与 executing-plans计划与执行的双人组合如果说 brainstorming 负责把需求问清楚那 writing-plans 就是把清楚的需求落成任务清单。这个技能会把目标拆解成具体的操作步骤标明每一步之间的依赖关系和顺序并给出验收方式。它输出的不是一句轻飘飘的我打算这样做而是一份可以直接照着走的计划文档。真正有意思的是 executing-plans 跟它互补。writing-plans 负责画地图executing-plans 负责按地图一格一格走。executing-plans 触发后模型会严格限定在当前步骤内做完一步回来检查确认无误再进入下一步而不是一次性把整个项目从头到尾生成一遍。这种拆法很像我们平时说的小步快跑每一步都留出了验证空间出了偏差不会像滚雪球一样到最后才暴露。4.3 TDD、debugging、code-review很多人忽略了这三件套在 superpowers 的技能列表里test-driven-development、debugging、requesting-code-review 这三个技能经常被新用户忽略因为大家天然更关注生成代码相关的技能。但实际跑过一段之后我觉得这三件套才是提升工程质量的隐形主力。TDD 技能的核心是先让模型写测试、再写实现代码每一个编码任务都被定义成让测试变绿的过程。debugging 技能则禁止模型瞎猜它会让模型先列证据、看日志、构造最小复现再逐步缩小定位范围。code-review 技能会把模型从写代码的人切换成审查代码的人对当前改动逐条列出问题而不是直接替你修改。这三个技能配合下来代码质量明显更稳尤其是 debug 的效率提升比裸奔状态高了好几倍。下面这张速查表整理了常用的几个技能方便对照使用技能名触发场景核心行为适合谁brainstorming需求模糊、方案不确定连环提问直至需求清晰所有写功能的新人writing-plans需求已明确需要拆解输出带依赖和验收步骤的计划复杂任务、多文件改动executing-plans计划已获批按步骤少量多次执行所有需要落地的编码任务test-driven-development开始写新功能代码先写失败测试再写实现重视回归质量的项目debugging出现报错、行为异常先复现再定位后修复排错经验不足的开发者requesting-code-review提交前、代码合并前以审查视角列出问题多人协作、对外发布creating-commit-messages提交代码时按规范生成提交信息习惯规范提交的团队5. 真实项目里的完整流转一个需求是如何跑完所有技能的5.1 一个再普通不过的功能需求只看单个技能容易有一种颗粒感每个技能好像都挺有道理但它们之间是怎么串起来的我这里用一个例子把流程走一遍。假设我在维护一个个人博客系统想给它加一个 RSS 订阅功能最初的需求描述只有一句话做个 RSS 订阅功能。这个描述如果直接丢给裸奔的 Claude Code它很可能直接去翻配置文件、找 RSS 库然后按自己的理解开干。但在 superpowers 的流程里事情不是这么发展的。5.2 关键轮次里每个技能分别做了什么第一轮Claude Code 识别到需求信息不足调用 brainstorming 技能开始连环提问。它会问你 RSS 版本要 2.0 还是 Atom内容范围是文章还是包含页面更新频率要不要跟发布事件挂钩输出全文还是只输摘要要不要在导航栏加订阅入口。几个问题下来原本一句话的需求变成了有边界、有取舍的需求描述模型还会输出一份简要的需求摘要让我确认。第二轮需求确认之后Claude Code 进入 writing-plans 技能。它开始罗列实施步骤引入 RSS 生成依赖、编写 feed 生成函数、新增/feed.xml路由、设计内容更新策略、补测试用例、在页面加入口。计划里还标明了步骤之间的依赖关系比如路由功能依赖 feed 生成函数完成。第三轮我说开始执行executing-plans 技能接管。模型没有一口气把六个步骤全部做完而是先完成第一步引入依赖并验证再进入第二步。执行到第四步时它遇到了 XML 特殊字符转义导致的报错。如果是在裸奔状态它可能直接改个转义逻辑试试但这次它切换到 debugging 技能先让我贴出现场日志构造最小复现确认是评论内容里包含了未转义字符再修复并补充回归测试。最后全部步骤完成后Claude Code 又触发 requesting-code-review 技能以审查者的身份重新审视了一遍所有改动发现缓存失效时间没有配置主动补上后才提交。整个过程下来需求是提前确认的、步骤是分解过的、错误是定位后修复的、质量是审查过的。这就是 superpowers 在使用中最让我满意的地方——它不是帮你写得更快而是保证整个流程不失控。5.3 协作时容易被忽略的两个细节这个流程走顺之后有两个细节值得提出来。第一个是计划的批准不能是默认的好的最好明确说一句开始执行或按计划执行executing-plans 技能才会严格按照计划一步一步来而不是和 brainstorming 混在一起。第二个是执行过程中如果中途插入一个完全无关的新需求技能的上下文很容易被打断建议让它继续执行当前计划而不是回到之前的工作——后者容易让模型从计划里的某一步重新开始导致步骤重复或遗漏。6. 安装和日常使用中真正容易踩的坑6.1 目录热情放错位置技能列表永远是空的我见过最典型的安装失败案例是把整个 git 仓库克隆完之后没有确认子目录结构就直接开始用。结果 Claude Code 的技能列表始终是空的因为模型期望的扫描路径下根本找不到带 SKILL.md 的文件。如果你ls ~/.claude/skills之后发现里面既不是技能子目录、也没有任何 SKILL.md 文件基本就是目录层级不对。解决办法是进入目录深度看一下把包含所有技能子目录的那一层整理成~/.claude/skills的直接子项。6.2 技能不触发十有八九是路由或引导出了问题如果你已经确认技能文件都在但 Claude 就是不调用它们我的排查顺序一般是这样的先检查项目根目录的CLAUDE.md里有没有我刚才提到的那段引导说明没有就先补上再检查技能文件的 frontmatter 是否完整特别是name和description字段有没有丢失还要检查技能描述所用的语言和你的提问语言是否匹配描述是英文的话中文提问可能匹配度会下降如果你的描述被自己改过先恢复原样再试。如果上面都排除了最好的办法是显式点名请使用 brainstorming 技能来处理这个需求。如果显式点名后技能生效说明路由逻辑没问题只是之前触发条件没满足如果显式点名后也没反应那才需要怀疑文件路径或版本支持问题。6.3 版本更新和重复安装升级反而带来新问题superpowers 的迭代速度不慢社区也活跃所以你会发现它时不时会更新技能内容。老用户容易踩的坑是之前用 git 方式安装在~/.claude/skills后来又通过 plugin 方式安装了一遍两套技能同时存在导致模型在同一个场景里被两个版本的技能指令拉扯行为变得很不稳定。我的建议是二选一要么保持 git 方式并定期git pull要么彻底走插件方式并在/plugin里确认没有旧目录残留。另外从旧版本升级后如果发现某个技能的行为跟文档描述不一致先到项目的 GitHub issues 里搜一下多半是缓存或版本问题不需要自己在本地反复折腾。6.4 我建议的排查顺序一条条照着来如果哪天你觉得 superpowers好像没工作了别急着卸载重装按这个顺序排查下来基本能定位检查~/.claude/skills目录下技能文件是否真实存在确认当前 Claude Code 版本是否支持技能或插件机制老版本需要升级确认项目CLAUDE.md里没有被注释掉或者覆盖掉引导配置开启新的会话配合日志确认模型是否提到过技能相关内容显式点名某个技能测试判断是路由问题还是执行问题去开源仓库的 issues 搜索not triggerednot installed等关键词。拿我自己来说在实际项目里跑了两个多月 superpowers 之后最明显的变化倒不是生成速度而是模型终于开始会拒绝了——需求不清的时候它会先提问而不是闷头写出错的时候会先看证据而不是反复试错。如果你刚装完觉得好像没什么区别别急着卸载先拿一个低风险的小功能从 brainstorming 到 plan 再到 execute 完整走一遍你大概率会发现这套技能的价值不在某一次代码生成有多惊艳而在整个开发流程终于变得有章法了。