1. 从“superpowers”这个热词说起它到底是什么最近一段时间技术社区里频繁出现一个词——superpowers。如果你在搜索框里敲下这几个字母会发现关联词清一色是“superpowers 具体使用”“有哪些 skills”“怎么引入这些技能”“想要安装 superpowers”。这组搜索行为本身就说明了一件事大家已经听说过它但真正上手的人还不多绝大多数人卡在“知道有这么个东西却不知道怎么用起来”这一步。我先把结论摆在前面。superpowers 本质上是一套面向 AI 编程助手的能力扩展框架它通过一组可插拔的“技能包”skills来给原本只会聊天、写代码片段的助手装上规划、调试、测试、代码审查、文档生成等一整套工程化能力。你可以把它理解成给一个刚入职的实习生配了一位带教老师外加一整套标准作业流程手册。实习生本身聪明但不知道项目规矩superpowers 就是那套规矩和工具。它解决的问题非常具体AI 助手在真实项目里经常“想当然”。你让它改一个函数它可能顺手把整个文件重写了你让它修 bug它不写测试直接改逻辑你让它做重构它不理解项目约定就乱动结构。superpowers 通过引入结构化的技能把“先理解、再规划、后执行、最后验证”这套工程习惯固化下来让 AI 的输出从“看起来能用”变成“真的能进代码库”。这篇文章适合三类人看。第一类是日常用 AI 助手写代码但总觉得不够稳的开发者你会在这里找到让输出质量上一个台阶的方法。第二类是团队里负责制定 AI 使用规范的技术负责人你可以参考这里的技能组织方式来搭建内部流程。第三类是对 AI 工程化感兴趣的产品和运营同学理解这套机制有助于你判断 AI 能力的边界在哪里。不管你是哪一类接下来的内容都会从“是什么”一路讲到“怎么装、怎么用、怎么避坑”。2. superpowers 的整体设计与思路拆解2.1 为什么是“技能包”而不是“一个大而全的插件”很多人第一次接触 superpowers 时会问为什么不直接做一个功能超全的插件把所有能力塞进去答案藏在软件工程的一个老道理里——单一职责。如果把规划、调试、测试、审查全部耦合在一个模块里任何一处改动都可能影响其他功能维护成本会指数级上升。而技能包的设计让每个 skill 独立存在可以单独启用、单独升级、单独替换。这种设计带来的直接好处是按需加载。你做一个前端项目可能只需要组件设计、样式规范、可访问性检查这几个技能你做一个后端服务可能更关心接口设计、数据库迁移、并发测试。技能包让你只装需要的部分避免无关能力干扰 AI 的判断。我实测下来技能越精简AI 的注意力越集中输出质量反而更稳定。另一个考量是可组合性。技能之间可以形成流水线比如“需求分析”技能输出一份任务拆解“代码实现”技能基于这份拆解写代码“测试生成”技能再基于代码写用例。每个技能只负责自己那一段衔接靠的是标准化的输入输出格式。这种思路和 Unix 管道的哲学是一致的每个工具做好一件事组合起来解决复杂问题。2.2 核心思路把工程习惯翻译成 AI 能执行的指令superpowers 最核心的价值不在于它提供了多少技能而在于它把人类工程师的隐性习惯显性化了。什么叫隐性习惯比如你拿到一个需求不会立刻动手写代码而是先想清楚边界条件、异常路径、依赖关系。这些动作在你脑子里是自动完成的但 AI 不会自动做除非你明确告诉它。superpowers 的每个技能本质上就是一段结构化的提示词加一套执行约束。它告诉 AI在这个阶段你应该先做什么、再做什么、什么情况下必须停下来问、什么情况下可以继续。举个例子“调试”技能会强制 AI 先复现问题、再定位根因、最后才提修复方案而不是一上来就给一段“可能有用”的代码。这个顺序看起来简单但它把“拍脑袋修 bug”这个最常见的坏习惯给堵死了。我在实际使用中最大的感受是superpowers 让 AI 的输出变得可预测。以前你用 AI 助手同样的提示词今天给的结果和明天给的可能差很远。引入技能之后因为执行路径被约束了输出的结构、粒度、甚至风格都趋于一致。这对团队协作特别重要因为可预测意味着可审查、可复用。2.3 方案选型背后的取舍轻量约束 vs 重型框架市面上给 AI 助手做能力扩展的方案大致分两派。一派是重型框架提供完整的项目脚手架、配置文件、依赖管理功能全但上手重另一派是轻量约束只提供提示词模板和执行规则不碰你的项目结构。superpowers 明显属于后者。这个取舍是有道理的。AI 编程助手的使用场景极其分散有人用它写脚本有人用它维护大型单体应用有人用它做数据探索。如果框架强行规定项目结构反而会限制适用范围。轻量约束的好处是侵入性低你可以在任何现有项目里引入不需要重构目录、不需要改构建流程。代价是它不帮你管理依赖和配置这部分工作得你自己做。我个人的判断是如果你追求的是“开箱即用的完整解决方案”superpowers 可能不是最优选但如果你想要的是“在现有工作流里无缝嵌入 AI 能力”它的轻量设计反而是优势。选型这件事没有绝对好坏关键看你的场景和容忍度。3. 核心技能解析与实操要点3.1 有哪些 skills一份实用的技能清单搜索热词里“有哪些 skills”出现频率极高说明大家最关心的就是技能清单。根据我的使用和社区反馈superpowers 的技能大致可以分成几个类别我整理成表格方便对照。技能类别典型技能解决的核心问题适用场景规划类需求拆解、任务分解、方案设计AI 上来就写代码缺乏全局观新功能开发、复杂重构实现类代码生成、组件设计、接口实现输出不符合项目规范日常编码、模块开发验证类测试生成、边界检查、回归验证改完不验证埋下隐患修 bug、改逻辑审查类代码审查、风格检查、安全扫描代码质量参差不齐提交前检查、团队协作文档类注释生成、README 编写、变更记录文档滞后于代码项目维护、交接这张表不是固定不变的技能会随着版本迭代增删。但类别划分相对稳定因为它是按软件开发生命周期的阶段来的。你不需要一次性装齐所有技能按项目阶段选择性引入才是正确姿势。比如项目初期重点装规划类和实现类进入维护期再补上审查类和文档类。3.2 规划类技能让 AI 先想清楚再动手规划类技能是我认为优先级最高的一类。原因很简单AI 最大的问题不是写不出代码而是写之前没想清楚。你给它一个模糊需求它会用最直接的方式实现但最直接的方式往往不是最合适的方式。以“需求拆解”技能为例它要求 AI 在动手前先输出一份任务清单包含每个子任务的输入、输出、依赖和验收标准。这个动作看起来增加了步骤但实际上大幅减少了返工。我做过对比不拆解直接写平均要来回改三四轮先拆解再写通常一到两轮就能定稿。多花的那点时间在返工上全赚回来了。使用规划类技能有个关键点你要给 AI 足够多的上下文。拆解质量高度依赖它对项目的理解程度。如果你只丢一句“帮我加个登录功能”它拆出来的任务会很泛如果你告诉它项目用的框架、现有的认证方式、数据库结构它拆出来的任务就能直接落地。所以我的习惯是在触发规划技能前先把相关文件路径、技术栈、约束条件一次性喂给它。提示规划类技能的输出不要直接当最终方案用它更像是“讨论稿”。你要参与进去对不合理的拆解提出修改AI 会根据你的反馈调整。这个过程本身就是理清需求的好机会。3.3 实现类技能把规范固化进生成过程实现类技能解决的是“输出不符合项目规范”这个老大难问题。每个团队都有自己的代码风格、目录约定、命名习惯AI 默认不知道这些除非你每次都重复交代。实现类技能的做法是把规范写成技能配置一次配置后续每次生成都自动遵守。具体怎么配通常是在技能文件里定义几类规则命名规则比如组件用大驼峰、工具函数用小驼峰、目录规则比如测试文件放在__tests__下、导入规则比如统一用绝对路径。AI 在生成代码前会读取这些规则生成后再自查一遍。我实测下来配置完善的实现类技能能把“风格不符”这类低级问题减少八成以上。这里有个容易踩的坑规则不要定得太细。我见过有人把缩进、空格、换行都写进技能配置结果 AI 为了遵守这些细节反而忽略了业务逻辑。规则应该聚焦在“影响可读性和可维护性”的层面格式问题交给格式化工具去管。技能管的是结构工具管的是样式分工要清楚。3.4 验证类技能改完必须证明改对了验证类技能是我最推荐新手优先引入的一类。因为“改完不验证”是 AI 编程里最危险的坏习惯没有之一。AI 改完一段逻辑会信誓旦旦告诉你“问题已修复”但实际上它可能引入了新问题或者根本没改到点子上。验证类技能强制 AI 在修改后做三件事复现原问题、验证修复效果、检查是否引入回归。复现是为了确认问题真实存在且被正确定位验证是为了确认修复有效回归检查是为了确认没把别的地方搞坏。这三步走完AI 才能说“完成”。我印象很深的一次经历让 AI 修一个边界条件导致的报错它改完说好了。我启用验证技能让它复现结果发现它改的是另一个分支的逻辑原问题根本没碰到。如果没有验证这一步这个 bug 就会带着“已修复”的标签溜进代码库。从那以后我所有涉及逻辑修改的任务都会挂上验证技能。3.5 审查与文档类技能别让技术债悄悄累积审查类技能和文档类技能经常被忽略因为它们是“不紧急但重要”的事。代码能跑谁愿意花时间审查和写文档但技术债就是这么一点点累积起来的。审查类技能的价值在于把审查变成自动动作不需要你额外花意志力去推动。审查技能通常会检查几个维度逻辑正确性、边界处理、错误处理、性能隐患、安全隐患。它不会替代人工审查但能过滤掉大量低级问题让人工审查聚焦在架构和业务层面。文档类技能则负责在代码变更后同步更新注释和说明避免文档和代码脱节。我的建议是审查技能在提交前挂文档技能在合并后挂。提交前审查能拦住问题合并后写文档能保证记录及时。这两个时间点卡准了技术债的增长速度会明显放缓。4. 怎么引入这些技能从安装到跑通的完整流程4.1 安装前的环境准备与检查“想要安装 superpowers”是热词里出现最多的诉求但很多人卡在第一步——环境不对。安装之前你需要确认几件事。第一你的 AI 助手支持技能扩展机制不同助手的扩展方式不一样有的通过配置文件有的通过插件目录。第二你的项目有明确的根目录技能配置通常需要放在项目根目录下的特定位置。第三你有权限修改项目配置如果是团队项目可能需要先和负责人沟通。环境检查我一般用一张清单过一遍助手版本是否支持、项目根目录是否明确、配置文件是否可写、是否有现成的技能配置可参考。这四项确认完再开始安装能避免大部分“装到一半发现不兼容”的尴尬。注意安装前先备份现有的助手配置。技能引入可能会覆盖或修改原有配置备份能让你在出问题时快速回滚。这个习惯我强烈建议养成我吃过没备份的亏重配花了大半天。4.2 引入技能的三种常见方式根据我的实践和社区经验引入技能大致有三种方式各有适用场景。第一种是手动配置。你按照技能文档把技能定义文件放到指定目录然后在主配置里引用。这种方式最灵活适合定制化需求强的场景但步骤多、容易出错。新手如果选这种方式建议一次只引入一个技能跑通再引入下一个。第二种是命令行安装。部分助手提供了包管理式的安装命令一条命令拉取技能包并自动配置。这种方式最省事适合标准技能但可定制性差。我用这种方式装过规划类和验证类技能基本开箱即用没遇到什么问题。第三种是从模板复制。社区里有人分享配置好的技能组合你直接复制到项目里改改就能用。这种方式适合想快速体验的人但要注意模板的版本和你的助手版本是否匹配不匹配可能报错。引入方式上手难度灵活性适合人群手动配置高高有定制需求的老手命令行安装低低想快速体验的新手模板复制中中想省事又要点定制的人4.3 配置文件的写法与关键参数不管你用哪种方式引入最终都会落到配置文件上。配置文件的核心是技能声明和触发条件。技能声明告诉助手“有哪些技能可用”触发条件告诉助手“什么情况下用哪个技能”。一个典型的技能声明包含名称、描述、适用场景、执行约束几个字段。名称要唯一描述要准确适用场景要具体执行约束要明确。我见过有人把描述写得很泛结果助手在该用技能的时候没用不该用的时候乱用。描述写得越具体触发越精准。触发条件通常用关键词或模式匹配来定义。比如“当用户提到 bug、报错、修复时触发调试技能”。这里的关键是关键词要覆盖全面但不过度。覆盖不全该触发时不触发过度覆盖不该触发时乱触发。我的经验是先定义核心关键词跑一段时间后根据实际触发情况增删。4.4 跑通第一个技能的验证方法配置写完不代表能用必须验证。验证方法很简单构造一个该技能应该触发的场景看助手是否按预期执行。比如你配了调试技能就给它一个带 bug 的代码片段看它是否先复现、再定位、后修复。验证时要注意观察三点技能是否被触发、执行步骤是否符合定义、输出格式是否规范。三点都符合说明配置正确有任何一点不符合就要回去检查配置。我一般会准备一组测试用例覆盖正常场景和边界场景每次改配置后都跑一遍确保没改坏。跑通第一个技能后再引入第二个。不要一次性引入多个技能因为技能之间可能有交互一次引入多个出问题很难定位是哪个技能导致的。逐个引入、逐个验证虽然慢一点但稳。5. 实操过程与核心环节实现5.1 一个完整案例用 superpowers 完成一次功能开发光讲概念不够我用一个真实案例把整个流程串一遍。需求是给一个已有的用户管理模块增加“批量导入”功能。这个需求不算复杂但涉及前端上传、后端解析、数据库写入、错误处理几个环节适合展示技能组合的用法。第一步我启用需求拆解技能把需求描述和现有代码结构一起喂给助手。它输出的任务清单包括设计上传接口、实现文件解析、处理数据校验、写入数据库、返回导入结果、前端上传组件。每个任务都标了依赖关系和验收标准。我检查了一遍把“数据校验”拆成了“格式校验”和“业务校验”两个子任务因为这两类校验的错误处理方式不同。第二步启用方案设计技能针对每个任务给出实现方案。这里我特别要求它说明“为什么选这个方案”。比如文件解析它对比了流式解析和一次性加载两种方式考虑到导入文件可能较大推荐流式解析。这个理由站得住脚我就采纳了。第三步启用代码实现技能按方案逐个任务生成代码。因为之前配置了命名和目录规则生成的代码风格和现有项目一致不需要额外调整。每生成一个模块我会快速扫一眼逻辑确认没问题再继续。第四步启用测试生成技能为每个模块生成单元测试。测试覆盖了正常路径和异常路径包括空文件、格式错误、重复数据几种情况。跑一遍测试全绿。第五步启用审查技能对整体代码做一次检查。它指出了两处问题一处是错误信息没有国际化一处是数据库写入没有用事务。这两处我确实疏忽了改完再跑测试通过。整个流程走下来从需求到可提交的代码大概花了两个小时。如果不用技能光是来回沟通和返工可能就要三四个小时。技能的价值不在于让 AI 更聪明而在于让流程更顺。5.2 参数选择与配置调优的实际记录配置技能时有几个参数需要根据项目情况调整我把我的调优记录分享出来。第一个是上下文窗口大小。技能执行时需要读取项目文件作为上下文窗口太小AI 看不到足够信息拆解和实现质量都会下降窗口太大又会引入无关信息干扰判断。我的经验值是规划类技能给大一点让它看到项目全貌实现类技能给小一点聚焦在当前模块。具体数值因助手而异需要实测。第二个是技能触发阈值。有些技能用相似度匹配触发阈值设高了不触发设低了乱触发。我一般从中间值开始跑一周看触发日志该触发没触发的降阈值不该触发触发了的升阈值。这个调优过程大概需要两三轮。第三个是输出详细程度。技能输出太简略信息不够用太详细又显得啰嗦。我的做法是分场景设置规划类输出详细因为要指导后续步骤实现类输出适中重点在代码本身审查类输出简略只列问题和建议。参数作用调优方向我的经验值上下文窗口决定 AI 能看到多少项目信息规划大、实现小规划类拉满实现类减半触发阈值决定技能何时被激活按触发日志微调从中间值起步两三轮调优输出详细度决定技能输出的信息量按技能类型区分规划详、实现中、审查简5.3 技能组合使用的编排技巧单个技能好用组合起来威力更大但组合也有讲究。我的编排原则是按阶段串联按需并联。串联是指技能按执行顺序依次触发前一个的输出作为后一个的输入。比如需求拆解到方案设计到代码实现到测试生成这是一条串联链。串联的关键是保证接口一致前一个技能的输出格式要能被后一个技能正确解析。我一般会在技能配置里统一输出格式避免衔接出问题。并联是指多个技能同时作用于同一份输入各自输出结果最后汇总。比如审查阶段代码审查、风格检查、安全扫描可以同时跑最后把三份报告合并。并联的关键是避免冲突如果两个技能对同一处代码给出矛盾建议需要人工裁决。我的做法是给技能排优先级冲突时以高优先级技能的建议为准。编排不是越复杂越好。我试过把五六个技能串成一条长链结果中间任何一环出问题整条链就断了排查起来很痛苦。后来我改成短链为主、长链为辅每条链不超过三个技能稳定性明显提升。6. 常见问题与排查技巧实录6.1 技能不触发怎么办技能不触发是最常见的问题原因通常有三类。第一类是触发条件没匹配上比如你配的关键词是“修复”但实际输入用的是“改正”匹配不到。解决办法是扩充关键词列表把同义词、近义词都加进去。第二类是技能未正确加载配置文件路径不对或格式有误助手根本没读到技能定义。解决办法是检查配置路径和格式看助手启动日志有没有报错。第三类是优先级冲突多个技能同时匹配助手选了另一个。解决办法是调整优先级或收窄触发条件。排查顺序我建议从外到内先确认配置文件被加载再确认触发条件匹配最后确认优先级。这个顺序能最快定位问题所在。6.2 技能输出不符合预期怎么调技能触发了但输出不是你想要的这种情况也常见。原因可能是技能定义太模糊AI 自由发挥的空间太大也可能是上下文不足AI 缺少做判断所需的信息还可能是约束太严AI 为了遵守约束牺牲了质量。调优方法对应三种原因定义模糊就细化定义把期望的输出结构、粒度、风格写清楚上下文不足就补充信息把相关文件、约束条件、参考示例喂给 AI约束太严就放宽约束把非核心的规则去掉给 AI 留出判断空间。我一般先调定义再调上下文最后调约束因为这个顺序改动成本最低。6.3 多个技能冲突的处理思路技能冲突表现为两个技能对同一问题给出不同甚至矛盾的建议。比如一个技能说用同步处理另一个说用异步处理。冲突的根源通常是技能设计时没有考虑彼此各自按自己的逻辑给建议。处理冲突有三个思路。第一是明确优先级在配置里指定哪个技能优先冲突时以它为准。第二是划分职责边界让每个技能只管自己那一段不越界给建议。第三是人工裁决把冲突点列出来由你判断哪个更合适。我通常先用前两种方法减少冲突剩下的用第三种兜底。完全消除冲突不现实能把冲突控制在可管理范围内就够了。6.4 常见问题速查表问题现象可能原因排查方法解决方向技能不触发条件不匹配/未加载/优先级冲突查配置路径、查触发日志、查优先级扩关键词、修配置、调优先级输出不符合预期定义模糊/上下文不足/约束过严对比期望与实际输出细化定义、补上下文、放宽约束多技能冲突设计未考虑彼此定位冲突点定优先级、划边界、人工裁决执行中断上下文超限/依赖缺失查中断位置和报错缩上下文、补依赖输出格式错乱格式定义不一致检查各技能输出格式统一格式规范6.5 我踩过的坑与独家避坑技巧说几个我实际踩过的坑都是文档里不会写的。第一个坑技能装太多导致启动变慢。我一开始贪多把能找到的技能全装上了结果助手启动要等十几秒每次触发还要在几十个技能里匹配。后来精简到只留常用的五六个启动秒开触发也准了。技能不是越多越好够用就行。第二个坑技能配置和项目配置混在一起。有次我把技能配置写进了项目的主配置文件结果换项目时忘了改导致技能在新项目里乱触发。后来我把技能配置独立成单独文件和项目配置分开管理换项目时只改引用路径清爽多了。第三个坑过度依赖技能导致自己不看代码。有段时间我完全信任技能输出结果一个技能生成的代码有个隐蔽的逻辑错误我没看出来上线后才发现。从那以后我坚持技能输出必须人工过一遍尤其是涉及核心逻辑的部分。技能是辅助不是替代。第四个坑技能版本不匹配。技能更新后配置格式可能变了旧配置直接报错。我的做法是升级技能前先看变更说明确认配置格式有没有变变了就先改配置再升级。这个习惯帮我避免了好几次升级事故。7. 技能体系的扩展与长期维护7.1 自定义技能的编写思路用久了你会发现通用技能不够贴合自己的项目这时候就需要自定义技能。写自定义技能的核心是把你脑子里的隐性流程写出来。比如你们团队有个特殊的发布流程每次发布前要检查五个东西这个流程就可以写成一个技能。写自定义技能的步骤先梳理流程把每一步的输入、动作、输出列清楚再定义触发条件什么情况下该用这个技能然后写执行约束哪些必须做、哪些不能做最后写输出格式保证和其他技能能衔接。写完先小范围试用收集反馈再迭代。我写过一个“发布前检查”技能把团队的五项检查固化进去。以前每次发布都要对着清单手动过现在触发技能自动跑漏检率从偶尔发生降到零。自定义技能的价值在于把团队知识沉淀下来不依赖某个人的记忆。7.2 技能库的版本管理与团队共享技能多了之后管理就成了问题。我的做法是用版本管理工具管技能库每个技能一个文件改动走提交记录。这样谁改了什么、为什么改都有迹可循。团队共享时把技能库作为子模块引入各个项目更新时统一拉取避免各项目技能版本不一致。共享技能库有个原则通用技能放公共库项目专属技能放项目库。公共库放规划、验证、审查这些通用能力项目库放和具体业务相关的技能。这样既保证通用能力统一又给项目留出定制空间。7.3 技能效果的量化评估方法技能有没有用不能凭感觉要量化。我跟踪几个指标返工次数、审查问题数、任务完成时间。引入技能前后各统计一段时间对比变化。我的数据显示引入规划类技能后返工次数下降约六成引入审查类技能后审查问题数下降约四成整体任务完成时间缩短约三成。量化评估的意义在于知道哪些技能真正有用。有些技能看起来很美实际用起来效果一般数据会告诉你真相。我定期做一次评估效果差的技能要么优化要么淘汰保持技能库的精简高效。8. 关于 superpowers 的一些个人体会用了一段时间 superpowers我最大的体会是它改变的不是 AI 的能力上限而是 AI 输出的稳定性下限。AI 本身很聪明但发挥不稳定有时候惊艳有时候离谱。技能的作用是把下限抬起来让输出质量维持在一个可接受的水平之上。对于日常开发来说稳定比惊艳重要得多。另一个体会是技能体系需要和团队工作流磨合。直接照搬别人的技能配置往往水土不服。因为每个团队的规范、习惯、痛点都不一样技能必须根据自己的情况调整。我建议先引入一两个核心技能跑顺了再逐步扩展不要一上来就搞大而全。最后分享一个小技巧定期回顾技能触发日志。日志会告诉你哪些技能经常用、哪些几乎不用、哪些触发了但效果不好。根据日志调整技能库比凭感觉调整靠谱得多。我现在每个月看一次日志每次都能发现可以优化的地方。这个内容后续还可以这样扩展把技能和 CI 流程结合让技能在代码提交时自动跑或者把技能输出接入项目管理工具自动生成任务和文档。这些方向我还在摸索有进展再和大家分享。