Gemini 3強的可怕，但真讓他干活兒他像實習生一樣不靠譜

最近谷歌正式發布 Gemini 3 后，其基準測試成績斷檔級領先，大家也是各種前端 vibe coding 玩得不亦樂乎。

但知危比較在意的兩個點是，一方面谷歌宣布 Gemini 3 是世界上最好的多模態模型，也強調 Gemini 3 對用戶意圖的理解，“ 無需過多提示就能獲得所需信息 ”，這就讓 Gemini 3 的 ToC 屬性變得很強。

另一方面，Gemini 3 在編程能力的基準測試上并沒有實現對其它模型的斷檔級領先（ 甚至這兩天內 OpenAI 就拿出了 GPT-5.1 Codex Max 來狙擊 Gemini 3 ），谷歌也沒有強調 Gemini 3 在幻覺、指令遵循等方面的優勢，但這些維度其實才是企業級場景最關心的，否則你在用 AI 編程的時候，不管模型多么博學多才，總會沒那么放心，就怕改 Bug、修漏洞比手寫代碼還辛苦，所以 Gemini 3 的 ToB 屬性是否夠強還有待進一步考察。

為了深度感受 Gemini 3 的 ToC 和 ToB 屬性，在本次測評中，知危著重體驗Gemini 3 的多模態理解和編程能力，至于科研能力，本次評測沒有涉及。

具體而言，在多模態理解能力方面，知危主要是讓 Gemini 3 理解視頻，包括電視劇、體育比賽、軟件操作等場景的視頻，看 Gemini 3 能理解到什么程度，幻覺多不多，是否夠專業。此外，看到 Gemini 3 在 ARC-AGI-2 上面翻倍的亮眼成績，知危也忍不住在相同場景中給 Gemini 3 再上上難度。

編程能力方面，知?；谶^去的測評經驗，會直接拿一些需求多且雜的場景讓 Gemini 3 一次做出來，如果不成功或者錯誤太大，不會給太多挽尊的機會。這些場景包括一次寫完 Excel、看 UI 截圖寫 3D 引擎、看視頻寫 3D 引擎等。知危也會在不同的平臺上都測試類似場景，包括網頁版 Gemini、Cursor 以及谷歌自己新推出的編程 IDE Antigravity。

好了，我們話不多說，測評開始！

多模態理解能力測評

其實，目前很少有 AI 模型能直接分析視頻的，國內只有通義千問提供這個功能。

我們拿《 甄嬛傳 》中最具張力的一場戲，也就是 “ 滴血驗親 ” 來測試一下Gemini 3（ 在網頁版 Gemini 中調用 Gemini 3 Pro，也就是思考模式 ）看不看得懂。因為網頁版上傳視頻有 100M 的限制，所以將視頻分成了好幾段輸入。

在第一段視頻中，皇后先向皇帝提出了 “ 滴血驗親 ” 的狠招，隨后呈現甄嬛等人的反應。

Gemini 3 的表現令人驚訝，幾乎無任何錯誤，對各個人物的動作、心思、表情，以及更宏觀的派系解析和劇情背景，都做出了非常準確的解釋。

當進一步提示 Gemini 3 做更細致的逐幀逐秒分析時，它也是不負眾望。

整整一分半鐘的視頻，真的按照幾秒一個單位來分析。

臺詞和潛臺詞都很精準，但最能展示多模態能力的，是對微表情的捕捉。比如皇后引導皇帝實施滴血驗親時，Gemini 3 描述皇后的表情動作為 “ 身體微微前傾，語重心長，眉頭微蹙，眼神看似誠懇，實則緊盯著皇帝的反應 ”，大家可以看看對不對。

再看看以下幾個精彩瞬間，動作和表情也是描述的很到位，雖然 “ 嘴唇微張 ” 等一些細節是 Gemini 3 自己加戲和夸大，“ 眼神游移 ” 應該要更后面才出現，這里更多是 “ 純粹的恐懼 ”。

只是看到分析的最后一句話，知危才意識到，Gemini 3 分明知道后面的劇情進展，畢竟 Gemini 3 的訓練數據已經包含了《 甄嬛傳 》的各種視頻、文本資料，能分析到這個程度或許并不令人意外。

