前言
在標榜全自動開發的 AI 時代，開發者最常面臨的痛點並非模型能力不足，而是 AI 往往在需求模糊時「急於動手」。缺乏邊界與規劃的程式碼產出，最終常演變成人類工程師需要花費大量時間去逆向工程（Reverse Engineering）AI 的錯誤邏輯。OMX（oh-my-codex） 的出現正是為解決此痛點，透過強制引入傳統軟體工程紀律，徹底改變 AI 代理（Agent）的工作流程。
OMX 說明
OMX 是一個掛載於 Codex CLI 外圍的工作流編排層（Orchestration Layer），負責擔任 AI 執行引擎的大腦與護欄，攔截並規範未經完善規劃的程式碼生成。
「把軟體開發的工程紀律，寫成 AI 必須遵守的硬性規範。」
失效安全預設關閉（Fail-Closed）
OMX 的核心理念建立在**失效安全預設關閉（Fail-Closed）**的系統設計思維上。當規格不清楚或條件不滿足時，系統會主動阻斷執行，而非盲目猜測。所有程式碼的產出，都必須源自於被核准的「單一真相（Single Source of Truth）」。
此外，OMX 會在專案底下生成 .omx/ 目錄作為系統的記憶體。這不是單純的暫存檔，而是完整保留計畫（Plans）、執行日誌（Logs）、上下文（Memory）與當前狀態（State），確保決策脈絡與執行狀態具備可追溯性與可重現性。
優點
- 避免盲目暴衝：強制釐清邊界條件與系統限制，拒絕無效的產出。
- 規劃與執行分離：先產出藍圖供人類審查（Review）後再動手，降低 Git 污染風險。
- 狀態與記憶留存：確保專案脈絡完整，不受開發中斷或交接影響。
- 多工平行協作：針對龐大任務可拆解模組，並分發給不同專業角色的 Agent 處理。
基本使用流程
OMX 將整個開發流程拆解為四個強制的指令節點，確保每一行程式碼的品質都經過嚴謹把關：
- 釐清需求：不會急著產出程式碼，而是逼迫人類釐清邊界與限制。
- 產出計畫：將規劃與執行徹底分離，讓人類在此階段進行審查。
- 精準執行：一旦藍圖確立，便嚴格遵守規格推動任務至完成。
- 團隊模式：當任務過於龐大，自動切換為多角色平行處理模式。
# 1. 釐清需求與收斂邊界（沒談攏規格前阻斷執行）
$deep-interview
# 2. 產出具體的實作藍圖（Plan），等待人類審查
$ralplan
# 3. 依照核准的藍圖精準執行，不隨意發散
$ralph
# 4. 啟用多工平行的團隊 Runtime，處理複雜模組
$team