1. 从“superpowers”这个热词说起：它到底是什么

第一次看到“superpowers”这个词，很多人会下意识联想到超级英雄电影里的超能力。但在当下技术社区的语境里，它指的是一套围绕 AI 编程助手构建的技能扩展体系——你可以把它理解成给 AI 助手装上一组“外挂模块”，让它在特定任务上从“能聊两句”变成“真能干活”。

我最初接触这个概念是在一个前端项目里。当时我用 AI 助手写一个复杂的表单校验逻辑，它给出的代码结构还行，但边界条件处理得一塌糊涂。后来有人跟我提了一句“你试试 superpowers”，我才开始认真研究这套东西。用下来的感受是：它解决的核心问题不是“AI 会不会写代码”，而是“AI 能不能按照一套可靠的工程规范去写代码”。

具体来说，superpowers 提供了一组预定义的skills（技能），每个 skill 针对一类具体任务场景，比如代码审查、测试驱动开发、调试排查、文档生成等。当你把这些技能引入到 AI 助手的工作流中后，助手在面对对应任务时就不再是“自由发挥”，而是按照技能里定义的步骤、检查清单和输出规范来执行。这就像给一个刚入职的工程师发了一本《操作手册》，他不用每次遇到问题都从头摸索。

这套东西适合谁？我的判断是三类人：一是日常重度使用 AI 编程助手的开发者，你已经习惯了让 AI 帮你写代码，但总觉得输出质量不稳定；二是技术团队的负责人，你想让团队里不同人用 AI 产出的代码保持一致的规范；三是对 AI 工作流感兴趣的技术爱好者，你想搞清楚“让 AI 按流程办事”这件事到底怎么落地。不管你是哪种，下面我会把 superpowers 的安装、技能引入、具体使用和踩坑经验都讲清楚。

2. superpowers 的整体设计与核心思路拆解

2.1 为什么需要“技能”这层抽象

要理解 superpowers 的设计，先得理解一个痛点：通用 AI 助手在专业任务上的表现是不稳定的。同一个问题你问两遍，它可能给你两种不同风格的答案。原因很简单——大语言模型的输出本质上是概率性的，它没有一个“标准作业程序”来约束自己。

superpowers 的思路是在 AI 助手和具体任务之间插入一层“技能定义”。每个技能本质上是一份结构化的指令集，包含几个关键要素：触发条件（什么情况下该用这个技能）、执行步骤（按什么顺序做什么事）、检查清单（做完之后要验证哪些点）、输出格式（结果应该长什么样）。当 AI 助手加载了某个技能后，它在处理对应任务时就会参照这份指令集来行动。

这个设计的巧妙之处在于：它没有试图去改变模型本身的能力，而是通过约束输出空间来提升可靠性。打个比方，一个厨师什么菜都会做，但你让他每天做一百道不同的菜，出品质量肯定参差不齐。如果你给他一份标准菜谱，告诉他“今天就按这个流程做这五道菜”，出品稳定性立刻就不一样了。superpowers 的 skills 就是那份菜谱。

2.2 技能体系的分层结构

我实际用下来，superpowers 的技能大致可以分成几个层次。最底层是通用工程技能，比如代码审查、重构建议、错误排查，这些不挑语言和框架，任何项目都能用。中间层是流程类技能，比如测试驱动开发的完整流程、代码提交前的自检流程，这类技能强调的是“按步骤走”。最上层是场景类技能，针对特定任务，比如写 API 文档、生成数据库迁移脚本、做性能分析。

这种分层的好处是你可以按需引入。如果你只是想让 AI 帮你做代码审查，那就只引入审查相关的技能，不用把整套体系都装上。我在实际项目中就是先引入了代码审查和调试两个技能，用顺了之后才逐步加上测试和文档相关的。

2.3 与传统 prompt 工程的区别

有人可能会问：这不就是写一段详细的 prompt 吗？我的理解是，它比 prompt 更进了一步。普通的 prompt 是你每次对话时临时写的，写完就没了，下次还得重写。而 superpowers 的技能是持久化、可复用、可组合的。你引入一次，之后 AI 助手在处理相关任务时就会自动参照。而且技能之间可以组合，比如“调试”技能可以和“代码审查”技能叠加使用，形成一个更完整的工作流。

