實測GLM-5.2 ：你別說，他還真能跟Claude干一下

6 月中旬上線并開源的 GLM-5.2，在當前頂級模型日趨封閉的背景下顯得尤為特別。

而更特別的是：口碑非常好，好到給人一種不真實感。

如果你想用到 GLM-5.2，現(xiàn)在要每天早上 10 點準時去搶資格，每天都是秒沒，搶熱門演唱會的門票也不過如此。

那么，GLM-5.2 究竟是不是真正意義上的國產開源模型突破？測一測便知道。

我們會先從基礎測試開始，拿幾個小游戲和小型軟件試試，然后要再上一個高度，在接近企業(yè)生產級的環(huán)境比如擁有將近 5 萬文件數(shù)的開源版 Excel 也就是 LuckySheet 中，對比 Claude Opus 4.8 和 GLM 5.2 的表現(xiàn)。

基礎能力測試

首先，快速過一遍基礎測試。

GLM 5.2 基本能完成 2048、PVZ 等小游戲的開發(fā)。

2048 一開始出現(xiàn) UI 問題，但也一次性修復好了。

至于 PVZ，除了邏輯沒有錯誤，在沒有任何細節(jié)提示的情況下，GLM 5.2 用純代碼開發(fā)出了可能是目前最具動態(tài)和 UI 美感的 PVZ，其它大部分模型會比較省事地用靜態(tài) Emoji 來代表植物和僵尸，但 GLM 5.2 “ 畫 ” 的植物和僵尸都是會動的。

GLM 5.2 甚至還考慮到了反映植物血量狀態(tài)的變化，比如下圖中最前方的堅果墻，在僵尸啃咬下逐漸出現(xiàn)難受的表情，也是很細節(jié)了。

櫻桃炸彈的爆炸效果也是很酷炫了。

還有一點是，它第一次開發(fā)就包含了種類很全的植物和僵尸，包括了雙發(fā)射手、鐵桶僵尸等。唯一一個槽點是植物卡片還是用 Emoji，雙發(fā)射手用來表示，不好辨認。

在知危另一個常測的案例也就是開發(fā)網頁版 Excel 中，GLM 5.2 一次完成了所有功能的開發(fā)，并且?guī)缀鯖]有錯誤。

在知危的經驗中，這是開源模型第一次做到單次運行就有如此高的完成度。有點小遺憾的是剪切做成了復制，復制會有偶發(fā)錯誤。

但一個比較影響體驗的地方是，這個任務耗時將近一個小時，其中驗證部分的耗時最長。

相比之下，頂尖閉源模型一般在十分鐘內開發(fā)完成。還有一個知危常測的 3D 引擎的開發(fā)也是耗時一個小時后，還沒出來結果，最后放棄。考慮到目前 GLM-5.2 的熱度，猜測是算力供給的原因，不代表模型真實表現(xiàn)。

近生產環(huán)境測試

以上只是前菜，知危過去的 Coding Agent 測評集中在小游戲和小型軟件引擎上，其實離生產環(huán)境還是比較遠。

真正的生產環(huán)境下，要面對數(shù)萬行甚至數(shù)十萬行代碼的上下文，以及成百上千的文件和功能模塊，其中的邏輯關系錯綜復雜。一個新功能即便看似簡單，如果關聯(lián)范圍大，難度也是倍增的。

而一個很容易將關聯(lián)范圍擴大的場景就是企業(yè)軟件的權限系統(tǒng)，畢竟是管理性質的需求，以及自上而下視角的產物。而且這個場景還具有安全和博弈性質，對邏輯上的細節(jié)、漏洞也很敏感。

為了不讓場景過度跳躍，我們還是選用 Excel 這個場景，具體項目來源是開源的 LuckySheet，它基本上包含了完整的 Excel 功能，本地安裝后文件數(shù)量將近 5 萬，但權限系統(tǒng)還很基礎，只有對單個工作表和單元格的編輯保護功能，是比較合適的實驗對象。

LuckySheet 的界面示例如下，權限管理功能在右上角的 “ 保護工作表內容 ” 中。

點擊 “ 保護工作表內容 ” 按鈕后，如下圖所示，如果勾選最上方的 “ 保護工作表及鎖定的單元格內容 ”，則當前這個工作表內所有單元格都不能再編輯 （ 但工作表本身還可以被刪除 ）。

