過去幾週，我特意破壞了自己的工作流程，來觀察當你將真實項目、混亂的代碼庫、不完整的規格等拋給 GLM-4.7 和 GPT-5 時，它們實際上的表現如何。

從紙面上看，這兩者都是「下一代」、「具代理性」、「擅長編碼」，以及其他常見的流行語。而在實踐中，當我進行並排測試，包括修復錯誤、多文件重構、和使用工具的代理時，GLM-4.7 和 GPT-5 之間的差異比宣傳所說的要明顯得多。

在我們深入之前，先做個快速聲明：GPT-5 的細節仍在不斷演變，且供應商的基準測試結果通常是令人滿意的。這裡分享的內容基於我自己在 2025 年 12 月的測試：小規模但可重現的實驗，使用相同的提示、代碼庫和工具，在兩個模型上進行。將這些視為現場筆記，而非權威。

讓我們逐一探討 GLM-4.7 和 GPT-5 真正不同的地方，尤其是在編碼、代理和成本敏感的工作流程上。

為什麼這個比較很重要

兩個模型都強調代理性和編碼能力

我之所以費心深入研究 GLM-4.7 vs GPT-5，原因很簡單：這兩家供應商都在強調同一點，更好的代理，更好的編碼，更好的推理。

在我的測試中，這轉化為三個具體問題：

1. 它們能可靠地驅動工具嗎？

我將兩者接入了一個小型的 代理框架，該框架可以存取：

• 一個shell（受限的沙盒），
• 一個用於讀寫專案文件的檔案系統層，
• 一個測試執行器。

1. 它們能真正交付可用的代碼更改嗎？

我使用了：

• 一套精簡的 SWE‑bench-風格的約40個來自真實開源Python專案的問題，
• 一些來自我客戶工作的TypeScript/Next.js任務。

1. 它們能保持預算嗎？

因為一個「聰明」的代理如果在修復一個錯誤上悄悄花掉50美元，那就不聰明了。

GLM-4.7和GPT-5顯然針對這些情境進行了優化，但取捨不同：

• GPT-5在英語密集型任務和產品風格推理中感覺更「自信正確」。
• GLM-4.7在原始編碼和工具使用上超越了它的價格，尤其是當我用更結構化的提示來引導它時。

對模型選擇決策的真正影響

這不是一場理論上的GLM-4.7與GPT-5對決。選擇滲透到一切事物中：

• 如果你全天候運行代理，模型價格和工具調用效率基本上決定了你的想法是否可行。
• 如果你在大規模的倉庫內工作，內容窗口和輸出長度決定了模型花更多時間在總結而非實際編碼上。
• 如果你為真實用戶運送產品，GPT-5 週邊的穩定性和生態系統可能比原始基準炫耀權更重要。

我已經將一位客戶的內部「AI 開發助理」從僅使用 GPT 的架構轉換為混合架構：GPT-5 用於產品規格工作和面向用戶的文案，GLM-4.7 則負責成本和吞吐量占主導的背景編碼任務。一年前這種分工還是不可想像的：現在就顯得合理了。

基準對決

我不會假裝自己重現了完整的學術基準，但我確實運行了每個的簡化版本。

SWE-bench 驗證

在一個小型的、經過驗證的錯誤修復集中（30 個 Python 問題，每個都有測試）：

• GPT-5：在不需要人工干預的情況下解決了 21/30（70%）。
• GLM-4.7：解決了 19/30（63%）。

當我允許第二次嘗試並提供反饋（「測試仍在失敗，這是日誌」）時，差距縮小了：

• GPT-5：25/30（83%）
• GLM-4.7：23/30（77%）

比起原始百分比，更重要的是它們如何失敗：

• GPT-5 的失敗通常只是缺少一個邊緣案例。
• GLM-4.7 有時會誤解原始問題描述，但在給予更清晰的步驟指導後，恢復得出乎意料的好。

SWE-bench 多語言

我臨時湊合出一個偽多語言的 SWE-bench：

• 保持代碼為英文，
• 但將錯誤報告和評論寫成中英文混合。

這裡 GLM-4.7 與 GPT-5 的比較：

• GLM-4.7：首次通過率為 18/25 (72%)。
• GPT-5：14/25 (56%)。

GLM-4.7 在處理中文錯誤描述方面明顯更好，並且不會被文檔字符串中的混合語言評論混淆。GPT-5 通常在我把報告重新用英文表達後才能解決問題，但這種額外的摩擦在大規模操作時是你不想要的。

Terminal Bench 2.0