而且，臺詞語音其實是很好的對齊模態，臺詞能提供精準的語義提示，并和視頻時間線做對齊，假設已經有大量文本語料給《 甄嬛傳 》做了逐幀分析，那 Gemini 3 可能很大程度上不是基于視頻來理解的。

所以，若是分析無聲音的同樣一段視頻，效果又如何呢？結果，Gemini 3 還是能認出這是《 甄嬛傳 》，以及大部分的人物，就是出現了非常大的錯誤，把甄嬛認成了華妃。

也因為這個錯誤導致對劇情的推測也產生了幻覺。

從這個結果來看，或許目前 AI 的多模態理解對文字的依賴還是比較大。

最后，因為今天 Nano Banana Pro 剛好上線，知危也在對話的末尾讓Gemini畫一幅漫畫來呈現劇情，結果還是很驚艷的（ 可能 Nano Banana Pro 太火，谷歌自己服務器撐不住了，沒實際生成圖像，最后是用 Lovart 的 Nano Banana Pro 畫出來的 ）。

這里還有一個非常離譜的地方，Nano Banana Pro 生成的這張漫畫圖，右下角甚至還有 “ 騰訊動漫 ” 的水印。。。

也不知道谷歌拿騰訊動漫練 AI 有沒有合法買數據授權，如果沒有的話歡迎騰訊聯系本編輯部搜集證據，索賠之后記得分我們點

為進一步避免模型對訓練數據的依賴，基于 Gemini 3 的知識截止日期是 2025 年 1 月，知危決定用 Gemini 3 來分析 2024-2025 賽季 NBA 總決賽雷霆 vs 步行者第一場的最后兩分鐘（ 比賽時間 ）的視頻片段（ 這場比賽實際是在 2025 年 6 月份舉行的，晚于 Gemini 3 的知識截止日期 ）。

相比電視劇，理解體育賽事有著不同的復雜度，雖然不需要關注微表情，但運動員動作大，且和籃球、其他運動員有物理交互，更有快速的空間移動和頻繁的視覺遮擋，相關訓練語料也更少，難度會更大。

在第一次的簡單分析中，Gemini 3 的回答表明了它認為這場比賽不存在，它甚至認為這是 NBA 2K 游戲的模擬畫面。當然，它準確地認出了這是 NBA 雷霆 vs 步行者的總決賽，以及一開始的賽況。

在接下來的關鍵鏡頭分析中，Gemini 3 能準確描述步行者球員的 “ 橫撤步 ” 運球動作，要知道當時的實況解說員并沒有說出這個 “ 橫撤步 ” 術語，只是 Gemini 3 把球員身份認錯了，應該是 2 號的內姆哈德而不是 23 號的內史密斯。

之后對第二回合、第三回合攻防的分析，Gemini 3 的描述都是準確無誤的，除了內史密斯的 “ 猶豫 ” 其實指的是在 “ 上籃 ” 和 “ 投籃 ” 之間的猶豫，而不是上籃之前要不要減速的猶豫。

接下來，再進行一次更細節的逐幀分析。

第一回合中內姆哈德的單打動作很精彩，所以值得再分析一次。

Gemini 3 雖然還是沒改正對身份的錯誤認識，但對動作的分析非常專業，它把剛才的 “ 橫撤步 ” 改為更精準的 “ 向右后方撤步 ”，并且球員在做撤步前，先做了向左側突破然后變向的連續假動作，這些描述并不是 Gemini 3 對實況解說的鸚鵡學舌，而是自主做出來的分析（ 這里對左右方位的定義可能和我們直觀理解上相反，但還是可以解釋通的 ）。

在第四回合雷霆的 2 號球員亞歷山大單打強攻拿回兩分，并把比分重新拉大到 105:110 后，到第五回合，對雷霆的 9 號球員卡魯索的防守策略分析中，Gemini 3 出現了嚴重幻覺。

卡魯索是在內姆哈德運球時被雷霆球員拍掉球后立馬上前搶球，并沒有出現 Gemini 3 所言的 “ 雙腳站定，雙手護胸 ” 的動作，這時裁判哨響，但在該片段內，并沒有給出裁判結果，Gemini 3 則立馬判定是內姆哈德進攻犯規。

