編輯 | 聽雨

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

現(xiàn)在已經(jīng)有太多能寫代碼、而且寫得非常好的模型了。Sonnets、Haiku 4.5、Codex 系列、GLM、Kimi K2 Thinking、GPT 5.1……幾乎每個(gè)都足以應(yīng)付日常的大多數(shù)編碼任務(wù)。

但對(duì)于開發(fā)者來說，誰也不想把時(shí)間和金錢花在一個(gè)排名第二或第三的模型上。最近，小編注意到一位全棧工程師 Rohith Singh 在Reddit上發(fā)表了一篇帖子，介紹他如何對(duì)四個(gè)模型（Kimi K2 Thinking、Sonnet 4.5、GPT-5 Codex 和 GPT-5.1 Codex）進(jìn)行了實(shí)測(cè)。

圖片

他給四個(gè)模型提供了完全相同的提示，要求它們解決可觀測(cè)性平臺(tái)中的兩個(gè)復(fù)雜問題：統(tǒng)計(jì)異常檢測(cè)和分布式告警去重。同一套代碼庫、完全一致的需求、同樣的 IDE 配置。

最終結(jié)論是GPT-5和GPT-5.1 Codex 的表現(xiàn)非常出色，它們真正交付了可上線運(yùn)行的代碼，漏洞最少；他也分析了每個(gè)模型各自的長處：Sonnet 4.5擅長提供高質(zhì)量、經(jīng)過充分推理的架構(gòu)設(shè)計(jì)和文檔輸出，Kimi則勝在創(chuàng)意十足且成本低。

最關(guān)鍵的是，GPT-5 Codex 相比Claude的可用代碼成本便宜 43%，GPT-5.1 則便宜了55%。

這位老哥在 Reddit 上表示：OpenAI 顯然在追逐 Anthropic 的企業(yè)利潤，而 Anthropic 需要重新考慮定價(jià)策略了！

完整代碼：

github.com/rohittcodes/tracer

如果你想深入研究可以去看看。提前說一句：這是作者專門為這次評(píng)測(cè)搭的測(cè)試框架，并不是一個(gè)打磨完善的產(chǎn)品，所以會(huì)有些粗糙的地方。

一、先放結(jié)論：GPT-5.1 Codex 是最終贏家

測(cè)試 1 ： 高級(jí)異常檢測(cè)GPT-5 和 GPT-5.1 Codex 都成功產(chǎn)出了可運(yùn)行的代碼。Claude 和 Kimi 則都存在會(huì)在生產(chǎn)環(huán)境中崩潰的關(guān)鍵性錯(cuò)誤。GPT-5.1 在架構(gòu)上改進(jìn)了 GPT-5，并且速度更快（11 分鐘 vs 18 分鐘）。

測(cè)試 2 ：分布式告警去重兩款 Codex 再次獲勝，并真正完成了端到端集成。Claude 的整體架構(gòu)不錯(cuò)，但沒有把流程串起來。Kimi 有一些聰明的想法，但重復(fù)檢測(cè)邏輯是壞的。

測(cè)試環(huán)境使用了各模型自帶的 CLI agent：

• Claude Code：Sonnet 4.5
• GPT-5 和 5.1 Codex：Codex CLI
• Kimi K2 Thinking：Kimi CLI

關(guān)鍵在于，GPT-5 Codex 總成本是0.95美元，而 Claude 則是1.68美元。也就是說 Codex 便宜 43%，而且代碼是真的能跑。GPT-5.1 更高效，總成本為0.76美元（測(cè)試1花了0.39美元，測(cè)試 2 花了0.37美元），比 Claude 便宜了55%。

圖片

GPT 5.1 Codex：

圖片

官方基準(zhǔn)：

圖片

定價(jià)：

• Claude：輸入 $3 / 百萬 token，輸出 $15 / 百萬 token
• GPT-5.1：輸入 $1.25 / 百萬 token，輸出 $10 / 百萬 token
• Kimi：輸入 $0.60 / 百萬 token，輸出 $2.50 / 百萬 token

