最近被一个叫 superpowers 的项目勾起了兴趣。起初我以为又是某个开发者搞出来的新框架直到自己装完、跑通、把几个技能真正用进日常开发才发现它解决的其实是一个特别实际的问题AI 助手能力再强如果没有一套清晰的工作方法做起具体任务来还是会随性发挥。Superpowers 的做法很朴素——把专业领域的方法论拆成一个个可复用的 Skill用 Markdown 文件写清楚目标、边界、步骤和质量标准。AI 在执行任务时读到这些 Skill就像有个老师傅在旁边按步骤指导它干活。我之所以想把它整理成一篇笔记是因为这玩意儿第一次用的时候确实有点门槛。光看仓库说明你只知道它叫超级能力但不知道它到底能干什么、装好之后怎么让 AI 调用、里面那些 Skills 之间有什么区别。这篇文章我打算从一个真实使用者的角度把安装过程、Skills 清单、调用方式、以及我自己写 Skill 的经验都过一遍。无论你是想在 Claude Code 这类终端 AI 工具里提升生产力还是单纯好奇给 AI 装上技能这件事怎么落地这篇都能给你一个能直接上手的路径。1. Superpowers 到底是什么它不是插件是 AI 的技能操作系统1.1 为什么叫超级能力先聊个直觉。我们平时用 ChatGPT、Claude 这类 AI多少都会遇到一种情况它什么都能聊但你要让它规规矩矩做一件事比如帮我写一个符合项目规范的单元测试它可能会写可写出来的东西要么风格不对要么漏掉了边界条件。问题出在哪儿出在知识和能力之间缺了一层东西——方法论。Superpowers 补的正是这一层。它把某个领域的专家做法比如怎么拆解复杂问题、怎么审查代码、怎么设计系统写成结构化的 Skill 文件。每个 Skill 不是简单的提示词它包含触发条件、执行流程、质量标准、输入输出格式。AI 在运行到这个 skill 的时候会像切换了工作模式一样不再自由发挥而是按这套方法论来。我试过一个最直观的例子让 AI 分析一个需求时如果直接问它会给你一堆通用建议但如果它先调用设计思维这个 Skill它会先帮你澄清用户、问题、约束再逐步收敛方案。结果完全不一样。所以 Superpowers 的超级能力本质上是把隐性的人类工作经验变成了 AI 可以按需加载的显式技能。1.2 它和插件、Prompt 模板的区别很多人会问这不就是插件吗不完全是。插件通常是从外部给 AI 工具加功能比如接入某个数据库、增加一个代码解释器。而 Superpowers 的 Skill 不直接改工具本身它改的是 AI 的处理逻辑。它更像是一套 SOP标准作业程序告诉 AI 遇到某类任务时应该怎么思考、怎么安排步骤、怎么输出结果。那它和普通 Prompt 模板的区别又在哪里普通 Prompt 是一段一次性的话你复制进去AI 按这段话执行作用是瞬时的。Skill 则是放在项目里的一个文件AI 会在合适的时机自动读取或者由你主动指定。它带有身份定义、触发条件和检查清单AI 在执行过程中还会自查相当于把一个经验丰富的老手拆成了可复用的文档。所以我的理解是插件是给 AI 换工具Prompt 是给 AI 递纸条Skill 是给 AI 做培训。Superpowers 这个项目的核心价值是建立了一套标准化的培训教材体系让 AI 能稳定地表现出专家的水准。2. 安装 Superpowers从零到能调用的完整流程2.1 环境准备先确认你的终端 AI 用的什么内核Superpowers 的 Skills 机制目前最成熟的载体是终端类 AI 编程工具尤其是 Claude Code。安装之前先确认几个基础条件终端 AI 工具已装好并且能正常对话。本机有 Git因为 Skills 文件需要从仓库拉取。知道项目的CLAUDE.md或者对应的配置文件放在哪。这个文件通常放在项目根目录AI 会把它作为项目的长期记忆。如果你用的是别的支持 Skill 机制的 AI 工具原理一样只是配置文件路径和加载命令可能略有不同。我的建议是第一步先别想着一步到位先用一个空项目验证能不能跑通再去现有项目里引入。2.2 拉取与加载具体操作步骤安装 Superpowers 通常不是下载一个 exe那种思路而是把 Skills 文件放到你的 AI 工具能读取的目录里。以 Claude Code 为例常见流程是在项目根目录下建一个.claude/文件夹如果还没有的话。用 Git 把 Superpowers 仓库克隆到某个本地目录比如~/.superpowers。将仓库里的skills/目录复制或软链到项目的.claude/skills/下。修改项目的CLAUDE.md告诉 AI项目里有一批技能文件在.claude/skills/下遇到相关任务时主动读取并遵循对应 Skill 的指导。如果你看到某个安装命令可以一键完成通常也是在做上面这几件事的自动化。我建议动手做一遍因为只有理解了文件放哪后面调试才知道去找谁。有个细节比较容易忽略很多仓库里的 Skill 文件不是直接放在skills根目录下的而是按类别分了子目录比如skills/Think/、skills/Engineering/。Claude Code 默认会递归扫描这些子目录但有些工具不会所以装完后第一件事就是确认 AI 能不能看见全部技能。2.3 验证安装怎么知道它已经生效装完别急着开工先做一个快速验证。最简单粗暴的办法是直接问 AI你支持哪些 skill如果你是 Superpowers 用户请把你当前可用的技能列出来。如果 AI 能给出一个列表说明配置文件生效了。如果它答非所问大概率是CLAUDE.md里的引导写得不够直白。这时我会再补一句请先读取.claude/skills/目录下所有文件然后总结每个 skill 的功能。这一步很关键。因为 AI 只有在上下文里真实读到过这些文件后面才会调用。有些安装失败不是文件放错了而是 AI 压根不知道有这堆文件存在。你可以在CLAUDE.md里写清楚在开始任何任务之前扫描 skills 目录并选择匹配的 skill这样就能避免技能在手却不会用的尴尬。3. 内置 Skills 大盘点拿到手先该试哪几个Superpowers 仓库内置的 Skills 数量不少我按自己用下来的感受分成三类每类挑几个有代表性的这样你拿到手之后不至于迷路。3.1 思维类技能设计思维与系统思维第一个值得优先尝试的是 Design Thinking设计思维。这个 Skill 会强制 AI 在动手之前先围绕用户是谁要解决什么问题约束是什么展开一轮结构化提问。举个例子我让它帮我规划一个博客系统的功能它没有直接列功能列表而是先模拟了三种不同身份的角色分析他们各自的核心诉求最后再回到系统设计上。这个流程会让你意识到平时我们太急着要答案反而忽略了最前置的问题定义。另一个是 System Thinking系统思维。这个 Skill 主要用于处理边界模糊、因素多、相互关联的问题。它会让 AI 列出影响系统的关键变量、因果关系、潜在反馈循环最后再给干预点建议。我第一次用它分析一个架构升级方案时AI 突然变得像一个资深架构师不是简单给方案而是先画了一张影响链路图当然是文字描述的指出数据库写入瓶颈很可能不在 SQL 本身而在调用链上的缓存过期策略。这种视角靠普通 Prompt 很难稳定出现。这两个技能合用效果很好Design Thinking 解决做不做、做什么的问题System Thinking 解决怎么做、先动哪里的问题。3.2 工程类技能代码审查与测试生成代码相关是我用得最频繁的领域。Superpowers 里有个 Code Review代码审查Skill它不是你让它Review 这段代码它就给反馈那种而是有一套完整的检查清单可读性、边界条件、性能隐患、安全风险、依赖合理性、测试覆盖。AI 会逐项排查并给出严重程度标记。我用它审过一段刚写完的接口代码还真抓出了一处并发场景下可能出现的数据竞争——这要放在平时我可能得等测试环节才能发现。还有 Unit Test Generation单元测试生成这类 Skill。它的特色是不会无脑生成 20 条重复用例而是先分析代码分支、边界、异常路径再挑选最优覆盖集合。而且它会把测试设计和实现分开先给出测试计划让你确认再生成代码。这个先计划后执行的习惯很值得学习。3.3 写作与解释类技能不要以为 Superpowers 只服务程序员写作和解释类的 Skill 对日常办公同样有用。比如 Explain Like Im Five面向新手解释复杂概念AI 会主动切换比喻和分层讲解策略。我有一次让它解释进程与线程的区别它用厨房、厨师、菜谱做类比同时保留了一小段面向工程师的精确术语效果比我自己写强不少。还有 Requirements Clarification需求澄清这类 Skill它在收到一个模糊需求时会先输出一份需求澄清清单包括目标、用户、验收标准、排期约束、风险假设。我在项目启动会上试过一次直接把需求讨论从各说各话拉到了逐项对齐的节奏。这个技能后面我会在自定义部分再展开因为它非常适合扩展成你自己的日常工具。4. 怎么把 Skill 引入实际工作流4.1 触发方式自动触发与手动唤起安装完成后最关心的问题就是怎么让它干活。Superpowers 的 Skill 有两种触发方式。第一种是自动触发。靠的是 Skill 文件里定义的trigger字段比如某个技能设置了当用户请求包含代码审查四个字时自动激活。这种方式适合高频、标准化的任务能减少你的显式指令成本。但缺点是如果触发词设置得太宽泛AI 容易误激活。这时你会看到它突然开始按某个流程走了反而显得笨拙。所以我在实际使用中更习惯用第二种方式。第二种是手动唤起。在对话里明确指定比如请使用 Code Review Skill 处理这段代码。这相当于你主动按下某个工具的开关。默认场景下我建议先手动唤起几次确认 AI 的行为符合预期后再考虑把某些高频场景改成自动触发。还有一个小技巧Superpowers 允许在同一段对话里叠加多个 Skill。比如我先用 Requirements Clarification 澄清需求再用 Design Thinking 确定方案最后用 Code Review 检查落地代码。AI 会依次执行不会混乱。4.2 多技能串联处理一个复杂需求的标准姿势单技能调用很简单但要让它们发挥最大价值学会串联才是关键。我一般遵循这个流程拿到需求先手动唤起 Requirements Clarification让 AI 把需求边界、验收标准、隐含假设问清楚。需求明确后调用 Design Thinking 或 System Thinking对解决方案做发散和收敛。确定技术方案进入编码阶段让 AI 按项目内约定写代码。写完代码自动或手动触发 Code Review让 AI 按检查清单自查。最后调用测试生成技能补上关键测试用例。这套流程跑下来你会感觉 AI 不是一个问答机器人而是一个有章法的协作者。它输出的每个阶段产物都可以作为下一步输入整个链路是顺滑的。新手容易犯的错是只把 Skill 当一个格式化输出器却忽略了前后顺序。技能和技能之间是有依赖关系的先用哪个、后用哪个直接决定了产出的质量。4.3 让 Skill 常驻项目的配置技巧如果你已经在某个项目里跑顺了想让它长期生效可以从两个层面入手。第一层是项目级配置。在CLAUDE.md里明确写出本项目已启用.claude/skills/下的技能库具体技能清单包括……。这样每次新起一个会话AI 都会重新读取项目记忆知道有哪些技能可用。注意CLAUDE.md不要写得过长AI 的上下文窗口有限你把技能清单列清楚就够了没必要把每个 Skill 的内容都抄进去。第二层是个人级配置。如果你每天都想用某个技能可以把它放到全局配置目录默认在~/.claude/下这样无论你打开哪个项目AI 都能看到这些技能。我习惯把思维类和需求澄清类的通用技能放全局把代码审查这种和项目强相关的留在各个项目的本地目录里。还有一点值得提醒技能文件多了以后AI 每次扫描都会消耗 token并增加响应延迟。我自己的经验是一个项目里放 15 到 25 个技能就是比较舒适的上限再多反而会让 AI 在选哪个技能上纠结甚至选错。定期清理不用的技能和清理代码依赖一样重要。5. 自己写一个 Skill技能文件的最小可复现模板Superpowers 真正的自由度在于你可以自己给 AI 加技能。写一个 Skill 没有想象的那么难本质就是按约定格式写一个 Markdown 文件。5.1 Skill 文件结构拆解一个标准的 Skill 文件通常包含两部分YAML frontmatter 和正文。YAML frontmatter 负责定义元信息和触发逻辑。常见字段有name技能名AI 会凭这个字段识别。description给 AI 看的描述写清楚这个技能解决什么问题什么时候用它。trigger触发条件可以是一个关键词方式也可以留空只做手动唤起。version版本号方便你后续迭代。正文部分是核心建议按下面几个小节组织背景说明这个技能为什么存在适用场景和不适用场景。输入要求需要调用方提供哪些信息最好有模板或示例。执行步骤步骤要尽可能地结构化大步骤下拆小步骤让 AI 一步步执行。检查清单AI 完成输出后需要自我对照哪些质量标准。输出格式定义最终输出的结构方便下游继续处理。有一个比较容易犯的错误把执行步骤写得太抽象比如分析用户需求这种一句话。AI 确实能理解但效果跟普通 Prompt 没什么区别。好的 Skill 应该写清楚分析用户需求时至少要考虑以下五个维度……并且每个维度都要用一个小标题单独展开。步骤写得越像操作手册最终输出就越稳定。5.2 写一个需求澄清技能的实战为了让你能直接照抄我分享一下我自定义的需求澄清技能它是我用的最多的技能之一。frontmatter 部分--- name: requirements-clarification description: 当用户提出一个模糊或复杂的需求时主动引导用户澄清目标、场景、验收标准和边界输出一份结构化的需求说明。 trigger: 需求澄清 version: 1.0.0 ---正文部分我要求 AI 按以下步骤执行先复述一遍你对需求的理解并要求用户确认或纠正。依次询问这些信息业务目标是什么目标用户是哪些人核心场景是哪一个可接受的验收标准是什么不能动的边界条件有哪些有哪些隐藏假设。如果用户给的信息不足不要硬猜使用如果确认不了我们可以先用默认假设的方式推进。输出格式固定为目标、用户、场景、验收标准、边界、假设、待确认问题七个部分。最后给出一个下一步建议比如建议先做原型还是先写接口文档。这个技能写完后我把它放到.claude/skills/目录里并在CLAUDE.md里加了一行当用户说帮我理清需求时使用 requirements-clarification 技能。实际效果非常好AI 不会再随便抛出一堆泛泛的功能列表而是像项目经理一样逼着你去想清楚。5.3 调试 Skills 的常见问题和性能建议写 Skill 时最常遇到的问题是AI 不按我写的步骤执行。我的排查思路是这样的先确认 AI 真的读到了这个文件。可以在对话里问它requirements-clarification 这个技能的执行步骤是什么如果它答不出来说明文件路径或索引有问题。再检查 frontmatter 格式。YAML 对缩进特别敏感一个空格错位会导致整个字段解析失败。建议写完先本地校验一遍 YAML 格式。最后是描述写得是否清楚。有时候 AI 不是不执行而是不知道什么时候该用。把 description 里那部分什么时候用它写得再具体一些触发率会明显提升。性能方面我前面提过技能数量不宜太多。另外还有个细节每个 Skill 文件本身可以适当控制篇幅我一般控制在 500 到 1000 字。太短了说明步骤不够细太长了你每次使用都要消耗大量 token而且 AI 可能只记忆开头忽略后面的细节。如果确实需要长步骤可以拆成多个 Skill让它们按顺序调用而不是塞在同一个文件里。6. 用了一段时间后的实战心得如果你已经看到这里说明你大概也想装一套试试。我分享一下自己踩过坑之后的一些体会希望能帮你少走点弯路。首先别一口气打满。刚开始用 Superpowers 时我一股脑把仓库里所有 Skill 全塞进项目里结果 AI 每次响应慢了不少还经常选错技能。后来我砍到只剩 15 个左右并且把最常用的几个设置为手动唤起情况立刻好转。技能这东西贵精不贵多。其次自己写 Skill 才是精髓。内置技能帮我们解决了从 0 到 1的问题但真正好用的往往是针对自己工作流定制的那几个。比如我给自己的写作流程写了一个博客文章生成技能规定开头必须用场景切入、每个小节要有具体案例、结尾必须给可操作建议。每次让 AI 写初稿它都能稳定产出我想要结构的内容不再需要我在 Prompt 里反复啰嗦。最后Skill 的维护也很重要。我每隔两周会过一遍自己写的技能文件有没有哪个触发条件和现在的习惯冲突了哪个技能的输出格式可以优化把技能当成活文档来维护AI 配合你的能力才会越来越强。Superpowers 给我的感觉不像是一个普通工具更像是一套让 AI 学会专业人士思考方式的框架。它没有把智能直接堆给你而是给了你一个组织经验、流程、标准的结构。安装和使用都不难难的是你愿不愿意花一点时间把你脑子里那些只有我知道怎么做的东西写成一个 AI 也能读懂的流程单元。一旦做完你会发现手里的 AI 真的多了一层超级能力。