這一模型專為長程任務打造。
智東西4月8日報道，今天，智譜正式開源其最強模型GLM-5.1，這一模型在專業軟件開發基準測試SWE-Bench Pro中，GLM-5.1刷新全球最佳成績，得分達到58.4，超過了GPT-5.4、Claude Opus 4.6等已經正式發布的閉源模型，和MiniMax M2.7、Kimi K2.5等開源模型。
GLM-5.1并非只能跑跑簡單的Vibe Coding小案例，它專門面向長程任務設計，能持續地自主規劃、執行并迭代，最終交付完整的工程結果。
兩個官方演示，直接把“長程任務”的能力具象化了：
在向量數據庫的調優任務中，GLM-5.1沒有人類手把手教，自己跑了655輪迭代——測試、分析、改代碼、再測試……最終把性能硬生生提升至3.6倍。
自動播放它還靠著一張架構草圖，連續自主工作了超過8小時，執行了1200多個步驟，最終輸出了一套功能完備的Linux桌面系統。官方測算，這相當于一個4人小團隊連軸轉一周的工作量。
自動播放這個“8小時不間斷工作”的紀錄，讓它成為了全球首個在真實工程任務中驗證這一能力的開源模型。
這意味著，那些過去只屬于人類團隊的復雜、長周期工程級任務，現在對逐漸AI也敞開了大門。
01.
海外網友火速體驗：
體感接近Opus 4.6
成本暴砍至1/30
GLM-5.1一經發布，就吸引了海量關注，其推文的閱讀量在12小時內就沖破了200萬次，目前已經飆到227萬次了。
不少體驗過GLM-5.1的網友紛紛發帖評價，在這些帖子中，有一個關鍵信息被反復提及：GLM-5.1的使用體感，已經接近Claude Opus 4.6。
AI開發者toli拿GLM-5.1和Opus 4.6跑了113個編程任務，發現GLM-5.1的體感就和Opus一樣。同時，智譜的Coding Plan提供了Claude Code訂閱三倍的用量，價格只有后者的1/3。Toli認為，GLM-5.1是絕對的殺手級產品。
另一位開發者Beau Johnson分享，他已經將自己部署的OpenClaw背后的模型，從Opus 4.6替換為GLM-5.1，作為協調和執行Agent。這一切換沒有帶來任何體驗上的差別，而成本卻從1000美元暴砍至30美元左右。
軟件定制公司Zenoware的創始人JP分享了他用GLM-5.1 one-shot做出來的10個案例，JP認為這是最接近Claude Opus 4.6的中國模型，給Opus 4.6帶來了嚴重威脅。以下是JP部分案例的集錦：
口碑之外，GLM-5.1在多項基準測試中的表現，同樣值得仔細拆解。
在編程能力這一維度，有三個基準測試的成績較有參考性，包括衡量模型專業軟件開發工作的SWE-Bench Pro、操作命令行解決問題的Terminal-Bench 2.0、從零構建完整代碼倉庫的NL2Repo。在這三個基準測試中，GLM-5.1的得分已經拍到全球第三、國產第一、開源第一。
而在考察模型設計能力的Design Arena上，GLM 5.1排名第四，同時多款GLM模型也包攬了這一榜單上的前四名，這個表現，基本可以和Opus 4.6還有Sonnet 4.6一塊兒坐主桌了。
而在文本能力維度，Text Arena上GLM-5.1被評為排名第一的開源模型。
02.
真刀真槍一手實測：
連續接受十幾條需求變更
還扛住了拔網線和復雜遺留代碼
榜單好看，用戶也叫好，但真正的考驗還是在實際使用里。這次，智譜格外強調“長程任務（Long-Horizon Tasks）”，確實精準判斷了當前大模型在工業界落地的痛點。
在真實的軟件工程或復雜業務場景中，幾乎沒有任何有價值的問題是可以通過“一問一答”或“單次生成”解決的。只有真正具備了自主試錯和策略演進的能力，模型才能像中高級工程師一樣去“啃”硬骨頭，而不是只寫個初版就罷工。
這已經幾乎成為了行業共識。無論是GLM-5.1、Claude Opus 4.6還是GPT-5.4，各家都在將長程能力作為核心賣點。
原因是，對于真正要拿AI干活、提效的企業而言，分數、正確率、排行榜都只是參考，他們關心的是模型能否在拿到一個任務后無需人工干預，自動診斷并修復問題，能否用8小時替代一個初級工程師一周的重復勞動，這些，才是可見的真實生產力。
那么，GLM-5.1到底能不能打？它真的能成為Opus 4.6的國產平替嗎？我們拿GLM-5.1和Opus 4.6跑了兩個完整工程任務，燒掉幾百萬token，看看它們的真實表現到底如何。
1、從零搭建待辦看板，前后端+數據庫全閉環
Prompt：
在一個空目錄下，從零搭建一個完整的“待辦事項看板”前端+后端，使用FastAPI+React，連接PostgresSQL數據庫，實現增刪改查。
拿到這一任務后，GLM-5.1和Opus 4.6都進行了初步的項目規劃，拆解提示詞中的要求，然后再開始開發。值得一提的是，我們用于測試的電腦環境相對老舊，還缺失部分依賴。率先進行開發的GLM-5.1馬上定位了這些問題，直接“動手”幫我們裝好了。
其實，GLM-5.1和Opus 4.6一開始給出的結果都有點簡陋。于是我們向兩個模型發送了十幾條修改意見，包括要打造完整的導航菜單、配備全局搜索框+通知系統+用戶頭像、三級分組菜單等等。
GLM-5.1并沒有被這一連串的“干擾”打斷自己的開發節奏，在多輪需求變更后仍然可以成功交付。最終它打造的任務看板功能完整度較高，交互體驗流暢，前后端數據也是聯動的——新增的項目的確能在數據庫中找到。
網頁的UI細節也很到位，字體大小層級分明，光標懸停在卡片上時有微動效，還通過顏色區分了任務的優先級。
再來看看Opus 4.6的表現。在基礎功能上，Opus 4.6同樣實現了基于數據庫的增刪改查核心功能，不過網頁的色彩選擇和UI設計有些單調。
這一表現源于智譜在訓練策略上的創新：通過顯著擴展任務過程的訓練窗口，采用多輪監督微調（multi-turn SFT）與強化學習（RL）結合的訓練范式，GLM-5.1得以在完整的任務流程中學習，從“接受任務→規劃→執行→調整→交付”的全過程都被納入學習信號。因此，它不會因新指令的影響，丟掉原本的目標與方向。
2、網絡中斷+遺留代碼+中文亂碼：GLM-5.1如何自救？
Prompt：
搭建一個簡易的電商后臺，需要實現商品管理、訂單流程和支付對接。
當AI模型進入企業，面臨的往往是更多復雜的不確定性，比如模糊的目標，混亂的項目結構等等。在這些因素的干擾下，GLM-5.1還能穩定交付嗎？
GLM-5.1的新任務，是搭建一個簡易的電商后臺，發送指令后，我們刻意使了點壞，在GLM-5.1快寫完項目的時候把網給掐了，并關閉了現有的上下文窗口。重啟Claude Code之后，再讓它根據之前的項目文件繼續開發。
GLM-5.1沒有被這一小插曲影響。在告訴它原項目的地址后，GLM-5.1花了3分鐘梳理了這個項目的后端部分，然后開始補齊前端缺失的代碼。
理解遺留代碼是開發的前提，理解程度直接影響著后續的開發質量。在GLM-5.1輸出的前端設計框架中，可以看到它對原本的后端代碼分析十分到位，不僅準確識別了Express 5+SQLite的技術棧，還敏銳地發現了后端缺少全局支付列表接口這一設計缺陷，并據此提出了“訂單列表+展開行加載支付記錄”的解決方案。
這得益于GLM-5.1更好的狀態延續與上下文整合。面對長時間跨度和大量上下文信息，GLM-5.1能穩定地追蹤已完成的內容、當前所處階段和下一步關鍵動作，持續整合新信息，保持執行鏈路的一致性。
在即將完成開發時，GLM-5.1在我們沒有要求的情況下，主動檢查了后端的API路徑，并發現并逐一修復了5個問題。這種“實驗→分析→優化”的閉環，正是GLM-5.1能在長任務中始終保持方向不偏、質量統一、無需人工頻繁糾偏的重要原因。
最終，GLM-5.1交付了這一電商后臺項目，核心功能運轉正常，還將后臺數據進行了可視化。不過，我們刻意人為動手修改了中文字符的編碼，讓這一電商后臺的中文字符顯示為小方塊。
為排查這一問題，GLM-5.1進行了29次工具調用，主要都是閱讀文件，多工具協同效果穩定。最后，它發現數據庫中多處中文字段都是亂碼（GBK編碼被錯誤當UTF-8存入），于是很快進行了修復?？梢哉f，GLM-5.1在多輪工具調用和長上下文場景中，表現出工程師般的自主診斷和修復能力。
經歷這兩個小插曲，GLM-5.1用大概45分鐘的時間完成了整個項目的開發，修復后的結果如下。
它交付了整整兩個文件夾的成果，算上代碼、組件庫等等，有數百個文件，大小也來到了40多兆。
拿到同樣任務的Opus 4.6，交付的結果如下：
從結果上來看，即便是我們人為給GLM-5.1上強度，它交付的結果也和Opus 4.6的結果保持在相似的水平線上。在保持原有功能、優化代碼結構等多重任務中，GLM-5.1仍然完成了高質量的方案設計與執行，充分驗證了其在復雜開發和維護任務中的工程化能力。
03.
結語：開源模型長程任務能力突破
從“回答問題”到“交付項目”
頂尖開源模型，正極大地拉近與閉源模型的差距。長程任務是Claude引以為傲的能力之一，模型不僅要會寫代碼，還要像人一樣在數小時內保持目標感、處理意外、自我糾偏、并堅持到最后一刻。
過去，這一直是閉源模型的護城河，也是開源模型難以逾越的分水嶺。
智譜稱，GLM-5.1是全球第一個在真實工程任務中驗證了8小時持續工作能力的開源模型。同時，我們的實測也顯示，GLM-5.1不是靠“更長的上下文窗口”去死記硬背，而是真正學會了“規劃→執行→檢查→修復→交付”的完整工作流。
大模型正在從“回答問題”走向“交付項目”。在這一方向上，GLM-5.1已具備了在真實、混亂、長周期的工程環境中，獨立承擔任務的底氣。
