Google on KnightLi的博客

Gemini 3.5 Flash 和 Gemini Omni 怎麼免費用：普通使用者與開發者入口整理

Wed, 20 May 2026 23:13:35 +0800

Google 發布 Gemini 3.5 Flash 和 Gemini Omni 後，最實際的問題不是 benchmark，而是普通使用者和開發者到底怎麼用，哪些入口免費，哪些入口只是低門檻試用。

先說結論：

想聊天、寫作、看圖、日常問答：優先用 Gemini app。
想測試 Gemini 3.5 Flash 參數、提示詞和多模態輸入：用 Google AI Studio。
想寫程式呼叫 Gemini 3.5 Flash：用 AI Studio 產生 API key。
想在終端機裡免費試用：可以看 Gemini CLI。
想體驗 Gemini Omni 的影片編輯：優先看 Gemini app 和 Google Flow。
想做正式生產：不要依賴免費額度，應該轉到付費 API 或 Vertex AI。

注意：免費額度、地區開放、訂閱層級和模型下拉選單會隨時間變化。本文寫作時間是 2026 年 5 月 20 日，正式使用前要以 Google 當前頁面為準。

Gemini 3.5 Flash 免費用法一：Gemini app

最簡單的入口是 Gemini app：

https://gemini.google.com/

使用方式很直接：

打開 Gemini。
登入 Google 帳號。
在模型選擇裡找 3.5 Flash。
直接開始對話。

這個入口適合普通使用者。你可以用它做寫作、總結、圖片理解、檔案內容分析、日常問答和簡單規劃。根據公開報導，Gemini 3.5 Flash 已面向全球使用者開放，並可在 Gemini 的模型下拉選單中選擇。

限制也很明確：免費使用者通常會有每日訊息數量、地區和功能限制。如果超過限制，就需要等待額度刷新或升級訂閱。

Gemini 3.5 Flash 免費用法二：Google AI Studio

如果你不是只想聊天，而是想調提示詞、看參數、測試結構化輸出，Google AI Studio 更合適：

https://aistudio.google.com/

基本流程：

登入 Google AI Studio。
新建 prompt。
在模型下拉選單裡選擇 gemini-3.5-flash。
輸入提示詞並執行。

AI Studio 的好處是控制能力更強。你可以調溫度、系統指令、結構化輸出、多圖輸入，還能把測試好的提示詞匯出成程式碼或 API 呼叫。

對開發者來說，AI Studio 是免費的試驗台。先在這裡把提示詞和輸入格式調好，再進入 API 接入，會少浪費很多額度。

Gemini 3.5 Flash 免費用法三：免費 API key

開發者最關心的是 API。AI Studio 可以建立 Gemini API key，用來呼叫 gemini-3.5-flash。

基本流程：

打開 Google AI Studio。
找到 Get API key。
選擇或建立專案。
建立 API key。
把 key 儲存到本機環境變數。

Python 範例：

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="用三句話解釋 Gemini 3.5 Flash 適合什麼場景。"
)

print(response.text)

Node.js 範例：

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "用三句話解釋 Gemini 3.5 Flash 適合什麼場景。"
});

console.log(response.text);

curl 範例：

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"Hello Gemini 3.5 Flash"}]}]}'

公開資料顯示，AI Studio 免費層通常會給 Gemini Flash 模型一定的每日請求額度。不同時間、地區和帳號狀態可能不同，常見說法包括每天約 1,500 次請求、每分鐘請求數限制和 token 限制。不要把這些數字寫死進生產計畫，正式上線前要查看 Google AI 當前定價和限制頁面。

Gemini 3.5 Flash 免費用法四：Gemini CLI

如果你喜歡命令列，可以看 Gemini CLI。它適合臨時腳本、程式碼庫摘要、檔案讀取和終端機裡的快速問答。

安裝方式通常是：

`1`	`npm install -g @google/gemini-cli`

然後執行：

gemini

CLI 更適合個人開發者日常使用，不適合生產整合。生產環境還是應該使用 API key、服務帳號、權限控制和可稽核的呼叫方式。

Gemini Omni 免費或低門檻用法：Gemini app 和 Google Flow

Gemini Omni 是面向影片創作和編輯的多模態模型。它的核心能力不是普通文字問答，而是用自然語言多輪修改影片，並引用圖像、文字、影片、音訊等輸入。

Google DeepMind 頁面給出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

頁面也說明，需要 Google AI 訂閱，功能會因訂閱層級和地區不同而變化。因此，Gemini Omni 的「免費用法」要更謹慎理解：有些入口可能允許免費使用者看到或試用部分能力，但完整影片編輯能力可能需要訂閱、地區開放或產品灰度。

如果你只是想體驗，建議按這個順序試：

先打開 Gemini app，查看是否有 Gemini Omni 或相關影片編輯入口。
再打開 Google Flow：https://flow.google/
如果你做短影片內容，再關注 YouTube Shorts 裡是否出現 Omni 相關編輯能力。

如果入口不可見，通常不是你操作錯了，而是帳號、地區、訂閱層級或灰度範圍暫時不滿足。

Gemini Omni 適合怎麼用

Gemini Omni 更適合創作者，而不是普通聊天。

你可以嘗試這些方向：

上傳或選擇一段影片，讓它改變風格。
讓影片中的某個動作變得更誇張。
用一張參考圖替換場景裡的物體或角色。
分多輪修改鏡頭、動作、環境和風格。
把草圖、參考圖、音訊或影片組合成一個新輸出。

提示詞可以寫得像給剪輯師提要求：

`1`	`保持原影片的人物和房間結構不變，把鏡子觸碰後的效果改成液體波紋，動作要自然，光線不要突然變化。`

多輪編輯時，不要一次塞太多要求。更穩妥的做法是：

先改主體動作。
再改風格。
再改鏡頭角度。
最後調節聲音、文字和節奏。

這樣更容易保持一致性，也更容易定位是哪一步出了問題。

免費使用時最容易踩的坑

第一，免費額度不是生產額度。免費 API key 適合測試、個人工具和原型，不適合承諾穩定服務。

第二，不要把敏感資料發到免費或第三方入口。尤其是未公開程式碼、客戶資料、合約、密鑰、財務表格和內部文件。

第三，注意資料使用設定。免費層可能有不同的資料使用策略，使用前要查看 AI Studio 或 Google 帳號裡的相關設定。

第四，影片能力通常比文字能力更受限。Gemini Omni 這類影片編輯功能可能受訂閱、地區、排隊、時長、解析度和內容安全策略影響。

第五，第三方「無限免費 API」要謹慎。很多閘道會限速、轉發請求、記錄日誌，甚至要求不透明的支付方式。敏感任務不建議走這類入口。

應該選哪個入口

如果你是普通使用者：

Gemini 3.5 Flash：用 Gemini app。
Gemini Omni：先看 Gemini app，再看 Google Flow。

如果你是創作者：

用 Google Flow 體驗 Omni 影片工作流。
用 Gemini app 做腳本、分鏡、提示詞和素材說明。

如果你是開發者：

用 AI Studio 除錯提示詞。
用 API key 接入 gemini-3.5-flash。
用 Gemini CLI 做個人終端機工作流。
生產環境考慮 Vertex AI 或付費 API。

如果你是企業：

不要依賴免費額度。
重點看權限、日誌、稽核、資料駐留、合規和密鑰管理。
影片生成和編輯還要補充浮水印、內容審核和版權流程。

小結

Gemini 3.5 Flash 的免費使用路徑比較清楚：Gemini app、Google AI Studio、AI Studio API key、Gemini CLI 都可以作為低門檻入口。它適合聊天、寫作、編程、Agent 原型和多模態測試。

Gemini Omni 的重點是影片編輯和多模態創作，入口主要在 Gemini app、Google Flow 和 YouTube Shorts，但完整能力更可能受訂閱和地區限制。它適合創作者先做體驗和概念驗證，不適合一開始就按穩定生產服務來規劃。

最穩妥的策略是：文字和程式碼任務先用 Gemini 3.5 Flash 免費層試通；影片創作先用 Gemini Omni 在 Gemini app 或 Flow 裡驗證效果；真正要上線，再轉向可稽核、可計費、可控權限的正式方案。

參考來源：

Gemini Omni 是什麼？Google AI 影片多輪編輯模型完整解析

Wed, 20 May 2026 23:11:58 +0800

Google DeepMind 公布了 Gemini Omni 頁面。它的定位很直接：從任意輸入創作內容，目前重點從影片開始。

如果說 Nano Banana 更偏向圖像生成和編輯，那麼 Gemini Omni 更像是面向影片的多模態編輯模型。使用者可以透過自然語言一步步修改影片，讓後一次修改建立在前一次修改之上，並盡量保持場景、人物、動作和畫面邏輯的一致性。

