作为一个经常折腾 Claude Code 的人最近被问得最多的一个词就是 superpowers。这个标题看着像游戏里主角的外挂实际上是社区里非常流行的一套技能集skills。打开任何一个 AI 编程相关的讨论区十个人里至少有八个人在聊怎么装、怎么用剩下两个在问“到底是啥”。这篇东西就把我这几周从安装到实战踩坑的全部过程捋一遍事无巨细该给的命令给全该说的原理说透能帮你少走不少弯路。1. 先别急着装搞清楚 superpowers 到底给 Claude 加了什么1.1 一种“技能”而不是“插件”很多人第一反应是superpowers 是不是类似 ChatGPT 插件的扩展包装上之后模型就会多几个 API、多几个工具这么理解不算全错但容易误导。本质上superpowers 是一堆写得很好的、结构化的工作流文档——它们以SKILL.md文件的形式存在于你的项目目录里。Claude 读这些文件之后就“学会”了在对应场景下按一套更规范、更完整的流程去执行。用一个生活化的类比你把一份《红烧肉标准化菜谱》递给一个厨艺不错的师傅他看一遍就知道要先焯水、再炒糖色、然后小火慢炖。你并没有给他一口新锅也没有给他一把新刀但做出来的菜品控明显稳定了。superpowers 就是这份菜谱只不过它是专门针对软件开发流程写的并且是以 AI 能读懂、能照做的格式写的。所以它和传统意义上的插件有本质区别。传统插件往往是给宿主程序增加功能而 superpowers 是给模型增加“做事的章法”。同一个模型没有技能时可能想到哪做到哪有了技能之后它会先收集需求、列计划、再动手、写测试、最后自查。这一整套行为就是我们常说的 Agentic Workflow也就是代理式工作流。1.2 从“回答问题”到“按流程干活”以前我们用 Claude 写代码更多时候是在“问问题”帮我看这个报错、帮我写个函数、帮我解释这段逻辑。模型虽然能输出一大段代码但它不关心你项目里有没有测试、代码风格统不统一、有没有先理解需求就盲目开工。superpowers 的设计思路就是强行把模型的工作方式从“回答者”变成“协作者”。它包含了诸如 brainstorming头脑风暴、planning计划、implementing实施、debugging调试、TDD测试驱动开发、code review代码审查等一整套技能。每个技能文件里都写了“什么时候用”“怎么用”“用完之后要输出什么”。模型在合适的时机读取了对应技能就会按里面的步骤一步步来。这套思路很聪明因为它的核心不是给模型塞知识而是给模型塞流程。知识模型本来就有缺的是在复杂任务里的自我管理能力。这也是为什么很多人在装完之后的第一感受是它怎么忽然变得“啰嗦”但“靠谱”了。所谓啰嗦是因为它会先提问、先规划所谓靠谱是因为它真能避免很多低级错误。1.3 为什么偏偏是它火了说句公道话在能力类似的项目里superpowers 并不是唯一一个做 skills 的但它有几个非常突出的优势。第一作者 Jesse Vincent社区常用 ID 是 obra本身就是 Perl 社区的老兵搞开源项目出身文档写得极其细致每个技能都像一份正经的团队规范而不是随便几句提示词。第二它的安装方式被设计成和 Claude Code 的插件机制无缝衔接直接走 marketplace 就能装不需要你去复制粘贴一堆文件。第三社区反馈非常快从项目爆火开始几乎每周都有技能更新bug 修复也积极。客观说它火起来还有一个时机因素正好赶上各家大模型在 agent 能力上快速迭代大家发现“模型能力”和“模型表现”之间差着很大一截而 superpowers 恰好把“表现”这一层给补上了。于是一传十、十传百成了很多人接入 agentic coding 的第一站。2. 零基础安装路线marketplace、plugin、skills 三层结构2.1 安装前需要满足的环境条件先把环境说清楚。superpowers 目前的载体是 Claude Code所以你得先有一个能正常运行的 Claude Code 环境。我在实测时用的是较新的稳定版本建议你装之前把 Claude Code 升级到最新版因为插件机制迭代很快老版本容易出现安装成功但加载不出来的情况。另外它依赖 Node.js 环境如果你的机器上还没有 Node先去装一个 LTS 版本。安装完 Node 之后重新打开终端确认claude命令能正常调用。如果你是第一次用 Claude Code需要先登录你的 Claude 账号这个在初次启动时会引导你完成没什么难度。还需要提醒一点如果你是在公司内网或者代理环境里使用网络策略可能会影响 marketplace 拉取。我遇到过终端能访问外网但 marketplace 添加失败的情况排查了一圈发现是代理环境阻断了部分请求。这时候把代理在白名单里放行或者临时关闭代理再执行安装命令就好了。2.2 一步步把 superpowers 装进来安装路径其实很透明就三步添加 marketplace安装插件让插件生效。第一步在终端里进入你想启用 superpowers 的项目目录然后运行claude plugin marketplace add obra/superpowers-marketplace这一句的作用是把一个远程插件市场注册到 Claude Code 的配置里。marketplace 可以理解成一个软件源类似你手机上的应用商店。obra 是作者的 GitHub 用户名superpowers-marketplace 是市场仓库名。第二步添加成功之后运行claude plugin install superpowers这句话会从刚才添加的市场里找到 superpowers 插件并安装。如果你想看有哪些可选插件可以在交互界面里输入/plugin会弹出一个插件管理面板能直接浏览 marketplace 里所有可安装的项目。还有一个更图形化的做法直接在 Claude Code 的交互窗口里输入斜杠命令/plugin按提示操作用菜单完成 marketplace 添加和插件安装。如果你不习惯记忆命令行用这套交互式方式更直观。第三步安装完成后重启 Claude Code 会话。有些版本支持热加载但我实测下来重启会话是最稳妥的能保证所有技能文件都被正确扫描进知识范围。2.3 装完怎么验证装没装成功不能只看命令行有没有输出“success”。我自己习惯用三步验证法先看插件目录运行claude plugin list如果输出里能列出 superpowers 相关条目说明插件本身的安装是成功的。然后进入项目目录确认是否存在.claude/plugins/目录并在里面找superpowers相关文件夹。这个目录是技能文件的落盘位置里面会有skills子目录每个子目录就是一个独立的技能每个技能目录里都有一个SKILL.md文件。最后也是最直观的一步在 Claude Code 对话框里输入/看斜杠命令列表里有没有出现 superpowers 相关的命令。如果有说明它已经被 Claude 正确加载。这时候你可以直接输入/superpowers它会输出当前可用的技能列表以及简单的使用说明。2.4 底层文件结构一览装完之后不要急着关终端我建议你花五分钟看看文件结构这对接下来的理解很有帮助。.claude/ └── plugins/ └── superpowers/ ├── skills/ │ ├── brainstorming/ │ │ └── SKILL.md │ ├── planning/ │ │ └── SKILL.md │ ├── tdd/ │ │ └── SKILL.md │ └── ... └── ...每个SKILL.md都包含了两部分frontmatter 元信息技能名字、描述、何时使用和正文工作流描述。frontmatter 是给模型做快速匹配用的正文是触发后要遵循的具体流程。搞懂这个结构之后你后面想自己加技能、改技能就有地方下手了。3. 技能目录拆解能直接白嫖的“超能力”清单3.1 规划类技能Brainstorming 与 Planning装完 superpowers 之后你先别急着让它写代码我建议先试两个技能brainstorming 和 planning。Brainstorming头脑风暴技能的核心作用是把一个模糊的念头变成一个清晰的需求文档。它会引导 Claude 向你提一系列问题你想解决什么问题、有没有限制条件、预期成果是什么、有没有参考案例。回答完之后它会把所有信息组织成一个结构化的需求说明并输出到一个scratchpad文件里。这个 scratchpad 相当于一个草稿本后续所有工作都围绕它展开。很多人觉得这一步多余但我在实际项目里发现它恰恰是最省时间的环节。模型在没有明确约束的情况下写出来的代码经常是“看起来对但细节全错”。花十分钟把需求聊透后来能省下几个小时的重构。Planning计划技能是在需求明确后生成一份可执行的开发计划。它会把任务拆成一个个具体的步骤每个步骤标注改动文件和验收标准。厉害的地方在于它生成的计划不是那种假大空的“整体重构系统”而是会细致到“新建src/api/client.ts实现getUserInfo方法并添加对应单元测试”这种程度。做完计划之后它会主动询问你是否确认确认后才进入到实施阶段。3.2 工程类技能Implement、Refactor、ReviewImplement实施技能是主力。它做的事情是读取之前确认的计划按步骤落实代码实现。它会分文件处理每个文件改动后都会说明改了哪些部分并在完成一个小阶段后停下来请你确认。这种“小步快跑”的节奏非常舒服出了问题不用推翻重来直接回退到上一个确认点就行。Refactor重构技能我强烈推荐配合 Claude Code 的编辑能力相当好用。它的流程是先分析现有代码结构找出重复和坏味道然后提出重构方案征得同意后再动手。注意它做重构时不会顺带改功能逻辑每一步都尽量保持行为不变这一点对生产代码尤为重要。Review审查技能则像是一个自带评审专家的 Code Review。它会从头到尾读一遍你指定的文件或代码范围按“问题严重程度”分级输出意见阻塞级、建议级、风格级。阻塞级会给出具体原因和修改建议。你还可以在触发它的时候指定关注点比如“只关注安全性问题”或“只关注性能问题”。3.3 测试与调试类技能TDD、Debugging、TroubleshootingTDD测试驱动开发是 superpowers 里被讨论最多的技能没有之一。它的核心流程可以用“红-绿-重构”来概括先写一个失败的测试再写刚好能让测试通过的实现代码最后在绿灯状态下做重构。技能文件里写得很细连“测试先行的三个层次输入输出、行为交互、异常分支”这种体会都考虑到了。Debugging调试技能则针对“遇到报错不知道从哪查起”的场景。它不会让你直接把整段报错丢过来而是引导你提供最小复现步骤、相关代码片段、期望行为与实际行为的差异。然后它会形成一个“问题假设→验证→缩小范围”的闭环整个过程像一个真正的调试者在做二分定位。我印象最深的一次是它通过排除法把问题定位到了一个看似无关的配置项那是我自己埋头查了一个多小时都没发现的问题。Troubleshooting排障技能比 Debugging 更大范围它适用于“系统不可用”或“行为异常”但没明确报错的情况。它会让 AI 充当一个故障调查员按时间线收集证据、查看日志、确认变更记录然后给出一个可能性排序的根因清单。这个技能部署在线上环境排查时特别好用前提是你愿意多给它喂一些上下文。3.4 配套的上下文与生命周期技能除了上面这些核心技能superpowers 还包含一些更“软性”的技能比如技能发现、工作总结、子代理分工等。它们不会直接产出代码但会影响整体协作效率。举个例子它有一个技能会在你每次会话结束时生成一份“进度快照”记录当前做到哪一步、下一步做什么、还有哪些待确认项。下次会话重新打开时你只要让它读取这份快照就能无缝接续上次的工作。这个能力听起来不起眼但对代理式编程至关重要——因为模型上下文窗口有限一旦会话断掉重新构建上下文是很大的浪费。你会发现这些技能之间并不是孤立的而是一套完整的工作循环先 brainstorm 明确需求再 planning 制定计划然后 implement 逐步实现测试不过就 debugging代码成型后 review最后 refactor 收尾。这正是 superpowers 的核心价值它把一到多个连续的工作流串了起来。4. 实战用法从需求到测试闭环的一次完整联动4.1 实战场景说明理论知识说再多不如完整过一遍实际流程。我拿最近做的一个小工具来举例需求很简单写一个命令行工具读取一个 JSON 配置文件按规则过滤出符合条件的日志条目并输出到新文件。这种需求如果直接让 Claude 写一分钟代码就出来了。但按 superpowers 的完整流程走能明显看出质量差异尤其表现在代码的健壮性和可维护性上。4.2 第 1 阶段头脑风暴对话一开始我直接输入我想实现一个日志过滤工具用法是读取 JSON 配置文件过滤日志文件里的数据行。请用 brainstorming 技能帮我把需求理一下。这时候 Claude 启动了头脑风暴技能没有直接写代码而是问了我几个问题配置文件的结构是什么样日志文件是什么格式过滤条件支持哪些逻辑输出格式要求是什么有没有性能要求大概五六个问题之后它在 scratchpad 里整理出了一份需求文档包括输入输出边界、核心功能点、非功能需求还有一个“不做的事”的列表。这里最让我满意的是“不做的事”这个部分。它明确排除了“自动发现日志格式”“动态修改配置文件”这些不相关需求。很多代码乱象源头就是需求边界没划清AI 拿到模糊指令后自由发挥最后加了一大堆多余功能。4.3 第 2 阶段制定计划需求确认后我输入请基于 scratchpad 里的需求文档用 planning 技能安排开发计划。它生成了一份大概 7 个步骤的计划搭建项目结构初始化package.json和 TypeScript 配置。定义配置文件的数据类型和示例文件。实现配置文件读取与校验模块。实现日志解析模块抽象出统一的日志行结构。实现过滤引擎支持包含、排除、正则、时间范围等条件。实现 CLI 入口接管命令行交互和输出。编写单元测试覆盖过滤边界情况。每个步骤后面都跟了验收标准比如第 3 步的验收标准是“配置文件缺失时给出明确报错字段类型错误时指出具体字段路径”。这份计划直接成为了后续工作的“合同”AI 不会偏离它我自己也知道每一步在干什么。4.4 第 3 阶段实现与自我检查计划确认后我输入/implement开始逐步实施。Claude 按计划从第 1 步开始先搭建项目骨架。一个细节让我印象深刻它在生成package.json时主动询问要用 ESM 还是 CommonJS 规范而不是默认选一个。这种“把决策权交还人类”的行为正是技能文件里明确定义的。第 4 步解析日志模块时它停下来问我“不同日志行的字段分隔符是否统一我在计划里按统一分隔符实现如果有变体需要单独设计适配层。”这就是“小步确认”的实际价值——它避免了做完一大堆之后才发现方向错了。到第 5 步过滤引擎的时候它写出了核心过滤逻辑然后主动调用了一次 review 技能对刚写的代码做自查。我留意到它发现了一个边界 bug当配置里同时存在“包含条件”和“排除条件”时先做包含过滤再做排除过滤会导致排除条件永远生效不了。它当场修正了逻辑顺序并补了注释。4.5 第 4 阶段测试与调试闭环代码实现完之后我输入用 TDD 技能检查测试覆盖然后把缺失的测试补上。它没有立刻补测试而是先分析现有测试覆盖情况。看完之后列出了一个矩阵正常行过滤、空文件、格式错误行、无匹配项、所有条件叠加、超长行、敏感字符等等。然后一张一张地补。补到“无匹配项”用例时它还顺便修了一个 CLI 输出细节原来无匹配时程序直接静默退出改成显式输出一行提示这样用户在自动化脚本里能明确感知结果。整个流程走完后我让 Claude 执行测试命令全部通过。最后它生成了一份简短的收尾报告列了改了哪些文件、测试覆盖率、还有哪些遗留的待确认项。整个过程连贯自然像和一个很有经验的结对编程伙伴在配合而不是在用一个只会吐代码的机器。5. 实测中的坑以及我总结的避坑经验5.1 坑 1模型版本与技能质量直接挂钩superpowers 的技能文件写得再好底层模型的能力依然是天花板。我在旧版模型上测试时planning 技能生成的计划明显粗糙步骤之间逻辑断层甚至会出现在计划里写“然后实现所有剩余功能”这种无效描述。如果你发现装完 superpowers 之后它表现得“不聪明”先别急着卸载第一步是确认你用的模型版本是不是最新、能力是否足够支撑这个技能库的复杂度。技能文件里那些精细的流程指令需要模型有足够强的上下文遵循能力才能真正执行。老版本模型不是不能用但体验会大打折扣。5.2 坑 2技能触发时机和上下文浓度另一个常见问题是技能“触发晚了”。你明明给了需求模型却没有先调 brainstorming直接开写。我查过这类情况多半是上下文里缺少“当前处于什么阶段”的提示。superpowers 的技能机制依赖模型对场景的识别而场景识别依赖上下文浓度。如果你的项目目录里有大量旧代码和无关文件模型容易被“带跑”。解决办法是在对话开头明确告诉它“使用哪个技能”比如直接说“请先调用 planning 技能制定计划”而不是放任它自由判断。等你对这套技能的触发习惯熟悉了再慢慢放宽让它自动调度。5.3 坑 3错误地把 superpowers 当成“全自动”这是最多人误解的一点。superpowers 并不意味着你可以当甩手掌柜。它定义的关键步骤几乎都有“暂停点”头脑风暴后等待确认、计划完成后询问是否批准、实现关键模块时停下来征询意见。这些暂停点是刻意设计的目的是让人类保持决策权。刚开始用时我对这种“频繁打断”很不适应总觉得效率低了。后来才想明白这正是它靠谱的来源。它强迫你在每个高风险节点上花半分钟时间看一眼避免模型在错误方向上狂奔。如果有一天你觉得它问得少了反而要警惕可能它没有按标准流程走。5.4 关于权限和工具配置superpowers 在运行过程中经常要写文件、跑测试、执行命令行工具。如果你的 Claude Code 没有开启工具权限或者项目目录的写入权限受限技能会卡在某个步骤上反复报错但报错原因经常不明显容易让人误以为是技能本身的 bug。我建议在项目启动时就把权限配宽松一点或者在第一次提示工具调用时选择“允许所有此项目工具调用”不要每次都临时确认。频繁弹权限确认框不仅烦还会打断技能内部的流程衔接导致模型忘记当前步骤。生产项目里至少给测试命令和文件读写开白名单。5.5 版本更新带来的文件冲突superpowers 更新频率高有时你本地改过的技能文件会被新版本覆盖有时新版本会引入之前没有的依赖。我遇到过更新插件之后本地自定义的技能突然失效的情况。建议把自定义技能放在独立目录里做好和原始技能的隔离。这样升级插件时你的自定义部分不会因为文件覆盖而丢失。另一个办法是给自己写的技能加上单独的 frontmatter 标记降低被合并覆盖的概率。6. 进阶玩法把默认技能改成你自己的超能力6.1 编辑已有技能在用了一段时间默认技能后你会发现有些流程不符合自己的习惯。比如我团队里的代码规范要求所有函数必须带 JSDoc 注释默认的 implement 技能没有这个步骤。解决方案很简单直接编辑SKILL.md文件。你可以在 implement 技能的正文里加一节“所有新建函数必须输出 JSDoc 注释内容包括功能说明、参数类型、返回值类型”。Claude 读取技能时就会按这个要求执行。需要注意的是SKILL.md的编写有讲究。frontmatter 里的 description 字段决定了技能何时被触发写得越精确触发越准。正文部分要使用明确的祈使句比如“必须”“需要”“不要”避免模糊表达。你可以把它当成一份给初级工程师读的作业指导书越具体执行越稳定。6.2 私有 marketplace 与团队共享如果你在一个团队里工作让每个成员都去修改自己本地的技能文件协调成本很高。更合理的做法是搭建一个私有 marketplace把团队的规范技能统一发到那里成员直接通过claude plugin marketplace add添加你的私有仓库地址即可。具体操作不复杂把技能目录推到 Git 仓库在根目录放好必要的 marketplace 元数据然后团队成员通过 marketplace 地址安装。这样你更新技能所有人拉取后就能同步生效。团队里的新人也不用再挨个教“怎么设置规范”装完插件就有了。6.3 与 MCP 和官方扩展的组合使用superpowers 和 MCP模型上下文协议Model Context Protocol工具可以一起用两者并不冲突。MCP 主要给模型提供外部数据源和操作外部系统的能力而 superpowers 管的是工作流程。一个解决“能做什么”一个解决“怎么做”。我实际使用中的组合方式是外部数据查询和系统操作通过 MCP 接入而整体的任务推进节奏和代码实施规范交给 superpowers 管理。比如一个需要查数据库的代码任务MCP 负责连接数据库和执行查询superpowers 负责规划、实现和测试流程。两者各管一摊配合得很顺畅。需要留意的是MCP 工具一多模型在启动时加载上下文的时间会变长。如果你的会话明显变慢可以考虑按需启用 MCP 服务而不是一次性全挂上。6.4 值得一试的自定义技能方向最后说一个我自己在琢磨的方向把项目特定的检查规则做成技能。比如前端项目里要求组建必须按照功能目录划分、组件导出方式统一、状态管理只用 store 模式。这些规范散落在团队文档里AI 根本不会主动去读但如果你把它做成一个project-guidelines技能在每次 implement 前触发效果立竿见影。改技能这件事本质上是在“驯化”模型的行为习惯。superpowers 给了你一套完整框架你能把它拧成适合自己团队的样子。它真正的价值不是那几十个默认技能而是这套“用文档定义 AI 行为”的机制。我现在的使用习惯是任何人让我推荐 Claude Code 的必装项superpowers 永远是第一个说出口的名字。但不是因为它的默认技能有多神而是因为它打开了一种可能性——让 AI 按你的章法来工作而不是你迁就 AI 的随性。希望这篇东西能让你少走点弯路早点把这套工具的潜力榨干。