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 包最大的差別:它不是只往系統提示詞裡塞規則,而是把釐清、規劃、執行、檢查、團隊協作和執行時診斷拆成一組可呼叫的工作面。
推薦安裝方式
README 和 Getting Started 文件都強調:OMX 預設推薦在 macOS 或 Linux 上搭配 Codex CLI 使用。原生 Windows 和 Codex App 不是它目前最主要的體驗路徑,可能會有不一致或不完整支援。
如果你已經裝好了 Codex CLI,可以這樣開始:
|
|
如果你還沒有 Codex CLI,並且希望 npm 管理安裝:
|
|
這裡有一個細節:不要在已經由 Homebrew 管理 codex 的機器上,直接把 @openai/codex 和 oh-my-codex 合併成一個全域安裝命令。README 提到,Homebrew 擁有的 codex 二進位可能會和 npm 安裝發生 EEXIST 衝突。OMX 只需要一個可用、已登入、在 PATH 上的 codex 命令,並不要求 Codex 一定由 npm 安裝。
安裝完成後,建議再跑一次真實執行煙測:
|
|
omx doctor 只能證明本地安裝結構大體正常,不能證明目前 shell/profile 裡的 Codex 帳號、代理、base URL 和認證鏈路真的能發起模型呼叫。這個區分很實際,尤其是你在不同 HOME、容器、遠端環境或本地 OpenAI 相容代理裡切換時。
預設工作流
OMX 的主線工作流大致是:
|
|
其中最常用的是三步:
$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