專案頁面：https://deepmind.google/models/gemini-omni/

它解決的核心問題

傳統影片編輯往往需要時間軸、圖層、遮罩、關鍵影格、調色、音軌和大量手動操作。AI 影片生成工具雖然可以從提示詞生成片段，但經常存在兩個問題：

一次生成後不容易精細修改。
多輪修改時人物、場景、風格和動作容易漂移。

Gemini Omni 想解決的是第二步：不是只生成一段影片，而是讓使用者像和剪輯師溝通一樣，持續提出修改要求。

頁面給出的說法是，它可以透過自然、分步驟的對話編輯任何影片。每次編輯都建立在前一次結果上，目標是保持一個連貫、統一的場景。

主要能力

Gemini Omni 的能力可以分成幾類。

第一類是自然語言影片編輯。使用者可以直接要求模型改變影片裡的美學風格、動作或特效。例如讓鏡子像液體一樣泛起波紋，讓人物變成線稿、毛氈玩偶、透明全息線框，或者讓整個環境變成 3D voxel art。

第二類是重構動作。它可以改變影片中發生的事情，例如放大手部形成的孔洞、讓玩具發出對應動物聲音、讓建築燈光隨音樂點亮。

第三類是基於參考圖像編輯真實影片。使用者可以給出圖像參考，再要求模型把某種建築、太陽、飛行器或其他物體放進真實影片場景裡。

第四類是多輪編輯保持一致性。頁面展示了把小提琴手移動到參考圖像環境、讓小提琴消失、再把鏡頭改成越肩角度的連續編輯流程。這比一次性提示詞更接近真實創作過程。

第五類是多輸入引用。Gemini Omni 可以把圖像、文字、影片、音訊等輸入整合成一個輸出，支援風格遷移、動作遷移、角色替換、草圖轉影片等任務。

為什麼它強調世界知識

Google 在頁面裡反覆強調，Gemini Omni 不只是「畫面變得真實」，而是結合 Gemini 的世界知識、物理直覺、歷史、科學和敘事邏輯。

這點很重要。影片模型如果只追求畫面質感，容易出現動作不合邏輯、物體關係混亂、文字和畫面不同步的問題。Gemini Omni 的目標是讓影片不僅看起來像，還要在故事、物理和語義上更連貫。

頁面中的例子包括：

大理石在連鎖反應軌道上滾動。
用 claymation 解釋蛋白質折疊。
用擬物化 stop motion 解釋海馬體工作方式。
讓字母和畫面裡的物體對應出現。
讓螢幕文字按節奏逐詞出現。

這些例子說明它不是單純的短影片特效工具，而是試圖把知識表達、敘事和視聽生成放在一起。

和 Veo、Flow、Nano Banana 的關係

從 Google 目前產品線看，Gemini Omni 更像是多模態創作和編輯能力的一層入口。

Veo 更偏影片生成模型本身，強調電影感影片和音訊生成。Google Flow 是面向創作者的 AI 創意工作室，適合組織鏡頭、素材和影片專案。Nano Banana 更偏圖像建立和細節編輯。Gemini Omni 則強調「從任意輸入到一致輸出」的多模態編輯，尤其是影片上的多輪自然語言控制。

簡單理解：

想生成高品質影片：關注 Veo。
想在創作工作流裡組織影片專案：關注 Google Flow。
想編輯圖像：關注 Nano Banana。
想用對話方式修改影片，並引用圖片、文字、影片、音訊：關注 Gemini Omni。

使用入口

頁面給出的入口包括：

Gemini app。
Google Flow。
YouTube Shorts。

不過頁面也說明，需要 Google AI 訂閱，功能會因訂閱層級和地區而不同。也就是說，並不是所有使用者在所有地區都能立即使用完整能力。

對創作者來說，最值得關注的入口可能是 Google Flow，因為它更接近完整創意工作台。對普通使用者來說，Gemini app 和 YouTube Shorts 可能是更低門檻的體驗入口。

安全和內容標記

Gemini Omni 頁面專門提到安全流程。Gemini Omni Flash 的開發與內部安全、安全責任團隊合作，並進行了自動化評估、人工評估、人工紅隊、自動化紅隊和發布前倫理安全審查。

內容透明度方面，頁面說明透過 Omni 在 Gemini app、Google Flow 或 YouTube 建立或編輯的內容，會包含不可感知的 SynthID 數位浮水印和 C2PA Content Credentials。使用者可以透過 Gemini app 驗證內容，後續也會擴展到 Chrome 和搜尋。

這部分對影片模型尤其關鍵。影片生成和影片編輯越真實，越需要內容來源標識、濫用防護和驗證工具。

適合哪些人

Gemini Omni 適合幾類使用者：

想用自然語言快速修改影片的內容創作者。
需要把草圖、參考圖、音訊、影片素材整合成成片的設計團隊。
做短影片、廣告概念、教育解釋影片和產品視覺稿的人。
想在 Google Flow 中構建 AI 影片工作流的創作者。
關注多模態影片編輯能力邊界的開發者和研究者。

但它也不一定適合所有場景。嚴肅商業片、品牌主視覺、影視製作、產品發布影片仍然需要人工審片、版權檢查、事實校對和素材管理。AI 可以明顯加速概念生成和初稿迭代，但不應替代最終審核。

怎麼看 Gemini Omni

Gemini Omni 的意義在於，它把 AI 影片從「一次性生成」推進到「可對話修改」。這比單純提升畫質更接近真實創作流程。

如果它在多輪編輯、一致性、參考素材控制、音畫同步和內容標記上表現穩定，AI 影片工具的使用方式會發生變化：使用者不再只寫一條長提示詞賭結果，而是像導演、剪輯師、設計師一樣，逐輪修改場景、動作、風格和敘事。

目前仍要看實際開放範圍、價格、地區限制、生成時長、解析度、版權策略和商用規則。對於普通創作者，最實用的觀察點是：它在 Google Flow 和 Gemini app 裡能不能穩定完成多輪影片修改。

參考來源：

Google DeepMind：Gemini Omni

Gemini 3.5 正式發布：Flash 先行，Google 把重點放在 Agent 和長任務執行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式發布 Gemini 3.5 系列。第一款開放使用的是 Gemini 3.5 Flash，定位不是單純的聊天模型，而是面向 Agent、程式碼生成和長時間複雜任務執行的模型。

從這次公告看，Google 對 Gemini 3.5 的敘事很明確：模型不只要回答問題，還要能規劃、執行、檢查，並在多步驟任務中持續推進工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已經面向多類使用者開放：

一般使用者可以透過 Gemini 應用程式和 Google 搜尋中的 AI 模式體驗。
開發者可以透過 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企業使用者可以透過 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同時提到，Gemini 3.5 Pro 仍在開發中，已經在 Google 內部使用，計畫在下個月推出。

這說明 3.5 系列會繼續保留 Flash 與 Pro 的分層：Flash 更強調速度、成本和可規模化執行，Pro 則更可能面向更複雜、更高能力需求的場景。

重點是 Agent 和程式碼任務

Google 把 Gemini 3.5 Flash 稱為目前最強的 Agent 與程式碼編寫模型之一。公告中提到，它在多項程式碼和 Agent 基準測試中超過 Gemini 3.1 Pro 的部分成績，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

這些指標本身不是一般使用者最需要關心的內容。更重要的是，Google 正在把模型能力往「可執行工作流」上集中：不僅能寫程式碼，還能處理舊專案遷移、複雜應用開發、財務報表整理、資料分析和持續測試。

在 Antigravity 開發架構中，Gemini 3.5 Flash 可以透過多個協作子代理處理大型任務。Google 展示的例子包括解析 AlphaZero 論文並實作可玩的遊戲、把舊版程式碼轉換為 Next.js、並行生成城市景觀和 UI 方案。

這類能力的方向很清楚：AI 編程工具正在從「生成一段程式碼」走向「組織多個 Agent 完成一個專案」。

多模態 UI 與圖形能力增強

Gemini 3.5 Flash 繼承了 Gemini 3 的多模態基礎。Google 強調它可以生成更豐富的網頁 UI、互動動畫和圖形內容。

公告中給出的應用場景包括：

為研究論文生成互動式動畫。
根據文字描述生成互動式硬體模型。
為學校募款活動生成完整品牌概念。
在短時間內為結帳流程生成多種 UX 方案。

這部分對開發者和產品團隊很有意義。模型不再只是輸出文字說明，而是能參與前端原型、互動設計和視覺化內容生成。

企業場景：把耗時流程自動化

