oh-my-codex vs Superpowers：Codex 编排还是技能纪律？

TL;DR

• oh-my-codex是 OpenAI Codex CLI 的开源编排层：它通过 tmux 在相互隔离的 git worktree 中启动多个并行 Worker Agent，把计划与记忆保存在项目内持久化的 .omx/ 目录中，并推动「澄清到完成」的工作流，让一个人能同时推进多个编码任务。

• Superpowers是一套可移植的技能与方法论框架，可装进 Claude Code、Codex、Cursor、Gemini CLI 等 Agent；它不加并发，而是加流程——头脑风暴、书面计划、测试驱动开发与代码审查，成为你的 Agent 默认的工作方式。

• 实操层面的差别：oh-my-codex 放大的是 Codex 能并行干多少活、并且跨会话记住状态；Superpowers 抬高的是代码质量下限——在你已经使用的任何一个 Agent 里，都强制先规划、先写测试。

• 两者是互补品，不是对手。2026 年常见的配置是：Claude Code 里装 Superpowers，用来做谨慎、测试先行的工作；当以 Codex 为主的项目需要后台 Agent、持久状态与团队运行时，再叠加 oh-my-codex。

1. 同一挫败感的两种叠加层

到 2026 年，开出一个好用的编码 Agent 会话，已经不再是做软件最难的部分；难的是会话之后的事。在几十轮对话里保持项目逻辑一致、在 Agent 修改你没盯着的文件时避免回归、并且有足够信心让一个自动化循环跑上一个小时——真正的崩溃都发生在这里。本文对比的两个工具，正是从相反方向解决这第二个问题；又因为它们都不能替代 Claude Code 或 Codex，所以总是被混为一谈。

这个「叠加层」问题对独立开发者最要紧：一家一人公司没有资深工程师、没有代码审查文化，也没有 CI 站在「自信的模型」和「坏掉的代码库」之间把关——那些让大团队保持自律的仪式，当你一个人就是整个团队时，根本不存在。这也是「氛围编程」（vibe coding）时代迎来一场安静清算的原因。提示词技巧进步得很快，但流程、审查与并行化并没有跟着来。我们在 vibe coding 能做什么、不能做什么 一文里拆解过这件事，简而言之：差距已经从模型质量，转移到模型周围的纪律与运行时。

正是这种转移，让这次选择成为真正的取舍，而不是品牌偏好。oh-my-codex 作用于运行时——同时跑几个 Agent、它们在哪儿干活、跨会话记住什么。Superpowers 作用于方法——Agent 在写代码之前做什么、怎么测试、怎么审查自己。记住「运行时 vs 方法」这条分界线，本文其余部分只是把它套用下去。

2. oh-my-codex：Codex CLI 之上的编排层

oh-my-codex 常简称为 OMX，是一个包装 OpenAI Codex CLI 的 TypeScript 项目，用 npm install -g oh-my-codex 全局安装。它把自己定位成「工作流层」而非替代品：Codex 仍是那个读文件、跑命令、写代码的执行引擎，OMX 则打理它周围的一切。这个项目的资历比它的名声更年轻、也更小——写这篇文章时，官方仓库大约 1,700 颗星——但它已经搭起了一套相当有主见的架构，越来越多的独立开发者每天都在跑。

核心机制是「带隔离的并行执行」。当你从一个 git 项目启动 OMX，它会以 tmux 托管的 Worker 形式启动多个 Codex 会话，每个 Worker 各占一个 git worktree，这样两个 Agent 可以改同一个仓库而不会在文件编辑上互相撞车。这些 Worker 外围是一层 HUD 式监控界面，显示每个 Agent 正在做什么；PreToolUse、PostToolUse 等 Codex 原生钩子则在 Agent 生命周期的正确节点注入 OMX 的工作流提示词，而不是指望模型自己记得。

第二个特点是持久化。OMX 把计划、日志与记忆存在项目内的 .omx/ 目录中，所以跑几个小时的任何任务——或一次被打断的会话——都能从已记录的状态恢复，而不是从头再来。官方工作流正是为此而生：请求含糊时，$deep-interview 会追问澄清；$ralplan 产出并审批带取舍的实现计划；之后执行交给单个 Agent 循环，或交给协调多个并行 Worker 朝同一目标推进的 $team。Codex 始终坐在协调者的位子上，2026 年初起，团队模式里 Claude 或 Gemini 也可以出任 Worker 角色。

