有件事我一直覺得很妙。
某次我把 Claude Code 寫好、自己看過覺得沒問題的一段程式碼，丟給 Codex 做 review。結果 Codex 一口氣抓出一堆我跟 Claude 都沒注意到的問題——race condition、漏掉的 edge case、一個會在高併發下爆掉的鎖。我心想好吧那反過來呢？把 Codex 寫的程式碼丟給 Claude Code 看。Claude 看了半天，給我一句客客氣氣的「這段寫得很完整，沒有發現明顯問題」。
這個不對稱的現象，在 Hacker News 的討論串 跟一堆 Reddit 貼文裡反覆出現，不是只有我遇到。它其實濃縮了一件事：Codex 跟 Claude Code 不是「誰比較強」的問題，而是它們根本是兩種不同性格的生物。 你拿 benchmark 分數去比，會發現兩邊幾乎打平；但真正決定你每天用起來爽不爽的，是它們的「脾氣」。
這篇就來聊聊我用了大半年下來，對這兩個工具最真實的使用體感——不是比規格表，是比那種「跟它共事久了才會懂」的細節。
它們根本不是同一種生物
先把最容易搞混的東西講清楚。雖然大家都叫它們「終端 AI coding agent」，但這兩個工具從骨子裡的設計哲學就分岔了。
Claude Code 是 Anthropic 的終端原生工具 ，預設跑在你自己的機器上，邊做邊跟你報告每一步、動到危險的東西會先問你。它的整個互動模型是「developer-in-the-loop」——你跟它並肩坐著，隨時可以打斷、可以導正。
Codex 則是 OpenAI 從雲端優先（cloud-first）出發 設計的，預設把任務丟進一個隔離的雲端 sandbox 裡跑。它的模型是「委派」——你描述任務、走開、回來看結果（通常是一個 PR）。它在 macOS app、CLI、IDE 擴充、ChatGPT 網頁、甚至 Slack 裡 @Codex 都能用。
把規格攤開來看會更清楚：
| 維度 | Claude Code | Codex |
|---|---|---|
| 主力模型（2026-05） | Opus 4.7、Sonnet 4.6 | GPT-5.4、GPT-5.5、GPT-5.3-Codex |
| 預設執行環境 | 本地終端（你的機器） | 雲端 sandbox ＋ 本地 CLI |
| 互動風格 | 逐步敘述、要你批准 | 丟出去自己跑、回來看 PR |
| 開源 | 否 | 是（Apache 2.0、Rust binary） |
| 沙箱安全 | 應用層（26 種可程式化 hook） | OS kernel 層（Seatbelt / Landlock / seccomp） |
| 設定檔 | CLAUDE.md（專有） | AGENTS.md（開放標準） |
| Context window | 1M tokens（Max/Team 標準定價） | 272–400K，GPT-5.4 實驗性 1.05M |
這張表你不用背，只要記住一句話：Claude Code 從「本地、敘述、要你批准」長出來，Codex 從「雲端、自主、給你成品」長出來。 後面所有體感差異，都是從這個分岔點延伸出來的。
順帶一提，Codex 的桌面 app 在 2026 年 2 月推出時是 macOS only ，Windows/Linux 用戶當時只能用 CLI——這對一些跨平台團隊來說是個 dealbreaker，要留意。
真正的差異，是它們的「個性」
規格表看完你大概無感，因為兩邊看起來都很能打。但用久了你會發現，最有感的差異 benchmark 永遠測不出來——是它們的講話方式跟做事節奏。
onevcat 那篇用了一個半月的深度心得 把這件事講得超精準，跟我的體感幾乎一模一樣：
Claude 相對啰嗦但細緻。 它喜歡把每個決策的前因後果、自己正在做什麼，都解釋給你聽，偶爾還會附贈一句「You're absolutely right」的情緒價值。這種個性在「理解專案、做簡單測試、邊探索邊調整」的時候超好用——你看得到它在想什麼，走錯方向馬上喊停。但處理困難任務時，它有時會顯得效率不高，而且很容易被你帶偏：你一句「會不會是這裡的問題？」它可能就真的順著你那個錯誤方向一路跑下去。
Codex 則是人狠話不多，直達要害。 它幾乎不解釋為什麼這麼做，往往就自己悶頭苦幹個十來分鐘，然後直接甩給你一個簡潔有效的解法。onevcat 那個比喻我超愛——「就彷彿在跟一個掃地僧對話，一個眼神勝過千言萬語」。但這種含蓄也有代價：碰到架構設計或需要研究的任務，除非你明確要求它解釋，否則那種「沉默是金」會讓你完全摸不透它的思路。
這裡有個很多人會踩的坑：話多不等於比較好。 我以前也以為 Claude 解釋得多就是比較聰明，後來才想通——這只是「適不適合當下這個任務」的問題。需要對齊需求、邊做邊釐清的活，Claude 的啰嗦是優點；目標明確、規格寫死的活，Codex 的沉默高效反而更省心。
還有一個實務上的雷：Codex 很常用 Python 腳本去改檔案，產出的 diff 不是那種一行一行清楚的修改，而是一坨腳本執行結果，review 起來很痛苦 。所以你基本上只能等它跑完、看最後結果，沒辦法像 Claude 那樣盯著過程即時介入。這也是為什麼——
Claude Code 適合 pair programming，Codex 不適合。 Claude 那種快速迭代、approve 每個 edit、走偏就打斷的節奏，就是結對編程的精髓。Codex 太慢了，它的正確用法是「丟出去，十分鐘後回來收貨」。HN 上一個資深開發者的配比我覺得很有代表性：Claude Code 用 80%、Codex 用 20%，但 Codex 當 PR reviewer 是所有工具裡最強的。
Benchmark？早就打平了
如果你還在用 SWE-bench 分數來決定要用哪個，我勸你省點力。2026 上半年這兩邊的數字已經咬得超緊，而且每次有新模型就翻盤一次。
| Benchmark（2026 上半年） | Codex（GPT-5.x） | Claude Code（Opus 4.x） |
|---|---|---|
| SWE-bench Verified | GPT-5.5 88.7%（5 月反超） | Opus 4.7 87.6% |
| Terminal-Bench 2.0 | GPT-5.3-Codex 77.3% | Opus 4.7 69.4% |
| OSWorld-Verified（電腦操作） | 較低 | 72.7%（領先） |
| Token 效率 | 省 2–4× | 吃 token 較凶 |
SWE-bench Verified 上，GPT-5.5 在 5 月以 88.7% 微幅反超了 Opus 4.7 的 87.6% ——差距只有 1.1 分，根本是測量誤差等級。但你換個 benchmark 結論就變：Terminal-Bench 2.0 上 Codex 把 Claude 拉開一截（GPT-5.3-Codex 77.3%、GPT-5.4 75.1% vs Opus 4.7 69.4%，不同評測機構數字略有出入），終端／debug 類任務它是真的強。
所以與其問「誰分數高」，不如問「它們各自擅長哪條軸線」。這個結論反而很穩定：
- Codex 擅長：terminal 操作、debug、抓 race condition 跟 edge case、PR review。Composio 的實測 裡，Codex 持續抓出 Claude 漏掉的邏輯錯誤。
- Claude 擅長：大型 codebase 推理、跨檔重構、前端設計保真。同一份 Figma 設計克隆測試 裡，Claude 保留了排版結構跟原始設計的圖片，Codex 給的版本功能正常但視覺有出入。
一個我覺得最該記住的數字是 token 效率：Codex 完成同樣的任務通常省得多，各家評測落在 2–3 倍 到 約 4 倍 之間，依任務型態而定。這件事看起來不起眼，但它直接連到下一個——也是會真正讓你崩潰的——問題。
會讓你崩潰的，其實是額度
講真的，benchmark、個性那些都還好，rate limit 才是會讓你當場想砸鍵盤的東西。 這也是 Reddit 上最高頻、而且方向超一致的抱怨。
Claude Code 這邊，Opus 吃 token 的速度快到誇張。5 小時額度、每週額度動不動就撞牆，一堆重度用戶被迫只能拿 Claude Code 來「規劃」 ，或是中途降級去用 Sonnet 才不會超限。onevcat 甚至算過，他以 API 計價的方式，一個半月燒掉了價值三千多美金的 token——後來 Anthropic 推出 weekly limit，他自嘲「大概就是針對我這種重度用戶吧」。
Codex 這邊就寬鬆很多。同樣 $20 的 Plus 方案，一個 Reddit 用戶說他「狂刷 GPT-5.4 xhigh 都還碰不到 5 小時限制」 ，auto-compact 也很平順、長 session 不太掉 context。這就是大量人從 Claude Code 跳去 Codex 的頭號原因——不是模型比較強，是同樣的錢能做更多事。前面講的 token 效率 2–4×，到這裡就直接兌現成「更不容易撞額度」。
不過這裡要踩個煞車，講兩個反面訊號，免得你以為 Codex 是萬靈丹：
第一，Codex 也有週期性「變笨」的抱怨 。每隔一陣子就會冒出一波「Codex 失去魔力了」「最近在複雜問題上越來越笨、自主性下降」的貼文，通常是 OpenAI 默默調整模型導致的。這種事 Claude 也會發生，兩邊都不能免疫。
第二，Codex 雖然額度寬鬆，但它很 verbose，話多會吃掉額度優勢。有用戶就吐槽「Codex 很囉嗦，考慮到它的 limit 這點滿煩的」。所以省不省，還是要看你的任務型態。
我的混合工作流（也是業界主流）
繞了一圈，結論其實很無聊但很實在：能同時用就同時用。 這不是和稀泥，是 2026 年絕大多數資深開發者收斂出來的共識。它們的強項剛好互補，硬要二選一反而虧。
我自己是做硬體／韌體的，BLE、儀器、各種工具鏈一大堆，分享一下我的配法：
工作流程： 需求／任務 → 判斷類型 →（規劃／重構／理解 codebase）走 Claude Code 主力；（規格明確／可無人值守）丟 Codex 外包執行 → 兩者寫完、commit 前 → 交給 Codex 當 PR reviewer → 合併。
拆開講：
Claude Code 當主力，負責規劃、跨檔重構、理解既有 codebase、以及那些需要邊做邊對齊的活。對我來說最關鍵的是——它的 MCP 生態超成熟 ，我那一堆串接硬體、BLE 抓包、邏輯分析儀的 MCP server 接上去就能用，這是 Claude Code 的主場。
Codex 當 reviewer 兼執行外包。寫完、commit 之前，固定丟給 Codex 做一輪 PR review（前面說過，它是公認最強的 reviewer）。另外那些規格寫死、可以無人值守的任務——批次腳本、CI、DevOps、純粹的 debug——直接丟給它在雲端 sandbox 跑，我去做別的事。
還有個進階玩法：兩者都能當對方的 MCP server，互相呼叫。不少 power user 就靠這個做自動化的交叉 code review，讓 Claude 寫的東西自動過一遍 Codex 的法眼。
如果你真的預算有限只能挑一個，我的建議是：
- 主要做韌體 debug、terminal 操作、規格清楚的活，而且很在意每月帳單 → 選 Codex。
- 主要做大型重構、需要深度推理跟互動、重度依賴 MCP 工具鏈，或公司幫你出錢 → 選 Claude Code（搭 Max 方案解額度焦慮）。
最後，講點掃興的真話
用了這麼久，我反而對「選哪個工具」這件事越來越無所謂了。
onevcat 那句話 我很認同：「當代 LLM 用戶的忠誠度接近於零，新模型吊打舊模型是業界常態，於是用戶也像候鳥一樣來回遷移。」廠商想用應用層那些 commands、subagent 配置來綁住你，但說真的——換工具的時候，那些精心設計的設定檔，幾分鐘複製貼上就能在新工具上重建。真正留得住人的，從來不是 lock-in，是模型本身的能力跟性價比。
所以與其糾結「Codex 還是 Claude Code」，不如把力氣花在一個更值得練的技能上：把需求講清楚。模糊的需求產生模糊的程式碼，清晰的需求才能逼出高品質的輸出。這個能力不管你用哪個工具、不管明年又冒出什麼新模型，都不會過期。
工具會一直換，候鳥年年遷徙。你的判斷力跟表達力，才是那個不會被 deprecated 的東西。
你現在主力是哪一個？有沒有什麼任務是某一邊特別頂、另一邊怎麼調都不行的？歡迎留言聊聊你的配方，我很想知道別人都怎麼搭。
參考資料
- Codex vs. Claude Code: Which is best? [2026] — Zapier
- Claude Code vs OpenAI Codex: I Built the Same App in Both — Composio
- Codex vs. Claude Code: Key Differences and When to Use Each — DataCamp
- Claude Code vs Codex CLI: 2026 Comparison — Termdock
- Codex vs Claude Code: 2026 Comparison for Developers — Leanware
- Codex vs Claude Code (May 2026): Benchmarks, Subagents & Limits — Morph
- Claude Code vs. Codex: sentiment dashboard 討論串 — Hacker News
- OpenAI Codex Review 2026 — NxCode
- 一個半月 Claude Code 使用心得 — onevcat
- OpenAI Codex vs Claude Code in 2026 Spring 討論 — r/ChatGPTCoding
沒有留言:
張貼留言