Claude Code、Codex、Grok Build 怎麼選？用工作流而不是規格表
本篇是「AI Coding CLI 觀察筆記」系列的第 3 / 3 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
「Claude Code、Codex、Grok Build 該選哪一個？」如果用模型名稱、context window 和月費回答，文章很快就會過期；如果只憑一次 demo 或 benchmark 回答，又很難對應你的 repo。
我會先看幾件和日常工作比較有關的事：在哪裡執行、能改哪些檔案、怎麼讀專案規則、能不能接上現有工具，以及做完要怎麼檢查。
這篇接著前兩篇，集中比較 Claude Code、Codex 與 Grok Build。GitHub Copilot CLI、Cursor CLI、Gemini CLI 等工具也可以用同樣的方式評估。
內容依 2026-07-14 官方文件查核。上一篇先解釋了為什麼 IDE、CLI 與 Cloud Agent 不是三代淘汰。
先看不容易過期的對照表
| 能力 | Claude Code | Codex | Grok Build |
|---|---|---|---|
| Local 互動入口 | claude | codex | grok |
| 非互動入口 | claude -p | codex exec | grok -p |
| 主要專案規則 | CLAUDE.md，可匯入 AGENTS.md | AGENTS.md | AGENTS.md，並提供 Claude 設定匯入 |
| Plan workflow | permission mode plan | /plan 或 Shift+Tab | /plan、可檢視與修改 plan |
| 權限控制 | permission modes、rules、sandbox | approval policy、sandbox mode、rules | ask／always-approve；plan 中非 plan file 寫入仍需批准 |
| Skills | 支援 Agent Skills | 支援 Agent Skills | 支援 Skills |
| MCP | 支援 | 支援 | 支援 |
| Hooks／Plugins | 支援 | 支援 | 支援 |
| 平行工作 | subagents、agent teams、background agents、worktrees | subagents、app／cloud worktrees | 平行 subagents、worktree integration |
| 程式化整合 | -p、Agent SDK | exec、SDK、app server、MCP server | -p、ACP |
| 專用 review 入口 | 可用 review Skills／GitHub integration | /review、codex review | Plan 與 diff review workflow |
這張表刻意不列模型版本、context window、token 額度和固定價格。那些資料適合在購買當天查，不適合拿來當長期選擇框架。
Claude Code：完整的 agent loop 與擴充層
Claude Code 目前不只是一個 terminal CLI。它也有 IDE、Desktop、Web、Remote Control、Slack 與 CI/CD 等 surface；核心 agent loop 和專案設定能在多個介面之間延續。
評估 Claude Code 時，可以一起看這幾組功能：
CLAUDE.md與 auto memory；- permission modes、allow/deny rules、sandbox；
- checkpoints 與 session 管理；
- Skills、hooks、MCP、plugins；
- subagents、agent teams 與 background agents；
claude -p和 Agent SDK。
這套組合適合已經把專案規則、hooks 和 Skills 建好，希望同一套設定在 terminal、IDE 或遠端介面延續的人。
要注意的是，功能多，需要釐清的設定也多。Permission mode、tool rule、sandbox 和外部執行環境是不同層，不能因為開了 plan mode 就假設所有 shell 行為都已被硬隔離。細節可查 Claude Code overview 與 permission modes。
Codex：把 approval、sandbox 與自動化介面拆得清楚
Codex 的 local CLI 把兩個問題明確分開：
- approval policy：何時詢問使用者；
- sandbox mode：程序實際能讀寫什麼。
這對需要在 CI、review 或不同風險 repo 間切換的人很實用。例如 reviewer 可以用 read-only sandbox，實作者則只取得 workspace write，而不是用一個「全自動」開關涵蓋所有情境。
Codex 現在也有 Plan mode、subagents、Skills、MCP、Hooks、Plugins 與專用 review flow。評估時應以目前版本為準，不要沿用早期 CLI 的功能印象。
codex exec -s read-only -a never "Review the current diff"
codex review --uncommitted若團隊重視 AGENTS.md、可重現的非互動輸出、獨立 review 入口，或需要明確控制本機執行邊界，Codex 值得放進評估名單。完整入口可參考 Codex CLI commands 與 approvals and security。
Grok Build：相容既有設定，主打 TUI、Plan 與 ACP
Grok Build 仍是 early beta，但 xAI 沒有要求使用者從零建立生態。官方發表文表示它能讀 AGENTS.md、plugins、hooks、Skills 與 MCP servers，TUI 也提供 /import-claude。
目前最值得觀察的幾點：
- 可用
/plan建立並檢視工作計畫； - 平行 subagents 與 worktree integration 被放在核心體驗；
grok -p可用於 script 和 bot；- ACP 可讓其他 client 把 Grok Build 當 agent backend；
~/.grok/config.toml可設定自訂模型與 endpoint；grok inspect能列出實際載入的 instructions、Skills、plugins、hooks 和 MCP。
它的主要不確定性也來自 early beta：穩定性、企業控制、跨平台細節、額度與相容行為都可能快速變動。不要因為「out of the box」就假設 Claude 或 Codex 的設定可以完全無差異執行。參考：Grok Build overview、Modes and Commands。
名稱相同的功能，實際用起來有什麼差別
表格上都有打勾的功能，還是得拿來跑一次，看看操作和限制是否符合需求。
都有 Plan Mode
要比較的是：
- plan 能否在寫檔前被逐項檢查；
- 是否能針對某一步留言或重寫；
- plan mode 限制的是模型行為、tool approval，還是 OS 層權限；
- 從 plan 進入實作後，權限會不會改變。
都有 subagents
要比較的是：
- 誰決定拆任務；
- subagent 能取得哪些 context 和工具；
- 是否使用獨立 worktree；
- 能否中止、重導或檢視中間結果；
- 多個結果如何整合；
- 並行是否增加 token、衝突和 review 成本。
都有 Skills、MCP、Hooks
要比較的是：
- discovery 路徑和優先順序；
- 支援哪些標準欄位與 client 專屬欄位；
- MCP credential 如何保存；
- hook 是否有 trust review；
- project 設定能否被組織政策限制；
- 同一份設定在實際 task 中是否真的被使用。
換工具時，這些細節都可能需要重設或調整，不能只看功能名稱相同就直接搬過去。
先確認任務要在哪裡執行
| 你的限制 | 評估重點 |
|---|---|
| 必須使用本機完整工具鏈 | local CLI 的 sandbox、credentials 與 shell 相容性 |
| 任務要在斷線後繼續 | cloud／background execution 與環境重現 |
| 要放進 CI | headless、結構化輸出、exit code、timeout、secret isolation |
| 需要逐行看 diff | IDE／Desktop review 體驗與 checkpoint |
| 大量獨立任務並行 | worktree、session 管理、合併策略與成本 |
| 已累積 Skills／MCP | discovery 相容性與 runtime 實測 |
| 高風險 production repo | 最小權限、外部隔離、人工批准與 audit trail |
本機、雲端和 CI 的限制不同。我會先確認任務在哪裡跑、需要哪些工具，再比較模型和介面。
評估順序可以照下面走：
flowchart TD
subgraph S1["先定義場景"]
direction LR
A["選執行環境<br/>Local / Cloud / CI"] --> B["設定最小權限<br/>sandbox / secrets / network"]
end
subgraph S2["再驗證相容性"]
direction LR
C["確認專案規則<br/>Skills / MCP / hooks"] --> D["同 repo、同任務<br/>同一套測試"]
end
subgraph S3["最後做選擇"]
direction LR
E["比較 diff、失敗恢復<br/>review 與成本"] --> F["選一個主力<br/>加一個不同角色"]
end
S1 --> S2 --> S3
用同一個 repo 做小型評估
可以挑一個有完整測試的小任務，讓候選工具在相同條件下完成，再比較結果。
任務範例：
Fix one reproducible bug in the authentication module.
Do not change the public API.
Add a regression test that fails before the fix.
Run the focused test and the project type check.
Report changed files, commands run, and remaining uncertainty.記錄這些結果：
- 第一次正確修改前花多少時間；
- 是否遵守 repo instructions 和修改範圍；
- 指令或測試失敗後如何修正；
- 最終 diff 是否容易 review；
- 有沒有把未驗證的內容說成已完成；
- 權限、context 和費用是否能被理解與控制。
同一個 prompt 不保證完全公平，但至少比拿三段不同 demo 下結論更接近你的真實工作。
我的選法：一個主力，加一個不同角色
如果已經有一套成熟工作流，不必為了新功能全部搬家。先保留主力工具，再讓第二個工具負責一個明確角色：
- 唯讀 review；
- 獨立 issue；
- plan critique；
- cloud background task；
- 特定 repo 或特定 runtime。
這樣才能看出切換帶來的是新能力，還是只是多一份設定和帳單。
最後我會看哪個工具讓我少花時間補背景、追進度和檢查修改。遇到失敗時，能不能看懂原因、接手處理，也會影響我願不願意繼續用。
