Google I/O 把 Search 變代理人

我把 Google I/O 拆成可抄的工作流模板：Search、Gemini、Spark 和智慧眼鏡怎麼從問答變成可委派的代理人。

我看 Google 這幾年一直在塞 AI 功能，看到後來真的有點膩。每次 demo 都很會講，輪到我自己用就開始漏氣：問一題還行，追問就失憶；要它幫我整理事情，最後只剩一堆漂亮廢話。最煩的是，它看起來像有在做事，實際上只是把我原本要做的功課換個介面再丟回來。這種東西拿去 keynote 很好看，拿來撐日常工作就很尷尬。

所以這次我看 Google I/O，第一個不是看名字，而是看它到底想改什麼工作流。原始整理我主要參考 Wirecutter 的回顧，作者是 Caitlin McGarry 和 Brenda Stolyar。它沒有給我一堆品牌糖衣，反而直接把重點拆成 Search、Gemini、Spark 和眼鏡，這比較像我想看的東西。

我先講結論：Google 這次不是在加一個聊天框而已，它是在把「問一個東西」推向「委派一件事」。這差很多。前者是查資料，後者是把事情交出去。只要方向真的是這樣，那我們看它的方式就不能只看模型多大、名稱多炫，而是要看它有沒有真的進到工作流裡。

Search 不再只是輸入框，這件事很重要

“The biggest change rolling out today is a redesigned ‘intelligent’ search box that will greet you on the Google homepage.”

翻譯一下就是，Google 想把搜尋框從「關鍵字欄位」改成「對話起點」。它會更願意接長句、接上下文、接追問，甚至把你一路帶進 AI Mode。這不是小改版，這是在改人怎麼跟搜尋互動。

我以前最煩的就是很多 AI 搜尋工具假裝能聊天，結果第一題答得像樣，第二題開始就像換了一個路人。Google 這次比較聰明的地方是，它沒有把新互動硬塞到新 app，而是直接塞回大家本來就會用的首頁。這種做法很土，但有效，因為它降低了學習成本。

更細一點看，這個搜尋框其實在教育使用者怎麼下 prompt。以前大家被訓練成要把需求壓縮成幾個字，像在跟機器吵架。現在它鼓勵你講完整句子，甚至把背景一起丟進去。這是很大的使用習慣轉向，因為它默默把「搜尋」變成「描述需求」。

我之前做 vendor research 就碰過這個痛點。一次性答案很快，但一旦市場有變動，整份整理立刻過期。真正有用的，不是回答一次，而是能持續追蹤、再濃縮成我能掃過去的更新。這也是 Google 這次比較像真的在解問題的地方。

實操上，我會這樣拆：

• 先讓使用者用自然語言講完整意圖，不要急著叫他選 filter。
• 把追問留在同一個介面，別逼人重新開一個流程。
• 只有當需求真的變細時，才切到結構化欄位。

如果你在做搜尋產品，這個方向很值得抄：先接住粗需求，再慢慢收斂，不要一開始就拿表單嚇人。

Google 終於把 agent 講得像能做雜事了

“Google Spark is a new ‘24/7 personal agent’ built into Gemini.”

白話就是，Google 想做的不是你問它才動，而是它能在背景裡盯事情、抓訊號、幫你處理一些瑣碎但很煩的協調工作。文章裡提到 Spark 可以從 email 抓 Google Docs，串第三方 app，像 OpenTable、Spotify、Uber，還能把家庭行程、檔案更新這些高優先事項整理出來。

這段我就比較有感了。因為我早就受夠那種只會回答問題的 assistant。多數人根本不需要一個會講話的搜尋引擎，他們需要的是一個能幫忙收拾事情的協調員。有人改會議時間、有人丟檔案、有人臨時要訂位，這些事情單獨看都不難，但串起來就很煩。agent 真正有價值的地方，就是把這種碎事接起來。

