如果你也跟我一样早就在终端里把 Codex 用上了但总觉得它在“执行”这件事上还不够听话那你大概需要看看Superpowers这个东西。我最初注意到它是因为每天要反复给 Codex 输入同一类指令读哪个文件、改哪段逻辑、跑什么测试、出现什么错误就停下来等我处理。这套流程手动操作了两个月之后我意识到问题不是 Codex 能力不行而是我给它布置任务的方式太原始了。后来我在社区看到superpowers这个词频繁出现又发现一份使用指南才搞明白它给 Codex 增加的不是“更聪明的模型”而是“更自动化的执行能力”。1. 先搞清楚 Superpowers 到底解决什么问题1.1 它不是一个独立 AI而是 Codex 的“驾驶舱”先说一个很多人都会混淆的点Superpowers不是一个可以替代 Codex 的独立程序也不是新的编程模型而是运行在 VS Code 里、依附于 Codex 扩展之上的增强层。你可以把它理解成给一台性能很强但操作繁琐的车加装了自动换挡逻辑——油门还是那个油门但驾驶体验完全不一样了。在我接触 Superpowers 之前Codex 给我的感觉是“能说会道但动手能力要靠我帮它铺路”。比如我让它修改一个 Java 类它常常只给我一段建议代码然后等我手动打开文件替换、再手动跑单元测试。可一旦我用上 Superpowers同样的请求会变成一条可执行的流水线找到目标文件、读取上下文、修改代码、运行 Maven 测试、把失败信息回传给 Codex 继续调整。整个过程不再需要我在中间当“传话筒”。所以如果你当前的问题是“我已经能用 Codex 回答问题但每次写修复代码都要手动确认”那么你要找的解决方案大概率就是这层增强扩展。1.2 真正的核心把高频操作变成可复用工作流Superpowers 真正改变我工作习惯的地方不是单次对话中的智能而是“把流程沉淀下来”的能力。程序员都知道一个道理重复劳动是效率的大敌。平时我们写脚本降低重复现在用 Superpowers 可以把那些高频出现的编码操作也脚本化。我举一个典型例子。之前我维护过一个遗留 Java 模块动不动就需要做“全局搜索旧接口引用→逐个升级→跑测试→修复编译错误”这种四步操作。没有 Superpowers 的时候我每一次都要把这几步从口头描述给 Codex费时间不说Codex 还经常会漏掉某些文件因为它的上下文窗口里没有完整项目地图。用上 Superpowers 之后我写了一个/full-refactor命令里面固化了几条规则列出所有受影响的模块、检查 import 清单、删除已弃用的方法调用、重新编译、第一时间跑关联测试。之后在 Codex 会话里敲下这么一条命令它就按照这个标准动作去执行。最让我受用的是这些规则本身也是用文本维护的想调整直接改配置根本不需要重新录入。这些可复用工作流才是 Superpowers 这个名字的真正含义——你掌握了它不只是多了一两个快捷键而是让 Codex 开始按照你的标准工作。1.3 和其他“提示词库”类工具的差别市面上能提升 AI 编码助手的工具不少很多是“提示词库”也就是把一些好的 Prompt 存下来需要的时候复制粘贴。但 Superpowers 的逻辑不太一样它把命令做成了结构化配置命令里可以携带附件、系统消息、执行步骤和自动校验条件。我做个对比方便你判断自己到底需要哪一类。维度普通提示词库Superpowers 方式交互方式粘贴文本结构化命令传入参数是否能执行动作不能只提供上下文可驱动 Codex 连续操作多轮循环依赖人工切换内置步骤、校验、循环复用边界同一段提示词可自由组合不同命令是否关心项目背景不关心可读取项目配置文件不是说提示词库没用而是它们解决的是“写什么”的问题Superpowers 还往前走了半步解决“怎么执行”的问题。对已经熟悉 Codex 的人来说这半步价值非常高。2. 从安装到接好Superpowers 挂在 Codex 上的完整流程2.1 环境准备比官方文档多走的一步先看环境依赖。你至少需要 VS Code、Node.js 运行环境和 Codex 官方扩展。Node.js 的原因很简单Superpowers 的很多命令本质上是调用本地 npm 包和脚本比如解析 Markdown、管理附加文件、检测环境变量这些能力依赖 Node 生态。如果你的机器上已经装过 Codex 扩展先确认它的版本不是太老最好升级到最新稳定版。还有一个容易踩的坑是某些环境中VS Code 的扩展被安装在非默认目录导致 Superpowers 激活后找不到 Codex 的命令面板入口。解决办法是先进入命令面板搜索Codex: Set API Key或者打开 Codex 面板正常发起一次会话确认 Codex 本身工作正常再继续下一步。我通常还会先创建一个临时目录在里面放一个最简单的hello.ts文件让 Codex 先跑通一次“解释这段代码”对话。这相当于给后续配置做一个基线后面发现问题时能快速排除“Codex 本身就挂了”这个因素。2.2 安装扩展并完成激活在 VS Code 的扩展市场搜索Superpowers看到对应扩展后点击安装。安装完成后重点来了很多用户以为装完就完事了其实还需要手动激活。打开命令面板CtrlShiftP 或 CmdShiftP输入并执行Superpowers: Install。这一步会自动把 Superpowers 需要的启动脚本写入当前用户的 Codex 配置目录。这个设计很关键——它不是在扩展层面直接干涉 Codex而是通过注入配置让每次启动 Codex 会话时都自动加载 Superpowers 的上下文。如果你在公司环境工作网络受限导致扩展市场搜索不到可以在项目根目录的package.json里手动添加依赖然后执行npm install superpowers/extension --save-dev这里不展开具体包名因为不同版本可能有命名差异你只要理解思路把扩展作为一个 npm 依赖安装后再在 VS Code 里选择“从文件夹安装扩展”指向本地的node_modules路径即可。安装完成后建议重启一次 VS Code 窗口。我见过不少用户没重启就直接用结果命令面板里找不到任何superpowers开头的命令误以为安装失败。2.3 第一轮“体检”确认它真正接管了 Codex重启之后不要急着写代码先做一轮体检。在 Codex 会话里输入/doctor这条命令是 Superpowers 自带的诊断命令它会输出当前环境信息Node 版本、Codex 扩展版本、配置文件路径、可用的 Slash 命令数量。看到这些信息基本就说明扩展已经生效了。如果/doctor没有反应优先检查两件事第一当前 VS Code 窗口是否打开了包含.codex配置的文件夹第二Codex 扩展是否处于激活状态。我遇到过一种情况扩展安装正确但用户把 VS Code 当作普通编辑器打开了一个单独文件没有进入工作区导致命令一直找不到上下文。体检通过后再打开 Superpowers 的配置文件目录看看。它一般位于用户主目录下的某个.codex文件夹里或者项目根目录的.codex文件夹。里面会有commands、workflows、skills等子目录。看到这些目录你就可以确认后面的配置都有地方放了。2.4 创建你自己的第一个 Slash 命令配置好了之后最值得做的一件事就是写一条自己的命令。我们从一个最简单的 Java 构建命令开始目的是让 Codex 自动执行一次 Maven 编译并把报错信息返回来。在.codex/commands目录下新建一个文件名称叫build-java.md内容结构大概是这样的--- description: 运行 Maven 编译并处理报错 argument-hint: 可选指定模块名 aggressive: true --- 你是一个 Java 项目助手。 1. 使用 mvn compile -pl module 编译指定模块如果没有指定模块直接编译整个项目。 2. 如果编译失败阅读错误信息定位到具体文件。 3. 给出修复建议然后等待我的确认。 4. 确认后执行修复并重新编译。保存文件后回到 Codex 会话输入/build-java你会看到这条命令已经被加载。它的价值在于把我原本每次都要重复说的“去编译、看错误、给方案、等我确认、再改”固化成了命令。以后团队里任何人想跑同样的流程敲一条命令就行。3. 核心能力拆解Slash 命令、工作流和 Agent Skills3.1 Slash 命令把程序化指令固化下来Slash 命令是 Superpowers 最常见的交互形式它本质上是一份带前置配置的 Markdown 文档但又不仅仅是提示词模板。命令文件中的 front matter 可以定义描述、参数提示、是否允许 AI 自动执行修复等行为。我建议每个命令文件都必须包含三部分第一description告诉 Codex 这条命令什么时候适合被调用第二argument-hint说明用户可以跟哪些参数第三正文部分用清单式语言描述执行步骤。这里有一个设计细节值得注意正文里的步骤一定要使用祈使句而不是疑问句。比如“运行npm test”和“你是不是应该运行npm test”相比前者在协同执行时的确定性高得多。因为 Codex 这类模型在遇到模糊表述时会产生大量不必要的“反问”反而拖慢工作流。你可以把命令文件看成给新手同事写的交接文档。文档越明确出错的概率越低。我甚至见过有人把团队编码规范写进命令里让 AI 提交代码前先检查一遍规范约束。3.2 工作流文件AI 的 SOPSlash 命令适合解决单次任务如果遇到一套多阶段流程比如“静态检查→单元测试→覆盖率分析→打包”那用工作流文件更合适。工作流文件写法上类似命令但多了对步骤阶段的定义。你可以在配置里声明几个阶段每个阶段有独立的提示词和结束条件。Superpowers 在执行时会按阶段推进前一个阶段通过后自动进入下一个阶段。如果某个阶段失败它可以选择停止或进入容错分支。我为什么强调这个因为真实项目里一次完整的代码变更往往涉及多个环节如果让 AI 一次性把所有事情做完出错概率和不可控程度都会大幅上升。阶段化之后每个步骤都像一个独立的检查点出了问题我能定位到具体环节不用从头再跑一遍。3.3 Agent Skills给 AI 装“专业技能包”Skills 是 Superpowers 里更高级的封装方式你可以把它看成“针对特定领域的技能包”。它不只是几条命令而是包含了一整套说明文档、代码规范、常用工作流和典型示例。举个例子。如果你经常处理 Java 项目可以在 skills 目录下建一个java-refactoring技能包里面放一个README.md描述你的团队对 Java 代码风格的要求命名规则、异常处理方式、禁止使用的 API、测试类放置路径等。这样当 Codex 执行涉及 Java 重构的命令时它会主动加载这份技能文档来校准自己的行为。我自己的体会是Skills 比写一堆命令更符合“知识积累”的逻辑。命令解决的是“做什么”技能包解决的是“按什么标准做”。对一个长期维护的项目来说后者带来的收益更稳定。3.4 配置与目录结构用一张表格整理核心目录结构方便你对照检查自己的配置目录/文件作用常见使用场景commands/存放 Slash 命令文件单次固定动作workflows/存放多阶段工作流分阶段执行完整流程skills/存放领域技能包特定技术栈的专业规范AGENTS.md全局助手说明定义 Codex 的基本行为原则.env或环境变量配置存放密钥和路径传递 JDK 路径、NPM registry 等这些配置全部是文本文件所以天然适合提交到 Git 仓库。我强烈建议你把.codex目录纳入版本管理。这带来的好处是全团队的 AI 辅助流程保持一致新成员拉下代码的同时也就继承了已有的工作流配置不用再靠口头传话。4. 实战三连Java 项目改造、多文件协作、worbuddy 联动4.1 Java 项目场景依赖梳理与重构先说 Java。很多开发者关心的场景是依赖升级和接口重构这两件事用纯手工方式做非常痛苦尤其遇到遗留系统依赖关系一团乱麻。我拿一个真实项目举例。项目是一个 Spring Boot 应用里面有一百多个import java.util.Date的旧接口调用我打算换成java.time.LocalDateTime。手动搜下来有一百多处不可能自己改完再验证。过去使用 Codex 的做法是让它生成补丁我再应用。但 Codex 生成的补丁经常因为上下文不全而漏改或者改坏了接口签名。用上 Superpowers 之后我把这个场景拆成了两条命令。第一条/scan-usage用于统计所有受影响的文件清单和改动量第二条/refactor-time-api让它基于清单逐文件执行替换并阶段性地跑编译测试。实际执行时发现最耗时的不是替换本身而是检查“被替换后的调用是否存在隐式类型转换不匹配”。比如有些地方调用了Date.getTime()而LocalDateTime没有这个方法代码一改立刻编译失败。Superpowers 的工作流在这里起了作用因为阶段化设计它在mvn compile失败后会自动读取新错误并单独列出让我判断是继续改还是先回滚。最终整个重构在一个小时内完成中间真正由我人工介入的次数只有三次。如果用老办法光是手动列出所有受影响文件就要花掉将近半天。4.2 多文件协作批量修改与一致性检查开发中还有一种高频需求是在多个文件之间保持一致修改。比如把项目里的日志工具从log4j 1.x切换到logback。这类改动最大的坑在于不是简单替换依赖就行还要统一 logger 的初始化方式、处理依赖传递、注意输出格式兼容。用 Superpowers 做多文件修改时我建议先定义一个技能包logback-migration。里面写明迁移清单第一哪些类应该被移除第二新旧 API 之间的映射表第三迁移后必须运行的测试类第四输出格式样例。然后创建一条命令让 Codex 依次读取技能包、扫描代码中所有org.apache.log4j的引用、生成一个待改动文件列表、逐文件替换、最后进行一致性检查。这里的核心技巧是让 AI 自己先“列计划再动手”。很多工具用不好的原因就是直接让 AI 改AI 改到哪算哪最后整个项目风格变得支离破碎。但 Superpowers 的工作流天然支持定义计划阶段和执行阶段所以我一直在工作流里刻意保留“列表生成”这一步。另外多文件修改之后“一致性检查”不能省。检查内容包括是否还有漏网的旧 import、是否所有新 logger 的初始化方式一致、是否某些文件里出现了重复转换。这一步我会写成一个单独的/consistency-check命令里面明确要求 Codex 给出一个 markdown 表格罗列涉及的文件、变更类型、是否通过检查。有了表格我就能快速判断还需要人工处理哪些地方。4.3 worbuddy 联动将同一套工作流带到桌面社区里还有一个叫worbuddy的工具经常和 Superpowers 一起被提起。它本质上是把 Codex 的会话能力包装成一个更友好的工作台界面特别适合不习惯整天面对终端的人。worbuddy 和 Superpowers 的联动方式并不复杂两者共用同一套.codex配置目录。只要你把commands、workflows、skills放在工作区根目录的.codex文件夹下在 worbuddy 里启动同一个项目它就能读取到这些配置并且执行方式与 VS Code 里保持一致。我日常的习惯是在给客户演示或者临时快速验证思路时直接用 worbuddy 打开项目调用/doctor和/build-java这类命令需要深度代码修改时再回到 VS Code。有一点要注意worbuddy 和 VS Code 扩展版本可能存在差异某些新特性在一边可用在另一边不可用。所以我的建议是先把配置写好在两个环境中都跑一遍doctor确认命令数量一致再把它纳入日常使用。否则你可能在 worbuddy 里敲了一个命令发现毫无反应然后误以为配置丢了。5. 高频问题排查与避坑记录5.1 扩展装了却没生效这个问题出现频率最高处理思路按顺序排查。第一确认命令面板里能找到Superpowers: Install并且执行时没有报错。第二确认 Codex 扩展处于启用状态。第三看到doctor输出后再进行下一步。如果你在终端里已经可以直接调用codex命令而 VS Code 扩展里却不生效大概率是 VS Code 找不到终端路径特别在 macOS 上。这时需要在 VS Code 设置里检查terminal.integrated.defaultProfile.osx是否正确指向了你的 shell。还有一个隐藏问题某些 PowerShell 环境会限制脚本执行策略导致 Superpowers 注入的启动脚本无法执行。解决方案是在项目本地设置执行策略或者改用 Git Bash 作为 VS Code 默认终端。5.2 命令执行到一半卡住卡住的常见原因有三个。第一个是命令中包含了需要交互确认的步骤比如npm install询问是否覆盖某些依赖。解决办法是在命令正文里明确“如果想确认先停下等待用户输入”或者在执行指令前加上--yes参数。第二个原因是网络请求超时。如果你的项目依赖部分第三方服务而当前网络环境对某些域名访问不稳定就可能卡住。我的处理方式是把网络密集操作拆成独立阶段并且在命令里写明“如果拉取失败给出错误原因后停止”而不是让 AI 一直重试。第三个原因是上下文过长。Codex 在读取多个大文件后输出复杂度增加响应会明显变慢。遇到这种情况可以在工作流中增加一个“先压缩问题”的阶段比如先让 AI 用最少的字复述任务目标再继续执行。5.3 Java 场景下的 JDK 路径问题Java 项目里最容易出现的问题就是编译命令找不到 JDK。Codex 本身并不会主动读取系统的JAVA_HOME很多时候需要你手动告知。我的做法是在.env文件里写入JAVA_HOME/path/to/jdk PATH$JAVA_HOME/bin:$PATH然后在命令文件里要求 Codex 执行编译前先读取.env并打印当前版本。这个操作看似多了一道工序但能避免大量无意义的错误排查。如果你使用多个 JDK 版本建议在命令参数中让用户手动指定版本。例如/build-java 17命令正文里对应写上使用 JDK 17 的路径来设置JAVA_HOME。这样既能灵活切换又不会因为环境变量混乱导致编译失败。5.4 文件权限与路径空格问题这个问题极容易被忽略尤其是在 Windows 环境下。很多开发者的项目路径含有空格比如D:\My Projects\demo。某些执行命令在传递路径时没有加引号就会导致“系统找不到指定路径”的错误。我在配置命令时的一贯约定是所有涉及文件路径的引用一律用双引号包裹。并且在命令文件开头写一句“处理路径时注意空格”。这句话虽然简单却能显著减少 Windows 环境的报错。另外如果工作流需要创建临时文件建议统一放到系统临时目录避免污染项目目录。比如使用$TEMP或/tmp并在完成后立即删除。5.5 几条让我“早十年知道就好”的经验最后聊几条掏心窝的经验。第一给 AI 的指令一定要追求确定性。你越是用“必须”“不允许”“只有当某条件成立时”这种表述AI 的猜测空间就越小执行结果就越稳定。第二把“验证”写进工作流。别只让 AI 改完代码就结束必须跟着一个“执行测试并汇报结果”的步骤。没有验证的改动就像没有测试的提交迟早要还的。第三所有配置都要纳入版本控制。Superpowers 的配置文件本质上就是你的团队资产迭代它们应该像迭代业务代码一样要有 commit、有 review。第四不要给 AI 过高的权限。尤其是aggressive: true这类自动修复选项建议只在你有把握的场景开启。否则 AI 可能会在改代码的路上顺手改掉其他不相干的东西到时候光排查回归问题就够你喝一壶。第五把AGENTS.md当成你的团队手册来写。你在里面写清楚“禁止做什么”比“应该做什么”更重要。比如规定“不允许修改测试文件”“不允许删除未引用的代码块”这些约束能避免很多不必要的意外。我在实际使用中最受益的一次是给一个老项目补齐了完整的java-refactoring技能包然后让 Codex 按标准重构了三十多个文件构建一次通过。那一刻我真正觉得这个工具的名字没有起错。AI 编码助手本身已经足够聪明但如果你能给它一套清晰的执行框架它就能爆发出比“聪明”更高一档的价值——稳定、可复用、不跑偏。如果你也准备在自己的项目里折腾一遍我的建议是从一条最常用的命令开始比如/build-java先让它替你跑顺一次编译。等你觉得这个流程可靠了再慢慢扩展工作流和技能包。不要一开始就试图把所有场景都自动化那样配置复杂度会把你和 AI 都淹没掉。从一个点开始尝到甜头你自然会知道下一步该往哪里加“超能力”。