对独立开发者来说，结果是杠杆：不必盯着一个 Agent 跑完一个任务，你可以把几个隔离的 Worker 播到不同分支上，在 HUD 里观察它们，再审查完成的工作。对本来就信任 Codex 的人，这相当于不增加人手却放大吞吐。代价是：只有当你手里真有互相独立的任务可以并行时，这套机制才划算——单独做一个改动时它是纯开销——而且它「macOS + Linux + tmux」的取向，对某些环境是实打实的限制。我们在 OpenAI 开源 Codex harness 的拆解里，更详细地聊过那个底层循环。

3. Superpowers：装进任何 Agent 的方法论

Superpowers 押的是相反的注：不给你更多 Agent，而是让你手里那个 Agent 用一种更严的方式干活。它由 Jesse Vincent 与 Prime Radiant 创建，是一套可组合的技能框架——每个技能都是一份纯 Markdown 的 SKILL.md 指令文件，配上一些 shell 辅助脚本——可装进 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot CLI 等多个载体。采用速度相当陡：写这篇文章时，官方仓库大约 76,000 颗星，自 2025 年底发布以来，已经成为生态里被用得最广的 Agent 技能项目之一。

价值在方法里。Superpowers 生效时，Agent 不会在你一描述功能就扑上去写代码；它会先进入头脑风暴阶段，问澄清问题，写一份你真的会读、会审批的简短设计文档。签字通过之后才进入规划——把工作拆成小而可验证的任务——然后是测试驱动开发，强制执行 red-green-refactor 循环：写实现代码之前，必须先存在一条失败的测试。代码审查与系统化调试为这个循环收尾；因为技能会自动触发，就算在某个又累又想赶紧发布的周二下午，纪律依然守得住。

项目自己的话总结了这套哲学：「纪律胜过灵感」（discipline over inspiration），这是对前沿模型最危险的特质——它们的自信——做出的刻意回应。先规划、先测试的模型偶尔还是会写错东西，但错误发生在有审查、有失败测试兜底的结构里，而不是三周之后由用户发现。技能是纯文本，所以透明、可编辑——你能精确读出自己装的是什么流程；技能还可移植，所以无论你从 Claude Code 换到 Codex 再换回来，方法论都跟着你——在这个每几个月就变一次的工具版图里，这是实打实的优势。

不过，这些都不会带来并发。Superpowers 让单个会话更可靠；它不会同时跑很多会话，也不会像编排层那样把状态跨几天持久化。对「我的 Agent 老是写出粗糙代码」的单人创业者，它近乎理想；对「并行跑不了多少活」的人，规模化问题依然无解。这正是两个项目最终被一起使用、而不是互相对抗的原因。

4. 正面交锋：它们各自到底改变了什么

把 oh-my-codex 和 Superpowers 摆在一起对比有点别扭：它们共享词汇，却不共享工作——两者都叫「workflow」，都提计划与 Agent，都是 MIT 许可、住在你终端里的项目。但把运行时与方法论分开看，差别就会变得具体，而且大部分互不重叠，如下表所示。

用正确的方式读这张表，会浮现出粗放式「对垒」叙事会漏掉的几个细节。除非你深度投入 Codex、手里又有可并行的活，oh-my-codex 几乎没什么用；Superpowers 则与载体无关，装到新 Agent 上的第一次会话就开始有用。同时，Superpowers 的方法论有多严，取决于宿主 Agent 愿意遵守到什么程度；OMX 则通过流程与状态强加结构，模型没法悄悄跳过。

两列量的本来就是不同的东西。如果你在意的那一行是「我一次能跑多少任务」或「工作会不会在笔记本重启后还在」，只有 oh-my-codex 答得上。如果你在意的那一行是「我的 Agent 会不会先测试、先审查再宣布胜利」，那就是 Superpowers 存在的全部理由。那些想两行通吃的工具，最后往往发现并发与方法论是两条独立的轴——所以，先挑当下让你最出血的那条轴。

5. 何时 oh-my-codex 是更优选择

如果你已经住在 Codex 里，而你的活天然由互相独立的任务组成——重构这个模块、迁移那个服务、再给第三块区域补测试——oh-my-codex 是更好的选择，因为它把这些任务变成你监控的后台工作，而不是你要亲自驱动的会话。让这一切安全成立的关键细节是隔离的 git worktree：每个 Worker 改自己的 checkout，一条分支上的狂野重构不会弄坏另一个 Worker 正在改的代码；持久化的 .omx/ 状态则让长达数小时的运行可以暂停、恢复，而不是撞上上下文上限白烧。

「团队运行时」把同样的思路延伸到单个 Agent 干不了的活上。与其让 Codex 把整套架构在脑子里撑三个小时，不如审批一份计划，让协作的 Worker 去执行，各管一块、把证据回报给领头者。对手里真有积压需求的独立开发者，这就是「晚上用来敲提示词」和「晚上用来审查已完成、彼此隔离的改动」之间的差别——HUD 给了你除了希望之外可以信的东西。

