企业官网建设流程全解析

OmX（oh-my-codex）上手指南：给 Codex CLI 加一层工作流、代理团队和 HUD

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex

OmX（oh-my-codex，命令为omx）是为 OpenAI Codex CLI 打造的协调层：它保留 Codex 作为执行引擎，在其之上补充标准工作流、可复用的代理角色与技能、.omx/项目状态目录、HUD 监控界面和 tmux 团队运行时。适合已经在使用 Codex、但觉得"从提问到交付"这段流程还要自己手工串起来的人。

读完这篇，你会知道：OmX 在开发流程中的位置、核心能力怎么用、从安装到验证的最小步骤，以及哪些平台与场景下它不适合你。

仓库docs/benchmarks/中提供了一张基准对比图，用于比较不同处理方式下的效果差异；具体数值以仓库内对应文档为准。

它解决什么问题

单独使用 Codex CLI 时，每个任务都要自己决定：需求要澄清到什么程度、计划怎么评审、进度状态存哪里、多个代理如何并行。

OmX 把这件事标准化：它不是替代 Codex，而是加一层"更好的任务路由 + 工作流 + 运行时"。计划、日志、记忆和模式状态统一落在项目的.omx/目录下，会话之间可以接着跑，而不是每次从零开始。如果你只想用裸 Codex 做单轮问答，确实不需要它；但如果你希望从需求澄清一路推进到可验证的交付，这一层能少很多手工编排。

能力地图：工作流在哪些环节被接管

技能方面，仓库的skills/目录内置了 ralph、team、tdd、deep-interview 等几十个可加载工作流，omx setup时会随提示词一起安装；默认建议只加载 2–5 个相关技能，一次塞太多会挤占上下文预算。

新手上手路径：先验证，再配置，再探索

前置条件：Node.js 20+；已安装并通过codex --version验证、且已完成登录认证的 Codex CLI；想跑团队模式还需要 macOS/Linux 上的tmux。

第一步，安装 OMX（推荐用 npm 全局安装）：

npm install -g oh-my-codex omx setup --scope project --merge-agents

第二步，验证安装与真实执行能力。omx doctor只检查安装结构是否完整，真正能发模型请求还要靠下面这条冒烟测试：

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

第三步，从一个 git 项目里用命名 worktree 启动会话，再按标准工作流推进：

omx --worktree=feat/task --madmax --xhigh

启动后在会话里先$deep-interview "..."澄清边界，再$ralplan "..."审批计划，最后用$ultragoal或$ultrawork进入执行。如果只想快速体验，也可以先读 Demo 指南。

适合谁使用：四个更值得试的场景

• ✅长链路任务：重构、跨模块改动这类需要"目标 + 检查点"跨轮次推进的工作。/goal加$ultragoal会把计划固化成.omx/ultragoal账本，中断后能接着跑。
• 需求边界模糊的项目：需求文档不全、口头交接多的场景，$deep-interview专门用于把意图、边界和非目标问清楚，避免代理开工就跑偏。
• 需要并行分工的大任务：$team/omx team给每个 worker 独立的 git worktree 和 tmux 面板，worker 只上报检查点证据、不直接改 leader 的状态文件。注意它属于"工作量大到值得付出协调成本"时才用，很小的任务反而会被提示过度编排。
• 想自动化自己的重复操作：钩子扩展点覆盖session-start、pre-tool-use、turn-complete等事件，用omx hooks init生成样板插件后即可在本地事件流里挂逻辑。

使用边界与注意事项

⚠️ 以下限制在官方 README 中写得很明确，评估前先看一眼：

• 平台：主要面向 macOS/Linux + Codex CLI 的路径调优；原生 Windows 与 Codex App 不是默认体验，可能不稳定且支持较少，Windows 上更推荐 WSL2。
• --madmax是高风险开关：它等价于 Codex 的"绕过审批和沙箱"参数，只应在可信仓库里用；配--worktree隔离改动是官方推荐做法。
• doctor 绿灯不等于能跑：omx doctor通过只代表安装结构没问题；认证、代理地址（openai_base_url）等问题要等真实模型调用才暴露，所以要用omx exec冒烟测试。
• 插件不是 CLI 的替代品：仓库也提供 Codex 插件形态（plugins/oh-my-codex），但插件模式仍需全局omxCLI 和对应的持久AGENTS.md作为编排指导层。
• 其他细节（如 Intel Mac 启动时 Gatekeeper 导致的 CPU 尖峰、tmux 下 Shift+Enter 换行问题）在 执行就绪排查 中有对应说明。

下一步：文档与常用入口

🧭 按需求顺序看这些文档即可覆盖大部分使用路径：

• Getting Started：入门与安装细节
• 代理目录：内置角色清单；技能参考：可加载工作流清单
• hooks 扩展文档：.omx/hooks/*.mjs插件的写法与事件模型
• Codex 原生 hook 映射：.codex/hooks.json与 OMX 钩子的归属关系
• 任务队列、Wiki 功能、集成指南
• 配置与状态入口：Codex 侧配置在~/.codex/config.toml（配置入口，按需调整）；OMX 侧的运行状态与计划都在项目内.omx/目录下，omx --help是随时可用的命令索引。

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex