昨天，智譜上線並開源了 GLM-5.2，主打 Coding 和長程任務。官方資料十分亮眼：前端盲測 Code Arena 拿了全球可用模型第一，長程任務上整體介於 Claude Opus 4.7 和 4.8 之間，是目前排名最高的開源模型。
我們提前拿到了內測資格，這陣子一直在 Claude Code 裡拿 GLM-5.2 干長活，慢慢摸出了一套用好它 1M 上下文的方法。正好趕上正式發佈，把這套用法完整分享出來。
一、用好 1M 上下文，在完成長程任務裡很重要
評價一個 AI 程式設計助手的標準，正在發生變化。過去我們看的是它答得對不對：問題拋過去，回答精準就行。
但現在的任務複雜得多。模型要自己讀檔案、查資料、記錄決策、排查日誌，一次任務往往是幾千次工具呼叫、連著跑大半天。這種時候，單次回答的好壞已經不是關鍵，關鍵是它能不能把整件事從頭做到尾、中間不跑偏。
而要做到這點，模型得有一段足夠長、又不出錯的"記憶"。大家這兩年盯著越來越長的上下文不放，就是這個原因。
但光有 1M 沒用。窗口多大是一回事，往裡面怎麼組織資訊是另一回事，後者才真正決定效果。下面這套方法，就是我拿 GLM-5.2 用下來覺得值得分享的部分。
二、先花兩分鐘，把 1M 上下文開起來
在 Claude Code 裡啟用 GLM-5.2 的 1M 模式，配置很簡單，改一下 .claude/settings.json 就行。把 ANTHROPIC_BASE_URL 指到智譜的 anthropic 介面，再把模型名填成帶 [1m] 後綴的那個。
這裡有個容易踩的小坑：後綴 [1m] 一定要帶上，不帶的話默認還是普通上下文的長度。配好之後用 /status 看一眼，確認走的是 1M 的那條線路。
關於 [1m] 後綴的注意事項：Claude Code 走 Anthropic 介面時模型名必須帶 [1m] 後綴；如果你同時使用 Kimi Code 走 OpenAI 相容介面，則不帶後綴，避免照搬踩坑。智譜官方的接入指南對此有詳細說明。
想讓它跑長程任務，再把思考檔位調到 /effort max，需要聯網查資料的話配上 MCP。具體命令和踩坑記錄我都放在文末的完整教學裡，照著走幾分鐘就能跑通。
教學地址：https://my.feishu.cn/docx/KNeqdPly7o6iWexfRKOcTqBxnbH
開起來之後，我一開始也以為萬事大吉，把所有東西一股腦全塞進去。試下來發現沒這麼簡單：好不好用，我總結了三條經驗。
三、實測下來的三條經驗
經驗一：給模型一個固定的錨點
第一個經驗，是給模型一個固定的錨點。長任務跑到第五十步時，它常常已經忘了第二步定下的約定。
我的做法是把這些約定都寫進 CLAUDE.md：命名規則、程式碼風格、那些目錄不能碰，讓它每一輪都先讀一遍。別指望"它應該記得"，只有把關鍵資訊寫下來，它才真的記得住。
經驗二：先判斷這個任務到底要不要開 1M
第二個經驗聽起來有點反常：我大部分任務其實是不開 1M 的。窗口越大，單次成本越高、速度也越慢，不分場景一律拉滿，純屬浪費。
我自己有個簡單的判斷：看資訊密度、時間跨度、出錯代價這三樣，中了兩樣才開。改個小函數、寫個指令碼，普通上下文夠用；但要重構一整個模組、跨幾十個檔案改一套邏輯，這種活就值得把 1M 拉滿。
把這步想清楚，比無腦開大窗口有用得多。該省的時候省，該上的時候上。
經驗三：把長任務切成階段，每段留檢查點
第三個經驗，是別讓它一口氣悶頭跑到底。再穩的模型，連著跑幾十輪也可能在某一步悄悄跑偏，等你發現的時候已經錯出去很遠了。
我的做法是把長任務切成幾個階段，每跑十到二十輪，就讓它輸出一段當前狀態的摘要：做到那了、改了什麼、下一步打算幹嘛。越早發現偏差，會提前避免很多不必要的麻煩。
四、GLM-5.2 的長程任務實測
光說經驗有點空，我拿這套方法跑過兩個規模差很遠的活，正好能帶大家看 GLM-5.2 的長程能力怎麼落到具體任務上。
任務一：給學習庫補前沿資料
第一個是小任務。我本地有個"認知科學-系統學習"的項目。其中，大概的框架已搭好（四層模型 + 8 個樞紐概念），但前沿素材為空。
運行前狀態：4 個檔案，48 KB。項目有一份 404 行的學習指南markdown文件，四個檔案總共541行內容，定義了四階段學習路徑。而且在相鄰領域還有大量知識儲備：現象學、決策科學、心理學等。
我沒讓它自由發揮，而是把任務拆成五輪寫進 prompt：廣度掃描畫地圖、覆蓋率審計查漏、深度鑽取、交叉合成、最後做筆記初始化。開頭還加了第零步，讓它先把項目裡的學習指南讀完、把 8 個樞紐概念複述一遍，把後面所有動作都錨在這套已有框架上。
GLM-5.2 在一次會話裡連著把五輪跑完，全程沒觸發上下文壓縮。最後從 4 個檔案變成 31 個、48KB 漲到 230KB，產出 42 張素材卡，8 個樞紐概念全部補到"充分"以上。
我最在意的是中間兩個細節。一個是第二輪的覆蓋率審計，它自己查漏補缺：發現"馬爾三層次"和"心智模組"兩個概念一張卡都沒有，沒等我提醒就補了 8 組定向搜尋把空白填上。
另一個是寫到第五輪做交叉筆記時，它還能呼叫我另一個項目裡的現象學內容，引用了胡塞爾的意向性、梅洛-龐蒂的身體現象學。那些是第一輪就讀進去的，中間隔了 20 多組搜尋，到這會兒居然還在上下文裡沒被擠掉。跨輪不丟記憶，這正是 GLM-5.2 的1M上下文真正發揮優勢的地方。
任務二：把 3473 個檔案的知識庫重排一遍
第二個任務規模就比較誇張了：一個 134MB、3473 個 Markdown 檔案的知識庫，讓它重排整個目錄。這體量是 1M 窗口的二十多倍，不可能一次讀完。
所以這回 prompt 我拆成了七輪：骨架掃描、覆蓋率審計、結構性重組、目錄標準化、遞迴內容審計、斷鏈修復、治理標準化。關鍵是分層，前四輪只動目錄骨架，第五輪才遞迴進檔案內容，第六輪再回頭修連結，不一上來就把整庫往裡灌。
GLM-5.2 同樣一口氣把七輪跑完，全程沒要我中途確認。3473 個檔案、二十多倍窗口的活還能不斷線，靠的就是它為長程任務訓練到模型裡的能力。
md 檔案從 3473 個理到 3389 個，目錄從 1659 個減到 1382 個、少了近三百個，空殼項目從 19 個清到只剩 1 個，命名不統一的 40 多個目錄全部標準化，順手還修了三百多處斷鏈。
最能說明問題的還是第五輪。它逐個讀檔案全文做交叉比對，揪出兩個內容完全一樣的鏡像目錄、好幾對同名不同版本的檔案。這些光看檔案名稱根本發現不了，必須把內容都讀進來一個個比。這一輪最吃長上下文的環節，短窗口基本做不動。
上面這兩個任務，是我自己用 1M 上下文實打實跑過的。後來翻了翻官方放出來的案例，有幾個場景讓我印象很深。
官方給了一個硬核案例：有人用 GLM-5.2 把當年送人類上月球的登月飛控程序，從六萬五千行的老程式碼整個移植成了 Rust，一行邏輯都沒改，整個過程全靠 Agent 自主走完，沒人中途接手。
還有一個更接近日常開發：從開發、聯調、測試到打包上線，一次性交付了一個覆蓋 Web、移動端、小程序的多端應用，累計用掉 88 萬 tokens，幾乎把 1M 窗口用滿。
這種複雜任務，現在 GLM-5.2 能在一次長任務裡跑完。所以從程式碼遷移到多端交付，它的能力邊界比我用到的寬得多。
當然 GLM-5.2 也不是沒有短板。決定它上限的，其實是有效長度和連續工作能力，而不是官方說的1M上下文。上下文一長照樣會衰減，"Lost in the Middle"那個老問題，它解決了不少，但你也別指望沒有一點損失。目前來看，超長任務上GLM-5.2 還是比 Opus 4.8 低 13%。
所以實際用的時候有兩個習慣：關鍵資訊該寫進 CLAUDE.md、該重申就重申，別只靠看模型去記；聯網的 MCP 有額度，大搜尋任務挑非高峰或者分批跑。知道這些邊界，反而更清楚該把 1M 用在什麼任務上。
寫在最後：現在就能上手
GLM-5.2 已經全量開放、MIT 開源，配置就上面那一段，幾分鐘的事。完整的保姆級教學放在文末，包括怎麼改 settings.json、怎麼配 MCP、上面兩個演示的完整 prompt 和步驟，新手照著走也能跑通。
用了這陣子，我對 1M 的看法也變了。表面看它就是能多塞點東西，但 GLM-5.2 用下來讓我發現，它真正的價值是讓 AI 能連續幹得更久、看得更深、完成得更完整。
教學完整版：https://my.feishu.cn/docx/KNeqdPly7o6iWexfRKOcTqBxnbH(Datawhale)