★ FEATURED ARTICLE 用 AI 编程助手写代码最大的感受是什么不是它太强了而是它强得不太稳定。同一个需求状态好时三分钟给你写完整套逻辑状态不好时能在一个命名不规范的小函数上反复打转。我花了不少时间研究怎么驯服这种不确定性最后发现关键不在模型本身而在你有没有给 AI 一套可复用的技能体系。Superpowers 就是干这个的。它不是某个具体函数也不是普通的提示词模板而是一组被封装成 skills 的最佳实践集合能让 AI 像有经验的老手一样先计划、再动手、后测试、最后复盘。如果你也想给 AI 编程助手装上这种超能力并且正在找安装方法和技能清单这篇文章就是为你准备的。1. Superpowers 是什么先搞懂它解决什么问题1.1 一个痛点AI 很强但发挥不稳定用 AI 编程助手的人估摸都有过这种体验让它做一件边界清晰的单点任务比如写一个排序算法、配一个构建脚本它通常干得很利索。可一旦任务变成把这两个模块解耦再把公共逻辑抽出来它就开始天马行空了。有时候它会给你一套看似合理但根本跑不通的方案有时候又会把明明能用的代码改出一堆新 bug。为什么因为模型本质是在做模式补全。它看到上下文里有相似场景就会照着训练数据里的模式输出但它缺少一个稳定的工作流来约束自己。人写代码是有肌肉记忆的先想方案、再动手、写完自测、让同事 review。AI 没有这个肌肉记忆除非你把这些习惯显式地塞给它。Superpowers 解决的问题恰恰就在这里。它通过一套预制的技能包把 AI 从裸奔状态拉回受控状态。用打游戏来类比模型本身就是一个拥有满级属性的角色但如果你不给它技能栏它只会平砍Superpowers 就是那个技能栏装上哪个技能AI 才会用哪个招数。1.2 把最佳实践变成可加载的 skills先解释一个基础概念在 Claude Code 这类 AI 编程助手的体系里skill 就是一个文件夹里面放一个SKILL.md文件。这个文件开头有一段 YAML 格式的元信息写清楚技能的名字、用途、触发条件正文部分则是具体的执行步骤和注意事项。模型在会话中遇到匹配的任务时会去读取这个文件然后按照里面的指令来行动。Superpowers 就是一整套这样的技能集合而且它不是零散的小技巧而是把软件开发里最常用的一整个流程全部封装成了标准 skills。从动手前的计划拆解到写代码时的实施约束再到写完以后的测试、代码审查、故障复盘都有对应的技能。你可以把它理解成给 AI 配了一位实战经验丰富的技术总监。这位总监未必比模型聪明但他知道什么时候该刹车、什么时候该加油知道每个阶段应该产出什么从而让整个开发过程变得可预期。1.3 这套体系适合谁用个人开发者是最受益的群体。一个人维护整个项目时没人帮你做代码审查也没人逼你写测试AI 又容易放飞自我这时一套强制流程就能发挥奇效。小团队也合适特别是没有专职 QA 的团队让 AI 按流程补测试、做 review能省下大量人工轮巡的时间。刚接触 AI 编程的新手更应该用与其被 AI 的幻觉带进沟里不如一开始就让它走固定流程至少能建立先想再做的潜意识。不过也得说句实话如果你的项目处于强监管行业或者公司对 AI 输出有严格的合规要求那么开源社区的技能包只能做参考你必须基于它做内部定制。Superpowers 的核心价值是把成熟流程固化给 AI而不是让 AI 替你承担决策责任。这一点摆清楚后面用起来就不会有预期偏差。2. 安装前准备环境与版本选择2.1 核心依赖先装好 Claude Code要跑 Superpowers首先得有一个能识别 skills 的 AI 编程助手。目前我用得比较多的是 Claude Code。它是 Anthropic 官方出的命令行编程工具装在本地终端里可以直接读写你项目里的文件。安装前提是环境里已经有 Node.js 18 以上版本然后一条命令就能装完npm install -g anthropic-ai/claude-code装完以后跑一下版本号确认claude --version能正常打印出版本号就说明安装成功了。这里有几个容易踩的坑。第一如果 npm 源很慢建议先换成国内镜像我这边直接用 npmmirror 体验会好很多。第二如果你之前装过旧版本升级的时候最好加--force参数避免缓存冲突导致命令失效。第三Claude Code 的很多能力需要登录账号才能使用装完以后先跑一次claude按提示完成登录别等到用的时候才发现没登录。2.2 获取 Superpowers 的渠道Superpowers 不像一个独立 App更像一个技能包。获取渠道主要有三种项目官方的 GitHub 仓库、npm 上的发布包、以及社区整理的镜像。这里必须多说一句。你在 GitHub 上搜 superpowers skills会看到不少同名但来源不明的仓库这个现象在热门项目身上很常见。我强烈建议只从项目主页上给出的官方仓库地址拉取不要图省事用第三方二次打包的版本。技能包本质上是一堆可执行指令和提示词脚本如果作者在某个 SKILL.md 里夹带私货让模型在特定场景下执行额外命令你会发现起来非常困难。我之前就见过有人把安装命令改成远程脚本结果装完以后多了好几个无关依赖排查了半天才发现不对劲。2.3 安装后的目录结构长什么样装好以后你会看到类似下面的目录结构.claude/ └── skills/ ├── plan/ │ ├── SKILL.md │ └── scripts/ ├── implement/ │ ├── SKILL.md │ └── ... ├── debug/ ├── review/ └── ...每个技能一个目录目录里至少有一个SKILL.md。模型就是靠这个文件里的描述来判断这个任务该不该用它。如果是全局安装技能目录一般放在用户目录下的~/.claude/skills/这样你在任何项目里都能用如果只想在某个项目里生效就把它放在项目根目录的.claude/skills/下。前者适合个人常用技能后者适合和项目强相关的专用技能。3. 安装与引入实操两种方式一步步来3.1 方式一一键脚本安装最简单的安装方式是执行项目提供的安装脚本。以官方 README 里的典型方式为例大概长这样curl -fsSL https://install.superpowers.dev/install.sh | bash不过这里我得多啰嗦一句执行这类管道安装脚本之前一定先下载下来看一眼内容。不是开玩笑很多安全问题的根源就是用户跑了一行自己完全不了解的curl | bash。安装脚本做的事情大致是检查 Claude Code 是否存在、把技能仓库克隆到 skills 目录、最后给你打印一份使用说明。跑完以后不要急着进项目先确认脚本到底把它装到哪个目录了。有些安装脚本默认装到全局目录结果你在项目里怎么调都看不到。反过来也有只装到当前项目目录的情况你换个项目又得重新装。3.2 方式二手动克隆引入我更推荐手动克隆。虽然多敲几条命令但每一步都清清楚楚出了问题也容易排查cd ~/my-project mkdir -p .claude/skills git clone https://github.com/[官方仓库地址]/superpowers.git .claude/skills/superpowers注意把那段[官方仓库地址]替换成你从项目主页复制的真实地址。克隆完之后检查一下.claude/skills/superpowers下面是不是每个技能文件夹都有SKILL.md。如果没有说明作者可能调整了目录结构你要么按照最新文档调整路径要么换个版本号重新克隆。这一步细看目录的功夫特别重要。模型加载技能是严格按路径和文件名来找的目录不对技能就会被静默跳过而且不会报任何错误你以为装好了其实根本没生效。3.3 引入后的验证让 AI 说说自己有哪些技能装好之后进到项目目录启动 Claude Codecd ~/my-project claude然后在会话里直接问一句你现在可以加载哪些 skills如果配置正确它会列出一串技能名称和用途。部分版本还支持直接输入/skills以命令面板的形式展示可用技能列表。如果它一脸迷茫或者告诉你没有可用技能百分之九十是路径问题。技能目录没放在.claude/skills下或者SKILL.md的名字大小写写错了。此时打开终端执行ls -la .claude/skills检查一下确保技能文件夹确实存在并且里面的文件严格叫SKILL.md大写字母不能少。另一个常见原因是 YAML 头写错导致解析失败这个我在后面常见问题里单独说。4. 核心 Skills 清单这些超能力到底能做什么4.1 工作流级技能plan / implement / reviewSuperpowers 最核心的价值就在这套组合拳上。plan技能要求 AI 在动手前先输出一份任务拆解包括变更范围、涉及文件、风险点、以及实施顺序。以前我直接让 AI 做需求它经常一句好的我来实现就开始改代码改到一半发现方向错了。有了 plan 技能的约束它会先给你一份类似技术方案的东西你确认没问题了再进入下一步。implement技能用来约束 AI 在实施阶段一次只做一件事。每完成一小步它就会检查是否符合预期而不是一口气改十几个文件最后报错都找不到源头。review技能则是让 AI 以挑刺的视角检查代码。我第一次用就被震撼到了。以前让它帮我看看这段代码它只会回一句看起来没问题。挂上 review 技能之后它会列出具体的推理链、可疑点、潜在安全问题甚至直接给出修改后的 diff。那种感觉就像是突然多了一个眼里揉不得沙子的结对同事。4.2 问题排查级技能debug / fix / refactor查 bug 是最考验 AI 的场景。没有约束时AI 会东试一下西试一下甚至直接猜一个原因就开始改。带debug技能后它会要求你先复现问题、收集相关日志然后建立假设、验证假设、定位根因最后才动代码。这个流程听上去很基础但 AI 在执行时却很容易做到位因为它会一步步向你确认信息而不是一上来就给一堆猜测。fix和refactor是配套出现的。fix 聚焦以最小改动解决问题而 refactor 侧重在不改变行为的前提下改善结构。这两个技能绑定得很紧因为很多人的真实需求是帮我改得干净点结果 AI 改着改着行为就变了。有技能约束时AI 会在动结构之前先用测试把现有行为钉住然后再动手。这一点对老项目维护尤其重要我吃过太多次只改了重构却引入回归 bug的亏。4.3 工程治理级技能git / test / doc / postmortem除了写代码Superpowers 里还会带一批项目治理相关的技能。这些技能听起来不怎么性感但对项目长期健康度的帮助却很大。技能名用途典型触发指令plan动手前输出任务拆解与实施计划先用 plan 规划一下这件事implement按计划逐步实现一次只改一件事按计划实施debug系统化排查 bug先复现再定位根因帮我查一下为什么报错review代码审查找 bug、安全与设计问题review 一下这次改动refactor非破坏性重构保持行为不变重构一下这个模块test分析并补充测试覆盖给这个函数补测试git-workflow规范化提交信息与分支管理提交代码postmortem事故复盘分析与改进项输出复盘这次线上问题以git-workflow为例它不只是让 AI 帮你执行 git 命令而是约束它按照规范生成提交信息、检查本次改动的 diff、甚至在做危险操作前提前警告。test技能也不是简单地说写几个测试而是让 AI 先分析哪些路径需要覆盖用哪种测试框架合适然后有目的地补测试。postmortem技能则用在事故之后它会引导 AI 按照发生了什么、为什么发生、怎么做才能避免复发三步走输出一份结构化的复盘报告。4.4 引入技能的正确姿势显式指令 vs 自动触发这里有个很多人没搞明白的机制skill 有两种触发方式。一种是显式触发。你在会话里直接说用 plan 技能规划一下或者用 debug 技能查一下模型就会去读取对应的 SKILL.md然后严格按照里面的指令执行。这种方式最可控特别适合重要流程。另一种是自动触发。每个 SKILL.md 的 YAML 头里有一个 triggers 字段用来描述哪些类型的请求会自动命中该技能。比如 debug 技能通常会写当用户报告程序异常、报错、行为不符合预期时自动使用本技能。于是你只要把报错信息贴给 AI它就会自动走 debug 流程。我实际测试下来自动触发在多数日常场景下都能命中省去了反复强调请用某个技能的麻烦。两种方式没有绝对好坏。显式更可控隐式更省心。我的建议是越重要的流程越用显式比如上线前 review、方案计划越是日常杂活越依赖自动触发就好。不过自动触发也不是万能的如果触发条件写得过于宽泛模型反而会不知道该不该用。这个就牵扯到技能自描述了后面细说。5. 实际使用中的常见问题与排查技巧5.1 为什么 AI 没有按预期加载某个 skill这是问得最多的一个问题也是最容易排查的。常见原因有三个。第一路径问题。技能目录不在 Claude Code 读取的路径范围里。项目级技能必须放在.claude/skills/下全局技能必须放在~/.claude/skills/下两边不能混用。第二SKILL.md的 frontmatter 解析失败。YAML 的语法极其脆冒号后面没加空格、描述里用了中文逗号、多写了一个 dependencies 字段但对应技能不存在都会导致解析失败。一旦失败整个技能会被静默跳过不报错、不提示。第三描述写得太宽泛模型识别不了。比如你写 处理文件模型面对具体问题时很难判断处理文件到底指的是这个技能还是另一个更匹配的技能。描述里应该写明适用于什么场景、能带来什么好处、以及不用它会有什么问题。排查时我建议打开 Claude Code 的 verbose 日志模式。它会打印出是否尝试加载某个 SKILL.md的日志记录。看到Loaded skill说明命中看到Skipped就说明触发条件没满足。我第一次排查时就是没开日志对着项目目录翻来覆去看了半小时最后发现只是 YAML 里一个冒号后面少了空格。现在想想都觉得亏。5.2 如何快速自定义一个自己的 skill千万不要觉得 Superpowers 只能用它自带的技能。它的目录结构完全是开放的你可以照葫芦画瓢写一个属于自己项目的技能。步骤很简单。先在.claude/skills/下建一个新文件夹名字用短横线连接的小写单词比如api-contract-check。里面放一个SKILL.md开头是 YAML frontmatter至少写清楚 name 和 description有条件的写上 triggers 和 dependencies。正文就是具体的执行步骤比如先读取 xxx 接口文件再比对 yyy 文档最后输出差异表。写完之后在会话里说用 api-contract-check 检查一下订单模块马上就能用。我自己给团队写过不少这类小技能比如检查前端项目里的 console.log 残留生成数据库迁移脚本模板按公司规范格式化提交信息每一个都很简单但用起来极其顺手。这个自定义能力才是 skill 生态最迷人的地方。别人给的是启动器真正能跑多远看你自己的玩法。5.3 一些实操经验与避坑建议最后分享几个我用了大半年后的心得体会每一条都踩过坑。第一不要一次性引入全部技能。Superpowers 默认装上以后会有十几个技能但你打开一个会话时模型不一定会全部读取如果任务比较复杂它甚至可能在读取技能描述上浪费大量 token。我建议先挑plan、debug、review这三个用熟再逐步增加。每个技能都会在会话中占用一定的上下文空间装太多反而拖累正常对话。第二技能里的指令不一定百分百适用你的项目该改就改。比如我们团队的提交规范要求带上需求单号我就把git-workflow技能里的提交信息模板改成了带单号的格式。技能是死的项目是活的不要被默认值束缚。第三凡是涉及curl | bash的安装方式务必先看一遍脚本再执行。这个习惯能挡住大部分恶意安装和错误安装。第四定期更新技能包。Superpowers 这类项目更新节奏不慢作者会根据新版模型的行为调整技能描述旧描述可能会误导模型。我一般每个月更新一次更新前先看一下 changelog避免突然变化影响自己已有的定制。我在实际使用中还有一个很深的感受这类 skill 体系真正的瓶颈从来不是安装步骤而是你有没有想清楚想让 AI 遵守哪些流程。Superpowers 给你提供了一套默认的最佳实践但默认值永远不等于你的最优解。花十分钟改一改技能描述把你自己团队的习惯写进去可能比换一个更强的模型更管用。工具永远只是起点真正让 AI 变得可靠的是你对流程的思考。
阅读完成 · 觉得有帮助？
