今天晚上閑著沒事，在自己 Mac 上把Codex CLI和Claude Code CLI拉到一起跑了一場同臺競技——用完全相同的編程任務，喂給同一個后端模型（DeepSeek V4 Pro），看看到底誰更靠譜。

結果有點出乎意料，不是模型的差距，而是工具層的差距。

本次測評說明：Mac 個人機器、headless 自動化運行、2 小時完成L1全部測試、DeepSeek 費用合計約5 元人民幣。純個人體驗，不是官方 benchmark。

為什么要這么測？

現在大家用 AI 編程工具，背后接的模型越來越多樣——OpenAI、Claude、Gemini，當然還有國內的 DeepSeek。但工具本身的穩定性和對第三方 API 的友好程度，往往比模型本身對日常使用的影響更大。

我的測評思路很簡單：

→ 同一套編程題目

→ 同一個后端模型（DeepSeek V4 Pro）

→ 兩個工具各跑 3 遍

→ 自動打分，不人工干預

??重要背景：接入方式不同

Claude Code原生支持 DeepSeek 的 Anthropic 兼容接口，直接配置ANTHROPIC_BASE_URL指向 DeepSeek 即可，一行配置搞定。

Codex就麻煩了。OpenAI 的接口協議在 v5.5 升級后換成了新的 Responses API，DeepSeek 暫時還沒完全跟進這個協議，所以 Codex 必須架一個本地代理做協議轉換，才能接上 DeepSeek——而這個中間層，帶來了一系列不穩定問題。

測試用例設計

整個測評框架按難度分了四檔：

等級

場景

本次狀態

L1

從零新建獨立模塊（算法、腳本）

? 已完成（5 個用例 × 3 次）

L2

修改已有代碼（存量代碼重構/補丁）

? 框架已設計，本次未跑

L3

多文件協作（跨模塊修改、接口對齊）

? 框架已設計，本次未跑

L4

復雜調試（定位并修復隱藏 bug）

? 框架已設計，本次未跑

為什么本次只跑了 L1？兩個原因：

→時間限制：2 小時 + 30 次 headless 運行已經把當天的精力用完了，Codex 的極端超時（最長 31 分鐘）讓整體耗時遠超預期

→先驗證方法論：L1 是最干凈的對照實驗場景——從零新建、沒有歷史包袱，最能單獨觀察工具層的穩定性差異。先把 L1 跑通，L2-L4 的方法論才可信

L2-L4 的測評（存量代碼修改、多文件重構、調試能力）會在后續補上，屆時結論可能會有變化——畢竟"接手別人代碼"才是開發日常里最高頻的場景。

本次 L1 的 5 個用例

5 個從零新建任務，覆蓋 TypeScript、Python、Go：

用例

語言

任務

L1-01

TypeScript

實現 LRU 緩存（O(1) get/put）

L1-02

Python

Nginx 日志解析，Top-10 IP 統計

L1-03

Go

線程安全環形緩沖區（注：本機未裝 Go）

L1-04

Python

為 5 個函數補 Google-style 文檔字符串

L1-05

Python

CSV 轉 JSON（支持嵌套字段）

每個用例自動驗證（腳本檢查文件存在性、函數正確性、格式規范），滿分 3-4 分不等，每個工具跑 3 次取中位數。

綜合得分：Claude Code 83.2 vs Codex 66.4

先上結果：

用例

Claude Code

Codex

差距

L1-01 LRU Cache

89.4

75.0

Claude +14

L1-02 Nginx 日志解析

86.6

56.2

Claude +30 ★

L1-03 Ring Buffer Go ??

67.6

58.7

受環境限制

L1-04 Python Docstring

87.5

67.0

Claude +21

L1-05 CSV to JSON

85.0

75.0

Claude +10

總均分83.266.4Claude +25%

Claude Code 在 5 個用例里拿下 4 個勝利，唯一"平局"是 Go 用例——因為我本機沒裝 Go，兩個工具都因為編譯失敗被扣分，不算誰的鍋。

? 速度差距：慢了 5.7 倍

這是讓我最吃驚的數據。平均響應時間：Claude 78 秒 vs Codex 445 秒。

更極端的是 Codex 的"爆炸式耗時"，出現了幾次讓人崩潰的單次超時：

→ L1-04 第 2 次運行：1895 秒（31 分鐘！）

