2.8 万 Star 的 oh-my-codex：Codex 真正缺的不是模型，是工作流

如果你已经把 Codex CLI 当成主力工具，我建议看一下 oh-my-codex。

但如果你只是刚装好 Codex，想体验一下它能不能写代码，我不建议第一天就装。

原因很简单。

oh-my-codex 不是让模型更聪明的魔法包。它是一套把 Codex 管起来的工程流程：先问清需求，先写计划，先审风险，再进入长任务执行。

这和普通 prompt 集合不太一样。

普通 prompt 多半是在教模型“怎么回答”。
oh-my-codex 的重点是规定“什么时候不能急着回答”。

截至 2026 年 5 月 26 日，Yeachan-Heo/oh-my-codex 在 GitHub 上接近 3 万 Star，Fork 也已经超过 2k。最新版本是 v0.18.3，发布时间是 2026 年 5 月 25 日。

这个热度不是因为它换了一个新模型。

恰恰相反，它承认 Codex 还是 Codex。它要补的是 Codex CLI 原生体验里最容易失控的那部分：长任务、模糊需求、多 Agent、计划漂移、验证不完整。

我看完新版 README 后，判断也变得更明确：

如果你只是小修小改，原生 Codex CLI 就够。
如果你经常把一整个功能、一轮重构、一个复杂 bug 交给 Codex，oh-my-codex 才开始有价值。

我最看重的是，它会先拦住你

现在很多 AI 编程工具都在讲“更快”。

更快读项目。
更快改代码。
更快开多个 Agent。
更快把任务跑完。

但我自己用下来，越来越觉得 AI 编程最危险的不是慢。

是太快。

你一句话还没说清楚，它已经开始改文件。
你只是想讨论方案，它已经建了新模块。
你让它修一个 bug，它顺手重构半个目录。
最后看起来动静很大，但你很难判断它到底解决了什么。

oh-my-codex 的第一层价值，是把这件事往回拉。

如果是我来用，不会先开 $team。我会先走这几步：

$deep-interview
$ralplan
$prometheus-strict
$ultragoal

这几个名字听起来有点中二，但背后的顺序是清楚的。

先问清楚。
再写计划。
高风险任务再审一遍。
最后才执行。

这比“再给 Codex 加十个工具”更实际。

因为很多任务失败，问题不在工具不够，而在前面根本没问清楚。

$deep-interview 适合处理一句话说不清的需求

我会最先用 $deep-interview。

它解决的不是代码问题，而是需求问题。

比如你说：

帮我重构登录模块。

这句话其实什么都没说清楚。

重构到什么程度？
只改前端，还是连后端鉴权一起改？
旧 token 要不要兼容？
测试怎么验收？
有没有不能碰的文件？
如果涉及权限，是接口层控制，还是页面层也要控制？

普通 Agent 很可能直接动手。

但我更希望它先把这些问题问出来。

这就是 $deep-interview 的价值。它把“我脑子里大概有个想法”逼成可以执行的任务边界。

对 AI 编程来说，这一步很重要。

人类同事听到模糊需求时，至少会追问几句。Agent 如果不追问，反而更危险。它会用自己的猜测把空白补上，而且补得很自信。

$ralplan 不是写漂亮计划，而是把代价摊开

需求问清之后，我会接 $ralplan。

它的重点不是写一份看起来完整的计划。

计划最容易写虚。

第一步改 A。
第二步改 B。
第三步测试。
第四步完成。

这种计划没有太大用。

我更在意的是它能不能把取舍讲清楚：

• 哪些文件会动
• 哪些模块有风险
• 哪些方案不选
• 为什么不选
• 怎么验证结果
• 出问题怎么回退

如果一个计划只告诉我“要做什么”，但不告诉我“为什么这么做、哪里可能出问题”，我不会让 Codex 继续执行。

oh-my-codex 这一层的意义，就是让 Codex 在动手前先把路线摆出来。

