金磊 發自 凹非寺
量子位 | 公眾號 QbitAI

在Coding這件事上，國產AI又famous了一下。

因為剛剛，在Claude Fable 5之下，開源界里拿下了AI編程第一（全球第二）：

不僅Arena官方用“令人難以置信的里程碑”來形容GLM-5.2取得的成績，很多網友也是直呼“瘋狂”：

不僅如此，在專門評測模型品味（taste）的Design Arena上，GLM-5.2取得全球第一的表現。

以及，在八項權威基準測試中，GLM-5.2的表現也是比較亮眼：

從結果上來看，國產、開源的大模型，可以說在Coding這件事上，首次躋身模型全球御三家（Claude、OpenAI和智譜）。

要知道，此前提到AI界的御三家，那大概率指向的是Claude、OpenAI和谷歌，不過這一次，從實打實的榜單能力來看，谷歌的Gemini實實在在地被GLM淘汰掉了。

而且這幾天國外各大博主陸陸續續開始了各種實測。

當然，實測的主角不只是GLM-5.2，他們還把GPT-5.5 High、Opus 4.8 High和Kimi K2.7 Code拉來一起同臺競技。

先說結論：

GLM 5.2表現得極其出色。

實際的對比效果是這樣的：

這位博主認為這類測試是在X上比較能體現AI實力的那種，而GLM-5.2的表現已經接近Claude Opus 4.8。

無獨有偶。

另一位外國博主同樣做了類似的實測，GLM-5.2依舊是穩穩輸出，讓他直呼道：

This is crazy.

但體感和口碑還只是一方面。

若是深挖一下GLM-5.2，它的亮點還包括：

支持真正可用的1M上下文，并在長程任務中繼續保持領先。

換句話說，現在的GLM-5.2可以一口氣“吃”下大項目級上下文、跨數小時自主推進。在很長一段時間里，Opus 級別的長任務與大型開發任務，是國產模型與海外旗艦之間很大的gap。

那么當它走進真實工作環境，效果如何？

一波實測，走起~

是真記得，還是只裝得下？

完整代碼庫理解

首先我們要測試的是GLM-5.2的記憶力。

因此，我們特意準備了GitHub上的Appsmith項目。

之所以選這個項目，是因為它是一個開源低代碼平臺，用于構建dashboard、admin panel、IT自動化等內部應用，天然包含前端、后端、插件、部署、權限等復雜模塊。

然后我們直接“喂”給GLM-5.2這樣的Prompt：

你是資深軟件架構師。桌面上的Appsmith是一個完整項目代碼庫，請先不要修改代碼。 請完成三件事： 1.梳理項目整體架構，輸出核心模塊、調用關系和數據流； 2.找出跨模塊耦合最重的3處，并說明原因； 3.給出一份可執行的重構路線圖，要求不破壞現有接口和測試。

這項任務的重點看模型能否把前端、后端、插件、Git服務、運行時和部署關系串起來。

先來看GLM-5.2的結果（上下滑動查看）：

可以看到，GLM-5.2先把Appsmith拆成monorepo結構，前端、后端的定位，以及拆分目錄也是非常精準。

更關鍵的是，它把幾條主鏈路串了出來。并且在耦合點判斷上，GLM-5.2也抓到了3個關鍵位置。

接下來是CodeX的表現（上下滑動查看）：

從輸出的效果來看，CodeX的結果更加清爽一些，它直接畫出了Appsmith的整體架構圖，并且對核心模塊的拆解也準確。

兩者的判斷有不少交集，都抓到了前端Redux/Saga中心化、后端ActionExecutionSolutionCEImpl.java過重，以及CE/EE繼承結構的問題。

不過雖然Codex的可讀性更強一些，但更像一份結構清晰的技術備忘；而GLM-5.2覆蓋更深，文件、鏈路、風險點和遷移階段給得更多，像是在給項目做一次工程體檢。

跨文件追Bug

第二項實測，我們換成OpenWebUI，測試一個真實工程里常見的問題，跨文件追Bug。

Prompt是這樣的：

桌面上的open-webui項目里有一個線上Bug，請你從全庫代碼中定位可能原因，給出：1.最可能的問題鏈路；2.涉及文件和函數；3.修復方案；4.需要補充的測試用例。 不要只看單個文件，請結合調用鏈分析。

GLM-5.2抓住了一個核心點，也就是DirectConnection流式返回的邊界不可靠（上下滑動查看）。

它把問題定位到“前端把上游SSE分片后再回傳，后端按完整事件解析”這條鏈路，并給出前后端兩側修復方向。

這一關很適合看模型有沒有真正沿著調用鏈走。

如果只看單個文件，很容易給出“加重試”、“加日志”、“檢查緩存”這類通用答案。但這個問題真正藏在前端chunk、SSE協議、socket轉發和后端JSON解析之間。

新增功能

第三個實測，我們繼續用OpenWebUI，任務是新增“會話摘要導出為Markdown”功能：

請在open-webui項目中新增一個“會話摘要導出為Markdown”的功能：1.用戶可以選擇一個歷史會話；2.系統生成結構化摘要；3.支持導出Markdown；4.補充必要測試；5.不要破壞現有接口。 請先給出實現計劃，再分步驟修改。

