1. 先说结论superpowers 到底是个什么东西如果你最近在逛开发者社区、技术群或者 GitHub 趋势榜大概率会撞见这个叫 superpowers 的项目。我第一次看到这个名字第一反应是哪个中二病起的项目名但翻完 README 和源码之后我得说这名字起得挺诚实——它就是给你手头的 AI 编程工具再叠一层 buff。简单来说superpowers 是一套开源 AI 编程增强技能包。它不替代你现有的 AI 编程工具比如 Codex、Claude Code 或类似命令行工具而是给它们注入一套更结构化的工作方法。打个比方原来的 AI 助手像一个刚毕业的高材生知识面广、反应快但缺乏项目实战里那一套先看全局、再拆任务、逐个验证的做事章法。superpowers 做的事情就是把这套章法以技能skills的形式喂给 AI让它从会聊天变成会干活。这个项目适合的人很明确希望在真实项目里用 AI 辅助写代码、但又觉得默认交互方式不够可靠的开发者。如果你只是拿它玩一玩、生成点零散代码片段那用不用这个都无所谓但如果你想让它帮你改一个模块、重构一段逻辑、排查一个 bug或者接手一个你不太熟悉的中大型代码仓库superpowers 能明显减少AI 一顿操作、结果方向全错的挫败感。我花了两周时间在个人项目和几个 Java 工程里实际用了它也踩了一些坑。这篇文章不打算复述 README我尽量把这工具到底改变了什么、怎么装、怎么用、什么场景下真的有用、什么场景下别指望它讲清楚。2. 核心原理它不是给你一个更强的模型而是给模型一套做事规范2.1 为什么默认状态下的 AI 编程助手不够顺手先聊一个很多人忽略的问题Codex、Claude Code 这类工具底层的语言模型能力其实已经很强了单看理解自然语言和生成代码片段的能力它们远超多数人的预期。但为什么你真正让它做一件跨文件、跨模块的事情时它经常跑偏问题通常出在工作方式上。默认交互是你问一句、它答一句AI 会基于你当前给的信息和你之前几轮的对话直接生成一个大答案。但真实项目里一个功能往往涉及多个文件、多种约束、既有代码风格和历史设计决策。AI 没有主动去看这些上下文它只是在猜测你想要的答案。打个比方你请一个帮手来改造你家厨房他能力很强什么工具都会用但他进门之后先不转一圈、不看看你家管道怎么走的直接问你你想怎么改我马上动手。你说了几句需求他立刻掏出电钻开始拆墙。结果呢很可能拆错墙、打穿水管。superpowers 的作用就是给这个帮手立了一整套规矩先勘察现场、列出问题清单、给出施工方案、确认后再动手、每做完一步都检查一下。2.2 superpowers 改变工作流的关键节点具体到实操层面superpowers 会把你和 AI 的协作流程切成几个阶段开始阶段先让 AI 确认对项目的理解包括项目类型、构建工具、目录结构、入口点、测试方式等。这一步看起来慢实际上能省掉后面大量返工。规划阶段要求 AI 把任务拆成可验证的小步骤而不是一次性丢给你一个大 diff。拆完之后它会和你确认每一步的目标和验收标准。执行阶段每一步都小步快走。改一个小文件、运行相关测试、确认无误再做下一步。这个节奏和资深工程师的日常操作非常接近。检查阶段改完一个单元之后AI 会被要求主动检查是否引入副作用比如改了公共工具类会不会影响其他调用方而不是只盯着自己刚写的函数。这套流程拆开看每一件事都平平无奇但合在一起就把 AI 从一个很会接话的同事变成了一个流程遵守得极好的结对程序员。2.3 它是怎么实现这套规范的superpowers 并不是一个需要你手动来回点击切换的复杂系统。它的核心是一系列skills 文件——你可以把这些文件理解成给 AI 看的岗位手册或者SOP 文档。每个 skill 对应一类任务场景里面用非常具体的指令告诉 AI面对这个场景你应该按什么顺序做事、每一步要输出什么、怎么才算完成。比如当你让 AI 去添加一个新功能它会加载对应的 skill按照里面的规范先输出对需求的理解再列出需要阅读的文件清单然后逐个文件阅读、记录关键信息最后才给出实施方案。这个过程里你作为用户能清楚地看到 AI 的思考轨迹也能在早期就拦住它可能会跑偏的方向。这种做法的高明之处在于它不依赖某一个特定模型。换一个模型只要这个模型能读文本指令、能执行文件操作这套规范就依然有效。所以它更像是在给所有 AI 编程工具打上一个通用的方法论补丁。3. 安装与接入比你想象中简单但有几个前置工作别跳过3.1 安装前先确认环境我最初犯的错是没仔细看环境要求直接把项目拉下来就跑结果在一个旧版 Node 环境里折腾了半天。所以先说清楚正常使用 superpowers你需要准备这几样必需项说明备注Git拉取项目源码一般都有Node.js建议 LTS 或较新版本运行脚本和命令行工具版本太旧某些语法糖会报错AI 编程工具Codex、Claude Code 或支持 skills 机制的同类工具需确认该工具具备文件读写和命令执行能力这些条件对做开发的读者来说基本不算门槛。真正容易被忽略的是你得清楚自己用的 AI 工具是否支持加载外部技能文件。有的工具是内置插件市场有的是读取固定目录下的指令文件有的可能暂时还不支持。我是先翻了官方文档确认支持方式之后才开始装的这一步其实省了很多事。3.2 安装步骤照做就行坦白说安装命令就那么一两条但为了让你少走弯路我把我的实操路径写完整一点先把 superpowers 项目克隆到本地。我习惯放在~/tools/superpowers这种目录方便统一管理。进入目录执行安装命令。具体命令项目 README 里写得很清楚本质是把技能文件软链symlink到你 AI 工具读取技能的那个目录里。检查软链是否成功。这一步别省直接去看你 AI 工具的 skills 目录下是否多出了几个子文件夹。启动你的 AI 编程工具输入一个简单的测试任务观察它的行为是否出现了先规划、再执行的变化。安装完之后要做的第一件事不是急着接大项目而是跑一遍自带测试。我用的做法是让 AI 在一个临时目录里创建一个极小的 Demo 项目让它从零开始加一个功能。这样做能在低风险环境里验证技能包是否真正生效。3.3 验证是否真正生效别只信安装日志有个很现实的问题安装命令执行成功了skill 文件也放进去了但 AI 工具在实际对话中就是表现不出该有的规范。我遇到过两种情况一种是 AI 工具和 superpowers 的兼容版本问题skill 文件加载了但没被正确解析表现就是 AI 依然我行我素、直接给大答案。另一种是对话上下文太长之后AI 忘了遵循技能文件里的规范又开始自由发挥。针对第一种解决方式是检查版本兼容性、看 AI 工具的日志输出。针对第二种解决办法比较原始但有效——在提示词里明确提醒一次比如直接告诉它请先按 superpowers 的规范输出你对项目的理解和任务拆解然后再动手。这不算什么高级技巧但实测下来能很大程度把跑偏的 AI 拉回正轨。顺便说一句很多人在这一步会犯装好了就当它永远生效的毛病。实际上 AI 的上下文窗口有限会话中途某些规范可能被遗忘所以你需要在关键时刻补一句提醒。这和带新人是一个道理光发给他一本员工手册是不够的重要项目节点上还是得口头嘱咐一句。4. 真实项目体验我在一个 Java 服务里用它做重构的完整记录4.1 为什么拿 Java 项目来试市面上很多 AI 编程工具的演示项目都是 Python 或 JavaScript因为脚本语言改起来快、验证成本低。但现实世界里大量业务系统是 Java 写的尤其是一些有点年头的 Spring Boot 服务动不动就是几十个类、多套环境配置、各种自定义注解。这类项目恰恰是 AI 最容易翻车的场景——它有时候会无视 Spring 的 Bean 管理机制给你生成一个既不参与容器管理、又没考虑事务边界的类。我决定用 superpowers 在这样一个 Java 工程里试水。这个工程不是我写的是接手的一个旧模块结构不算混乱但缺乏文档。平时我自己改也要花不少时间先摸清脉络。我想看看 superpowers 能不能让 AI 在未知代码库里的表现达到一个可用的水平。4.2 任务描述一个典型的改一处、带一串的需求我给出的任务是给现有订单状态查询接口增加一个缓存逻辑缓存 key 需要包含租户 ID 和订单状态TTL 设置为 5 分钟。如果是默认的 AI 交互很可能会发生这样的对话AI 直接给你生成一个CacheManager或RedisTemplate的使用代码告诉你在 Service 里加几行就行。但它不会告诉你这个接口是否已经有一个统一返回结构、是否在某些地方还被内部调用、缓存失效策略是否和现有配置冲突。在启用了 superpowers 之后AI 的第一步完全不一样。它先是输出了一份项目勘察笔记列出了它需要阅读的文件Controller、Service 实现类、Mapper、Redis 配置类、统一的返回类型定义。然后它真的逐个读了这些文件并且是在动手之前读的。这里有一个细节值得说明AI 的阅读不是像人一样一行行扫它会自动提取文件里的关键符号、方法签名、注解信息。但这一步非常必要因为后面的所有决定都依赖于这些基础信息。我自己以前用 AI 改代码经常发现它生成的代码里引用了不存在的工具类或者方法名和上下文不匹配根源就在这里——它没有提前做信息收集。4.3 执行过程中的两个关键节点第一次比较大的分歧点出现在缓存 key 设计上。AI 最初提出的方案是直接用租户 ID 加订单状态拼字符串。听起来没问题但我追问了一句现有代码里有没有统一的 Redis key 前缀规范AI 回去翻了工具类之后发现工程里所有的缓存 key 都带一个业务前缀并且要经过一个CacheKeyBuilder生成。于是它主动修改了方案改用现有的 builder而不是另起炉灶。这个自觉性让我有点意外因为默认状态下AI 很少会主动问自己现有的规范是什么。第二个关键节点是缓存更新策略。需求只说了查询加缓存但更严谨的做法是在订单状态变更的时候同步淘汰缓存。AI 在读完相关代码后主动提出只加缓存会导致并发下读取到旧状态并建议额外修改订单状态更新的地方增加缓存删除逻辑。最终我把这个建议也纳入了改动范围。这个体验其实回答了很多人对 superpowers 的疑问它并没有让 AI 变得更聪明但它让 AI 变得更严谨。同样的大模型默认模式是你问什么我答什么开启技能包之后变成了你要什么我先确认边界再按工程规范执行。对一个真实项目来说后者显然更重要。4.4 和 Codex 配合时候的实测感受因为热搜词里出现了 codex superpowers我也特意在 Codex 环境下做了对比测试。给我的感受是Codex 本身的代码生成能力很出色对 Java 的掌握也到位但缺少工程流程约束。比如你让它直接改一个方法它可能给你一个完美的单点修改但它不太会主动意识到这里需要同步更新测试这里需要检查调用方。加上 superpowers 之后Codex 的回复风格产生了明显变化它会先给一个执行计划按部就班地列出步骤每完成一步给一个简短的确认信息。这个变化对新手尤其友好因为你能在它动手之前就看出它有没有理解你的意图。如果你发现它第一步就走错了你完全来得及喊停而不用等它生成完整个 diff 之后才发现方向全错了。需要注意的是Codex 和 superpowers 的集成偶尔会有一些小摩擦最典型的是技能文件指向的指令和 Codex 自身内置的一些行为准则存在重叠或冲突。遇到这种情况处理方式一般是调整 superpowers 的配置项、禁用掉某个具体技能或者修改配置文件里的优先级。这块没有标准答案就是按照报错信息一步步试。5. Java 场景下的实践细节模型能力之外工程约束才是关键5.1 Java 项目对 AI 的隐含要求更多很多人拿 Java 项目用 AI 助手觉得不灵光吐槽点往往是它不懂 Spring 特性它对依赖注入的理解太表面它给出了一段编译通过的代码但放进项目里运行就报错。我承认这些吐槽有道理但换个角度想Java 生态里的隐式约束确实比 Python 那类自由风格的语言多太多。什么算隐式约束比如类要被 Spring 管理你才能够在里面用Autowired或构造器注入一个接口的返回结构定了你最好别在局部直接抛异常而是走全局异常处理器表结构变更了对应的实体、DTO、Mapper XML 都得同步改。这些约束不像语法错误那么显性AI 如果不是有意去检查很容易忽略。superpowers 在处理这类问题时相当于给 AI 加了一层检查清单。它会提醒 AI 在生成代码时注意依赖注入方式是否和项目内现有代码风格一致注意是否引用了不存在的配置项注意新类是否需要注册到配置类里。这些提醒叠加起来对 Java 项目的帮助特别直观。5.2 如果 AI 非要自定义一套轮子怎么办一个高频出现的尴尬场景是项目里明明有现成的工具类AI 偏要自己再写一个功能差不多的或者非要引入一个新的依赖来实现本可以用已有代码完成的事情。在默认交互模式里你通常要自己花时间指出这一点AI 才会回头看项目里有没有现成的实现。用了 superpowers 之后它的技能文件里写了一条很关键的指令动手前检查项目中是否已有可复用的工具类或服务优先复用现有代码而不是新造轮子。这条指令在项目比较庞杂的时候尤其有效。我的实测感受是它确实降低了AI 自作主张引入新依赖的频率。不过也不能完全指望它如果你发现它在某个具体任务里还是造了一个多余的类你需要指出来它一般会很快调整。5.3 测试的重要性比你以为的还高还有一个使用习惯想特别强调让 AI 改完代码之后主动要求它补测试或者跑测试。不是所有任务都需要补测试但只要是核心业务逻辑这一步都建议保留。我在 Java 工程里的体验是superpowers 的规范流程中通常会包含运行测试验证改动的环节。对有测试基础的工程这是很好的闭环但如果工程本身测试覆盖很差老项目常见这个环节就形同虚设。这种情况下我会在提示词里额外让 AI 至少做一次编译检查或者启动一个最小上下文来验证依赖注入是否正常。别小看这个动作它能拦下很多静态看起来正确、运行时直接报错的改动。6. 配置选型与常见冲突几个你迟早会遇到的坑6.1 技能文件不是越多越好第一次了解 superpowers 这个项目的人很容易有一个动作把所有 skills 一次性全部启用。我也这么干过。实际效果是灾难性的——AI 在收到一个普通任务时会尝试同时加载好几个技能规范反而不知道该听谁的。有些规范彼此还会冲突比如一个技能要求先给完整计划另一个技能要求快速直接动手模型有时候会宕机返回一个四不像的答案。后来我调整了方式一个会话只聚焦启用相关的一两个技能。比如做重构任务就只让它遵守重构相关的规范做新功能开发就只加载新功能开发的规范。这个调整之后AI 的表现立刻稳定了很多。这就像给员工发手册一次给十本他大概率什么都记不住一次只强调最重要的一本他反而能执行到位。6.2 与内置指令的优先级冲突如果你用的 AI 工具自身也有思考规范比如有些工具默认要求 AI 在最终回答前输出推理过程那么 superpowers 的某些指令可能会和它发生优先级冲突。一个明显的表现是AI 的回复变得啰嗦一边按工具内置规范说话一边又按 superpowers 的技能规范做事前后风格不一致。我遇到这个情况后采取的方案是在工具配置文件里把其中一套规范设为后备也就是只在另一套缺失时才生效。具体怎么操作取决于你用的工具但总原则是——不要让 AI 同时执行两套高优先级的行为约束选定一套为主另一套作为补充即可。6.3 版本更新一条命令解决的问题别乱手动改superpowers 的开发活跃度不算低技能文件的更新有时候会带来行为上的变化。我有一次手动在技能目录里加了自己的几条自定义规则之后项目一更新自动合并把我加的规则搞乱了导致 AI 行为异常了挺久排查起来很痛苦。后来我学乖了自定义规则尽量新建独立文件不要改动仓库自带文件。这样项目更新的时候只需要正常拉取最新代码、重新执行安装命令就行。如果你改了自带文件每次更新版本都要检查冲突非常容易出问题。7. 提示词写法的变化用 superpowers 之后你怎么和 AI 说话更高效7.1 任务描述里多一个约束条件维度很多人觉得 superpowers 是给 AI 用的规范和用户写提示词没关系。我的实际体验恰恰相反——你现在写提示词的方式也应该跟着变。以前我写需求会尽量详细描述结果比如写一个函数输入 A输出 B。但现在我意识到superpowers 更擅长处理有边界、有约束的任务所以我写提示词的时候会刻意补上两类信息一是约束条件比如不要引入新的 Redis 客户端依赖复用现有的OrderQueryService里的方法二是验收标准比如改完跑一遍mvn test -DtestOrderQueryServiceTest。这两个额外信息会显著提高 AI 一次做对的概率。原理也不难理解——你的约束信息帮它缩小了搜索空间验收标准又给了它一个明确的完成信号。相比之下只说帮我优化一下这个接口这种开放式需求即使有 superpowers 加持效果也有限。7.2 分阶段对话 vs 一次性大需求很多新用户习惯用一整段话来描述一个复杂需求帮我重构这个模块然后把日志加上还有不要影响原有接口的返回格式另外最好加个缓存。讲真这种一次性的复杂需求对任何 AI 工具都是不小的挑战。有了 superpowers 之后我建议把它当成一个更正式的协作者改成分阶段对话。比如第一阶段只说我想重构这个模块先帮我梳理当前的依赖关系和调用链不要改代码等它输出分析结果后再进入第二阶段基于上面的依赖关系帮我重写 Service 层的实现保持接口签名不变最后再提补全单元测试并运行验证。这种方式看起来多花了几轮对话实际上每一轮的目标都极明确AI 出错的概率大幅下降。7.3 关于重新加载技能这个小技巧会话进行到中后段的时候如果 AI 的行为开始偏离人设变得像一个普通的对话模型有一个很实用的小伎俩在对话里输入一条类似请重新阅读并遵守所有已加载技能的规范的指令。实测中这往往能让模型重新聚焦。原理我推测和上下文窗口里的注意力衰减有关——早期加载的技能规范在长篇对话中逐渐被后续信息冲淡了权重重新提示一次就相当于拉回注意力。这个技巧不算什么高深的东西但很好用。8. 实际收益与边界哪些事不该指望 superpowers8.1 它能给你什么用了这段时间我对这个项目的评价是正向的。它主要带来了三点改变减少无效改动。AI 动手前先看项目上下文这个习惯本身就能过滤掉很多错误方案。让 AI 的行为可预测。你不会再遇到让它改个接口它顺手把整个 Controller 重写了的惊吓。提升对 AI 的信任度。以前我给它派活总忍不住守在旁边盯着现在流程规范了我敢让它独立做一些局部改动再统一 review。这种改变不一定会在代码功能上带来肉眼可见的性能提升但对团队协作的体验、对项目代码风格的维护帮助是实打实的。8.2 它的边界在哪里同时必须说清楚superpowers 不是银弹。有几个场景我个人不太建议对它抱有太高期待需求本身模糊不清的时候。你让 AI把用户体验优化一下这种大词谁都处理不了。superpowers 再怎么规范流程也架不住任务目标本身是虚的。系统性架构调整。比如要把一个单体服务拆成微服务这种级别的改动涉及大量业务判断和架构权衡目前的 AI 工具配合技能包也只能做执行层面的辅助还不能承担真正的架构决策。项目上下文极其庞大且混乱的情况。如果代码库里垃圾代码太多、依赖关系一团乱麻AI 读文件的开销会很大效果也会打折扣。这种情况下先做人工清理比强行上 AI 效率高。8.3 移民过来的老项目需要额外耐心有些老项目的代码结构比较实在类名、方法名可能已经和实际功能严重不符比如一个叫UserServiceImpl的类里塞满了订单逻辑。这种命名腐烂对 AI 的误导非常严重。superpowers 的流程会在一开始要求 AI 梳理项目结构但 AI 看到的只是现状它没法自己识破这个类名字和实际功能不符这种历史遗留问题。应对办法是你得在提示词里提前打补丁注意项目里存在命名和实际功能不一致的情况梳理依赖的时候要按实际调用关系来不要仅凭类名下结论。这样做之后AI 的准确率会提升很多。这个经验也算是我在整理老项目时摸索出来的土办法但对项目里的 AI 协作非常有价值。9. 最后分享一点个人使用心得如果你也想在自己的工作流里引入 superpowers我给的建议不是先去搜一堆使用教程也不是一次性把项目全部技能都看完而是先找一个中等复杂度的旧任务——就是你手头那个说简单不简单、说难也不难的任务——按它规定的流程完整跑一遍。这个过程中你自然会感受到它和默认模式的差别也自然会暴露出哪些地方需要你调参、哪些技能对你当前项目没意义。我在几次踩坑之后形成的一个习惯是每次新开会话先花一两句话把当前任务的目标、约束、验收标准一次性说清楚。这不是 superpowers 文档里要求的事但和它配合起来效果格外好。这套组合用熟了以后AI 在项目里的角色会从偶尔灵光一现的代码片段生成器慢慢转变成一个流程感还不错、但需要你把关方向的项目协作者。最后再补一句关于安装的真心话如果你的 AI 工具版本比较新装完 superpowers 之后发现行为没有变化别急着怀疑项目出了问题。先确认技能文件的加载路径、确认当前对话模型确实支持读取这些文件再考虑是不是有配置项遗漏。绝大多数装了没效果的问题根源都是这一类环境层面的小细节。
superpowers开源技能包：让AI编程助手从“会聊天”到“会干活”
1. 先说结论superpowers 到底是个什么东西如果你最近在逛开发者社区、技术群或者 GitHub 趋势榜大概率会撞见这个叫 superpowers 的项目。我第一次看到这个名字第一反应是哪个中二病起的项目名但翻完 README 和源码之后我得说这名字起得挺诚实——它就是给你手头的 AI 编程工具再叠一层 buff。简单来说superpowers 是一套开源 AI 编程增强技能包。它不替代你现有的 AI 编程工具比如 Codex、Claude Code 或类似命令行工具而是给它们注入一套更结构化的工作方法。打个比方原来的 AI 助手像一个刚毕业的高材生知识面广、反应快但缺乏项目实战里那一套先看全局、再拆任务、逐个验证的做事章法。superpowers 做的事情就是把这套章法以技能skills的形式喂给 AI让它从会聊天变成会干活。这个项目适合的人很明确希望在真实项目里用 AI 辅助写代码、但又觉得默认交互方式不够可靠的开发者。如果你只是拿它玩一玩、生成点零散代码片段那用不用这个都无所谓但如果你想让它帮你改一个模块、重构一段逻辑、排查一个 bug或者接手一个你不太熟悉的中大型代码仓库superpowers 能明显减少AI 一顿操作、结果方向全错的挫败感。我花了两周时间在个人项目和几个 Java 工程里实际用了它也踩了一些坑。这篇文章不打算复述 README我尽量把这工具到底改变了什么、怎么装、怎么用、什么场景下真的有用、什么场景下别指望它讲清楚。2. 核心原理它不是给你一个更强的模型而是给模型一套做事规范2.1 为什么默认状态下的 AI 编程助手不够顺手先聊一个很多人忽略的问题Codex、Claude Code 这类工具底层的语言模型能力其实已经很强了单看理解自然语言和生成代码片段的能力它们远超多数人的预期。但为什么你真正让它做一件跨文件、跨模块的事情时它经常跑偏问题通常出在工作方式上。默认交互是你问一句、它答一句AI 会基于你当前给的信息和你之前几轮的对话直接生成一个大答案。但真实项目里一个功能往往涉及多个文件、多种约束、既有代码风格和历史设计决策。AI 没有主动去看这些上下文它只是在猜测你想要的答案。打个比方你请一个帮手来改造你家厨房他能力很强什么工具都会用但他进门之后先不转一圈、不看看你家管道怎么走的直接问你你想怎么改我马上动手。你说了几句需求他立刻掏出电钻开始拆墙。结果呢很可能拆错墙、打穿水管。superpowers 的作用就是给这个帮手立了一整套规矩先勘察现场、列出问题清单、给出施工方案、确认后再动手、每做完一步都检查一下。2.2 superpowers 改变工作流的关键节点具体到实操层面superpowers 会把你和 AI 的协作流程切成几个阶段开始阶段先让 AI 确认对项目的理解包括项目类型、构建工具、目录结构、入口点、测试方式等。这一步看起来慢实际上能省掉后面大量返工。规划阶段要求 AI 把任务拆成可验证的小步骤而不是一次性丢给你一个大 diff。拆完之后它会和你确认每一步的目标和验收标准。执行阶段每一步都小步快走。改一个小文件、运行相关测试、确认无误再做下一步。这个节奏和资深工程师的日常操作非常接近。检查阶段改完一个单元之后AI 会被要求主动检查是否引入副作用比如改了公共工具类会不会影响其他调用方而不是只盯着自己刚写的函数。这套流程拆开看每一件事都平平无奇但合在一起就把 AI 从一个很会接话的同事变成了一个流程遵守得极好的结对程序员。2.3 它是怎么实现这套规范的superpowers 并不是一个需要你手动来回点击切换的复杂系统。它的核心是一系列skills 文件——你可以把这些文件理解成给 AI 看的岗位手册或者SOP 文档。每个 skill 对应一类任务场景里面用非常具体的指令告诉 AI面对这个场景你应该按什么顺序做事、每一步要输出什么、怎么才算完成。比如当你让 AI 去添加一个新功能它会加载对应的 skill按照里面的规范先输出对需求的理解再列出需要阅读的文件清单然后逐个文件阅读、记录关键信息最后才给出实施方案。这个过程里你作为用户能清楚地看到 AI 的思考轨迹也能在早期就拦住它可能会跑偏的方向。这种做法的高明之处在于它不依赖某一个特定模型。换一个模型只要这个模型能读文本指令、能执行文件操作这套规范就依然有效。所以它更像是在给所有 AI 编程工具打上一个通用的方法论补丁。3. 安装与接入比你想象中简单但有几个前置工作别跳过3.1 安装前先确认环境我最初犯的错是没仔细看环境要求直接把项目拉下来就跑结果在一个旧版 Node 环境里折腾了半天。所以先说清楚正常使用 superpowers你需要准备这几样必需项说明备注Git拉取项目源码一般都有Node.js建议 LTS 或较新版本运行脚本和命令行工具版本太旧某些语法糖会报错AI 编程工具Codex、Claude Code 或支持 skills 机制的同类工具需确认该工具具备文件读写和命令执行能力这些条件对做开发的读者来说基本不算门槛。真正容易被忽略的是你得清楚自己用的 AI 工具是否支持加载外部技能文件。有的工具是内置插件市场有的是读取固定目录下的指令文件有的可能暂时还不支持。我是先翻了官方文档确认支持方式之后才开始装的这一步其实省了很多事。3.2 安装步骤照做就行坦白说安装命令就那么一两条但为了让你少走弯路我把我的实操路径写完整一点先把 superpowers 项目克隆到本地。我习惯放在~/tools/superpowers这种目录方便统一管理。进入目录执行安装命令。具体命令项目 README 里写得很清楚本质是把技能文件软链symlink到你 AI 工具读取技能的那个目录里。检查软链是否成功。这一步别省直接去看你 AI 工具的 skills 目录下是否多出了几个子文件夹。启动你的 AI 编程工具输入一个简单的测试任务观察它的行为是否出现了先规划、再执行的变化。安装完之后要做的第一件事不是急着接大项目而是跑一遍自带测试。我用的做法是让 AI 在一个临时目录里创建一个极小的 Demo 项目让它从零开始加一个功能。这样做能在低风险环境里验证技能包是否真正生效。3.3 验证是否真正生效别只信安装日志有个很现实的问题安装命令执行成功了skill 文件也放进去了但 AI 工具在实际对话中就是表现不出该有的规范。我遇到过两种情况一种是 AI 工具和 superpowers 的兼容版本问题skill 文件加载了但没被正确解析表现就是 AI 依然我行我素、直接给大答案。另一种是对话上下文太长之后AI 忘了遵循技能文件里的规范又开始自由发挥。针对第一种解决方式是检查版本兼容性、看 AI 工具的日志输出。针对第二种解决办法比较原始但有效——在提示词里明确提醒一次比如直接告诉它请先按 superpowers 的规范输出你对项目的理解和任务拆解然后再动手。这不算什么高级技巧但实测下来能很大程度把跑偏的 AI 拉回正轨。顺便说一句很多人在这一步会犯装好了就当它永远生效的毛病。实际上 AI 的上下文窗口有限会话中途某些规范可能被遗忘所以你需要在关键时刻补一句提醒。这和带新人是一个道理光发给他一本员工手册是不够的重要项目节点上还是得口头嘱咐一句。4. 真实项目体验我在一个 Java 服务里用它做重构的完整记录4.1 为什么拿 Java 项目来试市面上很多 AI 编程工具的演示项目都是 Python 或 JavaScript因为脚本语言改起来快、验证成本低。但现实世界里大量业务系统是 Java 写的尤其是一些有点年头的 Spring Boot 服务动不动就是几十个类、多套环境配置、各种自定义注解。这类项目恰恰是 AI 最容易翻车的场景——它有时候会无视 Spring 的 Bean 管理机制给你生成一个既不参与容器管理、又没考虑事务边界的类。我决定用 superpowers 在这样一个 Java 工程里试水。这个工程不是我写的是接手的一个旧模块结构不算混乱但缺乏文档。平时我自己改也要花不少时间先摸清脉络。我想看看 superpowers 能不能让 AI 在未知代码库里的表现达到一个可用的水平。4.2 任务描述一个典型的改一处、带一串的需求我给出的任务是给现有订单状态查询接口增加一个缓存逻辑缓存 key 需要包含租户 ID 和订单状态TTL 设置为 5 分钟。如果是默认的 AI 交互很可能会发生这样的对话AI 直接给你生成一个CacheManager或RedisTemplate的使用代码告诉你在 Service 里加几行就行。但它不会告诉你这个接口是否已经有一个统一返回结构、是否在某些地方还被内部调用、缓存失效策略是否和现有配置冲突。在启用了 superpowers 之后AI 的第一步完全不一样。它先是输出了一份项目勘察笔记列出了它需要阅读的文件Controller、Service 实现类、Mapper、Redis 配置类、统一的返回类型定义。然后它真的逐个读了这些文件并且是在动手之前读的。这里有一个细节值得说明AI 的阅读不是像人一样一行行扫它会自动提取文件里的关键符号、方法签名、注解信息。但这一步非常必要因为后面的所有决定都依赖于这些基础信息。我自己以前用 AI 改代码经常发现它生成的代码里引用了不存在的工具类或者方法名和上下文不匹配根源就在这里——它没有提前做信息收集。4.3 执行过程中的两个关键节点第一次比较大的分歧点出现在缓存 key 设计上。AI 最初提出的方案是直接用租户 ID 加订单状态拼字符串。听起来没问题但我追问了一句现有代码里有没有统一的 Redis key 前缀规范AI 回去翻了工具类之后发现工程里所有的缓存 key 都带一个业务前缀并且要经过一个CacheKeyBuilder生成。于是它主动修改了方案改用现有的 builder而不是另起炉灶。这个自觉性让我有点意外因为默认状态下AI 很少会主动问自己现有的规范是什么。第二个关键节点是缓存更新策略。需求只说了查询加缓存但更严谨的做法是在订单状态变更的时候同步淘汰缓存。AI 在读完相关代码后主动提出只加缓存会导致并发下读取到旧状态并建议额外修改订单状态更新的地方增加缓存删除逻辑。最终我把这个建议也纳入了改动范围。这个体验其实回答了很多人对 superpowers 的疑问它并没有让 AI 变得更聪明但它让 AI 变得更严谨。同样的大模型默认模式是你问什么我答什么开启技能包之后变成了你要什么我先确认边界再按工程规范执行。对一个真实项目来说后者显然更重要。4.4 和 Codex 配合时候的实测感受因为热搜词里出现了 codex superpowers我也特意在 Codex 环境下做了对比测试。给我的感受是Codex 本身的代码生成能力很出色对 Java 的掌握也到位但缺少工程流程约束。比如你让它直接改一个方法它可能给你一个完美的单点修改但它不太会主动意识到这里需要同步更新测试这里需要检查调用方。加上 superpowers 之后Codex 的回复风格产生了明显变化它会先给一个执行计划按部就班地列出步骤每完成一步给一个简短的确认信息。这个变化对新手尤其友好因为你能在它动手之前就看出它有没有理解你的意图。如果你发现它第一步就走错了你完全来得及喊停而不用等它生成完整个 diff 之后才发现方向全错了。需要注意的是Codex 和 superpowers 的集成偶尔会有一些小摩擦最典型的是技能文件指向的指令和 Codex 自身内置的一些行为准则存在重叠或冲突。遇到这种情况处理方式一般是调整 superpowers 的配置项、禁用掉某个具体技能或者修改配置文件里的优先级。这块没有标准答案就是按照报错信息一步步试。5. Java 场景下的实践细节模型能力之外工程约束才是关键5.1 Java 项目对 AI 的隐含要求更多很多人拿 Java 项目用 AI 助手觉得不灵光吐槽点往往是它不懂 Spring 特性它对依赖注入的理解太表面它给出了一段编译通过的代码但放进项目里运行就报错。我承认这些吐槽有道理但换个角度想Java 生态里的隐式约束确实比 Python 那类自由风格的语言多太多。什么算隐式约束比如类要被 Spring 管理你才能够在里面用Autowired或构造器注入一个接口的返回结构定了你最好别在局部直接抛异常而是走全局异常处理器表结构变更了对应的实体、DTO、Mapper XML 都得同步改。这些约束不像语法错误那么显性AI 如果不是有意去检查很容易忽略。superpowers 在处理这类问题时相当于给 AI 加了一层检查清单。它会提醒 AI 在生成代码时注意依赖注入方式是否和项目内现有代码风格一致注意是否引用了不存在的配置项注意新类是否需要注册到配置类里。这些提醒叠加起来对 Java 项目的帮助特别直观。5.2 如果 AI 非要自定义一套轮子怎么办一个高频出现的尴尬场景是项目里明明有现成的工具类AI 偏要自己再写一个功能差不多的或者非要引入一个新的依赖来实现本可以用已有代码完成的事情。在默认交互模式里你通常要自己花时间指出这一点AI 才会回头看项目里有没有现成的实现。用了 superpowers 之后它的技能文件里写了一条很关键的指令动手前检查项目中是否已有可复用的工具类或服务优先复用现有代码而不是新造轮子。这条指令在项目比较庞杂的时候尤其有效。我的实测感受是它确实降低了AI 自作主张引入新依赖的频率。不过也不能完全指望它如果你发现它在某个具体任务里还是造了一个多余的类你需要指出来它一般会很快调整。5.3 测试的重要性比你以为的还高还有一个使用习惯想特别强调让 AI 改完代码之后主动要求它补测试或者跑测试。不是所有任务都需要补测试但只要是核心业务逻辑这一步都建议保留。我在 Java 工程里的体验是superpowers 的规范流程中通常会包含运行测试验证改动的环节。对有测试基础的工程这是很好的闭环但如果工程本身测试覆盖很差老项目常见这个环节就形同虚设。这种情况下我会在提示词里额外让 AI 至少做一次编译检查或者启动一个最小上下文来验证依赖注入是否正常。别小看这个动作它能拦下很多静态看起来正确、运行时直接报错的改动。6. 配置选型与常见冲突几个你迟早会遇到的坑6.1 技能文件不是越多越好第一次了解 superpowers 这个项目的人很容易有一个动作把所有 skills 一次性全部启用。我也这么干过。实际效果是灾难性的——AI 在收到一个普通任务时会尝试同时加载好几个技能规范反而不知道该听谁的。有些规范彼此还会冲突比如一个技能要求先给完整计划另一个技能要求快速直接动手模型有时候会宕机返回一个四不像的答案。后来我调整了方式一个会话只聚焦启用相关的一两个技能。比如做重构任务就只让它遵守重构相关的规范做新功能开发就只加载新功能开发的规范。这个调整之后AI 的表现立刻稳定了很多。这就像给员工发手册一次给十本他大概率什么都记不住一次只强调最重要的一本他反而能执行到位。6.2 与内置指令的优先级冲突如果你用的 AI 工具自身也有思考规范比如有些工具默认要求 AI 在最终回答前输出推理过程那么 superpowers 的某些指令可能会和它发生优先级冲突。一个明显的表现是AI 的回复变得啰嗦一边按工具内置规范说话一边又按 superpowers 的技能规范做事前后风格不一致。我遇到这个情况后采取的方案是在工具配置文件里把其中一套规范设为后备也就是只在另一套缺失时才生效。具体怎么操作取决于你用的工具但总原则是——不要让 AI 同时执行两套高优先级的行为约束选定一套为主另一套作为补充即可。6.3 版本更新一条命令解决的问题别乱手动改superpowers 的开发活跃度不算低技能文件的更新有时候会带来行为上的变化。我有一次手动在技能目录里加了自己的几条自定义规则之后项目一更新自动合并把我加的规则搞乱了导致 AI 行为异常了挺久排查起来很痛苦。后来我学乖了自定义规则尽量新建独立文件不要改动仓库自带文件。这样项目更新的时候只需要正常拉取最新代码、重新执行安装命令就行。如果你改了自带文件每次更新版本都要检查冲突非常容易出问题。7. 提示词写法的变化用 superpowers 之后你怎么和 AI 说话更高效7.1 任务描述里多一个约束条件维度很多人觉得 superpowers 是给 AI 用的规范和用户写提示词没关系。我的实际体验恰恰相反——你现在写提示词的方式也应该跟着变。以前我写需求会尽量详细描述结果比如写一个函数输入 A输出 B。但现在我意识到superpowers 更擅长处理有边界、有约束的任务所以我写提示词的时候会刻意补上两类信息一是约束条件比如不要引入新的 Redis 客户端依赖复用现有的OrderQueryService里的方法二是验收标准比如改完跑一遍mvn test -DtestOrderQueryServiceTest。这两个额外信息会显著提高 AI 一次做对的概率。原理也不难理解——你的约束信息帮它缩小了搜索空间验收标准又给了它一个明确的完成信号。相比之下只说帮我优化一下这个接口这种开放式需求即使有 superpowers 加持效果也有限。7.2 分阶段对话 vs 一次性大需求很多新用户习惯用一整段话来描述一个复杂需求帮我重构这个模块然后把日志加上还有不要影响原有接口的返回格式另外最好加个缓存。讲真这种一次性的复杂需求对任何 AI 工具都是不小的挑战。有了 superpowers 之后我建议把它当成一个更正式的协作者改成分阶段对话。比如第一阶段只说我想重构这个模块先帮我梳理当前的依赖关系和调用链不要改代码等它输出分析结果后再进入第二阶段基于上面的依赖关系帮我重写 Service 层的实现保持接口签名不变最后再提补全单元测试并运行验证。这种方式看起来多花了几轮对话实际上每一轮的目标都极明确AI 出错的概率大幅下降。7.3 关于重新加载技能这个小技巧会话进行到中后段的时候如果 AI 的行为开始偏离人设变得像一个普通的对话模型有一个很实用的小伎俩在对话里输入一条类似请重新阅读并遵守所有已加载技能的规范的指令。实测中这往往能让模型重新聚焦。原理我推测和上下文窗口里的注意力衰减有关——早期加载的技能规范在长篇对话中逐渐被后续信息冲淡了权重重新提示一次就相当于拉回注意力。这个技巧不算什么高深的东西但很好用。8. 实际收益与边界哪些事不该指望 superpowers8.1 它能给你什么用了这段时间我对这个项目的评价是正向的。它主要带来了三点改变减少无效改动。AI 动手前先看项目上下文这个习惯本身就能过滤掉很多错误方案。让 AI 的行为可预测。你不会再遇到让它改个接口它顺手把整个 Controller 重写了的惊吓。提升对 AI 的信任度。以前我给它派活总忍不住守在旁边盯着现在流程规范了我敢让它独立做一些局部改动再统一 review。这种改变不一定会在代码功能上带来肉眼可见的性能提升但对团队协作的体验、对项目代码风格的维护帮助是实打实的。8.2 它的边界在哪里同时必须说清楚superpowers 不是银弹。有几个场景我个人不太建议对它抱有太高期待需求本身模糊不清的时候。你让 AI把用户体验优化一下这种大词谁都处理不了。superpowers 再怎么规范流程也架不住任务目标本身是虚的。系统性架构调整。比如要把一个单体服务拆成微服务这种级别的改动涉及大量业务判断和架构权衡目前的 AI 工具配合技能包也只能做执行层面的辅助还不能承担真正的架构决策。项目上下文极其庞大且混乱的情况。如果代码库里垃圾代码太多、依赖关系一团乱麻AI 读文件的开销会很大效果也会打折扣。这种情况下先做人工清理比强行上 AI 效率高。8.3 移民过来的老项目需要额外耐心有些老项目的代码结构比较实在类名、方法名可能已经和实际功能严重不符比如一个叫UserServiceImpl的类里塞满了订单逻辑。这种命名腐烂对 AI 的误导非常严重。superpowers 的流程会在一开始要求 AI 梳理项目结构但 AI 看到的只是现状它没法自己识破这个类名字和实际功能不符这种历史遗留问题。应对办法是你得在提示词里提前打补丁注意项目里存在命名和实际功能不一致的情况梳理依赖的时候要按实际调用关系来不要仅凭类名下结论。这样做之后AI 的准确率会提升很多。这个经验也算是我在整理老项目时摸索出来的土办法但对项目里的 AI 协作非常有价值。9. 最后分享一点个人使用心得如果你也想在自己的工作流里引入 superpowers我给的建议不是先去搜一堆使用教程也不是一次性把项目全部技能都看完而是先找一个中等复杂度的旧任务——就是你手头那个说简单不简单、说难也不难的任务——按它规定的流程完整跑一遍。这个过程中你自然会感受到它和默认模式的差别也自然会暴露出哪些地方需要你调参、哪些技能对你当前项目没意义。我在几次踩坑之后形成的一个习惯是每次新开会话先花一两句话把当前任务的目标、约束、验收标准一次性说清楚。这不是 superpowers 文档里要求的事但和它配合起来效果格外好。这套组合用熟了以后AI 在项目里的角色会从偶尔灵光一现的代码片段生成器慢慢转变成一个流程感还不错、但需要你把关方向的项目协作者。最后再补一句关于安装的真心话如果你的 AI 工具版本比较新装完 superpowers 之后发现行为没有变化别急着怀疑项目出了问题。先确认技能文件的加载路径、确认当前对话模型确实支持读取这些文件再考虑是不是有配置项遗漏。绝大多数装了没效果的问题根源都是这一类环境层面的小细节。