这一步能挡掉很多返工。

尤其是重构、鉴权、支付、库存、缓存、数据库迁移这类任务，直接让 Agent 开干，我现在会很谨慎。

$prometheus-strict 用来给计划挑刺

新版 README 里把 $prometheus-strict 放在高风险计划加固的位置，我觉得这个变化值得单独看。

它不是执行器。

它的角色接近一个严格审稿人，专门看计划有没有问题。

这一步适合放在 $ralplan 后面。

因为计划写出来以后，最怕的是你和 Agent 一起进入一种“好像都对”的状态。

比如：

先重构认证中间件，再统一权限判断，最后补测试。

看起来没问题。

但问题可能在别处：

• 老接口有没有兼容逻辑
• 管理后台和前台是不是共用 token
• 测试环境有没有真实登录态
• 权限失败应该返回 401 还是 403
• 是否会影响移动端自动续登

这些问题不是执行时才该发现。

执行前就应该有人挑出来。

所以我会把 $prometheus-strict 理解成“反对票机制”。它不是为了拖慢 Codex，而是为了防止 Codex 沿着一个看似合理、实际有坑的计划一路跑下去。

$ultragoal 是重任务入口，不是日常按钮

$ultragoal 是新版 oh-my-codex 里很核心的概念。

它适合那种真正需要持续推进的目标。

不是“帮我改个按钮颜色”。
不是“帮我补一个接口字段”。
也不是“帮我解释这段代码”。

它更适合这种任务：

把订单退款链路补完整，包括状态机、回调幂等、测试和后台操作入口。

这类任务里面会有多个阶段。

它需要计划，需要执行，需要检查，需要在中途调整，也可能需要拆给多个 worker。

这时候 $ultragoal 才有意义。

但我不会一上来就用它。

我会先用一个小任务试完整链路。

比如：

$deep-interview "clarify the failing login test"
$ralplan "plan the smallest safe fix"
$prometheus-strict "review the plan for hidden risk"
$ultragoal "execute the approved fix and verify it"

如果一个小任务都跑不顺，就不要拿它去改一整套架构。

这不是对工具不信任。

这是对复杂任务的基本尊重。

$team 很吸引人，但我不会把它当第一卖点

很多人看 oh-my-codex，会被 $team 吸引。

这很正常。

多 Agent、并行 worker、tmux、mailbox、任务队列、handoff，这些词听起来都很强。

但我现在反而不太愿意先讲 $team。

因为多数人的问题不是“worker 太少”。

多数人的问题是：

任务没有拆清楚。
写集没有隔离。
验收标准没有定。
多个 Agent 改完以后没人合并。
最后 diff 很大，但责任边界不清楚。

这种情况下，多 Agent 不是加速器。

它会把混乱放大。

我只会在一种情况下用 $team：任务已经有清楚计划，而且天然可以并行。

比如：

• 后端接口、前端页面、测试用例可以拆开
• 多个失败用例可以独立排查
• 文档、实现、验证可以分工
• 多个模块之间写集重叠很小

如果任务还没拆清楚，我宁愿让一个 Agent 慢慢做。

慢一点没关系。

乱才麻烦。

.omx/ 才是它区别于普通 prompt 包的地方

我很在意 .omx/。

因为它说明 oh-my-codex 不是只靠几句提示词在撑。

它会把计划、日志、状态、运行痕迹放到项目目录里。

这件事看起来不如多 Agent 酷，但对长任务更重要。

AI 编程最怕一种情况：

前面聊了很多，Agent 也做了很多，但真正留下来的只有一堆改动。

你不知道它为什么这么改。
你不知道它中途否掉了什么方案。
你不知道哪些验证跑过。
你不知道下一轮应该从哪里继续。

.omx/ 解决的是这个问题。

它把 Agent 的工作过程从“聊天气泡”变成“项目状态”。

这也是我认为它比普通 skills / prompts 更重的地方。