對於終端風格的任務（安裝依賴、運行測試、檢查日誌、進行小的文件編輯），我將兩個模型都接入了同一個沙盒。

我測量了 40 項任務的批次成功率：

• GPT-5：34/40 (85%)
• GLM-4.7：33/40 (82.5%)

主要區別：

• GPT-5 平均使用較少的工具調用（每項任務約 3.1 次）。
• GLM-4.7 每項任務大約調用 3.8 次工具。

雖然不算災難性，但如果你的代理每次調用都需要付費，你會感受到差別。

HLE with Tools

針對使用外部工具的高階評估（HLE），我測試了一個小型「分析師」工作流程：

1. 搜索文檔（通過網頁搜索工具）。
2. 閱讀頁面。
3. 調用計算器或小型 Python 沙盒。
4. 撰寫最終建議。

在這裡，GPT-5 開始展現優勢：

• GPT-5 在計劃方面表現更佳：它能提前 2-3 步預測所需的工具。
• GLM-4.7 偶爾會過度使用網頁搜索工具並重新抓取相似的頁面。

總的來說，在這個小型的 HLE-with-tools 測試中：

• GPT-5 大約在 88% 的時間內給出了我認為可以直接投入生產的答案。
• GLM-4.7 大約在 78% 的時間內感覺可以投入生產，其餘部分需要輕微的人為修正。

如果您的主要使用場景是編碼和工具，兩者都很可靠。如果您的使用場景是結合工具的戰略分析，根據我的經驗，GPT-5 還是更有優勢。

價格比較

對於獨立開發者來說，價格是 GLM-4.7 與 GPT-5 之間能悄然影響您整月的關鍵。

API 成本（輸入、輸出、快取的 tokens）

GPT-5 的確切定價尚未公開，但如果遵循 GPT‑4.1/o3 模式，我們預計會看到：

• 每百萬 tokens 的價格高於區域性的中國模型
• 可能對 快取 tokens 和 重用上下文 提供折扣

相比之下，GLM-4.7 在價格上採取了積極的策略，尤其是在中國地區，通常每個 token 比 OpenAI 的前沿模型便宜 30–60%，具體取決於您的地區和供應商。

在典型的編碼會話中（200K 輸入上下文，20–40K 輸出 tokens 跨步驟），我看到的運行成本是：

• GLM-4.7 成本約為 $0.40–$0.60
• GPT-4.1/o3 成本約為 $0.90–$1.40，達到相似的性能

如果 GPT-5 的價格保持在這個高位或更高，GLM-4.7 將在「每解決一個任務的價值」上保持強勢優勢。

典型代理工作流程的總成本

我還跟蹤了 每個成功任務的成本，而不僅僅是每個 token 的成本。

對於我的 30 個任務 SWE 樣式基準測試：

• GLM-4.7：大約 每次成功修復 $0.80
• GPT風格（GPT-4.1/o3代替GPT-5）：大約 每次成功修復 $1.30

即使GPT風格模型能解決更多任務，GLM在每次有效PR上的花費仍然勝出。

如果你正在運行：

• 持續代碼審查代理
• 自動化錯誤分類
• 每晚重構

這些修復成本差異會迅速累積。

自我託管選項（僅限GLM-4.7）

變數是自我託管。GLM-4.7可以部署在您自己的GPU或私人雲上。

這解鎖了以下使用案例：

• 您支付固定的基礎設施費用，而不是不可預測的API波動
• 法律/安全要求代碼絕不接觸美國或第三方供應商
• 您希望並行運行多個小型代理，而不需每次調用收費

當然，這不是免費的。您在交換：

• 運營複雜性（監控、擴展、升級）
• 前期基礎設施成本

……但一旦您的使用量超過某個界限（對我來說大約是 每天15-20M個tokens），GLM-4.7自我託管開始顯得比純GPT-5 API策略更具吸引力。

重要的架構差異

上下文窗口（200K vs ?）

對於GLM-4.7，我一致獲得~200K的tokens上下文使用空間。這足夠用於：

• 一個中等大小的代碼庫片段，
• 加上一些未解決的問題，
• 加上一些日誌和指令。

GPT-5 的具體上下文限制取決於層級/版本，供應商會不斷調整。實際使用中，我也把它當作一個 128K-200K 級別的模型來處理，幾乎從未在日常編碼任務中達到上下文限制。

真正有意義的差異不在於數字，而在於它們的使用方式：

• GPT-5 通常做得更好的是隱式摘要，即使我過度填充上下文，它也能保持專注。
• GLM-4.7 有時會在非常長的提示中「忘記」早期的細節，除非我明確結構化段落（例如，# 規格，# 代碼，# 測試）。