另一个区别是标准化。prompt 的质量完全取决于写 prompt 的人的水平，而 superpowers 的技能是经过设计和验证的，有固定的结构和检查点。这对团队协作特别有价值——大家用的是同一套技能，产出物的风格和质量就有了基本保障。

3. 核心技能解析与实操要点

3.1 代码审查技能：怎么让 AI 真正挑出问题

代码审查是我用得最多的一个技能。没有引入这个技能之前，我让 AI 审查代码，它基本上就是夸一遍然后提两个无关痛痒的建议。引入之后，变化非常明显——它会按照一套固定的维度去检查：边界条件、错误处理、命名规范、性能隐患、安全风险。

具体使用的时候，我的操作流程是这样的：先把要审查的代码文件路径告诉 AI 助手，然后明确说“用代码审查技能检查这个文件”。助手会先读取文件内容，然后逐项对照技能里定义的检查清单。我实测下来，它在边界条件这块特别有用。有一次它指出我写的一个分页逻辑在“总数为零”的情况下会抛异常，这个 case 我自己确实没考虑到。

注意：代码审查技能的效果和代码的可读性直接相关。如果你给它的是一坨没有注释、变量名全是 a1、b2 的代码，它的审查质量会明显下降。建议在审查前确保代码至少有基本的命名规范和模块划分。

3.2 调试排查技能：从“猜”到“系统排查”

调试技能解决的是另一个常见痛点：AI 助手面对报错信息时，经常给出“你可以试试这样”“也可能是那样”的模糊建议。调试技能的做法是强制走一个系统化排查流程：先复现问题，再定位范围，然后提出假设，最后验证假设。

我印象最深的一次是处理一个异步任务的 bug。任务偶尔会卡住不执行，日志里没有任何报错。我把相关代码和现象描述给 AI 助手，它加载调试技能后，第一步是让我确认任务的触发条件是否每次都满足，第二步是检查异步队列的容量配置，第三步才是看代码逻辑。结果问题出在第二步——队列容量设得太小，高峰期任务被静默丢弃了。如果没有这套系统化流程，我可能还在代码逻辑里绕圈子。

3.3 测试驱动开发技能：先写测试再写实现

测试驱动开发（TDD）这个技能，说实话我一开始是抗拒的。我之前的习惯是先写实现，跑通了再补测试。但用了这个技能之后，我发现 AI 助手在 TDD 模式下的产出质量确实更高。原因是：当你先让 AI 写测试时，它必须把需求想清楚；然后再写实现时，它有了明确的“通过标准”，不会跑偏。

操作上，我会先描述功能需求，然后说“用 TDD 技能来实现这个功能”。助手会先生成测试用例，我确认测试用例覆盖了我要的场景后，再让它写实现代码。这个过程比直接写实现要多一轮交互，但省去了后面反复调试的时间，总体算下来是划算的。

3.4 技能引入的三种方式与选择建议

引入技能的方式，我试过三种。第一种是全局引入，在 AI 助手的配置文件里一次性加载所有技能。这种方式适合你确定要长期使用整套体系的情况，好处是不用每次手动指定，坏处是可能会让助手在简单任务上也走复杂流程。第二种是按项目引入，在具体项目的配置里声明需要哪些技能。这是我最推荐的方式，因为不同项目对技能的需求确实不一样。第三种是临时引入，在单次对话中手动指定使用某个技能。适合你只是想试一下某个技能效果的情况。

选择哪种方式，我的建议是：先用临时引入的方式试两三个技能，找到对你最有价值的那些，然后在常用项目里按项目引入。全局引入我建议谨慎，因为技能太多反而会稀释每个技能的效果。

4. 完整实操流程：从安装到跑通第一个技能

4.1 安装前的环境确认

在安装 superpowers 之前，有几件事需要先确认。首先是你使用的 AI 编程助手是否支持技能扩展机制——目前主流的几款助手对这类扩展的支持程度不一样，有的原生支持，有的需要通过配置文件来实现。其次是你需要有项目的写入权限，因为安装过程会往项目目录里添加配置文件。

