先講一個讓我卡很久的矛盾。
如果你只看 benchmark，Gemini 3.1 Pro 在 SWE-bench Verified 上一度衝到 80.6%、登上榜首，把同期的 Claude 和 Codex 壓在下面，而且還是這群前沿模型裡最便宜的。照理說，這應該是個寫程式的猛獸。
但你只要打開 Reddit 的 r/ClaudeCode、r/GeminiCLI，或者 gemini-cli 的 GitHub issue 列表，畫風完全相反：「Gemini CLI is a joke」「hot garbage and slow」「把我的 repo 搞得一團亂」。同一個模型，數字漂亮到不行，口碑卻被踩在地上摩擦。
這個落差本身才是真正的故事。我花了幾輪搜尋、把社群論據跟官方工程文件交叉比對之後，結論很清楚：大家罵的「Gemini 寫程式爛」，九成歸因歸錯地方了。 問題幾乎不在模型腦力，而在三層完全不同的東西。這篇就把它一層一層拆開。
先別急著罵模型：benchmark 上 Gemini 根本沒落後
我們很習慣把「寫程式強不強」濃縮成一個 SWE-bench 分數。那就先看分數。
| 模型 | SWE-bench Verified | 備註 |
|---|---|---|
| Gemini 3.1 Pro | 80.6% | 首個破 80%，曾居榜首；sparse MoE + Deep Think |
| Claude Opus 4.5 / 4.6 | 76.2% ~ 80.8% | 多次與 Gemini 互換第一 |
| GPT-5.2 / 5.3 Codex | 71.8% ~ 80% | Codex 路線 |
| Claude Opus 4.7（較後期） | 87.6% | 這時才真正拉開差距 |
（數字跨來源略有出入，因為 SWE-bench 受 scaffold、抽樣影響很大，這裡看趨勢就好。來源：Vals.ai SWE-bench 榜 、Vellum 、Composio 。）
看出問題了嗎？除了 Claude 後期的 Opus 4.7 真的甩開一截，其餘時間這三家根本是貼著打。更尷尬的是，多份 2026 的排行榜——像 Morph 、Medium 的年度排名 ——都把 Gemini 3.1 Pro 封為「frontier 上的性價比之王」，還酸 Opus 的溢價是「為了 0.2 分 SWE-bench 多付你 2.5 倍」。
連 Real Python 在 比較 Gemini CLI 和 Claude Code 時都點出一個很刺的事實：Gemini 用免費層級的模型，在 SWE-bench 上硬撼 Claude 的付費旗艦，還撐得住。
所以「Gemini 模型不會寫程式」這句話，數據根本不支持。可是體感落差又真實存在——那它到底落在哪？
真正的災難在終端：Gemini CLI 的可靠度崩壞
落差在工具。準確說，是在那個包住模型、幫它讀檔、改檔、跑指令的東西——agentic CLI。社群罵的幾乎全部集中在這一層，而不是「模型懂不懂程式」。
最致命、也最一致的抱怨是無限迴圈。這不是零星個案，是系統性的。你去翻 google-gemini/gemini-cli 的 GitHub issue，loop 相關的 bug 一整排，很多都被標成 p1：
- #2201 ：編輯檔案時，反覆讀同一個檔、套用同一個會失敗的 replace，無限重試、沒有退出條件。
- #8237 ：「偵測到潛在迴圈」的硬性中斷反而誤殺合法的重複性任務，整個 session 卡死。
- #22141 ：處理一個小改動花了一小時以上；光回答「你用哪個模型」就要 13~14 分鐘。
最有畫面的是 acusti.ca 紀錄的那次：Gemini CLI 到最後卡在輸出「I'm done.」「I'll stop.」「Done.」，同一句變體重複了 42 次 ，直到 CLI 自己跳出「A potential loop was detected」才強制停下。夭壽，連「我做完了」都能講 42 遍還停不下來。
這裡有個很關鍵的細節：Google 的解法是事後加一個「偵測到迴圈」的硬煞車。這恰恰暴露了問題——它沒辦法讓 agent 從根本上自己收斂，只能在外面裝個攔截器硬擋。issue #8237 的抱怨就是這個煞車太粗暴，連正常的批次編輯都被當成迴圈砍掉。
第二類災難是檔案編輯不可靠。#6443 裡開發者紀錄了完整的崩壞鏈：「我反覆用 replace 工具但 old_string 不對，工具失敗後我又對檔案狀態做了錯誤假設」，最後 Gemini 連自己跟使用者的改動一起刪掉。r/ClaudeAI 那串「Gemini CLI is a joke 」裡有人講得很傳神：「就算用很強的 2.5 Pro，它還是把我的 repo 搞得一團亂。」
對照 Claude Code 並排測試的評價（r/ClaudeCode ）：「Claude 安靜地在 reasoning 重的任務上勝出——更乾淨的 refactor、更敏銳的 edge-case、更好的 repo 級理解。」差別不在誰比較聰明，在誰做事比較可靠、會收尾。一個是資深工程師，一個是有時候會發瘋、把介面越改越爛的實習生。
為什麼會這樣？因為「Harness 即產品」
這才是整件事最核心的解釋，而且它有官方文件、學術論文、業界大佬部落格一起背書。
過去一年業界冒出一個共識：前沿 coding 模型，是「針對自己的 harness 共同後訓練」出來的。 Harness 就是那層包在模型外面、定義它能做哪些動作（讀檔、bash、規劃、派 subagent）的執行框架。業界普遍推測，Claude 的 agentic 後訓練是繞著 Claude Code 在調、GPT-5 Codex 是繞著 Codex 在調——模型和工具綁在一起、共生演化（這點各家沒有完整公開細節，但從行為與多位研究者的分析高度一致）。Addy Osmani 和 HumanLayer 都把這點講得很直白：模型會針對 harness 設計者認為它該擅長的動作變強 。
這個共生關係有多重要？有人量化過：Claude Opus 4.7 從原生的 Claude Code harness 換到 Cursor 的 harness，functionality 就從 87.2% 跳到 91.1%——模型沒變，只換了外面那層工具（MindStudio ）。SWE-agent 的研究也顯示，光是把 tool-schema 設計好，固定模型也能大幅拉高 benchmark。換句話說——工具層的權重，在 agentic 場景下不輸給模型本身。
Anthropic 自己的工程文章 〈Effective harnesses for long-running agents〉 講得更白：即使是 Opus 4.5 這種前沿模型，丟進 Agent SDK 裡跑迴圈，如果只給它一句高階 prompt，它照樣蓋不出 production 級的 web app——你需要 compaction、context reset、handoff artifact 一大堆 harness 工程把它撐住。
▲────────── 回頭訓練 ──────────┘
（模型與工具層之間還有一條「共同後訓練」的虛線：兩者一起演化）
這就是 Anthropic 和 OpenAI 的飛輪：模型↔工具共同訓練，再用真實使用的 telemetry 回頭餵下一代。Google 呢？它的模型是「從頭為多模態打造」的通才——r/GeminiCLI 上最高讚的解釋一針見血：「因為它們的造法不同，Gemini 是樣樣通、樣樣鬆 （jack of all trades, master of none）。」agentic tool-use 那條 loop 的後訓練與工具成熟度，Google 起步就晚，飛輪也轉不起來。
Google 的組織病：一手好牌打成碎片
技術解釋之外，還有一層是組織的。這部分連主流媒體都看不下去了。
Google 最大的毛病是產品碎片化。Anthropic 就一個 Claude Code，OpenAI 就一個 Codex，目標明確、火力集中。Google 呢？同時養了 Gemini CLI、Gemini Code Assist、AI Studio、Firebase Studio、Jules、Antigravity——一桌子菜，每個都做一點點不一樣的事。獨立顧問 Martin Alderson 在 〈What's going on with Gemini?〉 直接用 smorgasbord（大雜燴）形容，還補了一刀：「我幾乎遇不到任何開發者日常在用 Google 的 SWE 工具。」
洛杉磯時報 的標題更不留情面：「Google 的內部鬥爭，正把 AI coding 競賽拱手讓給 Anthropic 和 OpenAI。」報導點名 Google 用 24 億美元的授權費與薪酬，從 Windsurf 取得核心人才與技術（典型的 acquihire 結構），結果 Jules 的負責人 Kathy Korevec 沒多久就跳槽去了 OpenAI。
而這個碎片化會自我惡化，Martin Alderson 點出最致命的一環——訓練資料飛輪。Claude Code 和 Codex 每天產生海量的真實 agentic 編碼 telemetry，回頭餵養下一代模型；Google 因為沒人用它的工具，就拿不到這桶燃料。沒人用 → 拿不到 telemetry → 下一代 agent 行為改不好 → 更沒人用，這是會複利的劣勢。
他還補了一個很犀利的觀察：Google 內部用的是一套極度客製的源碼控制、build、測試、部署系統，「當你習慣用 Google-scale 的方式想事情，就很難理解業界其他人到底怎麼寫程式」——所以它難以為「一般開發者」設計出順手的 agentic 工具。
如果你想要一句總結，r/google_antigravity 上那串「Anthropic 和 OpenAI 怎麼把 Google 打這麼慘 」的神比喻最到位：
如果 AI 智能是引擎、工具整合是傳動系統：Google 造了更好的引擎，Anthropic 造了更好的車，OpenAI 造了更好的賽車變速箱。 Gemini 有極強的原始大腦，卻完全缺乏可靠驅動工具、讀檔案系統、在 IDE 裡執行程式的「傳動系統」……你是在用法拉利引擎犁田。
最能說明這團混亂的，是一個正在發生的事件。2026 年 5 月的 Google I/O 上，Google 宣布 Gemini CLI 和 Code Assist IDE 擴充將在 6 月 18 日停止對 Pro／Ultra／免費用戶服務 ，全部要遷到新的 Antigravity CLI——一個閉源、用 Go 重寫、發布時還沒有 feature parity 的東西。用開源換閉源、功能還沒齊就逼遷移，AI Builder Club 的遷移指南 乾脆直接建議：個人開發者終端工作流就用 Claude Code，要全開源就用 Aider。自家工具的遷移指南把用戶推給對手，這畫面有夠尷尬。
等等，先別把 Gemini 寫死
罵了這麼多，得講句公道話——Gemini 完全不是沒救，而且把它寫死的人很可能會踩到自己的臉。
第一，便宜、快、context 大這幾張牌是真的硬。Gemini 是前沿模型裡的性價比之王、支援 1M context、多模態，前端／UI 生成出來的東西常常漂亮到不行，Web 版體驗也很順。r/GeminiCLI 有句話很實在：「Gemini 免費，你贏不了免費。」
第二，口碑正在回升。前面那些迴圈災難很多是 2.5 Pro 時代的事。到了 Gemini 3 Pro，Shipyard 在 2026 年 4 月的比較 反而觀察到：「很多用戶覺得 Gemini 3 Pro 比 Claude 更少卡住，更能自己跳出無效迴圈。」注意，這跟前面的舊抱怨剛好相反——這代表 Google 確實在補洞，落差在縮小。而且要公平地說，loop 不是 Gemini 的專利，r/Anthropic 上也有人抱怨 「Claude Code 一碰到複雜邏輯錯誤或 race condition 也會 loop」，只是程度差異。
第三，Google 手裡握著一張別人沒有的牌：自研 TPU。Martin Alderson 的分析很有意思——Gemini 3.5 Flash 跑到 206 tokens/sec，比同期的 Opus 4.8、GPT-5.5 快了大約 4 倍，單位推論成本極低，因為模型和 TPU 是 Google 內部一起設計的。從這個角度看，Gemini 與其說是輸給對手的開發者工具，不如說它根本是「在玩另一場遊戲」：模型很大程度是為 Google 自家海量內部 token 消耗（AI mode、Gmail）而調的。如果哪天它把 agent 那條故事理順，底層的矽晶＋研究＋整合會讓它非常難纏——「但那是個大大的 if」。
所以真要落到「我現在該用哪個」，我會這樣切：
| 你的需求 | 建議 |
|---|---|
| 要可靠的終端 agent 工作流、多檔 refactor | Claude Code / Codex CLI（現階段首選） |
| 預算敏感、大量批次、超長 context、前端 UI、多模態 | Gemini 3.x（性價比最佳） |
| 想兩邊通吃 | Claude 規劃＋code review，Gemini 大量實作；或 Gemini 分析產報告 → Claude 執行 |
| 你還在用 Gemini CLI | 注意 6/18 停服，評估遷 Antigravity CLI 或改用 Claude Code / Aider |
結語：罵之前，先分清楚你在罵哪一層
回到開頭那個矛盾。Gemini 的分數和口碑為什麼差這麼多？因為大家把「模型腦力」「工具可靠度」「組織策略」三件事揉成一句「Gemini 寫程式爛」。
拆開來看其實很清楚：模型那層 Gemini 沒輸，甚至更便宜；真正崩的是 agentic CLI 的可靠度，而它的根因是「模型沒跟工具共生後訓練」這個結構性差距，再被 Google 自己的產品碎片化雪上加霜。
這對我們最大的啟發其實是：在 agentic 時代，harness 跟模型一樣是產品的一半。 下次你覺得某個 AI 工具「很笨」，先停一下——你罵的到底是那顆腦，還是包在外面那層手腳？這兩件事，修起來完全不一樣。
如果你手上同時開著 Claude Code 和 Gemini，不妨拿同一個任務並排跑一次，你會很快親身體會「分數接近、體感天差地遠」是什麼意思——而那個差，正是 harness 的差。至於 6/18 之後 Antigravity 能不能把這層手腳補起來，會是接下來半年最值得盯的指標：Google 的引擎從來不是問題，問題一直是它願不願意專心把車造好。
參考資料
- Vals.ai — SWE-bench Verified 榜
- Anthropic — Effective harnesses for long-running agents
- Martin Alderson — What's going on with Gemini?
- LA Times — Google's internal struggle is handing the AI coding race to Anthropic and OpenAI
- Addy Osmani — Agent Harness Engineering
- MindStudio — Agent Harnesses Beat Model Upgrades
- The New Stack — Google pushes users from open-source Gemini CLI to closed-source Antigravity CLI
- Shipyard — Claude Code vs Gemini CLI: Who is winning in April 2026?
- acusti.ca — Endless Loops in the Gemini Coding Agent CLI
- Real Python — Gemini CLI vs Claude Code
- GitHub Issues: #2201 、#6443 、#8237 、#22141
沒有留言:
張貼留言