個人實測筆記：把同一份規格丟給 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 明顯較好：精簡、符合規格、會過、乾淨地組合既有元件，只有一個瑣碎的 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 加上少數小發現。

另一個用法：Grok 當「獨立驗證者」表現很好（跟它當實作者是兩回事）

後來我給同一個快速 Grok 模型一個唯讀的驗證任務：核對三個已實作功能 + 四個先前 code review 的發現 + 幾個 cross-cutting 檢查，並把測試套件跑起來。這次它明顯強：

• 守住唯讀：照指示用 plan 模式，跑了測試但一個檔案都沒改。
• 引用精準：每個結論都附確切的 檔名:行號，可驗證、不打高空。
• 是真的讀懂程式碼：對其中一個發現，它解釋了「為什麼安全」（只在 \n 字元邊界切片、小寫只用於 starts_with 而不影響 offset）——這是理解，不是在 echo prompt。
• 誠實校準：被告知「全對就說全對，不要硬找問題」時，它回「沒發現問題」，而不是捏造一個。唯一注意到的（一段顯示文字的欄位順序）也正確歸類為非缺陷。這正是 GLM 那種「假綠燈」的相反面。

所以在我的觀察裡，Grok（互動路徑）不只是有界的實作者，也是個可靠的唯讀審查/驗證者。

兩個操作上的限制要記著：(1) 這個 composer 模型拒絕 reasoningEffort（回 HTTP 400）——沒有 --effort 旋鈕可以為更難的設計任務調高推理深度，你拿到的是它固定的模式（驗證夠用，深度設計是個限制）；(2) 不好驅動——只有那個精確的 headless 呼叫（--single/--prompt-file）會吐東西，很容易誤用成「靜默的空輸出」。順帶一提，這次「fast」這個品牌在 wall-clock 上沒看到優勢（這是個重任務：讀約十個檔 + 整包編譯 + 跑測試）。

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

• 自主實作：在我這個環境，優先用本地 Workflow/Agent 路徑——它是這次唯一可靠跑起來、而且交出正確程式碼的 delegate。
• Codex（透過 review 路徑）：留給審查/分析，不要當多檔案實作者。
• Grok 模型本身：在互動路徑下有兩個合格用法——(a) 有界實作者：單檔/單一用途的任務（一個工具、一個修補、組合既有元件），給緊的規格、預期它一次做完或大聲失敗，然後獨立驗證；(b) 唯讀審查/驗證者：精準的 檔名:行號、真讀懂、誠實回「沒發現問題」（用 plan 模式跑）。限制：沒有 --effort（composer 拒絕 reasoningEffort）、headless 呼叫脆弱、重任務沒有速度優勢。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 做落地判斷的工程觀察者）