Google 在公告中列舉了多個合作夥伴案例。Shopify 使用子代理分析複雜資料並預測商家成長；Macquarie Bank 測試用 3.5 Flash 閱讀超過 100 頁的複雜文件，加速開戶流程；Salesforce 將其整合到 Agentforce；Ramp 用它改進複雜發票 OCR；Xero 用 AI 代理處理行政流程；Databricks 用自動化工作流監控資料異常並給出修復建議。

這些案例共同指向一個趨勢：企業採用大模型時，關注點正在從單次問答轉向流程自動化。模型是否便宜、快、能長時間穩定執行，會比單次回答是否驚豔更重要。

Gemini Spark：個人 AI 代理

Google 還公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驅動的個人 AI 代理，目標是在使用者引導下長期運行並主動執行任務。

Gemini Spark 已經開始面向受信任測試人員推出，Google 計畫在下週向美國 Google AI Ultra 訂閱使用者開放 Beta 測試。

這部分值得關注。Google 搜尋、Gemini 應用程式、Android、Workspace 和瀏覽器生態本來就覆蓋大量個人數位生活場景。如果個人 Agent 能與這些入口結合，影響可能比單獨的聊天機器人更大。

安全機制繼續前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 開發，並強化了資訊安全和 CBRN 相關防護。公告還提到使用可解釋性工具，在模型給出回答前協助檢查和理解推理過程。

這說明前沿模型的發布已經不只是能力競賽。越是強調 Agent、自動執行和長任務，安全控制、誤拒率、有害輸出防護和可解釋性就越重要。

怎麼看 Gemini 3.5

Gemini 3.5 Flash 的意義不只是「又一個新模型發布」。它更像是 Google 對下一階段 AI 產品形態的集中押注：模型要能調用工具、拆分任務、協作執行、生成 UI，並進入個人和企業工作流。

對開發者來說，值得關注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的實際體驗。對企業來說，重點是它能否在真實流程中穩定減少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 還沒有正式開放。等 Pro 發布後，Flash 與 Pro 在能力、價格、速度和上下文處理上的差異，才會決定它們各自更適合哪些生產場景。

參考來源：

Google Blog：Gemini 3.5 正式登場

Google Gemini Spark 爆料解讀：一個 24 小時在線的 Gemini Agent 可能要來了

Sun, 17 May 2026 11:58:08 +0800

Google 還沒有正式發布 Gemini Spark。

目前關於它的資訊，主要來自 Gemini Web 內部測試介面、社群截圖、TestingCatalog 報導，以及 36Kr / 新智元對相關爆料的整理。比較一致的說法是：Gemini Spark BETA 可能是 Google 正在準備的全天候 AI Agent，定位不再只是聊天助手，而是能在後台處理郵件、線上任務和多步驟工作流的「日常 AI 代理」。

所以這篇文章先把邊界說清楚：這是爆料解讀，不是 Google 官方發布稿。所有功能、命名和上線時間，都要等 Google 正式公告確認。

先說結論

從目前曝光的資訊看，Gemini Spark 有三個重點：

它可能是 Gemini 體系裡的 24 小時在線 Agent，而不是普通聊天模型。
它會調用更廣泛的個人上下文，包括 Google 應用、聊天記錄、任務、登入網站和位置資訊等。
它的風險和吸引力一樣大，因為它可能涉及資訊分享、遠端瀏覽器資料、購買動作和第三方服務調用。

如果 Google 真把 Spark 推出來，Gemini 的定位會發生變化：從「回答問題的 AI」變成「替你持續處理事務的 AI」。

Gemini Spark 是什麼

TestingCatalog 在 2026 年 5 月 14 日報導，Google 正在 Gemini Web 中測試 Gemini Spark BETA。曝光的歡迎文案把它描述成一個 everyday AI agent，可以 24/7 幫使用者處理 inbox、online tasks 和更多多步驟工作。

36Kr / 新智元的文章也提到，Spark 被扒出後，外界看到的是一個「全時 Agent」方向：它可以全天候待命，處理收件匣、執行線上任務，甚至可能涉及購買和資訊分享。

這意味著 Spark 不是一個單純的新模型名。它更像是 Gemini 產品層的一次升級：讓 Gemini 從對話窗口裡走出來，進入使用者的郵件、網頁、日程、任務和跨應用工作流。

它可能怎麼工作

根據 TestingCatalog 披露的隱藏 onboarding 文案，Gemini Spark 會從多種來源取得上下文，包括：

Connected Apps。
skills。
chats。
tasks。
使用者登入過的網站。
Personal intelligence。
location。

這些資訊會幫助 Spark 理解使用者想完成什麼，並在執行任務時調用必要的上下文。文案還提到，為了完成某些動作，Gemini 可能會把必要資訊分享給第三方，例如姓名、聯絡方式、文件、偏好，以及使用者可能認為敏感的資訊。

如果這些描述最終屬實，Spark 的工作方式會更接近「帶上下文的代理系統」，而不是一次性問答。它不是只看當前一句 prompt，而是可能綜合長期偏好、連接應用、瀏覽器狀態和任務歷史。

為什麼它重要

Gemini Spark 的關鍵，不在於多一個聊天入口，而在於 Google 有天然的生態入口。

OpenAI 和 Anthropic 可以做很強的 Agent，但它們很難天然擁有 Gmail、Calendar、Drive、Chrome、Android、Workspace 這條完整鏈路。Google 如果把 Spark 接進這些產品，使用者不需要額外搭建太多工作流，就能讓 Agent 進入日常事務。

這會帶來三個變化。

第一，Gemini 會從被動問答變成主動執行。使用者不再只是問「幫我總結這封郵件」，而是可能讓它持續整理 inbox、追蹤任務和執行後續動作。

第二，Agent 會更依賴個人上下文。它越懂你的郵件、日程、文件、瀏覽器狀態和偏好，越可能給出有用結果。

第三，權限邊界會變得更敏感。能做更多事，也意味著需要更清楚地知道它什麼時候能做、能做到哪一步、是否需要確認。

風險點在哪裡

TestingCatalog 披露的文案裡，有幾處很值得關注。

第一，Spark 是 experimental。也就是說，即便它上線，也不應被當成完全成熟、無需監督的系統。

第二，雖然系統設計上會在敏感操作前徵求許可，但文案也提示，它可能會在未經詢問的情況下分享資訊或完成購買。

第三，為了保持會話連續性，Gemini 會保存 remote browser data，比如登入細節和 remote code execution data。使用者可以在 Settings 中清除這些資料，也可以關閉 Connected Apps 和 Personal intelligence 相關能力。

這幾個點合在一起，說明 Spark 的產品方向很激進：它要做真正能執行任務的 Agent，而不是只生成建議。但越接近真實執行，越需要嚴格的權限、稽核、確認和回滾機制。

和 Remy、AI Ultra 的關係

TestingCatalog 提到，Spark 可能是此前內部代號 Remy 的 agentic Gemini upgrade 的重命名版本，也與面向 Google AI Ultra 訂閱使用者的 Gemini Agent 方向有關。

如果這個線索成立，Spark 可能不是憑空出現的新專案，而是 Google 把此前較高階、較封閉的 Agent 能力重新包裝，並準備推向更大範圍使用者。

36Kr / 新智元也把它描述成從 “Remy” 到 “Spark” 的升級：Gemini Agent 不再只是一個功能，而是要走向 24/7 的數位生活管家。

不過這仍然是基於爆料資訊的判斷。Google 是否會使用 Spark 這個正式名稱、是否只面向 AI Ultra、是否推出更輕量訂閱層，還要等官方確認。

MCP、skills 和工具生態

同一批社群截圖裡，還出現了 MCP Tool Testing 這類模型選擇器入口。36Kr 文章認為，這可能暗示新 Gemini 會原生支援 MCP 第三方工具接入，Thinking 模式也會重構。

這條線索和 Spark 放在一起看，很有意思。

如果 Spark 只是「會聊天的助手」，skills 和 MCP 的意義有限。但如果 Spark 是一個長期運行的 Agent，它就需要可靠地調用工具、存取網頁、執行任務、讀寫上下文，並把結果交付給使用者。

也就是說，Spark 可能不是單點功能，而是 Google Agent 工具生態的一部分：模型負責理解和規劃，skills / MCP / connected apps 負責執行和擴展。

對普通使用者意味著什麼

如果 Gemini Spark 真的發布，普通使用者最直接的變化可能是：

郵件不只是被總結，而是可以被分類、跟進和轉成任務。
網頁任務不只是給建議，而是可能在遠端瀏覽器中持續執行。
日程、位置、偏好和歷史對話會變成 Agent 的長期上下文。
購買、預訂、表單填寫等動作可能進入 AI 執行範圍。

