1. 从“superpowers”这个热词说起它到底指什么第一次看到“superpowers”这个词挂在热搜上我下意识以为是某部新出的超英电影点进去才发现讨论的是一套围绕 AI 编程助手扩展出来的能力增强方案。圈子里最近聊得火热的superpowers、codex superpowers、superpowers 使用指南本质上都指向同一件事给原本只会“你问我答”的 AI 编码工具装上一套可复用、可组合、可沉淀的“技能包”让它从单次对话的临时工变成能记住流程、按套路干活的长期搭档。我先把结论摆在前面免得你被各种名词绕晕。superpowers不是某个具体的编程语言也不是一个独立的软件产品它更像是一套面向 AI 编码代理coding agent的技能组织范式。你可以把它理解成给 AI 助手准备的一个“工具箱 操作手册”工具箱里放着一堆预先写好的技能文件操作手册规定了 AI 在什么场景下该翻哪一页、按什么顺序执行。superpowers java这类搜索词说明很多人关心的是它在 Java 这类具体技术栈里怎么落地而superpowers 安装、superpowers 使用教程则反映出大家最迫切的需求——怎么把它跑起来、怎么用顺手。这篇文章适合三类人看。第一类是已经在用 AI 辅助写代码、但总觉得“每次都要重新解释一遍需求”的开发者第二类是团队里负责搭建研发工具链、想让 AI 能力在团队内标准化的技术负责人第三类是对 AI 代理机制好奇、想搞明白“技能包”这套东西底层怎么运转的技术爱好者。不管你是哪一类我都会从概念、原理、安装、实操到踩坑一层层拆开讲尽量让你看完就能上手。需要提前说明的是superpowers这套东西目前主要围绕命令行环境下的 AI 编码代理展开它的核心载体是结构化的技能文件通常以 Markdown 或类似的纯文本格式存在。这意味着它天然跨语言、跨平台Java、Python、Go 都能用区别只在于你往技能包里塞什么内容。理解了这一点后面所有的操作都会顺理成章。2. 拆开“技能包”看本质superpowers 的运转逻辑2.1 为什么单靠对话式 AI 写代码总差点意思我先讲个自己的真实经历。早些年我用 AI 辅助写一个数据同步模块第一轮对话我把需求讲得很清楚AI 给的代码质量不错。可到了第二天继续做我新开一个会话又得把项目背景、代码规范、数据库表结构重新描述一遍。更麻烦的是AI 每次给的实现风格都不太一样有的用工具类封装有的直接内联最后代码库看起来像好几个人拼出来的。这个问题的根源在于普通对话式 AI 是无状态的。它不记得你昨天说过什么也不记得你们团队约定俗成的编码规范。你每次都在跟一个“失忆的天才”合作他能力很强但每次都要从头熟悉环境。superpowers要解决的就是这个“失忆”问题——它把那些反复要讲的东西固化成 AI 可以主动读取和调用的技能文件。打个比方。普通 AI 助手像一个临时请来的外包你每次都得写一份详细的需求文档给他。而装了superpowers的 AI 助手更像一个入职很久的老员工他知道公司有哪些内部工具、代码提交前要跑哪些检查、遇到某类问题该找谁。这些“知道”就藏在技能包里。2.2 技能文件里到底装了什么一个典型的技能文件结构上通常包含几个部分触发条件、操作步骤、注意事项、参考示例。触发条件告诉 AI“什么情况下该用这个技能”操作步骤是“具体怎么做”注意事项是“别踩哪些坑”参考示例则是“照着这个格式来”。我拿一个“新建 Java 实体类”的技能举例。触发条件可能是“当用户要求创建数据库实体类时”。操作步骤会写明先确认表名和字段再按项目规范生成类名字段用驼峰命名主键统一叫 id时间字段统一用 LocalDateTime。注意事项会提醒不要用 Lombok 的 Data 注解因为团队规范要求显式 getter/setter不要忘记加序列化接口。参考示例则贴一段标准代码。这种写法的妙处在于AI 不需要你每次重复它自己会在合适的时机读取技能文件。你只要说“帮我建一个用户表的实体类”AI 就会自动匹配到这条技能按里面的规范执行。这就是superpowers最核心的价值把隐性知识显性化把重复劳动自动化。2.3 技能之间如何组合与调用单个技能解决单点问题但真实开发往往是多步骤的。superpowers的进阶玩法是技能编排。比如“新增一个完整的 CRUD 接口”这个任务可以拆成“建实体类”“建 Mapper”“建 Service”“建 Controller”“写单元测试”五个技能AI 按顺序依次调用。这里有个关键设计技能文件里可以声明“前置技能”和“后续技能”。前置技能表示“干这件事之前必须先干那件事”后续技能表示“干完这件事通常还要干那件事”。AI 读取到这些声明后就能自动串起一条工作流。这比你在一个巨大的提示词里把所有步骤写死要灵活得多因为每个技能可以独立维护、独立更新。我实测下来这种组合方式特别适合有固定套路的开发场景比如后端接口开发、前端组件开发、数据库迁移脚本编写。凡是“每次做法都差不多、只是参数不同”的任务都值得抽成一个技能。3. 安装与初始化把 superpowers 跑起来3.1 环境准备中最容易被忽略的两件事superpowers 安装是搜索量很高的词说明很多人卡在第一步。我先把环境要求讲清楚。这套东西通常运行在命令行环境里你需要一个可用的 AI 编码代理作为宿主比如常见的命令行 AI 助手工具。技能包本身是纯文本文件所以对操作系统没有硬性要求Windows、macOS、Linux 都能跑。第一件容易被忽略的事是目录结构。技能文件不是随便扔在哪个文件夹都能被识别它需要放在宿主工具约定的技能目录下。这个目录通常在用户主目录下的一个隐藏文件夹里具体路径取决于你用的宿主工具。安装前一定要先确认这个目录存在不存在就手动建一个。第二件容易被忽略的事是文件编码。技能文件里如果有中文说明务必保存成 UTF-8 编码。我踩过一次坑用某个编辑器默认存成了 GBK结果 AI 读取时中文全是乱码技能触发条件匹配不上排查了半天才发现是编码问题。这个细节在官方文档里往往一笔带过但实际很致命。3.2 获取技能包的几种途径技能包的来源主要有三种。第一种是官方或社区维护的通用技能集涵盖常见的开发场景适合新手直接拿来用。第二种是团队内部沉淀的技能集把你们自己的编码规范、项目结构、常用命令写进去这是最有价值的部分。第三种是个人按需编写的技能针对你自己的工作习惯定制。我的建议是先用通用技能集跑通流程感受一下技能是怎么被触发的然后再动手写自己的。上来就写一堆自定义技能很容易因为不理解触发机制而写出一堆“永远不被调用”的死技能。获取到技能包后通常就是把它解压或克隆到前面说的技能目录下。有些技能包会带一个初始化脚本运行一下就能自动完成目录创建和文件复制。如果没有脚本手动复制也行注意保持原有的目录层级不要打乱。3.3 验证安装是否成功的实操方法装完之后怎么确认它真的生效了别急着写复杂任务先用一个最简单的场景验证。你可以对 AI 说一句“列出当前可用的技能”如果安装正确它应该能读取出技能目录下的文件列表并返回给你。如果它说“没有找到技能”或者返回空列表按这个顺序排查先确认技能目录路径对不对再确认文件是不是放在正确的子目录里最后确认文件扩展名是不是宿主工具支持的类型。我遇到过有人把技能文件放在了技能目录的上一级结果死活读不到挪进去就好了。验证通过后可以做一个更真实的测试让 AI 执行一个技能里明确定义过的任务观察它是否按照技能文件里的步骤来。比如技能里写了“生成代码后必须附上单元测试”那你就看它生成完代码后有没有主动写测试。如果有说明技能被正确加载并执行了。4. 上手实操从零写一个能用的技能4.1 选一个高频场景作为切入点写第一个技能千万别挑复杂的。挑你每天都要重复做、步骤固定、容易描述清楚的事情。我推荐从“代码格式化与提交信息生成”这类小任务开始因为它边界清晰、验证简单。假设我们团队规定提交代码前必须跑一遍格式化命令提交信息必须遵循“类型: 描述”的格式类型只能是 feat、fix、docs、refactor 这几种。这个规则每次都要跟 AI 讲很烦。那我们就把它写成一个技能。技能文件的内容大致这样组织触发条件写“当用户要求提交代码或生成提交信息时”操作步骤写“先执行格式化命令再根据改动内容判断类型最后按格式生成提交信息”注意事项写“类型只能从四种里选描述用中文不超过 50 字”。写完之后你只要说“帮我提交”AI 就会按这套规则走。4.2 技能描述里的措辞技巧技能能不能被正确触发很大程度上取决于触发条件的措辞。写得太窄很多相关场景匹配不上写得太宽又会在不相关的场景被误触发。我的经验是用“用户意图”而不是“具体命令”来描述触发条件。举个例子。写“当用户输入 git commit 时触发”就太窄了因为用户可能说“帮我提交一下”“把改动存一下”“生成个提交信息”这些都不会包含 git commit 这个字符串。改成“当用户表达提交代码、生成提交信息、保存改动等意图时触发”覆盖面就广多了。另一个技巧是在技能里列出同义词和常见说法。比如“提交”这个词用户可能说“commit”“存一下”“记录一下”“保存进度”。把这些都列在触发条件里匹配率会明显提升。这就像给搜索引擎加关键词覆盖得越全命中率越高。4.3 让技能可维护的三个习惯技能写多了之后维护就成了问题。我养成三个习惯分享给你。第一个习惯是给每个技能加版本号和更新日期。技能文件头部写清楚 v1.0、2024-xx-xx改过什么在文件末尾记一笔。这样团队里其他人用的时候一眼就知道这个技能是不是最新的。第二个习惯是把可变参数抽出来。比如格式化命令不同项目可能不一样那就不要在技能里写死而是写成“执行项目根目录下 package.json 里定义的 format 脚本”。这样同一个技能能适配多个项目。第三个习惯是定期清理僵尸技能。有些技能写完就再也没被触发过要么是触发条件写得太偏要么是场景已经不存在了。每隔一两个月翻一遍技能目录把没用的删掉保持技能集精简。技能不是越多越好能被用起来的才有价值。5. 在 Java 项目里落地 superpowers 的完整思路5.1 Java 技术栈适合抽成技能的环节superpowers java是很多人关心的方向我结合自己的 Java 项目经验讲讲。Java 项目的特点是结构规整、约定多、样板代码多这恰恰是技能包最能发挥价值的地方。适合抽成技能的环节我列几个实体类生成、Mapper 接口编写、Service 层业务方法、Controller 接口定义、单元测试骨架、数据库迁移脚本、异常处理规范、日志打印规范。这些环节每次做法都大同小异区别只在具体的类名和字段非常适合用技能固化下来。反过来说那些需要大量业务判断、每次逻辑都不一样的环节就不太适合抽技能。比如复杂的业务规则计算、性能调优方案这些还是得靠人跟 AI 具体讨论。技能包解决的是“重复的确定性劳动”不是“创造性的不确定劳动”。5.2 一个完整的 Java 接口开发技能链我拿“新增一个查询接口”这个任务演示一下技能链怎么串。整个任务拆成四个技能按顺序执行。第一个技能是“确认接口契约”。触发条件是用户要求新增接口。操作步骤是先问清楚接口路径、请求方法、入参、出参确认无误后再往下走。注意事项是不要自己臆测字段拿不准就问。第二个技能是“生成 Controller 方法”。前置技能是“确认接口契约”。操作步骤是按项目规范生成方法签名加上参数校验注解加上日志打印返回统一响应体。注意事项是路径命名用中划线方法名用驼峰不要忘了权限注解。第三个技能是“生成 Service 方法”。前置技能是“生成 Controller 方法”。操作步骤是定义接口方法写实现类处理业务逻辑调用 Mapper。注意事项是事务注解加在写操作方法上查询方法不加。第四个技能是“生成单元测试”。前置技能是“生成 Service 方法”。操作步骤是用项目统一的测试框架覆盖正常流程和异常流程断言要具体。注意事项是不要用 Thread.sleepmock 要清理。这四个技能串起来AI 就能从一句“帮我加个查询用户列表的接口”一路做到生成测试。中间每一步都会按技能文件里的规范来风格统一不会跑偏。5.3 技能与项目规范的同步维护这里有个现实问题项目规范会变技能文件也得跟着变。如果技能和实际规范脱节AI 就会按过时的规则生成代码反而添乱。我的做法是把技能文件纳入代码仓库管理。技能目录单独建一个仓库或者放在主仓库的一个子目录里跟代码一起走代码评审流程。规范改了提个 PR 改技能文件评审通过后合并。这样技能永远和规范同步而且改动有记录可查。另外我会在技能文件里引用项目里的实际配置文件而不是把配置值抄一遍。比如代码风格不写“缩进用 4 空格”而是写“遵循项目根目录 .editorconfig 的配置”。这样规范改了配置文件技能不用动AI 读到的永远是最新的。6. 踩坑实录那些让我折腾半天的坑6.1 技能不触发从现象到根因的排查链路最常见的坑就是技能写了但 AI 不调用。我遇到过一次写了个“生成数据库迁移脚本”的技能怎么试都不触发。排查过程分享给你这套思路可以复用到任何“技能不生效”的场景。第一步确认技能文件被加载了。让 AI 列出可用技能看文件名在不在列表里。在说明文件位置和格式没问题问题出在触发条件。第二步检查触发条件的措辞。我原来写的是“当用户要求生成 migration 时触发”但实际我测试时说的是“帮我写个建表脚本”。migration 和建表脚本字面上完全不搭边自然匹配不上。改成“当用户要求生成数据库迁移脚本、建表脚本、改表脚本时触发”立刻就生效了。第三步如果改了措辞还不触发就检查是不是被其他技能抢了。有时候两个技能触发条件重叠AI 选了另一个。这时候要么合并技能要么把触发条件写得更精确明确区分边界。6.2 技能执行顺序错乱的修复过程技能链的坑更隐蔽。我搭过一个五步的技能链结果 AI 执行时跳过了第二步直接做第三步导致生成的代码缺了必要的校验逻辑。根因是前置技能的声明方式不对。我原来在第二步技能里写“前置技能第一步”但第一步技能里没写“后续技能第二步”。AI 是从当前技能往前找前置如果前置技能本身没被触发它就找不到于是跳过。正确的做法是双向声明前置技能里写后续是谁后续技能里写前置是谁。这样无论从哪个方向进入链条都能串起来。修复之后我做了个验证故意从中间步骤开始触发看 AI 会不会自动补上前面的步骤。会补说明链条声明正确。这个验证方法很实用建议你搭完技能链都测一遍。6.3 技能文件写太长的副作用新手容易犯的错是把技能文件写成一篇长文恨不得把所有细节都塞进去。我早期也这样一个技能文件写了上千字结果 AI 读取后反而抓不住重点执行时经常漏步骤。后来我总结出一个原则一个技能只干一件事步骤不超过七步。超过七步就拆成两个技能。人的短期记忆容量有限AI 处理长文本时注意力也会分散步骤太多它记不住。另外技能文件里的语言要短句为主动词开头。不要写“系统应当对用户输入进行校验”要写“校验用户输入”。前者是描述后者是指令。AI 执行指令比理解描述更准确。这个细节看起来小但对执行效果影响很大。7. 让技能包真正提升效率的几个进阶玩法7.1 用技能沉淀团队的“隐性约定”每个团队都有一堆没写进文档、但大家都默认遵守的约定。比如“日志里不要打印用户手机号”“接口返回的时间统一用时间戳”“异常不要直接抛给前端”。这些约定新人不知道AI 更不知道每次都要口头提醒。superpowers最好的用法之一就是把这些隐性约定写成技能。我建了一个叫“代码红线”的技能触发条件是“生成任何代码时”操作步骤是“逐条检查以下红线”注意事项里列了十几条团队约定。这样 AI 每次生成代码都会自动过一遍红线相当于给代码加了一道自动检查。这个技能的价值随着团队规模增长会越来越明显。人多了口头传达容易漏写成技能就一劳永逸。而且新同事用 AI 辅助开发时这些约定会自动生效省去了大量培训成本。7.2 技能与代码评审的联动技能包还能跟代码评审联动。我们团队的做法是把评审中反复出现的问题反向沉淀成技能。比如评审时发现大家老是忘记给新接口加限流注解那就写一个“接口开发”技能把加限流注解写进步骤里。下次 AI 生成接口就会自动带上。这形成了一个正向循环评审发现问题问题变成技能技能预防问题评审时这类问题就少了。跑了一段时间后低级问题的数量明显下降评审能聚焦在真正的设计问题上。我建议你建一个“评审问题清单”每次评审后把重复出现的问题记下来攒够几条就更新对应的技能。这个习惯坚持几个月效果非常明显。7.3 技能包的版本管理与团队共享技能包要共享才有价值。我的做法是建一个独立的 Git 仓库放技能文件团队所有人都有权限读核心成员有权限写。仓库的 README 里写清楚每个技能是干什么的、怎么用、谁维护。版本管理上我用语义化版本号。技能内容小改加 patch 号新增技能加 minor 号不兼容的改动加 major 号。团队成员更新技能包时看版本号就知道要不要重新适应。共享还有个好处是技能可以互相借鉴。A 组写了个好用的技能B 组可以直接拿去改改用。我们团队现在有几十个技能覆盖了从环境搭建到部署上线的全流程新项目启动时直接复用省了大量重复劳动。8. 关于 superpowers 的几个常见疑问8.1 它和普通的提示词模板有什么区别很多人问superpowers跟我自己存一堆提示词模板有啥区别。区别在于触发机制和组合能力。提示词模板需要你手动复制粘贴而且模板之间是孤立的。技能包是 AI 主动读取的你只要表达意图它自己找对应的技能技能之间还能声明依赖关系自动串联成工作流。打个比方提示词模板像一本菜谱你得自己翻到某一页照着做。技能包像一个会做饭的助手你说“我饿了”他自己知道该翻哪页、该先炒哪个菜。这个“主动匹配”和“自动编排”的能力是技能包的核心优势。8.2 学习成本高不高说实话入门成本不高但用好需要一点耐心。基础操作就是写 Markdown 文件、放到指定目录、验证触发半天就能学会。难的是写出高质量、高命中率的技能这需要你对 AI 的行为模式有感觉知道怎么措辞它才听得懂。我的建议是别追求一步到位。先写三五个简单技能用一周时间观察哪些触发得好、哪些触发得差根据实际表现迭代。技能包这东西是“用出来的”不是“设计出来的”。用得越多你对触发条件的把握越准。8.3 适合什么样的项目技能包最适合有固定套路、重复劳动多、规范要求严的项目。后端接口开发、数据管道搭建、测试用例编写这些场景收益最大。反过来探索性强的项目、需求天天变的项目技能包的价值就有限因为套路还没形成写出来的技能很快就过时了。我的判断标准是如果一件事你一个月内做了三次以上而且每次做法差不多那就值得抽成技能。按这个标准筛一遍你的日常工作能筛出不少适合技能化的场景。9. 我个人的一点使用体会用superpowers这套东西大半年最大的感受是它改变了我跟 AI 协作的方式。以前我把 AI 当搜索引擎用问一句答一句现在我把它当团队成员用给它配好工具和规范让它自己按流程干活。这个转变带来的效率提升比单纯换个更聪明的模型要明显得多。另一个体会是写技能的过程其实是在梳理自己的知识。很多约定俗成的东西你不写下来根本意识不到自己一直在遵守。写技能逼着你把这些隐性知识显性化这个过程本身就很有价值。有时候写着写着发现自己以前的某些做法其实可以优化顺手就把工作流改了。最后分享一个小技巧技能文件里可以加一个“反例”部分写清楚“不要怎么做”。AI 对反例的敏感度比正例还高写几条反例往往比写十条正例更能约束它的行为。比如“不要用 System.out.println 打印日志”“不要在循环里查数据库”这类反例写进技能AI 生成代码时会主动避开。这个技巧是我踩了不少坑之后才悟出来的希望对你有用。