測(cè)試如何進(jìn)行：

我給所有模型提供了完全相同的提示，讓它們解決可觀測(cè)性平臺(tái)中的兩個(gè)高難度問題：統(tǒng)計(jì)異常檢測(cè)和分布式告警去重。這些可不是玩具題，而是需要對(duì)邊界情況、系統(tǒng)架構(gòu)進(jìn)行深入推理的那種任務(wù)。

我在 Cursor IDE 中完成所有設(shè)置，并記錄了token 使用量、耗時(shí)、代碼質(zhì)量，以及是否真正與現(xiàn)有代碼庫完成集成。最后這一點(diǎn)的影響遠(yuǎn)超我的預(yù)期。

關(guān)于工具的小提示：Codex CLI 自我上次使用以來已經(jīng)好很多了。支持推理流式輸出、會(huì)話恢復(fù)更可靠，還能顯示緩存 token 的使用情況。Claude Code 依然是最精致的：內(nèi)聯(lián)代碼點(diǎn)評(píng)、可回放步驟、思維鏈條清晰。Kimi CLI 感覺還比較早期。看不到模型的推理過程、上下文很快被填滿、費(fèi)用追蹤幾乎沒有（只能看儀表板上的數(shù)字）。整體讓迭代過程有點(diǎn)痛苦。

二、測(cè)試 1：統(tǒng)計(jì)異常檢測(cè)

任務(wù)要求：構(gòu)建一個(gè)系統(tǒng)，能夠?qū)W習(xí)基線錯(cuò)誤率，使用 z-score 和移動(dòng)平均（moving average），捕捉變化率尖峰（rate-of-change spikes），并在 10ms 內(nèi)處理每分鐘 10 萬條以上日志。

1.Claude 的嘗試

耗時(shí)：11 分23 秒|成本：$1.20|7 個(gè)文件新增，3,178 行代碼

Claude寫得非常“豪華”：用 z-score、EWMA、變化率檢查構(gòu)建了一個(gè)統(tǒng)計(jì)檢測(cè)器，文檔寫得很詳細(xì)，還提供了合成基準(zhǔn)測(cè)試，乍一看相當(dāng)令人印象深刻。但當(dāng)我實(shí)際運(yùn)行時(shí)，問題就來了。

圖3

實(shí)際情況：

• calculateRateOfChange() 在前一個(gè)窗口為 0 時(shí)返回 Infinity
• 告警格式化器對(duì)它調(diào)用 toFixed() → 立即觸發(fā) RangeError 崩潰
• 基線根本不是滾動(dòng)的：

circular buffer 會(huì)丟棄舊樣本

但 RunningStats 會(huì)保留所有數(shù)據(jù)→ 無法適應(yīng)系統(tǒng)狀態(tài)變化（regime changes）

• 單測(cè)使用 Math.random() → 整個(gè)測(cè)試套件非確定性
• 更致命的是：這些代碼完全沒有接入真實(shí)的處理管線（processor pipeline）

結(jié)論是：一個(gè)“很酷的原型”，但在生產(chǎn)環(huán)境中完全不可用。

2.GPT-5 Codex 的嘗試tokens：86,714 輸入（+ 1.5M 緩存）/ 40,805 輸出（29,056 推理）

耗時(shí)：18 分鐘 | 成本：$0.35 | 四個(gè)文件凈增加 157 行

Codex 實(shí)際上完成了集成。修改了現(xiàn)有的 AnomalyDetector 類，并將其連接到 index.ts。它可以立即在生產(chǎn)環(huán)境中運(yùn)行。

Image 4

邊緣情況處理很穩(wěn)健，會(huì)檢查 Number.POSITIVE_INFINITY，并在調(diào)用 toFixed() 時(shí)使用描述性字符串而不是崩潰。基線確實(shí)是滾動(dòng)的，使用循環(huán)緩沖和增量統(tǒng)計(jì)（sum、sum-of-squares），更新復(fù)雜度為 O(1)。時(shí)間桶與實(shí)際時(shí)鐘對(duì)齊，保證可預(yù)測(cè)性。測(cè)試是確定性的，并使用受控的桶觸發(fā)。