這聽起來很方便，但使用者需要建立新的習慣：不再只看 AI 說了什麼，還要看 AI 準備做什麼、已經做了什麼、能不能撤回、有沒有記錄。

未來 AI Agent 的體驗好不好，可能不只取決於模型聰不聰明，還取決於權限提示是否清楚、任務日誌是否可查、錯誤操作能不能恢復。

對開發者和團隊意味著什麼

對開發者來說，Spark 的意義在於 Google 可能正在把 Agent 從「展示產品」推向真實工作流平台。

如果 Spark 能穩定連接 Google 應用、第三方工具和瀏覽器狀態，那麼開發者會關心：

API 或擴展機制是否開放。
MCP 或 skills 是否可由第三方接入。
企業管理員能否控制權限、資料留存和稽核。
Agent 執行失敗時是否有可追蹤日誌。
是否支援沙盒、審批流和敏感操作確認。

對團隊來說，Spark 可能會先從 Gmail、Calendar、Docs、Drive、Chrome 這類高頻場景切入。它未必一開始就適合完全自動化高風險業務，但很適合作為 inbox triage、會議跟進、資料整理、市場研究和輕量營運任務的助手。

現在應該怎麼看

這條消息適合用「高可信方向，低確定細節」來理解。

高可信方向是：Google 確實在推進更主動、更長期運行、更深度接入生態的 Gemini Agent。TestingCatalog 報導的 Gemini Web 測試文案、社群截圖和 36Kr 整理的多方爆料，都指向同一個方向。

低確定細節是：正式名稱、上線時間、權限規則、訂閱層級、可用地區、是否開放 API、是否真的叫 Gemini Spark，都還不能下結論。

所以現在最穩妥的判斷是：

不要把 Spark 當成已經發布的正式產品。
可以把它視為 Google 下一階段 AI Agent 路線的強訊號。
真正值得等的是官方如何解釋權限、隱私、第三方資料分享和遠端瀏覽器資料保存。

總結

Gemini Spark 如果最終發布，可能會是 Gemini 從聊天助手走向全天候 Agent 的關鍵一步。它不只是換一個模型，而是把 Gemini 放進 Google 生態的郵件、網頁、任務、位置、個人智能和第三方服務裡。

它的潛力很大：更主動、更貼近真實工作流，也更容易借助 Google 的生態分發給大量使用者。它的風險也同樣大：一旦 AI 能分享資訊、保存瀏覽器狀態、執行購買和調用第三方服務，權限邊界就必須非常清楚。

所以 Gemini Spark 最值得關注的不是「它有多聰明」，而是 Google 準備怎樣讓一個 24 小時在線的 AI Agent 變得可控、可稽核、可信任。

參考連結：

Gemini 3.5 Pro 曝光：代號 Cappuccino，Google 想在編程和 Agent 上追回節奏

Sun, 17 May 2026 11:47:27 +0800

Google 還沒有正式發布 Gemini 3.5 Pro。

目前能看到的資訊，主要來自開發者社群截圖、匿名跑分、爆料人消息和媒體轉述。36Kr / 新智元在 2026 年 5 月 15 日整理稱，新一代 Gemini 檢查點內部代號可能是 Cappuccino，相關模型已經在社群和評測平台中提前曝光。

這類資訊還不能等同於官方發布，但它透露出一個清晰方向：Google 正在試圖同時補上兩塊短板，一塊是編程和推理能力，另一塊是全天候 AI Agent。

先說結論

這次爆料可以拆成三層來看：

Gemini 3.5 Pro 尚未正式發布，Cappuccino 更像是內部檢查點或候選版本代號。
曝光資訊顯示，新 Gemini 在程式碼生成、SVG / 互動式 Web 生成、多模態輸出上有明顯提升。
Google 同步測試的 Gemini Spark，可能比模型本身更關鍵，因為它指向 24 小時運行的個人 AI Agent。

換句話說，這不是一條簡單的「模型跑分新聞」。它更像是 Google 在 I/O 前釋放出的產品路線訊號：模型要追趕 GPT-5.5，Agent 要搶占使用者工作流入口。

Cappuccino 是什麼

36Kr 文章提到，網友 Lentils 放出的消息顯示，代號 Cappuccino 的 Gemini 3.5 Pro 檢查點已經開始產出。此前社群還在討論 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果這個命名最終屬實，說明 Google 可能希望把下一代 Gemini 包裝成一次更大的版本躍遷，而不是普通小版本更新。

需要注意的是，Cappuccino 現在仍應被視為爆料中的內部代號。它不等於 Google 已經公開上線的正式模型，也不代表最終發布名一定就是 Gemini 3.5 Pro。

編程能力為什麼是焦點

這次爆料裡最受關注的點，是新 Gemini 的編程能力。

36Kr 引述的社群截圖和跑分資訊顯示，新模型在以下任務上表現更強：

生成 SVG 與視覺元件。
生成互動式 Web 應用。
處理動畫、3D、可調參數面板等複雜前端輸出。
邏輯推理和程式碼生成能力有所提升。

文章還提到，Abacus.AI CEO Bindu Reddy 轉述的說法是，3.2 Flash 在編碼和推理上接近 GPT-5.5 的水準，同時成本更低。另有媒體信源則認為，新款 Gemini 的整體性能大致追平 GPT-5.5，但未必能帶來質變。

這也是為什麼要謹慎看待「追平 GPT-5.5」這句話。它更像是不同爆料源和匿名評測中的相對判斷，而不是 Google 官方給出的基準測試結論。

為什麼 Google 急著補編程

AI 編程已經從開發者工具變成了大模型競爭的核心戰場。

OpenAI 有 Codex，Anthropic 有 Claude Code。它們不只服務工程師，也在把產品經理、設計師、營運人員帶進「自然語言生成可運行產品」的工作流裡。

相比之下，Google 雖然有 Gemini 和 Antigravity，但在開發者心智裡一直沒有形成同等強度的預設入口。36Kr 文章也提到，Antigravity 在外部市場還沒有真正突圍，定價、額度提醒和體驗穩定性都曾引發社群討論。

所以新 Gemini 如果要證明自己，編程會是最直接的戰場。它不一定只比拼「會不會寫程式碼」，還要比拼能不能穩定產出完整介面、理解複雜需求、調用工具、修復錯誤並融入真實開發流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料裡，Gemini Spark BETA 也被扒出。

根據 TestingCatalog 等資訊源的說法，Spark 的定位接近「全天候 AI Agent」：它可以處理收件匣、執行線上任務、管理多步驟工作流，並連接 Google 應用、技能模組、聊天記錄、定時任務、登入網站、位置資訊等上下文。

這意味著 Spark 不是一個普通聊天入口，而是一個可能長期在線、持續讀取上下文並替使用者執行任務的系統。

它的吸引力很明顯：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起來，Spark 會天然擁有 OpenAI 和 Anthropic 很難複製的分發優勢。

但風險也同樣明顯。36Kr 文章提到，Spark 相關說明中出現了「可能在未經詢問的情況下分享資訊或完成購買」的表述。哪怕系統設計上會在敏感操作前徵求許可，這類 Agent 仍然會帶來隱私、授權邊界和誤操作風險。

這對普通使用者意味著什麼

如果你只是普通 Gemini 使用者，這次爆料真正值得關注的不是模型名，而是三個變化：

第一，Google 可能會繼續強化「生成完整結果」的能力。以前使用者經常吐槽 Gemini 在視覺生成、SVG、前端頁面上容易偷懶，如果新模型能一次給出多個完整方案，體驗會明顯改善。

第二，編程能力會繼續下放到更輕量的模型。爆料裡反覆提到 Flash 版本在編碼、推理和互動式生成上的提升，這意味著未來不一定只有 Pro 模型才能處理複雜任務。

第三，Agent 會變得更主動。Spark 如果發布，Gemini 可能不再只是回答問題，而是開始長期接管郵件、網頁、購買、日程和跨應用任務。

這對效率是好消息，對權限管理則是新挑戰。

這對開發者意味著什麼

開發者更應該關注兩個問題。

第一個問題是工具生態。36Kr 文章提到，社群從模型選擇器裡看到了 MCP Tool Testing 這類未公開入口。如果 Gemini 原生支援 MCP 或第三方工具測試，那麼它會更容易接入開發者自己的工具鏈。

第二個問題是成本和穩定性。即便新 Gemini 在某些基準上追平 GPT-5.5，開發者最終還是會看三件事：實際程式碼品質、上下文穩定性、價格和額度是否可預期。

過去一年，AI 編程工具競爭已經證明，模型能力只是門票。真正讓開發者留下來的，是能不能在日常專案裡持續可靠地改程式碼、跑測試、讀上下文、處理邊界條件。