如果在上圖最下方的 “ 允許用戶編輯區(qū)域 ” 中選定部分單元格 （ 比如界面示例中的標黃部分 ），則這些單元格可以編輯，并適用上圖中間的 “ 允許此工作表的用戶進行 ” 中的規(guī)則。比如去掉勾選 “ 設置單元格格式 ”，則在黃色區(qū)域內的單元格不能再設置字體、加粗等格式，但可以做其它勾選的編輯權限，比如刪除行、排序等。

那么，這個權限系統(tǒng)的槽點和不足有哪些呢？主要有四點。

首先，要保護的工作表，怎么還能被直接刪除呢？

其次，不能對文檔中所有工作表統(tǒng)一設置權限，需要一個一個操作，很影響效率。

第三，權限定義范圍僅限于工作表和單元格，沒有擴展到整個工作簿 （ 一個 Excel 文檔涉及的工作空間 ），比如對 “ 導出 ”、“ 打印 ”、“ 截圖 ” 等功能的約束。

最后，也是對生產環(huán)境而言最重要的，缺乏一個 “ 用戶-角色-權限 ” 體系。比如 Owner / Editor / Viewer （ 所有者 / 編輯者 / 查看者 ） 體系中，每一種角色可以被強制擁有不同的權限，比如 Owner 可以擁有所有權限，Editor 只能編輯。這其中涉及的權限最多、最廣，比如 Viewer 只能查看和評論，不能做任何編輯。有了 “ 用戶-角色-權限 ” 體系，Excel 才能被用于企業(yè)日常多人協(xié)作辦公和內容資產管理。

那么，接下來，我們就按以上四點，逐一實現(xiàn)這些需求，并對比 Claude Opus 4.8 和 GLM 5.2 的表現(xiàn)。

第一步，我們給工作表加上防刪除保護。

提示詞：

修改 LuckySheet 的權限系統(tǒng)，聚焦 “ 保護工作表內容 ” 這個模塊。添加一個功能，使得可以用勾選設置，當某個工作表被保護時，不能被刪除。

Claude Opus 4.8 順利實現(xiàn)了這一功能，在原有的 “ 保護工作表及鎖定的單元格內容 ” 選項下，加了一個 “ 禁止刪除此工作表 ”，實測有效。

GLM 5.2 也成功實現(xiàn)并實測有效。

但它把 “ 禁止刪除此工作表 ” 的選項放在了 “ 允許此工作表的用戶進行 ” 的規(guī)則集合中，從權限規(guī)則的集合關系上看，這并不合理。畢竟新規(guī)則是工作表級的，舊規(guī)則是單元格級的。

在第一步的較量中，Claude Opus 4.8 在 UI 層上略勝一籌。

第二步是開發(fā)一個新的配置界面，用來統(tǒng)一管理所有工作表的權限。

提示詞：

在現(xiàn)有 Luckysheet 權限系統(tǒng)基礎上擴展 “ 工作簿級統(tǒng)一權限管理功能 ”。

新增一個入口按鈕，固定放置在左下角 UI 區(qū)域，點擊后打開 “ 工作簿權限設置面板 ”。

功能要求如下：

• 提供對當前工作簿所有工作表 （ Sheets ） 的統(tǒng)一權限配置能力，可批量設置每個 Sheet 的 protection 狀態(tài)與 authority 配置。
• 支持一鍵應用權限模板 （ 如：全只讀 / 部分可編輯 / 完全開放 ）。
• 權限配置需覆蓋： sheet 是否可刪除 （ 繼承 protectSheetDelete ） ；單元格編輯權限 ；插入/刪除行列權限 ；格式修改權限。

Claude Opus 4.8 第一次開發(fā)失敗，左下角的圖標按鈕中的 “ 工作簿級統(tǒng)一權限管理功能 ”，在編輯一次并點擊 “ 確定 ” 生效過后，就無法再次編輯，點擊 "確定" 按鈕沒有反應，也不能真正阻止工作表被刪除。

經過兩次提醒它 debug，Claude Opus 4.8 發(fā)現(xiàn)了問題：工作簿權限面板采用了只初始化一次的模式，后續(xù)打開時只是查看狀態(tài)。并成功修復。

如下圖所示，左下角點擊圖標，就會啟動 “ 工作簿權限設置 ” 配置界面，這里可以集中對所有工作表統(tǒng)一進行權限管理。當為 “ sheet12 ” 工作表勾選 “ 保護 ”、“ 禁止刪除 ” 后，“ sheet12 ” 就不能被編輯和刪除了。

