1. Superpowers到底是什么：从“快”到“可靠”的中间层

1.1 为什么现在缺的不是速度，而是可靠

说实话，现在的AI编程工具在生成速度上已经快到让人没耐心等。让模型写个函数、补个测试，几乎都是秒出。但问题恰恰出在这里：速度越快，代码的质量风险就被放得越大。很多开发者都有过这种经历——让AI“加一个日志清洗功能”，它唰唰唰给你改了三四个文件，看起来每个文件都挺合理，往里一翻才发现，它把日志模块的接口也顺手改了，和现有调用方完全不兼容。

更麻烦的是，当这个对话聊了半小时、上下文里堆了几千行代码之后，AI经常会“遗忘”最开始的需求约束。在传统开发流程里，这种问题可以由代码评审和测试把关；但在AI自由发挥的对话式编程里，缺少一个“流程闸门”。Superpowers就是在这样的背景下被更多人重新发现的：它不是让AI写得快，而是让AI按一个可持续验证的流程来写。

1.2 核心定位：一套模块化、可复用的“技能库”

第一次接触Superpowers的时候，我有一个误判，以为它就是把一堆提示词打包成插件。真正装完看了几分钟，才发现它的核心是一套“技能文件”。每个技能对应一个特定的工程任务类型，技能文件用结构化的Markdown描述“什么时候该用这个技能、应该按照什么步骤执行、过程中要产出什么中间物”。技能文件头部通常会写明适用场景和触发条件，中间部分是一个明确的流程列表，最后还会规定产出物格式。

技能文件在整个体系里是真正的主角。它比提示词更有沉浸感：提示词是一次性的对话文本，而技能文件是待命的“能力包”。技能文件放在本机，既可以做成个人偏好，也可以整目录放进Git仓库变成团队规范。这整套东西的价值在于：你不需要在每次会话里重复“请你扮演一个资深后端工程师，先分析需求再写测试最后实现”这种长句子，只需要一个@技能名，所有约定就自动注入。

1.3 为什么叫“Superpowers”：把流程装备化

Superpowers这个名字起得很有意思。作者没有把它叫做“提示词增强包”，而是强调“超能力”。开发的思路是，把工程过程中那些成熟但琐碎的方法论，像装备一样装配给AI。就像程序员拿到一个库，不用重新发明轮子；AI拿到一个技能文件，就不用重新思考步骤。

我实际使用下来，这种“装备化”的设计带来了两个直观变化。第一，AI的启动状态更专业，它开始干活前会先声明“我准备按照某个技能流程来执行”，而不是直接从第一行代码开始编。第二，当任务偏离方向时，我能很快指出“你没按技能流程走”，然后把它拉回来，这在以前几乎不可能做到。这种感觉就像你从“让AI随手写代码”切换到了“和AI一起执行一个明确的小型项目”，后者显然更接近真实工程场景。

1.4 和普通提示词模板相比，差异到底在哪

为了让你把Superpowers和其他主流AI编程用法分清楚，我梳理了一个对比：

这个区别是本质上的。模板只是“说了一次的要求”，技能文件是“每次都会读到的规范”。当我们强调可靠时，规范要变得可重复、可约束，而技能文件做到了这一点。如果你想让AI编程体验从“开盲盒”变成“走流程”，Superpowers就是中间那层转变的关键。

2. 安装与环境准备：把技能装进AI助手

2.1 选好扩展和AI助手的组合

在实际使用之前，我需要先说明一下搭建环境的大方向。Superpowers是以VS Code扩展形式分发的，扩展本身并不产生代码，它负责三件事：管理技能文件、把技能注入到当前AI会话、提供可视化入口让你查看技能列表。

我的推荐配置是VS Code加一个主流的AI编程助手。Superpowers并不过度依赖某一款，核心是它要求助手支持“读取本地技能目录”和“按照技能步骤执行”。如果你用的是Claude Code，安装之后它会自动识别用户目录下的skills文件夹；如果用的是其他AI编程工具，只需要确认它有类似的技能加载机制即可。这一点比很多绑定特定模型的产品更友好。

安装步骤很简单：在VS Code扩展市场搜索Superpowers，点击安装，然后在扩展设置里指定一个“技能目录”。之后重启VS Code，扩展就会把目录里的技能文件同步给AI助手。整个过程大概五分钟，没有什么复杂的配置，但有一个细节我后面会单独讲：目录路径里尽量不要有中文，否则部分模型解析技能文件时会出现编码问题。

2.2 技能文件到底放在哪里：全局、项目还是团队

