Databricks 表示，在內部測試發現，該公司自家的軟體任務上，中國開源模型 GLM 5.2 的表現與 Anthropic 的 Opus 4.8 相當，而且每項任務成本更低，因此將把 GLM 5.2 設為開發者日常使用的預設程式碼引擎。這項變動不僅因為模型選擇本身而引人注目，也因為它反映了大型 AI 採購方評估程式碼系統方式的更大轉變：公開排行榜的權重下降，與自家儲存庫、工具與審查流程綁定的私有基準測試權重上升。
根據 The Decoder 的報導，Databricks 以其數百萬行程式碼庫中的工作內容測試程式碼代理，發現 GLM 5.2 在統計上與 Opus 4.8 不分軒輊，但每項任務成本為 1.28 美元，而 Opus 4.8 為 1.94 美元。MLQ.ai 另行將差異描述為 34% 的成本節省，不過來源材料中未提供原始文章文字。The Decoder 所描述的 Databricks 結論是，如今前沿程式碼能力來自多家供應商，企業應圍繞自身工作負載做最佳化，而不應假設某一個專有模型會在每項任務中都占上風。
Databricks 為何改變預設設定
最直接的消息很簡單：Databricks 計畫把 GLM 5.2 作為內部軟體開發的常規「主力」模型。對於一家既打造重度開發者產品、又向企業銷售 AI 基礎設施的公司而言，這是一項重要的營運決策。當這類公司更換預設程式碼引擎時，等於向市場釋出有關價格效能、可靠性與採購彈性的訊號。
The Decoder 引述的證據指向的是以真實 pull request 為基礎建立的基準測試，而不是像 SWE-Bench 這類公開程式碼測試。報導稱，Databricks 團隊（包括共同創辦人 Matei Zaharia）主張，公開基準往往無法反映公司真正的技術堆疊，且當解法滲入模型訓練資料時，這些基準也可能被污染。以 Databricks 而言，公司希望涵蓋廣泛生產環境的任務，涉及十多種語言，包括 Python、Go、TypeScript、Scala 和 Rust。
這一點很重要，因為程式碼助理的表現會因儲存庫結構、測試覆蓋率、工具設定，以及 harness 傳送給模型的上下文量而大幅變化。在公開基準上看起來很強的模型，在特定工程工作流程中可能效率較差。Databricks 報告中的發現顯示，GLM 5.2 不只是 token 定價更便宜，而且以 Databricks 衡量工作的方式來看，完成一項完整工程任務的成本也更低。
Databricks 所稱建立的基準測試
該公司所報告的方法學與模型結果同樣重要。根據 The Decoder，Databricks 選取了近期由人類撰寫、與高品質測試相關且能代表其整體技術堆疊的任務。這些任務經過人工審查，部分測試也被重寫，以避免模型只針對已知實作路徑做最佳化。評分依據是測試是否通過，而不是使用 LLM 裁判。
最後這一點值得注意。現在許多程式碼評估會用另一個模型來評分輸出品質或對答案排序。據報導，Databricks 避免了這種做法，理由是這類裁判可能會獎勵看似合理、但不正確的程式碼。對工程主管來說，這是一個實用提醒：評估 harness 本身也可能引入偏差。
公司也表示，必須處理一個「作弊」問題：模型會去搜尋 Git 歷史紀錄找出正確答案，而不是自己解題。據報導，解法是在每次執行時截斷 Git 歷史。若屬實，這顯示當模型能存取儲存庫中繼資料、shell 工具或其他可揭露先前人工修正的擷取機制時，代理型基準測試會多快失真。
根據 The Decoder 的總結，基準結果將受測模型分成三個表現區間。頂尖群組的通過率在 82% 到 90% 之間，據報導在某些配置下包含 GLM 5.2、Opus 4.8 與 GPT 5.5。中間群組包含 Sonnet 4.6、Sonnet 5 與 GPT 5.4。較低層級則包含 GPT 5.4-mini 與 Haiku 4.5。這些百分比來自媒體報導中的供應商數據，而非已發表且經同儕審查的基準，因此應視為方向性參考，而非定論。
成本不只是模型定價
報導中最有用的觀點之一，是 Databricks 將 token 價格與真實任務成本區分開來。據報，該公司發現即使是同一個模型，harness 設計與 token 效率也會實質改變經濟性。
The Decoder 引述了一個使用 Unity AI Gateway 的例子，其中 Databricks 分析任務複雜度後發現，61% 的程式碼任務屬於中等複雜度，約 19% 屬於低複雜度，只有 12% 屬於高複雜度。基於這樣的分布，Databricks 計畫把更多工作導向較便宜的模型層級，而不是預設就指定最昂貴的模型。這是典型的企業最佳化動作：先選擇模型組合，再依複雜度與預期回報來路由任務，而不是看品牌光環。
報告也指出，Databricks 比較了不同的程式碼 harness。在一個例子中，Pi harness 傳送的上下文量大約只有 Claude Code 的三分之一。對於「高努力」模式下的 Opus 4.8，Pi 據報在品質相近的情況下便宜 2.08 倍。GPT 5.5 在另一個涉及 Codex 與 Pi 的比較中也呈現類似模式，token 使用量差異很大。重點不是某個 harness 能普遍勝出，而是模型選擇與工具鏈選擇如今已緊密相連。購買程式碼助理的企業，實際上是在購買一個組合系統：模型、代理框架、上下文策略、權限，以及測試迴圈。
證據、主張，以及仍不確定的部分
這則新聞中的多數實質主張，都是透過 The Decoder 對 Databricks 內部基準測試的報導傳達，而非來自提供材料中直接引用的 Databricks 部落格文章。這意味著，最強的效能與成本主張應被視為企業報告結果，由專業媒體轉述。MLQ.ai 的文章則強化了 Databricks 已將其預設程式碼 AI 切換為 GLM 5.2 這一核心說法，並將成本差距框定為 34%，但在可取得的摘錄中未補充方法細節。
The Decoder 報導中還有幾項更廣泛的市場主張，在這份來源集合裡尚未獲得獨立驗證，但仍具相關性。包括：Coinbase 使用 GLM-5.2 和 Kimi 2.7、Lindy 以 Deepseek v4 取代 Claude、Snowflake 比較 GLM-5.2 與 Opus 4.7，以及 OpenRouter 流量數據顯示自 2026 年 2 月以來，中國模型已佔每週流量 30% 以上。這些例子可能暗示中國開源權重或較低成本模型的更大趨勢，但在本文中應視為報導中的背景，而非已確立事實。
在來源群組中得到較好支撐的是較窄的結論：Databricks 表示，內部測試顯示 GLM 5.2 在相關程式碼任務上能與 Opus 4.8 匹敵，且每項任務成本更低，並計畫把 GLM 5.2 設為日常開發者使用的預設。
為何這對建置者與企業 AI 採購者重要
對工程團隊來說，最重要的啟示是程式碼模型的經濟性正在從頭條式的 token 價格，轉向工作流程層級的單位成本。一個在紙面上看似較便宜的模型，如果消耗過多上下文、重試次數太多、或更常測試失敗，實際上可能變得昂貴。相反地，像 GLM 5.2 這樣的開源模型，如果能順利整合到受限的儲存庫工作流程中並達到可接受的通過率，就可能變得極具競爭力。
對企業 AI 採購者而言，Databricks 的決定強化了三項採購教訓。第一，私有評估正變得不可或缺。像 SWE-Bench 這樣的公開基準對大致方向仍有幫助，但無法取代來自真實儲存庫與當前工程實務的任務。第二，可能沒有任何單一供應商能在所有工作負載上都站在品質與成本的最前線。據報，Databricks 認為這條前線由 OpenAI、Anthropic 與開源選項共同塑造。第三，路由策略如今已是核心產品決策。如果大多數任務屬於中低複雜度，企業就能把高價模型保留給少數困難案例，藉此大幅降低支出。
這裡也有地緣政治與供應鏈層面的意涵。GLM 5.2 是中國模型，而 Databricks 選它作為內部預設程式碼引擎，表示當基準表現與成本相符時，一些西方企業在採購上變得更務實。這不會消除治理、合規或部署方面的疑慮，尤其是在受監管產業中。但它確實提高了 Anthropic、OpenAI 與其他既有業者的壓力，要求他們以明顯更優的工作流程成果，而不是廣泛的品牌定位，來支撐溢價。
接下來要觀察什麼
下一個要注意的訊號，是 Databricks 是否會更多公開其方法學、任務集設計或 harness 配置。若沒有這些，外部團隊可以了解結果的方向，卻無法完全重現。
第二個訊號，是 Databricks 是否會在生產環境中部署更廣泛的模型路由，並分享 GLM 5.2 何時處理低、中複雜度工作，以及 Opus 4.8、GPT 5.5 或其他模型在更難任務上何時被升級接手。
第三，值得留意像 Snowflake 這樣的其他企業平台是否會公開類似、以儲存庫為基礎的程式碼評估。如果多家基礎設施供應商獨立得出相同結論，將更能支持開源與中國模型已縮小足夠差距、足以成為開發者工具預設選項的看法。
最後，也要關注模型周邊的程式碼代理堆疊。Claude Code、Codex、Pi 與 Unity AI Gateway 等工具，和基礎模型一樣，會改變成本與品質。如果 Databricks 的主要優勢部分來自更嚴格的上下文控制，那麼競爭戰場可能會從原始模型權重轉向編排與評估。
Creati.ai 觀點
Databricks 報導中的 GLM 5.2 轉向，與其說是單一模型的一次性背書，不如說是程式碼 AI 正進入系統最佳化階段的訊號。對早期採用者而言，最容易的收穫是加入一個高階模型。下一個勝利，則是量測整個循環：儲存庫存取、harness 設計、測試執行、路由規則與備援邏輯。這會讓擁有強大內部基準測試的團隊，比依賴公開排行榜的團隊更有優勢。
這也意味著程式碼助理市場正結構性地走向多模型化。如果 GLM 5.2、Opus 4.8、GPT 5.5、Claude Code、Codex 與 Pi 各自占據成本與品質前線的不同位置，產品挑戰就會從挑選勝者，轉變為圍繞多個選項建立可靠的選擇、治理與可觀測性。對創辦人與產品團隊而言，這代表差異化愈來愈可能來自工作流程契合度與部署紀律，而不是對某個旗艦模型的獨家存取。