回到 “ 保護工作表內容 ” 這邊，可以看到 “ 保護工作表及鎖定的單元格內容 ”、“ 禁止刪除此工作表 ” 已經對應地被勾選上，只要取消勾選，就能正常編輯和刪除。

另外，在 “ 工作簿權限設置 ” 中，取消勾選 “ sheet12 ” 的 “ 修改格式 ”，并勾選 “ 保護 ”，效果相當于為圖中標黃區(qū)域禁止了 “ 修改格式 ”。

不過，Claude Opus 4.8 其實對最后一句提示詞的理解沒有抓到我的隱含意思，把 “ 允許此工作表的用戶進行 ” 規(guī)則的管理加了一層抽象和簡化，屬于吃力不討好了。

并且，“ 允許用戶編輯區(qū)域 ” 功能沒有被加入進來，這實際上是不完整的，時間原因只能先忽略這一點。

最后，對所有工作表，可以一鍵統(tǒng)一設置權限，切換三種模式。

為了不讓 GLM 5.2 也做吃力不討好的權限抽象的活，我在提示詞最后一句中做了調整，提醒它把權限集合直接搬過去就行。

提示詞：

在現(xiàn)有 Luckysheet 權限系統(tǒng)基礎上擴展 “ 工作簿級統(tǒng)一權限管理功能 ”。

新增一個入口按鈕，固定放置在左下角 UI 區(qū)域，點擊后打開 “ 工作簿權限設置面板 ”。

功能要求如下：

• 提供對當前工作簿所有工作表 （ Sheets ） 的統(tǒng)一權限配置能力，可批量設置每個 Sheet 的 protection 狀態(tài)與 authority 配置。
• 支持一鍵應用權限模板 （ 如：全只讀 / 部分可編輯 / 完全開放 ）。
• 權限配置需覆蓋： sheet 是否可刪除 （ 繼承 protectSheetDelete ） ；單元格編輯權限 ；插入/刪除行列權限 ；格式修改權限等 “ 保護工作表內容 ” 中的 “ 允許此工作表的用戶進行：” 中的所有權限。

GLM 5.2 很順利地解決了這個問題，沒有出現(xiàn) bug，并且界面簡潔而直觀。

它把權限模版、“ 允許此工作表的用戶進行 ” 中的權限細節(jié)，以及工作表列表，完全分開，從而可以做自由組合。

使用上很直觀，但也有一些小缺陷。Claude Opus 4.8 需要重復列出所有權限，但可以一次性逐個配置完，GLM 5.2 的界面則更適合批量配置。

在第二步的較量中，Claude Opus 4.8 在代碼層輸?shù)挠悬c難看，業(yè)務理解上我?guī)土?GLM 5.2 一把，所以不算數(shù)，UI 層上兩者各有千秋。

第三步是增加整個工作簿的權限定義，比如對 “ 導出 ”、“ 打印 ”、“ 截圖 ” 等功能的限定。

提示詞：

在現(xiàn)有 Luckysheet 權限體系基礎上，擴展 “ 工作簿級 （ Workbook Level ） 權限 ”。

當前權限定義主要集中于工作表 （ Sheet ） 和單元格區(qū)域 （ Range ），缺少對整個工作簿功能的統(tǒng)一控制。請設計并實現(xiàn)一套工作簿級權限模型，用于控制用戶對整個文件的操作能力。

新增權限項包括：

• 是否允許導出；
• 是否允許打印 ；
• 是否允許復制任意數(shù)據(jù)；
• 是否允許使用截圖功能；

把這些新功能匯總到 “ 工作簿級統(tǒng)一權限管理功能 ” 的配置界面中。

Claude Opus 4.8 很順利實現(xiàn)了這個功能，畢竟這是相對簡單的需求，不需要像之前那樣處理兩個配置界面之間的映射。

GLM 5.2 也很順利實現(xiàn)了這一功能，雖然在配置后會提示 “ 應用到所選工作表 ”，但其實都會應用到整個工作簿，無論切換到哪個工作表。

在第三步的較量中，雙方打成平手。

在最關鍵的第四步，我們要分兩小步實現(xiàn) “ 用戶-角色-權限 ” 體系，第一小步實現(xiàn) “ 角色-權限 ” 體系，第二小步實現(xiàn) “ 用戶-角色 ” 和 “ 用戶-權限自定義 ” 體系，結合起來才是完整的。

