最近一个月我的主力AI编程工具一直没消停过。先是同事甩了个链接过来说有个叫“superpowers”的开源项目能让AI写代码的水平上一个台阶接着群里又有人在问“superpowers安装”“superpowers java”还有人把“codex superpowers”挂到热搜上。我第一反应是又一个花里胡哨的提示词合集直到自己装完跑完一个真实项目才发现这东西的思路确实和我之前玩过的都不一样。这篇我打算把整个上手过程掰开揉碎讲清楚它到底是干嘛的、装的时候有哪些坑、配置完怎么验证、技能目录里哪些是真有用的以及它和Codex、Cursor这些工具怎么配合。如果你现在正在用AI写业务代码、写测试、做重构但总觉得AI“太笨、记不住上下文、同一个错误反复犯”这篇文章应该能帮你省下不少试错时间。1. 先搞清楚它到底是什么一个给AI编程工具加“工作记忆”的技能框架先说个现象。我见过不少团队把AI编程工具当“高级自动补全”让模型写个函数、补个单元测试还行但一旦涉及跨文件重构、按团队规范写代码、或者让AI自己发现并修复问题它就开始“失忆”了。不是模型不够聪明而是它每次对话的上下文窗口有限你上午告诉它的代码规范下午新对话里它就忘了你让它遵守TDD流程它写三步就跳步。superpowers这个项目要解决的正是这个“AI记不住事”的痛点。1.1 技能的本质是“可复用的指令包”你可能会想这不就是更长的system prompt吗是但也不完全是。我拆开它的文件结构之后就明白了它把完成某一类任务所需的完整方法论固化成了Markdown文件。比如“写测试”这个技能里面不只写“请写测试”而是拆成了先理解被测模块的输入输出边界列出关键分支和异常路径按给定格式生成测试用例描述再让模型逐条实现并运行验证失败时如何定位是测试问题还是实现问题也就是说它不是给AI一句咒语而是给了AI一套“遇到这类任务时的完整思考流程”。这个思路我非常认同AI编程工具最缺的不是单个知识点而是稳定的任务执行路径。你让一个资深工程师写接口测试他心里有一整套流程但让AI直接写它每次都在“猜测式开发”一会儿写个happy path一会儿补个异常用例顺序还经常乱。技能文件就是把这些流程显式写出来让模型每次都按这套路径走。1.2 为什么叫“superpowers”而不是“prompt库”我在网上看到有人把它归类为“提示词工程”我觉得不太准确。传统prompt给你的是“一句话”superpowers给你的是“一套方法论操作手册”。举个例子我用它自带的调试技能处理过一个线上问题AI不再是上来就猜“是不是空指针”而是先让我提供错误堆栈、相关代码路径、最近改动点再按“形成假设→验证假设→缩小范围→修复→回归”的顺序排查。这个体验差异非常明显。所以它真正的价值是把资深工程师处理某类任务时的隐性经验用模型能理解的方式固化下来了。它不是一个AI功能而是一套可扩展的AI行为框架。2. 安装前最容易忽略的三个环境细节superpowers的安装本身不复杂但我在折腾过程中发现很多人包括我会卡在三个和环境相关的细节上。如果你装完发现技能不生效、模型答非所问先回来对照这一节。2.1 运行环境不只是“装个npm包”的事superpowers是一个开源项目主要通过Node.js生态分发。但注意它不是一个独立程序而是寄生在某个AI编程工具之上的“技能层”。它的核心运行机制是安装时往你的AI工具配置目录里写入一批技能文件并在对话启动时自动加载索引。所以前置条件不是“装好Node就行”而是你本机得先有一个支持自定义指令或技能加载的AI编程工具Claude Code这类命令行工具是它的原生场景Codex CLI、Cursor等也可以用后面单独讲。我建议先确认两件事Node.js版本不要太老我用的是20.x实测稳定。太老的版本解析某些配置文件时可能出现兼容问题。包管理器建议统一npm和pnpm混用容易把node_modules搞得乱七八糟。我个人倾向npm因为项目文档里的命令大多以npm为准。2.2 配置目录的读写权限这个东西容易被忽略。安装脚本会自动创建配置目录并写入技能文件如果你的用户目录权限被改过或者公司电脑有安全策略拦截写入安装过程会“假成功”——命令跑完了但文件没写进去AI工具启动后根本看不到技能。判断方法很简单安装完成后手动打开配置目录看看技能文件夹是否存在里面的Markdown文件是否完整。如果你看到的是空目录说明被权限拦截了用管理员权限重跑安装脚本或者手动把下载的skills目录复制到配置目录下。2.3 和现有配置的冲突如果你之前已经往AI工具的配置里写过自定义指令、MCP配置或者别的技能插件安装时一定要看清楚合并逻辑。superpowers的安装器会往配置文件里追加内容而不是覆盖。但有些同名技能会互相干扰比如你自己定义过一个“code-review”技能它里面也带一个同名的先加载哪个、以谁为准不同AI工具的处理方式不一样。我的建议是安装前先备份配置文件安装后检查一下是否有同名覆盖提示。如果后续改过自己的配置发现不生效大概率就是这里冲突了。3. 装完后的第一次启动该盯哪几个地方安装成功只是开始真正的分水岭在第一次启动。很多人在这一步栽跟头不是因为装错了而是不知道“启动成功”应该长什么样。3.1 首次启动的完整检查清单我整理了一份自己每次重装都会走的检查清单照着走基本不会漏启动AI工具确认没有报语法错误或配置解析失败。在对话里输入类似superpowers或/skills的命令要看具体工具支持哪种唤起方式能列出技能列表就算加载成功。随便挑一个技能比如“write-tests”看它是否输出了该技能的“工作前说明”。如果没有说明技能没被正确识别。问一个和项目无关的问题确认不影响正常对话。整个流程可能不到5分钟但能帮你区分“装好了但没生效”和“压根没装进去”。我遇到最多的求助信息都是“我装了但没什么反应”结果一查配置文件压根没加载进去。3.2 它给你的不是“新对话界面”而是“行为方式变化”很多人误以为装完会多出一个按钮或者新的交互面板实际上你看到的东西几乎没有变化。它的生效方式很隐蔽你在对话中触发某个技能时模型会突然变得“懂流程了”。比如你写“帮我给这个模块写测试”如果技能生效模型不会马上甩出一堆代码而是先问你模块边界、期望行为甚至列出测试计划再动手。这个“变慢”的过程会劝退一部分人。但这是对的它就是在逼模型先想再写。如果你希望AI秒回代码这个工具确实不适合你如果你要的是稳定可维护的产出这个“慢”恰恰是价值所在。3.3 第一次触发的关键词匹配不同工具的触发方式不太一样有的靠自然语言“skills: write-tests”有的靠斜杠命令。建议先小范围试用比如拿一个不重要的工具函数写测试看看模型是否按技能流程走。如果你发现它还是老一套直接给代码那说明触发方式不对回到配置文档里查一下正确姿势。4. 技能目录逐条拆解哪些是真刚需哪些是锦上添花superpowers自带了一套技能目录我花了一下午把主要技能都过了一遍。说实话有几个技能命中率非常高几乎是天天用也有几个设计得偏“重”小项目里根本用不上。下面按我的实际体验拆一拆。4.1 写测试技能实测最值回票价的模块它的测试技能不是“帮我写测试”而是一套完整的测试设计工作流。我拿一个Java服务里的订单状态机试过模型先分析状态转换合法路径和非法路径再针对每个分支列测试用例最后才生成JUnit代码。整个过程下来覆盖率比我手写还高而且每条用例都有注释解释验证意图。如果你平时用AI写测试总觉得“覆盖率低”“都是happy path”问题往往不是模型能力而是没有人告诉它“应该先穷举分支”。superpowers的测试技能就是在补这件事。4.2 调试技能不再“瞎猜式修bug”调试技能是我个人认为最被低估的一个。它的做法是先把问题边界圈出来输入是什么、期望输出是什么、实际输出有什么偏差、最近一次改动是什么时候。然后基于这些信息让你选择“排查路线”。我在一个分页查询bug上试过它没有上来就推荐改查询语句而是先问我“offset计算方式是否包含排序字段”一句话就点醒了问题根源。这种体验让我确定了一件事技能的底层文档一定是有经验的工程师写的他们是把真实的debug思路翻译成了模型能执行的步骤。4.3 代码评审和重构技能大项目用得上小项目有点重代码评审技能会按“正确性→性能→可维护性→安全隐患”的优先级审查输出比普通review要结构化得多。重构技能则偏向“先建立行为基线再改代码”也就是重构前先让AI写一套验证用例这在处理遗留系统时非常踏实。但如果你只是个Demo项目或者代码量很小这两个技能确实会显得“套路化”不必硬上。4.4 自定义技能的扩展空间学完立刻改出自己的版本除了自带技能这个框架最吸引我的是自定义能力。技能文件本质上是Markdown你可以完全照着它的格式写自己的技能。比如我们团队有套内部编码规范过去我要在prompt里反复粘贴现在直接固化成团队技能文件每个成员加载同一个技能AI输出风格一下就统一了。这个能力对团队协作的价值很大你把经验沉淀成文件就再也不用靠嘴传了。5. 和Codex、Cursor等其他工具搭配的正确姿势最近“codex superpowers”这个搜索词热度很高确实不少人想把它用到Codex上。“superpowers java”这个词我也理解——主要是Java开发者想知道这东西能不能用来增强Java项目开发。这两个问题我放在一起说。5.1 Codex CLI接入核心看“自定义指令”能力superpowers的设计思路并不绑定某一个AI工具它依赖的是“外部指令文件加载”这个能力。Codex CLI支持自定义指令配置所以理论上可以复用superpowers的思维框架。但要注意不同工具的指令优先级、文件加载规则、变量替换语法可能不一样不能直接整个目录复制过去就完事需要按照目标工具的格式调整技能的加载方式。我的建议是不要追求100%功能迁移而是把superpowers里最核心的几个技能比如测试、调试按新工具的指令格式重新整理一遍。你抄的是它的方法论不是它的文件结构。5.2 Java项目实战和语言无关但和“测试框架”强相关说回Java。superpowers本身没有任何语言约束技能里面既没有JVM特定的东西也不绑定Maven或Gradle。我拿Java Spring Boot项目跑测试技能时它生成的测试代码用的是JUnit 5和AssertJ因为我的项目里已经写了这些依赖AI是靠读取项目上下文自己选型的。但这里有个实操要点技能会指导AI“先分析再写代码”而分析质量取决于AI对项目上下文的理解。Java项目通常比Node项目结构复杂实体类、仓储层、服务层、控制器层层层嵌套如果AI加载上下文不够技能再牛也白搭。所以我建议在Java项目里用之前先把项目的README、核心模块说明喂给AI让技能有足够的信息去做“边界分析”。5.3 哪些AI工具和“技能框架”的契合度最高说实话不是所有AI工具都能发挥这套框架的价值。契合度取决于三个能力是否能加载多文件指令决定技能能不能被拆成多个模块是否支持自动或手动触发技能决定技能是“随时在线”还是“呼之即来”上下文窗口大小决定技能里的完整流程是否塞得下从我实测来看命令行类工具Claude Code、Codex CLI表现最好它们天然支持多文件配置也容易做命令唤起。图形界面工具比如Cursor也可以用但要手动把技能内容粘到规则配置里体验稍差一些。6. 把技能跑进真实项目一份可复用的使用心法工具摸熟了之后真正考验人的是“怎么用”。我前后在不同项目里试了两周总结了几个关键经验供参考。6.1 先从一个技能入手别一上来就全家桶我见过不少朋友装完superpowers就立刻让AI执行各种技能结果发现输出不如预期然后判断“这个工具不行”。问题不在工具而是你一次性塞给模型太多规则它反而不知道以哪个为准。我的做法是一次只激活一个技能其他保持默认。先用两天“write-tests”等稳定了再加“debugging”让AI逐步适应也让你的使用习惯逐步建立。6.2 技能是“流程”不是“结果”要配合人工判断这句话可能有人不爱听但我必须说superpowers不会让你的AI瞬间变成高级工程师。它最大的作用是让AI的“行为过程”更规范——先分析再动手、先列用例再写代码、先定位再修复。但最终结果对不对还是要人来判断。我在用调试技能排查一个并发问题时AI给出的假设方向是对的但真正落实到锁的粒度调整仍然是我自己的经验在把关。所以我对这个工具的定义是项目管理的AI执行框架不是水平放大器。它让过程可控但不能替代你本身的技术判断力。6.3 对团队协作的建议把技能文件纳入版本管理如果你打算在团队里推广强烈建议把自定义技能文件放到Git仓库里管理和项目代码一起走。这样新同事进来clone完代码就自带团队AI规范不用一个一个手动配置。我目前就是把技能文件放在一个独立目录通过软链接指到AI工具的配置目录这样更新时只改仓库里的源文件就行。6.4 触发技能时的“提示词锚点”技巧很多工具触发技能靠的是“技能名称”的匹配所以怎么在你的工作指令里带上锚点很关键。我的习惯是写任务描述时加上按superpowers的写测试技能执行这类前缀模型几乎每次都能正确识别并切换流程。如果你发现触发不稳定可以试着在指令里引用技能文档的标题而不只是文件名。6.5 上下文预算管理技能文件本身也吃上下文这是很多人忽略的问题。技能文件再精简也是要占上下文窗口的如果一次加载几十个技能模型的有效记忆空间会明显变小反而影响代码生成的连贯性。我的实践是按项目类型选择技能包Web前后端项目只加载测试、调试、代码评审三个核心技能做工具库微服务的时候再加一个文档生成技能。保持“够用就好”的原则别让上下文全被技能规则占满。7. 我踩过的几个坑以及对应的排查思路最后这部分比较务实把我遇到过的真实问题、当时的排查逻辑和最终的解决方案写一下。这些坑大部分没有写进官方文档属于“试过才知道”的经验。7.1 坑一安装了但技能列表为空排查了半小时现象是安装命令执行完毕启动AI工具后输入技能列表命令却什么都没有。我先检查了配置目录——技能文件夹存在文件也有内容然后怀疑是权限问题但重装后依旧最后发现是配置文件里有一段旧的缓存语法和新版不兼容导致整个配置被模型解析阶段静默丢弃了一部分。清理掉旧配置文件、重新安装后解决。这里学到的排查思路是不要只盯着“文件是否存在”要确认文件里的内容有没有被真正加载。7.2 坑二技能触发后模型把“分析步骤”和“代码实现”混在一起输出这个问题出在我同时激活了“测试技能”和另一个自带的“思考技能”。两个技能都在教AI“先想再做”但它们定义的步骤顺序不一样模型无所适从。解决方式是停用其中一个。所以我前面强调“一次只开一个技能”不是保守是真的会冲突。7.3 坑三Java项目里技能生成的测试代码风格和团队不一致它生成的测试虽然结构完整但命名风格是should_xxx这种英文下划线风格而我们团队约定的是中文业务描述风格的测试名。我一开始以为是AI没学好后来发现是因为技能文档里给了测试方法命名的默认规范而项目代码里缺少对命名规范的示例AI自然按技能模板走了。解决方法是把团队测试规范写成一个自定义技能片段放在测试技能后面让它覆盖默认规则。7.4 坑四自定义技能文件写好后不生效这个问题我和朋友讨论过多次最后定位到是文件放置目录不对。有些AI工具只扫描配置目录下面第一层的技能文件不递归扫描子目录。我自定义的技能放在subfolder/my-skill.md系统压根不认。放到第一层后就正常了。如果你自定义技能不生效第一反应先看目录层级而不是看内容。7.5 坑五以为“技能越多越强”结果上下文爆炸有一段时间我为了追求“全面”一口气把自带技能全开结果模型写代码变得畏手畏脚——每一步都要先列一堆分析连写个工具函数都磨磨蹭蹭。这就是典型的上下文和注意力被技能规则稀释了。后来我通过给每个技能设定“使用范围说明”让模型只在真正遇到复杂任务时才切换到完整流程日常小改动仍然走默认模式体验立刻好了很多。这个经验给我最大的启发是框架可以给你超能力但你得决定什么时候使用它。无关紧要的任务让它快速输出真正复杂的问题再让技能跑完整流程。8. 最后说点个人体会玩了两周superpowers我最大的感受是AI编程工具的下一个阶段可能不是模型本身变大而是“怎么让模型的每一次输出都稳定在某个水平线上”。superpowers用一套可扩展的、可写的技能框架让这件事变得可控。如果你刚接触不要急着追求“全家桶”先把测试技能用好让它帮你建立“先分析再编码”的惯性。等习惯了这套工作节奏再慢慢把调试、代码评审这些技能加进来。如果你是用Codex CLI的用户或者Java栈的开发者更不用纠结“是不是原生支持”——技能这个方法论的迁移成本很低抄走它最核心的几页你就能在自己的工具链里复制出90%的效果。大概就是这些。后面我如果折腾出有意思的新用法再来继续分享。
Superpowers实战：给AI编程工具加“工作记忆”的技能框架
最近一个月我的主力AI编程工具一直没消停过。先是同事甩了个链接过来说有个叫“superpowers”的开源项目能让AI写代码的水平上一个台阶接着群里又有人在问“superpowers安装”“superpowers java”还有人把“codex superpowers”挂到热搜上。我第一反应是又一个花里胡哨的提示词合集直到自己装完跑完一个真实项目才发现这东西的思路确实和我之前玩过的都不一样。这篇我打算把整个上手过程掰开揉碎讲清楚它到底是干嘛的、装的时候有哪些坑、配置完怎么验证、技能目录里哪些是真有用的以及它和Codex、Cursor这些工具怎么配合。如果你现在正在用AI写业务代码、写测试、做重构但总觉得AI“太笨、记不住上下文、同一个错误反复犯”这篇文章应该能帮你省下不少试错时间。1. 先搞清楚它到底是什么一个给AI编程工具加“工作记忆”的技能框架先说个现象。我见过不少团队把AI编程工具当“高级自动补全”让模型写个函数、补个单元测试还行但一旦涉及跨文件重构、按团队规范写代码、或者让AI自己发现并修复问题它就开始“失忆”了。不是模型不够聪明而是它每次对话的上下文窗口有限你上午告诉它的代码规范下午新对话里它就忘了你让它遵守TDD流程它写三步就跳步。superpowers这个项目要解决的正是这个“AI记不住事”的痛点。1.1 技能的本质是“可复用的指令包”你可能会想这不就是更长的system prompt吗是但也不完全是。我拆开它的文件结构之后就明白了它把完成某一类任务所需的完整方法论固化成了Markdown文件。比如“写测试”这个技能里面不只写“请写测试”而是拆成了先理解被测模块的输入输出边界列出关键分支和异常路径按给定格式生成测试用例描述再让模型逐条实现并运行验证失败时如何定位是测试问题还是实现问题也就是说它不是给AI一句咒语而是给了AI一套“遇到这类任务时的完整思考流程”。这个思路我非常认同AI编程工具最缺的不是单个知识点而是稳定的任务执行路径。你让一个资深工程师写接口测试他心里有一整套流程但让AI直接写它每次都在“猜测式开发”一会儿写个happy path一会儿补个异常用例顺序还经常乱。技能文件就是把这些流程显式写出来让模型每次都按这套路径走。1.2 为什么叫“superpowers”而不是“prompt库”我在网上看到有人把它归类为“提示词工程”我觉得不太准确。传统prompt给你的是“一句话”superpowers给你的是“一套方法论操作手册”。举个例子我用它自带的调试技能处理过一个线上问题AI不再是上来就猜“是不是空指针”而是先让我提供错误堆栈、相关代码路径、最近改动点再按“形成假设→验证假设→缩小范围→修复→回归”的顺序排查。这个体验差异非常明显。所以它真正的价值是把资深工程师处理某类任务时的隐性经验用模型能理解的方式固化下来了。它不是一个AI功能而是一套可扩展的AI行为框架。2. 安装前最容易忽略的三个环境细节superpowers的安装本身不复杂但我在折腾过程中发现很多人包括我会卡在三个和环境相关的细节上。如果你装完发现技能不生效、模型答非所问先回来对照这一节。2.1 运行环境不只是“装个npm包”的事superpowers是一个开源项目主要通过Node.js生态分发。但注意它不是一个独立程序而是寄生在某个AI编程工具之上的“技能层”。它的核心运行机制是安装时往你的AI工具配置目录里写入一批技能文件并在对话启动时自动加载索引。所以前置条件不是“装好Node就行”而是你本机得先有一个支持自定义指令或技能加载的AI编程工具Claude Code这类命令行工具是它的原生场景Codex CLI、Cursor等也可以用后面单独讲。我建议先确认两件事Node.js版本不要太老我用的是20.x实测稳定。太老的版本解析某些配置文件时可能出现兼容问题。包管理器建议统一npm和pnpm混用容易把node_modules搞得乱七八糟。我个人倾向npm因为项目文档里的命令大多以npm为准。2.2 配置目录的读写权限这个东西容易被忽略。安装脚本会自动创建配置目录并写入技能文件如果你的用户目录权限被改过或者公司电脑有安全策略拦截写入安装过程会“假成功”——命令跑完了但文件没写进去AI工具启动后根本看不到技能。判断方法很简单安装完成后手动打开配置目录看看技能文件夹是否存在里面的Markdown文件是否完整。如果你看到的是空目录说明被权限拦截了用管理员权限重跑安装脚本或者手动把下载的skills目录复制到配置目录下。2.3 和现有配置的冲突如果你之前已经往AI工具的配置里写过自定义指令、MCP配置或者别的技能插件安装时一定要看清楚合并逻辑。superpowers的安装器会往配置文件里追加内容而不是覆盖。但有些同名技能会互相干扰比如你自己定义过一个“code-review”技能它里面也带一个同名的先加载哪个、以谁为准不同AI工具的处理方式不一样。我的建议是安装前先备份配置文件安装后检查一下是否有同名覆盖提示。如果后续改过自己的配置发现不生效大概率就是这里冲突了。3. 装完后的第一次启动该盯哪几个地方安装成功只是开始真正的分水岭在第一次启动。很多人在这一步栽跟头不是因为装错了而是不知道“启动成功”应该长什么样。3.1 首次启动的完整检查清单我整理了一份自己每次重装都会走的检查清单照着走基本不会漏启动AI工具确认没有报语法错误或配置解析失败。在对话里输入类似superpowers或/skills的命令要看具体工具支持哪种唤起方式能列出技能列表就算加载成功。随便挑一个技能比如“write-tests”看它是否输出了该技能的“工作前说明”。如果没有说明技能没被正确识别。问一个和项目无关的问题确认不影响正常对话。整个流程可能不到5分钟但能帮你区分“装好了但没生效”和“压根没装进去”。我遇到最多的求助信息都是“我装了但没什么反应”结果一查配置文件压根没加载进去。3.2 它给你的不是“新对话界面”而是“行为方式变化”很多人误以为装完会多出一个按钮或者新的交互面板实际上你看到的东西几乎没有变化。它的生效方式很隐蔽你在对话中触发某个技能时模型会突然变得“懂流程了”。比如你写“帮我给这个模块写测试”如果技能生效模型不会马上甩出一堆代码而是先问你模块边界、期望行为甚至列出测试计划再动手。这个“变慢”的过程会劝退一部分人。但这是对的它就是在逼模型先想再写。如果你希望AI秒回代码这个工具确实不适合你如果你要的是稳定可维护的产出这个“慢”恰恰是价值所在。3.3 第一次触发的关键词匹配不同工具的触发方式不太一样有的靠自然语言“skills: write-tests”有的靠斜杠命令。建议先小范围试用比如拿一个不重要的工具函数写测试看看模型是否按技能流程走。如果你发现它还是老一套直接给代码那说明触发方式不对回到配置文档里查一下正确姿势。4. 技能目录逐条拆解哪些是真刚需哪些是锦上添花superpowers自带了一套技能目录我花了一下午把主要技能都过了一遍。说实话有几个技能命中率非常高几乎是天天用也有几个设计得偏“重”小项目里根本用不上。下面按我的实际体验拆一拆。4.1 写测试技能实测最值回票价的模块它的测试技能不是“帮我写测试”而是一套完整的测试设计工作流。我拿一个Java服务里的订单状态机试过模型先分析状态转换合法路径和非法路径再针对每个分支列测试用例最后才生成JUnit代码。整个过程下来覆盖率比我手写还高而且每条用例都有注释解释验证意图。如果你平时用AI写测试总觉得“覆盖率低”“都是happy path”问题往往不是模型能力而是没有人告诉它“应该先穷举分支”。superpowers的测试技能就是在补这件事。4.2 调试技能不再“瞎猜式修bug”调试技能是我个人认为最被低估的一个。它的做法是先把问题边界圈出来输入是什么、期望输出是什么、实际输出有什么偏差、最近一次改动是什么时候。然后基于这些信息让你选择“排查路线”。我在一个分页查询bug上试过它没有上来就推荐改查询语句而是先问我“offset计算方式是否包含排序字段”一句话就点醒了问题根源。这种体验让我确定了一件事技能的底层文档一定是有经验的工程师写的他们是把真实的debug思路翻译成了模型能执行的步骤。4.3 代码评审和重构技能大项目用得上小项目有点重代码评审技能会按“正确性→性能→可维护性→安全隐患”的优先级审查输出比普通review要结构化得多。重构技能则偏向“先建立行为基线再改代码”也就是重构前先让AI写一套验证用例这在处理遗留系统时非常踏实。但如果你只是个Demo项目或者代码量很小这两个技能确实会显得“套路化”不必硬上。4.4 自定义技能的扩展空间学完立刻改出自己的版本除了自带技能这个框架最吸引我的是自定义能力。技能文件本质上是Markdown你可以完全照着它的格式写自己的技能。比如我们团队有套内部编码规范过去我要在prompt里反复粘贴现在直接固化成团队技能文件每个成员加载同一个技能AI输出风格一下就统一了。这个能力对团队协作的价值很大你把经验沉淀成文件就再也不用靠嘴传了。5. 和Codex、Cursor等其他工具搭配的正确姿势最近“codex superpowers”这个搜索词热度很高确实不少人想把它用到Codex上。“superpowers java”这个词我也理解——主要是Java开发者想知道这东西能不能用来增强Java项目开发。这两个问题我放在一起说。5.1 Codex CLI接入核心看“自定义指令”能力superpowers的设计思路并不绑定某一个AI工具它依赖的是“外部指令文件加载”这个能力。Codex CLI支持自定义指令配置所以理论上可以复用superpowers的思维框架。但要注意不同工具的指令优先级、文件加载规则、变量替换语法可能不一样不能直接整个目录复制过去就完事需要按照目标工具的格式调整技能的加载方式。我的建议是不要追求100%功能迁移而是把superpowers里最核心的几个技能比如测试、调试按新工具的指令格式重新整理一遍。你抄的是它的方法论不是它的文件结构。5.2 Java项目实战和语言无关但和“测试框架”强相关说回Java。superpowers本身没有任何语言约束技能里面既没有JVM特定的东西也不绑定Maven或Gradle。我拿Java Spring Boot项目跑测试技能时它生成的测试代码用的是JUnit 5和AssertJ因为我的项目里已经写了这些依赖AI是靠读取项目上下文自己选型的。但这里有个实操要点技能会指导AI“先分析再写代码”而分析质量取决于AI对项目上下文的理解。Java项目通常比Node项目结构复杂实体类、仓储层、服务层、控制器层层层嵌套如果AI加载上下文不够技能再牛也白搭。所以我建议在Java项目里用之前先把项目的README、核心模块说明喂给AI让技能有足够的信息去做“边界分析”。5.3 哪些AI工具和“技能框架”的契合度最高说实话不是所有AI工具都能发挥这套框架的价值。契合度取决于三个能力是否能加载多文件指令决定技能能不能被拆成多个模块是否支持自动或手动触发技能决定技能是“随时在线”还是“呼之即来”上下文窗口大小决定技能里的完整流程是否塞得下从我实测来看命令行类工具Claude Code、Codex CLI表现最好它们天然支持多文件配置也容易做命令唤起。图形界面工具比如Cursor也可以用但要手动把技能内容粘到规则配置里体验稍差一些。6. 把技能跑进真实项目一份可复用的使用心法工具摸熟了之后真正考验人的是“怎么用”。我前后在不同项目里试了两周总结了几个关键经验供参考。6.1 先从一个技能入手别一上来就全家桶我见过不少朋友装完superpowers就立刻让AI执行各种技能结果发现输出不如预期然后判断“这个工具不行”。问题不在工具而是你一次性塞给模型太多规则它反而不知道以哪个为准。我的做法是一次只激活一个技能其他保持默认。先用两天“write-tests”等稳定了再加“debugging”让AI逐步适应也让你的使用习惯逐步建立。6.2 技能是“流程”不是“结果”要配合人工判断这句话可能有人不爱听但我必须说superpowers不会让你的AI瞬间变成高级工程师。它最大的作用是让AI的“行为过程”更规范——先分析再动手、先列用例再写代码、先定位再修复。但最终结果对不对还是要人来判断。我在用调试技能排查一个并发问题时AI给出的假设方向是对的但真正落实到锁的粒度调整仍然是我自己的经验在把关。所以我对这个工具的定义是项目管理的AI执行框架不是水平放大器。它让过程可控但不能替代你本身的技术判断力。6.3 对团队协作的建议把技能文件纳入版本管理如果你打算在团队里推广强烈建议把自定义技能文件放到Git仓库里管理和项目代码一起走。这样新同事进来clone完代码就自带团队AI规范不用一个一个手动配置。我目前就是把技能文件放在一个独立目录通过软链接指到AI工具的配置目录这样更新时只改仓库里的源文件就行。6.4 触发技能时的“提示词锚点”技巧很多工具触发技能靠的是“技能名称”的匹配所以怎么在你的工作指令里带上锚点很关键。我的习惯是写任务描述时加上按superpowers的写测试技能执行这类前缀模型几乎每次都能正确识别并切换流程。如果你发现触发不稳定可以试着在指令里引用技能文档的标题而不只是文件名。6.5 上下文预算管理技能文件本身也吃上下文这是很多人忽略的问题。技能文件再精简也是要占上下文窗口的如果一次加载几十个技能模型的有效记忆空间会明显变小反而影响代码生成的连贯性。我的实践是按项目类型选择技能包Web前后端项目只加载测试、调试、代码评审三个核心技能做工具库微服务的时候再加一个文档生成技能。保持“够用就好”的原则别让上下文全被技能规则占满。7. 我踩过的几个坑以及对应的排查思路最后这部分比较务实把我遇到过的真实问题、当时的排查逻辑和最终的解决方案写一下。这些坑大部分没有写进官方文档属于“试过才知道”的经验。7.1 坑一安装了但技能列表为空排查了半小时现象是安装命令执行完毕启动AI工具后输入技能列表命令却什么都没有。我先检查了配置目录——技能文件夹存在文件也有内容然后怀疑是权限问题但重装后依旧最后发现是配置文件里有一段旧的缓存语法和新版不兼容导致整个配置被模型解析阶段静默丢弃了一部分。清理掉旧配置文件、重新安装后解决。这里学到的排查思路是不要只盯着“文件是否存在”要确认文件里的内容有没有被真正加载。7.2 坑二技能触发后模型把“分析步骤”和“代码实现”混在一起输出这个问题出在我同时激活了“测试技能”和另一个自带的“思考技能”。两个技能都在教AI“先想再做”但它们定义的步骤顺序不一样模型无所适从。解决方式是停用其中一个。所以我前面强调“一次只开一个技能”不是保守是真的会冲突。7.3 坑三Java项目里技能生成的测试代码风格和团队不一致它生成的测试虽然结构完整但命名风格是should_xxx这种英文下划线风格而我们团队约定的是中文业务描述风格的测试名。我一开始以为是AI没学好后来发现是因为技能文档里给了测试方法命名的默认规范而项目代码里缺少对命名规范的示例AI自然按技能模板走了。解决方法是把团队测试规范写成一个自定义技能片段放在测试技能后面让它覆盖默认规则。7.4 坑四自定义技能文件写好后不生效这个问题我和朋友讨论过多次最后定位到是文件放置目录不对。有些AI工具只扫描配置目录下面第一层的技能文件不递归扫描子目录。我自定义的技能放在subfolder/my-skill.md系统压根不认。放到第一层后就正常了。如果你自定义技能不生效第一反应先看目录层级而不是看内容。7.5 坑五以为“技能越多越强”结果上下文爆炸有一段时间我为了追求“全面”一口气把自带技能全开结果模型写代码变得畏手畏脚——每一步都要先列一堆分析连写个工具函数都磨磨蹭蹭。这就是典型的上下文和注意力被技能规则稀释了。后来我通过给每个技能设定“使用范围说明”让模型只在真正遇到复杂任务时才切换到完整流程日常小改动仍然走默认模式体验立刻好了很多。这个经验给我最大的启发是框架可以给你超能力但你得决定什么时候使用它。无关紧要的任务让它快速输出真正复杂的问题再让技能跑完整流程。8. 最后说点个人体会玩了两周superpowers我最大的感受是AI编程工具的下一个阶段可能不是模型本身变大而是“怎么让模型的每一次输出都稳定在某个水平线上”。superpowers用一套可扩展的、可写的技能框架让这件事变得可控。如果你刚接触不要急着追求“全家桶”先把测试技能用好让它帮你建立“先分析再编码”的惯性。等习惯了这套工作节奏再慢慢把调试、代码评审这些技能加进来。如果你是用Codex CLI的用户或者Java栈的开发者更不用纠结“是不是原生支持”——技能这个方法论的迁移成本很低抄走它最核心的几页你就能在自己的工具链里复制出90%的效果。大概就是这些。后面我如果折腾出有意思的新用法再来继续分享。