→ L1-05 第 1 次運行：1351 秒（22 分鐘）

→ L1-01 第 2 次運行：766 秒（12 分鐘）

反觀 Claude Code，最慢的一次是 148 秒。兩個工具接的是同一個模型，時間差異完全來自工具層——很可能是本地代理在某些輪次出現了重試或連接重建。

如果你把 Codex 用在 CI/CD 流水線里，一次超時 30 分鐘，代價太高了。

最大短板：穩定性

這是 Codex 跌得最慘的維度：穩定性得分 40（中位數竟然是 0）vs Claude 的滿分 100。

穩定性維度（同一任務多次運行是否一致）

最典型的例子是L1-02 Nginx 日志解析：

運行次

Codex 得分

Claude 得分

第 1 次

4/4 ?

4/4 ?

第 2 次

2/4 ??

4/4 ?

第 3 次

1/4 ?

4/4 ?

Codex 第 1 次完美，第 3 次連文件路徑都輸出錯了。Claude 三次全部滿分，從未出錯。

同樣觸目驚心的是L1-04 Python Docstring：Codex 連續三次都卡在同一個格式校驗上，Google-style 的 docstring 寫出來通不過 AST 檢查，而 Claude 三次全部通過。

為什么會這樣？根本原因分析

Claude Code：原生兼容，沒有摩擦

Claude Code 直接調用 DeepSeek 的 Anthropic 兼容接口——這個接口協議本來就是按 Anthropic 的規范實現的，Claude Code 原生就支持，零適配成本。配置只需要三行環境變量，調用鏈路極短：

Claude Code → DeepSeek Anthropic 接口 → 模型響應

Codex：協議錯配，代理引入不穩定

Codex 背后調用 OpenAI 的新版 Responses API（v5.5 以后），這個協議用了 WebSocket 長連接 + Server-Sent Events 混合模式，DeepSeek 目前還沒有完整實現這套協議。所以我不得不跑一個本地 Node.js 代理做協議轉換：

Codex →本地代理（deepseek-proxy.mjs）→ DeepSeek → 響應 → 代理再轉換 → Codex

多了這一層，就多了：

→ 連接超時的風險（解釋了那幾次 22-31 分鐘的離譜耗時）

→ 協議轉換帶來的 token 統計丟失（Codex 的 token 數始終報 0，無法統計成本）

→ 偶發的狀態不一致（解釋了 L1-02 質量隨運行次數遞減的現象）

這不是 Codex 或者 DeepSeek 單方面的問題。OpenAI 升級了協議，第三方追趕需要時間。等 DeepSeek 原生支持新協議之后，這些問題大概率會消失。

測試總花費：約 5 元

整個測評 30 次 headless 運行（5 用例 × 2 工具 × 3 次），合計 DeepSeek 費用約5 元人民幣。

其中 Claude Code 每次調用平均消耗約 3 萬 input tokens + 2-7k output tokens，按 DeepSeek V4 Pro 的價格算下來大約 $0.053 / 次。Codex 因為代理不上報 token，無法精確計算，但從模型本身看用量應該相近。

5 塊錢換來 2 小時、30 次真實運行的數據，性價比還是挺高的。

? 給同好們的建議

如果你想接第三方模型（DeepSeek、通義、Moonshot 等）：

→ 優先選Claude Code CLI。原生支持 Anthropic 兼容接口，接入零摩擦，質量穩定，速度快 5 倍以上。

如果你一定要用 Codex：

→ 耐心等 DeepSeek 原生支持 OpenAI 新協議，或者接受當前通過本地代理運行的不穩定性。某些任務 Codex 表現不差，但極端慢和質量退化問題需要心理準備。

如果你想復刻這個測評：

→ 完整的測評框架（runner 腳本、用例、打分器）已開源，地址在文末。

數據匯總

維度

Claude Code

Codex

綜合得分

83.2

66.4

質量

90.0

70.0

效率（速度）

82.2

68.9

穩定性

40.0

平均耗時

78 秒

445 秒

最慢單次

148 秒

1895 秒

測試費用

合計約 5 元（DeepSeek）

第三方 API 接入

原生支持，零配置

需本地代理轉換協議

測評工具版本：Codex CLI v0.133.0 / Claude Code CLI v2.1.119

后端模型：DeepSeek V4 Pro（兩者相同）

運行環境：macOS 15.4.1 / Node v23.10.0 / Python 3.13.2