oh-my-codex：给 Codex CLI 加上工作流、技能和运行时护栏

Mon, 25 May 2026 07:41:45 +0800

Yeachan-Heo/oh-my-codex，简称 OMX，是一个围绕 OpenAI Codex CLI 的工作流层。

项目地址：https://github.com/Yeachan-Heo/oh-my-codex

它想解决的不是“再做一个新的 coding agent”，而是让已经在使用 Codex CLI 的人，有一套更稳定的日常工作方式：启动时带上项目指令，任务变复杂时先澄清再计划，执行时有 durable goal 和状态记录，收尾时用 review 和 QA 把结果压住。

截至写作时，GitHub 页面显示仓库约有 29.4k star，最新 release 是 v0.18.1，发布时间为 2026 年 5 月 21 日。README 也明确说，官方项目是 Yeachan-Heo/oh-my-codex，官方 npm 包是 oh-my-codex，不要把第三方 “OMX v2” 项目误认为这个仓库的官方延续。

它到底是什么

OMX 不替代 Codex。

它保留 Codex CLI 作为实际执行引擎，自己主要补三类东西：

更固定的任务流程。
可复用的 prompts、skills 和 specialist agents。
.omx/ 目录下的计划、日志、状态和运行时记录。

换句话说，Codex 负责“动手干活”，OMX 负责“让干活过程更像工程流程”。这也是它和普通 prompt 包最大的区别：它不是只往系统提示词里塞规则，而是把澄清、计划、执行、检查、团队协作和运行时诊断拆成一组可调用的工作面。

默认工作流

OMX 的主线工作流大致是：

$deep-interview "clarify the authentication change"
$ralplan "approve the auth plan and review tradeoffs"
$prometheus-strict "stress-test the plan before durable execution"
$ultragoal "turn the approved plan into durable Codex goals"

其中最常用的是三步：

$deep-interview：在需求还不清楚时追问边界、目标和非目标。
$ralplan：把需求整理成计划，并经过架构与批判视角确认。
$ultragoal：把批准后的计划转成更耐跑的目标和检查点。

如果任务需要并行协作，可以在 Ultragoal story 里用 $team；如果只需要一个持续推进的单人循环，可以用 $ralph。这套命名看起来有点重，但背后的想法很清楚：不要让 agent 一听到需求就急着改文件，而是先把“要做什么、怎么做、怎么验收、什么时候停”写清楚。

skills 和 agents 提供了什么

OMX 文档把技能分成几类。

Canonical Workflow 里有 $deep-interview、$ralplan、$prometheus-strict、$ultragoal、$code-review 和 $ultraqa。这些面向的是完整工程任务：先澄清，再计划，再执行，再审查，再 QA。

Execution Modes 里有 $team、$ralph、$autopilot、$ultrawork 等。它们决定任务是单线推进、团队并行，还是更强的自动循环。

Agent Catalog 则更像角色库，包括 analyst、planner、architect、debugger、executor、verifier、security-reviewer、performance-reviewer、code-reviewer、test-engineer、designer、researcher 等。你不一定每天都要手动点名这些角色，但它们说明 OMX 的定位不是“万能大 prompt”，而是把工程过程拆成可复用的角色和阶段。

这对长期项目有意义。AI 编程里很多失败不是模型完全不会写代码，而是它太快进入执行，跳过需求确认、架构边界、测试基线和收尾审查。OMX 试图用技能和角色把这些步骤固化下来。

插件形态和运行时状态

README 提到，仓库里也包含官方 Codex plugin layout，路径是 plugins/oh-my-codex，并带有 marketplace metadata。

但文档也强调：这个插件形态不是 npm install -g oh-my-codex 加 omx setup 的替代品。插件作用更像是把 hooks、skill surface 和 Codex 生命周期集成包装起来，真正运行时仍然依赖已安装的 omx CLI。

最新 v0.18.1 release 的重点也集中在这条线上：插件安装会使用 pinned OMX launcher，hook 失败时更保守，Ultragoal 状态变更会序列化，release packaging 会排除 crate-local .omx runtime cache，并同步 npm、Cargo workspace、lockfile 和插件 manifest 的版本号。

这些变化说明 OMX 已经不只是一个 prompt 仓库，它开始认真处理安装形态、hook 安全、状态写入、release 包内容和跨运行时一致性。对工具链来说，这些都属于“不炫但很要命”的工程细节。

适合谁

OMX 比较适合已经在认真使用 Codex CLI 的开发者，尤其是这些场景：

经常让 Codex 处理多文件、多步骤任务。
希望 agent 先澄清需求，而不是直接改代码。
想把计划、执行、检查、review 和 QA 分开管理。
需要在项目里保留 .omx/ 状态、计划和日志。
想尝试 tmux/team runtime 或更强的长任务推进方式。
团队愿意把自己的工程习惯沉淀成 skills 和 prompts。

如果你只是偶尔让 Codex 改一行配置、生成一个脚本、解释一段代码，OMX 可能会显得偏重。它更像是给高频 AI 编程用户准备的工具腰带，而不是新手必须安装的第一层入口。

使用时要注意什么

第一，不要把 OMX 当成“无人值守自动完成一切”的保证。它能强化流程，但不能替你判断需求是否合理、架构是否该改、风险是否可接受。

第二，平台边界要看清楚。README 现在明确推荐 macOS/Linux + Codex CLI。Windows 原生路径存在，但不是默认最佳体验。如果你在 Windows 上使用，WSL2 通常比原生终端更稳。

第三，omx doctor 不是最终验收。真正能证明环境可用的是 codex login status 加 omx exec 这种实际模型调用测试。

第四，流程越强，越需要你写清楚任务边界。$ultragoal、$team、$autopilot 这类能力适合有验收标准的任务。如果需求本身还很含糊，应该先用 $deep-interview 或普通对话把边界拉清楚。

小结

oh-my-codex 的价值不在于让 Codex “变成另一个工具”，而在于给 Codex CLI 加了一层更工程化的工作方式。

它把 AI 编程从“我说一句，你改一轮”往“澄清、计划、执行、检查、记录状态”推进了一步。对轻量任务来说，这可能有点重；但对经常用 Codex 做真实项目的人来说，稳定流程、可复用技能、运行时诊断和 durable goal 反而是省心的关键。

如果你已经把 Codex CLI 当成日常开发工具，OMX 值得试一下。即使不直接安装，它对 skills、agents、计划和验收流程的拆法，也很适合拿来改造自己的 AI 编程工作流。

参考资料

Yeachan-Heo/oh-my-codex：https://github.com/Yeachan-Heo/oh-my-codex
Getting Started：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/getting-started.html
Agent Catalog：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/agents.html
Skills Reference：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/skills.html
v0.18.1 release：https://github.com/Yeachan-Heo/oh-my-codex/releases/tag/v0.18.1

Oh-My-Codex on KnightLi的博客