Wear OS 7 把手錶更新變成即時上下文

Wear OS 7 先補上 Live Updates 與電量，再把 Gemini 留到後面，讓手錶回到即時狀態與低摩擦操作。

我用 Wear OS 很久了，久到已經不太會被每次更新的宣傳詞騙到。每次 Google 說手錶又變聰明了，我都先想：通知會不會還是慢半拍？電量會不會還是一樣讓人焦慮？我是不是又得把充電器當成隨身配件？最煩的是，很多更新看起來很忙，實際上只是把問題包裝得比較好看。手錶如果不能讓我少看幾次手機，那它再花俏也只是另一個要照顧的裝置。

這次我會停下來看 Android Headlines 的這篇整理，是因為它把 Wear OS 7 的重點講得很直白：Google 先推 Live Updates 和更好的電量，Gemini 智慧功能晚一點才上。這種順序很少見，但我反而覺得比較像真的在解決手錶問題，而不是在做簡報。

先補日常痛點，這次順序終於對了

“The update includes things like Live Updates and improved battery life, both of which are part of the update starting today.”

翻譯一下就是：Google 先處理你每天都會碰到的痛點，不是先端出一個看起來很厲害、但你其實不常用的功能。這點我很買單。因為手錶最討厭的不是不聰明，是不穩。通知慢、電量差、資訊斷掉，這些才是使用者每天在罵的事。

我以前做過一個穿戴式通知頁，團隊一開始很愛把它做得像迷你手機首頁，結果問題一堆。畫面很多、層級很多、動畫很多，但使用者只想知道「現在進度到哪」。後來我把它砍成一個狀態卡，資訊少很多，抱怨也少很多。手錶不是縮小版手機，它比較像一個隨時可掃過的狀態欄。

這次 Wear OS 7 的節奏，至少在方法論上是對的：先讓人感覺得到改善，再談更大的野心。對開發者來說，這代表你該重新檢查自己的 wearable 介面是不是太貪心。很多功能其實不該先想「能不能在手錶上做」，而是先問「這個狀態需不需要被即時知道」。

實操寫法很簡單：

• 把所有 wearable 功能先分類成「即時狀態」與「延後操作」。
• 凡是使用者會反覆確認的東西，優先做成一眼看懂的摘要。
• 如果 2 秒內說不清楚現在發生什麼事，那這功能大概率不適合手錶。

Live Updates 不是新玩具，是手錶該有的工作方式

“As for Live Updates, this is a way to track real-time information.”

這句很短，但我覺得它把方向講對了。Live Updates 的本質不是多一個 API 名字，而是承認手錶最適合做的是「持續顯示變化中的狀態」。也就是說，它不是讓你一直打開 app，而是讓 app 的進度自己活在手腕上。

我之前看過太多 wearable 體驗卡在這裡：使用者收到一次通知，之後就沒了。外送到哪、火車還有多久、訂單是不是出貨了，全都要再打開一次 App 才知道。這種設計很浪費。因為手錶的價值不是把手機內容搬過來，而是把「我現在需不需要再拿手機」這件事延後。

Google 在文中舉的例子很實際，像是外送進度、運動比分。這些都不是炫技場景，卻剛好是最適合手錶的場景。它們有共同點：狀態會變、使用者會重看、而且每次都只想知道一小段資訊。這就是 Live Updates 真正有用的地方。

如果你是產品或工程，實作時我會這樣拆：

• 先定義一個唯一的「目前狀態」資料結構，不要讓 watch 自己猜。
• 讓手機與手錶共用同一份後端狀態，不要各自維護。
• 把變化點寫清楚，例如「已接單」「已取餐」「配送中」，不要只放一條模糊進度條。

這樣做的好處是，手錶不需要承擔完整流程，只要把使用者最在意的那一格資訊守住就好。

電量不是附加價值，是穿戴裝置的信任基礎

“Google says battery life is 10% better compared to Wear OS 6.”

10% 聽起來不大，但在手錶上這種數字很誠實。因為穿戴裝置最容易被電量打臉。你可以原諒它慢一點、醜一點，但很難原諒它一天還沒過完就開始求充電。手錶一旦讓人開始算電量，它的存在感就會從「方便」變成「麻煩」。

我很少把電量改善當成新聞主角，但在 Wear OS 這種產品上，電量就是主角。你做再多智慧功能，只要背景工作太吵、同步太頻繁、動畫太重，使用者最後只會記得：這玩意兒又要充了。那不是印象差，是產品信任直接掉下去。

所以我看到 Google 先講電量，我反而覺得比較務實。不是每次更新都要搞得像大改版，先把使用者每天都會感受到的痛點壓下來，才有資格談下一步。這也提醒開發者，別把「背景同步」當成免費午餐，手錶上每一次喚醒都在燒預算。

實操上我會這樣做：

• 把輪詢改成事件驅動，能推送就不要一直查。
• 把背景同步頻率降到最低可接受值。
• 所有動畫、圖片、資料刷新都先問一次：這真的值得喚醒手錶嗎？

如果你的 wearable 版本還在狂跑背景工作，那先別談新功能，先談省電。

