最近這段時間，整個開發者圈都被 OpenAI 的 Codex CLI 洗版了。
它讓 AI 編程助手真正走進了命令列，讓我們可以在終端機裡直接和 AI 對話寫程式碼、修 Bug、做重構。只要敲幾行指令，複雜的編程任務就能交給它搞定。
可真正用起來，問題就來了。每次對話都是從零開始，它不記得上次討論到哪兒了。
專案越大，它越容易迷路。不知道哪些程式碼改過、哪些坑踩過、哪些方案討論過。更要命的是，面對複雜任務，它只能一個人埋頭苦幹，沒辦法分工協作。
就像給你派了個很能幹的助手，但這助手沒有記性、不會主動規劃、也不懂團隊配合。
直到前幾天，我在 GitHub 上刷到了一個叫 oh-my-codex（簡稱 OMX）的開源專案，喊出了「讓你的 Codex 不再孤單」的口號。
GitHub 專案網址：
https://github.com/Yeachan-Heo/oh-my-codex
短短兩個月時間，這個專案就狂飆到了 16000+ Star，火得一塌糊塗。
它沒有替代 Codex，而是給 Codex 加了一層工作流引擎。讓原本單打獨鬥的 AI 助手，變成了一個懂規劃、有記憶、會協作的開發團隊。
┌─────────────────────────────────────────────────┐
│ Codex CLI (執行引擎) │
│ ↑ │
│ OMX 工作流層 │
│ ├── 深度訪談 ($deep-interview) │
│ ├── 規劃審批 ($ralplan) │
│ ├── 持續執行 ($ralph) │
│ └── 團隊協作 ($team) │
│ │
│ .omx/ 持久化儲存 │
│ ├── 計劃文檔 │
│ ├── 訪談記錄 │
│ ├── 執行日誌 │
│ └── 專案記憶 │
└─────────────────────────────────────────────────┘最讓我眼前一亮的，是它內建的四大核心技能。
1、首先是 $deep-interview 深度訪談系統。
以前用 Codex 最頭疼的就是需求不清楚的時候。我們給個模糊的需求，它就開始瞎猜著幹活，結果做出來的東西八成不是我們想要的。
而 OMX 的深度訪談會像個經驗豐富的產品經理一樣，主動追問需求細節。
比如你說「我要加個使用者認證功能」，它不會直接開始寫程式碼，而是先問：用 JWT 還是 Session？需要支援第三方登入嗎？安全等級要求多高？邊界情況怎麼處理？
透過一輪輪的訪談，把模糊的想法變成清晰的方案，確保大家理解一致了再動手。
# 深度訪談示例
$ omx
> $deep-interview "給系統添加使用者認證功能"
🤔 開始深度訪談...
Q1: 認證方式選擇
- 使用 JWT 還是傳統 Session？
- 是否需要刷新令牌機制？
Q2: 第三方登入
- 需要支援哪些第三方登入？(Google/GitHub/微信)
- OAuth 2.0 流程如何處理？
Q3: 安全等級
- 密碼強度要求？
- 是否需要雙因素認證？
- Session 過期時間？
✅ 訪談完成，已生成需求文檔 → .omx/interviews/auth-2026-04-05.md2、接下來是 ralplan 規劃審批流程。
這個功能解決了另一個痛點：沒有規劃就動手，改到一半發現方向錯了。
OMX 會把訪談得出的需求，轉化成一份詳細的實施計劃。列出要改哪些檔案、有哪些技術權衡、可能踩哪些坑、預計的工作量。
更關鍵的是，它會把這份計劃交給你審批。你可以提出質疑、討論替代方案、調整優先順序。
只有方案真正得到認可了，它才會進入執行階段。不再是埋頭亂幹，而是邊走邊對齊。
> $ralplan "審批使用者認證實施計劃"
📋 實施計劃生成中...
=== 使用者認證模組實施計劃 ===
【架構決策】
✓ 採用 JWT + Redis 方案
✓ 前後端分離架構
✓ 支援 Google/GitHub OAuth
【檔案變更清單】
- backend/auth/jwt.ts (新建，JWT 生成與驗證)
- backend/routes/auth.ts (新建，認證路由)
- backend/middleware/auth.ts (新建，認證中介軟體)
- frontend/pages/login.tsx (修改，登入頁面)
- database/migrations/001_users.sql (新建，使用者表)
【技術權衡】
⚖️ JWT vs Session
選擇 JWT：支援分散式、無狀態、行動端友好
代價：無法主動失效，需配合黑名單
【風險點】
⚠️ XSS 攻擊 → 使用 HttpOnly Cookie
⚠️ CSRF 攻擊 → 實施 CSRF Token
⚠️ 暴力破解 → 添加登入限流
【預計工作量】3-4 天
是否批准此計劃？(y/n/修改建議)3、然後是 $ralph 持續執行迴圈。
這個名字挺有意思，ralph 就是 relentless alpha，意思是「永不放棄的執行者」。
當計劃審批通過後，ralph 就會接手具體實施。它不是執行完就擼挑子，而是會持續驗證、發現問題、修復問題，形成一個完整的閉環。
比如改完程式碼會自動跑測試，測試掛了會分析原因再修復，修復完再驗證，直到所有檢查點都通過為止。
就像給你派了個既能幹活、又有責任心的員工，交代的事兒一定給你辦妥了才算完。
> $ralph "執行使用者認證實施計劃"
🔄 Ralph 持續執行迴圈啟動...
[Step 1/5] 建立資料庫遷移檔案
✅ 建立 001_users.sql
✅ 執行遷移
✅ 驗證表結構
[Step 2/5] 實現 JWT 工具類
✅ 編寫 jwt.ts
🧪 執行單元測試...
❌ 測試失敗：token 過期時間未設定
🔧 修復：添加預設過期時間 24h
🧪 重新測試... ✅ 通過
[Step 3/5] 建立認證路由
✅ 實現 /login 介面
✅ 實現 /register 介面
✅ 添加參數驗證
🧪 整合測試... ✅ 通過
[Step 4/5] 實現認證中介軟體
✅ Token 驗證邏輯
✅ 權限檢查
🧪 中介軟體測試... ✅ 通過
[Step 5/5] 前端登入頁面
✅ UI 元件實現
✅ API 對接
🧪 E2E 測試... ✅ 通過
✨ 所有任務完成！共修復 3 個問題，執行 28 個測試，全部通過。4、而最硬核的升級，是 $team 團隊協作模式。
傳統的 Codex 就像個單執行緒程式，一次只能幹一件事。而 OMX 的 team 模式可以啟動多個 Agent 並行工作。
假設你要重構一個大模組，涉及前端改造、後端介面調整、資料庫遷移、測試補充。
用 team 模式，你可以一口氣啟動 3 個 executor 角色，分別負責前端、後端、資料庫三條線。它們在各自的 tmux 會話裡獨立工作，互不干擾。
而且這些 Agent 之間還能相互協調。比如後端介面改完了，會通知前端可以開始聯調了。某個模組出現 breaking change，會自動同步給受影響的其他成員。
> $team 3:executor "重構電商模組"
🚀 啟動 3 個 Agent 團隊...
┌──────────────────────────────────────────────────────────┐
│ Team: refactor-ecommerce-2026-04-05 │
├──────────────────────────────────────────────────────────┤
│ Agent-1 [Frontend] tmux session: omx-team-1 │
│ ├─ 正在處理：商品列表元件重構 │
│ ├─ 進度：████████░░ 80% │
│ └─ 狀態：等待後端 API 就緒... │
├──────────────────────────────────────────────────────────┤
│ Agent-2 [Backend] tmux session: omx-team-2 │
│ ├─ 正在處理：訂單服務 API 改造 │
│ ├─ 進度：██████████ 100% ✅ │
│ └─ 訊息：已通知 Agent-1 API 已就緒 │
├──────────────────────────────────────────────────────────┤
│ Agent-3 [Database] tmux session: omx-team-3 │
│ ├─ 正在處理：資料庫表結構優化 │
│ ├─ 進度：██████░░░░ 60% │
│ └─ 狀態：正在執行遷移腳本... │
└──────────────────────────────────────────────────────────┘
💬 團隊協作日誌:
[14:32] Agent-2 → Agent-1: "訂單 API v2 已完成，新增欄位請查看文檔"
[14:35] Agent-1 → Agent-2: "收到，開始對接新介面"
[14:38] Agent-3 → All: "⚠️ 商品表添加庫存欄位，可能影響現有查詢"整個專案的狀態、進度、日誌，全都記錄在 .omx/ 目錄下。
這個目錄就像團隊的共享大腦。所有的規劃文檔、訪談記錄、執行日誌、專案記憶，全都結構化地存在這裡。
下次再打開專案，OMX 會自動載入這些上下文。它知道之前討論過什麼、決定了什麼、還有什麼坑需要注意。
不再是每次對話都從零開始，而是真正有了專案級別的連續記憶。
📁 .omx/ # OMX 工作目錄
├── 📋 plans/ # 實施計劃
│ ├── auth-plan-2026-04-05.md
│ └── refactor-plan-2026-04-03.md
│
├── 💬 interviews/ # 訪談記錄
│ ├── auth-interview.md
│ └── feature-clarification.md
│
├── 📝 logs/ # 執行日誌
│ ├── ralph-auth-2026-04-05.log
│ └── team-refactor.log
│
├── 🧠 memory/ # 專案記憶
│ ├── decisions.md # 重要決策
│ ├── pitfalls.md # 已知坑點
│ └── conventions.md # 程式碼規範
│
├── 👥 teams/ # 團隊協作
│ └── refactor-ecommerce/
│ ├── status.json # 團隊狀態
│ ├── messages.json # 協作訊息
│ └── worktrees/ # Git 工作樹
│
└── ⚙️ state/ # 執行時狀態
└── current-mode.json另外 OMX 還內建了一套角色專家系統。
當你用 omx --madmax --high 啟動時，它會自動載入一系列專業角色：架構師、執行者、審查員、測試工程師等等。
需要做架構設計時，調用架構師角色。需要快速執行時，切換到執行者。需要程式碼審查時，叫上審查員。
每個角色都有自己的專業 prompt 和工作流程，比一個通用助手要專業得多。
# OMX 內建 30+ 專業角色
🏗️ 架構與設計
├─ $architect # 系統架構師 - 設計技術方案
├─ $tech-lead # 技術負責人 - 技術決策
└─ $database-designer # 資料庫設計師 - 資料建模
⚡ 執行與實現
├─ $executor # 快速執行者 - 編碼實現
├─ $refactor-specialist # 重構專家 - 程式碼優化
└─ $debugger # 除錯專家 - 問題定位
🔒 質量與安全
├─ $code-reviewer # 程式碼審查員 - 質量把關
├─ $security-reviewer # 安全審查員 - 安全掃描
├─ $test-engineer # 測試工程師 - 測試覆蓋
└─ $performance-analyst # 性能分析師 - 性能優化
📚 文檔與溝通
├─ $tech-writer # 技術寫作 - 文檔編寫
├─ $api-designer # API 設計師 - 介面設計
└─ $oncall # 值班工程師 - 故障回應
# 使用示例
$ omx --madmax --high
> $architect "設計使用者認證架構"
> $security-reviewer "審查登入介面安全性"
> $executor "實現 JWT 認證邏輯"更貼心的是，OMX 還提供了一套監控介面 omx hud --watch。
可以實時看到每個 Agent 在幹什麼、執行到哪一步了、有沒有遇到問題。就像給開發團隊裝了個任務看板，一目了然。
$ omx hud --watch
╔════════════════════════════════════════════════════════════════╗
║ OMX 實時監控面板 ║
╠════════════════════════════════════════════════════════════════╣
║ 🎯 當前任務：電商模組重構 ║
║ 📊 總體進度：████████░░ 78% ║
║ ⏱️ 執行時間：2h 15m ║
╠════════════════════════════════════════════════════════════════╣
║ Agent 狀態 ║
║ ┌──────────────────────────────────────────────────────────┐ ║
║ │ 🟢 Agent-1 [architect] 正在審查架構設計 │ ║
║ │ └─ 檔案：src/services/order.ts │ ║
║ │ └─ 操作：分析依賴關係 │ ║
║ ├──────────────────────────────────────────────────────────┤ ║
║ │ 🟢 Agent-2 [executor] 正在重構程式碼 │ ║
║ │ └─ 檔案：src/api/products.ts │ ║
║ │ └─ 進度：15/20 函式已優化 │ ║
║ ├──────────────────────────────────────────────────────────┤ ║
║ │ 🟡 Agent-3 [test-engineer] 等待程式碼完成 │ ║
║ │ └─ 準備執行整合測試 │ ║
║ └──────────────────────────────────────────────────────────┘ ║
╠════════════════════════════════════════════════════════════════╣
║ 📈 統計資料 ║
║ ├─ 檔案修改：23 個 ║
║ ├─ 程式碼行數：+487 / -312 ║
║ ├─ 測試通過：156 / 160 ║
║ └─ API 呼叫：1,247 次 ║
╠════════════════════════════════════════════════════════════════╣
║ 📝 最近日誌 ║
║ [15:42:18] Agent-2: 完成 ProductService 重構 ║
║ [15:41:55] Agent-1: 發現循環依賴，建議重新設計 ║
║ [15:40:32] Agent-3: 單元測試覆蓋率達到 85% ║
╚════════════════════════════════════════════════════════════════╝
按 'q' 退出 | 'r' 刷新 | 't' 切換團隊視圖很多開發者一開始不敢用 AI 輔助編程，不是覺得 AI 不夠強，而是怕失控。
怕它改錯程式碼、怕它理解錯需求、出了問題不知道追溯哪裡。
OMX 在這方面給了很好的保障。所有的訪談記錄、規劃文檔、執行日誌，全都持久化儲存，可隨時回溯。
如果某個決策出了問題，可以清楚地看到當時為什麼這麼選、誰批准的、執行過程中發生了什麼。
再加上 team 模式的 worktree 隔離機制，每個 Agent 都在獨立的 git worktree 裡工作，互不汙染。就算出了問題，也能快速回滾。
🔒 安全保障機制
1️⃣ Git Worktree 隔離
main/ ← 主分支（保護）
├── .git/worktrees/
│ ├── agent-1/ ← Agent-1 獨立工作區
│ ├── agent-2/ ← Agent-2 獨立工作區
│ └── agent-3/ ← Agent-3 獨立工作區
✅ 互不干擾 ✅ 獨立提交 ✅ 快速回滾
2️⃣ 完整審計日誌
.omx/logs/audit.log
├── [2026-04-05 15:30] Agent-2 修改 auth.ts
├── [2026-04-05 15:32] 執行 npm test (退出碼：0)
├── [2026-04-05 15:35] 提交 "feat: add JWT auth"
└── [2026-04-05 15:37] 合併到 main 分支
3️⃣ 決策可追溯
每個重要決策都記錄：
- 💡 決策內容：為什麼選擇 JWT？
- 👤 批准人：使用者在 $ralplan 中確認
- ⏰ 時間戳：2026-04-05 14:25:33
- 📄 影響範圍：auth.ts, middleware/auth.ts
4️⃣ 故障快速恢復
$ omx team rollback <team-name> --to-commit abc123
✅ 所有 Agent 工作樹已回滾到安全狀態一鍵啟動，開箱即用
部署使用非常簡單，全域安裝後一行命令就能跑起來：
npm install -g @openai/codex oh-my-codex
omx setup
omx --madmax --high然後在 Codex 會話裡，用標準工作流推進任務：
$deep-interview "澄清需求和邊界"
$ralplan "審批實施計劃和權衡"
$ralph "持續執行直到完成"
$team 3:executor "並行執行複雜任務"專案還給出了詳細的配置要求：Node.js 20+ 版本，macOS/Linux 需要 tmux，Windows 需要 psmux。這些都是常規環境，絕大部分開發者都能直接上手。
📋 配置要求清單
必需環境：
✅ Node.js >= 20
✅ Codex CLI (npm install -g @openai/codex)
✅ OpenAI API Key
團隊模式額外要求：
🍎 macOS → brew install tmux
🐧 Linux → sudo apt install tmux
🪟 Windows → winget install psmux
🐧 WSL2 → sudo apt install tmux
推薦配置：
- 記憶體：4GB+
- 磁碟：2GB 可用空間
- 網路：穩定的 API 連接
一鍵驗證：
$ omx doctor
[OK] Codex CLI: installed ✅
[OK] Node.js: v20+ ✅
[OK] Prompts: 30 installed ✅
[OK] Skills: 40 installed ✅
[OK] MCP Servers: configured ✅
Results: 9 passed, 0 warnings, 0 failed寫在最後
放眼現在的 AI 編程助手領域，能把工作流、記憶、協作做到開箱即用的專案真的不多。
OMX 的思路很清晰：不跟 Codex 搶飯碗，而是給它加一層更聰明的工作模式。
如果你本來就在用 Codex 折騰各種自動化開發，又或者想要一個真正懂協作、有記憶的 AI 開發團隊。
那 OMX 絕對值得一試。
從單兵作戰到團隊協同，這只是第一步。
當每個開發者都能低成本組建一支懂規劃、會協作、有記憶的 AI 團隊，那些過去需要幾個人配合一週才能搞定的需求，也許現在一個人一天就能交付了。
未來的競爭力，不在於你能寫多少行程式碼，而在於你能調動多少智慧協作的力量。
GitHub 專案網址：
https://github.com/Yeachan-Heo/oh-my-codex
今天的分享到此結束，感謝大家抽空閱讀，我們下期再見！