我建议在安装前先做一次环境快照，比如把当前的配置文件备份一下。这样万一安装过程中出现冲突，可以快速回滚。具体操作就是把你 AI 助手的配置目录整个复制一份，改个名字加上日期后缀。

4.2 安装步骤与关键配置

安装过程本身不复杂，核心就是几步。第一步是获取 superpowers 的技能定义文件，通常是一个包含多个技能描述的目录结构。第二步是把这些文件放到 AI 助手能读取到的位置，一般是项目根目录下的特定文件夹，或者用户配置目录下的扩展文件夹。第三步是在助手的配置文件里声明启用哪些技能。

这里有个细节值得注意：技能文件的存放位置会影响它的作用范围。放在项目目录下，只对这个项目生效；放在用户配置目录下，对所有项目生效。我自己的做法是：通用的代码审查和调试技能放在用户目录，项目特定的技能放在项目目录。

配置声明这块，不同助手的语法不太一样。有的是在 JSON 配置文件里加一个 skills 数组，有的是在 Markdown 格式的配置文件中列出技能名称。我建议你直接参考 superpowers 官方提供的配置示例，不要自己凭感觉写，因为格式错误会导致技能加载失败，而且报错信息往往不明确。

4.3 验证技能是否生效

安装完成后，怎么确认技能真的生效了？我的方法是做一个对照测试。找一个你熟悉的任务，比如审查一段有明显问题的代码，分别在不指定技能和指定技能的情况下让助手执行，对比输出结果。如果指定技能后的输出明显更有结构、更深入，说明技能加载成功了。

另一个验证方法是直接问助手“你现在加载了哪些技能”。支持技能机制的助手通常能列出当前可用的技能列表。如果列表是空的，或者缺少你配置的技能，那就需要检查配置文件路径和格式。

4.4 第一个实战：用代码审查技能处理一个真实文件

我拿一个真实的例子来演示。假设你有一个用户注册的处理函数，代码大概五十行左右。操作流程是：打开 AI 助手的对话界面，输入“请用代码审查技能检查 src/handlers/register.js 这个文件”。助手会读取文件，然后按照技能定义的检查维度逐项分析。

我实测的输出结构通常是这样的：先给一个总体评价，然后分维度列出发现的问题，每个问题附带具体的代码行号和修改建议，最后给一个优先级排序。这个输出结构本身就是技能带来的价值——没有技能的时候，AI 的输出是散乱的；有了技能，输出是结构化的，你可以直接照着改。

提示：第一次使用某个技能时，建议拿一个你非常熟悉的代码文件来测试。这样你能准确判断 AI 的审查质量，也能建立对技能的信任度。不要一上来就拿核心业务代码去试。

5. 常见问题与排查技巧实录

5.1 技能加载失败怎么办

这是最常见的问题。表现是：你明明配置了技能，但助手的行为没有任何变化。排查顺序我一般是这样的：先确认配置文件的位置是否正确，不同助手读取配置的路径不一样，放错了地方等于没配。然后检查配置文件的格式，JSON 文件里多一个逗号少一个引号都会导致解析失败。最后确认技能定义文件本身是否完整，有时候下载过程中文件损坏了，助手读取不到内容。

如果以上都确认没问题但还是不生效，我的经验是重启一下助手。有些助手是在启动时加载技能配置的，运行中修改配置不会热生效。

5.2 技能效果不明显的原因分析

有时候技能加载成功了，但效果没有预期那么好。我遇到过几种情况。一种是任务描述太模糊，比如你只说“帮我看看这段代码”，助手不知道你要它用哪个技能、关注哪些方面。另一种是代码或项目结构太混乱，技能里的检查清单没法有效执行。还有一种是技能和任务不匹配，比如你用一个前端审查技能去检查后端代码，效果自然不好。

解决办法是：在调用技能时尽量明确任务边界，比如“用代码审查技能检查这个文件的错误处理逻辑”，而不是笼统地说“检查这个文件”。

5.3 多个技能同时使用时的冲突处理