這個體系在真實環(huán)境中需要結合用戶數(shù)據(jù)庫來實現(xiàn)，且要多人云端操作才能驗證，為把驗證過程集中在本地和單人，需要有一個角色或用戶切換機制。

“ 角色-權限 ” 體系下的權限定義如下表所示：

前面都是準備工作，到這里才是本次測試中最有難度的部分。

“ 角色-權限 ” 體系提示詞：

你需要在 “ 不依賴后端用戶系統(tǒng) ” 的前提下，為 Luckysheet 設計并實現(xiàn)一個 Google Sheets 級別的權限系統(tǒng)。

本任務用于本地測試環(huán)境，不需要真實賬號系統(tǒng)，也不需要處理協(xié)同編輯沖突。

一、背景約束

1. 使用 Luckysheet 作為基礎表格引擎
2. 不允許依賴后端用戶系統(tǒng) （ 無 Firebase / Auth / DB ）
3. 用戶在打開工作簿時 “ 手動選擇角色 ”
4. 角色僅用于本地模擬
5. 不需要處理協(xié)同編輯沖突 （ 重點說明：可以忽略 operational transform / CRDT ）

二、目標 （ 核心 ）

請設計并實現(xiàn)一個 “ 權限引擎 （ Permission Engine ）”，實現(xiàn)類似 Google Sheets 的權限體系：

支持三種角色：

• Owner；
• Editor；
• Viewer；

權限架構：

Owner：

• 查看數(shù)據(jù)；
• 評論數(shù)據(jù)；
• 分享數(shù)據(jù) （ 復制、導出、打印、截圖等 ）；
• 編輯數(shù)據(jù)；
• 編輯工作簿、工作表、單元格權限細節(jié)；

Editor：

• 查看數(shù)據(jù)；
• 評論數(shù)據(jù)；
• 分享數(shù)據(jù) （ 復制、導出、打印、截圖等 ）；
• 編輯數(shù)據(jù)；

Viewer：

• 查看數(shù)據(jù)；
• 評論數(shù)據(jù)；

其中：

• Owner 擁有全部權限。
• Editor 可以查看、評論，并在 Owner 設置的權限規(guī)則下進行分享和編輯數(shù)據(jù)。
• Viewer 只能查看和評論數(shù)據(jù)，永遠不能分享、編輯、設置權限。

鑒于 Claude Opus 4.8 第二步的表現(xiàn)不太令人滿意，所以我把 effort 參數(shù)從 high 提高一級，改成了 xhigh。

Claude Opus 4.8 成功實現(xiàn)了三種角色的分配，驗證可行，并且可以通過右上角的按鈕隨時切換角色，這個需求沒有明確提出，但它考慮到了，這對結果驗證很方便。

所有者在工作表和單元格級別的操作效果和未設置角色系統(tǒng)時基本相同，而工作簿級權限對所有者是失效的。

這符合常理，畢竟工作簿權限是資產性質，工作表和單元格權限是內容性質，后者和編輯者更匹配。

編輯者不能打開和配置 “ 工作簿權限設置 ” 和 “ 保護工作表 ” 內容，需要遵循所有者設置的工作簿、工作表、單元格權限來操作。

在下圖中，當管理者設置了不能截圖后，編輯者的截圖操作就被禁止了。

查看者除了閱讀和評論以外什么都不能做，在下圖可以看到工具欄部分除了 “ 評論 ” 都變灰色了，并且如果想對工作表進行復制、刪除、重命名操作，也會無效化。

不過，Claude Opus 4.8 并沒有禁止查看者平移、隱藏工作表，算是個小瑕疵。

考慮到 GLM-5.2 運行時間之長，因此沒有調整 effort 參數(shù)，在默認的 high effort 設置下，GLM-5.2 最后沒有完成這個任務。

比如打開工作簿后，沒有彈出角色選擇頁面，而是直接進入了工作簿，點擊左下角的全局權限設置會被禁止，但其它編輯功能還能正常使用，可能是被默認分配了編輯者角色，但界面中沒有可以切換角色的按鈕，所以沒法再繼續(xù)驗證。

為公平起見 （ 但不保證嚴格公平 ），我們把 effort 參數(shù)從 high 提升一檔到 xhigh，再試一次后，終于成功了，這一次 GLM-5.2 也在右上角設置了角色切換功能。

