Gemini 新聲音把聊天變成清單

我拆 Gemini 新 voice picker、Live 聲音與 widget 圖示更新，整理成可直接套用的 UI 模板。

我用 Gemini 有一陣子了。模型本身沒什麼大毛病，問題一直卡在介面：聲音選單像在滑相簿，Live 跟一般聊天又像兩個不同產品，widget 也常常只是把一堆功能塞進小框框，結果看起來很忙，實際上很難用。你明明只是想換個聲音，卻得在一個像玩具的 picker 裡慢慢翻。這種卡頓感很煩，因為它不是功能不夠，而是產品在最常碰到的地方不夠乾脆。

我後來注意到這次變動，才發現 Google 其實是在做一件很務實的事：把 Gemini 從「看起來很 AI」拉回「真的比較好操作」。聲音選擇改成清單，Live 與主聊天的聲音開始對齊，widget 圖示也換成更乾淨的 Neural Expressive 風格。這些都不是大新聞，但這種小改動最誠實，因為它直接暴露團隊到底懂不懂使用者怎麼切換、比較、啟動功能。

我被觸發的來源是 9to5Google 的 Abner Li 這篇短文。它沒有端出什麼誇張數字，也沒有官方長文，只有一個很明確的訊號：Gemini app 正在透過 server-side rollout 更新 voice picker、Gemini Live 聲音，還有 widget icon 套件。這種更新方式通常最值得拆，因為它代表產品團隊不是在發表會上講願景，而是在修日常摩擦。

聲音選單改成清單，因為橫向輪播真的很煩

Go to Gemini Settings > Gemini’s voice for a redesigned voice picker. Instead of a carousel, you get a list.

翻譯一下就是：Google 終於不再逼你用橫向輪播挑聲音了，改成一個老派但好用的清單。這不是退步，這是承認現實。當選項需要比較時，清單幾乎永遠比 carousel 好用。你不用猜還有沒有下一個，眼睛掃過去就知道有哪些，選起來也比較不會漏。

我自己最受不了的就是那種「看起來很漂亮」的設定頁，實際上每個選項都躲在側滑裡。你要比較 A 跟 B，結果得左右滑來滑去，還要記住剛剛那個聲音到底叫什麼。這種介面很像在測試使用者耐心，不像在幫人做設定。Gemini 這次把 voice picker 改成 list，我反而覺得像是終於把產品從展示櫃搬回工作台。

實操寫法很簡單：如果你的產品有模式、預設、語音、主題、代理人格這種互斥選項，先做成清單，再想要不要加預覽。不要一開始就把它包成輪播。輪播適合視覺本身就是重點的東西，不適合拿來藏設定。你要的是比較，不是逛展覽。

• 需要比較的選項，用 list，不要先上 carousel。
• 選項名稱要一眼可讀，別塞太多描述字。
• 選中狀態要直接看得到，不要再點一次才知道自己選了什麼。

這裡還有一個很細但很重要的點：清單會逼產品團隊重新思考資訊層級。當你不能靠滑動製造「有很多選項」的錯覺時，你就得真的整理選項。這件事很煩，但也很值。因為很多 UI 問題，本質上不是畫面不夠漂亮，而是選項結構本來就亂。

Flare 和 Glow 不是改名而已，是在重整聲音的記憶點

“Flare” and “Glow” are two new additions that replace Nova and Lyra.

也就是說，Gemini 的聲音名單不是只換皮，而是把一部分命名重新洗過。Nova 和 Lyra 被 Flare、Glow 換掉，其他像 Ursa、Vega、Pegasus、Dipper、Eclipse、Capella、Orbit、Orion 這些名字還在。這種命名方式很有意思，因為它介於「有性格」跟「不會太難懂」之間。

我一直覺得 preset 命名是很多團隊最容易偷懶的地方。不是叫 Bright、Calm、Balanced，就是叫 Mode 1、Mode 2、Mode 3。前者太像描述文案，後者太像工程師懶得想。Gemini 這組名字至少有記憶點，使用者比較可能記得「我上次用的是 Glow」，而不是「那個比較亮的那個」。這對語音系統很重要，因為聲音不是靜態圖示，選過一次之後還要能回來找得到。

我之前做過一個工具型產品，裡面有一堆 preset。最早我們用功能描述命名，結果客服一直收到同樣的問題：哪個是比較穩的？哪個是比較快的？哪個是給新手的？後來我們改成簡短命名，再配一個 sample，使用者反而比較快做決定。名字不是拿來解釋功能的，名字是拿來讓人記住和回頭找的。