為了再次檢驗 Gemini 3 對實況解說語音的依賴程度，知危也上傳了無聲音版本的同一片段給 Gemini 3 分析。

這一次，Gemini 3 的分析出現了很明顯的錯誤或模糊不清的情況，比如（ 00:16-00:55 ）這一段，Gemini 3 描述 “ 視頻出現剪輯跳躍 ”，但實際上在這段期間，雷霆和步行者先后進行了一次進攻未得分，最后雷霆的亞歷山大憑借單打強攻得到兩分。

并且（ 00:56-01:08 ）時間段內，被撞倒在地的球員應該是 2 號球員內姆哈德，而不是 0 號球員哈利伯頓。

但總體來看，Gemini 3 達到的準確率還是令人感到意外的，大部分情況下都能分析出是哪位球員執行了什么動作，以及對比分或比賽的貢獻。

知危接下來還將后續比賽片段（ 一直到步行者的 0 號球員哈利伯頓在最后時刻三分絕殺雷霆 ）在同一個對話中傳遞給了 Gemini 3 繼續分析，Gemini 3 結合實況解說語音還是能保持基本準確的水平，對步行者的 43 號球員西亞卡姆的高光時刻的分析很到位，并盛贊西亞卡姆給出了 MVP 級別的表現。

總體而言，Gemini 3 對體育視頻的分析掌握程度還是不如對電視劇的分析。雖然能夠基于實況解說的提示和視覺線索，給出更精細的描述和適當的宏觀分析，但幻覺率過于高，超出了實用限制。并且，在該場景也是非常依賴解說語音的，而不是原生地對視覺線索有足夠精細的理解。

最后也是用 Nano Banana Pro 畫一頁漫畫來呈現內姆哈德后撤步三分的高光時刻。這一次畫面精細度和劇情還原度也是很高，但內姆哈德相對其他球員以及在球場的空間站位呈現的不是很準確，后撤步則像是在沖浪，可能在空間智能或透視作圖方面還不是很擅長。

最后一個測試場景，是軟件操作視頻分析。

推特上有一個帖子比較火，Pietro Schirano 展示了如何用一句話讓 Gemini 3 寫一個功能完善的 3D 樂高引擎原型。

知危將這個視頻傳遞給 Gemini 3，令其分析這個引擎的 UI 組成和功能。

Gemini 3 的分析結果很精細，甚至能精準到視頻第 19 秒展現了重新上色功能，整體基本完全準確。

這個編碼案例其實很多網友并不買賬，他們自己用相同提示詞寫的 3D 樂高引擎完全不是那么回事。

所以，知危也順便將分析結果提煉成提示詞，進入下一個測評，也就是編程能力測

評。

編程能力測評

提示詞（ 基于視頻分析原文 ）：

基于Three.js、html技術，構建一款名為 "BRICK BUILDER" 的3D樂高積木構建軟件。

采用經典且直觀的 "三段式" (左-中-右) 布局，配合深色模式 (Dark Mode) 界面，旨在減少視覺疲勞并突出彩色的積木模型。

以下是對該軟件UI構成和核心功能的詳細分析：

1，頂部全局導航欄 (Top Toolbar)

這是軟件的控制中心，主要負責工具切換和項目管理。

基礎工具 (左側):

Select (選擇箭頭): 用于選中場景中的積木。

Add (加號): 默認模式，用于放置新積木。

Paint (油漆桶): 用于給已放置的積木重新上色（視頻 00:19 處展示了此功能）。

Delete(橡皮擦)：用于刪除已有積木塊。

歷史操作: 包含 撤銷 (Undo) 和 重做 (Redo) 箭頭。

項目管理 (右側):

Clear: 清空畫布。

New Project: 新建項目。

Export PNG: 將當前模型截圖導出為圖片。

Save Project: 保存當前進度。

2，左側資源庫面板 (Left Sidebar - Library)

這里是用戶的“零件箱”，用于尋找和選擇積木部件。

搜索欄 (Search): 允許用戶通過名稱快速查找特定積木。

分類標簽頁 (Tabs): 將積木部件分為 Basic (基礎磚), Plates (板件), Slopes (斜坡磚), Projects 等類別，方便篩選。

縮略圖列表: 視覺化展示積木的形狀（如 1x1, 1x2, 2x4 磚塊），點擊即可選中作為當前筆刷。