現在應該如何看待這條消息

這條消息適合用「強訊號、弱確認」來理解。

強訊號在於：多個社群線索都指向 Google 正在準備更強的新 Gemini，以及更主動的 Gemini Spark Agent。

弱確認在於：Gemini 3.5 Pro 還沒有官方發布，Cappuccino 仍是爆料代號，所謂「追平 GPT-5.5」的說法也需要等 Google 官方基準、第三方評測和真實使用者測試來驗證。

所以現在最穩妥的判斷是：

不要把它當成已發布產品。
可以把它當成 Google 下一階段 Gemini 路線的提前預告。
重點關注 I/O 或後續官方活動中是否會確認模型命名、API 可用性、價格、上下文窗口、工具調用和 Agent 權限邊界。

總結

Gemini 3.5 Pro / Cappuccino 的曝光說明，Google 可能正在為下一代 Gemini 做一次更強勢的版本推進。它要補的不是單一能力，而是整個 AI 工作流：模型要更會寫程式碼、生成介面和處理複雜推理，Spark 則要把 Gemini 推向全天候 Agent。

但在官方發布前，所有跑分和截圖都只能作為線索。真正決定 Gemini 3.5 Pro 能否翻身的，不是代號是否好聽，而是它能否在真實開發、真實辦公和真實多步驟任務裡穩定勝出。

參考連結：

Gemini Intelligence on Android 解讀：Google 正在把手機變成主動式 AI 系統

Sun, 17 May 2026 09:13:32 +0800

Google 在 2026 年 5 月 12 日發布了《A smarter, more proactive Android with Gemini Intelligence》，介紹 Gemini Intelligence on Android。它不是一個單獨的聊天 App，而是把 Gemini 能力放進 Android 系統、Chrome、Gboard、Autofill、widgets 和多設備體驗裡，讓手機從「等使用者點按鈕」變成「能主動幫使用者完成任務」的智能系統。

簡單說，Google 想讓 Android 從 operating system 走向 intelligence system。手機不只是打開應用、顯示通知、運行設定，而是可以理解螢幕、應用、語音和個人上下文，在使用者確認下完成更複雜的操作。

先說結論

Gemini Intelligence on Android 主要包含五個方向：

多步任務自動化：讓 Gemini 在應用之間完成叫車、購物、找資料等流程。
Chrome 智能瀏覽：在 Android 上總結網頁、比較資訊，並處理部分重複性網頁任務。
Autofill 升級：結合 Gemini 和個人上下文，幫使用者填寫更複雜的表單。
Rambler：把自然口語整理成更清楚、更專業的文字訊息。
自然語言小工具：使用者用一句話描述需求，Android 生成自訂 widgets。

這些功能會從 2026 年夏天開始分批推出，先到部分 Samsung Galaxy 和 Google Pixel 手機，之後擴展到更多 Android 設備，包括手錶、汽車、眼鏡和筆電。

多步任務自動化：從建議變成執行

Google 這次最重要的方向，是讓 Gemini 幫使用者跨應用完成多步任務。

原文舉了幾個例子：使用者可以讓 Gemini 訂健身單車課程、從 Gmail 裡找到課程大綱並把需要的書加入購物車，或者看到一張旅遊宣傳圖後，直接讓 Gemini 在 Expedia 上尋找類似行程。

這類能力的關鍵不只是「理解一句話」，而是要同時理解：

使用者目前螢幕或圖片裡的內容。
使用者授權範圍內的應用資訊。
下一步應該打開哪個應用。
哪些步驟可以自動執行。
哪些步驟必須停下來讓使用者確認。

Google 特別強調，Gemini 會在使用者指令下行動，並在任務完成時停止，最終確認仍由使用者控制。這說明它不是完全自動代理，而是帶有人類確認環節的移動端 agent。

螢幕和圖片上下文變得更重要

這次更新裡，一個值得注意的變化是 screen context 和 image context。

以前手機助手更多依賴語音命令和應用內固定介面。Gemini Intelligence 則更強調「看見目前螢幕」。例如使用者在備忘錄裡有一份購物清單，可以長按電源鍵喚起 Gemini，讓它根據清單建立配送購物車。

這意味著 Android AI 不只是聊天機器人，而是在嘗試理解使用者眼前的操作環境。未來手機 AI 的競爭，可能不只誰的模型回答更好，還包括：

能不能理解目前螢幕。
能不能跨應用執行。
能不能在後台追蹤任務進度。
能不能在關鍵節點可靠地讓使用者確認。

這也是移動端 AI 和網頁聊天 AI 的重要區別。

Chrome 智能瀏覽：從搜尋到網頁任務代理

Google 表示，從 2026 年 6 月下旬開始，Android 設備會獲得更智能的 Gemini in Chrome。

它可以幫助使用者研究、總結和比較網頁內容，也可以透過 Chrome auto browse 處理一些重複性網頁任務，比如預約、預訂停車位等。

這說明 Gemini in Chrome 不只是「網頁摘要」功能，而是在向瀏覽器代理發展。瀏覽器本來就是使用者完成網頁任務的入口，如果 Gemini 能理解網頁、填寫資訊、比較選項並執行部分步驟，Chrome 就會從瀏覽工具變成任務執行介面。

不過，這類功能也會面對幾個現實問題：

網站結構複雜，自動操作容易失敗。
表單、支付、登入和驗證碼等環節需要謹慎處理。
使用者需要知道 Gemini 到底做了什麼。
最終提交、付款或預訂最好仍保留人工確認。

所以，真正的難點不只是模型能力，而是瀏覽器自動化、安全邊界和使用者信任。

Autofill：從自動填密碼到自動填複雜表單

Autofill with Google 原本更多是密碼、地址、付款資訊等基礎便利功能。現在 Google 想把它升級成更智能的表單助手。

原文說，借助 Gemini 的 Personal Intelligence，Android 可以用連接應用中的相關資訊，自動填寫更多複雜表單欄位，包括 Chrome 裡的表單。

這類能力很實用。移動端填寫複雜表單一直很痛苦，螢幕小、欄位多、經常需要從郵件、日曆、聊天和文件裡複製資訊。如果 Gemini 能在使用者授權下自動整理並填寫，會節省很多時間。

但 Google 也強調，連接 Gemini 和 Autofill with Google 是嚴格 opt-in。也就是說，使用者自己選擇是否連接，之後也可以在設定裡隨時開關。

這點很重要，因為 Autofill 涉及個人資料、地址、帳號、支付、工作資訊和敏感表單。越是有用，越需要明確授權和可控退出。

Rambler：把口語變成可發送文本

Rambler 是這次更新裡比較有意思的新功能。

Gboard 已經可以把語音轉文字，但人說話時常常會有重複、停頓、語氣詞和自我修正。Rambler 的目標是把自然說話整理成更清楚、更適合發送的文本。

它適合這些場景：

你想快速口述一段訊息，但不想逐字修改。
你說話時夾雜停頓、重複和語氣詞。
你需要把隨口想法整理成更專業的簡訊、郵件或聊天內容。
你在多語言之間切換，希望系統理解上下文。

Google 還提到，Rambler 會清楚顯示使用者何時啟用了它，音訊只用於即時轉寫，不會被保存。這是對隱私和透明度的回應。

從產品角度看，Rambler 其實是把「語音輸入」升級成「語音寫作」。它不只是記錄你說了什麼，而是幫你把口語變成可發送的文字。

自然語言建立小工具

Gemini Intelligence 還會帶來 Create My Widget。使用者可以直接用自然語言描述想要的小工具，比如「每週推薦三份高蛋白備餐食譜」，系統就生成一個可以放在主螢幕上的自訂 widget。

這代表 Android 在嘗試 generative UI：使用者不再只從固定模板裡選擇小工具，而是描述自己想看的資訊和展示方式。

如果這個方向成熟，手機主螢幕可能會變得更個人化。天氣、日程、健康、通勤、飲食、學習、工作提醒，都可以變成按使用者需求生成的動態模組。

不過，生成式 UI 也需要解決穩定性問題。小工具不是一次性聊天回覆，而是長期顯示在桌面上，必須可靠、可讀、可配置，並且不能亂占螢幕空間。

Material 3 Expressive 與智能 UI

Google 還提到，Gemini Intelligence 會帶來基於 Material 3 Expressive 的更新設計語言。

這部分不是單純美化介面，而是讓 UI 動畫和互動更有目的感，減少干擾，讓使用者更專注於任務。換句話說，當 AI 開始主動處理任務時，介面需要清楚表達：

AI 正在做什麼。
哪些步驟已經完成。
哪些地方需要使用者確認。
使用者如何取消或修改。