但我也不會太快高潮，因為這種東西最容易翻車的就是權限。它要能幫你做事，就得看得到你的資料；它要能幫你下單，就得能動你的帳號。Google 說使用者可以控制它能碰什麼，這是正確答案，但真正的關鍵是控制介面要不要人話。設定如果寫得像法律條文，大家不是亂開就是直接放棄。

實操上我會這樣設計：

• 先把它能看什麼、能做什麼，用白話列出來。
• 讀取權限和執行權限分開，別混在一起。
• 凡是會送出訊息、付款、下單的動作，都要保留人工確認。

我自己做自動化時最怕的不是它不聰明，而是它太敢做。能省時間的 automation，前提是邊界清楚；不然它只是把 cleanup 丟給我。Spark 這次看起來就是 Google 想往「有邊界的常駐代理」走，這比空喊 autonomous 靠譜一點。

而且它還有一個平台意味很重的地方：如果 Gmail、Docs、第三方服務都接進去，Google 就不只是索引你的資料，它開始在中介你的操作。這件事對開發者很重要，因為你以後做產品，可能不是在跟 Google 的搜尋競爭，而是在跟它的工作入口競爭。

智慧眼鏡這次終於不像玩具了

“You’ll be able to ask Gemini for information about your surroundings and receive detailed directions.”

翻譯一下就是，Google 和 Samsung 想把智慧眼鏡做成真的能用，而不是只會拍片的奇怪玩具。文章提到這副眼鏡有內建喇叭、麥克風、相機，而且能跟 iPhone 和 Android 一起用。更重要的是，裡面跑的是 Gemini，不是什麼降級版 sidecar 模型。

我對智慧眼鏡一直很有怨氣，因為這類 demo 通常只有兩種：一種是戴在臉上的攝影機，另一種是穿戴式尷尬。這次至少方向比較務實。Wirecutter 也拿它跟 Meta 的 Ray-Ban AI glasses 比，重點不是硬體炫不炫，而是 assistant 夠不夠強。這很合理，因為硬體只是載具，AI 不行的話，眼鏡就只是昂貴臉部裝飾。

文章裡我最想試的反而是很日常的流程：用語音透過 DoorDash 點咖啡，或把食譜裡的材料直接加進購物清單。這種任務才像眼鏡該做的事，因為它短、即時、而且你手上通常真的不方便掏手機。

如果你在做穿戴式或語音介面，我會很直接地說：不要再追求那種「哇」一下的展示，去做使用者本來就會在走路、拿東西、看環境時做的事。導航、購物清單、快速下單、看見什麼就查什麼，這些才是對的場景。其他太花的功能，通常只是把複雜度搬到臉上。

Google 和 Samsung 目前還沒講價格跟上市時間，這很煩但也正常。比較值得注意的是它們找了 Samsung、Warby Parker、Gentle Monster 這些合作對象。這代表 Google 很清楚，這東西如果長得像實驗室樣品，正常人根本不會戴出門。

命名亂成一團，不是小事

“Google announced a slew of new AI tools… Many of them were confusingly named.”

也就是說，Google 內部可能知道每個名字代表什麼，但外面的人只會看到一坨名詞：Spark、Gemini 3.5 Flash、Omni、Antigravity。這不是單純的品牌問題，這是產品策略跟使用者理解沒對齊。你如果要我記這些名詞，我就先累了。

我不是在挑字眼。對開發者工具來說，命名就是介面的一部分。你如果連名字都讓人搞不清楚，那我根本不想繼續研究。Wirecutter 那篇厲害的地方，就是它把一堆名稱翻回實際用途，讓我知道哪些是模型、哪些是產品、哪些是功能。

實操上我會這樣做：

• 模型名、產品名、功能名分開，不要全部混著叫。
• UI 上直接寫使用者結果，不要只寫內部架構。
• 文件裡再放技術名，別把使用者當成要背你們架構圖的人。

