1. 为什么我会盯上这个叫 superpowers 的工具最近我常逛的几个技术社区里superpowers这个词的出镜率突然高了起来而且每次都跟 AI 编程助手绑定在一起。一开始我还以为是某个前端框架的新名字点进去才发现这其实是围绕 Claude Code 这类 AI 编程终端的一套技能增强插件。国内社区把它翻译成超能力听起来挺中二的但实际用下来它做的确实是给 AI 助手装技能这件事。1.1 热词背后的真实身份如果你去搜 superpowers 相关的内容大概率会看到几个固定搭配superpowers 安装、superpowers 使用教程、codex superpowers、superpowers java。这些热词拼在一起基本就能还原出这个工具的定位一套跑在 AI 编程助手之上的技能系统让你不用反复把同样的业务背景、代码规范、测试套路重新喂给 AI而是把它们沉淀成一个个可以被随时调用的技能模块。它的核心思路很有意思。普通的 AI 编程助手是你问它答每次对话都是重新开始哪怕你上一条消息里详细交代了项目的目录结构、命名规范和异常处理风格下一条消息它可能又忘得干干净净。而 superpowers 做的是把怎么干活这件事本身固化成技能让 AI 在遇到同类任务时能主动去加载对应的技能按里面定义好的步骤和模板去执行。这听起来有点像 IDE 里的代码模板但比代码模板高级不少。技能里面不仅包含流程化的提示词还往往绑定了一个子智能体的工作方式包括它需要读取哪些文件、按什么顺序执行检查、输出什么格式的结果。本质上是一套可复用的工作流封装。1.2 它到底解决了什么问题举个例子你就明白了。我手上有个老项目每次让 Claude Code 帮忙改代码之前都得花大段文字给它讲一遍项目背景这是个 Maven 多模块的 Java 项目依赖管理走父 POM测试用的是 JUnit 5接口返回统一用 Result 包装。讲完之后它偶尔还会忘遇到改到一半让我纠正的情况非常影响节奏。而如果用技能系统把这些信息整理成一个Java 项目改造技能那么下次只要告诉 AI 用 Java 项目改造技能处理这个模块它就会自动去加载对应的规则、步骤和示例不需要我重复唠叨。superpowers 恰好就是干这个的工具。它能从你日常对话中提炼技能把一段相对完整的、可复现的工作流整理成标准格式的技能文件放进 AI 助手可以读取的目录里之后每次需要时直接按名字调用。对于经常用 AI 写代码的人来说这省掉的不是一次两次重复描述的时间而是整个工作习惯的转变。2. 安装 superpowers第一关是环境准备说句实话这个工具的安装本身不算复杂但很容易在环境准备上翻车。我见过好几个朋友卡在装完不知道怎么验证这一步。这里我把完整的检查流程拆开讲。2.1 前置条件清单在动手之前先确认三件事你已经装好了 AI 编程终端的命令行工具并且能正常跑通一次简单的问答。你的终端环境支持执行 shell 脚本。Windows 用户建议直接用 WSL 或者 Git Bash纯 CMD 环境会比较痛苦。你的系统里有 git因为技能库本身是一个 git 仓库后续拉取更新、管理技能都离不开它。我的建议是先把第一条验证了再往下走。很多人以为装好了命令行工具就等于能用了实际上如果模型接口配置有问题或者没有完成登录认证后面所有步骤做起来都会像在打空气。先随手问一句你好确认能返回正常回答再继续。2.2 安装步骤详解第一步是从 GitHub 上把项目克隆到本地。我习惯放在~/tools目录下方便统一管理cd ~/tools git clone https://github.com/obra/superpowers.git这里有个小细节要注意不要用sudo克隆到系统目录除非你有充分的理由。因为这个工具后续要往你的用户目录下写技能文件如果仓库权限归属不对写文件的时候会频繁遇到 permission denied非常影响体验。第二步是运行它的安装脚本。项目仓库里一般会带一个安装脚本通常在bin目录下cd superpowers ./bin/superpowers-install如果你是从热词superpowers 安装点进来的可能也在社区里看到过一行命令直接装的版本那是把克隆和安装合并成了一条命令本质上做的事情是一样的这里就不贴了以免不同版本之间命令有出入给你带偏。脚本跑起来之后它会做几件事检查当前环境里 AI 编程助手是否正常。把技能示例文件复制到 AI 助手的配置目录下。配置一个用于技能生成的服务连接这个连接负责把你后续提供的对话素材加工成正式技能。每一步结束都会有输出提示我建议你盯着看别走神。如果哪一步红了先停下来解决不要硬往下跑。2.3 装完先跑通自检装完之后很多人以为就完事了其实还差一个验证环节。打开你的 AI 编程助手终端输入一条命令让助手列一下当前注册好的技能列表不同工具的命令不太一样有的用斜杠命令有的用自然语言直接问。我当时验证的时候能列出几个内置技能就算成功说明技能目录被正确读取了。如果列表为空大概率是技能文件放的位置不对或者助手的配置里没有指向正确的技能目录。这个时候回过去看安装脚本的输出它一般会把实际写入的路径打印出来照着检查一遍就行。还有一点安装完脚本之后建议重启一下终端会话。因为技能列表很多时候是启动时加载的不重启的话新技能不会被识别。这个坑我踩过装完直接试发现没反应差点以为安装失败了。3. 核心玩法Skills 的创建与调用逻辑工具装好只是开始真正值钱的是理解它的技能机制。我从造技能和用技能两个方向分别说说。3.1 Skills 的本质可复用的小型智能体你可以把技能理解成一个带说明书的小型智能体。一个技能文件里面通常包含两部分一部分是描述性文字告诉 AI 这个技能是干什么的、什么场景下触发、有哪些注意事项另一部分是具体的操作步骤有的技能还会附带参考代码片段或者检查清单。当 AI 接收到一个任务时它会先判断这个任务能不能匹配上某个已注册的技能。如果能匹配就按技能里的流程执行如果不能就退回普通的闲聊模式。这套机制的好处是技能本身的可控性很强——你可以把团队规范、代码风格、交付标准全部固化成技能让 AI 不再是自由发挥而是在你定义的边界里工作。有个概念需要特别区分清楚技能和普通的提示词模板不是一回事。提示词模板是死的你给它填参数它就输出对应的内容技能是活的它可以有判断逻辑可以根据现场情况决定先做哪一步再做哪一步。3.2 从会话记录生成新技能superpowers 最有意思的功能是它能从一段已有的对话中提炼出技能。操作上大概是这样的你把一段你觉得效果很好的、完整的对话素材丢给它让 AI 分析这段对话里的工作流然后自动整理成一个技能文件。我举个例子。有一次我让 AI 帮我给一个 JSON 接口写参数校验逻辑它先让我描述了字段规则然后生成了校验代码最后还跑了一遍测试用例。整个过程我觉得非常标准就把它标记成了JSON 参数校验技能的素材。AI 分析之后自动把先问字段规则 → 按规则生成校验代码 → 补充异常分支 → 生成测试这个流程提取成了技能。这个功能对个人沉淀非常有价值。你平时跟 AI 协作时的很多优秀做法以前是一次性的用完就没了现在可以随时沉淀成技能下次遇到同类需求直接调用而且可以在使用过程中继续迭代优化这个技能文件让它的表现越来越好。3.3 调用技能的正确姿势调用技能的方式取决于你用的 AI 编程助手怎么设计的。有的支持斜杠命令直接指定技能名比如输入/skill json-validation就触发对应的技能有的需要在自然语言里明确提及比如告诉 AI 使用 JSON 参数校验技能来处理下面的接口。我自己的习惯是在任务描述里把技能名写清楚并且补上一句按该技能的流程执行。这样可以减少 AI 在要不要用技能这个问题上的犹豫直接进入执行状态。还有一个使用上的细节技能也不是越多越好。技能库膨胀到一定程度之后AI 在匹配技能时可能会出现误匹配把 A 技能用在 B 任务上。所以建议定期清理不常用的技能保持技能库精简。我现在的做法是每周五下午花十分钟过一遍技能列表把近一周没被调用过的技能归档避免干扰匹配精度。4. Codex 与 Java热词背后最常见的两个场景热词榜上最显眼的两个搭配就是 codex superpowers 和 superpowers java。这两个方向正好代表了这类工具的两种典型用法一是跨工具的集成适配二是具体语言生态里的落地。4.1 Codex 环境下的集成方式Codex 是 OpenAI 旗下的编程智能体产品不少开发者也在用它。superpowers 能跟 Codex 扯上关系说明这个技能系统并不绑定在单一工具上而是通过通用的技能文件格式让不同工具都能读取和执行。我在集成 Codex 的时候体会到的一个要点是技能文件的描述部分要写得足够工具无关。比如不要写打开 Claude 的某个面板而是写读取项目根目录下的配置文件解析其中的依赖列表。这样不管底层是哪个 AI 工具在跑只要它能读文件、能理解自然语言就能照着技能操作。如果你准备把 superpowers 用在 Codex 上我建议先拿一个小技能做验证让它在 Codex 环境里跑一遍确认所有步骤能走通。Codex 的工作方式和终端类工具有些差异尤其是在执行多步骤操作时它更倾向于分步确认所以技能里的步骤拆分越细在 Codex 上的兼容性就越好。4.2 Java 项目里能用它做什么回到 Java 场景。老实说Java 项目的上下文复杂度比前端项目高不少Maven/Gradle 的构建链路、多模块的依赖关系、历史遗留的编码风格都是 AI 容易失忆的地方。superpowers 在 Java 场景里最有价值的一点是把这些项目背景固化成技能。比如我给自己定义了一个Java 模块分析技能里面包含了几个固定步骤读取根目录下的pom.xml或build.gradle梳理模块结构和依赖关系。识别项目使用的 Java 版本、框架版本、测试框架。输出一份模块清单包括每个模块的职责和对外依赖。有了这个技能我新开一个会话、面对一个陌生 Java 项目时只需要说一句执行 Java 模块分析技能AI 就会自动按流程把项目的家底摸清楚省掉了大量的来回问答。4.3 一个实际的 Java 重构示例说一个我最近做过的真实例子。我需要把一个老旧的同步接口改造为异步处理涉及线程池配置、任务队列接入和结果回调三个部分。以前做这种改造我得逐段给 AI 解释现状、目标、约束经常解释到一半自己都嫌烦。现在我把这个改造流程整理成了一个接口异步化改造技能里面写清楚了先扫描原有接口的调用方列表确认线程池的核心线程数、队列容量、拒绝策略生成异步改造代码保持对外接口签名不变补充并发场景下的单元测试实际调用这个技能之后AI 自动按步骤执行整个过程比之前手把手引导顺畅得多。而且因为技能是明确的最后生成的代码风格和我预期的高度一致几乎不需要我再返工。这也引出我的一个判断这类技能工具在 Java 这种重规范、重上下文的语言生态里发挥空间可能比在轻量脚本语言里更大。因为你省掉的不是几行代码的重复而是一整套项目背景知识的前置传递。5. 踩坑实录我在使用中遇到的五个典型问题任何工具用久了都会遇到问题superpowers 也不例外。我整理几个自己碰到过、且有代表性的事件每个都说说原因和解决路径希望能帮你少走弯路。5.1 问题一安装后技能列表为空这是我被问得最多的问题。装完一切正常但输入命令后技能列表空空如也。排查链路我走了一遍最后定位到原因技能文件被复制到了错误的家目录。因为我的终端会话是通过某个工具启动的它的HOME环境变量指向的位置和安装脚本预期的位置不一致导致技能文件写到了别的目录。解决方法是打开终端先执行echo $HOME看输出和安装脚本提示的写入路径是否一致。如果不一致要么把技能文件手动软链过来要么调整会话工具的环境变量。这个坑提醒了我一个原则装完之后确认路径比确认文件内容更优先。5.2 问题二生成的技能质量不稳定技能生成功能有的时候给出来的技能文件结构很乱步骤有重复描述不清楚。我分析下来根因是素材质量不够高。如果投喂的对话本身就东拉西扯AI 自然提炼不出清晰的流程。后来我养成了一个习惯投喂素材之前自己先过一遍把无关的客套话、中途跑偏的内容删掉只留主干。素材干净了生成的技能质量就会明显提升。5.3 问题三技能文件里的路径写死了有一次我给技能里写了一个绝对路径结果换了一台机器之后技能直接报错。绝对路径在个人电脑上没问题但技能是要跨环境复用的哪怕只是在同一台机器上的不同项目间切换都可能失效。解决方案是技能文件里一律用相对路径并且说明路径的基准点是什么。比如相对项目根目录、相对于当前工作目录让 AI 在执行时自己去定位。这个教训也让我意识到技能文件本质上是在给别人写文档——只不过这个别人是 AI 而已一样要注意可移植性。5.4 问题四上下文过长导致执行中断技能如果步骤多、参考内容长在大模型单次上下文吃紧的情况下可能会执行到一半就断掉。我的处理办法是给技能定义检查点。比如技能要求每完成两个步骤就把中间结果输出到指定文件这样即使执行中断也能从最近的检查点继续而不是从头再来。这个技巧在做大型重构类技能时尤其管用。5.5 问题五依赖环境变了但技能没跟上项目依赖升级、目录结构调整之后技能里的旧假设会失效。最典型的是我有个技能默认项目用 Maven 构建后来项目迁移到了 Gradle技能执行时还把pom.xml作为必读文件自然就找不到入口。这种情况没有一劳永逸的解法只能靠定期维护。我把技能文件纳入版本管理每次项目出现结构性变化就顺手更新相关技能。这本质上是一种知识资产的日常维护投入不大但能让技能长期保持可用。6. 进阶配置与我的个人习惯工具用顺了之后我开始琢磨怎么把它的价值最大化。分享几个我现在一直在用的配置习惯不一定适用于所有人但可以给你参考。6.1 自定义技能目录默认的技能目录用了一段时间后我觉得不够灵活因为工作里会区分个人项目、公司项目、开源贡献几个场景。干脆把技能目录拆成多个子目录每个子目录对应一个场景再通过配置文件把子目录都纳入读取范围。这样做的好处是隔离度高。公司项目的技能里可能包含内部规范不适合被开源项目误触发。拆分之后AI 可以按场景加载对应的技能集误用概率低了不少。6.2 结合 MCP 扩展能力MCP 协议现在很多 AI 工具都支持superpowers 的技能机制也可以和 MCP 工具结合。举个例子我的技能里某个步骤需要读取数据库表结构过去我是让 AI 去读 SQL 文件现在则可以让技能调用一个 MCP 工具直接连库查询表结构拿到的是实时信息准确度完全不一样。不过这里有一个度的问题。技能里调用 MCP 工具会让技能的运行依赖外部服务一旦服务不可用技能就废了。所以我一般只把 MCP 调用放在那些必须实时数据的步骤里其余步骤保持自包含保证技能在离线环境下也能执行大部分流程。6.3 团队协作时的最佳实践最后说说团队场景。如果你和我一样不是一个人在写代码那技能这套东西其实非常适合团队共享。把团队的编码规范、提交信息格式、代码评审清单都做成技能放进共享仓库里团队里每个人都能用。我特别想提醒的是团队共享技能一定要有版本记录。我自己就经历过一次有人在技能里加了一条新规则没说不清为什么结果整个团队生成的代码风格都变了排查了半天才找到是技能更新导致的。现在我们的做法是技能文件的改动必须带一行变更说明写清楚改了什么、为什么改避免黑盒变更。最后分享一个我坚持的习惯从开始用 superpowers 到现在我最深的体会是这类工具真正改变的不是AI 会不会干活而是你怎么定义 AI 干活的方式。技能系统逼着你去思考那些过去完全凭感觉的协作流程——到底先做什么后做什么哪些信息是必须前置的哪些检查是绝对不能跳过的。这个过程本身就比工具带来的效率提升更有价值。我现在每天开工前会花两分钟看一眼技能列表就像巡店一样。新增了哪个技能、哪个技能最近被频繁调用、哪个已经很久没动了心里有个数。这个小习惯让我对 AI 协作的整体状态始终保持掌控感也从没再出现过AI 突然做出意料之外的错误风格的问题。如果你正准备尝试这个工具我的建议是先别急着造一堆技能选一个你最高频的重复性任务完整地走一遍素材收集 → 技能生成 → 反复调用 → 迭代优化的闭环。跑通一次你就知道这套系统到底能帮你省多少事了。