superpowers 这个词这段时间在圈子里热度一直没降下去我在各个社区看到的问题也高度集中它到底是什么、怎么安装、里面有哪些 skills、以及最关键的一句——怎么引入这些技能。我把它完整跑了几轮之后可以负责任地说这套东西不是一个花哨玩具而是建立在 Agent Skills 机制上的一套可复用能力包本质上就是把 Claude 从你问一句、它答一句的对话工具变成有固定工作方法、能接手完整流程的执行系统。这篇文章我把安装步骤、引入方式、常用技能清单、一次完整实战的执行过程全部走通适合刚接触 Agent Skills 的新手也适合已经在用但想系统把机制理清楚的开发者。1. 为什么它叫 superpowers先搞懂 Skill 机制再谈安装很多人第一次看到 superpowers 这个名字第一反应是这又是一个提示词合集吧。我第一次也这么想实际看过它的目录结构之后才意识到它跟丢给你 50 条 prompt完全不是一回事。1.1 用技能而不是提示词来思考提示词解决的是一次对话怎么展开而技能解决的是某个领域的工作方法怎么稳定复用。打个比方提示词像你临时交代一个实习生今天报告这么写技能则像你给了实习生一本《这家公司报告撰写规范》里面写清了封面格式、章节结构、数据标注规则、审查清单。只要他接到的任务是写报告他就会自动翻开这本规范按照里面的流程走。superpowers 做的事情就是把 Claude 能干的活儿按照领域拆成一个一个技能包。每个技能包里面有一份SKILL.md描述该技能是什么、在什么场景下触发、执行步骤是什么若干辅助资源模板文件、脚本、参考文档、检查清单可执行的动作脚本有些技能会调用外部工具做文件处理、数据分析等操作当用户的请求命中某个技能的场景描述时Claude 会按需读取这个技能目录中的内容然后按照SKILL.md里定义好的流程执行。注意这里的两个关键词按需、流程。它不是把所有技能一股脑塞进上下文而是用到哪个读哪个读到的内容是带有明确操作步骤的方法论。1.2 为什么社区喜欢管它叫 superpowers因为这套机制补上了大语言模型一个天然短板模型本身不知道某个领域的高手是怎么工作的。你让它写一个竞品分析它可能直接给你列一个通用框架但这个框架跟你们行业、跟这个产品、跟当前汇报对象的偏好没有关系。而技能可以把这些领域内的隐性知识显性化变成一套固定动作。社区里普遍流传的 superpowers 集合往往包含几个大类头脑风暴、任务规划、结构化写作、代码审查、系统设计、数据清洗、日志分析、报告生成等。每个技能内部都在重复同一个思想——把思考过程固化成步骤把输出格式固化成模板。当你给 Claude 配上这么一套技能之后它的输出质量会呈现出一种稳定感不是偶尔一次好而是每次都按同样的专业路线走。这就是超能力的由来。1.3 它和插件、MCP 到底是什么关系这一段必须说清楚不然很多人会装完还是懵的。传统插件常驻运行、有 UI、绑定在某个平台上功能固定往往需要联网注册、授权。MCPModel Context Protocol主要解决模型怎么访问外部数据和服务相当于给模型接上了手和眼睛能读数据库、操作浏览器、调 API。Agent Skills解决的是模型接到任务之后怎么干活相当于给模型武装了一套工作方法论。你可以这样理解MCP 负责让模型能碰到外部世界Skill 负责让模型知道碰到了之后具体该怎么做。两者是可以配合的。superpowers 体系聚焦在 Skill 这一层它不替代 MCP也不是传统插件它是在模型大脑和外部世界之间补上了工作姿势这一层。2. 安装不是重点放对位置才是三步把技能包落到本地网上关于 superpowers 的安装教程不少但很多都只讲了git clone 一下、放进目录没有讲清楚放哪个目录有什么区别、为什么有的项目里识别不到。这一节我按自己的实测结果把整套流程说完整。2.1 第一步准备目录结构并获取技能包先明确一点一个技能就是一个文件夹文件夹内必须有一个SKILL.md文件这是该项技能被识别的唯一硬性条件。社区里的 superpowers 项目通常是一个仓库里包含多个这样的技能文件夹每个文件夹都是一个完整技能。我建议先建好目录骨架再获取技能包。以 Claude Code 最常见的安装路径为例mkdir -p ~/.claude/skills cd ~/.claude/skills然后从社区仓库获取技能包。如果用 git 方式git clone superpowers仓库地址 ./superpowers如果你只想要里面某几个技能而不是全部完全可以只复制对应的子文件夹到~/.claude/skills下。这一步没有任何魔法本质就是把文件夹放到该放的位置。2.2 第二步三个放置位置决定技能作用范围这是很多人踩坑的地方。技能包放在不同位置生效范围完全不一样。我整理了一张表是我实测过后觉得最清晰的分法放置位置路径示例生效范围典型使用场景用户级~/.claude/skills/当前用户的所有项目通用的工作方法比如报告模板、写作规范、代码审查流程项目级项目目录/.claude/skills/仅当前项目项目专属的方言、架构规范、发布检查清单团队级团队共享的 skill 仓库所有克隆了该仓库的成员统一团队输出规范、新人 onboarding 流程我刚开始用的时候把技能放进了项目目录的.claude/skills换了个项目之后死活触发不了排查很久才发现是路径错了。这里提醒一句如果你希望某个技能在所有项目里都生效务必放在用户级~/.claude/skills如果只希望某个项目使用放项目级如果团队要统一建议单独维护一个 skills 仓库成员各自 clone 并建立软链接。2.3 第三步用 CLAUDE.md 做引导接线文件夹放进目录之后技能并不会自动全局生效它只是进入了候选池。真正让它稳定被调用通常需要两个条件用户请求内容与该技能SKILL.md中description字段描述的场景匹配在CLAUDE.md中做显式引导告诉 Claude遇到什么任务优先看哪些技能。我强烈建议写一份CLAUDE.md放在项目根目录或~/.claude/CLAUDE.md。示例# CLAUDE.md ## 工作偏好 - 涉及任务拆解时优先使用 superpowers 中的 planning 技能。 - 涉及周报、月报、汇报文档时优先使用 writing 技能并严格按其中的模板输出。 - 涉及代码调试时使用 debugging 技能按照其步骤先定位再修复。这段配置看起来简单作用非常大。它相当于把一个一个技能接线到了具体任务类型上减少模型自己猜的概率。实测下来写完这份引导文件之后技能触发率提升非常明显。2.4 验证技能到底装没装好、有没有被触发装完不能闷头用先做一次最小验证。我的做法是分三层验证第一层验证目录确认SKILL.md文件存在并且内容包含name和description两段元信息。很多技能无法被识别就是缺少这两个字段。第二层验证加载在对话中直接问一句你可用哪些技能或者列出你收到的 skills 清单Claude 应该能列出对应的技能目录信息。第三层验证执行故意给一个能命中该技能描述的简短任务比如帮我把当前项目做一个两周开发计划然后观察它是否按照技能中的步骤输出而不是泛泛回答。第三层是最有效的验证。如果它给出了带明确步骤、模板、甚至带有检查清单的报告说明技能是真的被读进去并且执行了。如果输出跟平常没区别大概率是description写得太模糊或者CLAUDE.md里没有接线优先排查这两个方向。3. 一份能用得上的 skills 清单这些技能分别解决什么问题很多人在论坛上问superpowers 有哪些 skills其实不同的技能包集合差异挺大。我更建议按能力类别来理解而不是死记某个仓库里有什么。我按自己实际用下来觉得最有价值的四类逐个展开说说。3.1 规划与分析类把模糊目标变成可执行清单这类技能解决的是目标太大、无从下手的问题。典型代表是 planning 和 brainstorming。planning 技能的工作流程一般是先解读目标再拆解为阶段每个阶段下再拆任务任务要带上依赖关系和验收标准。它输出的东西不只是一个待办列表而是一份带时间线、风险点、里程碑的规划文档。我实际用来排过一次两周的项目计划它把开发登录模块这种一句话拆成了需求确认、接口设计、前端页面、后端逻辑、联调测试五个阶段每阶段都有出口条件。这种结构化程度靠临时对话很难稳定复刻。brainstorming 技能则是另一套逻辑它不强求立刻收敛而是先要求列出尽可能多的方案再按约束条件逐一筛选。做产品方案讨论的时候非常合适它会强迫你先把选项铺满再谈取舍。3.2 内容创作类从临时写手变成稳定的产出流水线这一类是大多数普通用户最先感受到超能力的地方。写作、文案起草、长文结构、总结提炼都归到这一类。以 writing 技能为例它通常内置了一套内容框架目标读者分析、核心观点、章节逻辑、素材引用位置、输出长度控制、质量自检清单。最关键的差异在于它有自检清单这一步——生成结束后它会按照清单重新检查一遍结构是否完整、逻辑是否闭合、是否有空话。这就让输出的稳定性提升了一个档次而不是偶尔灵光一现。对经常写周报、技术方案、产品介绍的人我建议重点体验一下这一类技能。你会发现同一个模型在接上技能前后的输出质量差异非常明显几乎像换了一个人。3.3 工程实践类把代码工作的老经验沉淀为固定动作代码审查、调试、系统设计、重构这类技能对开发者来说是实用的部分。debugging 技能一般会定义一套完整的排查链路先描述问题现场再列可能原因再逐个做最小复现最后修复并回归验证。它的价值在于逼着模型不要上来就猜答案。code-review 技能通常检查的维度包括安全性、性能、可读性、错误处理、边界条件、测试覆盖。我拿一个内部 PR 试过它抓出来的问题有异常信息直接暴露给前端不够安全这个循环里重复查询数据库这类细节而且每条都附了修改建议。这些工作方法如果你自己写 prompt也能写个大概但绝对没有技能包里的那么全。3.4 数据处理类把脏活累活变成规范作业日志分析、数据清洗、格式转换这类技能在面对真实数据处理任务时非常能打。比如日志分析技能它会规定先统计错误级别分布再按时间线聚合最后抽取 top 级异常并生成摘要报告。整个过程有一套明确顺序不会漏掉关键维度。数据清洗技能则会覆盖去重、缺失值处理、格式统一、异常值识别这些必经步骤每步都说明判断逻辑和输出结果。这类技能特别适合放在团队共享目录里因为数据处理规范的差异往往很大一旦沉淀下来收益是长期且稳定的。汇总一下我常用的技能清单技能类别典型技能适合场景关键产出规划分析planning、brainstorming项目排期、方案讨论任务清单、里程碑、风险点内容创作writing、summarize、draft周报、方案、长文结构化文档、自检报告工程实践debugging、code-review代码修复、代码审查定位报告、修改建议数据处理log-analysis、data-cleaning日志排查、数据预处理摘要报告、清洗结果4. 具体使用全过程让 superpowers 处理一个真实任务安装完技能、看完了清单下一步就是实际跑一个任务看看。这一节我以分析一份多模块项目的运行日志并输出问题报告为例完整展示一遍从发出请求到产出报告的链路。4.1 任务下达看技能如何被唤起我给 Claude 的输入很简单帮我看一下项目 logs 目录下今天的所有日志重点排查错误和性能异常输出一份可汇报的问题清单。这句话里其实有多个关键触发点日志、错误排查、输出报告。按照我前述的配置log-analysis 技能和 writing 技能都可能被唤起。实测中Claude 会先读取~/.claude/skills下各技能目录的索引信息然后选中最匹配的 log-analysis 技能读取它的SKILL.md紧接着才开始处理任务。这里有一个容易忽略的细节技能并不是一次对话里固定的角色设定它更像执行当前任务时的参考手册。同一个对话里如果先让 Claude 做日志分析再让它写周报它会在两个技能之间切换每次切换时读取对应的目录。这种按需切换的机制保证了不同任务之间不会互相污染上下文。4.2 执行过程拆解技能目录里那份 SKILL.md 起了什么作用打开 log-analysis 技能的SKILL.md内容结构通常长这样--- name: log-analysis description: 当需要分析应用日志、排查错误、统计异常、生成日志分析报告时使用。适用于 .log、.out、标准输出等文本日志。 --- # 日志分析流程 1. 先扫描全部日志文件统计日志级别分布ERROR/WARN/INFO。 2. 按时间线聚合错误信息过滤重复的同类异常。 3. 对每个错误类输出出现次数、首次/最后出现时间、相关堆栈前 3 行。 4. 识别慢请求或超时记录计算 p95 耗时如果日志包含耗时字段。 5. 最终输出问题清单、影响面评估、建议下一步操作。有了这份流程Claude 的行为就变得非常有章法它不会上来就根据看到的第一条异常下结论而是先做全量统计再做分类聚合最后才给结论。我那次任务的输出包含了三个关键错误类、一个影响较大的慢查询线索以及每条问题对应的修复建议。整个过程我是全程看着跑的它的中间步骤几乎每一步都能在SKILL.md里找到对应依据。4.3 使用节奏建议别一上来就全装全用我见过不少人刚装完 superpowers立刻把几十个技能文件夹全扔进~/.claude/skills然后发现模型变成了选择困难症——每个任务它都要在一堆技能里挑反而拖慢响应。技能虽好也要讲究使用节奏。我自己采用的做法是分三步渐进先保留 5 个以内跟自己日常工作最相关的技能跑两周看哪些真的频繁触发、哪些永远用不到。把用不到的技能先移出目录避免干扰把高频技能单独建立精简集。确认稳定之后再把低频技能放进一个独立的归档目录需要时临时复制回来。如果你一开始就想要一个完整体系也可以整套安装后依赖CLAUDE.md里写清楚的触发条件来控制。但我个人经验是技能数量越少模型选择正确的概率越高这个规律在 Agent Skills 机制下比想象中更明显。5. 跑顺之后要留意的坑以及怎么把它改造成自己的superpowers 跑起来不难但真正在日常工作中做到稳定、可控、不抢戏还是有几个地方需要特别留意。这一节我把踩过的坑和迭代思路都总结出来按重要性排序。5.1 最容易出问题的三个地方命名、描述、依赖先说命名。SKILL.md里的name字段是技能的唯一标识如果两个技能目录的name相同模型在加载时就会混乱。我之前试过把两份不同来源的写作技能同时放进去结果触发时它一会儿读 A 的步骤一会儿用 B 的模板输出不伦不类。排查办法是把名字改成带有前缀的形式比如superpowers-writing、team-writing降低冲突概率。再说描述。description字段决定了技能在什么场景被唤起写得太宽泛比如这个技能用于写作会导致几乎所有文本任务都去尝试写得太窄比如仅用于博客文章写作又会错过其他合适场景。我现在的写法是先写核心场景再补充触发词。例如当用户需要生成周报、月报、项目汇报文档或要求按规范输出文档时使用本技能。最后是依赖。有些技能包会带 Python 脚本或 shell 脚本执行依赖本机环境。安装之后建议先手动跑一下技能目录里的脚本命令确认依赖齐全。别看这条简单我遇到过一次技能包需要pandas而环境里没有导致整个任务卡在脚本报错上输出还不如不用技能时写出来的东西。5.2 自己封装一个技能比想象中简单收益却很直接很多人以为 skill 是只有大神才能造的东西其实不用写任何框架代码。核心就是把你的工作方法写成结构化文档再配上一个目录而已。我封装技能的三步法把你要沉淀的工作方法拆成 5 到 8 个固定步骤每个步骤写清楚做什么、输出什么。把这些步骤写进SKILL.md在文件头部写好name和description。把常用的模板、示例、检查清单放进同一个目录供技能运行时读取。以我个人封装的竞品调研技能为例SKILL.md内容大致是先明确调研目标再按能力范围拆解竞品维度功能、定价、用户反馈、市场定位每维度按统一的素材收集规范整理最后生成包含差距分析的报告模板。整套写下来不到一百行但在团队里复用起来非常趁手。5.3 让技能和 MCP 配合而不是互相替代前面说了 skill 管工作方法MCP 管访问外部数据两者可以组合。我常用的一个组合是通过 MCP 连接数据库和内部文档系统同时把数据抽取后如何生成分析报告的流程放进 skill 里。这样Claude 既能够自己去拿数据也知道拿到数据之后要怎么整理、怎么出报告。组合使用时的顺序通常是模型先判断任务需要什么数据MCP 去取然后判断该按什么流程加工数据skill 提供步骤最后产出结果。如果你已经接入了 MCP 又装了 superpowers你会发现两者并不冲突反而是天然互补。5.4 版本更新与团队共享把技能当代码来维护技能的本质是目录加文档所以它完全可以当成代码来管理。我现在的做法是把所有团队级技能放在一个独立的 git 仓库里成员通过 clone 或 submodule 引用。每次技能内容有调整就提交更新团队成员拉取后即生效。这里有一个很实用的技巧技能目录里可以加一个CHANGELOG.md每次改动记录一下改了什么、为什么改。这个文件本身不参与模型执行但维护起来极其有用。尤其是团队里有多人都会修改技能文档时没有版本记录很快会变成谁改了什么都不知道的状态。把这套流程跑起来之后superpowers 才能真正从一个个人玩具变成团队基础设施这也是我认为它最值得投入的部分。最后分享一个我在使用中养成的小习惯每次更新技能包之后不急着直接投入生产任务而是先丢给它一个小而典型的测试任务比如用 planning 技能把一个做饭流程拆成可执行步骤。这类任务足够具体能立刻暴露技能是否被正确加载、步骤是否合理。跑通之后再进入真实任务省下的时间远比测试那几分钟多。