技能文件的存放路径决定了这套技能的“生效范围”。这里有三层选择：

• 用户级目录：推荐。任何项目都能使用，适合放通用型技能，比如test-driven-development、debugging。
• 项目级目录：项目专属。适合放和当前业务强相关的技能，比如“xx系统代码生成规范”或者“数据库迁移操作流程”。
• 团队共享目录：把这个目录里的技能文件纳入版本控制，大家拉下来就能用同一套开发流程。

这是整个体系里最容易被忽略、也最容易踩坑的地方。我见过有人把技能装在用户级目录，却在项目里运行另一套同名技能，结果AI每次加载的都是项目级版本，用户级改动怎么都不生效。后来排查很久才发现是目录优先级问题。建议制定一个统一约定，别让两套技能打架。

2.3 如何验证技能真的被加载

技能装完之后，不要直接开始写业务代码，先做一次“加载验证”。我的验证方式很简单：打开AI助手，输入一句类似“请先加载brainstorming技能，然后我们聊一下这个需求的边界”。如果模型返回的内容里包含了技能定义的步骤，就说明加载成功。

如果没有反应，我会按顺序排查：第一步看skills目录下是否有SKILL.md文件，文件名错了模型不认；第二步看扩展设置里的路径是否指向了正确的层级，很多人把路径指到了某个技能文件夹里面，而不是包含所有技能的根目录；第三步重启VS Code，让缓存重新建立。这套验证流程虽然朴素，但能把80%的无效工作排掉。

2.4 技能目录结构与配置思路

这里给出一个我在项目里使用的实际目录结构，供参考：

.skills/ ├── brainstorming/ │ └── SKILL.md ├── test-driven-development/ │ └── SKILL.md ├── local-file-reading/ │ └── SKILL.md └── code-review/ └── SKILL.md

每个技能文件夹里只需要一个SKILL.md。它的头部通常包含name、description、工作流程等字段。如果某个技能还依赖少量辅助文件，可以直接放在同一目录下。目录名和技能名保持一致，命名用小写中划线，模型解析的准确率最高。配置时还有一个容易被忽略的点：如果你同时在多个项目之间切换，建议把“通用技能”放在用户级目录，“项目专属技能”放在项目目录，两边互补，而不是互相覆盖。

3. 如何引入技能：把长提示词换成技能调用

3.1 技能调用的基本语法

Superpowers把技能调用的API设计得很简洁。核心语法就是在对话里用@标记技能名：

@test-driven-development 请为PaymentService的退款接口补足测试，并让测试先失败一次。

模型看到这个标记，会去找对应技能文件，加载里面的流程，然后严格按流程往下走。我们不再需要自己写“请你先写测试，再写实现，最后重构”，因为技能文件里全都写好了。

另一个重要点是“一个会话尽量只激活一个主技能”。有一次我把brainstorming和code-review一起@，结果AI先做了头脑风暴然后又试图审查自己的输出，整体流程变得非常割裂。后来我养成了习惯：主技能只有一个，其他技能在合适的时机追加。

3.2 常用技能清单与典型场景

我整理了一张个人使用频率最高的技能表：

每个技能的产出物都是将来可以回看的工作痕迹。这点非常关键。在传统AI编程里，对话结束就什么都记不住；技能流程会把中间产物留在对话或项目里，整个思考过程变得可追溯。尤其是code-review这类技能，它会按技能文件里列出的规则逐条检查，不会因为对话太长而漏掉几条。

3.3 让AI自动选技能：靠一个description字段

Superpowers支持自动选择技能，这个机制很多人没有充分用起来。当模型接收到一个新任务时，它会把任务语义去匹配所有技能文件头部描述，匹配度高的技能就自动加进当前执行计划里。

所以技能文件里description写得越具体，自动选择的准确率越高。我的写法是“该技能用于XX类型任务，当用户要求XX时使用”，而不是“该技能很常用”。比如不要写“适用于很多场景”，而是写“当用户要求在修改核心模块前先进行影响面分析时使用”。模型非常吃这一套，它会把它当成决策依据，而不是泛泛而谈的说明。

3.4 自己写技能：从复制到定制

当内置技能不够用的时候，自己定制一个技能文件并不难。我会按照这个模板来搭：

--- name: my-workflow description: 当用户需要执行XX任务时使用 --- # 工作流程 1. 读取任务背景 2. 列出当前文件清单 3. 输出修改计划 4. 等待确认后实施 5. 实施后用测试验证