有一些權(quán)衡。桶方法更簡(jiǎn)單，但靈活性略低于循環(huán)緩沖。它是在擴(kuò)展現(xiàn)有類，而不是創(chuàng)建新類，這讓統(tǒng)計(jì)檢測(cè)和閾值邏輯耦合在一起。文檔相比 Claude 的長篇說明來說很少。

但重點(diǎn)是：這段代碼可以直接上線。現(xiàn)在就能運(yùn)行。

3.GPT-5.1 Codex 的嘗試tokens：59,495 輸入（+607,616 緩存）/ 26,401 輸出（17,600 推理）

耗時(shí)：11 分鐘 | 成本：$0.39 | 三個(gè)文件凈增加 351 行

GPT-5.1 采用了不同的架構(gòu)方式。它沒有使用時(shí)間桶，而是使用基于樣本的滾動(dòng)窗口，通過頭尾指針實(shí)現(xiàn) O(1) 剪枝。RollingWindowStats 類維護(hù)增量的 sum 和 sum-of-squares，從而可以瞬時(shí)計(jì)算均值和標(biāo)準(zhǔn)差。RateOfChangeWindow 則單獨(dú)追蹤 5 分鐘緩沖區(qū)內(nèi)最舊和最新的樣本。

實(shí)現(xiàn)更加簡(jiǎn)潔。邊緣情況通過 MIN_RATE_CHANGE_BASE_RATE 處理，避免在比較速率時(shí)出現(xiàn)除以零的情況。基線更新被限流，每個(gè)服務(wù)每 5 秒更新一次，減少冗余計(jì)算。測(cè)試是確定性的，使用受控時(shí)間戳。文檔全面，解釋了流數(shù)據(jù)的處理流程和性能特點(diǎn)。

相比 GPT-5 的關(guān)鍵改進(jìn)：

• 執(zhí)行更快：11 分鐘 vs 18 分鐘
• 架構(gòu)更簡(jiǎn)單：不再需要單獨(dú)的 ErrorRateModel 類
• 內(nèi)存管理更好：周期性壓縮緩沖區(qū)
• 質(zhì)量同樣可上線，但效率更高

4.Kimi 的嘗試耗時(shí)：約 20 分鐘 | 成本：約 $0.25（估算） | 增加 2,800 行

Kimi 嘗試同時(shí)支持流式日志和批量指標(biāo)，新增了基于 MAD（中位數(shù)絕對(duì)偏差）和 EMA（指數(shù)移動(dòng)平均）的檢測(cè)，非常有野心。

Image 5

但是基礎(chǔ)實(shí)現(xiàn)有問題。它在檢查新值之前就更新了基線，使得 z-score 實(shí)際上總是零，真正的異常根本不會(huì)觸發(fā)。存在 TypeScript 編譯錯(cuò)誤：DEFAULT_METRIC_WINDOW_SECONDS 在聲明前被使用。速率變化計(jì)算直接除以前一個(gè)值，未檢查是否為零，會(huì)導(dǎo)致和 Claude 一樣的 Infinity 崩潰。測(cè)試中在緊密循環(huán)里重復(fù)使用同一個(gè)日志對(duì)象，從未出現(xiàn)真實(shí)的模式。沒有任何東西被集成。

這段代碼甚至都無法編譯。

5.第一輪快速對(duì)比

總結(jié)：GPT-5 和 GPT-5.1 都交付了可工作的、集成的代碼。GPT-5.1 在速度和架構(gòu)上進(jìn)行了改進(jìn)，同時(shí)保持了同樣的生產(chǎn)就緒質(zhì)量。

三、測(cè)試 2：分布式告警去重

工具路由集成：