實操寫法是這樣：如果你要替 voice、theme、assistant persona、AI mode 命名，先決定命名規則，再決定數量。不要今天一套、下週又一套。名稱要穩，例子要短，說明要放在清單外面，不要塞進每個選項裡把畫面弄髒。

• 命名要能被記住，不要只會被讀懂一次。
• 數量控制在使用者能一次看完的範圍。
• 每個選項最好有 sample 或 preview，別只靠文字說明。

這一段我會特別注意，因為語音系統很容易變成「工程上有很多分支，使用者看起來卻像一團」。命名就是幫你把那團東西整理成可理解的分類。Gemini 這次至少有在做這件事。

Live 跟主聊天聲音不一致，使用者只會覺得你很分裂

Following last week’s Neural Expressive redesign, the Gemini app is rolling out new voices for the main chat experience and Gemini Live.

翻譯一下就是：Google 開始把主聊天跟 Gemini Live 的聲音體驗拉近了。這件事看起來很小，但我覺得它其實是整個 assistant 體驗有沒有「像同一個人」的分水嶺。使用者不會在腦中分成「文字版 Gemini」和「語音版 Gemini」，他們只會覺得自己在跟 Gemini 講話。如果兩邊聽起來差很多，信任感就會掉。

我以前碰過一個語音助理專案，文字模式很精準，語音模式卻故意做得很熱情。團隊以為這叫有性格，結果使用者回饋很直白：你們怎麼每個模式都像不同產品？這就是問題。不是不能有差異，而是差異不能大到讓人覺得系統人格分裂。語氣、節奏、詞彙感，最好都得在同一個範圍內。

實操上，這種一致性要先從規格定義。你要先講清楚：這個 assistant 的語氣是偏冷靜、偏直接、還是偏陪伴型。然後把這個定義套到 chat、live、通知、快捷入口，甚至錯誤訊息。不要讓每個 surface 自己長出一套性格，最後再怪使用者不懂。

如果你的產品同時有 text 與 voice，我會建議你直接做一份 voice identity sheet。不是品牌手冊那種空話，而是很實際的東西：常用詞、禁用詞、回應長度、停頓節奏、失敗時怎麼說。這些東西一旦沒有統一，使用者很快就會把它當成兩個不同系統。

• 先定義同一個語氣範圍，再去做不同 mode。
• 文字與語音不要各自長出不同人格。
• 錯誤訊息也要跟主體驗同一種語氣。

我會特別盯這點，因為 AI 產品最常犯的錯就是把「多模態」做成「多個碎片」。Gemini 這次的方向比較像是把碎片收回來，至少在聲音層面是這樣。

Neural Expressive 圖示變薄，widget 才終於不像一包工具箱

Meanwhile, the widget layouts are unchanged from before, but all icons have been refreshed. Neural Expressive makes use of thin outlines for the Microphone, Camera, Gallery, File, Video, Screenshare, and Live.

也就是說，widget 的結構沒動，動的是圖示語言。這個選擇我很買單。因為很多團隊一碰到 widget 或快捷面板，就會忍不住想重排全部功能，好像不折騰一下就不算改版。其實大多數時候，使用者不需要新布局，他們只需要畫面乾淨一點、辨識快一點。

Thin outline 的效果就在這裡。它不會搶走注意力，但能把整個小面板的視覺重量壓下來。尤其像 Microphone、Camera、Gallery、File、Video、Screenshare、Live 這種高頻動作，圖示比裝飾重要得多。你要的是一眼辨識，不是設計獎。

我自己很怕那種 widget 圖示風格不一致的產品。A 是實心、B 是線框、C 又忽然變得很圓潤，整個面板看起來就像不同人各畫各的。這次 Gemini 至少做對了一件事：先把圖示統一，再保留原本的動作布局。這種做法很像老司機會選的路線，因為它先修最容易讓人煩的地方。

實操寫法：如果你有 launcher widget、quick action panel、floating tray，先把「動作地圖」固定下來，再調圖示粗細、對比、間距。不要一口氣改 layout 和 icon 風格，除非你想連 A/B test 都不知道是誰害的。小面板的原則很簡單：認得出來，比好看更重要。

• layout 穩定，圖示風格先統一。
• 高頻動作優先，別把常用功能藏在次要位置。
• 圖示要在小尺寸下仍能辨識，別只顧桌面截圖。

這種改法很務實，也很像 Google 現在對 Gemini 的態度：不急著重做整套，而是先把最容易卡住的地方磨順。這比喊口號有用多了。

Server-side rollout 的價值，是讓產品先學會閉嘴

This is rolling out via a server-side update with the latest version (1.0.913571982) of the Gemini “app”/homescreen shortcut.

