Claude Code技能扩展superpowers:用SKILL.md固化AI工作流 第一次听到“superpowers”这个名字我以为是哪个游戏模组或者效率工具套件直到我真正装进 Claude Code 里跑了一轮才发现它解决的是一个我一直觉得别扭、但又说不上来哪里不对劲的问题AI 助手的能力边界不应该只靠临时对话里的几句话来定义而应该像搭积木一样把一套套沉淀好的“技能”随时装进去、随时调用。如果你是 Claude Code 的日常用户你一定遇到过这种场景换了个新项目想让 AI 按你习惯的方式工作结果又得从头把规则讲一遍或者你想让 AI 做一次完整的代码审查结果它只给你改了命名不规范漏掉了更深层的逻辑问题。superpowers 就是冲着这个痛点来的——它把那些反复使用的“工作套路”打包成标准化的技能让 AI 不再是一个只会接话的聊天框而是一个真正能按流程干活的执行者。这篇文章我会从安装、配置、核心技能分类到自定义技能把整套玩法拆开揉碎讲清楚适合想把手头 AI 工具用得更透的开发者参考。1. 先说清楚superpowers 到底解决了什么问题1.1 没有技能库的 Claude Code痛点在哪我用了很长一段时间的 Claude Code最大的感受是它很强但每次都要“热身”。新开一个项目你想让它按照团队规范写提交信息、按某种结构做需求分析、按特定维度审查代码——这些规则本身不复杂问题是每次都要在对话里重新描述一遍而且描述得不够精确时它的发挥就很飘。这就像你请了一个能力很强的实习生但这位实习生每换一个工位就失忆一次你得把工作流程从头教一遍。一次两次还能接受时间长了你会发现大量时间其实不是在跟 AI 讨论问题而是在给 AI “讲规矩”。superpowers 的出现等于把这些规矩做成了一本本标准作业指导书放在固定的目录里AI 需要的时候自己就能翻到。1.2 技能库对日常工作流的实际提升装好 superpowers 之后变化最明显的一点是你不需要再在提示词里写“请按照某某规范来做”这种话了。技能被调用时完整的操作框架会自动注入到 Claude 的上下文里AI 会按照技能里定义好的步骤、标准、输出格式来执行任务。举个例子以前让 AI 做代码审查它的表现取决于你提示词写得细不细。有了专门的 code-review 技能之后它会自动从安全漏洞、性能瓶颈、可维护性、边界条件这几个维度去检查输出一份结构化报告而不是只盯着变量命名。这就是技能库的价值——把人的经验固化到 AI 的上下文里让它每次执行都有稳定的下限而不是靠运气。2. 安装与配置全流程2.1 前提条件先确认你的环境开始之前先把前提条件捋清楚。superpowers 不是一个独立应用而是 Claude Code 的技能扩展包所以你必须先装好 Claude Code 并完成基本配置。我这边使用的环境是 Node.js 18 以上版本Claude Code 保持在最新版本操作系统是 macOS不过 Windows 和 Linux 上的流程基本一样只是终端命令略有差异。安装之前建议先确认一下环境Node.js 版本在终端输入node -v查看如果低于 18建议先升级Claude Code 已可用在终端输入claude能进入交互界面就算正常npm 源国内用户如果觉得下载慢可以先切换到国内镜像源避免安装超时顺便提一句我一直建议把 Claude Code 装在全局环境而非项目局部环境因为技能库是跨项目复用的工具装成局部依赖的话换个项目又得折腾一遍那就失去意义了。2.2 初始化与安装一条命令搞定superpowers 的官方文档给了一个相当省心的安装方式。它会自动检测 Claude Code 的配置目录然后拉取最新的技能包并初始化好目录结构。npm install -g superpowers/claude-code-skills装完之后进入你的项目目录或者任意一个你想要启用技能的目录执行初始化命令skills init这一步会在你的 Claude Code 配置目录下创建.claude/skills文件夹所有技能模块都收拢在这里。初始化完成之后你会看到类似这样的输出✅ superpowers for Claude Code installed Skills installed to: ~/.claude/skills如果执行过程中提示权限不足大概率是 Claude Code 的配置目录归属和当前用户不一致用sudo chown -R $(whoami) ~/.claude修正一下所有权再重新初始化就行。2.3 配置验证怎么确认技能真的生效了装完不能只看“安装成功”四个字就完事我习惯做一次完整的验证。第一步用skills list命令列出所有已安装的技能模块看到列表里有内容就算第一步过了skills list输出大概长这样• brainstorming • code-review • debugging • test-driven-development • ...第二步把技能实际用一次。随手创建一个临时目录写一个带明显问题的 Python 文件比如某个列表推导式写错了然后启动 Claude Code让它对这个文件做一次 code-review。如果它给出了结构化的审查意见而不是泛泛而谈说明技能已经被成功加载进了上下文。如果技能没有生效最常见的坑是你启动 Claude Code 的目录和初始化时用的目录不一致导致它没找到.claude/skills。进入正确的目录再启动问题就消失了。2.4 目录结构与运行原理理解了文件结构你才算真正理解 superpowers 的工作方式。装好之后的目录树大概是这样的.claude/ └── skills/ ├── brainstorming/ │ └── SKILL.md ├── code-review/ │ └── SKILL.md ├── debugging/ │ └── SKILL.md └── ...每个技能对应一个文件夹核心是里面那个SKILL.md文件。这个文件用 Markdown 写成里面包含了技能的描述、触发条件、执行步骤、输出要求。Claude Code 在对话过程中会读取这些文件的内容把它们作为上下文的一部分来理解。这其实是一种很聪明的设计它没有做一个复杂的插件系统而是把所有经验浓缩成文本模板利用 Claude 强大的文本理解能力来“执行”技能。这也意味着你完全可以手动修改甚至创建自己的技能文件夹不需要写代码只需要会写 Markdown。3. 核心技能玩法拆解与实战3.1 内置技能全景这些 skills 能干什么superpowers 默认带了一批技能我挑几个实际用得最多的说说。brainstorming这个名字很直白就是头脑风暴。它适合在项目早期用来发散想法技能会让 AI 先问你几个关键问题然后基于问题生成多套候选方案。这个技能最有价值的地方在于它要求 AI 先给出多个方案再逐步收敛而不是一上来就拍板这对产品设计讨论特别有用。code-review这个我刚才举过例子它会按安全、性能、可维护性、边界条件等维度对代码做系统性检查。跟直接说“帮我看看这段代码有什么问题”相比它的输出更有条理而且会给出问题等级标注方便你决定优先处理哪个。debugging这是我最常用的技能之一。它内置了一套系统的排错流程先复现问题、再缩小范围、提出假设、验证假设、最后输出修复建议。以前我遇到诡异 Bug 时会反复给 AI 贴错误日志请它猜原因现在直接让 AI 按 debugging 技能的流程来走逻辑严谨很多。test-driven-development也就是 TDD。技能会引导 AI 先写测试用例、再看测试失败、然后写实现代码最后跑通回归。对于想要规范开发流程的团队来说这个技能相当于把一套完整的 TDD 方法论直接塞进了 AI 的上下文。learn-from-codebase它会让 AI 自动分析项目的目录结构、核心依赖、代码风格然后输出一份项目指南。接手他人代码的时候这个技能可以帮你快速建立全局认知比对着 README 猜来猜去高效太多。3.2 让技能真正生效的调用姿势技能装好了并不等于它每次都会自动出现。Claude Code 加载技能是有触发机制的你得知道怎么正确“叫醒”它。最直接的方式是在对话里明确提到技能名比如请使用 code-review 技能审查 src/app.py通常里面描述的触发词也可以比如“帮我对这段代码做一次深度检查”AI 可能会理解为你想要一次完整的 code-review但为了稳定触发我建议还是直接点名技能。这就像你跟同事说“按标准流程走一遍”对方不一定理解你说的“标准流程”是什么直接说“用 code-review 的评审规范来走”信息就不容易失真。还有一种情况是技能之间需要顺序搭配。我经常把learn-from-codebase和code-review连起来用先了解项目概况再做审查最后用brainstorming给出优化方向。一套组合拳下来等于把一个 5 人团队的协作流程压进了单次会话里。3.3 自定义技能编写你自己的 SKILL.mdsuperpowers 真正让我上头的点在于它鼓励你写自己的技能。你不需要懂编程只需要按照特定格式写一份 Markdown 文件就能把团队的独家经验固化下来。SKILL.md的基本结构不复杂YAML front matter写技能的名称、简短描述触发条件说明什么情况下应该调用这个技能执行步骤详细列出 AI 应该按什么顺序做什么事输出格式定义最终的交付物长什么样我自己写了一个“前端样式自查”技能执行步骤是先检查响应式布局断点、再检查颜色对比度、然后检查交互状态、最后输出优化建议。写完之后放进.claude/skills/frontend-style-check/SKILL.md重新启动 Claude Code技能就生效了。之后每次让它查前端代码它都会自动按这套框架来执行输出质量非常稳定。这里说一个容易忽略的细节技能描述越具体AI 正确调用的概率就越高。描述里最好写清楚“何时用、处理对象是什么、最终产出是什么”而不是只写一句“检查前端代码质量”。4. 常见问题与排查技巧实录4.1 高频报错与解决办法我在实际使用中积累了一些报错场景整理成一张速查表问题现象原因分析解决办法skills list看不到任何技能初始化目录错误确认当前目录和初始化时一致或重新skills init技能安装成功但对话中不生效触发方式不对明确点名技能名不要用模糊说法自定义技能出现但行为不符合预期SKILL.md 格式错误检查 YAML front matter 是否完整步骤是否清晰npm 安装超时网络源过慢切换 npm 镜像源后重装更新技能时被拒绝文件权限问题用 chown 修正配置目录归属4.2 技能不生效从这三个角度入手遇到“技能不生效”的问题大部分时候不是工具坏了而是使用姿势的问题。我的排查顺序是先看目录再看格式最后看上下文。“看目录”是最基础的一步。确认.claude/skills就位于你当前启动 Claude Code 的目录下。这听上去很蠢但我就踩过这个坑——在/home/user/下执行skills init然后跑到/home/user/project里启动 Claude Code技能完全消失。现在我的习惯是每次新建项目后先skills init再开始干活一秒都不耽误。“看格式”针对的是自定义技能。YAML front matter 里的name和description字段不能漏而且description要尽量写得像一段“使用说明”而不是一个标签。我见过不少人在这里只写“用于检查代码”结果 AI 确实调用了技能但不知道该按什么标准来执行输出结果自然一塌糊涂。“看上下文”是指如果当前会话中已经堆积了大量其他指令技能的部分描述可能被上下文稀释导致执行不完整。遇到这种情况最简单的做法是开一个新会话或者用/clear清理会话上下文之后再单独调用技能。4.3 上下文管理与安全边界superpowers 把技能注入上下文的机制比较特殊它会自动读取技能描述和步骤这些内容会占据一定的上下文窗口。如果你的会话已经接近上下文长度上限再调用一个步骤复杂的技能可能会导致 Claude 为了节省空间而“简化执行”只做到一半就停了。所以我有个习惯一个会话里不要同时调用两个大型技能。比如test-driven-development和code-review都是步骤繁多的技能同时在同一个会话里使用输出明显变浅。如果想做“先写测试再审查代码”这样的任务流我会拆成两个会话或者先手动把上一步的关键结论粘贴到下一步里减少上下文的压力。安全方面也要留个心眼。技能文件里的步骤是自然语言指令组成的AI 会信任这些指令并执行。如果你从网上直接下载了别人的技能包一定要先翻开SKILL.md看看里面写了什么确认没有引导 AI 去执行危险命令行操作的内容再放进自己的技能目录。这和安装第三方依赖时要看包代码是一个道理。5. 从“会用”到“用好”技能组合与工作流设计5.1 用技能组合复刻团队协作流单个技能带来的提升是线性的技能组合带来的提升是复利式的。我花了不少时间琢磨怎么组合它们目前最顺手的一套流程是接新项目时先用learn-from-codebase建立项目认知然后用brainstorming把需求方向和潜在方案理清接着用test-driven-development驱动核心模块的开发上线前再用code-review做一次全量代码审查。这套组合其实复刻了传统团队里“技术负责人梳理架构 测试驱动开发 代码评审”的流程。以前这些环节需要多个身份协作现在一个 AI 会话就能顺序完成。输出的质量不一定比资深工程师手写的高但胜在稳定、快、且不会遗漏基本项。对于个人开发者或者小团队来说这已经够用了。5.2 技能迭代把踩过的坑变成团队的资产使用技能库最正确的态度是把它当成一个活着的文档系统而不是装完就再也不动的静态工具。每当你发现 AI 在某个环节的输出不符合预期、漏掉了重要检查项、或者你用某个经验修正了它的答案都应该考虑把这个经验同步回SKILL.md里。比如我最早写的“前端样式自查”技能初版只有三条步骤后来把“检查空状态显示”“检查超长文本截断”这两条补充进去之后AI 的输出质量明显上了一个台阶。还有一个我比较建议的做法技能仓库也要做版本管理。我的.claude/skills目录放在了一个独立的 Git 仓库里每次修改都记录提交信息。这样如果某种写法的技能效果不好随时可以git revert回退到上一个大版本特别实用。6. 实操心得说句实在话superpowers 并不复杂它的核心思想简单到几乎不像一个“工具框架”把高频的工作流写成 Markdown让 AI 照着执行。但正是这种简单让它变得特别容易被低估。在跟身边朋友交流的过程中我发现一个规律说“这玩意没用”的人基本都是装完就完事、从没打开过SKILL.md文件的人而那些觉得“离不开了”的人几乎都会在最初的三天里改出属于自己的第一版技能。如果你还在纠结怎么开始我的建议很具体先拿code-review技能做一个真实项目的小模块审查感受一下标准化流程和随手提问的差别然后打开debugging技能的SKILL.md读一遍里面的步骤设计你大概就能理解“把经验写清楚”这件事到底有多大的魔力。最后找一个你自己重复过多次的工作哪怕只是“整理每周发布日志”这种小事写成一份 20 行的SKILL.md让它成为你的第一个自定义技能。技能这个东西价值不在于收藏了多少而在于你到底用它沉淀下了多少自己的套路。装好只是起点真正把技能“榨干”的过程就是你把自己的方法论一点点喂回给 AI 的过程。