我想先自己用一下處于測(cè)試階段的 Tool Router，它基本上允許你添加任意 Composio 應(yīng)用，并且根據(jù)任務(wù)上下文僅在需要時(shí)從對(duì)應(yīng)工具包加載工具。這大幅度減少了你的 MCP 上下文膨脹。可以閱讀這里了解更多：Tool Router (Beta)

在啟動(dòng) 測(cè)試 2 之前，我通過我們的工具路由將所有內(nèi)容集成到 MCP 中，而 MCP 是隨 Tracer 一起發(fā)布的。快速回顧一下為什么要這樣做：Tool Router 將用戶連接的所有應(yīng)用暴露為可調(diào)用的工具給任何智能體（agent）。每個(gè)用戶只需一次 OAuth 授權(quán)，AI SDK 就可以獲得統(tǒng)一接口，而不用我手動(dòng)對(duì)接 Slack、Jira、PagerDuty 以及未來可能接入的其他工具。

實(shí)際好處在于：

1. 統(tǒng)一訪問 + 每用戶授權(quán)：一個(gè)路由就能管理 500+ 個(gè)應(yīng)用，每個(gè)會(huì)話只看到用戶實(shí)際連接的集成。
2. 無需重新部署，SDK 原生支持：新的連接可以即時(shí)出現(xiàn)，帶有正確的參數(shù)和 schema，使智能體可以直接調(diào)用，無需膠水代碼。

（順便提一句，這正是 Rube MCP 后端所依賴的服務(wù)。）創(chuàng)建它的輔助代碼在 packages/ai/src/composio-client.ts：

export class ComposioClient {
  constructor(config: ToolRouterConfig) {
    this.apiKey = config.apiKey;
    this.userId = config.userId || 'tracer-system';
    this.toolkits = config.toolkits || ['slack', 'gmail'];

    this.composio = new Composio({
      apiKey: this.apiKey,
      provider: new OpenAIAgentsProvider(),
    }) as any;
  }

  async createMCPClient() {
    const session = await this.getSession();

    return await experimental_createMCPClient({
      transport: {
        type: 'http',
        url: session.mcpUrl,
        headers: session.sessionId
          ? { 'X-Session-Id': session.sessionId }
          : undefined,
      },
    });
  }
}

有了這個(gè)，任何 LLM 都可以直接接入相同的 Slack/Jira/PagerDuty 鉤子，而不用我手動(dòng)管理 token。只要替換工具包列表或智能體，甚至是內(nèi)部自動(dòng)化，就能獲得同樣穩(wěn)定的工具目錄。

測(cè)試 2：分布式告警去重

挑戰(zhàn)：解決多個(gè)處理器同時(shí)檢測(cè)到同一異常時(shí)的競(jìng)態(tài)條件。處理 ≤3 秒的時(shí)鐘偏差和處理器崩潰問題。防止處理器在 5 秒內(nèi)重復(fù)觸發(fā)同一告警。

1.Claude 的方案

耗時(shí)：7 分 1 秒 | 成本：$0.48 | 四個(gè)文件增加 1,439 行

Claude 設(shè)計(jì)了一個(gè)三層架構(gòu)：

• L1 緩存
• L2 建議鎖 + 數(shù)據(jù)庫查詢
• L3 唯一約束
• 時(shí)鐘偏差通過數(shù)據(jù)庫的 NOW() 而非處理器時(shí)間戳來處理。
• PostgreSQL 建議鎖在連接關(guān)閉時(shí)自動(dòng)釋放，優(yōu)雅地處理崩潰。
• 測(cè)試套件 493 行，覆蓋了緩存命中、鎖爭(zhēng)用、時(shí)鐘偏差和崩潰情況。

問題同測(cè)試 1：沒有集成到 apps/processor/src/index.ts。

• L1 緩存使用 Math.abs(ageMs)，沒有考慮時(shí)鐘偏差（盡管 L2 會(huì)處理）。
• 建議鎖的 key 是 service:alertType，沒有時(shí)間戳，會(huì)導(dǎo)致不必要的串行化。
• 唯一約束阻止所有重復(fù)的活躍告警，而不僅僅是 5 秒窗口內(nèi)的重復(fù)告警。

