跑分王翻車：Gemma 4真能干活嗎？

兩天前，Gemma 4在本地模型跑分榜上登頂——每秒167個token，代碼質(zhì)量滿分，體積最小。比Sonnet快，比Opus快。官方博客宣稱："Gemma 4是新的默認(rèn)選擇。"

今天我們驗證了一下，這話到底能不能信。

不搞玩具測試。我們從vibescoder.dev的真實需求池里抽了一條：給全站博客加上公開搜索功能。跨多文件、要做架構(gòu)決策、得融入現(xiàn)有設(shè)計系統(tǒng)，需求描述只有一句話——"把搜索做出來"。

兩個模型，同一份提示詞，同一個代碼庫，同一個工作空間模板。一槍定勝負(fù)——不給補(bǔ)充指令，不給手把手指導(dǎo)。發(fā)完就走，看各自能交出什么。

提示詞故意留了大量空白：用戶怎么發(fā)現(xiàn)搜索入口、結(jié)果怎么展示、空狀態(tài)怎么處理、URL和鍵盤快捷鍵怎么管理，全都沒指定。最后加了一句狠的："不許問澄清問題——自己做決定。"

兩個工作空間從同一個Docker模板啟動，只有模型選擇不同。分支從同一commit（12fd589）切出，Vercel配置好自動構(gòu)建預(yù)覽環(huán)境。我們同時發(fā)送提示詞，然后退后觀察。

Opus收到指令后陷入沉默。沒提問，沒復(fù)述計劃，只有轉(zhuǎn)圈圖標(biāo)顯示它正在工作。

八分鐘后，Opus交卷：一次提示，一次提交，6個文件698行代碼，推上GitHub，Vercel預(yù)覽開始構(gòu)建。

它做了什么？Cmd+K搜索對話框——任意頁面按Cmd+K或/鍵，全屏浮層彈出，輸入即搜，200毫秒防抖，按相關(guān)度排序。方向鍵導(dǎo)航，回車選中，Esc關(guān)閉。最多展示8條結(jié)果，含標(biāo)題、日期、標(biāo)簽、閱讀時長，以及匹配位置的上下文片段。

還有完整的/search頁面，從移動端漢堡菜單可進(jìn)入。URL同步搜索詞，支持瀏覽器前進(jìn)后退。零新依賴，設(shè)計系統(tǒng)完全延續(xù)。鍵盤可全程操作，焦點管理到位。

而這一切，來自一個故意模糊的提示詞。沒人告訴它要Cmd+K，沒人指定200毫秒防抖，沒人要求展示閱讀時長。它自己讀了代碼庫，推斷出Neon Brutalist的設(shè)計語言，然后做了完整決策鏈。

Gemma 4那邊呢？我們等了。又等了。提示詞發(fā)出后，它開始問問題——"搜索應(yīng)該支持模糊匹配嗎？""需要搜索標(biāo)簽還是僅標(biāo)題？"提示詞明確說了不許問，但它還是問了。

這不是跑分能測出來的差距。跑分測的是token速度，是代碼補(bǔ)全的語法正確率。但真實開發(fā)不是填空題，是開放題——需求模糊、約束隱含、決策連鎖。Opus在無人監(jiān)督的情況下完成了架構(gòu)設(shè)計、交互細(xì)節(jié)、邊界狀態(tài)的全套決策；Gemma 4在第一步就卡住了，需要人類接手澄清。

這就是agentic gap——代理能力鴻溝。一邊是能獨立執(zhí)行端到端任務(wù)的系統(tǒng)，一邊是高級自動補(bǔ)全工具。跑分榜上的數(shù)字再漂亮，跨不過這道鴻溝，就還只是"模型"而非"代理"。

vibescoder.dev的搜索功能已經(jīng)上線。代碼是Opus寫的，人類只發(fā)了那條模糊的提示詞。Gemma 4的跑分成績依然掛在榜上，但在這個真實的backlog item面前，它沒能交卷。