如果你也在用 Claude Code 这类 AI 编程助手应该会注意到一个高频词superpowers。它不是什么超级英雄皮肤而是可以装进 Claude Code 的一套“技能包集合”目的就是给 AI 补充可复用的工作流能力。最近社群里的讨论集中在“具体怎么用”“有哪些 skills”“怎么引入”我干脆把自己从安装到上手的完整过程写出来给想尝试的人一条顺畅路径。先说清楚Superpowers 不是某个模型也不是一个“提示词模板”那么简单。它更像是一套打包好的技能目录每个技能都有独立文件Claude Code 读到对应场景后会自动把技能内容加载进上下文从而改变 AI 的执行方式。也就是说装上它之后AI 做任务时会开始有章法先想清楚目标再拆任务再动手再验证。对于日常写脚本、改 bug 和做小需求的人来说这种变化最直观的感受就是“AI 终于不再急着甩代码了”。1. 先搞清楚Superpowers 到底给你的 AI 助手加的是什么1.1 原生编码能力与“技能”本质上是两回事很多人刚开始以为“给 Claude 装 superpowers”就是让 AI 变得更聪明这个理解方向不对。大模型本身的代码能力在它被训练出来那天就固定了真正可以改的是“它在项目中如何工作、按什么顺序工作、输出前需要检查什么”。打个比方一个新人能力很强但你给他一台电脑他未必知道公司流程Superpowers 做的是把一套工作流程写进文件让 AI 在特定场景下自动遵守。Claude Code 原生也能写代码、读文件、执行命令但它的默认行为更像是“即时响应”你说改什么它就直接改。这种模式对简单任务没问题可一旦需求稍微复杂AI 就会开始猜甚至连续改好几轮都打不中要点。技能包解决的是“行为约束”不是“智力提升”。1.2 技能在 Claude Code 里的实际加载方式Superpowers 的设计很直白每个技能一个目录目录里有一个SKILL.md文件作为入口。文件头部是 YAML 格式的描述信息说明这个技能什么时候该触发文件正文是具体操作方法可以是分阶段步骤、检查清单、编码规范甚至可以直接让 AI 启动子代理去干某件事。当我在对话里说“帮我想个方案”时Claude Code 会去扫描当前环境里所有可用技能看描述符是否匹配。如果匹配到 brainstorming 技能它就会把该技能文件里写的那套“发散思路、评估候选方案的流程”注入到当前上下文中然后按这套流程执行。这里有个关键点技能不是常驻指令它更像“按需执行的 SOP”。你不需要每次手动喊它但也可以显式指定“用某个技能来干活”。这种按需触发机制的好处是省上下文坏处是你得理解每个技能的触发条件不然会以为技能没装上。1.3 为什么它在近期成了搜索热点最近“superpowers”这个词频繁出现在开发者讨论区直接原因有两个。第一越来越多团队开始把 Claude Code 纳入日常开发但他们很快发现每个人用 AI 的方式差异很大有人用得好有人用得差差就差在“流程意识”。Superpowers 把流程做成了可复制的技能包。第二Claude Code 的插件机制日趋成熟装技能不再需要手写一堆系统提示词几条命令就能搞定。于是大家开始找“有哪些 skills”“安装路径是什么”其实就是想把这套工程化的工作法搬到自己项目里。2. 打开技能清单Superpowers 里那些值得认识的 skills2.1 核心“工作流型”技能我在仓库的 skills 目录里翻到过不少技能这里只挑几个让我印象深刻的。brainstorming需求很模糊的时候它会要求 AI 先列出多种解决思路再对比每个方案的副作用、成本和验证方式而不是马上写代码。这个技能对我特别有用因为很多时候我还没想清楚自己要什么就让 AI 开写写一半才意识到方向错了。planning把一个大目标拆成可执行、可验证的小任务并标注依赖关系。它和直接给 AI 说“写个计划”不同它有一套固定的格式拆完之后还要让 AI 自己检查每个步骤是否真的可执行。tdd测试驱动开发。技能会要求 AI 先写失败的测试再写最小实现最后跑测试和重构。这个流程单独看没什么稀奇但让 AI 长期稳定遵守就很有价值尤其是改别人项目里的老代码时能倒逼 AI 不做无边界的大改。debugging它不是让 AI 盯着报错信息瞎猜而是先收集现象、建立假设再逐步隔离代码路径。实际用下来这个技能能明显减少“改一行跑一次再改一行再跑一次”的循环。2.2 偏工程化的“组合型”技能Superpowers 里还有一些偏工程编排的技能比如 subagent-driven development。大意是当任务规模较大时主代理先写计划文件然后派多个子代理分别去执行不同子任务最后统一汇总验证。这种做法在 Claude Code 的多代理机制下效果不错适合做并行开发或者长任务。这类技能不会在每次对话中主动触发因为场景比较重。但它给出了一个很好的思路AI 编程不只是“单兵作战”还可以把任务拆给多个子代理各自带上下文互不干扰。对于有复杂项目的团队这种技能的价值会更高。2.3 技能不是越多越好选择策略这里我必须泼一盆冷水不要装完全部技能就觉得自己无敌了。技能包的核心是“行为控制”控制得太多AI 反而会在简单任务上变得啰嗦。我自己的策略是“按项目选技能”。比如一个快速脚本项目只需要保留 debugging 和基础的执行能力一个需要长期迭代的功能模块就加上 brainstorming、planning 和 tdd。你可以直接编辑技能目录把不用的技能文件移出当前项目或是在SKILL.md的描述里写清楚触发边界避免 AI 动不动就把简单请求拽进全套流程。使用场景推荐技能组合原因临时脚本/一次性任务debugging轻量避免过度规划小型功能开发brainstorming tdd先明确方向再用测试兜底大型模块重构planning subagent-driven development需要拆解依赖控制风险线上问题排查debugging 单技能减少干扰快速定位根因3. 从零安装 Superpowers我跑通的两种方式3.1 方式一通过 Claude Code 插件市场安装在 Claude Code 里输入/plugin界面会弹出插件面板。选择添加 marketplace填上 Superpowers 的 GitHub 仓库地址然后执行安装。我当时用的命令大致是这样/plugin marketplace add https://github.com/obra/superpowers /plugin install superpowers如果你的 Claude Code 版本对命令格式有调整不要硬背直接去仓库 README 的 Installation 部分复制最新命令。这个项目迭代是真的快我一个月前装的版本和两个月前看到的文件结构已经有差异了。装完之后重启 Claude Code再输入/skills或者问一句“当前环境里有哪些可用技能”就能看到 Superpowers 带进来的技能列表。正常的话你会看到若干个带独立命名的技能名称旁边通常还有简短描述。3.2 方式二手动拉取仓库并注册为技能目录如果你所在的开发环境不方便用插件市场或者你想完全掌控技能文件的位置可以手动拉仓库git clone https://github.com/obra/superpowers.git拉下来之后把仓库里的 skills 目录链接或复制到 Claude Code 的全局技能目录mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/这样做的优点是目录结构一目了然想删哪个技能直接删文件夹。缺点是没有自动更新上游仓库更新后你需要手动git pull再把变更同步到本地技能目录。个人项目我推荐插件方式团队统一管理时手动方式更可控。3.3 安装后第一件事验证技能真的被读到了很多人装完技能后发现自己让 AI 做某件事AI 好像还是老样子于是以为装失败了。其实多数情况是触发条件没匹配上。装完后不要急着做复杂任务先花一分钟做验证在 Claude Code 里输入/skills看技能列表里是否出现了 brainstorming、planning 等条目。直接说“请使用 brainstorming 技能帮我梳理这个需求”观察 AI 是否切换成“分阶段输出”的模式。打开一个简单的报错场景让它用 debugging 技能排查看它是否先问现象、收集信息再动手改代码。如果名字出现在列表里但行为没变化多半是当前对话上下文过长或者技能描述里限定了触发场景。这时你可以手动指定技能名让 AI 强制参考对应文件。4. 引入技能的实操案例让 AI 按你的流程而不是它的习惯工作4.1 一个最小示例改造排查崩溃 bug 的方式我之前遇到一个偶发性崩溃项目里没有技能时AI 的做法是直接读相关文件然后给出一个自认为最可能的修复点。装上 debugging 技能后我会显式说“用 debugging 技能帮我查一下这个崩溃。”它会先去定位最小复现路径分析调用链用日志输出关键变量再定位疑似模块最后才动手改。这一步对效率和失误率的影响都很大尤其是在老项目里。如果你已经装了 tdd 技能它还会在修完 bug 后主动补一条回归测试。以前这些是人为提醒的现在技能文件里写明了步骤AI 不执行反而像漏了步骤一样。4.2 主动调用技能的最直接句式技能包不是魔法开关但它确实提供了稳定的触发入口。最直接的方式就是一句话“用某个技能做某件事”。比如“用 brainstorming 技能先帮我列三个可能的方案再评估。”“用 planning 技能把这个功能拆成 5 个以内的子任务。”“用 tdd 技能给这个函数补测试。”这种写法等于告诉 Claude Code“这个任务有专门工具请翻对应文件”。实测下来AI 的响应结构会变得非常清晰不会东拉西扯。4.3 把团队规范写成自定义技能Superpowers 最好的扩展方式不是囤别人的技能而是把自己的团队工作流也做成技能。比如你可以在~/.claude/skills/code-review/SKILL.md里写死一套代码评审标准先看安全风险再看可读性再看性能最后检查测试覆盖。Claude Code 在收到“帮我 review 这段代码”时会自动按这个顺序走。这种做法相当于把经验沉淀成“团队记忆”不管谁用 AI都会按同一套规则执行。这也是我最终觉得 Superpowers 这类设计有意思的地方它本质上是让每个人都能给 AI 写标准作业流程。5. 我踩过的坑和现在的使用习惯5.1 坑一全量加载后AI 开始“过度规划”我第一次安装时直接保留了所有技能结果 AI 连“帮我改个变量名”这种操作都想先开 planning。它甚至给我列出一个三步计划再问我“是否继续”。表面上流程很规范实际上把简单事搞复杂了。后来我把触发描述改窄并且只保留当前项目需要的技能文件情况才正常。5.2 坑二多台机器之间的技能配置不一致我家里和办公室各有一台开发机一开始只在一边装了技能另一边没装导致两边行为差异很大。后来我把技能目录纳入 dotfiles 管理每次同步配置时一起推送。如果你和队友协作最好在项目仓库里保留一份技能文件路径说明或者在文档里写清安装命令避免有人“裸奔”有人“满配”。5.3 坑三上游更新太快改造本地文件容易冲突Superpowers 的更新频率不低我自己也忍不住改过技能文件里的细节。结果下一次同步时本地 git 冲突搞得我很头疼。现在我的习惯是不直接改上游文件如果需要定制就在自己的技能目录里新建一个技能引用上游思路但写成适合自己的版本。这样既保留了我的定制又不影响拉取更新。5.4 我目前实际使用的技能子集和工作流现在我的项目里只保留了四个技能brainstorming、planning、tdd、debugging。需求特别模糊时先过一遍 brainstorming复杂度较高的功能才用 planning涉及核心逻辑修改时强制走 tdd线上问题只用 debugging。这样一个配置既不会让 AI 在简单需求上长篇大论又能在关键环节稳住节奏。在我自己实际使用的过程中最明显的体感是“AI 说人话的时间变多了瞎写代码的时间变少了”。技能包不会让 AI 突然变成架构师但它能够把你平时需要反复在提示词里强调的规范变成一套稳定的、可复用的文件结构。如果你正准备尝试 superpowers我的建议是先装最小的子集严格验证一条流程跑顺了再逐步加。这比一口气把全套技能都塞进去更容易看清它到底值不值得留在你的工具箱里。