但这些是有真实成本的。OMX 主要为 macOS/Linux + tmux 调优，所以 Windows 上你从第一天起就走在次级、支持较少的路径上。这个层加了不少活动部件——hooks、worktree、团队状态——Codex 一更新，偶尔就会坏；它的高级参数还能整个绕开审批闸门，这种自主性只该在你信得过的仓库里开启。如果这听起来是「每小时干更多 Codex 活」的合理代价，就用它；否则，它大概还不是你的菜。

6. 何时 Superpowers 是更优选择

如果你的主力载体是 Claude Code，或者你每周在 Claude Code、Codex、Cursor 之间换来换去，Superpowers 是更好的选择，因为它给你一套不关心底层是谁的方法论。「头脑风暴优先」的流程是最被低估的部分：逼着 Agent 先提问、写一份你审批的设计，能在任何代码存在之前就拦下一大批误解——昂贵错误恰恰发生在这里。任何看过 Agent 兴致勃勃实现错误功能的人，都会认同光这一个环节就值回安装。

测试驱动循环是 Superpowers 在重质量的工作里胜出的第二个理由。要求实现代码之前先有失败的测试，并在任务之间跑审查，把模型盲目的自信变成可审计的东西；而且因为技能只是普通文本文件，你能读出自己信任的确切流程，再按项目需要裁剪。这介于「偶尔走运的 Agent」和「有可重复流程的 Agent」之间；对回归代价高昂的代码库——支付逻辑、鉴权流程、数据迁移——可重复性胜过原始吞吐。

Superpowers 帮不上忙的地方是规模。它不拉起并行 Worker，不保存跨会话的持久状态；在超长任务上，它依赖宿主载体的上下文管理，所以会话一拉长，纪律就会变软。对把 Claude Code 当日常工具的单人创业者来说，周边配置同样重要——我们写 Claude Code 给单人创业者与非开发者 的文章覆盖了整套环境——但如果你真正的瓶颈是量，没有任何方法论修得好。

7. 大多数人最终会跑起来的组合

这场对比之所以拒不出一个干净赢家，是因为运行时与方法论本来就不是二选一的购买项。越来越多的开发者两个都跑：载体里装 Superpowers，让每个会话从规划与 TDD 开始；需要后台 Worker 和大规模推送的持久状态时，再在 Codex 之上叠 oh-my-codex。两层不打架，因为它们管的是不同的时刻——Superpowers 决定每个任务怎么执行，OMX 决定哪些任务跑、在哪里跑、带着什么记忆跑。

把 OMX 想成生产车间，把 Superpowers 想成车间里每个工人都要遵守的质量清单。现实中的摩擦点在上下文预算：两个工具都会注入指令，在小模型上，一个会话可能在实际工作开始前，就把相当可观的上下文耗在流程样板里。务实的解法是：利用 Superpowers 透明的技能文件，只保留你需要的环节——探索性工作用头脑风暴与审查，凡是需要长期维护的东西用 TDD——把 OMX 的团队模式留给大到值得付出协调开销的活。

如果你还拿不准从哪儿开始，用你最主要的瓶颈当决胜项。如果你抱怨的是「Agent 写出来的代码很糙、我不信任它」，先装 Superpowers，让它的循环在真实项目上跑一周。如果是「任务比时间多，我的 Agent 一次只能干一件事」，先用单个 worktree 把 oh-my-codex 搭起来，在一个并行任务上学会这套工作流，再往外扩。无论走哪条路，你都没有把另一个工具锁在门外——这个组合更互补，而不是更竞争。

8. 结论

oh-my-codex 与 Superpowers 回答的是不同的问题，这正是把它们对立起来会带来更多困惑而非清晰的原因。oh-my-codex 回答的是「怎么用 Codex 并行跑更多活，并且随时可恢复」；Superpowers 回答的是「怎么让每一个 Agent 会话都规划、测试、审查，而不是靠猜」。两者都是严肃、活跃维护的开源项目——OMX 是更年轻、更精简的编排层，Superpowers 是更大、更可移植的方法论——谁也不该在这场比赛里输掉。

装任何东西之前，先说出你真正的瓶颈。当你是 Codex 重度用户、有可并行或长跑的任务、且能接受它 tmux + Unix 的取向时，选 oh-my-codex；当你想要一套能跟着你跨 Claude Code、Codex、Cursor 的纪律，或者质量波动才是拖慢你的原因时，选 Superpowers。当两种痛在同一周出现——对真在推产品的单人创业者来说，这一天迟早会来——就让它们一起跑：一个管生产车间，一个管质量线。