總結(jié)：架構(gòu)很棒，但仍然只是原型。

2.GPT-5 的方案

tokens：44,563 輸入（+1.99M 緩存）/ 39,792 輸出（30,464 推理）

耗時(shí)：約 20 分鐘 | 成本：$0.60 | 六個(gè)文件凈增加 166 行

Codex 完成了集成。修改了現(xiàn)有的 processAlert 函數(shù)，并加入了去重邏輯。

• 使用基于預(yù)留（reservation）的方法，配合專用的 alert_dedupe 表并設(shè)置過期時(shí)間，比建議鎖（advisory locks）更簡(jiǎn)單，也更容易理解。
• 使用事務(wù)和 FOR UPDATE 鎖來實(shí)現(xiàn)串行化協(xié)調(diào)。
• 時(shí)鐘偏差通過數(shù)據(jù)庫 NOW() 處理。
• 處理器崩潰通過事務(wù)回滾處理，自動(dòng)清除預(yù)留記錄。

注意事項(xiàng)：

• 在 ON CONFLICT 子句中存在輕微競(jìng)態(tài)條件：兩個(gè)處理器可能在任一方提交前都通過 WHERE 檢查。
• 沒有后臺(tái)清理過期的 alert_dedupe 條目（不過每次插入時(shí)會(huì)清理過期條目）。
• 去重鍵包含 projectId，同一服務(wù)+類型在不同項(xiàng)目中被視為不同條目，這可能是有意設(shè)計(jì)，但值得注意。

總結(jié)：除了 ON CONFLICT 的小問題外，這份方案可直接投入生產(chǎn)。

3.GPT-5.1 Codex 的方案

tokens：49,255 輸入（+1.09M 緩存）/ 31,206 輸出（25,216 推理）

耗時(shí)：約 16 分鐘 | 成本：$0.37 | 四個(gè)文件凈增加 98 行

GPT-5.1 采用了不同的方法，使用 PostgreSQL 建議鎖（advisory locks），類似 Claude 的設(shè)計(jì)，但實(shí)現(xiàn)更簡(jiǎn)單。

• acquireAdvisoryLock? 函數(shù)通過 SHA-256 哈希生成 service:alertType 的鎖鍵，確保去重檢測(cè)的串行化。
• 時(shí)鐘偏差由 getServerTimestamp() 獲取的服務(wù)器時(shí)間處理，如果處理器崩潰，鎖會(huì)在連接關(guān)閉時(shí)自動(dòng)釋放。

去重邏輯：

• 先檢查 5 秒窗口內(nèi)的最近活躍告警；如果沒有，再檢查所有活躍告警。
• 如果存在重復(fù)告警，則根據(jù)新告警的嚴(yán)重程度更新。
• 建議鎖確保一次只有一個(gè)處理器可以進(jìn)行檢查和插入，消除了競(jìng)態(tài)條件。

相比 GPT-5 的預(yù)留表方法更簡(jiǎn)潔，不需要額外表，只用建議鎖和簡(jiǎn)單查詢即可。

• 已直接集成到 processAlert，包含正確的錯(cuò)誤處理，并在 finally 塊中清理鎖。

4.Kimi 的方案

耗時(shí)：約 20 分鐘 | 成本：約 $0.25（估算） | 七個(gè)文件凈增加 185 行

Kimi 這次實(shí)際上完成了集成。修改了 processAlert 并加入了去重邏輯。

• 使用離散的 5 秒時(shí)間桶，比預(yù)留表方法更簡(jiǎn)單。
• 使用數(shù)據(jù)庫原生的 ON CONFLICT DO UPDATE 原子 upsert 來處理競(jìng)態(tài)條件。
• 實(shí)現(xiàn)了指數(shù)退避（exponential backoff）重試邏輯。

關(guān)鍵問題：

