1. Superpowers 到底是什么解决什么问题先说结论Superpowers 不是某个炫酷的框架也不是什么黑科技插件它是一套专门给 AI 编程助手用的“技能包”。装上它之后AI 不再只是你问一句它答一句的聊天窗口而是能按一套标准工作流去思考、拆解、执行任务的工程助手。说白了就是给 AI 装上一套“职业培训手册”让它知道什么时候该先写方案什么时候该写测试什么时候该停下来说“我发现了问题”。这年头用 AI 写代码的人不少但大多数人其实还停留在“让它生成一段代码”的阶段。遇到复杂的任务AI 的表现就很不稳定有时候它能一口气写出漂亮的功能有时候它绕来绕去改 bug 改出一堆新 bug。问题出在哪出在 AI 没有一个稳定的方法论。它知道很多知识但它不像一个老工程师那样知道“遇到 bug 应该先复现、再定位、再修、再回归验证”。Superpowers 做的事情就是把这些经验方法论固化成一份份可以被 AI 读取和调用的“技能文件”。这个项目最早是围绕 Claude Code 这类终端型 AI 编程工具设计的但它的核心思路完全可以迁移到其他支持 skills 机制的 AI 工具上。如果你正在用 AI 结对编程觉得“有时候好用有时候不好用”那你就是 Superpowers 的目标用户。如果你是新手刚接触 AI 编程助手那这篇文章能帮你从一开始就建立正确的使用姿势少走很多弯路。2. 核心机制拆解skills 到底是怎么运作的2.1 一个 skill 文件里装了什么要理解 Superpowers先得理解它背后的 skills 机制。一个 skill 本质上就是一个目录里面装着一份说明文件通常叫SKILL.md。这份说明文件不是给人读的是给 AI 读的。它一般包含两部分头部是元信息写着这个技能叫什么、什么时候该用、用之前需要什么条件正文部分是操作指引告诉 AI 这个技能具体怎么执行。我拿“写测试”这个技能举例。常见的写法是这样的--- name: write-tests description: 当新增功能或修改 bug 时使用该技能为代码编写单元测试和集成测试 --- # Write Tests ## 触发条件 - 用户要求为某个功能添加测试 - 修改了现有代码但测试未同步更新 ## 执行步骤 1. 先阅读被测代码梳理公开接口与核心逻辑 2. 确定测试框架与运行命令 3. 为每个关键路径编写测试用例覆盖正常分支与异常分支 4. 运行测试确认全部通过 5. 如果测试失败回到代码定位问题而不是直接改测试 ## 注意事项 - 不要为了覆盖率而写无意义的断言 - 测试速度过慢时优先拆分大测试AI 读到这份文件之后就会按里面写的步骤去执行。你可以把 skill 理解成给 AI 的“函数定义”只不过这个函数是用自然语言写的。2.2 AI 怎么知道自己该用哪个技能这里就涉及 skills 机制最巧妙的部分了。AI 不会一次性把所有技能都读进上下文——那样太消耗 token 了。它通常只读取一个索引文件里面列着所有可用技能的“名称”和“一句话说明”。当任务来临时AI 先看索引判断当前任务可能匹配哪个技能再去读取对应的SKILL.md完整内容。这个过程有点像你打开手机里的外卖 App先看到的是店铺列表和招牌菜点进感兴趣的那家才能看到完整菜单。Superpowers 的价值在于它把大量工程实践整理成了成熟的“菜单”而不是让 AI 每次都在大脑里临时发挥。2.3 为什么非要用技能框架直接写 prompt 不行吗这是很多人问的问题。理论上你可以在 prompt 里写“请先写测试再写实现”AI 也会照做。但实践下来有几个问题第一prompt 越长AI 越容易丢失重点尤其是对话轮数多了之后早期指令的影响力迅速衰减第二每次开新会话都要重新啰嗦一遍效率太低第三你自己的方法论很可能不够系统想到哪儿写到哪儿。技能框架解决的就是这三点它把方法论固化成文件不占用对话上下文它按需加载AI 需要用的时候才读取它经过社区大量实践验证比个人临时总结的 prompt 专业得多。Superpowers 帮我省下的最大时间开销就是“反复向 AI 解释我的工作习惯”这件事。3. 安装与配置从零开始引入 Superpowers3.1 先说清楚前提条件安装 Superpowers 之前你至少得有一个支持自定义 skills 的 AI 编程环境。目前比较常见的是 Claude Code 这类命令行工具另外像 Codex、Cursor 等也在逐步支持类似的 skills 机制。需要注意的是技能文件本身是通用格式但加载方式在不同工具里略有差别下面的步骤主要基于 Claude Code 这类工具来演示其他工具的读者可以对照调整。我的建议是先确认你的工具已经能正常跑通基础对话再考虑装技能包。不要一上来就折腾环境否则出问题了你分不清是技能的问题还是工具本身的问题。3.2 获取技能包Superpowers 的获取方式很直接既然是开源项目最常规的做法就是克隆仓库到本地。这里我按最常见的方式演示# 找一个合适的目录存放技能包建议放在用户目录下 cd ~ git clone https://github.com/yourusername/superpowers.git克隆完成后你会看到目录里有一堆子目录每个子目录就是一个独立的技能。有些仓库会带一个install.sh脚本有些则是纯手工复制。我遇到的大部分情况是手工配置所以下面重点讲手工方式。3.3 配置 AI 工具读取技能目录这一步是核心。你的 AI 工具通常有一个专门的目录用来放 skills名字可能叫skills也可能是.claude/skills之类的。你需要做的就是把克隆下来的技能目录复制进去或者做一个软链接。以常见做法为例# 假设你的 AI 工具技能目录是 ~/.claude/skills mkdir -p ~/.claude/skills # 把技能包里的所有技能目录复制过去 cp -r ~/superpowers/* ~/.claude/skills/复制完之后检查一下目录结构是不是长得像这样~/.claude/skills/ ├── brainstorming/ │ └── SKILL.md ├── debugging/ │ └── SKILL.md ├── test-driven-development/ │ └── SKILL.md └── ...每个技能目录下必须有SKILL.md文件AI 靠这个名字来识别技能。如果你发现某个目录里没有这个文件多半是克隆不完整或者项目结构有调整需要回到仓库主页确认最新的目录布局。3.4 验证技能有没有被 AI 正常感知装完之后别急着开始写代码先做个快速验证。开一个新的会话直接问 AI 一句你现在有哪些可用技能请列出名称和用途。AI 如果能列出一串技能清单说明技能索引加载成功。如果它说“我没有技能”或者“我不太清楚”那大概率是技能目录配置不对。这种情况我后面会在常见问题里专门讲排查方法。4. 内置技能逐个看Superpowers 里有哪些 skills4.1 规划与设计类技能这一类的核心价值是“先想清楚再动手”。其中最常用的是brainstorming头脑风暴和writing-plans写实施计划。brainstorming技能解决的是需求模糊的问题。很多时候用户说“帮我做一个数据看板”但这个需求背后有太多没定义的细节数据从哪里来看给谁用需要哪些指标更新频率是多久如果没有这些信息AI 写出来的东西大概率不是你要的。这个技能会引导 AI 在动手写代码之前先向你确认需求、列出开放性问题、给出多个方案选项。我实际用下来的感受是它把“AI 猜需求”变成了“AI 问需求”光这一点就能避免一半以上的返工。writing-plans则是在需求明确之后把实现路径拆成一份可执行的分步计划。它要求 AI 先列出所有涉及的文件、改动点、依赖关系再排执行顺序。这个技能对大型改动特别有用。我接手一个老项目时经常让 AI 先出一份改动计划给我 review确认无误后再让它动手安全感提升了一个等级。4.2 编码与测试类技能这一块是 Superpowers 的重头戏也是绝大多数人安装它的直接原因。test-driven-development测试驱动开发技能会强制 AI 按红灯-绿灯-重构的节奏推进先写一个会失败的测试再写最小实现让测试通过最后重构代码并保持测试绿色。说实话第一次看 AI 执行这个流程的时候我是有点感动的因为它不再是闷头给你甩一大段代码而是像真人一样一步步来每一步都有测试兜底。debugging技能也值得单独拿出来说。它给 AI 定了一套非常严格的排查流程先复现问题、再缩小范围、提出假设、验证假设、定位根因、修复、回归。最关键的是它要求 AI 在定位到根因之前禁止直接改代码。这条规则救过我很多次——以前 AI 经常是“猜一个可能的原因然后改一行代码试试”运气好能用运气不好就引入新问题。有了这条强约束整个调试过程变得有章法多了。除了这两个还有code-review、refactoring、writing-commit-messages之类的常见技能。每个技能的侧重点不同但底层思路是一致的把专业工程师的习惯写成规范流程让 AI 照章执行。4.3 研究与验证类技能这类技能解决的是“别让 AI 编造答案”的问题。verification或类似的研究类技能会要求 AI 在给出结论之前先明确信息来源、验证路径甚至先跑一段命令确认当前状态再基于事实做推断。举个例子你让 AI 排查一个线上问题它可能会凭经验给出几种可能原因。但在有验证类技能约束的情况下它要先检查日志、确认配置、复现现象然后才敢下结论。这套流程对生产环境排障特别重要——没做过的事情就说是“可能原因”有做过验证的才说“确定原因”这种严谨性正是 AI 编程中最稀缺的品质。5. 实战体验与调用技巧5.1 让 AI 主动使用技能的两种姿势技能装好之后你实际使用中会遇到两种情况一种是任务很典型AI 自动就匹配到了正确技能另一种是任务不太典型AI 不知道调哪个技能或者干脆没意识到有技能可用。对于第一种情况你什么都不用做正常提需求就行。AI 读懂了你的需求后会在后台查索引、加载技能、按技能流程执行。你会注意到它的思考方式明显不同——变得更结构化比如它会先总结“我准备按以下步骤来”或者先问你几个澄清问题。对于第二种情况最好的做法是显式点名。直接在对话里说请使用 brainstorming 技能帮我梳理这个功能的需求。或者说按 test-driven-development 技能来开发这个模块。显式点名有两个好处一是强制 AI 加载对应的技能文件二是让 AI 进入该技能的角色设定不再依赖它自己的“自由发挥”。我个人的习惯是新需求用 brainstorming 过一遍实现时显式指定 tdd 技能遇到线上 bug 则明确要求走 debugging 流程。5.2 技能之间怎么配合使用Superpowers 的另一个特点是技能之间可以串起来用。这就像真实开发流程一样一个需求从想法到上线中间要经过多个阶段每个阶段对应一个或几个技能。我经常用的组合套路是这样的先用 brainstorming 把模糊需求想清楚 → 再用 writing-plans 拆解实现步骤 → 接着用 test-driven-development 写功能 → 最后用 code-review 让 AI 自己审一遍代码。这套流程走下来整个开发过程非常流畅。每个技能的输出会自然成为下一个技能的输入比如 brainstorming 产出的需求确认清单可以直接交给 writing-plans 去生成实施计划。AI 在这种多技能配合的模式下表现更像一个完整的小团队。5.3 自定义技能把个人经验也变成资产Superpowers 自带技能够用但真正让它发挥最大价值的是你开始写自己的技能。技能文件格式并不难无非是 markdown 加几个字段。我建议从自己的痛苦经历里找灵感你反复向 AI 叮嘱过什么你在哪个环节被 AI 坑过把这些写成技能以后就不会再踩同一个坑。我举个例子。我手头有一个老项目启动流程特别繁琐每次开新会话都要跟 AI 解释一堆前置步骤。后来我写了一个project-bootstrapping技能把启动命令、环境变量、常见坑都写进去了。从那以后每次开新会话我只要说“按项目启动技能来”AI 就自动完成所有初始化工作省心到不行。写自定义技能的时候我有个小建议先从最让你头疼的那个重复劳动开始。不要贪心一次只解决一个问题跑顺了再加新的。6. 常见问题与排查经验6.1 技能索引加载了但 AI 就是不用这是我遇到最多的情况。技能列表 AI 能列出来但实际执行任务时它完全不按技能走还是老一套自由发挥。问题的根源多半在于技能文件里的“触发条件”写得太窄或者描述不够具体。AI 判断“现在适不适合用这个技能”时靠的就是描述文字。如果描述里只写了“当用户需要编写测试时”AI 面对“帮我验证这个函数”这种非典型说法就可能识别不出来。解决办法有两个方向。一是改技能描述把所有可能的说法都列进去让描述更宽泛二是在对话里显式点名强制 AI 使用。我倾向于后者因为改技能文件会影响所有会话显式点名则只影响当前对话更灵活。6.2 技能文件存在但 AI 完全感知不到这种情况通常是目录配置问题。先检查技能文件放的路径对不对再看文件名是不是SKILL.md且大小写一致。我踩过一个大坑技能目录名和文件名都对但目录层级多了一层导致 AI 扫描不到。检测方法很简单开新会话问一句“你现在有哪些技能”。如果 AI 的回复里提到了你的技能说明加载成功如果提都没提就去检查路径和文件结构。这里没什么玄学几乎都是目录层级的问题。6.3 技能内部执行混乱步骤被跳过了AI 虽然加载了技能文件但执行到一半可能会偏离流程——比如让它先写测试它写了几行就去写实现代码了。这种情况最有效的招数是“边看边纠偏”。当 AI 开始跑偏时立刻打断它提醒它回到技能规定的当前步骤。这里有个小技巧你不需要重新读一遍技能文件只要用一句话点出关键约束就行。比如“按这个技能的流程现在应该先写失败的测试然后再实现”。实测下来这类提醒非常有效AI 会立刻回到正轨。6.4 一份速查表我把常见问题整理成一个速查表方便你直接对照排错。症状可能原因解决方案AI 列不出技能清单技能目录配置错误检查路径和 SKILL.md 是否存在能列出但实际不用触发条件描述不够宽泛显式点名指定技能或改描述技能执行到一半跑偏长对话中上下文干扰打断并提醒回到当前步骤技能之间互相冲突多个技能描述重叠简化描述明确职责边界自定义技能没生效元信息字段写错对照官方格式逐项检查7. 关于使用节奏的一点提醒技能不是装得越多越好这一点我想单独拿出来说。很多人一看到技能包里有几十个技能就全装上然后发现 AI 反而变笨了。原因很简单技能越多AI 判断“该用哪个”的难度就越大误用、跳用、混用的情况都会增加。我的建议是分阶段引入。第一周只启用三五个核心技能比如 brainstorming、debugging、test-driven-development。跑熟了之后再逐步加入其他技能。每次加入新技能后留意它对现有流程的影响——如果发现某个技能经常抢活或者被无视就该考虑调整描述或者干脆移除。另外技能只是工具不是银弹。它提升的是 AI 执行任务时的“下限”能让 AI 不犯低级错误、不跳步、不猜需求。但它不能帮你想清楚产品方向也没法替你做出架构决策。该你自己思考的部分还是得自己思考。把技能当成一个靠谱的执行框架而不是替代你思考的“外挂大脑”这个定位想清楚了用起来就不会失望。我在实际使用中最深的体会是真正值钱的不是那几十个现成技能而是你在这个过程中建立起来的“把经验固化成流程”的习惯。一旦你开始为自己写技能相当于把自己的知识资产化每多写一个未来的每一个新会话都站在了过去的肩膀上。这种复利效应才是 Superpowers 带给我的最大收获。