輸出長度 (128K vs ?)

當我要求完整的補丁或測試套件時，GLM-4.7 冷靜地生成了非常長的輸出，數萬個標記而不會卡住。

GPT-5 也能處理大輸出，但我注意到它更可能提前停止並說「如果你想要剩下的部分，請告訴我」，尤其是在類似聊天的界面中。

對於巨大的差異：

• GLM-4.7 更舒適於一次性輸出大塊代碼。
• GPT-5 更偏向於更迭式、對話風格（「這是第 1 部分……現在是第 2 部分……」），這對人類來說更友好，但對自動化流程略顯煩人。

思考模式和推理深度

兩種模型都推銷某種形式的「深層思考」或推理模式。

在我的測試中：

• 開啟 GPT-5 的推理模式（若可用）提升了複雜錯誤修正的成功率約 10–15 個百分點，但也：
  • 增加了延遲約 1.5–2 倍，
  • 並且提高了相同比例的 token 使用量。
• GLM-4.7 的「慢/深思」風格提示（明確指示它逐步思考、檢查假設、重讀代碼）也有幫助，但收益較小：最棘手任務的改善可能只有 5–8 個百分點。

如果你重視產品決策或多步驟規劃的最大推理能力，GPT-5 的高階版本仍然領先。如果你重視在合理成本下的足夠推理，GLM-4.7 自有其一席之地。

實際編碼性能

這裡是 GLM-4.7 與 GPT-5 的編碼比較具體化的地方。

多文件重構

我給兩個模型相同的場景：

• 一個小型 TypeScript monorepo（約 60 個文件）。
• 目標：提取共用分析助手並移除 4 個服務中的重複邏輯。

結果：

• GPT-5：
  • 正確識別了所有 4 個目標區域。
  • 提出了一個非常乾淨的 API 設計。
  • 但其修補錯過了 2 個導入和一個微妙的類型不匹配。
• GLM-4.7：
  • 自行找到了 3/4 的重複點。
  • 需要提示才能找到最後一個。
  • 更常輸出能在第一次嘗試時編譯的修補程式。

經過 2–3 次來回迭代後達到「綠色測試」的時間：

• GPT-5：平均約 22 分鐘（包括安裝和測試）。
• GLM-4.7：約 24 分鐘。

老實說？這算平手。兩者都可以作為重構助手使用。GPT-5 更像是具有良好設計品味的資深開發者，而 GLM-4.7 則像是一個快速且謹慎的中級開發者，會仔細檢查類型。

錯誤修復循環

在較小的 SWE 風格錯誤任務中，我觀察了每個模型在循環嘗試中的表現：

1. 提出修復方案。
2. 執行測試。
3. 閱讀失敗日誌。
4. 再試一次。

我看到的模式：

• GPT-5：
  • 更擅長解釋長的 Python 追蹤。
  • 較不容易重複相同的錯誤修補。
  • 通常在 2–3 次循環內收斂。
• GLM-4.7：
  • 有時會卡在相同的錯誤假設上。
  • 但一旦我明確指出「假設你之前的想法是錯的，提出不同的方法」，它就能跳出困境。
  • 平均需要 3–4 次循環來處理最難的錯誤。

測試生成質量

我也要求兩者在修復錯誤之前生成測試（這是一個出乎意料的強大技巧）：

• 對於 Python + pytest：
  • GPT-5 生成的測試更具描述性，且參數化的案例更好。
  • GLM-4.7 生成的測試稍微簡單一些，但語法錯誤較少。
• 對於 TypeScript + Jest：
  • 兩者都不錯，但在我只給出幾個例子時，GPT-5 更擅長反映實際項目慣例（命名、文件夾結構）。

如果你的主要使用案例是 GLM-4.7 與 GPT-5 的代碼代理比較，我會這樣總結：

• GPT-5：更高的潛力，稍微更擅長規劃，較少出現「愚蠢重複」迴圈。
• GLM-4.7：卓越的成本效益比，當你給它結構化提示和一些防護邏輯時非常強大。

何時選擇 GLM-4.7

對成本敏感的使用案例

如果你是獨立開發者、小型代理商或運行副業項目，GLM-4.7 與 GPT-5 的選擇通常歸結於一個殘酷的指標：每個解決任務的成本。

從我的記錄來看：

• 對於代碼代理，GLM-4.7 通常達到 GPT-5 成本的 40–60%，而質量約為 80–90%。

這種取捨值得用於：

• 背景代碼維護、
• 大規模重構、
• 文件生成、
• 批量測試生成。

