oh-my-codex：給 Codex CLI 加上工作流、技能和執行時護欄

Mon, 25 May 2026 07:41:45 +0800

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 包最大的差別：它不是只往系統提示詞裡塞規則，而是把釐清、規劃、執行、檢查、團隊協作和執行時診斷拆成一組可呼叫的工作面。

預設工作流

OMX 的主線工作流大致是：

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

參考資料

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

Oh-My-Codex on KnightLi的博客