写好之后放到技能目录里，重启VS Code，然后在对话里@my-workflow测试。如果模型没有按逻辑执行，多半是流程描述太口语化，把它改成明确的动词加产出物，比如“列出当前文件清单”而不是“检查文件”，模型的执行度会明显提升。技能这东西，越短越有效，我自己的技能文件一般控制在10步以内，因为步骤太多会稀释模型的注意力，反而容易跳过关键节点。

4. 核心优势拆解：可靠性究竟从哪里来

4.1 从黑盒输出到显性流程：每一步都有据可查

可靠性的第一步，是让AI的执行过程可以被观察。早期的AI编程更像一个黑盒：你发出指令，它直接吐出一大片改动，然后你来承担理解它逻辑的成本。Superpowers改变的是这个过程——它在执行链路里加入了分阶段的输出点：先输出需求理解，再输出方案，再输出测试计划，最后才写代码。

这么做的好处非常直观：你可以在任一步骤介入，把问题扼杀在早期。比如它把需求理解错了，你在方案阶段就能发现，不用等代码写完再来一遍推倒重来。这个过程相当于把“事后验收”提前到了“过程管理”。这个改变对复杂项目尤其重要，因为复杂项目中早期一个错误决定的影响往往会被放大十倍。

4.2 测试驱动开发的工程化：让AI自己证明代码没问题

可靠的核心是验证，而验证的高效手段依然是测试。Superpowers里的test-driven-development技能把TDD变成了一条硬流程：AI必须先写出一个失败测试，再实现足够通过该测试的代码，最后再考虑重构。这和手工开发中写测试的顺序完全一致，但由技能文件来保证AI不会跳步。

我实测过几次：在没有启用TDD技能时，AI经常会先写实现，然后补一个有“自证清白”意味的测试；启动TDD技能后，它被迫先写不太可能通过的测试，反而能提前暴露出我对接口设计的误解。这正是可靠性的核心逻辑：先定义“什么是正确”，再谈实现。对AI编程而言，这条顺序是生死线。

4.3 上下文管理和变更控制：防止AI“跑偏”

AI编程项目做得越大，越会暴露一个致命问题：模型上下文有限，聊着聊着就把早期约束忘了。Superpowers给这个问题提供了两层解法。第一层是记忆锚点：技能文件每次加载都会把约束重新注入，相当于提醒AI“我们约好要按这个步骤走”。第二层是变更控制：技能流程强制AI在改动大文件之前列出改动计划，等开发者确认后再动。

我曾经让AI重构一个被多个模块引用的数据模型，由于技能流程里有“先列影响面”这一步，AI在动手之前把十来个调用方全列了出来，我及时踩住刹车，避免了几个模块的连锁返工。这种能力不是模型本身变强了，而是流程让它变得更谨慎。在长期项目里，这种“谨慎”的价值远大于“快速产出代码”的价值。

4.4 可演进的知识沉淀：技能就是团队资产

最后一点容易被低估，但长期价值很大：技能文件是可以进化的知识资产。团队里某个成员发现了一个好用的调试流程，完全可以把它沉淀成新技能，提交到代码仓库，全员共用。几年下来，这套技能库就会成为AI编程时代的“团队手册”。

这些技能不依赖某个开发者的记忆，也不依赖某个模型的内部知识，它就在仓库里，谁拉下来谁用。短期的可靠靠流程，长期的可靠靠沉淀，Superpowers把两者都承接住了。我在团队里推行这套方案后，最大的变化是不同开发者对AI产出的评判标准变得一致了，不再出现“你觉得能跑就行，我觉得必须补测试”这种争论。

5. 实操案例：从需求到可靠代码的完整链路

5.1 一个小任务：给工具增加日志格式切换参数

以我上周做的Python小任务为例。需求是给命令行工具增加一个参数，让日志输出能在纯文本和JSON之间切换。表面上看很简单，但AI直接动手很容易改乱参数解析模块和日志模块。

第一步，我@brainstorming，AI先输出了一个需求边界清单，最后我们在“参数取名叫--log-format”这一点上达成一致；第二步，切到@test-driven-development，让AI先写一个测试，模拟传入--log-format=json，断言日志包含JSON字段；第三步，让AI写实现，改参数解析和日志初始化；第四步，让AI跑测试并给出验证结果。最终提交的改动只有两个文件、十来行代码，干净利落。

5.2 一个复杂重构：把单体模块拆成多个服务

另外一次经历是把一个接近两千行的单体模块拆成几个服务。这种任务不设流程的话，AI大概率会越拆越乱。我先@local-file-reading，要求只输出这个模块的函数清单和外部调用关系，不写任何代码；接着@brainstorming生成拆分方案，把“新服务各自的职责”写清楚；确认方案后，才让AI按test-driven-development的方式迁移第一批代码。