翻譯一下就是：Google 沒有把這次更新包成一個大張旗鼓的版本發表，而是用 server-side 方式慢慢推。這種做法很適合 UI 微調，因為你可以先看一小部分使用者的反應，再決定要不要擴大。對產品團隊來說，這比一次全推省很多麻煩。

我其實很喜歡這種「先安靜地改，再看有沒有人真的比較順」的節奏。因為大部分 UI 問題都不是功能不存在，而是摩擦太多。server-side rollout 讓你可以只改 voice picker、只改 icon、只改默認 voice set，而不是逼整個 app 一起翻新。這樣你才知道到底是哪個改動真的有用。

實操上，如果你在做 AI 產品，我會建議把 model、UI、branding 分開處理。模型調整是模型調整，介面調整是介面調整，別一次全塞進 release note。你如果把所有東西混在一起，最後只會得到一堆「好像有變好，但不知道是哪裡變好」的回饋。

還有一個很實際的做法：把 server-side config 用在那些看得見、但不影響核心資料結構的地方。像 picker 排列、快捷入口、圖示樣式、預設聲音，都很適合。這些地方改錯了還能回收，改對了卻立刻有感，最適合拿來做漸進式優化。

Gemini 這波不是大改版，是把日常摩擦一個個削掉

Following last week’s Neural Expressive redesign, the Gemini app is rolling out new voices for the main chat experience and Gemini Live.

我看完這波更新的感想很直接：它不是在炫技，是在把使用者每天都會碰到的卡點往下壓。聲音選單更好掃，Live 和主聊天更像同一個系統，widget 圖示更清楚。這些都不是會被截圖瘋傳的東西，但正因為不搶戲，才更像真的產品工作。

我一直覺得 AI 產品很容易犯一個毛病，就是太愛把模型能力當成介面。結果使用者明明只是想完成一件事，卻被迫理解一堆產品內部邏輯。Gemini 這次的方向比較像反過來：先讓人比較好選、比較好看、比較好啟動，再談其他。這才是工具該有的樣子。

實操寫法我幫你整理成一句話：如果你的 AI 產品有 voice、live mode、widget、quick action，先把它們整理成同一套操作語法。清單比輪播好，穩定布局比亂改好，一致語氣比各說各話好。這三件事做好，很多你以為要靠大改版才能解的問題，其實就會少一半。

可抄的模板

# AI 語音與 Widget UI 改版模板（可直接套用）

## 1. Voice Picker
- 使用 list，不使用 carousel。
- 每個 voice 顯示一行：名稱 + 1 句短描述。
- 選中狀態直接高亮，不再額外點進去確認。
- 若需要 preview，放在列表右側或列表下方，不要藏到二級頁。

### Voice 命名規則
- 名稱要短、穩定、可記憶。
- 同一套命名規則只用一種風格，不要今天描述型、明天抽象型。
- 例：Flare / Glow / Orbit / Dipper / Vega

## 2. Voice Identity
- Chat、Live、通知、錯誤訊息使用同一語氣範圍。
- 定義：
  - 語氣：冷靜 / 直接 / 友善
  - 長度：短句優先
  - 禁用：過度擬人、過度熱情、每句都像在演戲
- 讓不同模式共享同一份 voice spec。

## 3. Widget / Quick Action
- 保持 layout 不變，先改 icon style。
- 使用單一 icon weight，優先 thin outline 或統一線條粗細。
- 高頻動作放第一排：Microphone / Camera / Gallery / File / Video / Screenshare / Live
- 小尺寸下仍可辨識，避免裝飾細節過多。

## 4. Rollout
- 先用 server-side flag 推出。
- 先改 picker，再改 icon，最後才動預設值。
- 每次只改一層，避免無法判斷是誰造成使用者困惑。

## 5. 產品備註文案
我們把 voice carousel 改成 list，讓使用者更快比較選項。
我們保留 widget layout，只更新 icon style 以提升辨識度。
我們統一 chat 與 live 的 voice 風格，減少模式切換時的割裂感。

這段我自己會直接拿去改成 PRD 或設計規格。重點不是 Gemini 的名字，而是它背後那套順序：先讓選項好掃，再讓語氣一致，最後才去美化圖示。這種順序很少出錯。

來源主要是 9to5Google 的原文。我上面寫的判斷、拆法和模板，是我根據這篇報導延伸出來的實務整理，不是 Google 內部文件的轉述。

如果你想自己看產品表面，我也放上 Gemini 官方頁、Google Play app 頁面，還有 Google Gemini 更新頁。我這篇負責拆方法論，原始來源負責告訴你這次到底改了什麼。