• 去重檢測(cè)比較的是 createdAt 時(shí)間戳，對(duì)于同時(shí)插入的告警時(shí)間戳相同，會(huì)返回錯(cuò)誤的 isDuplicate 標(biāo)志。
• 重試邏輯計(jì)算了新的桶，但從未使用，仍然傳入相同時(shí)間戳，導(dǎo)致再次遇到相同沖突。
• 更新嚴(yán)重級(jí)別的 SQL 過于復(fù)雜，冗余。

總結(jié)：方法思路不錯(cuò)，但執(zhí)行有嚴(yán)重問題。

5.第二輪快速對(duì)比

總結(jié)：GPT-5 和 GPT-5.1 都交付了可工作的代碼。GPT-5.1 的建議鎖方法比 GPT-5 的預(yù)留表更簡(jiǎn)潔，并且消除了競(jìng)態(tài)條件。

6.成本對(duì)比

兩個(gè)測(cè)試的總成本：

• Claude：$1.68
• GPT-5 Codex：$0.95（便宜 43%）
• GPT-5.1 Codex：$0.76（便宜 55%）
• Kimi：約 $0.51（根據(jù)總成本估算）

雖然 Codex 使用了更多tokens，但成本更低。原因是：

• Claude 的長篇推理和更高的輸出費(fèi)用（$15/M vs $10/M）拉高了成本。
• Codex 利用緩存讀取（超過 150 萬tokens）大幅降低了成本。
• GPT-5.1 在此基礎(chǔ)上進(jìn)一步優(yōu)化了tokens效率，測(cè)試 1 成本 $0.39，測(cè)試 2 成本 $0.37。
• Kimi 的 CLI 只能顯示整個(gè)項(xiàng)目的總花費(fèi)，因此每次測(cè)試的成本需要估算。

四、GPT漏洞最少，Claude文檔全面，Kimi最有創(chuàng)意

這兩項(xiàng)測(cè)試的最終贏家是GPT-5 和 GPT-5.1 Codex，它們交付了可上線的生產(chǎn)代碼，且嚴(yán)重漏洞最少。相比之下，Claude 架構(gòu)更好，Kimi 有創(chuàng)意點(diǎn)子，但只有 Codex 持續(xù)交付可工作的代碼。

1.Codex 勝出的原因：

• 真正集成了代碼，而不是創(chuàng)建平行原型
• 捕捉了其他人遺漏的邊緣情況（例如 Infinity.toFixed() 的 bug，Claude 和 Kimi 都中招）
• GPT-5 和 GPT-5.1 的實(shí)現(xiàn)都是生產(chǎn)就緒
• 比 Claude（GPT-5）便宜 43%，GPT-5.1 更高效

缺點(diǎn)：

• 文檔不如 Claude 全面
• 測(cè)試 2 中有輕微 ON CONFLICT 競(jìng)態(tài)（GPT-5）
• GPT-5 運(yùn)行時(shí)間較長（18-20 分鐘 vs Claude 的 7-11 分鐘），但 GPT-5.1 與 Claude 速度相當(dāng)

2.什么時(shí)候用 Claude Sonnet 4.5：

擅長：架構(gòu)設(shè)計(jì)和文檔

• 思路出色，測(cè)試 2 的三層防御顯示出對(duì)分布式系統(tǒng)的深刻理解
• 文檔詳盡（測(cè)試 1 用了 7 個(gè)文件）
• 執(zhí)行速度快：7-11 分鐘
• 延展思考結(jié)合自我反思，輸出方案推理充分

缺點(diǎn)：

• 不會(huì)真正集成，輸出的是需要手動(dòng)連接的原型
• 兩個(gè)測(cè)試都有嚴(yán)重漏洞
• 成本高：$1.68
• 過度設(shè)計(jì)（3,178 行 vs Codex 157 行凈增）

使用場(chǎng)景：當(dāng)你需要深入的架構(gòu)評(píng)審或文檔優(yōu)化，且愿意花時(shí)間手動(dòng)集成和修復(fù)漏洞時(shí)。

3.什么時(shí)候用 Kimi K2 Thinking

擅長：創(chuàng)造性方案和另類思路