重有重的代价，但也有重的价值。

如果你只是临时问一句，不需要它。
如果你要把一个任务跑几个小时，甚至拆成多轮继续做，状态落盘就很有必要。

安装前先看清楚：它主要服务 Codex CLI

这一点要说清楚。

oh-my-codex 不是 Codex App 增强工具。

它服务的是 OpenAI Codex CLI。

如果你主要用桌面版 Codex App，不怎么碰终端，那它不是你的第一选择。

它的 README 也写得很直接：默认推荐环境是 macOS / Linux + Codex CLI。Windows 原生路径和 Codex App 都不是默认体验。

Windows 用户如果要试，我会建议先走 WSL2。

不要在原生 Windows 上一边折腾 Node、tmux、psmux、Codex CLI，一边再折腾 OMX。出了问题你会很难判断是哪一层坏了。

安装也别一上来就乱装。

如果你已经有 Codex CLI：

npm install -g oh-my-codex

如果你还没有 Codex CLI，再装：

npm install -g @openai/codex
npm install -g oh-my-codex

README 里还特别提醒，不要把 npm install -g @openai/codex oh-my-codex 当成统一标准答案。尤其是 Codex CLI 如果是 Homebrew、系统包或别的方式安装的，混在一起装反而可能把所有权搞乱。

这句话很实在。

很多 AI 工具教程最容易省掉这种细节，但真正出问题时，往往就是这些安装路径和权限问题。

omx doctor 只是体检，不是验收

omx doctor 很有用。

但我不会只看它。

README 里也写得很清楚：omx doctor 检查的是安装形态、hooks、运行时前置条件。它不能证明当前 Codex 环境一定能真实发起模型请求。

所以我会把 smoke test 当成必做步骤：

omx doctor
codex login status
omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"

这一步尤其适合国内用户。

因为你可能有代理。
可能有自定义 openai_base_url。
可能有多个 Node。
可能 shell 里的环境变量和你平时打开的终端不一样。

doctor 通过，只能说明体检项目过了。

真正执行一次，才知道链路是不是通的。

如果是我来试，会按这个顺序

我不会第一天就开 $team。

我会这样试：

第一步，先确认原生 Codex CLI 正常。

codex login status

第二步，安装 oh-my-codex。

npm install -g oh-my-codex

第三步，做检查和真实执行。

omx doctor
omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"

第四步，拿一个小任务跑主流程。

$deep-interview
$ralplan
$prometheus-strict
$ultragoal

第五步，确认它真的能留下计划、状态和验证结果。

第六步，再考虑 $team。

这里的关键不是把功能全部试一遍。

关键是确认它有没有让任务更可控。

如果装完以后，你只是多了一堆命令，但任务还是一上来就乱改，那它对你没有价值。

谁适合装，谁可以先跳过

我觉得这类人适合试：

• 已经长期用 Codex CLI
• 经常处理跨文件、跨模块任务
• 经常让 Codex 跑长任务
• 重视计划、审查、验证和状态记录
• 愿意理解 tmux、hooks、.omx/、worker 边界
• 最好用 macOS、Linux 或 WSL2

这类人可以先跳过：

• 只是刚开始体验 Codex
• 主要用 Codex App
• 只做小修小改
• 不想维护本地状态目录
• 不想处理终端、Node、tmux、环境变量
• 期待“装完一个包，AI 自动变强”

oh-my-codex 不是轻工具。

它是给重度 Codex CLI 用户准备的一套工作台。

你的任务越复杂，它越可能有用。
你的任务越简单，它越可能显得重。

最后

AI 编程现在真正进入的阶段。

模型能力还会继续涨，但日常开发里更稀缺的，已经不是“会不会生成代码”。

而是：

需求能不能问清。
计划能不能被审。
任务能不能推进。
状态能不能留下。
多 Agent 能不能收住。
结果能不能验证。

oh-my-codex 做的就是这件事。