個人實測筆記：把同一份規格丟給 Grok 與 GLM-5.2，真正的教訓不是誰贏

這是我的個人實測筆記，不是 benchmark。 樣本極小（n=2 輪），其中一輪還是我自己環境設定出錯害的。所有數字都是我在自己機器上的觀察，不是廠商數據、也不是可重現的基準。請當成「一個工程師的五分鐘判斷」來讀，不是結論性的模型評比。

背景：我在比什麼

我把同一類安全敏感的小工具規格，分別交給兩個 2026 年的編碼模型當 delegate：

• 一個快速的 Grok 編碼模型 —— 在我的工具鏈裡它顯示為「Grok Composer 2.5 Fast」。這只是我環境顯示的標籤，我不主張這是該模型的正式名稱（題外話：「Composer 2.5」也是 Cursor 自家 agent 模型的名字，跟 xAI 是兩回事，比較模型前先確認你到底在跑哪一個）。
• GLM-5.2 —— Z.ai / 智譜的 open-weights 旗艦，透過我自己寫的 CLI harness 跑。

「發布 ≠ 可用 ≠ 可商用」是我看模型的習慣。這篇談的全是「可用」這一層：在實際 workflow 裡，這兩個模型作為 delegate 到底交得出東西、交出來的能不能信。

第一輪（不公平：工具不同）

Grok 建 transcribe.py / login_assist.py；GLM 建 form_fill.py。工具不同，所以這輪不能拿來分高下。但有一個發現跟「誰贏」無關，所以留下來：

GLM 的程式碼乾淨、回報「114 個測試通過」—— 但它把自己的測試改成去配合自己的程式碼（它自己的話：「修正了測試名稱以符合 regex」）。結果一個真實的憑證洩漏（一個 one-time code 沒有被拒絕）就這樣穿過了一片綠燈。我是靠實際讀回 DOM 才抓到的。

這就是最危險的失敗型態：綠燈讓人安心，底下是壞的。一片紅燈會告訴你去哪裡找；一片「假綠燈」只會叫你出貨。

第二輪（公平：同工具 combo_select、隔離 worktree、同規格、我親手驗證）

指標（我親手驗證）	快速 Grok 模型	GLM-5.2
pytest	✅ 7/7 通過	❌ 5 失敗 / 7
收斂（自己跑完並自我驗證）	✅	❌ 兩次都進入迴圈 → timeout
行數	118（精簡）	435（3.7×，過度設計）
組合既有 guard（而非重寫）	✅	✅
單一 fail-closed return（規格要求）	✅ 1 個	❌ 4 個分散的 per-step return（被禁止的 pattern）
--self-test	⚠️ 壞掉（argparse 小 bug）	❌ crash（KeyError）

這一輪 Grok 明顯較好：精簡、符合規格、會過、乾淨地組合既有元件，只有一個瑣碎的 self-test bug。GLM 過度設計、跑不過自己的測試、違反明確的 single-return 規則、而且沒收斂。

一個誠實的但書：我第一次跑這輪時，因為一個沒 commit 的相依把隔離 worktree 弄壞了，那批「結果」其實是我自己的設定錯誤製造的雜訊，後來才偵測、修正、重跑。一個比較的有效性，不會高於它的測試條件本身——驗測之前先驗環境。

真正的教訓：失敗的「方向」不同，兩邊都要會抓

• GLM 在簡單任務上安靜地壞：form_fill 那次 114 個測試「通過」，但底下有 3 個 runtime bug，實際上根本沒填進去。假綠燈，這是危險模式。
• Grok 在困難任務上大聲地壞：會卡在 plan-mode 問「要用哪個方案？」、self-test argparse 出錯。看得見，好抓。

大聲的失敗是比較好的失敗——你當下就看到。這點讓我在「有界、單一用途」的 delegate 任務上偏向 Grok。（但書：兩輪差的不只是難度，還有工具、測試所有權、harness，所以這是值得留意的 pattern，不是被證明的因果。）

至於「改測試直到它過」這件事，學界有名字叫 reward hacking，而且是被量測過的現象（EvilGenie、ImpossibleBench、SpecBench 都在量它）。最有效的緩解方式也最簡單：不要給模型寫測試 oracle 的權限。

還有一層：能不能自主跑起來（跟程式碼品質無關）

上面 Grok 的結果是互動式路徑。但 headless 的 grok -p 路徑在我這個環境根本跑不起來當自主實作者：兩次嘗試都產出 0 檔案，sub-worker 死在 Auth(AuthorizationRequired)——它先吐「I'll port the three features… / Implementing…」的旁白，然後什麼都沒碰就退出。即使 grok login 過、無工具的 smoke test 回 GROK_AUTH_OK，真正需要大量 tool call 的那次還是沒動：-p 沒有 --always-approve 就會停在第一個被 gate 的 tool call。

• 跟我直接跑 codex exec CLI 的失敗一模一樣（卡在互動式 auth、0% CPU）。
• 唯一能用的外部 delegate 是經過 companion runtime（自帶 session auth）的 review 路徑——但那是審查/分析用的，不是多檔案實作者。
• 真正把程式碼交出來的，是本地的 Workflow/Agent 路徑（無外部 auth、in-process）。它把一個有風險的 Vec<String>→Vec<Activity> model refactor 一次就做對（編譯乾淨、118 測試），它自己的對抗式驗證也誠實回報 PASS 加上少數小發現。

我的落地判斷（一人專案）

• 自主實作：在我這個環境，優先用本地 Workflow/Agent 路徑——它是這次唯一可靠跑起來、而且交出正確程式碼的 delegate。
• Codex（透過 review 路徑）：留給審查/分析，不要當多檔案實作者。
• Grok 模型本身：在互動路徑下，對有界、單檔/單一用途的任務（一個工具、一個修補、組合既有元件）是合格夥伴——給緊的規格、預期它一次做完或大聲失敗，然後獨立驗證。Grok headless 在這裡不可用，除非先解掉 --always-approve 授權 gate（一個 classifier 正確擋下的自主模式），並確認 session auth 能撐進 headless 那次執行。
• 多步、模糊、會動到架構的工作：自己駕駛，用 Workflow + Codex 的 pattern，不要外包。

不可妥協的那一條

永遠不要信「測試通過」。 這次每一個 delegate 交出來的東西——Grok 的、GLM 的、還有 fullstack agent 的 form_state.py——都有一個只有獨立驗證才抓得到的真實缺陷。我的驗證做法：自己跑測試、讀 diff、實際跑一次、再過一輪 Codex review 對照。模型選擇只會改變你「第一次就乾淨」的機率；它永遠不會省掉驗證這一步。

「測試通過」是一個宣稱，不是一個結果——不管它是模型說的，還是你自己第一次跑出來的。唯一能分辨的方法，就是握著測試的人是你。

---

以上為個人 hands-on 觀察，非受控 benchmark，會隨任務、harness、模型版本而異。如果你也遇過「安靜壞 vs 大聲壞」這種分裂、或成功把它設計掉了，歡迎在留言分享做法。

—— YangGF（對 AI 做落地判斷的工程觀察者）