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编程用法分清楚我梳理了一个对比维度普通提示词模板Superpowers技能文件生命周期随对话结束而消失持久保存在本地/项目中触发方式每次都要完整写出来用技能名触发自动加载结构化程度自由文本容易歧义有明确字段适用场景、流程步骤、产出物可维护性分散在各聊天记录里统一目录管理、可版本控制执行约束靠模型自觉流程步骤成为模型的显式上下文这个区别是本质上的。模板只是“说了一次的要求”技能文件是“每次都会读到的规范”。当我们强调可靠时规范要变得可重复、可约束而技能文件做到了这一点。如果你想让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 常用技能清单与典型场景我整理了一张个人使用频率最高的技能表技能名触发方式典型场景预期产出brainstorming手动需求模糊、方案不确定需求拆解、候选方案、风险评估test-driven-development手动核心逻辑、重构、修复Bug先失败的测试、实现代码、重构后的测试绿local-file-reading显式/隐式模型需要读取本地代码文件关键结构、调用关系摘要debugging手动报错、行为异常复现步骤、根因假设、验证方案code-review手动提交前检查、合并前评审按规则逐条审查结果、修改建议每个技能的产出物都是将来可以回看的工作痕迹。这点非常关键。在传统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直接动手很容易改乱参数解析模块和日志模块。第一步我brainstormingAI先输出了一个需求边界清单最后我们在“参数取名叫--log-format”这一点上达成一致第二步切到test-driven-development让AI先写一个测试模拟传入--log-formatjson断言日志包含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最常见的挫折点。我遇到过至少四次原因各不相同。整理出来的排查路径如下确认技能目录里必须有SKILL.md且大小写完全一致确认扩展设置里的技能根目录指向的是包含技能文件夹的那一层而不是某个技能内部重启VS Code让技能文件被重新读取在对话里技能名看模型是否输出了技能文件里的流程框架检查当前项目是否有一份更高优先级的配置覆盖了全局技能目录只要按这个顺序走一遍绝大多数问题都能解决。剩下的少数情况往往不是配置错而是模型对某个技能描述有歧义那就回到修改description这个层面。6.2 模型绕开技能流程时的应对方法模型的自由度有时候是好事有时候却是麻烦。最典型的表现是技能流程明明要求先输出改动计划模型却直接开始改代码。遇到这种情况不用重新开聊天直接在对话里说一句“先暂停代码改动回到技能流程的第几步”。多数时候能立刻纠正。如果想要更保险可以修改技能文件的结构把“等待确认”作为一个明显的阶段步骤同时要求模型每完成一步就暂停。添加这种机制之后模型“绕开流程”的概率会降低很多。本质上这还是在技能文件里下功夫把约束写得越像任务步骤模型越容易遵守。6.3 多AI助手协同让技能成为统一规范现在的开发团队往往不止一个AI助手在工作。有的负责写代码有的负责审查还有的负责文档。技能文件因为是本地Markdown天然可以共享。我们把技能目录纳入Git仓库之后团队里的任何助手只要配置指向这个目录就能使用同一套流程。这种做法最大的收益是减少了不同助手给出的风格不一致问题。以前用Claude Code写的代码和另一个助手写的代码在结构上总有些“性格差异”统一技能后差异明显缩小代码之间更像是同一个程序员写的。这一点在大团队里非常受用因为AI输出的一致性直接影响后续维护成本。6.4 性能和token开销如何控制成本与速度技能文件本质上也是上下文的一部分加载过多肯定会增大token开销。我的建议是不要让全部技能一次性加载尽量在会话中按需。如果发现某次会话特别长并且消耗token很快可以看看是不是同时加载了好几个大技能文件。把技能文件保持在精简格式不必要的背景说明能删就删只在需要时引入。实践下来一次正常开发会话增加的开销在可接受范围内换来的是更少返工整体性价比是高的。最后再分享一个小小的个人习惯我每次打开新会话都会在正式任务前多问一句“你准备用哪个技能流程来做这件事”。别小看这一句它相当于让AI先做一次“流程预演”也是把AI编程从“快”引向“可靠”最关键的一种条件反射。