如果你也用Codex CLI写过代码一定会有这种感觉AI确实能写但完全离不开人。每跑一步都要你点批准每做完一个文件就停下来问下一步盯它的时间比自己写还多。superpowers这套工具包解决的正是这个“半自动”问题。它本质上是一组给Codex CLI打补丁的技能系统让AI从“你问一句我答一句”变成“你给目标我自己规划、自己执行、自己修错、自己验收”。这篇文章我把从下载到实战的所有细节写清楚包括怎么装、怎么配置、用Java项目跑一个真实任务以及我踩过的几个坑。1. superpowers的设计思路它到底给AI增加了什么能力1.1 普通Codex CLI为什么越用越累Codex CLI本身是个非常强的终端编程助手跑起来以后能读写文件、执行命令甚至在本地起一个容器做实验。但它有个使用体验上的致命点每一步都要经过你。你让它“加个分页接口”它会先问你要不要读Controller读完了再问要不要改Service改完了再问要不要跑测试。你以为在指挥AI实际上变成了给AI跑腿签字的人。为什么设计成这种交互模型因为安全。默认策略下Codex不能擅自执行你不确认的命令也不能改你没点头的文件这样能避免模型抽风搞坏环境。但代价是效率极低。尤其是多文件改动、多步骤联调这种场景人工确认的次数甚至会超过手写代码的次数我想这是很多人都放弃深度使用Codex的原因。superpowers的切入点就在这儿它不替代Codex的底层模型能力而是通过一套结构化的“技能包”把任务规划、命令执行、结果检查、错误修复这些环节串成闭环。AI在收到一个目标后会先给自己写一份任务清单然后逐条执行、逐条打勾遇到报错就读日志、改代码、重跑直到清单全部完成。这个流程意味着你需要在安全性和自动化程度之间做一个取舍而superpowers把这个取舍通过配置暴露给你。1.2 核心设计把“思考”物化成文件我看过不少AI编码辅助项目很多都在堆功能但superpowers的思路不一样。它最核心的设计是让AI把计划和状态写到项目目录下典型的就是task.md、plan.md这类文件。AI接手任务后会在项目里生成一个任务描述文件把需求拆成可验证的步骤每一步都写清楚“做什么、怎么验证、完成标准是什么”。这个设计有三个明显的好处。一是AI不容易“忘事”每一步都落盘在文档里就算上下文被截断下次启动还能接着干。二是你随时能检查AI的思路打开task.md就能看到它准备怎么改代码而不是等它改完再猜。三是任务完成后的验收有了依据AI会按清单逐条确认而不是凭感觉说“我做完了”。我最初觉得这个做法有点笨——让AI写文档还不如让它直接写代码。但实际用了以后我发现这个“笨办法”恰恰解决了AI编程最大的不稳定性。模型思维是概率性的写下来的计划是确定性的。只要AI按照自己的计划执行哪怕中途模型换了一个后续步骤依然是清晰的。这也是为什么我在多文件重构时特别依赖这种模式。1.3 superpowers、Codex CLI、WorBuddy三者的关系这里有个容易混的概念。Codex CLI是OpenAI出品的终端AI编程工具负责连接模型、管理权限沙箱、执行命令。superpowers是一套运行在Codex CLI之上的技能包它通过AGENTS.md和技能目录告诉AI“你有额外能力可以用”。而WorBuddy可以理解为给Codex CLI套了一层更友好的图形界面同时也会读取同样的技能配置。所以从技术链路看底层都是Codex CLI在调用模型superpowers负责扩展AI的工作方法论WorBuddy负责把对话界面变得更顺手。我用WorBuddy跑superpowers时感觉更像是在用IDE而直接开终端用Codex时更像在和一个极客同事协作两者各有好处。你完全可以在纯终端环境里用superpowers也可以搭配WorBuddy使用策略文件是共享的。正是这种解耦设计让我觉得superpowers比某些“全家桶”方案更靠谱。它没有把自己绑死在某个特定工具上而是把增强能力做成了标准化技能包谁都能调用。2. 安装与初始化让AI获得超能力的最小路径2.1 前置条件与版本确认先说环境要求。superpowers本身是脚本加配置的组合对操作系统要求不高macOS和Linux都能跑Windows下通过WSL也能用。但有几个前置条件你必须先确认不然装完会发现各种神奇问题。第一Codex CLI必须已经装好并且能正常对话。我建议你先在终端里跑一句最简单的指令比如“11等于几”确认模型响应正常后再往下走。第二Node.js版本最好在20以上因为skill脚本里有不少依赖新版Node API。我在一台Node 18的机器上跑过部分技能会直接报语法错误升级Node 20后就好了。第三Git要能用因为大多数安装方式都需要克隆仓库而且后边的技能更新也依赖Git。还有一点要注意如果公司内网环境比较严格访问API不稳定你得先解决网络通畅问题。我见过很多人装好后卡在“AI半天不响应”排查到最后根本不是superpowers的问题而是网络超时。2.2 三步完成安装安装流程不复杂但网上有些教程写得啰嗦我把核心路径提炼成三步。第一步把项目克隆到本地。我习惯放在用户目录下方便管理git clone https://github.com/jeffhosler/superpowers.git ~/superpowers cd ~/superpowers第二步把技能目录软链接到Codex的配置目录。因为Codex CLI启动时会去~/.codex/skills下加载技能直接把目录指过去就行ln -s ~/superpowers/skills ~/.codex/skills如果你用的Codex版本较新它可能优先读取项目内的AGENTS.md文件你还需要在自己的项目根目录放一个说明文件告诉AI去加载superpowers技能。方法是在项目下创建AGENTS.md内容写一句你需要使用 superpowers 技能包来完成编程任务。首先加载 available_skills 里的能力说明然后按 plan、execute、verify 的流程工作。第三步验证安装。进入任何一个项目目录启动Codex后问它“你有没有superpowers技能”如果它回答出“有我可以规划、执行、验证”说明加载成功。第一次加载可能会比较慢因为AI要读取一大堆技能描述后面会有缓存就会快很多。2.3 模型与权限配置安装只是第一步运行体验好不好很大程度上取决于~/.codex/config.toml里的配置。我在这个文件里踩过不少坑把最有用的几个参数说明一下。模型选择上我建议优先用o3或者GPT-5系列因为superpowers的规划能力依赖较强的推理模型。如果你用太小的模型AI经常会“假装”自己完成了任务实际上只改了一个文件。这里有个不成文的经验推理能力越强的模型越适合做多步骤任务因为它的规划结果更可靠。model o3 model_provider openai approval_policy on-request [model_providers.openai] wire_api responsesapproval_policy是我特别想提醒你的。默认值下AI执行每条命令前都要弹确认框对于superpowers这种全自动流程来说会烦死你。我个人的做法是在自己的开发机上用on-request也就是AI只在遇到敏感操作时才询问在CI环境或完全可重建的开发容器里再考虑更激进的策略。但别一上来就开全自动。我第一次跑superpowers时直接开了最大权限结果AI在项目里乱建了一堆临时文件最后还得手动清理。建议先保持温和的审批策略跑几轮没问题再逐步放开。2.4 冒烟测试让AI自己跑通一条流水线配置好以后我建议你做一次冒烟测试免得真到任务里才发现链路不通。最简单的方式是让AI做一个“给项目加一行注释”的任务。启动Codex输入类似这样的话codex 请使用 superpowers 工作流在 README.md 开头加一行说明然后执行 git diff 给我看结果。如果配置正确你会看到AI先创建task.md然后读文件、改文件、跑git diff最后在对话里回放结果。跑完一次以后你可以顺手用skill-update让AI自行检查技能包版本它会告诉你哪几个技能需要更新、怎么更新。这个冒烟测试非常值得做。它只要一分钟但能同时验证技能加载、命令执行、文件读写三个核心链路。很多新手忽略这一步直接上大任务结果排查了半天发现是环境变量的问题非常浪费时间。3. 实战复盘用superpowers完成一个Java接口开发3.1 任务规划从模糊需求到可执行清单实战我用的是一个Spring Boot项目需求是给订单模块新增一个分页查询接口。单说需求本身对AI来说不难但我特意没说清楚实现细节就想看看superpowers能不能自己把方案定出来。启动后我给的原始指令是请按 superpowers 工作流完成订单分页接口开发。需求GET /api/orders?page1size20返回 PageResultOrderVO。使用 Spring Data JPA不要改动数据库表结构。接下来大概半分钟AI在项目根目录生成了一个task.md。我打开看了一下它把任务拆成了这么几条梳理现有Order实体与Repository接口创建OrderVO和PageResult类新增Controller接口补充Service层分页逻辑运行mvn compile验证编译运行mvn test执行相关测试。这里有一个让我很舒服的细节它写“不要改动表结构”其实理解成了“不要改实体字段映射关系”并且在计划里明确标注了“不迁移数据库”。这说明模型正确捕获了我的约束条件。当然不是每次计划都这么靠谱。有时候AI会漏掉一些隐含步骤比如忘了加RestController注解。这种时候我一般不会直接告诉它“你漏了注解”而是指出计划里的对应步骤没有写验证标准。它就会重新调整计划。这个“通过计划对齐预期”的过程比在代码层面对齐要高效得多。3.2 自动执行AI自己跑Maven命令并修复报错规划完成后AI开始执行。这一步是最能体现superpowers价值的地方。正常情况下AI会先看pom.xml确认Spring Boot版本再读OrderController判断现有代码风格然后才开始写代码。在执行阶段AI写文件的方式也和默认模式不同。默认模式下它每次改动前都要你批准在superpowers的全自动策略下它会连续改好几个文件然后自动运行mvn compile。我第一次看到它在没有我做任何操作的情况下自己跑编译其实有点紧张——万一把项目改坏了怎么办。结果它还真改出过问题。有一次它新建的PageResult类里用了一个我不知道的泛型写法编译直接报错。关键是接下来的行为这才是superpowers真正厉害的地方AI读取了编译日志定位到错误行号自己把泛型改回常见的PageT结构然后重新跑了一遍mvn compile直到编译通过。整个过程我没说一句话也没点一次确认。如果你用默认的Codex CLI这种“报错-修复-重跑”的循环通常需要你介入告诉它“看一下报错再改”。而superpowers通过技能描述让AI形成了条件反射遇到编译失败先去读日志再分析根因而不是盲目重试或者换个写法糊弄过去。这个体验上的差距用过一次就很难回去。3.3 多文件编辑与最终验证编译通过之后AI会对刚才生成的代码做一次自查。这一步在superpowers里有一个专门的验证技能它会重新读取所有改过的文件检查几个常见问题类名是否语义化、Controller是否缺少统一返回体、有没有打印不必要的信息到日志、有没有硬编码魔法值。我注意到它在OrderVO里生成了一个叫orderStatus的字段但实体类里对应的字段名是status它自己发现后在VO里加了JsonProperty(status)注解来兼容前端字段。这种细节如果没有专项检查环节普通的一次性生成代码根本不会主动处理。全部检查通过以后AI跑了一遍mvn test确认已有的测试没被破坏然后更新了task.md把每一条标记为完成。最后它给出了一个简单总结新增文件3个修改文件2个编译测试全部通过未改动数据库。我后来人工核验了一遍代码整体质量确实能直接用。有一个小问题是它把分页大小的默认值写死在Controller里了虽然不影响运行但严格说的话应该抽到配置文件。我把它提给AI后它立刻改成了Value注入。这种“人工验收时发现小问题随手丢回给AI修”的工作流已经成了我这几个月的常态。4. 高频踩坑与排查实录4.1 权限、环境变量与沙箱冲突全自动模式最大的敌人不是AI太笨而是环境权限不够。我在最开始跑superpowers时任务卡在了AI执行sudo命令的环节。默认沙箱下Codex不允许AI执行sudo它会要求人工授权结果脚本在这里直接挂起看起来就像“AI卡死了”。遇到这种情况我的建议是分两步。第一步项目环境尽量用不需要sudo的命令。比如装依赖用npm install --prefix而不是全局装启动服务用sysctl调整端口而不是改系统配置。第二步如果确实需要更高权限比如要改Nginx配置才能完成联调我会在Codex的配置里为该命令设白名单而不是直接放开所有sudo权限。另一个高频问题是环境变量不生效。AI在终端里跑命令时未必会加载你的~/.zshrc或~/.bashrc导致它找不到node、java或docker命令。这个坑我踩过好几次后来在AGENTS.md里加了一番说明告诉AI“执行命令前先确认PATH中包含/usr/local/bin、$HOME/.nvm等目录”情况才明显好转。4.2 上下文窗口溢出与任务过长superpowers让AI能连续工作很久但模型的上下文窗口依然是硬约束。我在一次代码评审任务里让它读了一个大型模块的全部Controller结果中途就出现了早期任务细节被挤掉的情况。具体表现是AI开始重复读取文件、忘记task.md里已经打勾的步骤、甚至把两个不相关的步骤弄混。这个问题没有完全根治的办法但有几个缓解技巧。一是尽量把任务按模块拆分不要让AI“通读全部代码”。二是利用task.md的摘要机制让AI在每个阶段结束时更新文档这样即使上下文被截断重启后还能从文档恢复状态。三是控制无关文件的读取可以在需求里明确“只读取src/main/java/com/example/order包下的文件”避免它去翻其他模块。我在实际使用中甚至会刻意把大任务拆成两三个会话规划一个会话执行一个会话验证再一个会话。虽然看起来麻烦但每个会话的上下文都干干净净AI反而跑得更稳。4.3 AI陷入死循环与失控全自动模式跑久了难免遇到AI反复执行同一操作、结果完全没进展的情况。我遇到最离谱的一次是让AI修复测试用例它改完一个断言发现测试还挂就开始尝试另一个方案又不行又换一个方案前前后后改了十几轮项目目录里出现了好几个备份文件问题依然没解决。后来我加了两个约束才好转。第一在任务指令里写清楚“每次尝试方案前必须在task.md记录失败原因一个方案失败超过两次就停下来询问人类”。第二使用Codex自带的终止条件参数比如限制最大循环次数或在任务变得无意义时强制中断。需要注意的是单纯的“让它别乱来”在模型层面并不可靠必须把约束变成流程的一环。遇到这种卡死状态我一般会用两条指令收尾先问AI“你刚才做了什么为什么一直失败”引导它整理思路然后再加一条“请把当前状态记录在task.md并列出下一步的选项”。绝大多数情况下让AI把问题讲清楚以后它自己就能意识到在钻牛角尖。4.4 WorBuddy场景下的使用差异如果你和我一样有时在终端里跑Codex有时又打开WorBuddy用图形界面那你需要注意一个差异WorBuddy可能会对任务执行做额外的权限弹窗。这本身不是问题但如果你之前在终端里配置了全自动策略切到WorBuddy后还是会弹确认框容易让人以为配置失效了。原因在于WorBuddy为了保证图形界面下的安全性会维护一套独立的审批配置。我的做法是在WorBuddy的偏好设置里把技能加载目录指向同一个~/.codex/skills然后单独配置它自己的审批级别。不是说非要两套都自动而是你要清楚当前工作在哪套配置下避免误判。此外WorBuddy在渲染AI输出时会自动折叠长命令如果你看到“命令执行成功”但实际没有日志点一下展开就能看到完整输出。这种展示层差异不影响底层逻辑但排查问题时容易被误导。5. 从会用到用好留给后来的朋友几个心得我自己用superpowers跑了大概三周最大的感受是它让我重新理解了“AI编程”这件事。以前我觉得AI是个高级补全器现在我更愿意把它当做一个能独当一面的初级组员——前提是你得给它一套明确的工作方法论。superpowers的价值恰好就是把这套方法论沉淀成了技能包。关于进入姿势我真心建议从小任务开始。不要第一次就丢给它一个一周工期的重构任务哪怕它规划得很像样。先在真实项目里跑几个小需求把任务拆解、命令执行、自动修错这几个环节都跑顺了再逐步加大任务量。这个过程也是逐渐建立你对AI的信任感的过程——说实话我看AI自己跑mvn deploy的时候心脏是有点承受不了的。还有一个小技巧任务简报尽量写得像给同事发消息一样别写太长。核心信息就那么几条做什么、在哪做、别碰什么、怎么算完成。我发现把约束说清楚比把实现细节说清楚更重要。superpowers的规划能力足够强让它自己琢磨实现方案效果反而比手把手教它更好。工具迭代很快我用的版本和下个月的新版本肯定又有差异。如果哪天你发现某个技能没生效先别怀疑智商多半是路径配置或者版本问题。去项目仓库看更新记录再对一下AGENTS.md基本都能解决。“用文档把AI的行动边界和流程固定下来”这件事本身就是superpowers最值得学的地方哪怕你以后换了工具这套工作习惯也能一直用下去。