主動式 AI 如果沒有清晰 UI，很容易讓使用者感到失控。所以設計語言本身也會成為 AI 產品體驗的一部分。

可用性和節奏

根據 Google 原文，Gemini Intelligence 功能會從最新 Samsung Galaxy 和 Google Pixel 手機開始，在 2026 年夏天分批推出。之後會擴展到更多 Android 設備，包括手錶、汽車、眼鏡和筆電。

這說明它不是一次性全球全量上線，而是分批 rollout。具體可用性可能取決於設備、地區、語言、應用支援和帳號設定。

如果你想體驗這些功能，最現實的預期是：

先關注 Pixel 和 Samsung 旗艦機。
關注 2026 年夏季後的系統更新。
留意 Gemini、Chrome、Gboard、Autofill 和 Android 設定中的新開關。
不同地區和語言可能不會同時支援所有功能。

這對 Android 意味著什麼

Gemini Intelligence on Android 的意義，不是又加了幾個 AI 小功能，而是 Android 產品定位的變化。

過去的手機系統主要負責管理應用、通知、權限、檔案和硬體。現在 Google 想讓系統理解使用者意圖，並在應用之間完成任務。這個方向如果成功，Android 的競爭點會從「系統功能和生態應用」擴展到「能不能主動幫使用者做事」。

這也會讓移動端 AI 競爭進入新階段：

Apple 會強調本地化、隱私和系統整合。
Google 會強調 Gemini、搜尋、Chrome、Android 和多設備生態。
第三方 AI App 會更難和系統級入口競爭。
應用開發者需要考慮自己的 App 如何被 AI 代理呼叫。

未來幾年，手機上的 AI 可能不再只是一個聊天入口，而是變成系統級執行層。

總結

Google 這次發布的 Gemini Intelligence on Android，核心不是「手機裡多了一個 Gemini 聊天框」，而是把 AI 放進 Android 的操作流程裡。多步任務自動化、Chrome 智能瀏覽、Autofill、Rambler 和自然語言小工具，都是在讓手機從被動工具變成主動助手。

它能不能真正改變使用者習慣，取決於幾個關鍵因素：自動化是否可靠、隱私開關是否清楚、跨應用操作是否順暢、使用者是否始終保留最終控制權。至少從這次發布看，Google 已經把 Android 的下一階段定義為主動式 AI 系統，而不只是傳統移動操作系統。

參考連結：

Google Blog：A smarter, more proactive Android with Gemini Intelligence

Gemini Embedding 2：把文字、圖像、影片和音訊放進同一個向量空間

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog 介紹了 Gemini Embedding 2 的開發用法。這個模型已經透過 Gemini API 和 Gemini Enterprise Agent Platform 進入 GA，重點不只是「新的 embedding 模型」，而是把文字、圖像、影片、音訊和文件映射到同一個語義空間。

這會讓檢索系統的邊界變寬。過去很多 RAG 流程需要先把圖片、影片、音訊拆成文字或中繼資料，再分別建立索引；Gemini Embedding 2 則可以直接處理多模態輸入，讓代理、搜尋和分類系統更容易圍繞真實業務材料工作。

原文連結：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

模型能力

Gemini Embedding 2 支援 100 多種語言。單次請求可以處理：

最多 8,192 個文字 token
最多 6 張圖片
最多 120 秒影片
最多 180 秒音訊
最多 6 頁 PDF

它的關鍵點是「統一語義空間」。開發者可以把不同模態的內容放在同一套向量表示裡，用同一種檢索、聚類或重排序邏輯處理。

例如，文字描述和圖片可以放在同一次 embedding 請求裡：

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

如果你希望每個輸入分別得到 embedding，而不是聚合成一個向量，可以使用 Batch API。原文也提到，Agent Platform 對這類批次支援還在跟進中。

對 RAG 的意義

多模態 embedding 對代理式 RAG 很有用。一個 AI agent 可能需要同時檢查程式碼倉庫、PDF、截圖、圖表、音訊會議紀錄和產品圖片。如果所有資料都能進入同一個語義空間，檢索鏈路就不必為每種材料單獨設計一套入口。

Google 建議根據任務使用 task prefix，讓 embedding 更貼近檢索目標。例如問答、事實核查、程式碼檢索和搜尋結果，可以使用不同前綴：

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

這種前綴適合非對稱檢索：使用者查詢往往很短，文件內容往往很長。把 query 和 document 分別按任務格式整理，可以改善短查詢到長文件之間的匹配。

原文給了兩個落地回饋：

Harvey 在法律檢索基準上，Recall@20 precision 相比上一代 embedding 提升 3%。
Supermemory 在 Recall@1 搜尋準確率上提升 40%，並把它用於記憶、索引、搜尋和問答管線。

這些數字不代表所有場景都會同幅度提升，但說明多模態 embedding 已經不只是展示能力，而是在真實檢索產品中產生效果。

視覺搜尋

Gemini Embedding 2 也適合做以圖搜圖、圖文混合搜尋和商品識別。原文提到服裝租賃公司 Nuuly 用它匹配倉庫中未打標籤的服裝照片，使 Match@20 從 60% 提升到接近 87%，整體成功識別率從 74% 提升到 90% 以上。

這類場景的關鍵不是生成內容，而是理解「這張圖片和哪個庫存、文件或商品紀錄最接近」。如果你的業務裡有大量圖片、影片片段或掃描件，多模態 embedding 會比純文字索引更自然。

檢索重排序

Embedding 還可以用於 rerank。常見做法是先用基礎檢索拿到一批候選結果，再計算候選結果和使用者查詢之間的相似度，把更相關的內容排到前面：

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文還提到一種思路：先讓模型根據內部知識生成一個假設答案，再把這個假設答案做 embedding，與候選內容比較相似度，用來挑出語義更貼近的結果。這對問答型 RAG 尤其有用。

聚類、分類和異常檢測

除了檢索，embedding 也適合聚類、分類和異常檢測。和前面的問答檢索不同，這些屬於對稱任務，query 和 document 可以使用同一種任務前綴：

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

這類任務可以用於輿情分類、內容審核、相似資產歸類、異常樣本發現，也可以幫助 agent 對大量上下文材料先做整理，再進入後續推理。

儲存和成本

Gemini Embedding 2 預設輸出 3,072 維向量。它使用 Matryoshka Representation Learning，因此可以透過 output_dimensionality 把向量截斷到更小維度。Google 推薦在效率優先時使用 1,536 或 768 維：

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

向量可以存到 Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB 等系統裡。成本方面，原文提到 Batch API 可提供更高吞吐，並達到預設 embedding 價格的 50%。

開發者該怎麼用

如果你已有文字 RAG，可以先從兩類增量改造開始：

把 PDF、截圖、圖片說明和文字文件放入同一個索引，測試查詢召回是否更穩定。
給不同任務加 task prefix，例如問答、事實核查、程式碼檢索、商品搜尋，不要把所有內容都按同一種 embedding 方式處理。

如果你在做新產品，可以優先考慮這些方向：

企業知識庫：同時檢索文件、圖表、簡報截圖和會議材料。
視覺搜尋：用圖片、文字或混合輸入查找商品、資產、設計稿和檔案。
Agent 工具鏈：讓 coding agent、研究 agent 或客服 agent 檢索多種格式的業務材料。
內容治理：對文字、圖片、影片片段做統一分類、聚類和異常檢測。

Gemini Embedding 2 的價值在於把多模態材料變成同一套可檢索資產。對開發者來說，這會減少「先轉文字再檢索」的中間層，也讓 RAG 系統更接近真實世界的資料形態。

Gemini 進入 Google built-in 汽車：車載語音助理開始變得更像真正的 AI 助理

Fri, 01 May 2026 06:09:57 +0800

Google 在 2026 年 4 月 30 日宣布，Gemini 開始進入搭載 Google built-in 的汽車，作為 Google Assistant 的升級版本陸續推送。

這件事的重點不只是「車裡多了一個 AI 助理」，而是車載語音互動正在從固定命令，轉向更自然的連續對話。使用者不需要嚴格記住指令格式，可以像和一般助理交流一樣，讓 Gemini 幫忙導航、處理訊息、查詢車輛資訊，甚至控制部分車內設定。

先從美國英語使用者開始

根據 Google 的說明，這次更新會涵蓋新車和既有車輛，前提是車輛支援 Google built-in，並且使用者已經在車機裡登入 Google 帳號。

rollout 會先從美國英語使用者開始，之後再擴展到更多語言和國家。符合條件的使用者會在車內看到升級到 Gemini 的提示。升級後，可以透過以下方式喚起 Gemini：

說出 Hey Google
點擊主畫面上的麥克風
使用方向盤上的語音按鈕

