最近不少人问我Superpowers 到底是个啥它跟 OpenAI 的 Codex CLI 有什么关系简单说Superpowers 是 Codex CLI 的一个自动化扩展装好之后你的 Codex 不再是你问一句它答一句的被动助手而是可以连轴跑任务、出错自己修、重开窗口还记得之前干了啥的“干活搭子”。如果你已经在用 Codex CLI但觉得每次生成代码都要手动确认太多、会话一关上下文全丢那这个项目就是冲着你来的。这阵子开发圈里“superpowers 使用指南”“superpowers 安装”这些词热度一直不低很多人把它当成某种锦上添花的小插件。我的实际体验是它改变的其实是整个交互范式。默认的 Codex 更像是“手动挡”superpowers 则把换挡、踩离合、看路况这些动作包了大半你只需要盯住方向盘。今天这篇文章我就从项目定位、安装配置、核心玩法、Java 实战到排障心得完整拆一遍。1. Superpowers 是什么Codex CLI 的“自动化外挂”1.1 不是超级英雄梗是给 Codex 装上的干活能力第一次看到“superpowers”这个名字我以为是某个前端框架或者游戏模组。实际上它是围绕 Codex CLI 构建的一套开源扩展层给原本偏“会话式”的 Codex 注入三样东西自主循环、命令审批策略、跨会话记忆。你可以把它理解成一个“驾驶辅助系统”——不让 Codex 变成完全无人驾驶但能显著减少你来回手动确认的次数。我最初从“superpowers java”这个搜索词顺藤摸瓜找到这个项目是因为当时正愁怎么拿 Codex 自动跑 Java 项目的补测试任务。默认情况下Codex 每执行一条 shell 命令就要征求一次同意跑一个mvn test可能要确认五六次一旦中间编译报错你还得手动把错误信息喂回去让它重新尝试。用了几次之后我就觉得这不是我想要的自动化这只是换了一种方式在做“人肉 copilot”。Superpowers 解决的核心问题就是把这套“任务 - 执行 - 看结果 - 继续执行 - 修错 - 再执行”的循环封装起来。它做的事情很朴素但很关键让 AI 在面对“编译失败”这种常见情况时不打断你先去读日志、改代码、重新执行直到跑通或者遇到真正需要你决策的节点。就这一步体验上的飞跃直接改变了我对 Codex CLI 的依赖程度。1.2 默认 Codex 与 Superpowers 的差距在哪里用一句话总结默认 Codex 的工作方式单轮能力强连续干活弱。它能帮你写出很漂亮的一段代码但很难自主把“写代码 - 跑测试 - 修 bug - 再跑测试 - 写文档 - 提交”这条链路走完。每次模型停下来等你确认都会打断它自己的思路。你可能只是点了两次回车但它重新进入上下文时已经丢掉了一部分对当前状态的判断。Superpowers 在这条链路上补了两个关键设计。一是“循环执行”允许 Codex 在设定的命令额度内连续运行每次执行完命令后主动读取输出判断是继续还是修正。二是“状态记忆”把工作区进度、待办事项、已完成内容写进本地文件即使你关闭终端、第二天重开它还能接着干活。这种模式很像真实团队里一个“执行力很强但偶尔需要你兜底”的开发人员你给方向它负责跑腿和纠错。还有一个容易被忽略的点默认 Codex 的上下文窗口再大也会在长任务中逐渐遗忘早期决策。Superpowers 通过把关键信息落盘把“记忆”从模型上下文里搬到了文件系统里。这是我认为它最聪明的地方——不是靠模型硬背而是靠工程手段做持久化。1.3 适合谁用、需要哪些基础如果你已经用 Codex CLI 跑过几个项目哪怕是简单的“帮我写个 Python 脚本”那上手 Superpowers 基本没有门槛。你只需要知道几件事Codex 的配置文件放在哪里、怎样开启一个会话、怎样输入任务。剩下的它都会在 README 里给你讲清楚。如果你是纯命令行小白那我建议先别急着装。不是说装不上而是你可能会在“它自动跑了命令但跑偏了”的时候不知道如何干预。Superpowers 给你的是一个自动化工具不是免死金牌你至少得看得懂终端输出里的报错知道CtrlC能中止知道怎么看一个文件有没有被改坏。另外做 Java 方向的朋友可以重点关注这个项目。Java 项目的构建链路长、编译反馈多正好是 Superpowers 自动修复能力最能发挥的场景。你不需要额外买什么只要本地有 JDK 和 Maven 或 Gradle就能在小时级的时间里看到一条比较完整的自动开发流水线。2. 安装与配置实操把 Superpowers 真正跑起来2.1 动手前的环境准备我不太喜欢“缺什么装什么”的安装方式所以在装 Superpowers 之前建议先把地基打好。你本机需要这几样东西一个能正常调用模型的 Codex CLI版本别太老最好保持最新Git用来拉取 Superpowers 项目本体Node.js 环境Codex 插件体系里不少脚本依赖它执行如果你要跑 Java 场景提前装好 JDK 以及 Maven/Gradle。装完以后我建议先做一次“冒烟测试”随便建个临时目录让 Codex 写一个 hello world 脚本并执行确认它的基本命令执行链路是通的。这一步被很多人跳过结果后面出了问题根本分不清是 Codex 的问题还是 Superpowers 的问题。需要说明的是不同版本的 Superpowers 对 Codex CLI 的版本有兼容要求你下载项目文件后第一件事应该是打开 README找到 “Requirements” 或 “Prerequisites” 段落核对一下版本号。这个习惯能帮你避开一半以上的安装坑。2.2 具体安装步骤与配置路径Superpowers 的安装本质上是“把扩展文件放到 Codex 配置目录并让 Codex 启动时加载它”。我以最常见的安装方式为例你实际操作时以自己拿到的 README 为准。第一步克隆项目到本地。大多数教程会建议放到~/.codex/superpowers因为 Codex 默认会扫描~/.codex目录下的配置和插件。命令大致是这样git clone 项目地址 ~/.codex/superpowers如果你拿到的项目文件是一个压缩包解压后手动放到~/.codex/superpowers也是一样的效果。第二步在~/.codex/settings.json中登记 Superpowers。Codex 默认不会加载一个“不在配置里”的目录所以你需要打开没有就新建settings.json加入类似这样的配置{ superpowers: { enabled: true, path: ~/.codex/superpowers } }不同版本可能字段名略有差异有的版本用plugin而不是superpowers有的需要额外写一个commands目录。这些细节都写在你拿到的版本 README 里照抄即可。第三步重启 Codex 会话。注意不是关掉终端再打开而是彻底退出 Codex 进程后重新启动。因为插件加载发生在启动阶段你热更新配置是没用的。2.3 验证安装是否生效的三种方式装没装上不能靠感觉。我一般用三个方法验证。第一个方法看启动日志。启动 Codex 时如果 Superpowers 加载成功通常会在终端输出里出现类似 “Superpowers loaded” 的提示。如果你什么都没看到先别怀疑人生去翻一下日志文件看看有没有报错路径找不到或者 JSON 解析失败。第二个方法查命令列表。在 Codex 会话里输入/help或直接输入/superpowers如果能看到一系列扩展命令出现在命令列表里说明加载成功。我遇到过很多人配置写了但命令列表里空空如也最后发现是 settings.json 里多了一个逗号整个 JSON 解析失败Codex 直接忽略了所有配置。第三个方法跑一个 5 分钟的冒烟测试。给它一个简单任务“创建一个 test.txt 文件内容写上 hello然后读取它并打印内容。”如果它能够连续执行多条命令而不需要你反复确认说明自主循环已经在工作了。2.4 升级与回滚别让新版本破坏你的工作流Superpowers 更新频率不算低因为 Codex 本身也在快速迭代。升级的时候我强烈建议先备份~/.codex/settings.json和你的会话目录然后把项目目录git pull到最新版再重启 Codex。如果升级后发现行为不对比如命令不见了、自动审批逻辑变了不要硬扛直接回滚到上一个版本。Git 已经帮你存了历史回到之前能用的 commit 通常是一条命令的事cd ~/.codex/superpowers git log --oneline -5 git checkout 上一个能用的commit有一点要特别提醒升级前看一眼 changelogSuperpowers 偶尔会改配置字段名。我有一次直接 pull 完没看文档配置里的旧字段不生效结果它在会话里表现得像个完全没装扩展的普通 Codex排查了半小时才发现是字段改名了。3. 核心玩法拆解自主循环、命令审批与记忆机制3.1 自主循环从“一问一答”到“跑完为止”Superpowers 最核心的机制我称之为“任务循环”。它做的事情不复杂给 Codex 一个任务然后允许它在一个额度范围内自动执行命令、读取输出、决定下一步直到任务完成、命令额度耗尽、或者遇到需要人工决策的情况。这个循环的价值在你处理编译错误时体现得最明显。默认情况下Codex 执行mvn compile失败了它会停下来跟你解释“这里有个编译错误需要修一下”等你确认后再继续。Superpowers 模式下它会直接读取错误输出定位到报错文件修改代码重新执行mvn compile。这种“自我修复”的能力不是模型本身突然变聪明了而是插件在工程层面把“反馈回路”自动化了。我用一个生活化的类比默认 Codex 相当于一个你每走一步都要问“我可以往前走吗”的员工Superpowers 则相当于你告诉他“这段路你自己走遇到能绕开的小石头就绕开遇到断桥再回来叫我”。它省掉的不是智力成本而是沟通成本。3.2 命令审批与安全边界自动不等于失控很多人第一次用 Superpowers 时最爽的时刻是看到它在终端里噼里啪啦自动执行一串命令。但爽完以后往往就是坑。我在早期使用中把自动批准的命令条数调得很大结果它在一个无关的配置目录里自作主张改了文件搞得我花了不少时间恢复。Superpowers 给你的自由度是分层的你可以设置自动批准的最多命令条数、可以配置某些命令必须人工确认、可以设置危险操作黑名单。我的建议很朴素从最小的自动额度开始试比如 5 条命令。跑完一个任务后你心里对“它会执行哪些操作”有了数再逐步调大额度。危险的命令一定要放进人工确认清单。比如删除文件、覆盖配置、git push、rm -rf、chmod这类有副作用且不可轻易回滚的操作我从来不会让它自动执行。你要记住模型对当前文件系统状态的理解是统计性的不是精确的它可能以为某个目录是你临时建来玩的顺手就删了。3.3 会话记忆与工作区管理下次打开还认识你如果说自主循环是 Superpowers 的引擎那跨会话记忆就是它的方向盘。它会把任务进度、已完成事项、当前待办、重要决策点写到一个结构化的文本文件里。你结束会话后它默默记下这些状态第二天打开一个新的 Codex 会话告诉它“继续昨天的任务”它就能从记忆文件里把上下文捞回来。这个设计太实用了。默认的 Codex 一旦关掉终端之前聊的上下文基本就烟消云散尤其当你处理一个大任务跑了半天发现一个细节需要调整结果重开后模型完全不记得前面的讨论。Superpowers 的记忆文件让这种“失忆”不再发生。使用时有一点需要注意记忆文件是纯文本可以被你手动编辑。如果任务中途发现方向偏了你完全可以直接打开记忆文件把“当前目标”改成你真正想做的事。这比在会话里强行纠正模型更直接、更省 token。3.4 常用内置命令组合一套我常用的工作流见过不少人在用 Superpowers 时只会把任务一股脑丢进去然后看它跑。效率高不高高但失误率也不低。我自己的做法是把它提供的内置命令拆成阶段来用比较固定的组合是规划、实现、审查三段式。第一阶段让模型先做规划。你可以通过类似/plan的命令让它梳理任务拆解、文件结构、预计改动点。这一步会生成一份计划文档存进记忆文件。第二阶段再让它进入实现模式执行代码编写和构建。第三阶段等实现完成后切到审查模式让它自查代码中的问题、补测试、清理调试输出。这套组合的本质是把“让它自己干”拆成“先想清楚再动手”。模型在规划模式下不会急着改代码输出的方案你可以先扫一眼不对劲就及时喊停。很多翻车现场其实都是因为跳过了规划阶段直接让模型冲进实现结果方向错了白白跑了一大堆命令。4. 实战记录用 Superpowers 跑一个 Java 命令行工具4.1 场景设定一个空目录和一句任务描述为了更直观地展示它到底怎么干活我拿一个真实的例子说。我准备了一个空目录想在里面生成一个 Java 命令行工具功能是读取一个 CSV 文件统计每一列的非空值数量然后输出一张简单报告。环境里已经装好了 JDK 17 和 Maven。我不打算手动创建任何项目结构全部交给 Superpowers 来跑。我给它的任务描述是这样写的“在当前目录创建一个 Java 命令行工具使用 Maven 管理读取输入的 CSV 文件统计每列非空值数量并输出报告。”这里有个实操心得任务描述越明确结果越可控。我只说了“读 CSV 统计非空值”没有指定要用哪个库、输出什么格式给了它一定的自由空间但验收标准是清晰的——能跑通、结果对。4.2 从任务输入到第一次出结果启动 Codex 会话后我切到目标目录让它创建一个工作区记录然后把任务粘贴进去。Superpowers 很快就进入了自主循环状态。它做的第一件事是创建 Maven 工程结构包括pom.xml、src/main/java下的主类。这个过程它会自动执行mkdir等命令没有向我确认。接着它开始写代码写完主逻辑后自动执行mvn compile验证编译。我注意到的第一个亮点是当mvn compile因为缺少依赖而失败时它没有停下来问我而是自己去读错误日志回到pom.xml里补上了依赖声明然后重新编译。整个过程大概 30 秒终端输出非常顺畅。随后它又自动生成了一个测试用的 CSV 文件运行了主程序检查了输出结果是否符合预期。你可能会问它怎么知道要生成测试数据因为我在任务描述里没提但它在实现阶段自己判断“需要有输入数据才能验证程序逻辑”这个判断在默认 Codex 下也常常需要用户提醒。Superpowers 的自主循环让这种“常识性补充”被自动完成了。4.3 自动修复与人工介入点整个过程中并非一帆风顺。它第一次运行mvn package的时候因为我在本地配置的 Maven 镜像源问题依赖下载失败。Superpowers 读了日志后试图修改 Maven 配置重试但连续两次都没有成功。这时候它没有继续死磕而是停下来把遇到的问题写进了工作区记录然后提示我可能需要人工决策。这个停止点其实很重要。如果它不顾一切地反复重试甚至去改系统级的 Maven 配置文件那就过了。一个合格的自动化工具要知道什么时候该停下来问人。我介入后手动调整了一下依赖镜像然后告诉它“问题已解决继续”。它从记忆文件里读取了之前的进度直接跳到依赖下载成功的状态继续打包。还有一次需要人工介入的节点是它准备执行mvn install——这会把构建产物装到本地仓库严格来说不算是“只读”操作了。它主动向我确认因为这条命令不在自动确认的白名单里。我点了确认后它就继续了。4.4 验收与收尾别让它自己提交代码任务跑完后我做的第一件事不是直接信任输出而是手动执行一遍程序用我自己准备的 CSV 数据验证结果。这一步不能省不管 Superpowers 运行得多流畅它生成的代码仍然可能有边界情况没处理比如空文件、表头缺失、CSV 里有带引号的逗号等。确认基本功能正常后我让它补了一份 README 和两个单元测试。它同样走了一遍“写代码 - 编译 - 跑测试”的循环没有让我确认一次。最后Git 提交是我手动执行的没有交给它。原因很简单我还没有 review 代码 diff不知道它改了什么。让 AI 自动 commit 甚至自动 push是我不推荐的用法至少在你不熟悉这个项目的时候不要这么干。5. 常见问题与排查技巧实录5.1 高频问题排查速查表这一节我整理了这几周在社区和我自己的使用中遇到的高频问题直接做成一张速查表方便你将来对号入座。现象可能原因解决办法启动时看不到 Superpowers 加载提示配置未生效或路径填错检查~/.codex/settings.json的 JSON 格式和路径命令列表里没有扩展命令插件加载失败多半是配置字段变了查看 README 最新配置字段重启 Codex设置了自动批准但还是要确认某些危险命令被列入强制人工确认列表查看命令白名单/黑名单配置按需调整重开会话后不记得任务进度记忆文件路径不对或工作区没建好检查工作区记录文件是否生成确保目录可写自动修复循环里反复重试同一个错误模型没有找到真正根因人工介入把错误信息中最关键的堆栈喂给它升级后行为大变新旧版本配置不兼容备份配置回滚到上一个可用 commit5.2 我踩过的三个实在坑第一个坑是我把自动批准命令数调到了 50。当时跑一个比较大的重构任务心想让它放开手脚跑结果它在一次git clean -f执行前没问我把我还没提交的临时文件全清理了。虽然那些文件不太重要但那一刻我意识到“自动批准额度”不是越大越好它决定了模型操作的“狂奔半径”。后来我所有项目的自动额度都不超过 10。第二个坑是改了 settings.json 后没重启 Codex。那一次我以为改了配置就能热生效结果在会话里折腾了二十分钟模型表现得像个完全没有超能力的普通 Codex。直到我退出重进才看到加载提示。从此我养成一个习惯凡是碰配置文件改完第一件事就是重启进程不要在会话里反复试探。第三个坑是跨会话恢复时路径写错了。我以为恢复的是 A 项目的会话结果它在 B 项目的目录里创建了一堆文件。这不是模型的问题是我自己没确认工作区路径。现在每次恢复会话前我都会先让它打印当前目录和记忆文件位置确认无误再继续。5.3 把 Superpowers 用得舒服的几个习惯用了一段时间之后我总结出几个对所有人都适用的使用习惯。任务一定要拆小。不是说你不能给它一个大任务而是不要让它一口气从零做完一个完整项目。更好的方式是把它拆成“建立项目骨架”“实现核心逻辑”“补测试”“写文档”这几个阶段每完成一个阶段你花一分钟检查一下记忆文件和关键输出。这样即使它跑偏损失也在可控范围内。验收标准在任务描述里写清楚。Superpowers 擅长执行不擅长猜你心里想什么。你在任务描述里明确“编译通过”“测试覆盖率达到多少”“输出格式是 JSON”它就能把验收动作自动跑起来你不写它可能觉得“代码能跑”就算完成。最后保持对 Git diff 的敬畏。Superpowers 自动改动的文件你一定要看 diff 再决定是否保留。它可能在修复一个问题的同时把两个无关文件的换行符全改了或者顺手删掉了一个看起来没用、实际上被其他模块引用的方法。这类问题不是 bug是模型语义判断的局限只能靠你把关。说实话我第一次跑通“自动编译失败 - 自动修复 - 自动重跑”这个循环时确实有一种“这才叫 AI 编程工具”的感觉。Superpowers 没有让 Codex 变成无所不能的超级智能它只是把那些琐碎的、重复的、本该由工具代劳的环节真正交给了工具。这种体验上的转变比单纯提升模型智商要来得实在得多。我用下来的最大体会是它最适合的是“你已经知道要做什么、但不想一遍遍盯着执行过程”的场景。你给它一个明确的目标一套清晰的安全边界它就能像一个执行力很强的实习生一样把脏活累活干完再交给你做最终检查。也别急着让它碰敏感操作先从小任务开始磨合找到你和它之间最舒服的那个“自动额度”你会回来感谢这个项目的。
