最近网上到处都在传一套叫 superpowers 的技能包说是装完以后 Claude Code 就像开了挂一样调试、写代码、修 bug 全都自带方法论。我一开始以为又是营销号在吹概念直到自己动手装了一遍、在真实项目里跑了两周才意识到这玩意儿确实不是噱头——它把那些“高手才知道的工作流”直接固化成了可复用的技能文件让 AI 不再每次从头猜你想怎么干活。这篇文章就围绕 superpowers 到底是什么、怎么安装、有哪些 skills、以及怎么在实际开发里引入这些技能展开。我会把我自己的安装过程、实测用法和踩过的坑全部写出来尽量让没接触过的人也能照着操作。1. superpowers 到底是什么从一段尴尬的对话说起1.1 一次没有超能力的 Claude Code 对话先讲个真实场景。我刚用 Claude Code 的时候让它帮我排查一个接口偶发超时的问题。它的第一反应是打开代码库一顿乱翻然后列出一大堆可能原因可能是连接池配置不对、可能是 N1 查询、可能是日志里的某个异常没捕获……每一项都分析得头头是道但每一项都没深入验证。我当时的感受是这工具确实懂很多但它没有“排查问题的章法”。它就像一个知识渊博但没受过职业训练的新人什么都懂一点却没有一套完整的工作流程。我要反复拉它回正轨不断说“先别改先复现”“把日志加上再看”“定位到具体分支再修”这类话。会话一长上下文一乱它就开始东一榔头西一棒槌了。后来我才知道这个问题不是 AI 能力不够而是缺了“工作方法论层”的约束。1.2 superpowers 的核心机制把方法论做成文件superpowers 是一套基于 Claude Code 技能机制的技能包由开发者 jealouscloudChris发起项目在 GitHub 上开源后社区反响一直很高。它做的事情说穿了并不玄就是把你平时想让 AI 遵守的调试步骤、代码审查清单、系统设计流程、任务规划方式全部写成结构化的“技能文件”让 Claude 在接到对应任务时自动加载这些技能按里面的标准流程执行。用一句大白话总结别人用 Claude Code 是提问式交流装完 superpowers 之后是让 Claude 按标准作业程序干活。技能文件本身是基于官方支持的 SKILL.md 规范写的每个技能都有一段 frontmatter包含技能名称、描述、适用场景然后是具体的执行步骤、检查清单和验收标准。Claude 在对话过程中会根据任务语义匹配对应技能匹配上了就自动按技能里的流程走。关键点在于这些技能不是临时的提示词而是躺在磁盘上的独立文件可以被复用、被分享、被不断修改迭代。它解决的核心问题有三个经验不随会话消失。普通对话里你教给 AI 的流程下一轮新会话就忘了。技能文件是持久化的这轮学会了下轮直接用。方法论可复制。团队里任何成员都能把一套调试规范写成技能全组共享不用靠口口相传。AI 的行为变得可预测。同样的任务技能加载前后Claude 的输出质量和工作路径完全是两回事。1.3 为什么这套项目值得装在装之前我也犹豫过Claude Code 本身不是很强了吗还需要额外装技能实际用过的结论是需要而且非常需要。默认状态下的 Claude Code 更像一个“高性能但无状态”的助手。它能理解复杂指令但在没人引导的情况下它不会主动采用最优工作流。superpowers 相当于给你的 AI 助手做了一次职业培训把“资深工程师遇到 bug 时会怎么系统排查”这个经验拆解成了可执行的步骤清单。装完之后Claude 在关键时刻会主动说“好的我先按照系统化调试流程来做”然后按部就班地复现、加日志、二分定位、修复、回归——那种感觉就是从跟一个聪明实习生合作变成了跟一个带过多年团队的技术负责人合作。2. 装它之前你要搞明白的事环境依赖和目录结构2.1 前置要求清单动手之前先把环境检查一遍免得装到一半卡住。我的实测环境是 macOS Node.js 20整套流程走下来很顺利下面这些前置条件基本是硬性的一个可正常使用的 Claude Code 命令行环境需要对应版本的 Claude 账号授权Node.js 18 及以上版本Claude Code 版本不要太老至少要是支持 skills 目录机制的版本能正常访问 GitHub因为安装脚本和技能仓库都从上面拉如果你之前装过 Claude Code可以直接在终端里跑claude --version看版本号没装过的先去官方文档把 Claude Code 装上这个步骤我就不展开了官方文档写得很清楚。2.2 Claude Code 的配置目录到底怎么组织要理解 superpowers 的安装逻辑先得理解 Claude Code 的配置目录结构。以 macOS 为例配置根目录在~/.claude/下面常见的子目录和文件有这些settings.json全局配置文件包括权限、模型参数、插件配置等CLAUDE.md项目记忆文件的全局版本Claude 每次启动会自动读取commands/存放斜杠命令每个.md文件对应一个命令比如/review、/testskills/存放技能文件官方技能目录Claude 会扫描这里的 SKILL.mdplugins/插件目录superpowers 这类带完整功能包的项目一般装在这里通过插件机制把自己的技能和命令注入到 Claude Code 中agents/子代理相关配置技能和子代理经常搭配使用superpowers 的安装本质上就干了两件事把项目克隆到插件目录然后让 Claude Code 的插件系统加载它。插件加载后它会把自己内置的 skills 文件注册到技能库里同时把一些辅助命令注册到斜杠命令列表里。2.3 技能文件长什么样SKILL.md 标准很多人第一次看到技能文件都会问这不就是 Markdown 文档吗对但关键在于它的结构约定。一个标准的 SKILL.md 长这样--- name: systematic-debugging description: 当用户报告一个 bug 或异常行为时使用。按系统化流程定位根因先复现、再假设、再二分验证。 --- # 系统化调试技能 ## 执行步骤 1. 拿到问题后先要求最小复现步骤 2. 在关键路径插入日志或断言 3. 对可能原因排序逐个验证 4. 修复后运行回归测试 ## 验收清单 - [ ] 根因已确认而非猜测 - [ ] 修复有对应测试覆盖 - [ ] 原有功能无回归frontmatter 里的name和description非常关键Claude 就是靠description来判断“当前这个用户请求是否应该触发这个技能”。描述写得越具体、越贴近真实任务场景技能被正确触发的概率越高。这也是后面很多人装完技能发现“不生效”的根源所在——不是技能坏了而是描述写得泛泛Claude 根本没认出来该用这个技能。3. 动手安装官方 CLI 和手动克隆两条路3.1 官方推荐的一键安装流程superpowers 官方的安装方式非常省事本质就是一行脚本。我当时执行的时候大概是这样的流程打开终端先确认claude命令在 PATH 里能正常启动执行官方提供的自动化安装脚本一句以 curl 管道方式调用的 bash 脚本脚本会自动把仓库克隆到~/.claude/plugins/superpowers安装完以后脚本会提示重启 Claude Code 会话装完后我做的第一件事是在 Claude Code 里输入/plugin查看已加载的插件列表确认 superpowers 在列。这一步很重要很多人装完不验证结果在旧会话里一直没生效还以为是脚本有问题。如果你更喜欢手动控制也可以直接进到~/.claude/plugins/目录用 git clone 把项目拉下来效果一样cd ~/.claude/plugins git clone https://github.com/jealouscloud/superpowers.git手动克隆的好处是你可以自由切分支、看源码、改技能文件方便后续二次开发。3.2 安装脚本到底做了什么我之前一直对“一条 curl 管道 bash”的安装方式心存戒备所以在执行前专门把脚本内容拉下来看了一下。脚本的核心动作其实很简单检查~/.claude/plugins/superpowers是否已存在存在则做更新不存在则克隆检查依赖比如是否有 git、node 环境把所有.claude/skills相关的技能文件路径打印出来方便配置看明白之后我放心了不少。这类开源项目用自动化脚本主要目的就是减少手动配置带来的路径错误。你如果也担心安全问题完全可以先下载脚本看一眼再执行或者干脆用手动克隆的方式。3.3 自定义安装位置和环境变量有一点值得单独说明superpowers 默认装在全局插件目录~/.claude/plugins/下这意味着所有项目都能共用这套技能。但有些时候你可能希望某个项目单独使用特定技能版本或者团队项目里为项目单独定制技能集那就涉及自定义安装位置。方法是把技能目录指向项目本地Claude Code 支持项目级.claude/目录。你可以在项目根目录建一个.claude/skills/把需要的技能文件软链接进去或者直接在项目.claude/plugins/superpowers里做一份自己的定制版。路径这块我踩过一个坑一开始我以为是直接把 superpowers 克隆到项目目录里就行但 Claude Code 的插件机制对项目的依赖路径识别很敏感建议还是用官方默认的全局安装方式然后通过 soft link 做项目级覆盖别轻易改动安装基路径。4. 内置技能全景这些 skills 分别解决什么问题4.1 核心技能列表与适用场景superpowers 内置的技能数量不少而且特性很清晰每个技能都针对一类具体任务设计。我把常用且实测过比较靠谱的几个列进一个表方便你快速对照技能名称解决的问题典型触发场景sliding-window debugging代码量大、bug 难定位时按窗口分段排查“这个模块运行结果不对帮我查一下”systematic debugging从复现到根因的一整套调试流程“服务偶发报错不知道什么原因”code-review按清单审查代码关注正确性、健壮性、可读性“帮我 review 一下这个 PR”design-lens从设计模式角度审视代码结构“这段代码有没有设计上的问题”generate-skill根据对话内容自动生成新技能文件“以后遇到这种任务就按这个流程做”watch-mode / loop-enhancements反复执行测试、自动改进代码直到全绿“跑一下测试失败就修再跑直到通过”每个技能内部都包含完整的方法论。拿 sliding-window debugging 来说它的核心思想是把一个庞杂的代码库切分成多个“窗口”每个窗口内的代码量控制在 Claude 的上下文能力范围内然后按窗口逐个审查缩小问题范围。这很像排查电路故障时用的二分法先确定问题在哪个大区域再逐步缩小到具体线路而不是按下电笔到处乱戳。4.2 技能之间的分工与配合这些技能不是孤立存在的它们在真实任务里经常组合使用。比如你报告一个 bugClaude 可能会先加载 systematic debugging 技能进入“复现问题 → 建立假设 → 验证假设”的循环。在验证过程中它会发现需要审查某段异常逻辑于是又触发 code-review 技能对那段代码做一次静态审查。最后修复完成它调用测试相关技能补一条回归用例。这个联动机制很有价值因为这说明技能系统不是简单的提示词模板集合而是一个可以互相调用的方法论网络。Claude 会根据任务进程动态决定下一个动作加载对应的技能文件作为执行指南。4.3 哪些技能我实测最常用在我自己的项目里触发频率最高的前三名是systematic debugging这个基本是日常必用的。任何一个“现象和预期不符”的请求都会触发它它会先要求我提供最小复现步骤而不是直接猜测答案。generate-skill这个技能很反直觉它是用来自动生成新技能的。你只要描述清楚“以后遇到某某场景应该怎么做”它就能写出一个新的 SKILL.md 文件放进技能库。code-review每周做代码审查时用的频率很高它会按“正确性 → 边界条件 → 错误处理 → 性能 → 可读性”的顺序逐项过一遍比我口头说“帮我看看代码有没有问题”要系统得多。5. 技能在实战里怎么用一次完整调试过程的还原5.1 一个真实场景偶发 500 错误排查为了让你更直观地感受装与不装的区别我把一个真实案例完整还原出来。项目背景是一个 JSON API 服务某段时间总在线上偶发 500日志里只有一句笼统的Internal Server Error没有堆栈信息本地复现率极低。在装 superpowers 之前我让 Claude Code 处理过类似问题它的做法是直接给我列出了七八种可能原因从磁盘 IO 到框架 bug 都有然后问我“你想先查哪个”。我当时就很无语。装完 superpowers 后我把同样的问题描述发给它。区别立刻出来了它先告诉我“我会按照系统化调试流程来处理”然后主动要求我提供完整的请求参数样例出故障的时间段和日志片段相关代码文件列表拿到这些信息后它开始按 sliding-window 的方式切分代码路径先定位到请求处理链路的入口到出口再逐一窗口排除在可疑的窗口内加日志而不是一上来就大范围修改代码。5.2 关键的命令调用与交互方式实际使用中技能被触发的方式有两种一种是自动匹配Claude 根据任务语义自动加载另一种是手动指定你可以在对话里直接说“使用 sliding-window debugging 帮我看看这段代码”。此外superpowers 的插件还会注册一部分斜杠命令你可以输入斜杠触发对应工作流比如/superpowers:debug手动开启调试技能模式/superpowers:review手动触发代码审查技能如果你装了多个技能包这些斜杠命令能帮你绕过自动匹配的不确定性直接指定要走哪条工作流。我个人建议能手动指定的场景尽量手动指定别全靠自动匹配。因为自动匹配依赖 description 和你的需求描述之间的语义相似度描述不清晰时匹配结果会跑偏。5.3 效果对比装技能前后的行为差异还是上面那个 500 错误案例两种模式的处理路径差异如下处理阶段未装技能的 Claude Code装完 superpowers 的 Claude Code拿到问题后直接列举多种猜测原因先复现问题要求最小化输入定位过程凭借记忆猜测可疑代码按窗口分段审查逐步缩小范围加日志在用户指定的位置加在判定窗口的关键路径主动加修复方式按猜测直接改根因确认后再改并补回归用例验证手段只在用户要求时跑测试自动跑相关测试并核对结果那次问题最终的根因是一个边界参数在校验逻辑里抛了异常但异常被上层吞掉只记了通用错误。用传统方式排查可能得折腾大半天那次在技能引导下大概一个多小时就定位到了而且它还顺手建议加了一条针对该边界参数的测试用例。6. 怎么引入自己的技能自定义 skill 的正确姿势6.1 手写一个 SKILL.md 的完整模板superpowers 的价值不只是自带技能更重要的是它给你示范了“怎么给 Claude 写技能”。我在实际项目里很快就从“使用技能”过渡到了“写技能”因为团队里有大量重复性、规范性的工作非常适合固化成技能文件。下面是一个我常用的自定义技能模板你可以直接抄--- name: sql-review description: 当用户要求审查 SQL 语句、优化慢查询或检查表结构设计时使用。尤其适用于涉及 WHERE 条件、JOIN 顺序、索引使用的场景。 --- # SQL 审查技能 ## 执行步骤 1. 拿到 SQL 后先明确表结构和索引情况 2. 分析 WHERE、JOIN、ORDER BY 子句是否命中索引 3. 检查是否存在 N1 查询或扫全表的隐患 4. 对每条优化建议给出理由和预期效果 5. 输出修改后的 SQL 和验证方法 ## 验收清单 - [ ] 每一条优化建议都对应具体 SQL 语句 - [ ] 建议按性能影响排序 - [ ] 最终给出可执行的验证步骤写好之后把文件放到~/.claude/skills/目录全局生效或者项目根目录的.claude/skills/下项目内生效重启 Claude Code 会话就能被扫描到。6.2 让技能被自动触发的小技巧写技能最大的坑在于你写了一个技能Claude 却从来不触发它。问题几乎都出在description上。我总结出来的三条经验描述里要包含明确的触发行为词。比如“当用户要求审查 SQL”“当用户报告查询速度慢”这类表达里面要有具体的动作和场景不要只写“用于 SQL 场景”。描述里要包含关键词变体。同一个意思可能有多种说法比如“慢查询”“查询慢”“性能问题”“接口超时”尽量都列在描述里。遵循“宁可过度匹配不可完全不匹配”的原则。自动任务触发时Claude 少有精确匹配的能力它是在做语义判断。描述写宽泛一点技能被用到的机会更大你觉得没必要触发时手动在对话里说一句“跳过技能直接回答”就行。6.3 技能、子代理与工具的三层配合单纯靠技能文件Claude 的工作流是“读文档 → 执行步骤”。但更进一步技能文件内部可以指定调用子代理也可以结合 MCP 工具和 hooks形成更完整的自动化链路。我最常用的组合是技能负责“定义标准流程”子代理负责“执行具体调查”MCP 工具负责“拉取外部数据”。比如前面提到的 SQL 审查技能我会在技能正文里写“如果需要检查表结构和索引先去数据库元数据节点读取信息”这样 Claude 在跑技能时就会自动连接数据库查信息而不是干等用户手动提供。hooks 也是个有意思的方向。通过配置 hooks你可以让 Claude 在特定事件比如文件写入、命令执行时自动加载某个技能。这样实操层面就产生了一种很有意思的玩法代码一跑挂Claude 自动进入调试技能模式不需要你手动说任何话。7. 我踩过的坑安装和使用排查清单7.1 技能根本没被触发这是出现率最高的问题我在群里见了太多人问“为什么我装了 superpowers 它不用”。按排查顺序走一遍确认技能文件确实存在且格式正确。你可以直接告诉 Claude“列出当前已加载的技能”它会输出技能列表。如果列表里没有你期望的技能说明根本没加载成功。确认装完是否重启了会话。Claude Code 的技能扫描发生在会话启动阶段旧会话里不会自动热加载新技能。确认你的请求描述是否足够接近技能的 description。触发不了就手动指定说“请使用 systematic debugging 技能处理这个 bug”。确认你用的模型版本支持技能机制。有些老版本模型不支持技能永远不会被匹配。7.2 插件语法错误导致启动失败我遇到过装完 superpowers 后 Claude Code 启动直接报错的情况终端里提示某个文件解析失败。当时排查下来是插件配置里引用的一个技能文件路径写错了导致启动时加载异常。解决办法有两个一是查看报错信息里给的路径直接去那个文件看格式问题二是临时把插件目录移走让 Claude Code 用纯净模式启动再逐步加回插件定位问题。如果你自己改过技能文件特别容易踩 YAML frontmatter 的缩进坑。YAML 对空格缩进极其敏感description:后面忘加空格、冒号写成了中文冒号都会导致整段 frontmatter 失效。7.3 更新与卸载时容易忽略的细节superpowers 更新频率不算低因为它还处于快速迭代期。更新方式很简单在插件目录里git pull拉最新代码然后重启会话。但它更新后可能会重置一些自定义技能配置所以如果你改过插件内的技能文件记得提前备份自定义部分。卸载更简单把插件目录删除在 settings.json 里把对应的 plugin 配置项清掉即可。但要注意卸载插件后你的项目中如果有当时用技能生成的工作流脚本、测试文件它们是独立存在的不会随插件消失。所以卸载前先想清楚哪些是你需要保留的。7.4 一个实操验证清单最后送你一份我每次排查技能问题时都会跑一遍的验证流程重启会话后输入/plugin确认 superpowers 处于已加载状态输入“请使用 sliding-window debugging 处理以下问题”触发手动调用输入“列出当前技能”检查技能列表用一个简单的测试任务验证技能是否真正走到了完整流程而不是仅返回文本查日志确认技能文件被读取的时间点用来判断加载是否滞后这几步跑完基本能定位 80% 的问题出在哪里。我在实际项目里玩了两周后最大的体会是superpowers 真正的价值不在于那几个现成的技能而在于它给了你一套“把方法论编码成 AI 行为”的思路。现在我已经把团队代码规范、发布检查清单、新项目初始化流程全都写成了自定义技能丢进技能库日常开发里的重复沟通和低级失误明显少了很多。如果你也想让 Claude Code 从“聪明但散漫”变成“有章法地干活”这套技能包值得花一个下午装上试试。