AI工具

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

整理 Yeachan-Heo/oh-my-codex 的定位、安装方式、核心工作流、skills/agents 体系、插件形态、平台边界和使用建议。它不是 Codex 的替代品，而是给 Codex CLI 增加流程、状态和运行时检查的一层工具。

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 作为实际执行引擎，自己主要补三类东西：

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

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

推荐安装方式

README 和 Getting Started 文档都强调：OMX 默认推荐在 macOS 或 Linux 上配合 Codex CLI 使用。原生 Windows 和 Codex App 不是它当前最主要的体验路径，可能会有不一致或不完整支持。

如果你已经装好了 Codex CLI，可以这样开始：

1
2
3
4

codex --version
npm install -g oh-my-codex
omx setup
omx doctor

如果你还没有 Codex CLI，并且希望 npm 管理安装：

1
2
3
4

npm install -g @openai/codex
npm install -g oh-my-codex
omx setup
omx doctor

这里有一个细节：不要在已经由 Homebrew 管理 codex 的机器上直接把 @openai/codex 和 oh-my-codex 合并成一个全局安装命令。README 提到，Homebrew 拥有的 codex 二进制可能会和 npm 安装发生 EEXIST 冲突。OMX 只需要一个可用、已登录、在 PATH 上的 codex 命令，并不要求 Codex 一定由 npm 安装。

安装完成后，建议再跑一次真实执行烟测：

1
2

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

omx doctor 只能证明本地安装结构大体正常，不能证明当前 shell/profile 里的 Codex 账号、代理、base URL 和认证链路真的能发起模型调用。这个区分很实际，尤其是你在不同 HOME、容器、远程环境或本地 OpenAI 兼容代理里切换时。

默认工作流

OMX 的主线工作流大致是：

1
2
3
4

$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 编程工作流。

参考资料

© 2022 - 2026 KnightLi的博客
记录并分享
使用 Hugo 构建
主题 Stack 由 Jimmy 设计