用了一週 Codex，我才搞清楚它跟 Claude 的差距在哪

> Patch Note

老實說這篇文章的動機很單純 — 用了一週 Codex 之後，我想把這個「換工具」的過程記下來，因為我覺得市面上大部分的比較文都在講功能，但沒有人告訴你「什麼情況下你應該打開哪個工具」。

這週的設定是 Codex TUI on MacOS，跑 gpt-5.6-sol xhigh，對照組是 Claude Code TUI，跑 opus-5 xhigh。都是目前各自陣營的頂配，baseline 算是對齊的。

結論先講：Codex 是一個更「乖」的工具，Claude 是一個更「懂你」的工具。這聽起來很簡單，但背後的意義對工程師的工作流程影響很大。

---

環境與前置

工具選型的部分說一下背景，我這段時間在處理 Ruby on Rails 的專案，所以大部分的 coding 任務都是在這個 stack 上面跑的。

選 Codex TUI 的原因很直接 — OpenAI 最近把 Codex agent 的體驗推進很多，TUI 這個介面讓你可以在 terminal 裡面直接跑，不用切換視窗，對工程師來說 context switching 少一點就是好一點。

Claude Code 我已經用了一段時間，有一些 skills（等於是 Claude 的 custom prompt/workflow）積累下來，這個差異在這週的測試裡造成了一些影響，後面會講。

環境細節：

• MacOS
• Codex TUI，model：gpt-5.6-sol xhigh
• Claude Code TUI，model：opus-5 xhigh
• 主要任務類型：feature implementation、debugging、PR review、Jira ticket 處理

這次沒有特別量化每個任務的時間，因為一開始就不是做嚴謹的 benchmark，純粹是「換工具看看有什麼感覺」的實驗。所以以下的觀察都是質性的，不要拿來做選購依據，但我覺得這些觀察比任何跑分都更實用。

---

實作步驟（也就是實際體驗的分解）

第一關：skills 的非對稱問題

一開始就踩了一個坑。我這段時間有把一些 Claude 的 session 做成 skills，但不是每個都有 port 到 Codex。所以一開始 Codex 的「起點」就比 Claude 低。

解法其實很簡單：把 Codex 指向 Claude 的 skills folder，然後請它把這些 skills 轉換成 Codex 的格式。這個過程本身就是一個有意思的 meta 操作 — 讓 AI 幫你把另一個 AI 的工作流搬過來。

這個坑要提出來是因為：如果你是從 Claude 轉過來的，要記得這個步驟，否則你會覺得 Codex「怎麼這麼不智慧」，但問題其實是你沒有給它足夠的 context。

第二關：debugging 的時候我還是開了 Claude

這個觀察讓我有點意外，但回想起來很合理。

有一次遇到一個感覺比較緊急的 bug，我下意識地開了 Claude，不是因為它一定比較好，而是「熟悉感」。

這讓我想到一個遊戲裡常見的情境：新 patch 出來、meta 換了，理論上有更強的 build，但在 ranked 上你還是會想抓舊的 main，因為你知道它的邊界在哪。工具也是一樣 — familiarity 在高壓情況下有很實際的價值。

結論：如果你現在主力是 Claude，不需要在趕 deadline 的那週換工具。

第三關：Codex 的 output 風格差異

這週最讓我有感的地方有兩個：

Code comment 的密度。 Codex 在 Ruby/Rails code 裡面加的 comment 明顯比 Claude 少，我個人很喜歡這個風格。Claude 有時候會幫你把每一行都解釋一遍，看起來很貼心但其實有點吵。Codex 的 code 讀起來更乾淨。

對話風格的差異。 Claude 的 output 比較像是你的 pair programming 夥伴在跟你說話，有一種人味；Codex 的 output 更像是...怎麼說，有人把原著描述成《星際迷航》裡面的 Data 角色（一個高度理性、幾乎不帶情緒的 Android）。這不是說 Codex 不好，只是風格不同，你要習慣它的溝通方式。

第四關：速度快，但 overall 沒有更省時間

Codex 在做主要的 code changes 的速度感覺比 Claude 快，但這個速度優勢在後半段消失了。

具體來說：Codex 做完主要改動之後，後續的 test rerun、review、polish 花了很多時間。整體算下來，兩者在 time difference 上面沒有明顯的差距。

這個觀察很重要：不要因為「感覺比較快」就以為效率比較高，要算整個 flow 的時間。

第五關：code architecture 的哲學差異

這是這週最實質的發現。

同一個 requirement，給 Codex 和 Claude 各做一次。Claude 的實作通常會帶更多東西：abstractions、Sorbet signatures、type aliases、design pattern 的應用。Codex 的解法通常更直接，更「contained」，創造的東西更少。

