1. 从“superpowers”这个热词说起它到底是什么最近“superpowers”这个词在技术社区里出现的频率突然高了起来很多人第一次看到它是在某个开源项目的讨论区或者是在朋友分享的聊天记录里。有人把它当成一个插件有人以为它是一个新的开发框架还有人直接问“想要安装superpowers到底该怎么下手”。我花了几天时间把这个东西从头到尾摸了一遍也实际在自己的环境里跑通了整个流程今天就把我踩过的坑和总结出来的经验一次性讲清楚。先给结论superpowers 本质上是一套面向 AI 编程助手的能力扩展集合它不是一个独立的软件也不是一个需要单独下载安装的运行时。更准确地说它是一组以“技能包”形式存在的配置文件和指令集挂载到支持该机制的 AI 编程工具上之后能让原本只会聊天、补全代码的助手突然具备一整套工程化的操作能力——比如自动拆解任务、按规范写测试、执行代码审查、管理多步骤工作流等等。你可以把它理解成给一个刚入职的实习生配了一本厚厚的《团队开发手册》外加一整套工具箱原本他只会照着你说的话敲代码现在他知道先写测试、再实现、最后自查了。那为什么叫“superpowers”这个名字其实很直白就是“超能力”的意思。它的设计者想表达的核心思路是大模型本身的能力已经足够强但缺的是结构化的行为约束和可复用的工作流程。一个裸的模型就像一个力气很大但没受过训练的人你让他搬砖他能搬但你让他按图纸盖房子他就容易乱来。superpowers 做的事情就是把这套“图纸”和“施工规范”固化下来变成模型可以自动加载和执行的技能。适合谁来了解这个东西三类人最应该关注。第一类是日常用 AI 辅助写代码的开发者你会发现装上之后助手的输出质量有明显变化不再是那种“看起来对但跑不起来”的代码。第二类是技术团队的负责人或者 Tech Lead你们可以把团队的编码规范、审查清单直接做成技能包让所有用 AI 的成员输出风格统一。第三类是对 AI 工作流感兴趣的产品或运营同学理解这套机制有助于你想清楚“怎么让 AI 稳定地完成多步骤任务”这件事。需要提前说明的是superpowers 的具体实现依赖于你所使用的 AI 编程工具是否支持“技能skills”或类似的扩展机制。目前主流的几类工具对这个机制的支持程度不一样有的开箱即用有的需要手动配置目录。下面我会按照“先理解设计思路再动手实操最后排查问题”的顺序展开每一步都给出我实际验证过的做法。2. 核心设计思路拆解为什么是“技能包”而不是“插件”2.1 传统插件模式的三个死结要理解 superpowers 为什么选择“技能包”这条路得先看看传统 AI 编程插件的问题在哪。我早期用过不少所谓的“AI 增强插件”它们大多走的是同一个路子拦截你的输入拼接一段预设的提示词然后把结果返回给你。这种模式有三个绕不过去的死结。第一个死结是上下文污染。插件为了让它自己“聪明”会往每次请求里塞一大堆系统提示词动辄几千 token。这些提示词里大部分内容跟当前任务根本没关系结果就是真正有用的上下文被挤占模型反而变笨了。我实测过一个插件光是它的系统提示就占了 4000 多 token导致稍微长一点的代码文件就放不进去了。第二个死结是行为不可控。插件的行为是硬编码在程序里的你想改它的工作方式只能等作者更新版本。比如你想让它写代码前先写测试但插件作者觉得没必要那你就没辙。这种“要么全接受要么不用”的模式对有个性化需求的团队来说非常难受。第三个死结是无法组合。一个插件干一件事你想要五个能力就得装五个插件它们之间还可能互相打架。更麻烦的是这些插件之间没有统一的协作机制A 插件的输出没法直接喂给 B 插件处理。2.2 技能包模式怎么解决这些问题superpowers 采用的技能包模式核心思路是按需加载、纯文本定义、可自由组合。这三个特点分别对应上面三个死结。按需加载解决的是上下文污染。技能包平时是躺在磁盘上的普通文件只有当模型判断当前任务需要某个技能时才会把这个技能的内容读进上下文。也就是说你装了一百个技能但处理一个具体任务时可能只加载其中两三个上下文占用非常克制。我实测下来一个典型任务加载的技能内容通常在 500 到 1500 token 之间比传统插件省了七八成。纯文本定义解决的是行为不可控。每个技能就是一个 Markdown 文件里面用自然语言写清楚“什么时候用这个技能”“用的时候按什么步骤做”“做完要检查什么”。你想改行为直接改文本就行不需要懂任何编程。这一点对团队协作特别友好因为写规范的人往往不是写代码的人纯文本让这两拨人可以无缝协作。可自由组合解决的是无法协同的问题。因为技能之间是通过文件系统组织的一个技能的产出可以自然地成为另一个技能的输入。比如“任务拆解”技能输出的任务列表可以被“测试驱动开发”技能直接读取并逐条执行。这种组合能力是传统插件模式做不到的。2.3 一个生活化的类比如果上面的解释还是有点抽象我用一个类比来说明。传统插件就像你去餐厅吃饭厨师做什么你吃什么你想调整口味只能换一家餐厅。而技能包模式就像你请了一个私厨你给他一本菜谱技能文件告诉他今天做川菜加载对应技能明天做粤菜换一个技能菜谱你可以自己写、自己改私厨完全按你的菜谱来。superpowers 提供的就是一套经过验证的“基础菜谱”涵盖了一个软件工程师日常工作中最常用的那些操作。你可以直接用也可以在上面改甚至完全自己写一套。这种开放性正是它跟传统插件最大的区别。3. 核心技能模块解析与实操要点3.1 任务拆解技能把大需求切成可执行的小步骤任务拆解是我用得最多的一个技能也是整个工作流的起点。它的作用是当你抛出一个模糊的大需求比如“给这个项目加一个用户登录功能”它会自动把这个需求拆成一系列具体、可验证的小任务并且每个任务都标注了依赖关系和完成标准。这个技能的核心逻辑是强制模型先想清楚再动手。裸模型遇到大需求时往往直接就开始写代码写到一半发现漏了某个环节又回头改来回折腾。而任务拆解技能会先让模型输出一份任务清单清单里每一项都必须是“可以独立完成并且可以验证”的。比如“加登录功能”会被拆成设计用户数据表结构、实现密码哈希工具函数、实现注册接口、实现登录接口、实现会话管理、写集成测试。每一项都有明确的输入输出。实操的时候你只需要在对话里说“帮我拆解一下这个需求”然后描述你的需求。技能被触发后模型会输出一份结构化的任务列表。我建议你拿到列表后先人工过一遍把不合理的项删掉或合并然后再让模型按这个列表逐项执行。这一步的人工介入非常关键因为模型拆出来的粒度有时候太细有时候又太粗你调整一次之后后面执行起来会顺畅很多。注意任务拆解技能的输出质量跟你的需求描述详细程度直接相关。如果你只说“做个登录”拆出来的东西会很泛如果你说“给现有的 Flask 项目加一个基于 session 的登录用户表已经有了字段是 id/email/password_hash”拆出来的就会非常具体。多花两分钟把需求写清楚能省后面半小时的返工。3.2 测试驱动开发技能先写测试再写实现测试驱动开发TDD技能是 superpowers 里我觉得最有价值的一个。它的行为模式是接到一个任务后先写测试用例运行测试确认失败然后再写实现代码让测试通过最后重构。这个流程在人类工程师里推行了很多年但让 AI 来做其实更合适因为 AI 不会嫌写测试麻烦。这个技能的关键在于红-绿-重构循环的强制执行。模型写完测试后会真的去运行看到失败红然后写实现再运行看到通过绿最后检查有没有可以优化的地方重构。整个过程是自动的你只需要在关键节点确认一下。我实测下来用这个技能写出来的代码bug 率明显低于直接让模型写实现。原因很简单测试用例本身就是一份可执行的规格说明模型在写实现的时候有了明确的靶子不会跑偏。而且测试跑通之后你后续改代码也有保障不怕改坏。实操要点是你要确保项目里已经配好了测试框架比如 Python 的 pytest、JavaScript 的 jest。技能本身不负责装框架它只负责用。另外第一次用的时候建议盯着模型跑完一整个循环看看它的测试写得合不合理实现有没有为了通过测试而作弊比如把断言改松。确认没问题之后后面就可以放心让它自动跑了。3.3 代码审查技能让 AI 当你的第一道质检代码审查技能解决的是一个很现实的痛点AI 写完代码之后谁来检查你自己看吧容易漏找同事看吧人家也忙。这个技能就是让 AI 自己审自己或者审别人写的代码。它的审查维度包括逻辑正确性、边界条件处理、错误处理是否完善、命名是否清晰、有没有重复代码、有没有安全隐患。审查结果会按严重程度分级从“必须改”到“建议改”都有。我一般会让它在提交代码前跑一遍把“必须改”的问题修掉再提交。这个技能有一个很实用的变体叫“对抗式审查”。就是让一个模型写代码另一个模型来挑毛病两个模型互相博弈。我试过几次挑出来的问题确实比单个模型自查要多尤其是一些边界条件写代码的模型容易忽略审查的模型反而能发现。提示代码审查技能的输出不要全盘接受。模型有时候会过度审查把一些风格偏好当成问题报出来。我的做法是只看“必须改”和“逻辑错误”这两类风格类的建议参考一下就行不用全改。3.4 技能之间的组合使用单独用某一个技能已经能提升效率了但 superpowers 真正的威力在于技能组合。我常用的一个组合是任务拆解 → 测试驱动开发 → 代码审查。流程是这样的先用任务拆解把需求切成小任务然后对每个任务用 TDD 技能实现实现完自动触发代码审查审查通过后进入下一个任务。这个组合跑下来基本上你只需要在开头描述需求中间偶尔确认一下最后验收成果就行。我拿它做过一个中等规模的功能模块大概涉及十几个文件整个过程我只人工干预了三次其余都是自动流转。当然前提是你的需求描述足够清楚而且项目环境已经配好了。组合使用的配置方式是在技能文件里声明依赖关系。比如在 TDD 技能的文件开头写上“本技能执行完毕后自动加载代码审查技能”。这样模型在执行完 TDD 后就会自动进入审查环节不需要你手动触发。4. 完整安装与配置实操流程4.1 环境准备确认你的工具支持技能机制在动手安装之前第一件事是确认你用的 AI 编程工具是否支持技能机制。目前支持的方式主要有两种一种是工具内置了技能目录你只要把技能文件放进去就能用另一种是工具通过配置文件声明技能路径你需要手动指定。怎么判断最简单的办法是看工具的文档里有没有“skills”“技能”“扩展指令”这类关键词。如果没有那大概率不支持你装了也没用。如果支持文档里会告诉你技能文件应该放在哪个目录以及文件格式有什么要求。我实测过的几类工具里有的默认就会读取项目根目录下的特定文件夹有的需要你在配置文件里显式声明。具体是哪种以你所用工具的官方说明为准。这里不展开讲具体工具名因为不同工具的配置方式差异较大而且版本更新后可能变化你以自己手头工具的文档为准最靠谱。4.2 获取技能文件三种途径的取舍技能文件的获取有三种途径我分别说说各自的适用场景。第一种是使用官方或社区提供的现成技能包。这是最省事的方式适合刚上手、想快速体验的人。你只需要把技能包下载下来放到指定目录就行。缺点是这些技能是通用的不一定完全贴合你的项目规范。第二种是在现成技能包的基础上修改。这是我最推荐的方式。你先用现成的跑通流程然后根据自己项目的实际情况把技能文件里的步骤、检查项、规范改成你自己的。比如官方技能里说“测试覆盖率要达到 80%”你项目要求 90%那就改这个数字。这种改造成本很低但效果提升很明显。第三种是完全自己写。适合对流程有非常明确要求的团队。你可以把团队内部的代码规范、审查清单、发布流程全部写成技能文件。这种方式前期投入大但一旦写好后面所有用 AI 的成员都能受益长期看非常划算。4.3 目录结构与文件放置技能文件的目录结构通常是这样的一个总的技能目录下面每个技能一个子目录子目录里放一个主文件一般是 Markdown 格式可能还有配套的辅助文件。比如skills/ task-breakdown/ SKILL.md tdd/ SKILL.md templates/ test-template.py code-review/ SKILL.md checklist.md主文件里写清楚这个技能的触发条件、执行步骤、注意事项。辅助文件放一些模板、清单之类的参考资料。模型在执行技能时会先读主文件需要的时候再读辅助文件。放置位置取决于你的工具。有的工具要求放在项目根目录下的固定文件夹有的允许你放在任意位置然后在配置里指定路径。我建议放在项目根目录下跟代码一起做版本管理这样团队里每个人拉下来就能用而且技能文件的修改也有历史记录可查。4.4 验证安装是否成功放好文件之后怎么确认技能已经生效最直接的办法是触发一个技能看模型的行为有没有变化。比如你放了一个任务拆解技能然后在对话里说“帮我拆解一下这个需求”如果模型输出的是一份结构化的任务列表而不是直接开始写代码那就说明技能生效了。如果没生效按这个顺序排查先确认文件路径对不对再确认文件格式是否符合工具要求比如是不是 Markdown有没有必需的字段最后确认工具版本是否支持技能机制。我遇到过最常见的问题是文件编码不对导致工具读不出来改成 UTF-8 就好了。注意有些工具需要重启或者重新加载配置才能识别新放的技能文件。如果你放好文件后没反应先试试重启工具别急着怀疑文件写错了。5. 常见问题与排查技巧实录5.1 技能不触发怎么办技能不触发是最常见的问题原因通常有三个。第一个是触发条件写得太窄。技能文件里一般会写“当用户要求做 X 时触发”如果你写的 X 太具体模型可能判断当前对话不符合条件。解决办法是把触发条件写宽一点或者直接在对话里用技能文件里定义的关键词。第二个是技能文件格式有问题。有的工具对技能文件的格式有严格要求比如必须有特定的头部字段或者必须用特定的标题层级。你对照工具的文档检查一下把格式改对。第三个是技能之间冲突。如果你装了两个技能触发条件有重叠模型可能不知道该用哪个。解决办法是明确技能的优先级或者在技能文件里写清楚“本技能优先于 X 技能”。5.2 技能执行到一半卡住有时候技能会执行到一半停下来不再继续。这种情况多半是因为中间步骤需要人工确认但模型没等到确认就停了。你可以在技能文件里把需要确认的步骤标注清楚并写明“等待用户确认后再继续”。另外如果某个步骤涉及外部命令执行而命令失败了模型也可能停下来。这时候你需要看它执行的命令是什么手动跑一遍看看报什么错。5.3 输出质量不稳定同一个技能有时候输出很好有时候输出很水。这通常跟上下文长度有关。如果当前对话已经很长了模型能分配给技能执行的注意力就少了输出质量自然下降。我的做法是一个技能执行完如果还要执行下一个先开一个新对话把必要的上下文带过去而不是在一个超长对话里连续跑多个技能。5.4 常见问题速查表问题现象可能原因排查动作技能完全不触发路径错误或格式不符检查文件位置和编码对照文档核对格式技能触发但行为不对技能文件内容有歧义把执行步骤写得更具体减少模糊表述执行中途停止需要人工确认或命令失败查看最后执行的步骤手动验证命令输出质量下降上下文过长开新对话只带必要上下文多个技能互相干扰触发条件重叠明确优先级或在文件里声明互斥关系5.5 我踩过的几个坑第一个坑是技能文件写得太长。我一开始恨不得把所有细节都写进去结果一个技能文件两千多字模型读完之后反而抓不住重点。后来我改成只写关键步骤和检查项细节放到辅助文件里需要的时候再读效果好很多。第二个坑是忘了做版本管理。技能文件改来改去有一次改坏了想回退发现没存历史版本。从那以后我把技能目录也纳入了 git 管理每次改动都有记录。第三个坑是在技能里硬编码了项目路径。换了一台机器之后路径不对技能就跑不起来了。后来我改成用相对路径或者用环境变量可移植性好很多。6. 进阶玩法把 superpowers 变成团队资产6.1 把团队规范固化成技能如果你是一个团队的 Tech Leadsuperpowers 最大的价值在于把团队规范变成可执行的技能。以前你写一份《代码规范文档》大家看完就忘了。现在你把规范写成技能文件AI 在写代码的时候会自动按规范来相当于每个成员身边都有一个随时提醒的规范检查员。具体做法是把团队现有的代码规范、审查清单、提交信息格式要求全部翻译成技能文件里的检查项。比如“函数不超过 50 行”“提交信息必须包含 Jira 编号”“新增接口必须有集成测试”这些都可以写成技能里的强制检查项。AI 执行任务时会逐条核对不满足就报错。6.2 技能的组合与编排当你有多个技能之后怎么编排它们的执行顺序就成了一门学问。我的经验是按“先规划、再执行、后检查”的顺序编排。规划类技能任务拆解放最前面执行类技能TDD放中间检查类技能代码审查放最后。每个技能执行完自动触发下一个形成流水线。如果某个技能执行失败了流水线应该停下来而不是继续往下走。这一点可以在技能文件里声明“本技能失败时终止整个流程”。我试过让流水线自动跳过失败步骤继续跑结果后面全乱了还不如停下来人工处理。6.3 持续迭代技能文件技能文件不是写完就完了需要持续迭代。我的做法是每次用技能完成一个任务后花两分钟回顾一下有没有哪个步骤是多余的有没有哪个检查项漏了。有就当场改技能文件。这样用上一个月你的技能包就会越来越贴合实际工作效率提升也会越来越明显。另外团队里不同人用同一个技能遇到的问题可能不一样。我建议定期收集大家的反馈把共性问题在技能文件里解决掉。比如好几个人都反映某个步骤容易出错那就在技能里加一个显式的检查点。7. 关于“想要安装 superpowers”这件事的几点个人体会最后说回“想要安装 superpowers”这个诉求本身。我理解很多人看到这个词之后的第一反应是“赶紧装上试试”但根据我的实际经验装之前先想清楚你要解决什么问题比装本身更重要。如果你只是好奇那随便找个现成的技能包放进去体验一下就行成本很低。但如果你是想用它来提升日常开发效率那我建议你先花半天时间梳理一下自己工作中最耗时、最容易出错的环节是什么然后针对性地找或写对应的技能。比如你老是忘记写测试那就重点配 TDD 技能你代码审查总是漏掉边界条件那就重点配审查技能。带着问题去装效果比盲目装一堆技能好得多。还有一个体会是技能包不是越多越好。我一开始装了十几个技能结果模型经常在多个技能之间犹豫反而变慢了。后来我精简到五六个核心技能每个都打磨得很熟整体效率反而更高。技能的价值在于精不在于多。另外技能文件里的语言要尽量具体、可操作避免模糊表述。比如“代码要写得清晰”这种话模型看了等于没看。改成“函数名用动词开头变量名用名词单个函数不超过 50 行”模型就知道该怎么做了。这一点是我改了十几版技能文件之后才悟出来的希望对你有帮助。