開源界的里程碑：GLM-5.2 在實際任務中超越 Opus 4.8

近日，在一場針對 AI 輔助編程能力的測試中，GLM-5.2 模型展現出了驚人的實力。這場測試並非普通的代碼挑戰，而是一個特意設計成“AI 抵抗性”的後端編程作業，要求開發者將三個現有開源項目（offmute、meeting-diary 和 ipgu）的功能整合成一個統一的流水線。測試結果顯示，GLM-5.2 僅通過一次嘗試就生成了比 Opus 4.8 更高質量、更易維護的代碼，其轉錄和説話人識別準確度也更為出色。

基於這一成功，作者正式發佈了 offmute-v2，一個完全開源的新一代轉錄工具。它巧妙地將常規語音轉文本（STT）模型與多模態大語言模型（LLM）結合起來，能夠生成時間戳準確、帶有説話人標記的轉錄文本，並且可以在任何環境下運行，甚至包括瀏覽器。offmute-v2 不僅比前代版本更精確、格式更優，而且成本更低，堪稱“非氛圍式”的工程成果。

測試的細節頗為有趣。作者為 GLM-5.2 和 Opus 4.8 提供了完全相同的提示文件、兩個測試錄音（一個嘈雜的講座和一個多人播客），以及人工校驗的轉錄樣本。兩個模型均在 Claude Code 環境下執行，以消除框架差異。結果顯示，GLM 版本初次使用僅有一個可修復的緩存 bug，而 Opus 版本則存在音頻文件兼容性問題。整體而言，GLM 的輸出質量、代碼風格和指令遵循程度都更勝一籌。

在技術層面，兩個模型不約而同地採用了相同的核心策略：讓多模態 LLM 負責內容（原文、語氣、説話人切換），讓 ASR 模型提供精準的時間戳，然後通過 Needleman-Wunsch 全局比對算法將兩個輸出融合。這是一個經典的動態規劃方法，用於匹配兩個序列，在這裏就是視頻文字流和聲學文字流。有趣的是，Opus 的代碼註釋中聲稱使用了“Hirschberg-free 帶狀變體”來優化大規模輸入，但實際代碼並未實現該優化——註釋與代碼不符，這恰恰是隻有人工審查才能發現的典型問題。

成本方面，GLM-5.2 共消耗約 2.09 億個 token，而 Opus 4.8 消耗約 2.866 億個，其中大部分是緩存讀取。GLM 在 token 使用效率上略佔優勢。

作者強調，這項測試設計的初衷是獎勵正確使用 AI 並懲罰濫用。如果開發者採取“氛圍編碼”（vibe-coding），即將大部分工作交給 AI 而不加審查，代碼中很容易出現各種奇怪的漏洞，例如提示詞被隨意生成、依賴項混亂、處理測試數據過於簡單等。offmute-v2 的成功正是建立在結構化數據和格式化的嚴格流程之上。

儘管 offmute-v2 表現亮眼，但並非完美無瑕。兩個版本都暴露出一些初期 bug，例如 GLM 版本的緩存錯誤和不恰當的中轉目錄，以及 Opus 版本對視頻格式的過分依賴。不過，這些問題均易於修復。作者認為，這仍然是一個里程碑式的時刻：前沿能力正在開源化，任何人都可以基於最先進的模型構建自己的工具。