對于這個任務，模型需要先理解會話數據怎么存，權限怎么判斷，前端菜單入口在哪里，API怎么封裝，測試應該放在哪里。

GLM-5.2這一輪更像完整工程交付：

它把“Markdown導出”拆成后端工具、路由、前端API、UI入口和測試五層；最后，它跑出了38個后端測試全部通過。

這就是AgenticCoding真正要看的地方。交付物不能只是一段代碼，還要能并入項目。

一口氣做多項任務

第四個實測，我們這次嘗試讓GLM-5.2和CodeX一口完成多個任務。

Prompt是這樣的：

基于公開可驗證數據，構建一套可追溯、可復現的 2026 年英國 PBSA（學生公寓）行業研究與數據分析包，系統評估學生需求、供給管線、租金走勢、運營商格局及投資環境，為內部投資與預算決策提供支持。

在片刻之后，GLM-5.2一口在桌面輸出一整個文件夾的內容：

做的圖表是這樣的（上下滑動查看）：

也同時生成了一份完整的分析報告：

整體來看，GLM-5.2在文件數量、表格結構、圖表覆蓋、復現腳本和數據質量控制上更完整，最終更像一套可以拿去內部評審前繼續打磨的研究材料包。

什么時候別用1M

不過有一說一，1M上下文并不是什么任務都適用。

如果只是改一個小函數、補一個簡單腳本、改一個按鈕文案，整庫上下文的收益并不明顯。很多時候，只給必要文件，模型反而更快、更干凈，也更不容易過度設計。

真正適合1M上下文的，可能是下面這幾類任務：

整庫理解、跨文件追Bug、長期重構、復雜功能新增、多交付物研究項目、超長文檔審閱、代碼和文檔一起分析。

也就是說，1M上下文是為了讓它在真實工作里少忘事、少跑偏、少反復問你要背景。

它把長上下文從一個發布參數，拉回了開發者和知識工作者真正熟悉的現場：一個大項目、一堆歷史包袱、幾個跨模塊Bug、一項不能破壞舊邏輯的新需求，以及一整套必須同時交付的報告、表格、圖表和腳本。

模型競爭進入長期工作能力階段

這輪測完，一個最直接感受或許是這樣的：

AICoding正在換階段。

過去大家更關注模型會不會寫代碼、會不會補全、會不會一次性生成一個Demo。這個階段比的是單次輸出能力。

但現在，開發者開始把模型放進真實工程流里使用。任務不再是寫一個孤立函數，而是讀完整項目、理解架構、追蹤調用鏈、保持需求約束、修改多處文件、補測試、生成文檔，甚至連續十幾分鐘、幾個小時自主推進。

這時候，模型競爭的核心就變了。

上下文長度不再只是參數表上的數字，它開始變成Coding Agent的工作內存。一個Agent要持續工作，就必須記住項目結構、接口約定、歷史決策、工具調用結果、中間修改狀態和用戶最開始給出的邊界條件。只要中途忘掉一項，最后產物就可能偏。

所以長上下文真正重要的地方，在于把AI Coding從會寫一段代碼，推向能做一段工程。

這也是為什么GLM-5.2有機會進入AI Coding里的“御三家”。

在全球CodingAgent進入硬核的長程工程階段后，開發者正在形成三類主流選擇：ClaudeCode、OpenAICodex，以及以GLM-5.2為核心的開源長程CodingAgent路線。

• Claude Code代表的是閉源Coding Agent體驗的上限，強在工程體感、工具調用和復雜任務推進；
• OpenAI CodeX代表的是OpenAI體系下的代碼生成和智能體路線，背后有模型、產品和開發者生態的連續投入；
• 而GLM-5.2代表的，則是另一條同樣關鍵的路線：開源、長上下文、面向真實工程任務的Coding Agent底座。

這條路線的價值，不只在于國產模型也能寫代碼。

更重要的是，當AI Coding進入大工程階段，開發者需要的不只是一個云端黑盒。很多團隊會關心模型能否私有化，能否接入自己的工具鏈，能否讀內部代碼庫，能否承載長上下文任務，能否在成本可控的前提下穩定工作。

開源長程Coding Agent路線，正好補上了這塊拼圖。

如果說前一階段的AI Coding，比的是誰能更快寫出一段能跑的代碼；那么下一階段，比的就是誰能更久地待在項目里，理解它、記住它、改動它，并且不把它弄壞。

這也是GLM-5.2這次最核心的信號：

國產開源模型的競爭，已經不只是在榜單上追分，而是在進入真實開發者工作流，進入長程工程任務，進入AICoding最硬核的牌桌。

而這張牌桌上，GLM-5.2終于有了一個清晰的位置。

參考鏈接：
[1]https://x.com/ng_thanh8/status/2066806465042718755
[2]https://x.com/OmedVibeCodes/status/2066568185202012170
[3]https://x.com/aicodeking/status/2065714397159555563
[4]https://x.com/arena/status/2066957802741043641
[5]https://x.com/Designarena/status/2066940737011560652