我做AI编程工具也有两三年了,Claude Code、Cursor、继续涌现的各类Agent框架都折腾过不少。说实话,工具越来越强,但真正让我觉得“队友上了一个档次”的,反而是最近装上的这套叫superpowers的开源技能包。它不是一个简单的prompt模板,也不是一条命令搞定某个功能的脚本,而是一整套让AI按专业工作流干活的“技能体系”。这篇文章我不打算念README,而是把我从安装、拆解技能清单、到自定义skill、再到实际跑通完整流程的整个过程,连坑带经验一起写出来。想直接上手的,照着做就行。
1. superpowers是什么?先把它和普通prompt插件分清楚
1.1 它本质上是给Claude Code装“职业技能包”
superpowers这套东西,核心载体是一堆目录化的“skill”。每个skill就是一个文件夹,里面有一个SKILL.md文件,用结构化方式写清楚这个技能的适用场景、触发条件、执行步骤和输出要求。当你在Claude Code里使用它时,AI会读取这些说明,在合适的时候自动加载对应的技能,然后按设定好的流程干活。
这和普通prompt的区别非常明显。普通prompt就是把一段话复制到对话框里,告诉AI“你要怎么怎么干”,但这段提示词离开当前会话就失效了,而且不同场景下你总要重新组织语言。superpowers则把经验固化成了文件,AI遇到对应场景会自动翻出来用,不用你每次重复口诀。你可以把它理解为“给AI上的职业培训课”,上完课它就知道接到任务后该按什么顺序、用什么方法完成。
我第一次用的时候最直观的感受是:AI不再像个只会接话的聊天机器人,而更像一个拿到需求后会先思考、再列计划、然后逐步执行的技术同事。它会主动说“我先梳理一下需求,然后给出几个方案”,而不是直接甩出一段代码让你自己判断对不对。
1.2 为什么值得关注:它把AI从“回答问题”变成“完成工作”
普通AI编程工具场景里,最常见的痛点是什么?是AI答得都对,但活儿干不到底。你让它改bug,它给你一段修改建议,你自己去改;你让它写功能,它生成几百行代码,但没测试、没文档、没提交。superpowers试图解决的,正是这个“从建议到交付”之间的巨大鸿沟。
它通过一组相互串联的skills,给AI建立了一条完整的工作链路。比如任务来了,先搞清楚目标,然后头脑风暴、拆解计划、编写任务清单,再进入编码、测试、调试,最后整理文档发布成果。整个过程是环环相扣的。每一个环节都有对应的技能文件告诉AI:“这个阶段你的角色是什么、必须产出什么、用什么标准验收”。
所以网上那些关于superpowers的热搜,像“有哪些skills”“怎么引入这些技能”“想要安装superpowers”,本质都是同一个诉求:大家发现只靠聊天式prompt已经不够用了,想把AI训练成一个真正能顶岗的开发者。superpowers正好提供了这个框架。
2. superpowers安装教程:4种方式把技能引入你的工作环境
2.1 前置条件:你至少得有一款支持skill机制的AI编程工具
superpowers本身不挑平台,但目前最成熟的场景是Claude Code。如果你用的工具支持.claude/skills/目录或者兼容Anthropic的skill规范,那也能直接复用。安装之前,先确认你的Claude Code版本够新,最好用最新版,因为skill加载机制一直在迭代,老版本可能会出现技能读取不到的情况。
我用的环境是macOS + Claude Code 2.x版本,整个过程大概五分钟。Windows环境要注意路径分隔符和终端权限问题,建议用PowerShell以管理员身份执行部分命令。Linux上一般没有额外障碍,但如果你是通过SSH远程操作的服务器,记得先确认~/.claude目录是否存在,没有就手动创建。
在动手安装前,还有一件重要的事:备份你的Claude配置目录。路径一般是~/.claude,里面有你的设置文件和已装插件。虽然superpowers安装过程不强制覆盖,但后续你自己添加自定义skill时,改文件是难免的,提前备份一下,出问题能快速回滚。
2.2 安装步骤:插件市场、Git克隆、手动复制都行
先说最快的方式:通过Claude Code的插件市场安装。在会话里输入下面两行命令:
/plugin marketplace add obra/superpowers /plugin install superpowers@superpowers插件市场方式的好处是以后更新方便,作者发新版本后,你在工具里直接走插件更新流程就行。我推荐大多数用户用这个方式,省事,也不会弄乱目录结构。
第二种方式是Git克隆,适合你想深度定制、或者直接看源码的人。
git clone https://github.com/obra/superpowers.git cd superpowers克隆下来后,你会看到里面有一个skills目录,这个目录里每一个子文件夹都是一个独立的skill。接下来要做的是把它接入你的Claude Code环境。你可以把这整个skills目录复制到你的项目级目录.claude/skills/,或者放到用户级目录~/.claude/skills/。项目级目录只对当前项目生效,用户级目录会对所有项目生效。我个人的习惯是用户级放一份常用技能,项目级放需要和团队共享的定制技能。
第三种方式更保守一点,直接手动复制配置文件。如果你不想大规模改动目录,可以只挑几个你需要的skill复制过去。比如你只想要测试驱动开发和调试技能,那就只复制skills/test-driven-development和skills/debugging这两个文件夹。这种方式的缺点是后续更新麻烦,容易漏掉依赖项,所以我只在验证单个技能的时候用。
安装完之后,重新打开Claude Code会话,让它识别新技能。如果一切正常,你在对话里提到相关场景时,AI会主动加载对应技能。想确认它有没有加载成功,可以直接问它:“你现在有哪些可用的skills?”或者“能不能介绍一下你的技能列表?”。
2.3 验证是否生效:有个简单的判断方法
不需要很复杂的检测,你只需要新建一个会话,输入一个和某个技能强相关的小任务。比如你装了test-driven-development技能,就让AI“用测试驱动的方式写一个判断闰年的函数”。如果它回复的时候主动提到“按照TDD流程,先写测试再写实现”,那说明技能已经加载了。
如果它没有反应,别急着判定安装失败。先检查几个位置:技能目录是否放对了、SKILL.md的frontmatter格式是否完整、Claude Code版本是否支持。我遇到过一种情况,技能目录放到了.claude/skills但名字拼错了一个字母,AI根本扫不到。另外,有些版本的Claude Code要求技能目录必须直接放在skills下,不能多套一层别的目录,这个细节特别容易踩坑。
3. superpowers有哪些skills?我整理了一份核心技能清单
3.1 技能命名与组织逻辑:先理解它为什么这么设计
superpowers里的技能命名非常直白,基本都是“动词+对象”的结构,比如brainstorming是头脑风暴,writing-plans是写计划,test-driven-development是测试驱动开发,debugging是调试。这种命名的好处是,AI在读取技能描述时能快速匹配任务场景,你作为使用者也一眼能看出每个技能的用途。
除了命名,技能之间还有依赖关系。比如creating-skills这个技能,它的作用是教AI如何创建新的skill,而它本身会依赖reading-templates或者writing-markdown这类基础技能。设计者希望技能之间可以互相调用,形成组合拳。这个思路很聪明,相当于让AI具备了“自我进化”的能力:遇到新任务时,它可以先拆解任务,然后组合已有技能,实在不行就创建新技能。
我在实际使用中注意到,它内部有几个核心的“流程类”技能,比如brainstorming、writing-plans、creating-tasks、engineering-task,这些技能组合起来就是一条完整的项目开发流水线。AI会先和你头脑风暴确认需求,再输出计划文档,然后把计划拆成一个个任务,最后进入执行阶段。这套流程几乎覆盖了从0到1做一个功能的完整闭环。
3.2 典型技能逐项拆解:每个技能解决什么问题
下面列几个我用得最多、也最有代表性的技能,说说它们具体是干什么的。
brainstorming(头脑风暴):这个技能让AI在动手写代码之前,先和你做多轮方案探讨。它会主动提出几个候选方案,分析各自的优缺点,还会结合上下文给出推荐。我经常在需求模糊的时候触发它,效果比直接说“帮我写个功能”好太多。
writing-plans(编写计划):当任务比较大、涉及多文件修改时,AI会用这个技能把任务拆解成步骤,写明每步要改哪些文件、预期产出是什么,最后生成一份计划文档。你确认后它才进入编码环节。这个技能是避免AI“东一榔头西一棒子”的关键。
test-driven-development(测试驱动开发):这个技能强制AI按照“先写测试、再写实现、再重构”的顺序来写代码。它会在动手前先列出测试用例,再开始写业务逻辑。对于追求代码质量的人,这个技能基本是必装的。
debugging(调试):这个技能要求AI按“复现问题—定位原因—最小修改—验证修复”的流程排查bug,而不是上来就瞎猜乱试。它还特别强调每次只改一个变量,改完必须验证。
reading-code(阅读代码):在改动陌生代码之前,AI会先通读相关文件,输出一份理解笔记,包括模块职责、关键调用链、潜在风险点。它能有效避免AI在不理解代码的情况下乱改出错。
autonomous-command-execution(自主命令执行):这个技能约束AI执行终端命令时的行为。它会让AI在执行危险命令或不确定的操作之前,先向你确认,避免它在服务器上乱跑命令。
launching-new-projects(启动新项目):新建项目时,AI会按规范帮你搭好目录结构、初始化Git、创建基础配置文件。省去你重复手工搭建骨架的时间。
publishing-work(发布成果):把完成的代码、方案整理成可发布的文档或文章。我经常用它来把一次完整的开发过程整理成博客初稿,效率非常高。
除了上面这些,还有security-audit(安全审查)、navigating-codebases(代码库导航)、writing-markdown(写Markdown文档)、creating-skills(创建新技能)等等。我在下表里整理了一份更全的清单和适用场景,方便你对照选择。
| 技能名 | 核心作用 | 触发场景 |
|---|---|---|
| brainstorming | 多轮方案探讨,输出候选方案和推荐 | 需求模糊、方案选型 |
| writing-plans | 把大任务拆解成可执行计划并输出文档 | 多文件改造、复杂功能开发 |
| creating-tasks | 将计划细化为具体任务清单 | 进入编码前 |
| test-driven-development | 先测试后实现再重构 | 任何业务代码开发 |
| debugging | 按流程复现、定位、修复bug | 排查线上/本地问题 |
| reading-code | 阅读并理解现有代码后输出笔记 | 接手陌生项目、改动旧代码 |
| navigating-codebases | 快速定位代码库中的关键文件 | 大型仓库搜索 |
| autonomous-command-execution | 约束终端命令执行的节奏 | 涉及命令行操作的场景 |
| launching-new-projects | 初始化新项目结构和配置 | 新项目开工 |
| publishing-work | 把成果整理成可发布内容 | 写技术文章、项目总结 |
| security-audit | 审查代码和配置中的安全隐患 | 发布前安全检查 |
| creating-skills | 指导AI创建新的自定义技能 | 需要沉淀新经验时 |
3.3 怎么挑选适合你的技能组合
不是所有技能你都要装上。技能越多,AI在匹配时越容易犹豫,反而拖慢响应。我的建议是:先按你的工作类型选定核心技能,再逐步扩展。如果你是写业务代码的,必装test-driven-development、debugging、brainstorming;如果你是做项目启动和架构的,必装launching-new-projects和writing-plans;如果你经常要写文档、做知识整理,writing-markdown和publishing-work会很有用。
装完之后也不要一直不清理。用上一段时间,回顾一下哪些技能你真的高频使用,哪些几乎没触发过。对于几乎没用的技能,直接删掉或者移到备用目录。技能不在多,关键是每一条都能在需要的时候精准出现。
4. superpowers具体怎么用:从被动问答到主动工作流
4.1 触发方式:自动加载和手动唤醒两种
superpowers的使用方式和我一开始想的不太一样。它不是那种你在对话框里输入/use test-driven-development就立刻切换模式的工具(虽然某些版本支持类似命令),更多时候是“AI自己判断该用哪个技能”。
什么意思呢?每个SKILL.md文件的frontmatter里有一段description,里面写明“在什么情况下使用这个技能”。Claude Code启动后会扫描所有技能,当你的对话内容命中某条描述的语境时,它就会自动加载对应的技能文件,把完整的操作指令注入到上下文中。这个机制有点像浏览器的自动补全:你不用手动开启,输入进浏览器地址栏后,它自动给你匹配关键词。
手动唤醒的方式也有,就是在描述任务时明确说出技能名。比如“请用debugging技能帮我定位这个bug”。这种方式适合你很清楚要调哪个技能的时候。我实测下来,自动加载和主动指定混合使用效率最高:大方向由你自己把握,具体流程细节交给AI按技能执行。
4.2 工作流编排:多个技能如何串成一条线
真正体现superpowers价值的地方,是多技能串联。我举一个实际例子:上次我需要给一个旧项目新增一个支付接口。我没有直接说“写代码”,而是在对话里描述了需求。AI首先加载了brainstorming技能,和我确认接口字段、异常处理方式,给了两套方案。我选了其中一套后,它又加载了writing-plans,把任务拆成“定义接口契约、编写数据模型、实现业务流程、补充单元测试、更新文档”五个步骤。然后它进入编码阶段,自动加载test-driven-development,先写测试用例再实现逻辑。中途有一个测试总过不去,它主动加载debugging技能,没有乱改代码,而是先打印日志、定位参数校验问题,最后只改了一处地方,测试就通过了。
整个过程我几乎没有催它,它自己按流程走完。这和我以前用AI编程的感觉完全不同。以前是我一步一步告诉它“现在做什么、下一步做什么”,现在是它有一套内置的项目管理逻辑,我只是需求方和最终验收人。那种“AI真的在干活”的实感非常强。
这段体验让我理解了一个关键点:superpowers本质上是在规范化AI的工作习惯。它不像单个prompt那样只改变一次回答,而是建立了持续的行为模式。AI一旦进入这套模式,回答问题的质量会稳定很多,不会时好时坏。
4.3 让技能更稳定:上下文清理和角色设定
技能虽然好用,但也依赖一个干净的上下文。我建议在一个比较大的项目中,每隔一段时间开启新会话,并让AI手动加载项目根目录里的记忆文件或计划文档,而不是让旧会话无限拉长。上下文太长之后,技能加载的指令权重会被淹没,AI容易淡忘核心约束。
另外,你可以在Claude Code里给AI设定一个“主角色”,比如“资深全栈开发工程师”,让它在执行任何技能之前先意识到自己的角色。配合superpowers的流程约束,输出质量会更稳。我在配置文件里加了一段角色描述,实测下来AI在涉及技术选型时会更谨慎,给出的理由也更具体。
5. 手把手教你写自己的skill:从模板到落地
5.1 一个skill就是一个目录,核心是SKILL.md
superpowers最有吸引力的地方,是你可以自己创建技能,把日常重复的工作流固化下来。我一开始也觉得写技能是高难度操作,真正动手后发现,只要你理解它的文件结构,这件事门槛并不高。
一个技能的基本结构长这样:
skills/ └── my-skill/ ├── SKILL.md ├── reference/ │ └── examples.md └── scripts/ └── validate.pySKILL.md是这个技能的灵魂,里面用YAML格式写元信息,用Markdown写操作指令。reference目录放参考资料,scripts目录放可执行脚本。AI加载技能时,首先读SKILL.md,根据指令需要再决定是否读取其他文件。
下面是我自己创建的一个“代码审查”技能的SKILL.md模板,你可以直接参考:
--- name: code-review description: 在提交代码或合并请求前,对代码进行系统审查,发现潜在问题并给出修改建议。 when_to_use: 当用户要求审查代码、检查代码质量、准备提交合并请求时,自动使用该技能。 depends_on: - reading-code --- # 代码审查技能 ## 目标 在进入审查前,先理解代码的整体结构,再逐项检查。 ## 执行步骤 1. 使用 reading-code 技能理解待审查代码的功能与调用关系。 2. 检查代码是否符合项目既定风格,是否存在明显的反模式。 3. 从可读性、性能、安全性、可测试性四个维度给出审查意见。 4. 对每个问题标注严重程度:必须修改、建议修改、可选优化。 5. 输出一份审查报告,包含问题清单、修改建议和优先级排序。 ## 输出格式 使用 Markdown 表格列出问题、位置、严重程度和修改建议。我把这个文件放进skills/code-review目录后,重新加载Claude Code,然后在对话里随便贴了一段代码,说“帮我审查这段代码有什么问题”。AI很快就按我设定的步骤输出了一份带严重级别和修改建议的审查报告,格式完全符合我的要求。
5.2 写instructions的要点:越具体,AI执行越稳
写SKILL.md正文的时候,最关键的是把步骤写具体、写可操作。不要只写“审查代码的质量”,而要写清楚“先看什么、再看什么、最后输出什么格式”。AI对含糊描述的响应远不如对明确步骤的响应。
我的经验是,每一步都要包含两个要素:做什么,以及做到什么标准。比如“检查代码是否存在未处理的异常,如果发现,标注文件路径和行号”,比“检查代码可靠性”要好用得多。另外,尽量给AI一个输出模板,它可以照着填,而不是自由发挥。自由发挥的时候,AI偶尔会漏掉关键项。
还有一个容易忽略的点:技能之间的依赖关系。如果你创建的技能需要用到已有技能,在frontmatter里通过depends_on字段声明。AI加载当前技能时,会注意到它依赖的其他技能,在需要时自动加载。这个机制能避免一个技能里塞太多内容导致上下文爆炸。
5.3 绑定触发器与测试:让技能在正确时机自动出现
写完技能后,你可能还会遇到一个尴尬问题:AI就是不自动加载它。原因多半是description写得不好。description是AI判断“什么时候用这个技能”的唯一依据,它要足够具体、覆盖面合适,最好包含触发场景的关键词。
比如你写“代码审查”,但描述里只有“审查代码质量”,那AI在读代码但没提“审查”这个词的时候,可能就不触发。你可以改成“当用户要求审查代码、检查代码质量、准备提交合并请求、或者提供一段代码询问有没有问题时使用”。描述越贴近实际对话,触发率越高。
创建完技能后,我建议用一个真实小任务做验证。如果没触发,回到description里补充更多触发词。如果触发了但执行结果不合预期,调整正文步骤。这是一个不断打磨的过程,本质上和训练人一样,反馈越具体,表现越稳定。
6. superpowers常见问题排查与避坑经验
6.1 安装后技能完全没生效,问题通常出在目录路径
我遇到最多的求助信息就是“装好了,但AI完全不搭理”。排查路径其实很固定,先检查目录。技能目录必须放在.claude/skills/下,不能多套一层superpowers/skills。有些用户克隆仓库后,直接把整个仓库文件夹复制进skills目录,变成了.claude/skills/superpowers/skills/xxx,这种结构是扫描不到的。
还要注意,Claude Code在不同平台对大小写敏感程度不同。Linux和macOS默认大小写敏感,目录名用Test-Driven-Development还是test-driven-development必须一致。Windows上虽然不敏感,但也不建议混用大小写,保持规范能减少后续维护成本。
另外,修改技能文件后,旧会话不会自动重新加载,这也是很多人“改了没反应”的原因。更新技能后,记得开一个新会话再测试。
6.2 技能加载了但是行为不符合预期,多半是依赖缺失
有些技能执行到一半会突然中断,或者明显没有按流程走。我遇到过几次,发现原因是依赖的技能没有安装。比如creating-skills这个技能,它依赖reading-templates来读取模板文件,如果依赖缺失,它就会跳过关键步骤。
解决方法是,每次安装一个技能前,先看它的depends_on字段,把依赖一并安装。手动复制技能目录时,尤其容易漏掉这一步。另外,技能里的脚本如果依赖外部Python包或者Node模块,也需要单独安装。这类问题在报错时往往不明显,AI可能只会说“执行失败”或者“缺少某段指令”。
6.3 技能冲突:多个技能同时匹配怎么办
当对话内容同时命中多个技能的描述时,AI会选择加载一个或按顺序加载多个。这会导致流程交叉,行为变得不可预测。我遇到过debugging和test-driven-development同时激活的情况,AI一边按TDD流程写测试,一边又跳出去做问题复现,场面有点混乱。
遇到这种情况,我的做法是主动干预:明确告诉AI“当前阶段只使用哪个技能”。比如“先不要管测试流程,先帮我定位这个bug的原因”。高素质的AI会立刻调整,只保留指定技能的指令。如果你发现某个技能经常被误触,也可以修改它的description,缩小适用范围,减少和其他技能的语义重叠。
6.4 我的几条避坑经验
用superpowers这段时间,有几个心得体会值得单独说一下。
第一,不要一次性装太多技能。技能数量多之后,AI在匹配阶段会花更多时间,响应速度会变慢。我现在用户级目录大概保留了十个左右核心技能,足够覆盖绝大多数任务。
第二,定期更新。superpowers迭代很快,技能格式几乎每个月都在微调。旧格式的技能在新版本里可能无法正常加载,最好的办法是关注仓库动态,隔段时间执行一次插件市场更新。
第三,把自定义技能独立保存。我自己创建的技能都放在一个单独目录里备份,比如~/Documents/my-ai-skills/,这样即使Claude Code配置被重置,我也能快速恢复。毕竟手写的技能带有个人经验,丢了再写一遍成本很高。
7. 结束语:把它当队友培养,而不是当工具使唤
如果只看安装命令和技能列表,superpowers似乎只是一个配置包而已。但我实际用下来,最大的感触是它改变了我和AI协作的方式。以前我把AI当成一个随时可以提问的搜索引擎,现在我是把一套工作方法完全托付给它,让它按照我认可的标准去完成任务。
所以如果你刚接触这套东西,我的建议是别急着把全部技能都装上。你先装两三个最常用的,跑通一次完整的工作流,感受一下“AI主动按节奏干活”是什么体验。然后你再决定要不要深入定制。技能是死的,但工作流是活的,真正值钱的是你愿意花时间去定义标准、打磨流程这件事本身。这套工具的价值,最终会体现在你自己想明白“AI该怎么干活”这个问题的过程里。