這說明 Google 沒有把 Gemini 做成一個需要重新學習的新入口，而是延續原本的車載語音入口，只是把底層助理換成更強的 Gemini。

車載語音不再只靠固定命令

過去車載語音助理常見的問題是：能做的事不少，但使用者必須說得很「標準」。一旦表達稍微複雜，助理就容易聽不懂，或者只能執行最基礎的動作。

Gemini 進入車機後，Google 強調的是自然對話能力。比如使用者可以直接說：

I need to grab lunch, find some highly rated sit-down restaurants along the way. I’m not in a rush, oh, and I’d like to eat outside.

Gemini 會結合 Google Maps 找沿途合適的餐廳。使用者還可以繼續追問停車情況、是否有素食選項等，不需要重新發起一輪完整搜尋。

這種互動更符合駕駛場景。人在開車時很難像使用手機一樣反覆篩選、點擊和修改條件，語音助理如果能理解更完整的意圖，就能明顯減少分心。

地圖、訊息和音樂會變得更順手

Google 給出的幾個例子，基本都圍繞駕駛時最常見的需求。

第一類是路線和地點搜尋。

Gemini 可以根據 Google Maps 資訊尋找沿途餐廳、景點或充電站，也可以回答和目前路線相關的問題。比如經過體育場附近時，使用者可以問附近是否有活動、是否會影響交通。

第二類是訊息處理。

使用者可以讓 Gemini 總結新簡訊，再根據上下文回覆。比如讓它回覆朋友「我在路上，並附上預計到達時間」。如果臨時想改內容，也可以繼續補充，不必從頭開始。

第三類是音樂和氛圍。

使用者不一定需要知道電台名或具體歌單，可以直接描述想聽的內容。例如播放爵士電台，或者在 YouTube Music 裡播放適合山路駕駛的歡快 70 年代 folk-rock，並跳過慢歌。

這些功能本身並不新，但 Gemini 的價值在於把多個條件合在一句自然語言裡處理，而不是把使用者逼回固定命令。

Gemini Live 讓車裡也能邊走邊聊

Google 還提到，Gemini Live 也會進入車載場景，目前處於 beta。使用者可以點擊 Gemini Live 按鈕，或者說 Hey Google, let's talk 開始更自由的對話。

這類場景更像「開車時的陪伴式學習和腦力激盪」。例如開車去 Lake Tahoe 時，可以讓 Gemini 講當地歷史和趣聞；聽到感興趣的內容後，可以隨時打斷追問。也可以讓 Gemini 幫忙規劃到達目的地後的徒步路線和活動安排。

這和傳統車載助理的差異很明顯。傳統助理更像工具按鈕，Gemini Live 則更像一個可以連續交流的語音介面。

車輛說明書和即時車況是關鍵差異

更值得注意的是，Gemini 不只是回答通用問題。Google 表示，他們和車廠合作，把 Gemini 更深入地接入車輛系統。

這帶來幾類更貼近汽車本身的能力。

第一，使用者可以詢問車輛功能。

比如「自動洗車前我應該怎麼準備？」或者「我的車庫天花板太低，後車廂門會碰到，怎麼設定後車廂不要完全打開？」Gemini 會根據車廠提供的車主手冊，給出適配具體車型的答案。不同品牌和車型能提供的資訊細節會有所差異。

第二，電動車使用者可以詢問即時電量和續航。

例如目前電量、到達目的地時預計剩餘電量，或者讓 Gemini 查找附近充電站。它還可以結合 Google Maps，幫使用者找充電附近的咖啡店等地點。

第三，部分車內設定可以透過自然語言調整。

Google 舉的例子是使用者說「車裡又起霧又冷」，Gemini 可以理解背後的意圖，調高暖風並打開除霧。

這類能力比單純把聊天機器人搬進車機更實際。汽車是一個有明確狀態、硬體能力和安全邊界的環境，AI 助理如果能理解車輛上下文，價值會比普通問答更高。

車載 AI 的邊界也更重要

車內場景對 AI 的要求和手機、網頁不同。

開車時使用者不能頻繁看螢幕，也不能花太多注意力糾正 AI。助理需要足夠簡潔、可靠，並且不能在關鍵場景裡製造新的負擔。

所以 Gemini 進入汽車並不意味著所有複雜任務都適合在車裡完成。更合理的方向是：

降低導航和資訊查詢的操作成本
用自然語言替代多層選單
幫使用者快速理解車輛功能
在不分散注意力的前提下處理訊息和媒體
給 EV 使用者更順滑的充電與路線資訊

反過來，高風險操作仍然需要清晰邊界。比如影響駕駛安全的設定、需要確認的訊息發送、涉及車輛控制的動作，都應該有足夠明確的確認流程。

小結

Gemini 進入 Google built-in 汽車，是 AI 助理從手機和網頁繼續向日常環境擴展的一步。

它的意義不在於車裡終於可以「聊天」，而在於車載語音助理開始理解更複雜的意圖，並能結合地圖、訊息、音樂、車輛說明書和部分車況資訊來完成任務。

如果 rollout 順利，車載語音互動可能會從「記住命令」逐漸變成「描述需求」。這對開車場景很重要，因為真正好的車載 AI，不應該要求駕駛者為它分配太多注意力。

參考連結：

Your car with Google built-in is about to get smarter, thanks to Gemini - Google Blog

如何呼叫 Google Nano Banana 做圖片去背

Thu, 09 Apr 2026 20:10:48 +0800

這篇文章用一段實際可執行的 Python 腳本，示範如何呼叫 Google 的 Nano Banana 圖像編輯能力來做商品圖去背。

目前這份實作的目標很明確：

讀取一個目錄中的商品圖片
呼叫 Google 圖像模型執行背景移除
對回傳圖片再做一次本地透明背景清理
最終輸出為透明底 PNG

如果你手上已經有一批白底商品圖、耳機圖、線材圖，想快速生成可用於電商的透明背景圖片，這種方式會很直接。

這段程式碼做了什麼

這份腳本主要分成 4 個部分：

定義提示詞，讓模型知道要執行「去背景、保留主體、不要加陰影」
呼叫 google-genai 的圖像生成介面
從模型回應中提取圖片結果
再用本地邏輯把邊緣淺色背景轉成透明，減少殘邊

也就是說，它不是單純把圖片丟給模型就結束，而是把「模型編輯 + 本地後處理」串起來了。

執行前準備

先安裝依賴：

`1`	`.\.venv\Scripts\python.exe -m pip install google-genai pillow`

如何取得 GEMINI_API_KEY

GEMINI_API_KEY 就是呼叫 Gemini API 時使用的金鑰。根據 Google 官方 quickstart，如果你還沒有 key，可以直接在 Google AI Studio 建立。

取得步驟如下：

打開 Google AI Studio。
登入你的 Google 帳號。
找到 Get API key 或 API keys 頁面。
建立一個新的 API key。
複製產生出來的 key。
把它設定到本地環境變數中，供腳本讀取。

如果頁面中還沒有可用專案，通常需要先完成專案初始化，之後再回到 API Key 頁面建立金鑰。

拿到 key 之後，再設定環境變數：

`1`	`$env:GEMINI_API_KEY="your_api_key"`

如果你用的是 cmd，可以寫成：

`1`	`set GEMINI_API_KEY=your_api_key`

如果你同時設定了 GEMINI_API_KEY 和 GOOGLE_API_KEY，實際執行時通常會優先讀取 GOOGLE_API_KEY，所以建議只保留一個，避免混淆。

目錄結構範例

腳本接收兩個參數：

例如：

images/
  product1.jpg
  product2.png

output/

如何執行

假設腳本檔名是 cutout.py，執行方式如下：

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output`

如果你想換模型，也可以明確傳參：

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output --model gemini-2.5-flash-image`

腳本會遍歷輸入目錄中的這些格式檔案：

.jpg
.jpeg
.png
.webp

處理完成後，會在輸出目錄中生成同名的透明底 PNG 檔案。

核心呼叫流程

真正呼叫 Google Nano Banana 的關鍵程式碼在這裡：

response = client.models.generate_content(
    model=model,
    contents=[PROMPT, image],
)

這裡傳入了兩個內容：

一段文字提示詞 PROMPT
一張 PIL.Image

提示詞內容是讓模型把整張商品圖背景移除，只保留主體，並強調幾件事：

保留完整商品
保留細線和線纜細節
清理內部空洞和環形區域
不要新增物體
不要添加陰影

這類提示詞對去背品質影響很大，尤其是耳機線、透明邊緣、空洞區域這類細節。

為什麼還要做一次本地後處理

模型回傳結果後，腳本沒有直接儲存，而是又執行了 make_transparent_from_borders(image)。

這一步的思路是：