自主託管的需求

如果你的團隊或客戶：

• 不能將代碼發送至第三方雲端，或
• 希望在私有基礎設施上運行一切，

那麼 GLM-4.7 的自主託管特性是決定因素。

操作起來更麻煩嗎？是的。你需要處理 GPU、推理服務器、監控和擴展。但如果你的令牌量足夠高且安全/隱私不可妥協，這是一個非常理性的選擇。

中文代碼庫

如果你的代碼庫：

• 具有中文的註釋、變數名稱或提交訊息，或
• 你的團隊優先使用中文報告問題，英文其次，

GLM-4.7 目前具有真正的優勢。

在我混合中英的倉庫測試中：

• 它幾乎能原生理解帶有中文堆疊追蹤和日誌消息的錯誤報告。
• GPT-5 在我翻譯完所有內容後才跟上，但這需要額外的工作流程。

所以如果你在以中文為主或雙語的環境中工作，GLM-4.7 更自然地融入到日常開發生活中。

何時選擇 GPT-5

成熟的生態系統

GLM-4.7 與 GPT-5 的主要非技術性論點是生態系統。

GPT-5 目前在以下方面獲勝：

• 第三方整合的深度，
• 為其 API 調整的現成工具和代理，
• 社群範例、文件和調試提示。

如果你正在構建需要與許多 SaaS 工具、插件或無代碼平台整合的項目，GPT-5 是最省力的選擇。

英文優先的工作流程

對於英文優先的：

• 產品規格，
• 使用者體驗文案，
• 策略文件，
• 複雜的推理任務，

GPT-5 簡直更為精緻。

在我的測試中，它的：

• 規格撰寫，
• 取捨分析，
• 和解釋質量

在不需要修改的情況下更具有「客戶準備好」的品質。GLM-4.7 也可以處理這些，但我發現我更常需要編輯語氣和結構。

最大穩定性需求

如果你的優先事項是：

• 超可預測的延遲，
• 極低的常識幻覺容忍度，
• 以及強大的供應商 SLA，

目前來說，GPT-5 是更安全的選擇。

在長期運行的代理中，一次奇怪的幻覺就可能造成實際損害（比如錯誤配置基礎設施），GPT-5 的安全防護和監控系統更為成熟。GLM-4.7 在我的測試中表現良好，但周圍的生態系統（評估、安全防護、現成工具）尚未經過充分驗證。

更大的格局：模型正在商品化

從更廣的視角來看，GLM-4.7 和 GPT-5 最有趣的部分不是誰「贏了」。而是對於許多日常工作來說，它們都已經足夠好。

現在真正重要的是：

• 解決問題的價格（而不是每個 token 的價格）。
• 圍繞模型的生態系統和銜接工具、日誌記錄、重試、提示模式。
• 是否適合你的語言和領域（以英語為主的 SaaS vs 雙語代碼庫 vs 內部工具）。

經過所有這些測試後，我的實際結論是：

• 當你需要最高的推理質量、精緻的英文輸出和豐富的生態系統支持時，使用 GPT-5。
• 當你更關心吞吐量和成本，或者需要自我託管和更好的中文性能時，使用 GLM-4.7。

老實說？不要害怕混合使用它們。

在我自己的技術堆棧中：

• 規格、產品決策和面向客戶的寫作 → GPT-5。
• 批量編碼代理、測試生成和內部維護任務 → GLM-4.7。

如果你剛開始，我建議這樣做：

1. 選擇一個有代表性的工作流程，比如「使用代理修復我倉庫中的失敗測試」。
2. 使用相同的提示和工具，分別用 GLM-4.7 和 GPT-5 執行 10 次。
3. 追蹤：成功率、總代幣數、成本，以及閱讀輸出時的煩躁程度。

這個小實驗將讓你比任何行銷頁面或部落格文章（包括這篇）更了解 GLM-4.7 和 GPT-5 對你的生活影響。

然後保留真正能為你完成工作的模型，而不是那個有更華麗基準圖的模型。

最適合你的模型取決於你的工作流程，而不是排行榜。

在所有這些測試之後，不舒服的事實是：對於大多數個人和獨立工作流程來說，模型本身不如圍繞它的代理設計來得重要。

這正是我們在 Macaron 所建立的。我們不押注單一「最佳」模型。我們結合最強的現有模型與真正學習你的工作方式、關心什麼、如何迭代以及通常在哪裡出問題的記憶系統。

如果你想知道這在實際中是什麼感覺，可以自己嘗試一下。 [免費試用 Macaron →]