Gemini 晚點來，這很煩，但其實合理

“The Wear OS 7 launch will not initially include Gemini Intelligence.”

白話就是：這次先不把 AI 助理完整塞上來，先把底層體驗補好。老實說，這安排我雖然嫌它慢，但不算錯。因為如果基礎體驗還爛，AI 再聰明也只是把爛事講得更順口。

文章提到 Gemini 後面會帶來個人化協助，還能在手腕上做多步驟的 app 自動化。這才是有意思的地方。不是聊天而已，而是把一些原本要你自己點來點去的流程，變成可串接的動作。這種東西如果做得好，手錶才真的從通知鏡子變成操作入口。

但我也得潑點冷水。手錶輸入本來就不舒服，語音、點按、滑動都有限。如果 Gemini 只是把原本的操作包裝成更聰明的建議，最後還是要你手動確認一堆步驟，那它只是比較會講話，不是真的比較省事。

我會建議團隊這樣準備：

• 先盤點哪些動作可以安全串成多步驟流程。
• 把 intent 與狀態轉換整理乾淨，不要只做畫面。
• 每個會出錯的地方都設計好手錶上看得懂的失敗訊息。

如果你現在就在做 wearable workflow，先把流程整理乾淨，後面 Gemini 才有東西可接。

Pixel Watch 先吃到更新，這種分批我已經很熟了

“Google is likely to start with its most recent offering, the Pixel Watch 4.”

這句很像 Google 一貫的節奏：說是今天開始推，但實際上你什麼時候拿到，還要看機型、地區、電信商、甚至當天的 rollout 狀態。文章也提到 Pixel Watch 2 和 Pixel Watch 3 會相容，但相容不等於同時到手。這種事我看多了，早就不會把「已發布」跟「我現在能裝」畫上等號。

對開發者來說，這很重要。因為你不能只測最新款，然後假裝其他裝置都一樣。穿戴裝置的碎片化雖然沒有手機那麼誇張，但在 rollout、carrier support、硬體效能這幾個地方，還是很容易踩到差異。尤其是你如果要支援通知、背景同步、或即時更新，老機型的表現常常會比較難看。

所以我會這樣做：

• 測試時至少跑一次最舊的支援機型，不要只看新機。
• 文件裡把「相容」和「已全面開放」分開寫。
• 客服或內部支援流程先準備好分批更新的說法，別讓使用者以為自己漏掉了什麼。

這種 rollout 本來就不整齊，與其抱怨，不如把支援流程寫得更老實。

這次真正的重點，是把手錶拉回它該做的事

我看完 Wear OS 7 的第一個感覺，不是「哇好多功能」，而是「Google 終於比較像在做手錶，而不是做縮小版手機」。Live Updates、電量改善、之後才上的 Gemini，這三件事其實指向同一件事：手錶要的是即時上下文，不是複雜介面。

這個方向我認同，因為它夠務實。手錶最強的地方從來不是資訊量，而是你抬一下手就能知道現在狀況。它應該做的是提醒、狀態、快速確認、簡單授權，而不是逼你在小螢幕上完成一整套手機式操作。只要這件事想清楚，很多設計問題都會自己縮小。

如果你在做 Wear OS 相關產品，我會把優先順序排成這樣：先做 live state，再顧 battery，再想 automation。順序錯了，後面都會很累。這次 Google 至少沒有把順序搞反，我覺得這比多一個花俏功能還重要。

可抄的模板

Wear OS 7 wearable design checklist for live context apps

1. 先挑對場景
- 外送與物流追蹤
- 計時器與排隊狀態
- 交通與行程資訊
- 運動比分
- 裝置或家居狀態

2. 定義唯一的 live state
- status
- last_updated
- next_expected_change
- action_available
- user_confirmation_required

3. 手錶畫面只保留三件事
- 目前狀態
- 下一步會變什麼
- 使用者現在能做什麼

4. 更新策略
- 優先 event-driven update
- 能 batch 就不要頻繁 sync
- 保留 last known state
- 非必要不要 polling

5. 電量規則
- 降低 refresh 頻率
- 壓縮 payload
- 少用高成本動畫
- 記錄 background wakeups

6. Gemini / automation 準備
- 把可串接的 intents 整理出來
- 明確標出需要確認的步驟
- 失敗狀態要能在小螢幕讀懂
- 不要把整個 app 流程硬塞給手錶

7. 測試清單
- 無網路
- 狀態延遲
- 分批 rollout
- 舊款手錶
- 功能只開一半

可直接貼進產品規格的句子：

"On Wear OS, the watch should show current state, not just open the app. If the status changes, the wrist should update without making the user hunt for it. Keep the experience glanceable, battery-aware, and safe to automate in steps."

這段我會直接貼進 spec。因為它不是在講漂亮話，而是在講手錶真正該扛的工作。

來源我主要拆的是 Android Headlines 這篇，以及 Google 的 Wear OS / Pixel Watch 相關資訊；前半段的拆解是我自己的開發者讀法，後半段模板是我整理成可直接拿去用的版本。