1. 从“superpowers”这个热词说起它到底是什么最近一段时间“superpowers”这个词在技术社区和效率工具圈子里被反复提起很多人第一次看到它是在某个开源项目的讨论区或者是在朋友转发的一条“我给我的编辑器装上了 superpowers”的动态里。紧接着就有人问“superpowers 怎么安装”“想要安装 superpowers 需要什么前置条件”。我一开始也以为这又是一个营销味很重的概念包装直到我自己动手把它跑起来、用了一段时间之后才意识到它解决的其实是一个非常具体、非常痛的问题如何让一个通用的 AI 编程助手真正具备某个特定项目、特定团队、特定技术栈所需要的“超能力”。说白了superpowers 不是某个单一的软件而是一套围绕 AI 辅助开发的能力扩展机制。它的核心思路是模型本身的能力是通用的、泛化的但你在实际写代码时需要的往往是高度场景化的能力——比如“读懂我们这个项目的目录约定”“按照我们的代码规范生成组件”“在提交前自动跑一遍我们的检查清单”。这些能力如果每次都靠临时写提示词去凑效率极低而且不稳定。superpowers 做的事情就是把这些场景化能力沉淀成可复用、可组合、可安装的模块让 AI 助手从“什么都会一点”变成“在你这个项目里特别能打”。这篇文章适合几类人看第一类是已经在用 AI 辅助写代码、但总觉得“差口气”的开发者第二类是团队里负责工程效率、想统一 AI 使用方式的技术负责人第三类是对这类能力扩展机制好奇、想搞清楚它底层怎么运作的技术爱好者。不管你之前有没有接触过类似的东西我都会从设计思路讲到实操步骤再到踩过的坑尽量让你看完就能自己动手装一遍、配一遍。需要先说明一点superpowers 这类机制目前在不同工具链上的具体实现差异很大有的以插件形式存在有的以配置目录加脚本的形式存在还有的干脆就是一套约定俗成的文件结构。我下面讲的内容是基于这类机制最常见的实践形态来展开的如果你用的具体工具在细节上和我描述的不完全一致思路是通用的照着迁移即可。2. 为什么需要 superpowers通用助手的三个天花板2.1 通用能力在具体项目里为什么会失灵我先讲一个我自己踩过的真实场景。之前我在一个前端项目里让 AI 帮我写一个表单组件它给我的代码本身没毛病但问题一大堆它用了我们项目里根本没装的 UI 库命名风格和我们现有的组件完全不一致目录放错了位置甚至连 import 路径的别名都没用我们配置的。我每次都要花大量时间把这些“通用正确但项目错误”的代码改回来。这就是通用能力的第一个天花板它不知道你的项目上下文。第二个天花板是它不记得你的偏好。你这次告诉它“不要用 any 类型”下次开新对话它又忘了。你反复强调的规范在它那里是一次性的不会沉淀。第三个天花板是它不会主动执行你的流程。比如你们团队规定提交前必须跑 lint、必须更新 changelog、必须检查某个配置文件这些流程 AI 不会自动帮你做它只负责生成代码剩下的全靠你手动补。superpowers 要解决的恰恰就是这三个天花板。它通过把“项目上下文”“个人偏好”“团队流程”这三类信息结构化、模块化让 AI 助手在每次工作时都能加载到正确的“能力包”从而表现得像是专门为你的项目训练过一样。2.2 能力扩展机制和普通提示词的本质区别很多人会问那我直接把要求写进系统提示词不就行了为什么要搞一套 superpowers这个问题问得好我一开始也是这么想的。但实际用下来区别非常明显。普通提示词是扁平的、全量的。你把所有要求堆在一段文字里每次对话都全量加载。项目小的时候还行一旦规范多了、场景多了提示词会变得又长又乱模型反而抓不住重点而且维护起来极其痛苦——改一条规范要在几百行文字里找。superpowers 式的机制是分层的、按需的。它把能力拆成一个个独立的模块每个模块负责一类事情比如“代码风格”“目录约定”“提交流程”“测试规范”。AI 在具体任务中只加载相关的那几个模块既精准又高效。更重要的是这些模块可以版本化管理、可以团队共享、可以按项目覆盖。这就像你家里的工具箱普通提示词是把所有工具倒在一个大袋子里每次用都得翻半天superpowers 是给你一个分层的工具箱用哪个拿哪个还能给不同房间配不同的工具箱。2.3 哪些人最该考虑上手不是所有人都需要 superpowers。如果你只是偶尔让 AI 帮你写个正则、解释段报错那完全没必要折腾。但如果你符合下面几种情况投入时间配置它是非常划算的每天有大量代码是 AI 辅助生成的团队里多人共用 AI 工具但输出风格五花八门项目有比较严格的规范和流程你希望把个人的使用经验沉淀下来而不是每次重新解释。我个人的判断标准是如果你每周花在“纠正 AI 输出”上的时间超过一小时那就值得配置。3. 核心设计思路拆解superpowers 是怎么组织的3.1 能力模块化的基本结构superpowers 最核心的设计思想就是“一切皆模块”。一个能力模块通常包含几个部分一段描述这个能力做什么的元信息、一段注入给 AI 的指令内容、以及可选的辅助资源比如模板文件、检查脚本、示例代码。元信息负责让系统知道“这个模块叫什么、什么时候该用它”指令内容负责告诉 AI“具体怎么做”辅助资源负责给 AI 提供可参考的素材。这种结构和我们熟悉的软件包管理很像。你可以把每个能力模块理解成一个 npm 包或者 pip 包它有名字、有版本、有依赖、有入口。安装 superpowers 的过程本质上就是把这些包放到正确的位置让 AI 工具在运行时能发现并加载它们。理解了这一点后面所有的安装和配置操作都会变得顺理成章。3.2 加载机制什么时候用哪个能力模块化之后紧接着的问题就是AI 怎么知道当前该加载哪些模块常见的做法有两种。一种是基于触发条件每个模块声明自己在什么情况下生效比如“当任务涉及创建新组件时”“当用户提到提交代码时”。另一种是基于显式引用你在对话里主动说“用 XX 能力来做这件事”系统就去加载对应模块。实际产品里往往是两者结合。我实测下来触发条件式的体验更顺滑因为它不需要你每次都记得模块名字但前提是触发条件写得足够准否则会出现“该加载的没加载”或者“加载了一堆不相关的”。显式引用式更可控适合对精度要求高的场景。你在配置自己的模块时建议先想清楚这个模块是“自动触发”还是“手动调用”这直接决定了它的元信息怎么写。3.3 优先级与覆盖项目规范和个人偏好的冲突处理一个绕不开的问题是如果团队规范说“用双引号”但我个人偏好单引号听谁的superpowers 这类机制通常有一套优先级规则常见的是“项目级覆盖团队级团队级覆盖个人级个人级覆盖默认级”。也就是说越贴近具体项目的配置优先级越高。这个设计非常合理因为项目规范是硬约束个人偏好是软约束。我在配置的时候会把“绝对不能违反的”放在项目级把“我个人的小习惯”放在个人级这样既保证了代码符合团队要求又保留了自己的舒适区。理解优先级规则还有一个好处当 AI 的输出不符合预期时你可以快速定位是哪一层的配置在起作用排查效率高很多。4. 安装前的准备工作别急着敲命令4.1 确认你的工具链是否支持在动手之前第一件事是确认你正在用的 AI 工具是否支持这类能力扩展机制。不同工具的扩展方式差别很大有的原生支持插件目录有的需要通过配置文件挂载还有的只支持在特定模式下加载外部指令。你需要去查一下你所用工具的官方文档确认它有没有“自定义指令”“能力扩展”“插件系统”这类功能。如果完全不支持也不是没办法退而求其次可以用“外部文件加手动引用”的方式把能力模块写成独立的文档文件在对话开始时手动粘贴进去。这种方式体验差一些但胜在通用任何工具都能用。我早期就是这么干的虽然麻烦但确实能明显提升输出质量。4.2 环境依赖与版本要求确认支持之后接下来要检查环境依赖。常见的依赖包括工具本身的版本要达到某个最低要求老版本可能没有扩展接口、运行时环境比如某些机制依赖 Node 或 Python 来执行辅助脚本、以及文件系统权限要能读写配置目录。我遇到过最坑的一次是工具版本太老扩展接口的行为和新版不一致导致模块加载了但没生效排查了半天才发现是版本问题。提示安装前务必记录下你当前工具的版本号一旦出问题可以快速回退对比。很多人忽略这一步结果出问题时连“之前是什么状态”都说不清。4.3 目录规划把能力放在哪里目录规划是很多人会忽略但非常重要的一步。你需要决定能力模块放在哪个目录下是全局共享还是项目独有。我的建议是分两层全局目录放那些跨项目通用的能力比如通用的代码风格、通用的提交规范项目目录放这个项目特有的能力比如这个项目的目录结构约定、这个项目用的特定框架规范。这样分的好处是换项目时全局能力自动可用项目能力跟着项目走不会互相污染。具体目录名各工具有各工具的约定你按官方推荐来就行不要自己乱起名字否则工具可能发现不了。我见过有人把模块放在一个自认为“更合理”的目录里结果工具死活加载不到白白浪费一下午。5. 实操安装全流程一步步把 superpowers 跑起来5.1 第一步获取能力模块安装的第一步是拿到你想要的能力模块。来源通常有三种官方或社区提供的现成模块、团队内部沉淀的私有模块、以及你自己从零写的模块。新手建议先从现成的开始跑通流程之后再尝试自己写。获取方式一般是下载或者克隆对应的模块仓库然后放到你规划好的目录里。这里有个细节要注意模块的目录结构必须符合工具的约定不能多一层也不能少一层。我建议拿到模块后先看一眼它的目录结构和官方文档里的示例对比一下确认无误再放进去。很多“装了没反应”的问题根源就是目录层级放错了。5.2 第二步配置加载入口模块放好之后需要配置加载入口告诉工具“去哪个目录找能力模块”。这一步通常是在工具的配置文件里加一段配置指定模块目录的路径。配置格式各工具不同有的是 JSON有的是 YAML有的直接在设置界面里填。配置的时候要特别注意路径的写法绝对路径最稳妥相对路径容易因为工作目录变化而失效。我踩过的坑就是用相对路径在项目根目录下运行没问题一旦在子目录里运行就找不到模块了。改成绝对路径之后世界清净了。另外如果你配置了多个模块目录注意它们的加载顺序顺序会影响优先级。5.3 第三步验证是否生效配置完不要急着用先做一次验证。验证方法很简单开一个新对话问 AI 一个只有加载了你的能力模块才能正确回答的问题。比如你的模块里规定了“所有组件必须放在 src/components 下”你就问它“新建一个按钮组件应该放在哪”如果它答对了说明模块生效了如果它答的还是通用答案说明没加载成功。验证这一步千万别省。我见过太多人配置完直接就开始用结果用了一周才发现模块根本没生效一直在用通用能力干活白白浪费了时间。验证通过之后再开始正式使用心里才踏实。5.4 第四步按需增删和迭代跑通之后你会发现有些模块用不上有些模块需要调整。这时候就进入迭代阶段。增删模块很简单把目录加进去或删掉然后重新验证即可。调整模块内容则需要改模块里的指令文本改完同样要验证。我的经验是不要一次性配置太多模块。新手容易贪多把能找到的模块全装上结果加载了一堆互相冲突的指令AI 反而无所适从。建议从三到五个最核心的模块开始用顺了再逐步增加。每次只加一个加完验证这样出问题也容易定位。6. 常见问题与排查技巧实录6.1 装了但没生效排查顺序很重要“装了没生效”是最高频的问题。我的排查顺序是这样的先确认模块目录路径配置对不对再看模块目录结构符不符合约定然后看模块的元信息格式有没有写错最后看工具版本是否支持。这四步能覆盖九成以上的问题。其中最容易出错的是元信息格式。很多模块对元信息的字段名、缩进、引号都有严格要求少一个逗号或者多一个空格都可能导致解析失败。我建议改完元信息后用工具自带的校验功能跑一遍或者找个在线的格式校验器检查一下能省很多事。6.2 模块之间打架冲突的识别与解决当你装了多个模块可能会遇到指令冲突。比如模块 A 说“用分号”模块 B 说“不用分号”AI 就懵了。识别冲突的方法是观察 AI 的输出是否在不同对话里表现不一致或者在同一对话里前后矛盾。如果出现这种情况大概率是模块冲突。解决办法有两个一是调整优先级让更重要的模块覆盖次要的二是合并冲突的模块把矛盾的指令统一成一条。我倾向于后者因为长期来看模块越少越清晰维护成本越低。与其让两个模块打架不如把它们合并成一个职责明确的模块。6.3 性能问题模块太多会不会拖慢响应有人担心装太多模块会拖慢 AI 的响应速度。实测下来只要模块是“按需加载”的影响非常小因为每次只加载相关的那几个。但如果你的工具是“全量加载”模式那模块多了确实会变慢因为每次都要把所有指令塞进上下文。判断你的工具是哪种模式很简单装十个模块看响应时间有没有明显变化。如果明显变慢说明是全量加载这时候就要控制模块数量或者把不常用的模块改成手动调用。我个人的做法是保持自动加载的模块在十个以内超出的都改成手动触发。6.4 常见问题速查表问题现象可能原因排查方法解决方式模块完全不生效路径配置错误检查配置文件里的目录路径改成绝对路径部分模块生效部分不生效目录结构不符约定对比官方示例的目录层级调整目录结构加载报错元信息格式错误用格式校验工具检查修正字段名和缩进输出前后矛盾模块指令冲突逐个禁用模块定位合并或调整优先级响应明显变慢全量加载模式增减模块观察响应时间控制数量或改手动调用换项目后失效用了项目级配置检查配置作用范围通用能力放全局目录7. 我个人的实操心得与进阶玩法7.1 从“抄”到“写”模块的渐进式积累我刚开始用的时候全是拿现成的模块用着用着发现有些地方不顺手就开始改。改着改着就摸清了模块的写法开始自己写。这个过程我强烈推荐给每个人先抄再改最后写。直接上手写模块很容易因为不熟悉约定而写出无效的模块挫败感很强。自己写模块的时候有个小技巧把你平时反复对 AI 强调的那些话记下来它们就是最好的模块素材。比如你总是说“记得加错误处理”“记得写注释”“不要用某个库”把这些整理成模块以后就不用反复说了。我现在的模块库里有一半都是从我的“口头禅”里提炼出来的。7.2 团队协作把 superpowers 变成团队资产superpowers 最大的价值其实在团队场景。当团队把规范沉淀成模块新人的 AI 助手一装上就自动符合团队规范省去了大量口头培训和代码 review 的来回。我们团队现在的做法是把核心规范做成一个共享模块库放在内部仓库里每个人配置时指向这个仓库规范更新时所有人自动同步。这里有个经验团队模块要有人维护不能建完就不管。我们指定了一个人负责定期 review 和更新模块确保它跟得上项目的变化。没有维护的模块很快就会变成过时的负担反而误导 AI。7.3 后续可以怎么扩展跑通基础用法之后可以往几个方向扩展。一是把模块和 CI 流程结合让 AI 生成的代码自动过一遍检查二是给模块加上示例代码让 AI 有更具体的参考三是做模块的版本管理不同项目锁定不同版本避免升级带来的意外。这些都属于进阶玩法等你把基础用顺了再考虑。我个人在实际操作中的体会是superpowers 这类机制的价值不在于它有多复杂而在于它逼着你把脑子里那些模糊的“我觉得应该这样”变成明确的、可执行的规则。这个过程本身就是一次对项目规范的梳理哪怕 AI 一点忙都帮不上光是这份梳理出来的规范文档就已经值回票价了。最后再分享一个小技巧每次你觉得 AI 输出不对的时候别急着改代码先想想“这个错误能不能变成一条模块指令”能的话就加进去。坚持一个月你会发现需要纠正的次数越来越少。