这件事给我们的提示是：复杂任务不是让AI一次性做完，而是每一步都给出足够小的缓冲。技能组合的目的就是给任务分阶段划定边界，让AI在边界内行动。那次重构全程花了两个多小时，但几乎没有发生“改一个地方弄坏另一处”的事故，和以前直接让AI大改相比，省下的返工时间远多于花费的流程时间。

5.3 复盘：可靠性提升的三个关键动作

复盘我自己几个落地项目，真正影响可靠性的动作就是三个：

• 开始写代码前强制做需求拆解，让AI先输出对需求的理解
• 任何涉及既有代码的大改动，必须先列改动计划和影响范围
• 每一步实现都用测试来验证，而不是靠AI口头保证

这三个动作难度不高，但在AI编程流程里容易被跳过。Superpowers的价值，就是把这几个工程习惯变成了不用每次重复的口头叮嘱，而是内置的流程规则。如果你只打算记住一篇文章里的三句话，这三句就够了。

5.4 反面教材：不设流程的AI编码现场

为了让你有更直观的体感，我可以讲一个反面案例。有一次我为了赶时间没有激活技能，直接让AI“优化下这段查询逻辑”。它确实给出了一个新版本查询代码，乍一看可读性很好，性能也不错。但问题是，它顺手把原来函数里一个副作用的逻辑给挪走了，几个依赖这个副作用的测试当场红掉。如果当时让它先走一遍code-review，或者至少先跑一下受影响路径的测试，就不会发生这种“好心办坏事”的情况。用技能是给AI上保险，不是拖慢速度。

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

6.1 技能没生效的排查路径

技能没生效是使用Superpowers最常见的挫折点。我遇到过至少四次，原因各不相同。整理出来的排查路径如下：

1. 确认技能目录里必须有SKILL.md，且大小写完全一致
2. 确认扩展设置里的技能根目录，指向的是包含技能文件夹的那一层，而不是某个技能内部
3. 重启VS Code，让技能文件被重新读取
4. 在对话里@技能名，看模型是否输出了技能文件里的流程框架
5. 检查当前项目是否有一份更高优先级的配置，覆盖了全局技能目录

只要按这个顺序走一遍，绝大多数问题都能解决。剩下的少数情况，往往不是配置错，而是模型对某个技能描述有歧义，那就回到修改description这个层面。

6.2 模型绕开技能流程时的应对方法

模型的自由度有时候是好事，有时候却是麻烦。最典型的表现是：技能流程明明要求先输出改动计划，模型却直接开始改代码。遇到这种情况，不用重新开聊天，直接在对话里说一句“先暂停代码改动，回到技能流程的第几步”。多数时候能立刻纠正。

如果想要更保险，可以修改技能文件的结构，把“等待确认”作为一个明显的阶段步骤，同时要求模型每完成一步就暂停。添加这种机制之后，模型“绕开流程”的概率会降低很多。本质上这还是在技能文件里下功夫，把约束写得越像任务步骤，模型越容易遵守。

6.3 多AI助手协同：让技能成为统一规范

现在的开发团队往往不止一个AI助手在工作。有的负责写代码，有的负责审查，还有的负责文档。技能文件因为是本地Markdown，天然可以共享。我们把技能目录纳入Git仓库之后，团队里的任何助手只要配置指向这个目录，就能使用同一套流程。

这种做法最大的收益是：减少了不同助手给出的风格不一致问题。以前用Claude Code写的代码和另一个助手写的代码在结构上总有些“性格差异”，统一技能后差异明显缩小，代码之间更像是同一个程序员写的。这一点在大团队里非常受用，因为AI输出的一致性直接影响后续维护成本。

6.4 性能和token开销：如何控制成本与速度

技能文件本质上也是上下文的一部分，加载过多肯定会增大token开销。我的建议是：不要让全部技能一次性加载，尽量在会话中按需@。如果发现某次会话特别长并且消耗token很快，可以看看是不是同时加载了好几个大技能文件。把技能文件保持在精简格式，不必要的背景说明能删就删，只在需要时引入。实践下来，一次正常开发会话增加的开销在可接受范围内，换来的是更少返工，整体性价比是高的。

最后再分享一个小小的个人习惯：我每次打开新会话，都会在正式任务前多问一句“你准备用哪个技能流程来做这件事”。别小看这一句，它相当于让AI先做一次“流程预演”，也是把AI编程从“快”引向“可靠”最关键的一种条件反射。