★ FEATURED ARTICLE 如果你和我一样在Claude里做稍微复杂一点的事就忍不住重开对话窗口那这篇文章应该对你有用。我前阵子频繁被一个问题困扰每次让Claude写方案、查Bug、排计划都要从头铺陈背景讲到一半还担心它忘了需求只能一遍遍强调。后来同事丢给我一个开源插件叫superpowers我一开始以为又是噱头试了之后才意识到问题不是Claude不够聪明而是我从来没把自己的工作方法沉淀下来交给它。superpowers做的事情其实很朴素把专家级的工作流程封装成一个个可复用的skills技能让Claude在合适的时机自动调用而不是靠你现场口述。这篇内容基于我用它几个月的真实经历从是什么、怎么装、预装技能有哪些到自己动手写skill、避坑按我的踩坑顺序完整梳理一遍。适合两类人刚听说superpowers、想知道装了能干什么的入门者以及已经在用、但没想清楚怎么把skills私有化和自定义的进阶用户。1. superpowers到底是什么先绕过超能力这个名字看清本质1.1 从一个让我抓狂的深夜讲起有段时间我负责一个跨团队的技术方案Claude帮了大忙但到了对话第四轮它忽然一本正经地开始推翻我们已经确认过的技术选型理由还很充分。那一刻我真的想把窗口关了重开。冷静下来复盘我发现问题不在Claude而在我的用法上我什么都没教它只是甩了一个任务过去。Claude不是不聪明是缺少工作方法。这个场景可能很多用过AI助手的人都不陌生。你让它写需求文档它第一版就洋洋洒洒给你五千字但你心里清楚它连目标用户是谁都没确认。你让它修Bug它看了报错就给答案结果改完治标不治本。这不是模型能力不够而是我们预期的专家级处理流程从没被明确告诉过它。superpowers刚好命中了这个痛点。它把一套套专家级的工作流封装成可复用的skillsClaude会在遇到匹配场景时自动加载对应技能并按技能里写好的方法论执行。换句话说你不再需要每次对话从头教Claude先分析需求再给方案装好之后它会自己按这套流程来。我后来大概花了一两个月把superpowers从安装、使用到自定义整个摸了一遍这篇文章算是这段经历的记录。1.2 SkillsClaude的能力外挂规范想真正理解superpowers得先搞清楚它依赖的底层机制——Claude Skills。一个skill本质上就是一个包含SKILL.md文件的文件夹。SKILL.md开头有一段YAML格式的元信息声明技能名称和触发描述正文则是具体的执行步骤、适用场景、注意事项还可以附带脚本、参考文档等资源。Claude在收到用户请求时会根据对话内容和技能描述自动决定要不要唤醒某个技能唤醒后技能里的指令会作为额外的上下文注入指导它按特定流程工作。打比方的话Claude是那个高智商但是刚入职的新人Skills是你给他准备的岗位SOP手册。新人不会主动按你的习惯做事但他非常擅长照着SOP执行。superpowers就是一个已经写好了大量高质量SOP的资深专家你把他请进来团队的执行力自然就上一个台阶。这也是我后来才想明白的事跟AI协作的下一个阶段拼的不是谁的对话技巧更花哨而是谁沉淀的SOP更专业。同样一个模型装了一套好skills之后产出的水平会明显不一样。1.3 superpowers在Skills生态里的位置Skills是开放的规范任何人都可以写社区也已经有各种技能合集。superpowers是这里面做得相当特别的一个它不只是技能包更自带了一套和Claude高效协作的工作方法。比如它内置的brainstorming skill不是简单让Claude列十个点子而是要求Claude先确认问题边界再发散可能性然后帮你建立选项之间的联系最后收敛出可执行的方案。整个过程有节奏、有步骤像极了一位资深顾问在做前期调研。superpowers还有个理念让我印象很深强调用技能创造技能。你可以先用现成的brainstorming技能梳理自己工作中反复出现的流程再把流程固化成新的skill。工具的价值不只是封装的几个固定技能而是给了你一套可自我复制的方法论。这也是我后面自定义技能时一直在用它的原因。2. 安装与首次启动一条命令背后的目录结构2.1 前置准备先确认你的Claude环境安装之前先看手头环境支不支持skills。superpowers面向的是Claude Code这类支持技能机制的交互环境如果只是用普通网页聊天暂时没法直接跑这个插件生态这是很多新手没搞明白的第一件事。另一个前置条件是确认Claude版本足够新。Skills规范对不同版本有要求老版本可能加载不了甚至报错。我的习惯是装之前先跑一句claude --version然后把版本号和项目README里的要求对比一下。很多装上了没反应的问题八成都卡在这里而不是后面的安装步骤出错。2.2 安装步骤clone、注册、生效superpowers是开源项目迭代很快不同阶段的安装方式会有些差异。以当下主流的安装流程为例建议动手前先看一眼仓库的README避免照着过时教程操作。第一步把superpowers克隆到本地。我在终端里执行的是git clone https://github.com/obra/superpowers.git第二步在Claude Code中注册这个插件。通常是在Claude Code里执行插件安装命令指定刚才克隆下来的路径。不同版本支持的命令前缀不一样有的版本用/plugin有的版本需要在配置文件里手动指定路径。第三步重启会话让插件在启动阶段完成加载。首次加载时Claude可能会请求一些权限比如读取技能目录、允许运行脚本等建议先都允许否则后面部分技能会跑不起来。2.3 如何确认已经生效装完最怕的是静默失败看起来一切正常实际啥也没加载。我建议用两个办法确认。一个是在Claude Code里输入/plugin status看superpowers是否出现在已启用列表里。另一个是直接丢一个模糊一点的请求比如我想做个项目但还没想清楚方向帮我理理。如果Claude开始像顾问一样反问你问题而不是立刻给建议大概率就是brainstorming技能已经接管了。这个体验差异非常明显装没装成功一测便知。2.4 目录结构知道文件在哪后面才改得动装完之后值得花一分钟看看它的目录方便后续修改和自定义。以我本机的结构为例大致是这样superpowers/ ├── skills/ │ ├── brainstorming/ │ │ └── SKILL.md │ ├── planning/ │ │ └── SKILL.md │ ├── debugging/ │ │ └── SKILL.md │ └── ... ├── README.md └── ...技能根目录下的skills文件夹里每个子目录对应一个技能技能核心就是那个SKILL.md。如果你想全局生效可以把某个技能复制到用户级技能目录通常是~/.claude/skills如果只打算在某个项目里用就放进项目的.claude/skills目录下。这里有个容易混淆的点superpowers仓库里带了哪些技能和你当前环境里实际加载了哪些技能不一定完全一致。因为生效范围取决于你放到了哪个目录、插件加载了哪些路径。所以排查问题时第一件事永远是列出当前实际生效的技能目录而不是对着仓库里的文件清单猜测。3. 预装Skills清单superpowers的超能力具体长什么样3.1 创作规划类brainstorming、planning、writingsuperpowers最核心的几本SOP集中在创作和规划上这也是我日常使用频率最高的几个技能。brainstorming是在需求还不清晰时介入的。它的流程大致是先理解问题背景再生成多个选项横向比较最后筛选出最值得做的方向。注意它不会在第一轮回复里直接给最终答案而是像真正的头脑风暴一样先发散再收敛。刚开始用你可能觉得Claude变啰嗦了但习惯之后就能感觉到它产出的方案质量明显更高不是那种看着热闹却落不了地的点子集合。planning承接brainstorming的结果负责把方向转成可执行的步骤计划。它擅长拆解任务、识别依赖关系、预估风险。典型场景是方向定了帮我排一个两周的实施计划——它会先把大目标拆成里程碑再落到具体任务和验收标准。writing则偏向内容创作。它不是替你打字而是提供一套结构化写作框架先定受众和目标再搭提纲逐节推进最后检查表达一致性。比起让Claude直接写一篇走完这套流程出来的文章结构会扎实很多。我写对外发布的技术文章时已经习惯让它先按这个技能出一版框架再自己填充血肉。这三个技能经常串联使用脑暴定方向、计划排步骤、写作出内容。串联过程中Claude会主动切换技能这也是superpowers的一大特色——几个技能不是孤立的而是能按场景接力。3.2 工程排错类debugging与问题排查debugging是我几乎每天都在用的技能它改变了Claude面对报错时的行为方式不再是看了一眼错误就猜答案而是先复现、再缩小范围、定位根因、最后验证修复是否真的解决了问题。举个例子。以前我贴一段报错给Claude它经常直接给出一个可能是XX问题的修复建议改完发现没解决还得再来一轮。启用了debugging技能之后它会主动要求我补充上下文、建议我加日志、确认复现条件整个排错链路严谨了很多。时间久了你会发现它带着你走的这套排查思路也会反过来影响你自己排查问题的方式。源码里的工程类技能不止这一个还有配合联调、梳理调用链之类的应用。不过我的建议是先用熟debugging这一个它带给排查类工作的效率提升最直观。当你发现Claude不再急着给答案而是先问你是怎么复现的就说明这套方法论已经生效了。3.3 通用软技能类conversation、decision-making、negotiation、research这组技能覆盖的是非代码场景也是superpowers和其他工具包拉开差距的地方。conversation负责处理沟通类任务把模糊的需求聊清楚、把技术方案讲给非技术同事听。它会教Claude在关键节点停下来提问确认而不是一股脑输出。我经常拿它来练习怎么跟业务方对齐需求Claude扮演的角色像是一个训练有素的访谈者。decision-making适合几个方案各有优劣、不知道选哪个的场景。它会让Claude列出评估维度给每个方案打分标注不确定性最后给出带前提条件的建议。注意它不会替你拍板而是帮你看清决策依据和代价。negotiation针对的是价格、资源、排期等谈判场景。它把谈判拆成利益分析、底线梳理、话术组织几个环节对产品和技术的跨团队协作很有用。我自己在和合作方谈排期时会用它预演对话提前把对方可能的诉求和我的让步空间都想清楚。research则面向资料调研类任务。它让Claude明确调研范围、生成检索关键词、整理可信来源、输出带引用的总结。比直接甩一句帮我查一下XX要专业得多因为它会先确认你到底要解决什么问题而不是给你一堆泛泛的资料列表。这组技能让我重新理解了superpowers这个名字它不只是让你多会写代码而是把你做人时可能会用到的通用方法论都整整齐齐地装了进去。3.4 触发机制SKILL.md里的description决定一切上面这些技能为什么会在合适的时机自动出现关键在SKILL.md开头的description字段。Claude每次收到请求时会悄悄检查可用的技能列表对比当前对话意图和description的匹配度再决定加载哪个。所以description写得好不好直接决定技能能不能被正确唤醒。描述太宽泛会误触发太窄则该用的时候不用都影响体验。这也是我后来不太建议直接大改预装技能instructions部分的原因description是技能的对外接口一旦改了接口整个行为就可能不可预测。如果你觉得某个技能的行为不符合预期试着先调整description里的触发条件比硬改执行步骤要安全得多。4. 自己写一个Skill把重复劳动变成可复用资产4.1 从我为什么要写说起用了两周superpowers之后我开始不满足于只用别人写好的技能。我的工作里有一类特别重复的事Review前端代码。每次我都希望Claude按同样的标准来看代码——可维护性、边界条件、样式副作用——但每次都得把标准重新描述一遍还经常描述不全导致它这次看了性能、那次看了命名标准飘忽不定。这正是自定义skill的最佳场景把反复进行的审查动作沉淀成一份Claude每次都能稳定遵循的Checklist。你会发现一旦这个skill写好了之后所有前端Review都会按同一套标准来不会因为你的描述心情而波动。4.2 SKILL.md的基本结构创建自定义技能的步骤很标准。先在用户级技能目录下建立文件夹mkdir -p ~/.claude/skills/frontend-code-review然后创建SKILL.md基本骨架如下--- name: frontend-code-review description: 当用户要求审查前端代码、检查JS/TS/HTML/CSS代码质量、排查页面渲染或交互问题时使用。凡涉及组件逻辑、状态管理、样式写法的审查请求都适用。 --- # 前端代码 Review 指南 ## 目标 在给出结论前先按固定维度做完整检查避免只盯表面问题。 ## 执行步骤 1. 读取相关代码先梳理数据流和组件关系 2. 按以下三个维度逐一检查 - 可维护性命名是否清晰、逻辑是否重复、耦合是否过高 - 正确性边界条件是否处理、异步竞态是否考虑 - 样式副作用是否影响全局样式、是否考虑了响应式 3. 输出结构化结论按严重程度排序每条建议附带具体代码位置 4. 遇到不确定的行为先提出问题不做无依据猜测注意frontmatter里最重要的是description它不是给人看的是给Claude判断触发时机用的。正文部分则是技能的执行指南越具体越好可以用列表写步骤也可以附上几条示例甚至把完整案例放到references目录里用链接形式引用。4.3 让Claude主动想起来用你的技能description的写法很多人写的skill不生效原因多半是description写成了负责前端代码审查这种只描述职责的句子。真正有效的写法要包含三个要素触发场景、适用对象、排除情况。上面示例里我特意写凡涉及组件逻辑、状态管理、样式写法的审查请求都适用就是在扩大正确触发率。如果你还遇到误触发可以补一句类似单纯的代码格式化建议不属于此技能范围的排除说明。一个经验新手可以先从复刻你最近一个月重复做过的事情开始。比如你反复让Claude按某个格式输出周报那就写一个周报生成skill你反复让它按某个模板做竞品分析那就写一个调研skill。自己的需求就是最好的场景从真实重复劳动里提炼出来的技能命中率远高于凭空想象的通用能力。4.4 用superpowers自带流程辅助创作自己写skill时我的习惯是先别急着动笔。我会开一段新对话让Claude用brainstorming技能帮我梳理我每周都要做几类重复任务分别是A、B、C帮我设计一个技能结构应该包含什么。走完一轮脑暴之后再动手写SKILL.md思路会清晰很多。superpowers的价值在这里体现得很完整它不只是一个技能库更是一套生产技能的流水线。用现成的脑暴技能来设计新技能用现成的写作技能来优化新技能的措辞和结构整个过程环环相扣。这比你自己从零组织一份技能文档要高效得多。写完之后记得新开对话验证。准备一两个真实的代码片段或真实任务丢给它观察Claude是否主动加载了你的新技能、执行步骤是否符合预期。验证通过后你的自定义技能才算真正上线。5. 用熟之后才知道的细节与坑5.1 skill没被调用八成是description在拖后腿这是我踩过最深的坑。有段时间我写了一个周报生成skilldescription只写了生成周报。结果实战里只有当我明说生成周报四个字时才触发稍微换个说法我总结一下这周工作就完全失效。后来我把description改成了当用户要求总结本周工作进展、整理完成事项、输出工作汇报、或把本周记录整理成周报时使用也适用于周报相关的模板填充与格式整理。效果一下子不一样了。写description时多问自己一句如果用户换五种说法表达这个需求我的description能覆盖几种5.2 全局技能和项目级技能的优先级Claude的技能是分层存放的用户级目录下的技能对所有会话生效项目级目录下的技能只对该项目生效。如果同名技能两边都有实际加载时以项目级为准。这就引出一个协作里的坑团队成员各写了一套同名技能平时用项目级的没问题但一旦有人把项目级技能删了行为就会静默回退到用户级的旧版本排查起来非常费劲。我的处理方法是项目级技能只放需要团队统一执行的、少而精的几条个人习惯类技能一律放用户级避免互相覆盖。如果你发现某个技能的应用范围开始模糊宁可重命名也不要让两个同名技能长期并存。5.3 skill不是越多越好上下文有成本superpowers自带的技能已经有十几个再加上你自己写的很容易不知不觉堆到几十个。但我实测下来技能太多反而让Claude变得选择困难每次请求都要在更多候选里挑来挑去误触发的概率明显上升而且每个候选技能的描述都会占用一部分上下文窗口本质上是一种隐性损耗。我个人的建议是全局技能控制在十五个以内项目级控制在五个以内。定期用/skills命令盘点把长期用不到的先移到备份目录。少而精永远比多而全更稳。你沉淀技能是为了提效不是收集手办。另外提醒一句不要觉得某个技能偶尔没用就删判断标准应该是过去两周是否真实触发过。如果没触发先看是不是description写太窄而不是立刻否定整个技能。5.4 版本管理把skills当代码一样维护最后一个建议来自一次惨痛教训。我某次手滑改坏了一个用了很久的自定义技能当时没做备份只能靠记忆重写结果怎么都找不回原来那个手感。从那以后我把自己所有自定义技能收进了一个git仓库和普通代码一样提交、打tag、写commit信息。这样带来的好处很实际技能改了之后效果变差一条git log就能看到改动一条git revert就能回退换新电脑git clone一下原来的整套技能体系瞬间还原。superpowers本身是开源项目也是这么管理的你把自己的技能资产纳入同样的管理方式整套体系才具备可持续演进的能力。最后再说一点个人体会。用了superpowers之后我突然发现自己更愿意写文档了因为写skill的过程本质上是把脑子里的隐性经验显性化。工具早晚会迭代甚至会被新的工具取代但你沉淀下来的这套工作方法会一直跟着你走。这大概才是超能力真正值钱的地方。
阅读完成 · 觉得有帮助？