所有者可以自由編輯權限，編輯者在權限約束下工作，查看者除了評論以外什么都不能做，這些關鍵點都驗證通過了。

值得注意的是，和 Claude Opus 4.8 相同，GLM-5.2 也認為所有者不受工作簿權限的限制。

第一小步的較量不好判斷勝負，還是只看第二小步的表現(xiàn)吧。

在第二小步，我們要實現(xiàn) “ 用戶-角色 ” 和 “ 用戶-權限自定義 ” 體系，這樣更符合協(xié)同辦公軟件的真實設置，直觀理解是所有者可以從基于用戶 ID 分配權限。

其中，“ 用戶-權限自定義 ” 體系是屬于每個用戶的個性化權限設置，和角色默認值有潛在邏輯沖突，會是一個考察重點。

“ 用戶-角色 ” 和 “ 用戶-權限自定義 ” 體系提示詞：

將權限系統(tǒng)的控制粒度從角色級升級為用戶 ID 級，并為 Owner 增加協(xié)作者管理權限。

本任務用于本地測試環(huán)境，不依賴任何后端用戶系統(tǒng)，也不需要真實登錄。

一、核心前提 （ 非常重要 ）

1. 不使用后端
2. 所有用戶在進入工作簿時，根據(jù)列表從中選擇一個 userId （ 唯一標識 ）。一共有 10 個 userId，其中有 1 個 Owner，2 個 Editor，7 個 Viewer
3. 權限完全在前端模擬
4. 不需要協(xié)同編輯沖突處理 （ 忽略 OT / CRDT ）

二、系統(tǒng)目標 （ 升級版 ）

Owner 協(xié)作者管理 （ 關鍵升級點 ）：

Owner 可以：

• 基于 userId 設置、修改協(xié)作者角色，可修改為 Editor 或者 Viewer
• 如果是 Editor，可對指定 userId 分配權限細節(jié)，支持權限覆蓋 role 默認值

觸發(fā)按鈕放置在 UI 右下角。

Claude Opus 4.8 成功地新增了這個功能。

現(xiàn)在，作為所有者 Alice，我們可以和之前一樣，通過 “ 工作簿權限設置 ” 配置適用全局的權限，比如把截圖權限去掉。

也可以在右下角的 “ 協(xié)作者管理 ” 中，配置每個用戶的自定義權限，可以看到，剛打開界面時，編輯者 Bob 和 Carol 的截圖權限都被取消勾選了。如果把一個觀看者 Dave 設置成編輯者，其擁有的權限也是默認把截圖取消勾選。所以同步邏輯沒有問題。

實測 Bob 的截圖操作確實被禁止了。

重頭戲來了，在 “ 協(xié)作者管理 ” 這個界面，你可以任意給編輯者設置和 “ 工作簿權限設置 ” 不一樣的、沖突的權限，比如給 Bob 再加上截圖權限，去掉編輯權限。（ 細心的朋友會發(fā)現(xiàn)這兩個權限項的文字被加粗了 ）

經驗證 Bob 變得可以截圖了。

也變得不能編輯了，雙擊標黃單元格沒有反應。

并且，這時候，無論 Alice 再怎么修改或刷新 “ 工作簿權限設置 ”，都不會影響在 “ 協(xié)作者管理 ” 中編輯過的權限細節(jié)，比如截圖。

那原來方便的同步邏輯就徹底失效了？

并不是，只需要在 “ 協(xié)作者管理 ” 界面中，把 Bob 的權限 “ 重置為默認 ”，就能恢復同步邏輯。這時也能看到，“ 截圖 ” 字樣的加粗格式消失了。

可以說，Claude Opus 4.8 把潛在的邏輯沖突梳理得很明白。

但不足之處在于，“ 協(xié)作者管理 ” 中對編輯權限的設置過于簡單粗暴，沒有匹配 “ 工作簿權限設置 ” 的粒度。

GLM-5.2 交付的成果則是有些奇怪。

首先，角色和用戶切換界面做的很漂亮。

但用戶自定義權限設置中，編輯者的權限細節(jié)沒有和 “ 工作簿權限設置 ” 相匹配，這樣最重要的同步邏輯無法實現(xiàn)，處理自定義權限中的沖突也不需要了，“ 工作簿權限設置 ” 會一直存在潛在的矛盾。

