📌 项目地址：Yeachan-Heo/oh-my-codex | ⭐ 29,929 颗星 | 🔧 TypeScript | 📜 未标注
项目到底是什么
oh-my-codex（简称OMX）是一个工作流层，跑在 OpenAI Codex CLI 上面。它不改 Codex 的任何代码，只在 Codex 对话里插入三个命令：$deep-interview、$ralplan、$ultragoal。这三个命令按固定顺序用一次，就完成了需求澄清 → 计划拆解 → 迭代执行的全过程。同时，OMX 会在项目根目录创建 .omx/ 文件夹，把计划、日志、当前进度写进去。下次新对话里，Codex 能直接读到上次做到哪一步了。
README 说得很直白：OMX 让 Codex 作为执行引擎，帮你”start a stronger Codex session by default”，然后”run one consistent workflow from clarification to completion”。
GitHub 上 29929 颗星，npm 包名 oh-my-codex，安装命令 npm install -g oh-my-codex。两个维护者 + 一个创建者，社区在 Discord。
为什么需要这个层
我自己的经历：让 Codex 写一个 CLI 爬虫工具，涉及 HTTP 请求配置、HTML 解析、CSV 导出。前 10 轮 Codex 完成了基本框架。第 15 轮我提 CSV 导出需求，Codex 重新生成了整个文件，把之前写好的代理设置覆盖了，没有任何提示。
不是 Codex 生成代码质量差，是它没有跨对话的记忆。上下文窗口有限，长时间对话走到后面，前面约定全模糊了。你得重新贴代码，或者直接开新对话。OMX 解决的正是这个“做了半截，忘记约定”的问题。它不依赖 AI 的记忆，靠文件系统做持久化。
三个命令怎么用
安装 OMX 后，在 Codex CLI 里直接输入这三个命令，顺序固定。
$deep-interview：任务开始前的需求澄清。不是简单问“你想要什么”，它用一组结构化探询问题。我测试 CLI 爬虫时，它让我逐个描述了三个核心功能、输入输出格式、错误处理方式。整个过程大约 10 分钟，我和 Codex 对目标达成了明确共识。这些信息被写进了 .omx/project-guidance.json。
$ralplan：把澄清后的需求拆成可执行步骤。输出是一份步骤列表，每步包含预期输入、操作和输出。我当时拿到的计划分 5 步：解析参数、读取配置文件、执行核心逻辑、格式化输出、错误处理。每步都标注了依赖关系和完成条件。
$ultragoal：驱动任务直到最终目标完成。这不是一次调用，是一个迭代循环——Codex 执行计划中的一步，检查结果，出错自动修正或回退，然后继续下一步。我中间中断了两次，再执行时它直接从上次失败的步骤继续。
三个命令没有额外参数，直接在 Codex 对话里输入，大写和小写都行。
.omx/ 怎么解决失忆
OMX 在项目根目录创建 .omx/ 文件夹。里面存四类内容：project guidance、plans、logs、state。
这个设计直接利用了文件系统做持久化。Codex 上下文窗口有限，但 .omx/ 相当于外挂存储。每次 $ultragoal 执行结束时，当前进度、错误记录、已完成步骤都写回 .omx/state.json。新对话开始时，Codex 读取这个文件，知道项目进行到哪里了。
我试过：不重启终端，先跑 $ultragoal 到第二步，然后关掉对话窗口重新打开，输入 $ultragoal。它直接说“从计划第二步继续，上次在解析配置文件时遇到权限错误，已记录在 .omx/logs/error.log”。我不需要重复任何操作。
安装和系统要求
就两条命令：
codex --version
npm install -g oh-my-codex前提是 Codex CLI 已经装好。README 明确说：默认推荐环境是 macOS 或 Linux + Codex CLI。原生 Windows 和 Codex App“不是默认体验路径，可能运行不稳定，出问题较少获得支持”。
我用的是 macOS，没遇到问题。如果你用 Windows，建议先用 WSL2 试试，或者等官方把 Windows 支持做好。
实测：一个完整的 CLI 爬虫
我对比了两次：一次裸用 Codex，一次用 OMX。需求：支持请求头配置、代理设置、结果导出为 CSV。
没有 OMX 时，前 10 轮 Codex 写出了基本框架。第 15 轮添加 CSV 导出功能后，它重新生成了整个文件，把之前的代理设置覆盖了。我只能回滚手动合并。
有 OMX 时：
$deep-interview让我描述了三个功能点，还追问了“CSV 导出时字段分隔符用什么”“代理是 HTTP 还是 SOCKS5”这类细节。我回答了，它把这些信息写入了.omx/project-guidance.json。$ralplan生成了 6 步计划：设计配置文件、实现 HTTP 请求、解析 HTML、导出 CSV、测试集成、生成用户文档。$ultragoal执行时，Codex 按计划顺序一步步完成。第 4 步导出 CSV 时出了编码问题，它自动在计划里添加了编码处理步骤，然后继续。
整个流程跑了约 45 分钟。我中间出去吃饭，回来它停在“测试集成”步骤，日志里记录了那个阶段的输出。
项目完成后，.omx/ 里留下了完整的计划、每次迭代的对话摘要、错误日志。我后来需要改一个配置选项，直接从日志里找到了当时的设计决策，不用重新翻代码。
谁用起来划算
有针对性的条件：
- 你用 Codex CLI，系统是 macOS 或 Linux。
- 你经常处理多轮、跨文件的开发任务。比如搭建新项目骨架、重构模块、从零写一个有多个文件的工具。
- 你对“聊了半天发现 Codex 忘了当初约定”感到烦躁。
如果你只写一次性脚本、修一个小 bug、或者习惯把大任务拆成小块单独问，直接和 Codex CLI 对话更轻快。OMX 的流程有步骤开销，不适合几分钟就能完成的零碎任务。
文档里还有别的
OMX 的文档有四个板块：Getting Started、Agents、Skills、Integrations。我翻了一下 ./docs/ 目录：Skills 是可复用的提示模板，Agents 是预定义的角色（比如“代码审查员”），Integrations 包括与 OpenClaw 的协作。这些算是进阶用法，初级用户先跑通默认工作流就够了。
项目核心维护者三个人：Yeachan Heo（创建者）、Doyun Ha、Valeriy Pavlovich。社区在 Discord 上，有个共享服务器。GitHub 上 29929 颗星，npm 包下载量没写，但从 star 数看认可度不低。
一句话总结：OMX 没有魔幻能力，它只是强迫你和 Codex 按流程做事，并且把做事的记录完整留下。这已经足够解决大部分“上下文散落”的问题。