我自己的經驗是，名字一亂，整個產品就會開始長出一堆解釋成本。每個人都要先問「這到底是哪個東西」，那就代表你的產品還沒站穩。Google 這次的 AI 核心如果要鋪到 Search、Spark、眼鏡三條線，差異就必須靠行為說話，不然最後只會變成同一個助手換三套皮。

真正的標準很無聊：有沒有幫我省時間

“As always, you’ll need to check the AI’s work to confirm that it’s accurate.”

翻譯一下就是，Google 自己也知道這些東西還是會出錯，所以你不要把方向盤直接丟掉。這句話很誠實，但也把標準講死了：不是看它多會講，而是看它有沒有減少重工。

我現在評 AI 功能都用很土的標準。搜尋如果能讓我少改三次 query，它就有用。agent 如果能幫我持續盯更新，它就有用。眼鏡如果能讓我少掏一次手機，它就有用。只要它開始製造新的驗證成本，立刻打回原形。

所以我會這樣檢查任何 agentic workflow：

• 它到底是省掉哪一步？
• 它有沒有把工作從人手上搬到另一個地方？
• 它失敗時，是不是會留下可回收的草稿，而不是亂送出東西？

這也是我覺得這次 Google I/O 值得拆的原因。它不是因為發了很多新玩具，而是因為它終於比較明確地把 AI 對準真實工作：搜尋、監控、協調、下單、看環境。這些都還不完美，但方向夠清楚了，已經可以拿來設計自己的產品和 prompt。

老實講，我寧可看一個方向不那麼漂亮、但能拆解的產品，也不想再看那種滿口願景、最後什麼都接不起來的 demo。對開發者來說，能抄的不是口號，是工作流。

可抄的模板

# 把 AI 產品拆成 agentic workflow 的模板（可直接貼到筆記或 PRD）

## 1. 先定義它不是什麼
- 不是「更會聊天的 chatbot」
- 不是「只會回答一次的搜尋框」
- 不是「看起來很忙但不會做事的 demo」

## 2. 這個功能真正要改變的工作流
- 使用者原本要做的事：________________
- 現在希望 AI 幫忙接走的步驟：________________
- 需要持續監控的訊號：________________
- 需要跨 app 協調的動作：________________

## 3. 權限與邊界
- 這個 agent 可以讀取：________________
- 這個 agent 可以執行：________________
- 需要人工確認的動作：________________
- 失敗時要回傳的狀態：________________

## 4. 介面設計原則
- 先讓使用者用自然語言描述需求
- 再在同一個介面內做追問
- 只有在需要精準控制時才切換成表單或 filter
- 不要把模型名當成使用者要記的東西

## 5. 評估標準
- 是否真的省下時間
- 是否減少重工
- 是否留下可檢查的草稿
- 是否避免錯誤動作直接發出
- 是否能被一般使用者理解

## 6. 可直接用的 prompt
你是產品設計顧問，請把下面這個 AI 功能拆成可落地的 workflow。

請輸出：
1. 這功能真正改變了哪個工作流
2. 它需要哪些資料與權限
3. 它可以做哪些動作，哪些要人工確認
4. 它最可能失敗在哪裡
5. 這功能怎麼設計才不會增加 cleanup
6. 如果要做成 MVP，先砍掉哪些部分

功能描述：
[在這裡貼上你的功能說明]

## 7. 我自己的判斷句
- 如果它只是回答問題，不算 agent
- 如果它會做事但邊界不清，不算可上線
- 如果它不能省時間，只是在搬運工作，不值得吹

這份模板是我根據 Google I/O 這種發表會整理出來的，不是原文照抄。原始來源是 Wirecutter 的回顧文章，以及 Google I/O 官方頁面。我把它轉成比較適合開發者直接拿去寫 prompt、PRD 或內部筆記的版本。

如果你要回頭看原始內容，先讀來源，再拿這份模板去拆你自己的產品。這樣比較不會只記得新聞標題，卻忘了真正該抄的是工作流。