這不是說 Codex 比較差 — 在很多情況下，simpler is better。但如果你的 codebase 需要考慮 long-term scalability，Claude 那個「多做一點」的傾向有時候是有價值的。

測試的時候也發現：Claude 的 code 在 edge case handling 上面表現比較好，可能就是因為它想得更多。

第六關：git 操作的失誤

Codex 在這週犯了一個蠻嚴重的錯誤。

場景是：branch A 以 branch B 為 base，branch B 以 main 為 base。我請 Codex 做 rebase，它直接 rebase with main，結果產生了一個有 4000+ additions 的 PR。

這種操作需要明確的指令，Codex 不會去猜測你的意圖。Claude 在這種情況下通常會先確認你想要的 behavior，或者根據 context 做出比較合理的判斷。

這個差異正好對應到我說的那個核心差距：Codex 做你說的事，Claude 試圖理解你想要的事。在 git 操作這種「說錯了代價很高」的場景，這個差距會很明顯。

第七關：Jira 整合和 MCP 的體驗

Jira 這塊在 Codex 上面很痛苦。我用的是 CLI tool 不是 MCP，Codex 的操作流程很碎：開瀏覽器 → 叫你登入 → 切回 CLI → 再切回瀏覽器。很割裂。

Claude 在這邊的優勢是它記得你之前怎麼做，所以它會更主動地用你習慣的方式處理。

MCP authentication 這塊反而是 Codex 的 CLI 做法讓我比較喜歡：它會叫你手動執行 codex mcp login，每次都走正確的 auth flow，很明確。Claude 有時候會試著自動跑，然後卡住。

---

效果與數據

這週的測試沒有嚴謹的數字，但幾個質性觀察可以轉換成比較具體的判斷：

速度感知 vs 實際效率的落差：Codex 在 initial coding 的速度讓人有「快」的感覺，但整個 PR cycle 算下來，跟 Claude 沒有明顯差距。目前沒有公開數據支持哪個 model 在特定任務上有多少百分比的速度差異。

Code complexity：同一個 requirement，Claude 的實作通常包含更多的 abstraction layers 和 type system 應用，Codex 的解法平均少 20-30% 的「附加建構物」（估計，基於這週觀察的幾個任務）。這個差異在小型 feature 上不明顯，在涉及 architecture 決策的大型 feature 上很顯著。

失誤率：Codex 在這週出現了一次比較嚴重的 git 操作失誤（4000+ additions 的 PR），這類「做錯了代價很高」的錯誤在 Claude 上面較少出現，因為 Claude 傾向在模糊情境下先確認。

工具切換成本：如果你已經有一定量的 Claude skills 積累，直接換 Codex 會有一個 migration overhead，這個成本應該算進去。

---

Meta 判讀

從目前 AI coding agent 的 meta 來看，這場 Codex vs Claude 的比較其實代表了兩種不同的設計哲學：

Codex 的方向：更像是 Unix 哲學 — do one thing and do it well。你說什麼它做什麼，不越界，不過度解讀。這個方向對工程師來說其實很吸引人，因為你知道 agent 的邊界在哪，不用擔心它「自己決定幫你做更多」然後搞壞東西。

Claude 的方向：更像是一個有 context 的 senior engineer。它試圖理解你的意圖，會主動做你「應該要想到」的事，但這個能力同時也是風險來源 — 因為它可能理解錯。

從投資和產品角度來看，OpenAI 和 Anthropic 在 coding agent 這塊的競爭現在越來越直接。Anthropic 在開發者工具這塊建立了相當強的品牌認知，Claude Code 的口碑在工程師社群裡很紮實。OpenAI 的 Codex 還在補足這個差距，但方向感清楚：主打 precision 和 technical clarity，跟 Claude 的「貼心」做差異化。

這場競爭誰贏，很大程度上取決於工程師最後重視哪一個維度：可控性還是智慧性。

---

結論

要不要換？這樣判斷：

繼續用 Claude 的情況：你已經有 skills 積累、你的任務 context 比較複雜、你需要 agent 在模糊情境下做出合理判斷、或者你在趕 deadline。

試試 Codex 的情況：你想要更乾淨的 code output、任務邊界清楚、你習慣 Unix 式的「精準指令」工作流，或者你就是想多認識一個工具。

老實說，我的結論是兩個都留著，任務分工。Codex 拿來跑那些邊界清楚的任務，Claude 繼續處理需要「猜你意圖」的那些。就像打遊戲沒有人說只能練一個角色。

延伸閱讀

• 為什麼開發者開始退訂 Claude？一個真實的產品品質警示
• 繼 Cursor 之後 下一個爆紅的 AI 開發工具會是什麼？
• Coding Agent 正在改變工程、產品、設計的協作方式 — 但改變的不是你想的那個