為什麼 Google 隱藏的 Gemini Live 模型，比演示更重要

Google 隱藏的 Gemini Live 模型，顯示它正在打造可切換的 AI 平台，而不只是單一聊天機器人。

Google 現在真正值得注意的，不是 Gemini Live 的展示效果，而是它背後已經出現可路由、可替換、可分工的模型架構。Google App 17.18.22 的隱藏選單直接露出七個選項，還有兩個標成 RC2；在測試裡，不同變體會做出不同事：有的會抓即時天氣，有的會記住前文細節，有的自稱 Gemini 3.1 Pro，還有一個思考版會加上推理層。這些差異不是表演，而是產品架構正在成形。

第一個論點：Google 在把 Gemini Live 做成路由系統，不是單體模型

最有力的證據就是模型選單本身。伺服器下發的 menu 代表 Google 可以不改 App 就切換能力，這是平台思維，不是單次實驗。清單裡的 Default、A2A_Rev25_RC2、A2A_Rev25_RC2_Thinking、A2A_Rev23_P13n、A2A_Nitrogen_Rev23、A2A_Capybara、A2A_Capybara_Exp、A2A_Native_Input，已經不是「一個模型」的概念，而是一組可調度的工作單元。

RC2 標記更關鍵。Release Candidate 2 的意思是，這些變體不是純概念，而是已經進到接近上線的階段。當兩個新選項在短時間內出現，且在控制測試中表現不同，Google 傳遞的訊號很清楚：Gemini Live 正從通用助手，變成會依任務分派模型的路由器。這種架構才能承接後續新能力，而不會每加一項就把整個體驗搞亂。

第二個論點：這些隱藏變體透露了 Google 的真正產品策略

個人化模型是最直接的證據。測試中，P13n 變體會先問使用者所在時區，而不是硬猜；它也會記住前面提過的個人資訊，並在後續對話中引用。預設的 Gemini Live 不會這樣做。這不是小修小補，而是 Google 在把「一般助理」和「有記憶、懂上下文的助理」拆開處理，因為只有拆開，才有辦法同時控制隱私、延遲與準確度。

Capybara 也很有代表性。它在測試裡自稱 Gemini 3.1 Pro，而不是一般的 Flash Live 模型，這暗示 Google 正在同一個對話外殼裡測試分層模型。白話說，使用者未來拿到的不是單一 Gemini Live，而是一組分工明確的引擎：有的負責速度，有的負責記憶，有的負責推理，有的負責不同輸入模式。這才是正確方向，因為即時語音、即時檢索和深度推理本來就是不同工作負載。

反方可能怎麼說

最強的反對意見是：隱藏模型不等於會成功上線。Google 一向擅長先放出伺服器端實驗，再臨時調整方向；一串代號很可能最後只是被放棄的試驗品。就算真的推出，把 Gemini Live 切成很多變體，也可能讓使用者感到混亂，造成行為不一致，最後比單一預設模型更不穩定。

這個質疑有一部分是對的，因為模型太多確實可能把體驗弄壞。問題在於，現在看到的證據不是把複雜性直接丟給使用者，而是先把複雜性藏在伺服器端。選單是隱藏的、可控的，而且已經按任務切分。這正是上線前該做的事：先把路由層做好，再決定要不要把選擇權交給使用者。風險存在，但架構方向是對的。

你能做什麼

如果你是工程師、PM 或創辦人，該學的不是「Google 有七個隱藏模型」，而是它正在把介面和模型解耦，並用伺服器端路由去管理成本、延遲與能力差異。你的產品也應該這樣做：把預設路徑維持輕量，把推理、記憶、個人化和特殊輸入拆成可替換模組，並在 UI 之前先把模型切換機制、能力分級和記憶政策設計清楚。未來贏的 AI 產品，不會再假裝一個模型能做完所有事。