最近有个词在 AI 编程圈子里出现频率挺高superpowers。它不是某一个人的超能力也不是某个模型版本号而是一套给 AI 编程助手准备的技能库把那些复杂、高频、需要经验的任务比如代码审查、写单元测试、梳理 Git 提交记录、按规范重构全部预先写成技能文件让 AI 按标准流程干活而不是临时靠提示词现场发挥。你要是用过 Claude Code 这类工具应该能懂这种感受——模型很聪明但每次都要你在旁边一步步指挥任务一拉长它就开始飘改着改着就忘了最初的约束。superpowers 想解决的就是这个“每次都从零开始”的问题。这篇文章把我亲测的安装流程、使用姿势、踩过的坑和一些底层判断写出来给正在琢磨这东西怎么落地的人一个参考。1. 整体设计思路拆解superpowers 到底解决了什么问题1.1 它不是更多提示词而是把任务流程固化成“标准作业程序”很多人第一次接触 superpowers 会误以为它是某种“更强的提示词模板合集”其实差别很大。提示词是每次对话时你重新组织一遍需求模型听完就忘下一次又得重来而技能文件是长在项目里、存在于固定目录下的一份结构化的“操作手册”里面写清楚了这个技能在什么情况下该用、具体分几步做、每一步要做到什么程度、最终产出长什么样。我举个生活化的例子。让一个新手厨师“做一份宫保鸡丁”他大概率会懵或者做成乱七八糟的味道但如果你给他一张标准作业程序卡上面写明食材切配规格、下锅顺序、火候区间、出锅前怎么勾芡他照着做就能稳定交出一盘及格以上的菜。superpowers 里的每个 skill本质就是给 AI 发这样一张标准作业卡。它让 AI 从“一个聪明但缺乏经验的临时工”变成“一个看了老师傅操作手册的熟练工”。这也是项目叫 superpowers 的原因——技能一装AI 的实战能力确实像开了外挂。实际使用中你会发现同样让 AI “审查一下代码”没有技能时它可能泛泛说“代码整体不错注意一下错误处理”而加载了技能之后它会先拉 Git diff列出变更文件然后按安全检查、边界条件、性能隐患、可读性四个维度逐项过每条问题都带上文件路径和行号。这种差异不是模型变聪明了而是流程被强制拉齐了。1.2 skills、rules、plugins 的分工别混为一谈刚开始折腾这类工具的人很容易把三个概念搞混rules、plugins、skills。我自己排查问题时就吃过亏先花点时间把它们的关系理顺。rules 是全局行为约束常驻在系统上下文里适合放“不要删除用户数据”“代码里不要硬编码密钥”这类团队规范。缺点是它占上下文不能写太长否则模型会被一堆规则压得反应迟钝。plugins 是扩展工具能力的相当于给 AI 增加新的“手”和“眼”比如让它能跑某个命令行工具、能读取某个数据库结构、能调用外部 API。它解决的是“AI 有没有能力做这件事”的问题。skills 解决的是“AI 会不会按对的流程做这件事”的问题。它按需加载只有触发到相关任务时才把整个技能文件注入上下文用完即走。superpowers 这个体系下核心资产就是一组高质量的 skills可能顺带配一些插件来支撑技能里的工具调用。三者的关系可以这样记rules 管言行举止plugins 管工具装备skills 管干活流程。1.3 为什么这类技能库突然火起来了原因其实很朴素大模型的上下文窗口看起来很大但真正稳定有效的长度并没有那么夸张。你把一个复杂任务的完整流程、检查清单、输出格式全部写进对话里一方面浪费 token另一方面流程描述和用户需求混在一起模型很容易抓错重点。把流程外置成独立的技能文件按需加载既省钱又稳定还能跨项目复用。更关键的是技能具有可积累性。今天我在项目里总结了一套“发布前检查流程”写成 skill 后下个项目直接就能用团队里其他人也能共享。这种知识复利是单纯收藏提示词无法带来的。superpowers 会火本质上是因为它把 AI 编程从“每次靠临场发挥”推向了“可沉淀、可复用、可交付”的新阶段。2. 安装前准备与本地方案选型2.1 前置条件先满足再动手安装 superpowers 之前先把基础环境理清楚否则出了问题你很难判断是技能的问题还是环境的问题。支持 Skill 机制的 AI 编程终端目前主流是 Claude Code此外 Cursor、Cline、Roo Code 等也有各自的 skills 加载方式。我用的是 Claude Code下面的路径和命令都基于它其他工具的读者以官方文档为准。Node.js 18 以上以及 Git。技能库本身主要是 Markdown 和脚本文件但加载器依赖 Node 运行环境Git 用于拉取技能仓库。一个空的测试项目目录。强烈建议不要第一次就在重要生产项目上试因为你还不熟悉技能会怎么改动工作区里的文件先在沙盘里跑一遍更稳妥。网络上要能正常访问代码托管平台。很多安装失败的案例根本不是命令写错而是技能仓库没拉完整clone 过程中断了一截导致加载器找不到 SKILL.md。检查完这些之后建议先看一眼版本。不同版本的 CLI技能安装命令可能会有差异我见过不少人是照着旧教程敲命令结果报错的。先执行claude --version确认环境版本再搜索匹配的命令格式。2.2 安装方式的选型克隆仓库还是远程安装我在实际使用过程中试过两种安装路线各有适用场景。一种是克隆仓库到本地。这种方式能看到技能库的全貌适合学习型选手。你可以逐个打开技能文件看里面的步骤设计、检查清单、依赖说明甚至直接改造成自己的版本。第一次接触 superpowers 的人我建议走这条路。把项目 clone 到~/superpowers之后先ls skills看看有哪些技能目录再决定装哪几个。另一种是使用 CLI 的远程技能安装命令适合已经熟悉技能内容、想快速在团队里铺开的场景。这种方式会自动拉取技能文件到对应目录省去手动复制但对技能内容没有本地审查环节。如果团队要批量部署我更倾向于先安排一个人把技能仓库审一遍再让大家统一安装。因为技能文件本质上是可执行指令如果上游被投毒或篡改AI 可能会按照恶意流程操作这个风险不能忽视。2.3 认识技能目录结构先弄懂再动手不管哪种安装方式最终技能文件都会落到某个目录下。你需要先把目录结构搞清楚因为后面大量排查工作都跟“文件放错位置”有关。一个技能在文件系统里就是一个独立文件夹里面通常包含skills/ code-review/ SKILL.md checklists/ security.md performance.md scripts/ collect-diff.jsSKILL.md 是技能的入口文件固定放在该技能目录的根目录下。加载器扫描技能时首先读取 SKILL.md 里的 YAML 头部拿到技能的 name 和 description决定这个技能该在什么场景被触发。其他附属文件比如检查清单、参考文档、辅助脚本都通过相对路径引用。只要 SKILL.md 损坏、路径层级多包了一层或者 YAML 头部格式写错这个技能就会被加载器忽略。我见过最典型的错误是把skills/code-review/SKILL.md误放成了skills/code-review/doc/SKILL.md结果 AI 始终找不到这个技能。所以安装完先别急着用把目录结构里 SKILL.md 的位置确认好后面能省很多事。3. 实操过程把 superpowers 一步步引入工作区3.1 拉取技能仓库到本地第一步把技能库 clone 到本地。不同的分发源会有不同的仓库地址但结构上大同小异git clone https://github.com/xxxx/superpowers.git ~/superpowers cd ~/superpowers ls skills如果 clone 失败先看网络能不能正常访问托管平台再看仓库地址有没有拼错。不要急着怀疑命令绝大多数情况是网络没能完整把仓库拉下来。clone 成功后输出里会显示接收对象和解析对象的计数看到几十个目录都正常说明技能文件基本齐了。ls skills这一步很重要它会告诉你这个技能库到底内置了哪些能力。一般常见的分类有代码审查、测试生成、Git 工作流、重构、调试、文档编写等。先看目录名再打开两个感兴趣的文件读一读你会对这套体系有更直观的感觉。别急着装先逛一圈。3.2 把技能文件装入用户级技能目录接下来把需要的技能安装到用户级技能目录。Claude Code 默认会扫描~/.claude/skills/下的所有技能文件夹。你可以直接复制也可以做软链。我推荐用软链因为技能库如果更新了你可以直接git pull不需要重新复制mkdir -p ~/.claude/skills ln -s ~/superpowers/skills/code-review ~/.claude/skills/code-review如果你用的是项目级技能目录则是在项目根目录下创建.claude/skills/结构一模一样。项目级的好处是技能跟着项目走团队其他人 clone 项目后自动就有了适合把团队规范固化到代码仓库里坏处是每个项目都要单独装配。全局级适合放那些你在所有项目里都需要的通用技能比如代码审查、Git 规范。我个人的习惯是通用技能放全局专属规范放项目。这里有一个容易被忽略的权限问题如果技能里带了可执行脚本记得确保脚本有执行权限否则 AI 调用工具时会报权限错误。用chmod x处理一下脚本目录。3.3 验证技能是否真的被加载装完之后最关键的一步是验证。很多新手装完就当完事了结果真要调用时才发现 AI 根本没加载到技能白白浪费时间。第一种验证方式是在交互界面里输入/skills正常情况下会列出当前环境所有可用技能看到code-review出现在列表里说明目录扫描环节没问题。看不到就重点查目录位置和 SKILL.md 格式。第二种验证方式是直接对话测试。找一个有 Git 历史的小项目输入调用 code-review 技能审查最近一次提交的代码变更。然后观察 AI 的响应。如果它说“我准备使用技能 code-review”并且开始执行git diff、按清单逐项检查最后输出带路径和行号的审查报告说明技能完整生效了。如果它只是泛泛回答“这次提交看起来还不错”那大概率技能没有触发成功。还可以用调试模式跑一次非交互命令看日志里有没有出现技能加载记录claude --debug -p 调用 code-review 技能审查当前目录 src 下的代码看到类似 “Using skill: code-review” 的日志输出才算真正落地。3.4 按需启用别把整套技能全塞进去第一次体验 superpowers 时我犯过一个错误把技能库里的所有技能一股脑全装进了~/.claude/skills/。结果对话时 AI 每次都要扫描一堆技能描述上下文占用变高响应变慢而且技能多了之后description 之间还会发生冲突——比如“code-review”和“security-audit”两个技能的触发条件高度重合AI 不知道该调用哪个。后来我收敛了策略只保留当前项目高频使用的两到三个技能其余临时需要时再手动装。技能装得少AI 的调用准确率明显提升。这跟现实世界是一样的工具箱里工具太多你反而会找不到最趁手的那把。4. 核心技能拆解与实战使用要点4.1 一个标准技能文件的内部结构要真正用好 superpowers不能光会装还得看得懂技能文件。我打开一个典型的 SKILL.md 给你拆解一下--- name: code-review description: 对代码变更执行系统性审查覆盖安全、边界条件、性能、可读性。当用户提到审查代码、review changes、帮我看看这次提交时使用。 --- # 执行步骤 1. 使用 git 获取变更文件列表。 2. 按安全、边界、性能、可读性四轮逐一检查。 3. 输出审查报告每条问题必须包含文件路径和行号。 # 质量要求 - 安全问题必须优先标注。 - 每条建议必须给出理由禁止空泛评价。 - CI 配置变更要额外检查是否引入不可信代码。 # 参考文件 - checklists/security.md - checklists/performance.mdYAML 头部的name是技能的唯一标识description是加载器决定触发时机的重要依据直接决定了 AI 在什么情况下会想到调用你。我甚至见过有人为了让技能更易触发在 description 里写了十几个可能的触发词效果反而变差。简洁、覆盖高频场景才是更合理的写法。正文部分以“执行步骤 质量要求 参考文件”三段式最实用。执行步骤要具体到可操作质量要求要给出可验收的标准参考文件用来挂更长篇的检查清单避免单个技能文件臃肿。4.2 实战场景一让 AI 按技能执行代码审查场景设定你刚完成一个功能分支想在合并前让 AI 做一轮代码审查。没有技能时你可能会写“帮我审查一下代码”然后 AI 给你几句正确的废话。有技能时我通常是这样下指令的使用 code-review 技能审查 main 分支相对于当前分支的差异重点检查安全隐患和边界条件。技能生效后AI 会自动按技能文件里的步骤执行。它会先运行git diff main...HEAD拿到变更列表然后逐一打开文件进行解析再按安全、边界、性能、可读性的顺序过一遍检查清单。最终输出通常长这样安全问题 1 条src/api/auth.ts:87使用eval解析响应体存在代码注入风险。边界条件 2 条src/utils/format.ts:23未处理null值src/services/order.ts:56除法未校验分母为 0。性能建议 1 条src/router/index.ts:42循环内调用fs.stat可改为批量读取。这种报告的价值在于每条问题都指向具体位置并且附带理由你可以直接拿去修。为什么技能能做到这一点因为技能文件里明确写了“每条问题必须给出文件路径和行号禁止空泛评价”这句话强制执行了输出质量。这背后是合理的设计如果只让 AI“好好审查”它不知道你的验收标准技能把验收标准前置了AI 就能按图索骥。4.3 实战场景二用技能批量生成单元测试写单元测试是很多人头疼的事有了技能之后思路也完全不一样了。我会这样下指令调用 test-generation 技能为 src/utils/format.ts 生成测试文件覆盖正常路径、边界值和异常输入。技能会先读取源文件分析函数签名和行为逻辑然后列出测试矩阵最后补充测试用例。比如遇到formatDate这样的日期格式化函数技能生成的测试会覆盖import { formatDate } from ../utils/format; describe(formatDate, () { it(正常路径格式化标准日期, () { expect(formatDate(new Date(2024-01-15))).toBe(2024-01-15); }); it(边界情况闰年 2 月 29 日, () { expect(formatDate(new Date(2024-02-29))).toBe(2024-02-29); }); it(异常输入非法日期对象, () { expect(() formatDate(new Date(invalid))).toThrow(); }); });注意这里的关键点技能不是简单生成几个“看起来像测试”的用例而是会先拆解函数的行为矩阵。通常包括正常路径、边界值、异常输入、类型不匹配这几大类。社区里很多 superpowers 相关的技能还会内置变异测试的思路比如在建议测试时提醒你“检查断言是否真的能捕获错误实现”。这些是普通提示词很难一次交代清楚的东西技能却能稳定做到。4.4 实战场景三把自己的团队规范写成技能用久了别人的技能你就会想把自己团队的规范也写成技能。这其实是 superpowers 最大的长期价值所在。我提供一个极简模板你照着改就能用--- name: frontend-review description: 前端项目合并前审查重点关注组件性能和无障碍访问。当提到前端审查、组件检查时使用。 --- # 步骤 1. 列出变更涉及的组件文件。 2. 检查每个组件是否有不必要的重复渲染。 3. 检查所有交互元素是否具备可访问性属性。 # 质量要求 - 重复渲染问题必须给出具体 props 或 state 变化原因。 - 可访问性问题必须标注缺失的 ARIA 属性或键盘事件。写技能的过程中我最大的体会是技能文件是写给模型看的操作手册不是给人看的博客。所以步骤必须具体到可执行质量要求必须量化少用“合理”“合适”“规范”这类模糊词。你把它当成给一个聪明但没经验的实习生写任务书就有感觉了。5. 常见问题与排查技巧实录5.1 技能明明装了AI 却说找不到这是我被问得最多的问题。现象是技能目录已经存在SKILL.md 也放到位了但 AI 就是好像不知道这个技能。排查按下面的顺序来能解决九成的问题可能原因检查方式解决办法目录层级多包了一层到技能目录下看 SKILL.md 是否直接存在调整目录结构确保 SKILL.md 位于技能目录根下SKILL.md 头部的 YAML 格式错误用文本编辑器打开检查有没有缩进错误修正 name/description 字段注意冒号后要有空格技能目录没有在加载扫描范围内用/skills查看当前加载列表把技能复制到正确的全局或项目技能目录description 里的触发词太窄回忆你输入的关键词是否和触发词完全对不上在对话中明确点名“调用某技能”或在 description 增加同义触发词加载器版本过旧检查 CLI 版本升级到支持 skill 机制的版本排查时我建议先用ls直接进目录看文件树确认路径没有问题。然后再考虑是不是加载器的问题。不要一上来就把技能文件删掉重装很多问题只是目录或格式细节。5.2 技能触发了但执行效果跟普通对话没什么区别有时候你会遇到更隐蔽的情况AI 确实加载了技能但输出的质量依然很水。这通常不是技能没生效而是你的指令和技能之间的衔接出了问题。比如我原本期待的代码审查报告应该是结构化、分维度的结果 AI 只是简单说“代码写得很规范建议补充注释”。回头复盘才发现问题出在我的指令不够明确“审查一下代码”这个说法太模糊连技能都很难判断你的验收期望是什么。解决办法是在指令里补充验收要求“按技能里的审计维度和输出格式执行”。换句话说技能负责提供标准作业程序而你负责告诉 AI“这次严格按标准作业程序来”。另外如果技能文件里的步骤本身写得比较抽象比如只说“检查代码质量”那 AI 执行起来也会摸不着头脑。我后期一般会在技能里加一句硬性要求“禁止输出空泛评价每条结论必须有代码位置支撑”效果会立刻不一样。5.3 token 消耗比预期高怎么优化技能是一把双刃剑。技能文件写得再精简一旦加载进上下文它总归要占 token。实际项目中我遇到过一种情况某个技能目录里塞了好几个大文件光是参考文档就有几十 KBAI 每次调用技能都要把这些文件全部读完token 开销立刻上去了。优化思路有两个一是精简技能文件本身把那些过长的示例代码放到独立目录让模型需要时再去读而不是一次性全量加载二是按需启用不要在~/.claude/skills/里堆太多技能。后来我给自己定了一条规则在线技能不超过五个且每个技能正文不超过一百行。这个阈值不一定适合所有人但值得参考。我还观察到技能触发时机也会影响 token。如果 description 写得太宽泛比如一个“代码审查”技能描述了几乎所有场景AI 会在很多不相关的任务里也顺手加载它。把触发条件收紧只在真正相关的对话里才让技能登场token 消耗会明显降下来。5.4 多个技能冲突AI 选错技能怎么办当你的技能库越来越丰富难免会遇到两个技能的触发词高度重合。比如“code-review”和“security-audit”都声称在“审查代码”时使用AI 可能就懵了。遇到这种情况我建议在 description 里明确边界。比如让 code-review 聚焦“合并前的常规审查”让 security-audit 聚焦“安全专项审阅包含依赖扫描和注入检测”。同时在对话里你也可以点名“使用 security-audit 技能忽略常规 code-review”。点名是最高优先级几乎不会有歧义。更深一层技能之间其实可以互相调用。我见过有人在 code-review 技能里写“如果变更涉及网络请求调用 security-audit 的依赖扫描步骤”。这种设计更接近真实工作流但需要你先把技能之间的关系理清楚别让它们变成一锅粥。6. 关于 superpowers 的一些个人体会说句心里话superpowers 这类技能库给我的最大启发不是它有多少现成技能而是它让我重新理解了“AI 提效”这件事。过去总觉得让 AI 干活靠的是更聪明的模型、更长的提示词实际上很大一部分天花板在于我们有没有把“正确的工作方式”交付给模型。模型学的是模式但你给它一个稳定可靠的流程它能跑出远超预期的结果。我在实际项目中用了一两个星期之后最大的改变不是代码写得更多了而是我在团队里推进了一个内部技能库。把发布检查清单、接口变更通知规范、数据库迁移注意事项都写成了技能文件。回过头来这就是老师傅经验的产品化——每个踩过的坑、每条必须检查的节点都变成了 AI 可执行的标准动作。superpowers 只是一个起点真正有价值的是你围绕它沉淀下来的那套属于自己的技能体系。最后分享一个实际操作的小习惯技能库更新很频繁不要迷信“装一次用一年”。每隔一段时间用真实的小项目把关键技能回测一遍看看有没有因为基础库变化而失效。AI 编程工具的更新速度很快技能也像软件一样需要维护保持这种意识你就不容易被版本迭代甩下车。