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/codexoh-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 則更像角色庫,包括 analystplannerarchitectdebuggerexecutorverifiersecurity-reviewerperformance-reviewercode-reviewertest-engineerdesignerresearcher 等。你不一定每天都要手動點名這些角色,但它們說明 OMX 的定位不是「萬能大 prompt」,而是把工程過程拆成可複用的角色和階段。

這對長期專案有意義。AI 編程裡很多失敗不是模型完全不會寫程式碼,而是它太快進入執行,跳過需求確認、架構邊界、測試基線和收尾審查。OMX 試圖用技能和角色把這些步驟固化下來。

插件形態和執行時狀態

README 提到,倉庫裡也包含官方 Codex plugin layout,路徑是 plugins/oh-my-codex,並帶有 marketplace metadata。

但文件也強調:這個插件形態不是 npm install -g oh-my-codexomx 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 statusomx exec 這種實際模型呼叫測試。

第四,流程越強,越需要你寫清楚任務邊界。$ultragoal$team$autopilot 這類能力適合有驗收標準的任務。如果需求本身還很含糊,應該先用 $deep-interview 或普通對話把邊界拉清楚。

小結

oh-my-codex 的價值不在於讓 Codex「變成另一個工具」,而在於給 Codex CLI 加了一層更工程化的工作方式。

它把 AI 編程從「我說一句,你改一輪」往「釐清、規劃、執行、檢查、記錄狀態」推進了一步。對輕量任務來說,這可能有點重;但對經常用 Codex 做真實專案的人來說,穩定流程、可複用技能、執行時診斷和 durable goal 反而是省心的關鍵。

如果你已經把 Codex CLI 當成日常開發工具,OMX 值得試一下。即使不直接安裝,它對 skills、agents、計劃和驗收流程的拆法,也很適合拿來改造自己的 AI 編程工作流。

參考資料

记录并分享
使用 Hugo 建立
主題 StackJimmy 設計