如果你最近逛技术社区大概率会频繁撞见superpowers这个开源项目。它不是新语言、不是新框架而是一套给 Claude Code 用的技能库skills。我第一次看到这个名字时以为是又一个“AI 增强插件”结果装完用了一周才意识到它真正改变的并不是模型能力而是我们使用模型的方式——从“我问它答”变成了“它按章法干活”。这篇文章适合正在用 Claude Code 做真实项目、但总觉得 AI“差点意思”的开发者。如果你也遇到模型回答很漂亮、代码却总像临时拼凑的情况那superpowers大概率能帮上忙。我会从安装、技能盘点、日常用法到踩坑记录完整讲一遍最后附上我自己的真实体验。所有步骤基于当前常见实践具体版本差异我会在文内特别标注。1. 它解决的核心痛点AI编码助手缺的不是智力是工作流1.1 一个让我印象深刻的对比我先说说为什么会对这个项目产生兴趣。有段时间我在公司内部推广 Claude Code发现两类截然不同的用法。一类同事把它当成“高级问答框”让 AI 写个函数、解释一段报错、生成几条正则然后用完即走。另一类同事会在一个任务里反复让 AI 修改同一个文件改完再测、测完再改看起来像在“碰运气”。真正的分水岭出现在一个重构任务上。让 Claude Code 重构一个 300 行的遗留模块第一类用法会直接甩出一版全新实现——干净、简洁但和周边代码风格完全脱节测试也挂了一片。第二类用法虽然每次改动小、回归少但过程非常漫长因为它没有系统化的检查步骤。superpowers解决的就是这件事它把有经验的工程师的“工作习惯”固化成可执行的文本指令让 AI 在接到任务时不再凭感觉自由发挥而是先规划、再小步执行、最后审查。说得直白点这就好比给一个技术很强的实习生发了一本 SOP 手册他会突然变得可靠很多。1.2 技能机制的本质SKILL.md 到底是个什么东西很多人第一次听到“skills”这个概念会懵我换个说法就很好理解技能就是一个 Markdown 文件或者一个带附件的目录里面写清楚了“什么时候用这个技能”和“用的时候按什么步骤来”。每个技能目录下通常有一个SKILL.md结构大致是--- name: skill-name description: 这个技能适合什么场景、解决什么问题、何时触发 --- # 工作流 1. 第一步先做信息收集 2. 第二步形成假设并验证 3. 第三步小步实施并检查 4. 第四步输出结果清单文件开头的 YAML 部分是给模型看的“索引”正文部分是可执行的工作流程。Claude Code 在启动时会扫描技能目录把这些技能描述加载进上下文。对话中模型会根据你的请求自动匹配最合适的技能也可以在指令里显式要求调用某个技能。你完全可以自己写这样的文件superpowers只是把一批通用性很强的技能提前写好了而已。理解了这一点“安装 superpowers”本质就变成了“把一批高质量技能文件放到模型能扫描到的目录里”。1.3 为什么它能在社区里突然火起来一个重要背景是 Claude Code 加强了原生 skills 支持。以前也有人写各种 prompt 模板和 system prompt但都属于“一次性注入”每次对话都要手动粘。现在模型会在启动时自动扫描技能目录并理解每个技能的触发条件。这相当于给技能机制配了标准插槽而superpowers刚好填进来了一批高质量的“官方替代品”。我自己的体会是这套东西的价值不在某个单一技能多聪明而在于它提供了一个框架。你可以把公司编码规范、团队评审清单、个人调试习惯全部写成技能文件然后让 Claude Code 统一执行。这种思路比到处收集“神奇 prompt”靠谱得多——prompt 是碎片技能是系统。2. 安装Superpowers三条路径和一次验证2.1 前置条件别跳过版本检查安装之前先确认电脑上已经装好 Claude Code并且能正常跑起来。这个前提看起来废话但值得多说一句如果你用的是旧版本不一定支持技能目录扫描装了也白装。我在终端里的检查习惯是claude --version能正常输出版本号就说明 CLI 没问题。另外确认git命令可用Windows 用户建议用 PowerShell 执行下面的命令macOS/Linux 用户直接用终端。2.2 全量安装克隆仓库并复制技能社区里最主流的安装方式是把 superpowers 仓库克隆到本地然后把技能目录内容复制到 Claude Code 的全局技能目录。在 Linux / macOS 上执行git clone https://github.com/obra/superpowers.git ~/superpowers mkdir -p ~/.claude/skills cp -r ~/superpowers/skills/* ~/.claude/skills/Windows PowerShell 下对应命令是git clone https://github.com/obra/superpowers.git $HOME\superpowers New-Item -ItemType Directory -Force $HOME\.claude\skills Copy-Item $HOME\superpowers\skills\* $HOME\.claude\skills\ -Recurse我推荐用软链接代替复制。好处是以后仓库更新技能时你的技能目录自动同步不用重复复制。macOS / Linux 做法ln -s ~/superpowers/skills/* ~/.claude/skills/Windows 下对应可以用目录联接mklink /J不过复制也不麻烦看个人习惯。2.3 按项目安装更适合团队协作的方式如果你只在某个项目里使用或者希望技能定义跟着仓库走推荐在项目根目录建.claude/skills文件夹只复制当前需要的技能。这样这个技能目录可以提交进 git团队成员拉到代码后自动获得同一套工作流约定。我的习惯是通用能力放全局~/.claude/skills团队规范放项目.claude/skills。两条路径互不冲突Claude Code 启动时会同时扫描。不过要注意目录层级不能嵌套得太深技能一般要求skills/技能名/SKILL.md这种结构路径层级错了就会被静默忽略。2.4 验证安装是否生效装完重启 Claude Code新开会话然后直接问一句你现在能使用哪些技能请列出你已加载的 SKILL.md。如果模型能明确列出该技能名称、适用场景就说明加载成功。如果回复得模棱两可先检查技能目录里是否存在SKILL.md再用文本编辑器打开文件确认 YAML 头部格式没被弄坏。这里有个容易被忽略的坑如果那个description写得过于泛泛模型在运行时会不容易判断什么时候该调用它。superpowers仓库里的技能描述大多是写清楚触发条件的但你自己拷贝出来的第三方技能就要多留个心眼。3. 技能盘点这套skills包里到底装了什么3.1 规划与设计类技能把模糊需求变成可执行任务我最先体会到价值的是任务规划类技能。以前让 Claude Code 做个稍大的功能它会直接开始写代码把需求边界、接口设计、异常处理全丢在脑后。启用规划技能后模型会先拆分目标、列出约束条件和验收标准再逐步执行。举个例子我曾经让它“给用户列表接口加缓存”。没有技能的时候它直接改了一版代码连缓存失效策略都没写。启动规划技能后输出变成了需求澄清要不要缓存穿透保护、方案权衡本地缓存还是 Redis、实施步骤、测试要点。虽然这些事有经验的工程师自己都会想到但对 AI 来说没有明确指令它就懒得想。3.2 开发与质量类技能TDD、调试、重构最常用开发流程相关的技能里我觉得测试驱动开发TDD是思路最清晰的。它会要求模型先写一个失败测试确认测试确实因为“功能不存在”而失败然后写最小实现让测试变绿最后再做重构。这套流程对 AI 特别适用因为 AI 天然急着“交答案”如果不按步骤走很容易跳过测试。调试类技能也很有含金量。它强调“先复现再二分不做无根据的乱改”。典型步骤是收集现象和报错、缩小范围、提出假说、用小实验验证每个假说最后再动手。听起来朴素但能明显减少模型“假装定位问题然后随手改一行”的行为。重构类技能我之后才频繁使用它会强制检查是否存在测试保护要求每一步改动都能独立通过验证避免一次抛出一大坨不可审阅的代码。3.3 审查与安全类技能让 AI 学会审代码而不是夸代码代码审查技能解决了我的另一个痛点。默认情况下让 Claude Code 审查代码它很容易给出“整体实现优雅逻辑清晰”这种场面话。审查技能会把问题按严重程度分级阻塞性问题、主要问题、次要问题、风格建议每个问题都要给出文件和行号。这逼着模型去逐行读代码而不是扫一眼给个总体印象。安全审查技能则专门检查认证、越权、注入、敏感信息泄露等风险。它特别适合在代码提交前跑一遍某些越权接口问题我在 review 时容易漏AI 按清单检查反而更全面。3.4 文档与提交类技能被低估的效率工具仓库里还有一批文档和协作类技能。比如根据代码生成 README、维护变更日志、生成符合 Conventional Commits 规范的提交信息。这类技能看起来不惊艳但我实际用下来非常省时间——尤其是提交信息它会让每个 commit 都带上清晰的前缀和作用范围而不是默认的“update code”。我用一张表总结当前版本里比较典型的技能类别具体文件名和数量会随仓库更新变化但方向大致一致技能类别适用场景实际价值任务规划拿到含糊需求拆分目标、明确约束和验收标准TDD开始写新功能先失败测试、最小实现、小步重构系统调试线上 Bug 或复现问题按假说验证避免乱改代码审查提交 MR/PR 前按严重程度分级列出问题安全审查认证、支付、权限模块检查越权、注入、信息泄露重构维护老代码小步重构测试保持绿色提交规范每次 git commit生成规范化提交信息文档生成交接、开源项目自动产出 README 和设计文档4. 真正使用起来让技能从纸面走向代码4.1 显式调用最稳的触发方式技能虽然支持自动匹配但我实测下来真正关键的任务还是显式指定更稳。直接在对话里写清“使用 XX 技能”就行。实际对话示例如下使用任务规划技能帮我把“微信小程序端增加扫码登录”拆成可执行的任务清单包含依赖顺序和验收标准。模型就会把技能里的步骤走一遍输出一份结构化任务拆解。如果你希望它进入调试模式可以这样写使用系统调试技能分析这个接口偶发超时的问题。仓库在 src/server 下最近一次修改涉及 redis 连接池。注意给足上下文。技能只是工作流剧本不是魔法模型依然需要知道仓库路径、问题现象、约束条件。很多声称“技能无效”的反馈其实是上下文给得太少。4.2 自动触发依赖描述质量也依赖你的提问方式自动触发听起来更酷实际效果则有点随机。模型会根据自己的理解来决定“这个请求该不该用技能”但它可能误判。比如有时候我只是闲聊某个 bug模型却启动了重型调试流程有时候我明确想让它写测试它却直接开始写实现代码。我的经验是如果你想让自动触发更可靠提问时就用技能描述里出现过的关键词。比如调试技能描述里如果包含“复现”“定位”“报错排查”这些词你的请求里就尽量带上这些表述。这是一种低成本提升命中率的方法。4.3 一个完整的最小工作流示例我通常在实现一个中等功能时这样配合技能使用流程如下使用任务规划技能拆分需求得到任务清单和验收标准。针对核心逻辑使用 TDD 技能先补测试再实现。实现完成后使用代码审查技能自查重点看是否有遗漏分支。最后用提交规范技能生成 commit 信息。配合起来Claude Code 的行为模式就从“能干活”变成了“按工程规范干活”。这个转变不是某个单点技能的效果而是整套流程设计带来的结果。4.4 把自己团队的经验写成技能这里必须说一个我强烈建议做的事不要只停留在使用现成技能试着把你自己团队的规范写成新技能。操作并不难在项目.claude/skills下新建一个目录放一个SKILL.md--- name: frontend-component description: 在创建或修改前端组件时使用。规定目录结构、样式方案、可用性要求。 --- # 组件开发流程 1. 检查项目现有组件是否存在类似实现 2. 创建组件目录包含 index.tsx 和 styles.css 3. 样式统一使用设计系统变量禁止硬编码颜色 4. 为可交互元素补充键盘操作支持 5. 完成后再检查一遍可访问性清单写完之后Claude Code 下次在这个仓库里处理组件需求时就会自动加载这套规则。这才是superpowers对我而言最有价值的地方它培养了你“用技能去约束 AI”的思维方式。5. 一个月实测小结哪些用法值得保留哪些坑别踩5.1 技能不是越多越好第一次装完很多人会像逛应用商店一样想把所有技能都启用。我劝你别这么做。技能越多模型在匹配时就需要读更多描述一是响应会变慢二是误用概率升高。比如安全审查技能可能在普通 CRUD 接口需求里被误触发给本来简单的任务加了一堆不必要的检查清单。我目前的配置是全局只启用任务规划、TDD、代码审查、系统调试、提交规范这几个其余技能在需要时按项目维度单独装。这样既保持轻量又能保证高频场景稳定生效。5.2 全局技能和项目技能要避免重复如果一个技能同时存在于~/.claude/skills和项目.claude/skills模型可能出现行为冲突。我遇到过最典型的场景是团队项目里放了一个自定义代码审查规范结果全局代码审查技能也同时加载两边对“严重问题”的定义不一样导致模型一会儿按这个标准输出一会儿按那个标准输出。解决方式很简单统一规则。要么全局完全不管项目具体规范要么项目里存在自定义技能时就不装全局同名技能。5.3 更新技能要谨慎别让旧版本拖垮新行为superpowers仓库迭代速度不慢隔几周可能就会有新的技能或修改。用软链接方式的用户直接git pull就能更新收益是即时获得改进风险是某个技能的指令变化可能影响你的既定工作流。我现在的做法是每两周手动 review 一次更新日志而不是无脑拉取。如果这个技能的更新说明和你使用场景不相关就暂时不动。它毕竟是一套外部定义的工作流你是在把一部分判断力让渡给它保持适度谨慎是有必要的。5.4 一个被很多人忽视的安全边界技能本质上是“可执行的指令文本”它会指导模型做什么、不做什么。因此在使用第三方技能时最好通读一遍SKILL.md的内容确认里面没有诱导模型执行危险操作的设计——比如让你关闭安全校验、直接在线上环境跑批处理或者其他高风险行为。我自己团队如果要给 AI 定义技能会把它们放在私有仓库里维护而不是直接公开。技能里往往包含项目结构、命名规范等内部信息这些东西平时散落在文档里大家不觉得敏感一旦被集中写进技能文件就可能被回显或被他人看到值得留个心眼。最后分享一点个人体会用技能包管理 AI 工作流真正让我受益的不是某一个技能的效率提升而是它逼着我重新梳理了自己的工作方式。为了写清楚“什么时候该用调试技能”我反而想明白了自己平时是怎么调试的为了给团队写组件技能我把原本模模糊糊的代码规范一条条落实成文件。这件事对个人也好、团队也好都是一种额外收获。