• 測(cè)試 2 的時(shí)間桶、測(cè)試 1 的 MAD/EMA 嘗試顯示出創(chuàng)造性思考
• 實(shí)際集成了代碼，像 Codex 一樣
• 測(cè)試覆蓋不錯(cuò)
• 成本可能最低（CLI 不顯示使用情況）

缺點(diǎn)：

• 核心邏輯處處有嚴(yán)重 bug
• 測(cè)試 2 的重復(fù)檢測(cè)和重試邏輯有問題，測(cè)試 1 的基線更新順序有問題
• CLI 限制（無法查看成本，上下文容易填滿）
• 基本邏輯錯(cuò)誤導(dǎo)致代碼無法正常運(yùn)行

使用場(chǎng)景：當(dāng)你想要?jiǎng)?chuàng)意方案，并且可以花時(shí)間重構(gòu)輸出、修復(fù)漏洞時(shí)。

總的來說，GPT-5.1 Codex 真的是非常出色。它交付了集成好的代碼，能處理邊緣情況，成本比 Claude 低 43%，而且?guī)缀醪恍枰~外打磨。GPT-5 已經(jīng)很穩(wěn)了，但 GPT-5.1 在速度和架構(gòu)上的改進(jìn)，使它成為新項(xiàng)目的明顯首選。

至于Claude，我會(huì)用它做架構(gòu)評(píng)審或文檔優(yōu)化，雖然知道還得花時(shí)間手動(dòng)接入和修復(fù)漏洞。而Kimi勝在創(chuàng)意十足且成本低，但邏輯漏洞很多，需要額外時(shí)間重構(gòu)。

三個(gè)模型生成的代碼都很“漂亮”，但只有 Codex 持續(xù)交付可用、集成的代碼。Claude 設(shè)計(jì)更好，但不集成。Kimi 有聰明點(diǎn)子，但會(huì)出現(xiàn)致命錯(cuò)誤

對(duì)于需要快速獲得可用代碼的實(shí)際開發(fā)場(chǎng)景，Codex 是最實(shí)用的選擇，而 GPT-5.1 則是在此基礎(chǔ)上的進(jìn)一步進(jìn)化，使它更出色。

而在 Reddit 評(píng)論區(qū)，很多網(wǎng)友紛紛表示，自己會(huì)用Codex 審查 Claude Code，效果很好。

圖片

網(wǎng)友 a1454a 則分享了自己的具體步驟：

我也是這樣做的。關(guān)鍵在于上下文管理：研究顯示，LLM 的上下文越多，性能可能越差。對(duì)于復(fù)雜代碼庫，實(shí)現(xiàn)一個(gè)功能可能就占用了大量上下文，幾輪迭代后上下文占用可能達(dá)到 70%。

我的做法是：

1、清空上下文

2、讓 Claude 制定多階段實(shí)現(xiàn)計(jì)劃，每階段都有可驗(yàn)證的驗(yàn)收標(biāo)準(zhǔn)

3、Claude 實(shí)現(xiàn)一兩輪后，讓 GPT-5 高級(jí)思維審查實(shí)現(xiàn)結(jié)果，并反饋給 Claude 修改

4、GPT 滿意后，清空 Claude 上下文，開始下一階段

這樣 Claude 的上下文始終干凈專注于實(shí)現(xiàn)功能，GPT 的上下文則專注于檢查完成的實(shí)現(xiàn)。

還有網(wǎng)友同意作者的觀點(diǎn)：Anthropic 現(xiàn)在定價(jià)太貴了。

圖片

那么評(píng)論區(qū)的各位大佬們：

你更傾向于用哪一款模型呢？你覺得它們之間有何優(yōu)劣？

參考鏈接：??https://www.reddit.com/r/ClaudeAI/comments/1oy36ag/i_tested_gpt51_codex_against_sonnet_45_and_its/??

??https://composio.dev/blog/kimi-k2-thinking-vs-claude-4-5-sonnet-vs-gpt-5-codex-tested-the-best-models-for-agentic-coding??

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：聽雨