從圖片四周邊界開始找淺色背景像素
用廣度優先搜尋把連通的淺色區域全部標記出來
最後把這些區域統一改成透明

這樣做的好處是可以進一步清掉一些殘留白邊、淺灰背景和不夠乾淨的邊緣區域。

判斷「是不是背景」的條件在這裡：

def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35

簡單理解就是：

顏色整體夠亮
RGB 三通道差異不能太大

這比較適合處理白底、淺灰底、接近純色的商品圖背景。

完整原始碼

下面保留目前這份完整原始碼，方便你直接重用或二次修改：

from __future__ import annotations

import argparse
import os
from pathlib import Path
from collections import deque

from PIL import Image

try:
    from google import genai
except ImportError as exc:  # pragma: no cover
    raise SystemExit(
        "Missing dependency: google-genai. Install it with "
        r"'.\.venv\Scripts\python.exe -m pip install google-genai'."
    ) from exc


PROMPT = (
    "Remove the entire background from this product photo and return only the product "
    "on a fully transparent background as a PNG. Keep the full product intact, preserve "
    "thin cable details, clean the inner loops and holes, and do not add any new objects "
    "or shadows."
)


def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35


def to_pil_image(image_obj) -> Image.Image:
    if isinstance(image_obj, Image.Image):
        return image_obj
    pil_image = getattr(image_obj, "_pil_image", None)
    if isinstance(pil_image, Image.Image):
        return pil_image
    as_pil = getattr(image_obj, "pil_image", None)
    if isinstance(as_pil, Image.Image):
        return as_pil
    raise TypeError(f"Unsupported image object type: {type(image_obj)!r}")


def make_transparent_from_borders(image: Image.Image) -> Image.Image:
    rgba = image.convert("RGBA")
    width, height = rgba.size
    pixels = rgba.load()

    visited: set[tuple[int, int]] = set()
    queue: deque[tuple[int, int]] = deque()

    def push_if_bg(x: int, y: int) -> None:
        if (x, y) in visited:
            return
        r, g, b, _ = pixels[x, y]
        if is_light_background_pixel(r, g, b):
            visited.add((x, y))
            queue.append((x, y))

    for x in range(width):
        push_if_bg(x, 0)
        push_if_bg(x, height - 1)
    for y in range(height):
        push_if_bg(0, y)
        push_if_bg(width - 1, y)

    while queue:
        x, y = queue.popleft()
        for nx, ny in ((x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)):
            if 0 <= nx < width and 0 <= ny < height:
                push_if_bg(nx, ny)

    for x, y in visited:
        pixels[x, y] = (0, 0, 0, 0)

    return rgba


def save_first_image_part(response, dst: Path) -> None:
    parts = getattr(response, "parts", None)
    if parts is None and getattr(response, "candidates", None):
        parts = response.candidates[0].content.parts

    if not parts:
        raise RuntimeError("Model returned no content parts.")

    for part in parts:
        inline_data = getattr(part, "inline_data", None)
        if inline_data is None and isinstance(part, dict):
            inline_data = part.get("inline_data")

        if inline_data is None:
            continue

        if hasattr(part, "as_image"):
            image = to_pil_image(part.as_image())
            dst.parent.mkdir(parents=True, exist_ok=True)
            make_transparent_from_borders(image).save(dst)
            return

        data = getattr(inline_data, "data", None)
        mime_type = getattr(inline_data, "mime_type", "")
        if data:
            dst.parent.mkdir(parents=True, exist_ok=True)
            with open(dst, "wb") as handle:
                handle.write(data)
            with Image.open(dst) as img:
                processed = make_transparent_from_borders(img)
                processed.save(dst.with_suffix(".png"))
            if dst.suffix.lower() != ".png":
                dst.unlink(missing_ok=True)
            return

    raise RuntimeError("Model returned text only and no edited image.")


def process_image(src: Path, dst: Path, client, model: str) -> None:
    with Image.open(src).convert("RGBA") as image:
        response = client.models.generate_content(
            model=model,
            contents=[PROMPT, image],
        )
    save_first_image_part(response, dst)


def main() -> None:
    parser = argparse.ArgumentParser(description="Use Nano Banana / Gemini image editing to cut out product images.")
    parser.add_argument("input_dir", type=Path)
    parser.add_argument("output_dir", type=Path)
    parser.add_argument("--model", default="gemini-2.5-flash-image")
    args = parser.parse_args()

    api_key = os.environ.get("GEMINI_API_KEY")
    if not api_key:
        raise SystemExit("Missing GEMINI_API_KEY environment variable.")

    client = genai.Client(api_key=api_key)
    exts = {".jpg", ".jpeg", ".png", ".webp"}

    for src in sorted(args.input_dir.iterdir()):
        if not src.is_file() or src.suffix.lower() not in exts:
            continue
        dst = args.output_dir / f"{src.stem}.png"
        process_image(src, dst, client, args.model)
        print(dst)


if __name__ == "__main__":
    main()

適合繼續優化的地方

如果你準備把這段腳本繼續用於批次生產，後面還可以補這些能力：

增加失敗重試，避免單張圖片報錯後整批中斷
記錄日誌，方便定位是哪張圖處理失敗
把不同背景閾值做成可配置化
支援遞迴掃描子目錄
增加原圖與結果圖的對比預覽

小結

如果你只想快速理解「怎麼呼叫 Google Nano Banana 做去背」，其實核心就三步：

安裝 google-genai 和 Pillow
設定 GEMINI_API_KEY
用 client.models.generate_content() 傳入提示詞和圖片

而這份程式碼的價值在於，它不只是呼叫模型，還補上了透明背景後處理，更適合直接拿去做商品圖去背任務。

Google Gemma 4 模型對比：2B/4B/26B/31B 怎麼選？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模態 與 本地離線運行，並提供從輕量端到高性能端的完整模型梯度。對大多數本地部署使用者來說，關鍵不是選最大，而是選最符合硬體與任務需求的版本。

Gemma 4 各模型對比

下表用於快速選型參考；具體性能與資源占用請以實際部署環境測試為準。

模型	參數規模	定位	主要優勢	主要限制	推薦場景
Gemma 4 2B	20 億	超輕量	延遲低、資源占用小、部署門檻最低	複雜推理與長鏈路任務能力有限	行動端、IoT、輕量問答、簡單自動化
Gemma 4 4B	40 億	輕量增強	比 2B 更穩定的理解與生成能力，仍易於本地部署	高強度編碼與複雜 Agent 任務上限有限	本地助手、基礎文件處理、多語言日常任務
Gemma 4 26B	260 億	高性能（專家混合）	推理與工具調用能力明顯提升，適合生產工作流	顯存需求顯著上升，硬體門檻更高	編程助手、複雜工作流、企業內部 Agent
Gemma 4 31B	310 億	高性能（稠密）	綜合能力最強，複雜任務穩定性更好	資源成本最高，部署與調優成本更大	高要求推理、複雜程式任務、重度自動化

怎麼選：按硬體和任務倒推

如果你主要關心「能不能跑、跑得順不順」，可以按下面選：

8GB 顯存：優先 2B/4B。
12GB 顯存：優先 4B 或更高模型的量化版本。
24GB 顯存：可重點考慮 26B，並依任務評估 31B 量化版。
更高顯存或多卡：可嘗試 31B 的高精度配置。

建議先保證穩定性與推理速度，再逐步提升模型規模。

四類典型使用場景

1) 本地通用助手

優先模型：4B
原因：成本與效果平衡佳，適合長期常駐運行。

2) 程式與自動化

優先模型：26B
原因：在多步驟任務、工具調用、腳本生成上更穩。

3) 高難度推理與複雜 Agent

優先模型：31B
原因：在複雜上下文下穩定性更高、容錯更好。

4) 邊緣設備與輕量離線

優先模型：2B
原因：最容易在資源受限設備落地。

部署建議（Ollama 方向）

更實用的做法是小步快跑：

先用 4B 建立可運行基線（速度、記憶體、效果）。
把真實任務做成固定測試集（例如 20 條常見問題 + 10 個自動化任務）。
再升級到 26B/31B 對比準確率、時延與顯存成本。
只在收益明顯時升級大模型。

這樣可以避免一開始就追求大參數，導致卡頓、吞吐低與維護複雜度上升。

結論

Gemma 4 的真正價值，不是單純參數更大，而是提供了從輕量到高性能的一整套可落地梯度：

想低成本快速上線：從 2B/4B 開始。
想讓本地 AI 真正接入生產流程：優先 26B。
想衝擊複雜推理與重度自動化：再上 31B。

Gemma 4 的最佳選擇通常不是參數最大，而是與硬體條件與任務目標匹配度最高的版本。