開源界的里程碑：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 版本對影片格式的過分依賴。不過，這些問題均易於修復。作者認為，這仍然是一個里程碑式的時刻：前沿能力正在開源化，任何人都可以基於最先進的模型構建自己的工具。