3，中央3D工作區 (Center Viewport)

這是核心交互區域，用戶在此進行搭建。

3D 網格底板 (Grid Baseplate): 提供空間參考，幫助用戶對齊積木。

智能吸附與預覽 (Smart Snapping & Ghost Preview): 當鼠標懸停在網格或已有積木上時，會顯示半透明的“幽靈磚”預覽（紅色半透明），告知用戶積木即將落下的位置。積木會自動吸附到網格點或其他積木的表面。

交互反饋: 放置積木時有輕微的動畫效果。

4，右側屬性與設置面板 (Right Sidebar)

該區域用于控制外觀、視角和選中物體的屬性。

視角控制 (View Cube/Buttons): 位于面板左上角的小圖標，允許用戶一鍵切換視圖：

3D: 自由透視視角。

TOP / FRONT / SIDE: 快速切換到頂視圖、正視圖或側視圖（視頻 00:14-00:17 展示了此功能）。

顏色調色板 (Colors): 提供預設的樂高標準色（紅、橙、黃、綠、藍、黑、白等）。用戶可以在放置前選擇顏色，或配合油漆桶工具使用。

屬性 (Properties):

Position (X, Y, Z): 顯示當前選中積木的坐標。

Rotation: 包含一個按鈕（通常是旋轉90度），用于調整積木方向。

場景設置 (Scene):

Grid: 開關網格顯示。

Shadows: 開關陰影渲染，用于提升真實感或節省性能。

5，底部狀態欄 (Footer)

提供統計信息和操作提示。

統計數據: 左下角顯示 Bricks (積木數量) 和 File Size (文件大小)。

上下文提示: 屏幕底部中間會根據當前工具顯示提示文本，例如 "Place Brick (Click to rotate)" 或 "Paint Brick (Click to select)"，這是非常好的UX設計，降低了學習成本。

6，總結與UX亮點

極簡主義: 界面沒有復雜的菜單層級，所有常用功能都平鋪在界面上，所見即所得。

清晰的邏輯: “左側選材 -> 中間搭建 -> 右側調整”的操作流非常符合直覺。

視覺輔助: 預覽（Ghosting）和網格吸附功能極大地降低了在2D屏幕上操作3D物體的難度，確保積木不會放歪。

將以上提示詞用于 Gemini 3 生成 3D 樂高引擎，如果做得好，那便是多模態理解和編程雙劍合璧。

最終實現的 3D 樂高引擎能夠成功運行，雖然沒有完全按照分析細節來實現，或者說沒有完全復刻原版，而是簡化了很多。

但至少基礎的磚塊、添加、刪除、上色、視圖、旋轉、導出等是都有的，足夠完成一個最粗糙的作品。

上面案例所采用的 Three.js 畢竟是 Javascript 的庫，如果能用純 Javascript 寫出足夠復雜的前端場景，那才更厲害，為此自然還是得測試寫一個的 Excel 原型才能讓人信服。

知危套用之前 GPT-5 在 Cursor 一次運行成功的提示詞，再次輸入到網頁版 Gemini 3 中，試圖復刻。

提示詞如下：

請幫我開發一個功能完整的網頁版Excel應用，技術棧使用HTML、CSS、JavaScript，需要實現以下核心功能模塊：

-第一階段：基礎功能（核心優先級）

網格渲染系統：

實現1000×1000單元格的虛擬渲染；

優化滾動性能，確保流暢體驗；

橫坐標（A、B、C等）和縱坐標（1、2、3等）需要與單元格精確對齊；

滾動時坐標軸與內容區域保持同步，無偏移；

單元格編輯功能：

雙擊單元格進入編輯狀態，編輯框與原單元格完全重合；

Enter鍵保存內容并向下移動到下一個單元格；

Tab鍵保存內容并向右移動到下一個單元格；

支持空值和默認值的正確處理；

編輯欄應可編輯，實時顯示和修改當前選中單元格的值；

富文本格式工具欄：

實現獨立的格式按鈕，每個按鈕狀態基于當前選中單元格的格式屬性獨立判斷；

字體大小調整；

加粗、斜體、下劃線、刪除線（按鈕狀態互相獨立）；

文本對齊：左對齊、居中、右對齊；

背景顏色設置；