其實，GLM 5.2 是采用了另一種更省事的方式，所有編輯者優(yōu)先遵循 “ 工作簿權限設置 ” 中的配置，還有若存在沖突，則優(yōu)先推論 “ 沒有這項權限 ”。

比如在 “ 工作簿權限設置 ” 中開放所有分享權限，在 “ 協(xié)作者管理 ” 中關閉編輯者 Bob 的分享權限，則 Bob 不能再進行分享。

如果在 “ 工作簿權限設置 ” 中保護某個工作表，在 “ 協(xié)作者管理 ” 中打開 Bob 的編輯權限，Bob 也不能編輯。

這樣的權限體系會更安全，但編輯者的自定義權限只會比全局設置更少，不會更多，自定義的靈活性不夠，也不符合提示詞要求 “ 支持權限覆蓋 role 默認值 ”。

并且，對于自定義權限，GLM 5.2 是接近照搬了提示詞中的字段，這里面 “ 編輯結構 ” 的意義難以理解，經過測試發(fā)現(xiàn)其實和 “ 編輯數(shù)據(jù) ” 是重復的，評論權限的獨立設置并無太大必要性。

所以，在第二小步的較量中，Claude Opus 4.8 在業(yè)務理解和邏輯處理上完勝。

好了，測評結束！

最后看看 Token 用量對比，根據(jù)官網，GLM-5.2 的總用量大約是 40M。

根據(jù) Claude Code 的統(tǒng)計，這里忽略之前測試用的 Claude Fable 5，Claude Opus 4.8 的總用量大約是 759k，GLM-5.2 的總用量大約是 4M，這和官網十倍的差距不知道是什么原因。

以上結果不代表一個編程小白也可以用 Claude Opus 4.8 或 GLM-5.2 上手企業(yè)生產環(huán)境的權限系統(tǒng)開發(fā)，這個測試雖然上下文環(huán)境復雜得多，但也只是基于功能實現(xiàn)層面。企業(yè)生產環(huán)境中的權限系統(tǒng)本質上是業(yè)務規(guī)則的表達，而不只是技術問題，包含大量隱含規(guī)則，更不用說還要考慮攻防博弈、系統(tǒng)可擴展性、責任機制這些因素了。

最后總結一下。

就測評結果而言，在工程實現(xiàn)能力上，GLM-5.2 已經能夠在比較大型的真實項目中與 Claude Opus 4.8 展開正面競爭；但在復雜業(yè)務系統(tǒng)設計、權限模型抽象、規(guī)則沖突處理等偏架構和產品層面的能力上，Claude Opus 4.8 仍然有比較明顯的優(yōu)勢。

但 GLM-5.2 也確實展現(xiàn)出了令人意外的大型代碼庫理解能力和一次性開發(fā)成功率。

不談比較，就模型本身而言，無論是小游戲開發(fā)、網頁版 Excel、還是接近企業(yè)級場景的權限系統(tǒng)改造，GLM-5.2 大部分時間都沒有出現(xiàn) “ 中途崩潰 ”、“ 上下文失憶 ”、“ 功能做到一半跑偏 ” 等問題，在 UI 設計上可以說非常驚艷。即便面對 LuckySheet 這種接近 5 萬個文件規(guī)模的大型代碼庫，它依然能夠持續(xù)理解項目結構，并完成跨模塊修改。

更重要的是，GLM-5.2 并不是一個閉源商業(yè)模型，而是一個開源模型。

如果你的目標是私有化部署、二次開發(fā)、成本控制、數(shù)據(jù)安全，或者希望在開源體系中獲得接近第一梯隊的 Agent 能力，那么 GLM-5.2 已經具備了非常高的使用價值。

當然，GLM-5.2 也暴露出了一個非常明顯的問題：耗時。

在 LuckySheet 權限體系的開發(fā)中，GLM 5.2 基本每一個需求都花了將近一個小時來實現(xiàn)，大部分耗時都花在驗證上。GLM-5.2 在復雜任務上的一次性成功率遠高于過往開源模型，可能是大量驗證和反思帶來的收益。但從實際使用角度看，這依然是一個不可忽視的問題。

好在，速度的問題很大概率是算力問題帶來的，如果獲得更多算力，未來能夠在保持現(xiàn)有完成度的前提下，將大型任務的執(zhí)行速度大幅提高，那么它對閉源頂級 Coding Agent 的競爭力還會進一步提升。