当你同时引入多个技能时，偶尔会出现指令冲突。比如代码审查技能要求“先看整体结构再看细节”，而调试技能要求“先定位问题范围再看代码”。如果两个技能同时作用于一个任务，助手可能会在两种流程之间摇摆。

我的处理原则是：一个任务只用一个主技能。如果确实需要多个技能配合，就分阶段进行。比如先只用调试技能定位问题，问题定位后再切换到代码审查技能来检查修复方案。这样每个阶段的目标清晰，不会互相干扰。

5.4 常见问题速查表

5.5 我踩过的三个坑

第一个坑是贪多。一开始我把能找到的技能全装上了，结果助手在每个任务上都试图走复杂流程，简单任务也要绕一大圈。后来我精简到只保留三四个核心技能，效率反而高了。

第二个坑是忽略技能版本。superpowers 的技能定义是会更新的，我有一段时间一直用旧版本的技能文件，发现有些检查项已经过时了。建议定期检查一下有没有更新。

第三个坑是没有建立自己的技能组合。用了一段时间后我发现，最顺手的配置是“代码审查 + 调试 + 测试”这三个技能的组合，其他技能对我来说使用频率很低。找到适合自己的组合比追求“全”更重要。

6. 进阶用法：把技能组合成工作流

6.1 从单技能到工作流的思路转变

单独用一个技能解决单个问题，这是入门用法。进阶用法是把多个技能串成一个工作流，覆盖从需求到交付的完整链路。比如我现在的标准流程是：接到新功能需求后，先用测试驱动开发技能生成测试用例，确认用例覆盖完整后，再用代码审查技能检查实现代码，最后用调试技能处理测试中发现的问题。

这个工作流的价值在于每个环节都有明确的输入和输出。测试用例是输入，实现代码是输出；实现代码是输入，审查报告是输出。环节之间衔接清晰，不会出现“做到一半不知道下一步该干嘛”的情况。

6.2 自定义技能的思路

superpowers 提供的预置技能覆盖了常见场景，但你的项目可能有特殊需求。这时候可以考虑自定义技能。自定义技能的核心是写清楚三件事：什么时候用（触发条件）、按什么步骤做（执行流程）、做完怎么检查（验证清单）。

我写过一个针对数据库迁移的自定义技能，触发条件是“涉及数据库结构变更的任务”，执行流程是“先生成迁移脚本，再生成回滚脚本，然后检查索引影响”，验证清单是“迁移脚本能在测试库跑通、回滚脚本能正确还原”。写完之后，团队里所有人做数据库变更时都会走这个技能，再也没有出现过“迁移脚本写了但忘了写回滚”的情况。

6.3 团队协作中的技能共享

如果你在团队里推广 superpowers，我的建议是从一个小范围开始。先找两三个愿意尝试的同事，一起用一两周，把好用的技能和配置沉淀成团队共享的文档。然后再逐步推广到更多人。

共享的时候要注意版本管理。技能文件本身应该纳入版本控制，这样每个人用的都是同一套技能定义。配置文件的差异（比如个人偏好的技能组合）可以各自维护，但技能定义本身要统一。

7. 我个人的使用体会

用 superpowers 这套东西大概有几个月了，最大的感受是：它改变的不是 AI 的能力上限，而是 AI 的输出下限。以前用 AI 助手，好的时候特别好，差的时候特别差，你得花很多精力去判断这次输出靠不靠谱。引入技能之后，输出的波动范围明显收窄了，你大概知道它会给你什么水平的东西。

另一个体会是，技能的价值和你的任务复杂度成正比。如果你只是让 AI 帮你写个简单的工具函数，用不用技能差别不大。但如果你要处理的是一个涉及多个文件、多个模块的复杂任务，技能带来的流程约束就非常有价值了。

最后分享一个小技巧：每次用完一个技能后，花两分钟记录一下这次的使用感受——哪个检查项特别有用、哪个步骤感觉多余、输出里有没有你没想到的点。积累一段时间后，你就能根据自己的实际需求去调整技能配置，甚至写出更适合自己的自定义技能。这个过程本身就是对你自己工作流的一次梳理。