一鍵清除格式功能；

UI界面要求：

頂部工具欄包含所有格式設置按鈕；

名稱框顯示當前選中單元格坐標（如A1、B2）；

編輯欄顯示并可編輯當前單元格內容；

整體界面美觀，具有現代化設計風格；

-第二階段：高級功能（擴展功能）

行列操作：

點擊行號后，按"="鍵在下方插入新行，按"-"鍵刪除當前行；

點擊列號后，按"="鍵在右側插入新列，按"-"鍵刪除當前列；

刪除后自動重排坐標編號，保持連續性；

添加最小保護機制，避免刪除最后一行或列；

復制粘貼操作：

實現Command/Ctrl+C（復制）、Command/Ctrl+X（剪切）、Command/Ctrl+V（粘貼）快捷鍵；

支持單元格內容和格式的復制粘貼；

支持行列的整體復制粘貼操作；

撤銷恢復系統：

實現Command/Ctrl+Z（撤銷）和Command/Ctrl+Y（恢復）功能；

維護操作歷史棧，限制最大100層以控制內存；

頁面刷新時清空操作棧；

選擇功能：

支持單元格多選（拖拽選擇矩形區域）；

支持整行、整列選擇；

選中狀態的可視化反饋；

-第三階段：完善功能（產品化）

數據導入導出：

支持導出為CSV格式文件；

支持導出為JSON格式文件；

確保導出的文件能在Microsoft Excel中正確打開；

UI美化優化：

添加滾動動畫效果；

優化陰影和漸變效果；

提升整體視覺體驗和交互流暢度；

響應式設計，適配不同屏幕尺寸；

但最終寫出來的 Excel 有一堆 Bug，比如字體格式有時能用有時不能用，文本對齊、復制剪切功能也有各種意想不到的問題，簡直是災難現場，不如上次對 GPT-5 的測試 ( 傳送門 )。

知危懷疑是網頁版 Gemini 的 Agent 能力不足，就切換到谷歌新推出的編程 IDE Antigravity，用相同的提示詞來測試。

結果，寫出來的網頁版 Excel 完全無法交互，鼠標點擊沒有反應，也不能輸入，甚至不能顯示單元格，應該說比網頁版表現還差吧。

為了再給它一次機會，我提示它自行檢查并修復。

第一階段：基本功能

發現一個錯誤，即單元格編輯器和選中高亮顯示會在滾動時與網格分離，因為它們位于視口容器而非內容容器中。已將它們移至正確的容器。

但它發現的錯誤和單元格相關，這并不是最關鍵的，甚至實際界面中都看不到有任何單元格。

接下來，知危極大降低了要求，只讓 Antigravity 寫了一個《 2048 》游戲，看看產品本身是否有問題。

測試發現游戲能運行，視覺效果也很好。

但 Agent 運行有一些問題，會無限期的停留在測試階段。

到此，只能認為 Antigravity 作為編程 IDE 產品還不夠成熟完善。為了最大程度發揮 Gemini 3 的編程水平，知危決定在 Cursor 上測試。

果然，在 Cursor 上調用 Gemini 3 Pro，就能用相同提示詞順利完成 Excel 原型的開發，而且也是一次成功。

目前為止，知危拿這個案例測試過很多大模型，只有 GPT-5 和Gemini 3 Pro 是能一次成功的。在 UI 審美上，Gemini 3 Pro 比 GPT-5 更好。

但接下來的測試再次讓知危大跌眼鏡。

還是緊接前面提到的 3D 樂高引擎案例，我們在 Cursor 上再試一遍，因為 Cursor 無法輸入視頻，所以只用了 UI 截圖。

第一次嘗試，讓 Gemini 3 Pro 參考 3D 樂高引擎的UI界面截圖來開發。

結果還是依樣畫葫蘆寫了個不能交互的網頁。

知危給了它最后一次機會，將前面在網頁版 Gemini 3 分析推特視頻后得到的提示詞，再一次提供給 Cursor 中的 Gemini 3 Pro，結果這個網頁仍然是不能交互的。

到此，基于這些實測結果判斷，Gemini 3 的編程能力還是能達到頂尖水平，也有足夠的代碼審美，但發揮是不夠穩定的，不管是幻覺率還是對指令遵循的細致全面程度，還沒有達到業內最高水平。

