很多人第一次听说 superpowers是在某个技术群里看到有人贴了一段对话AI 居然主动按步骤把一篇博客从大纲写到了终稿中间还自己扮演了苛刻编辑把初稿批得体无完肤。问用了什么神仙工具答曰“superpowers”。我当时的第一反应是这又是一个包装精美的提示词模板吧直到自己装完、跑通、用了三周之后才意识到它跟提示词模板完全不是一回事。这篇文章就围绕 superpowers 写清楚它是什么、解决了什么问题、怎么安装、自带哪些技能、底层怎么工作以及如何把你自己团队的工作流也沉淀成同样的技能。如果你已经在用 Claude Code或者正在被“每次都要重新教 AI 你的工作方式”这件事折磨这篇内容应该能帮上大忙。1. superpowers 到底是什么不是又一个插件而是一套 AI 技能体系1.1 一个容易混淆的定位问题先说结论superpowers 不是一个独立软件也不是那种“复制一段 prompt 到对话框就完事”的提示词合集。它是构建在 Claude Code 基础上的一整套技能框架和技能库项目发起人是 Jesse Vincent圈内更常叫他 obra。这个名字在硬件圈和开源圈都不陌生他做过键盘、写过 Perl这几年把大量精力投在了“如何让 AI 真正按人的工作方式干活”这件事上。superpowers 这个项目的核心主张很朴素模型能力再强如果每次开工都要从零教它一遍流程效率一定是低下的。真正拉开差距的不是模型本身而是你愿不愿意把那些重复出现过二十遍的工作方法沉淀成结构化的技能让 AI 下次直接按这套技能执行。这有点像老工程师会把常见的故障排查步骤写成 checklists新来的实习生照着做就不会出大错。superpowers 就是干这个的只不过它的载体是 AI 技能包。1.2 两层结构技能库与技能框架理解 superpowers最好把它拆成两层看。第一层是它内置的现成技能库。这个库里包含了一批面向真实任务的技能比如写博客、做深度研究、制定执行计划、审查代码、生成单元测试、规范 Git 操作等。每个技能都是一份结构化的指令文件告诉 AI 这个任务应该按什么步骤推进、中间要产出什么、最后交付什么格式。你不需要自己从零写这些流程装上之后直接调用就行。第二层是它定义的技能编写框架。这一点在我看来才是 superpowers 真正值钱的地方。它定义了一套如何组织技能文件的规则每个技能放在独立目录里入口文件叫 SKILL.md用 YAML 头信息声明技能的名称、描述、允许使用的工具正文部分写具体的执行流程和约束。这套规则本身是开放的你完全可以按照同样的规范写一个“我们团队的发布检查技能”然后丢给 AI 使用。简单来说内置技能是“赠品”技能框架才是“主菜”。很多人只注意到赠品忽略了主菜等于白用了这个项目。1.3 它和普通 prompt、MCP、插件有什么区别这里我经常被人问糊涂干脆把三者的区别说透。普通 prompt 是一次性的你今天告诉 AI“先写大纲、再写初稿、再自我审核”明天还得再说一遍。它可以写得很长很详细但每次都要重新喂给模型既浪费上下文又不稳定。MCPModel Context Protocol解决的是“AI 怎么连外部工具和数据”的问题比如连数据库、连浏览器、连企业内部系统。它管的是工具接入层不太关心“拿到数据之后按什么流程做分析、输出什么格式的报告”。插件Plugin是一个分发和安装单元解决的是“代码以什么单位打包、通过什么渠道发布升级”的问题。superpowers 本身就是一个以插件形式分发的技能集合。所以三者的关系是superpowers 通过插件机制分发内含的技能在运行时通过 Claude Code 的技能系统加载必要时技能内部再去调用各种 MCP 工具。它们不冲突甚至经常搭配使用。真正让 superpowers 区别于普通 prompt 的地方是它把“AI 的工作方法”模块化了有目录、有元数据、有加载机制而不是一段躺在聊天记录里的长文本。2. 环境准备与安装从零到跑通只需要十分钟2.1 需要提前备好的环境安装之前先确认三样东西Node.js、Claude Code、Anthropic 账号访问权限。Node.js 建议装 18 以上的 LTS 版本20 LTS 更好。因为 Claude Code 本身是一个基于 Node 的 CLI 工具运行环境不达标后面排查问题会很痛苦。检查方式很简单在终端跑一下node -v npm -v第二个是 Claude Code。如果你还没装用 npm 全局安装即可npm install -g anthropic-ai/claude-code claude --version安装完成后首次启动会引导你完成 API Key 或账号登录的配置这类设置按官方引导走一遍就行。如果你已经日常在用 Claude Code说明前置环境是好的直接进入下一步。2.2 安装方式一通过 Plugin Marketplace 安装推荐在 Claude Code 的会话界面里以/开头的命令是给 CLI 用的内建指令。安装 superpowers 走插件市场最省事直接在会话里输入/plugin marketplace add obra/superpowers-marketplace这条命令把 superpowers 的插件市场添加进你的 Claude Code。接着再执行/plugin install superpowerssuperpowers-marketplace安装完成后插件市场的机制会自动把 superpowers 的技能文件放到对应的插件目录里以后项目更新了也可以在插件管理界面里一键升级。这个方式的好处是干净、可追踪、升级方便推荐大多数人用。2.3 安装方式二手动 Clone 技能目录如果你习惯自己掌控代码或者想把技能文件改一改再本地测试直接 clone 仓库更透明。做法是把仓库拉下来放进 Claude Code 会扫描的技能目录。全局生效的目录通常是git clone https://github.com/obra/superpowers ~/.claude/skills/superpowers如果只想让某个项目生效就把仓库放到项目根目录下的.claude/skills/里。Claude Code 会同时扫描全局目录和项目目录项目目录的优先级更高这在后文讲避坑时还会提到。2.4 验证安装怎么确认技能真的加载了装完别急着用先验证一下。在 Claude Code 会话里输入/skills正常情况下会列出当前可用的全部技能里面应该能看到superpowers命名空间下的一堆技能名。也可以直接下一条指令试水比如superpowers/blog 帮我写一篇 800 字的短文主题是“团队代码评审怎么落地”。如果 AI 能识别出superpowers/blog并按照博客技能的工作流开始给你反馈大纲说明安装成功。如果提示找不到这个技能大概率是版本问题或者目录没被扫描到先去升级 Claude Code 到最新版再检查技能目录路径是否正确绝大多数问题都能在这两步里解决。安装本身确实很快五分钟到十分钟足够。真正需要花时间的是搞清楚这个技能库能干什么、什么时候该调哪个技能。这就是下一部分要聊的。3. 自带技能盘点这些 skills 分别解决什么问题3.1 我当前版本里看到的核心技能列表我装的是 2025 年春季的版本实际扫出来的技能大概有这么几类博客写作、深度研究、任务规划、代码审查、单元测试、Git 工作流、架构设计评审等。不同版本、不同时间点拉下来的仓库内容会有差异但主干方向基本稳定。下面这张表是我实测下来最容易用到的一批具体以你安装仓库的 README 和/skills列表为准。技能名解决的问题典型使用场景superpowers/blog把“写文章”这个模糊目标变成可执行的成熟流程写技术博客、公众号长文、内部文档superpowers/research围绕一个主题做多角度搜集、交叉验证并输出报告竞品分析、技术选型调研、行业扫描superpowers/plan把模糊目标拆解成带依赖关系的执行计划项目启动、季度目标拆解、产品方案规划superpowers/code-review按严重程度分级审查代码改动合入 PR/MR 之前的代码评审superpowers/test为指定模块生成单元测试并在失败时自动修复补测试覆盖、回归老模块superpowers/git-workflow规范化 Git 操作流程提交信息整理、分支合并、变更集管理superpowers/architecture对系统设计做结构化评审方案评审会之前的技术预审3.2 写作与研究类技能内容是重灾区先说说用频最高的写作类。superpowers/blog写长文是真的稳它内置的流程大致是先和你确认主题、目标读者和篇幅然后产出结构大纲等你确认后才开始写草稿写完还会进入自我审稿环节以苛刻编辑的角度挑毛病、删废话最后给修订稿。这个流程单独拿出去作为 prompt 已经很好用了难点在于你每次都要完整地把这套流程写清楚而这里只需要一个superpowers/blog。superpowers/research适合那种“信息又多又杂、你不知道从哪下手”的调研任务。比如让我做“React 状态管理方案在 2025 年的选型对比”它会把调研拆成多个子问题逐个展开最后整理成一份带来源标注和建议的对比报告。它比较强调区分“已核实的事实”和“基于信息的推断”这点我挺喜欢因为很多直接让 AI 写出来的调研报告会把猜测写得跟事实一样硬。3.3 工程与协作类技能把日常流程标准化代码相关的主要是三个superpowers/code-review、superpowers/test、superpowers/git-workflow。这套组合拳的场景非常清晰写完代码先用superpowers/test生成并跑测试再调用superpowers/code-review对改动做审查最后用superpowers/git-workflow整理提交信息并合入。代码审查的输出格式很统一按严重程度分类会导致线上故障的、存在安全隐患的、性能有明显隐患的、可读性和维护性问题各类下面再列文件、行号、问题描述和修改建议。这种结构化输出比你在对话里一句“帮我 review 一下代码”得到的零散反馈可靠得多。superpowers/plan则更偏开工前给它一个模糊目标它会拆出来阶段、依赖关系、验收标准和风险项现在已经是我的项目启动默认动作。4. 核心机制SKILL.md 如何被加载、触发与防上下文爆炸4.1 每个技能本质上是一个目录用惯了这个框架之后你会意识到 superpowers 的所有魔法都建立在一种文件约定上。在技能目录里每个技能是一个独立文件夹里面最重要的文件叫SKILL.md。这个文件分两部分开头是 YAML 格式的元信息声明技能叫什么、什么时候该用、允许调用哪些工具后面是 Markdown 正文写这个技能的执行流程、质量要求、注意事项。一个简化版的SKILL.md长这样--- name: release-checklist description: 在每次发布前执行发布检查核对文案、链接、版本号和合规红线。当用户要求“准备发布”或“发布前检查”时使用。 allowed-tools: [Read, Edit, Glob] --- # 发布检查技能 ## 适用时机 在用户准备发布任何对外内容或版本时使用。 ## 执行步骤 1. 读取待发布内容检查标题、正文和摘要是否完整。 2. 逐条核对链接是否包含死链、外链是否合规。 3. 确认版本号、日期和更新时间是否一致。 4. 输出检查清单标注每项通过或失败。这里的关键不是 Markdown 本身而是这个文件承担了三种职责向系统声明自己的能力、向模型提供执行时的完整指令、向人类维护者提供一目了然的技能文档。一个技能文件同时是运行描述、触发规则和使用说明书。4.2 渐进式披露为什么技能不会把上下文塞爆用过长 prompt 的都有经验把几个大任务的完整说明一股脑塞进系统提示里模型会变得迟钝因为上下文里塞满了当前用不到的信息而且越长的指令越容易让关键点被稀释。superpowers 没有这么做它靠的是渐进式披露progressive disclosure。机制是这样的Claude Code 启动时扫描所有技能文件但只把每个技能的name和description这两段短信息加载到系统提示里。模型的长期记忆里只有一张“技能索引卡”名字是什么、一句话描述它什么时候该被使用。真正的完整步骤在SKILL.md正文里系统不会提前加载。只有当模型觉得当前任务与某个技能匹配、或用户显式调用某个技能时它才去读取对应文件的完整内容把详细指令注入当前上下文。这个设计很像图书馆大厅里摆满索引卡告诉读者哪本书在哪个书架读者真去借阅时馆员才会把整本书搬过来。如果你把所有技能全文都放在大厅里书架早就塌了。正因为用了渐进式披露就算你装了四五十个技能每个技能只占一两行的系统提示预算完全可接受。4.3 前缀调用把触发主动权攥在自己手里技能触发有两条路径。一条是模型根据description自动判断该不该用比如你随口说一句“咱们准备发版了”模型可能就会自动去加载 release-checklist 技能。另一条是用户显式调用也就是superpowers/blog这种带命名空间的写法。为什么 superpowers 要设计前缀我的理解是它把触发主动权交回给了用户。自动触发虽然方便但模型判断不一定每次都准有时候你只是聊到某个话题并不是真的想执行整套流程有时候你确实想执行流程但模型没识别出来。前缀解决的就是这种不确定性你说调就调说的就是显式意图模型不会跟你讨价还价。同时命名空间还解决了技能名字冲突的问题两个不同作者的技能就算重名用different-namespace/name也能区分开。4.4 和子代理、上下文预算的配合光有渐进式披露还不够。一个技能展开之后如果正文写得又长又啰嗦上下文照样会爆掉。所以 superpowers 的技能设计普遍强调“够用就好”执行步骤尽量控制在核心流程内细节最多到子步骤不做过度展开。我之前见过有人把一个技能写到两万字结果加载之后模型连基本的对话都变迟钝了这就是没有控制上下文预算的反面教材。另外复杂技能内部通常会拆成多个里程碑以 checklists 的方式分段推进每完成一阶段就汇总一次结果而不是要求模型把整个长流程的所有中间状态都堆在上下文里。这种“边做边清”的设计思路和写长程序时要拆函数是一个道理。配合子代理subagent使用的话效果更明显可以让主会话只负责调度具体执行塞给独立上下文的子代理互不污染。5. 三个典型场景走一遍写博客、做研究、审代码5.1 场景一用 superpowers/blog 写完一篇技术博客我在跑通安装后的第一个实测就是让它写一篇“团队怎么落地代码评审”的技术博客。我给的指令很简单superpowers/blog 我想写一篇给工程师看的博客主题是“代码评审怎么坚持下来”。核心观点是评审不是检查错误而是知识共享。字数 1500 左右。它的第一步不是直接写正文而是先给了一份文章结构大纲问我是否调整。这个细节很重要因为很多写作任务的失败根源在于 AI 猜错了文章的骨架。确认大纲之后它才开始逐节写正文然后自行进入“苛刻编辑”状态对初稿进行挑刺开头太平淡、第二段的论据和案例混淆、结尾缺少行动建议。最后给出的修订稿比初稿瘦了一圈重点也确实更突出了。我后来复盘这个技能的价值不在于“它写得比我好”而在于它把“作者编辑读者”这三个角色的协作闭环打包进了同一个流程。你不需要自己反复切换角色去提要求它自己在内部就完成了。5.2 场景二用 superpowers/research 做技术选型调研第二个实测是让我印象最深的。当时我需要快速了解某个开源协议在商业化场景下的限制任务是superpowers/research 调研 MIT、Apache 2.0、GPL 3.0 在内部工具和 SaaS 产品中的使用差异输出选型建议。它没有直接给结论而是先列了一批需要回答的子问题包括许可证对分发的要求、对修改版本的约束、和商用产品的关系等然后逐个展开每个结论都尽量给出源文档来源。最后输出了一张三列对比表并附了一段“在什么场景下优先级怎么排”的建议。重要的是它很明确地把哪些是许可证原文直接支持的条款、哪些是基于常见法律解读的推断分开标注这让我拿去做决策时心里有数。这种“先拆问题、再查证、再给建议、最后明确区分事实和推断”的框架其实和做竞品分析、方案调研是同构的。换成任何需要信息收集和判断的领域这个技能都能复用。5.3 场景三用 superpowers/code-review 审查一个未合入 PR技术博客和调研报告都是文本类任务代码审查则更考验技能对上下文的组织能力。我拿手头一个还没合入的 PR 实测这个 PR 改了一个支付回调的服务端点涉及金额计算和异常处理。给它的指令是superpowers/code-review 请审查当前未合入的支付回调改动重点关注金额计算和边界条件。输出分成了几块最重要的一块指出了金额精度处理缺陷建议统一换算成最小单位后再运算次要的一块指出了回调接口存在重复通知未做幂等控制的隐患再往下是几条代码风格和可读性建议。每条都定位到了具体文件和行号并附了简短修改示例。特别提一句它甚至能判断哪些问题是这次改动引入的哪些是整个模块的历史遗留问题这比很多直接抓着一行代码就开喷的审查方式要专业得多。我用完后的感受是代码审查技能最大的价值不是替代人而是把审查结果的结构化程度拉高让负责人能按优先级快速处置。6. 造一个自己的 skill把团队规范变成可复用技能6.1 为什么你应该自己写技能内置技能再全也不可能覆盖你团队特有的流程。比如你们团队发版前要过安全检查、链接检查、文案调性检查这种规范 AI 不可能自己知道只有你把它写成技能AI 才会真正遵守。把团队规范沉淀成技能这件事本质上就是把你平时反复在评审会上强调的话变成 AI 每次都会自动执行的检查清单。6.2 一步步创建一个“发布检查”技能说了这么多直接动手做一个。假设我们要做一个发布检查技能防止每次发布时漏掉关键步骤。第一步在技能目录下新建一个文件夹。想在项目级生效就放在当前项目的.claude/skills/release-checklist/里想全局生效就放进~/.claude/skills/release-checklist/。第二步在里面创建SKILL.md写下 YAML 元信息和正文--- name: release-checklist description: 在每次发布前执行发布检查核对文案、链接、版本号和发布红线。当用户说“准备发布”“发布前检查”或“可以发了吗”时使用。 allowed-tools: [Read, Edit, Glob] --- # 发布检查技能 ## 适用时机 用户准备发布任何对外内容、版本或功能之前。 ## 执行步骤 1. 读取待发布内容检查标题、摘要和正文是否完整。 2. 检查所有内链和外链标记任何可能失效的链接。 3. 核对版本号、日期和上一版本差异。 4. 确认发布文案里没有绝对化表述和未经验证的数据。 5. 按“通过/失败/需确认”三档输出检查清单。第三步在技能目录里还可以放参考文件、模板、脚本。比如放一个templates/checklist.md让技能输出时可以引用这份模板保持团队既有文档格式。第四步测试。直接用真实发布场景触发它看它有没有按步骤执行输出格式是否符合预期再回头调整description的措辞。这里我会特别提醒一句description 是整个技能的灵魂它的作用不是给人类看而是让模型知道“这个技能什么时候该上场”。写得太宽该触发的时候不触发写得太窄很容易和别的技能重叠触发混乱。6.3 三个让技能更好用的编写原则我自己在实践中学到的心得总结成三条。一是用 checklists 而不是散文。模型对列表的执行忠实度远高于对大段散文的执行忠实度。步骤写成清单它能一步一步走步骤写成段落它就容易自由发挥。二是明确边界条件。好的技能不仅要写“什么时候用”还要写“什么时候不要用”。比如发布检查技能可以加一条“如果发布对象仅是内部测试环境则跳过文案检查”。这条红线能让 AI 不在错误的场景下套用流程。三是控制权限。allowed-tools里只列这个技能真正需要的工具。发布检查只需要读写文件就没必要给执行命令的权限。技能出问题的时候权限暴露面越小后果越可控。7. 三周实测的避坑心得7.1 坑一装完 /skills 列表找不到想要的东西这个坑我踩过两次。第一次是装了插件市场版本之后列表里只有超级技能名没有具体的 blog、research原因是当时的 Claude Code 版本太老对插件市场里的技能结构支持不完整。升级之后就好了。第二次是我自己手动 clone 到了项目目录但项目路径写错了放在.cli/skills而不是.claude/skills扫描不到。这个目录拼写很容易错留意一下。解决方法总结就是先升级到最新版再检查目录路径。7.2 坑二自动触发不够准老是不该用的时候跳出来渐进式披露的原意是让模型根据 description 自动判断但模型判断偶尔会过于积极。有段时间我在对话里只是随口说“这篇文章写得还行”它就触发了 blog 技能的完整写作流程开始给我列大纲场面一度很尴尬。后来我改用显式superpowers/blog调用的方式把自动触发的任务收敛到少数几个边界特别清晰的技能上。这里面的判断标准很现实技能流程越长、副作用越大越应该用显式调用别把控制权完全交给模型。7.3 坑三长任务连续跑上下文还是会爆渐进式披露解决的是“加载时”的上下文问题解决不了“运行时”的累积问题。我有一次在一个会话里连续跑了三个研究型技能每个技能都加载大量资料跑到后面明显感觉模型变“钝”了回答开始丢三落四。后来我的做法是把大任务拆开每个技能单独开会话跑或者利用子代理把具体执行放在独立上下文里。另外研究类技能输出结果后尽快让它把关键结论整理到本地文件既方便复用也减少上下文里的长期占用。7.4 坑四多个技能 descriptions 互相重叠触发串味装了团队内部的技能之后很快就发现和内置技能的 description 有重叠。比如我们团队的“发布检查”和外部的某个写作技能在“检查文案”这一点上就撞了。解决办法有两个一是把重复的部分挪到内置技能覆盖不到的地方让每个技能只保留自己的独特职责二是在内部技能的 description 里加一句“仅用于内部发布流程不用于通用内容写作”人为划清边界。技能少的时候感觉不到技能一多description 就是你的索引系统索引混乱整个库就废了。7.5 我的真实体会被改变的是工作习惯最后说点个人感受。用了三周之后我发现自己最大的变化不是“会调用一堆技能”而是开始习惯性地把每件重复做的事问一遍能不能把这件事写成一个技能再往前走一步团队里那些最有经验的工程师脑子里的 checklists如果能沉淀成技能新人上手的速度会快很多评审争论的起点也会高很多。superpowers 给我的启发就是AI 真正省力的地方不是替你做决策而是把你认为理所当然、但每次都要重新交代一遍的做事方式变成它骨子里的习惯。这个方向比多装几十个插件有价值得多。