前面因為分析 3D 樂高引擎視頻被帶進了編程能力測評的坑，但多模態理解測評的難度還沒真的上來，我們繼續這個維度的測評。

為了提高多模態分析的難度，自然還是要上 ARC-AGI-2 這個測試集，畢竟 Gemini 3 在這個基準測試集中的提升幅度是最大的。

但知危不是拿公開的評估集來再測一次，測試設置需要針對多模態這個屬性做一些調整。

ARC-AGI-2 的官方發布使用 json 表示二維網格，例如下圖是該項目的 GitHub 中包含的一個評測集中的數據部分展示：

樣本：e376de54.json，來源：https://github.com/arcprize/ARC-AGI-2/blob/main/data/evaluation

通過順手 vibe 一個小型程序可以將這個矩陣轉換成圖像（ 每個數字代表在圖像中的坐標和顏色 ），如下圖所示：

知危不想按照官方設置使用 json 為輸入，而是要以圖像作為輸入傳遞給 Gemini 3，并且為防止大模型吸收基準測試數據作為訓練數據取巧，會對這個評估集樣本再做一些微調（ 修改 json 數據再轉換為圖像即可 ）。比如下圖中，左圖是原評估集樣本，右圖是微調后的樣本，黑邊與數據無關可忽略。

按這個思路，知危制作出了兩個新的謎題。這是第一題：

下圖是準確答案，應該按照排第二的長度值重組所有斜線。

Gemini 3 的分析框架是對的，但得出的結論卻是：取最大長度統一（ 無法理解，真的就差一點點啊 ）。

在下一道題中，知危對原評估集樣本做了如下改動（ 樣本：247ef758.json ）：

這是第二道題的完整呈現：

下圖是準確答案，方框的四條邊上如果有某個顏色構成十字相對方位，該顏色對應的方框外幾何素材就可以放入方框內十字交叉點的位置。這里因為微調了顏色，第四組的藍色幾何素材也要放入方框內。

Gemini 3 有理解到規則是對左側素材的篩選，但錯誤地把篩選規則理解為基于素材的形狀，映射位置規則有理解到要基于方框邊框像素點，但沒有精確到十字交叉點。

所以，它最終得出來的答案也是錯誤的。

這才測了兩道，Gemini 3 就都錯了。要知道這還是 ARC-AGI-2 中比較簡單的題。

樣本：4c7dc4dd.json

這個結果并不代表 Gemini 3 在類似 ARC-AGI-2 場景中的實際表現，畢竟實驗設置不同，只是也表明 Gemini 3 在靜態圖像的空間認知和邏輯分析上還是比較初級的，過程有理有據，但低級錯誤令人頭疼。

好了，到了這里，本期內容的全部測評就結束了。

通過這個測評，可以認為，Gemini 3 在各種多模態理解和編程場景中，都給出了局部亮眼、整體不穩定的表現，比如：

• 能多維度分析電視劇劇情和人物，卻把主角給認錯；
• 能自主分析運動員連續動作，卻編造不存在的球員動作；
• 能逐幀分析視頻，卻高度依賴語音；
• 能寫全UI解析，卻不能完整復刻；
• 能寫好Excel，卻寫不好3D樂高引擎；
• 圖片理解框架很有邏輯，卻敗在尺寸比較的一小步；

所以 Gemini 3 給人的感覺就是巨好玩，但不夠令人放心，畢竟跨越不同模態確實有趣，但聚焦單個模態才是專業，換句話說就是 ToC 屬性爆棚，ToB 屬性還不夠。

他有點像一個優秀大學畢業的高學歷實習生，知識素養足夠，但真讓他干活他也是錯漏百出。

總之，我們暫時認為 Gemini 3 玩一玩是很不錯的，但是還是盡量不要把它用到生產環境，萬一出什么問題也不好解決。（ 昨天吃到個不知真假的瓜，有人用 Gemini 3 來 Coding 的時候被刪了 800G 重要文件 ）

或許，谷歌這次能這么強得益于其生態中擁有的豐富模態的海量數據，隨之帶來的缺點是谷歌還來不及將模型調教的足夠可靠。

當然，畢竟潛力太大，我們還是期待谷歌和 Gemini 家族的后續發力。