iOS 27 Siri 可能改靠 Gemini

我拆解 iOS 27 Siri 可能改用 Gemini 與自動刪除聊天的報導，順手給你一份可直接套進 AI 產品的刪除與 fallback 架構模板。

我做 AI 助手做到現在，早就不會被 demo 唬住了。我最在意的反而是那些卡卡的地方：模型回得很快、語氣很像人、介面也做得很順，但一問到資料留多久、出了錯誰接、換模型會不會整組炸掉，團隊就開始閃。那種「看起來很聰明，其實只是把問題往後拖」的感覺，我很熟，也很煩。

Apple 的 Siri 這幾年給我的感覺也差不多。不是不能用，是常常只能用到一半，接著就開始裝傻、踢皮球、或者假裝自己懂了。當我看到這則關於 CNET 轉述 Mark Gurman 的 Bloomberg 報導時，我第一個反應不是驚訝，是覺得終於有人承認：這種助手不能再只靠包裝，得把後端策略老老實實補起來。

這次的重點很直白：傳聞 Apple 可能在 iOS 27 的 Siri 上大量依賴 Google Gemini，還會加上聊天自動刪除選項。這不是什麼空泛的「Apple 正在探索 AI」；這是把模型供應商、資料保留、使用者信任三件事直接攤在桌上。這種細節，比一百篇形容詞堆滿的 AI 新聞都更值得看。

Apple 不是在加 AI，是在外包最難的那段

Apple's Siri app in iOS 27 will get an auto-delete option for chats and will also rely heavily on Google's Gemini for its AI chatbot operations.

翻譯一下就是：Apple 可能不再假裝自己要從底層一路包到頂，而是把最吃模型能力、最吃調校、也最吃算力的那一層交給 Gemini。這件事很務實，也很現實。因為模型層本來就是最燒錢、最容易出包、最不值得每家公司都重造一次的地方。

我看過太多團隊卡在這一點。產品明明只是需要一個能回答、能查資料、能接工具的助手，結果大家先吵「我們一定要全自研」。最後不是做出一個更好的系統，而是做出一個更貴、更多 bug、還更難維護的版本。面子有了，產品沒了。

所以我現在的判斷很簡單：模型供應商可以換，助手外殼不能亂。UI、工具層、記憶規則、刪除政策，這些都應該獨立於 Gemini、OpenAI、Anthropic 或任何一家模型。你如果把這些東西綁死，第一次換供應商時就會知道什麼叫自找麻煩。

• 把 assistant shell 跟 model provider 分開。
• 模型呼叫全部走 adapter，不要直接散落在各個頁面。
• 保留政策不要寫死在 prompt 裡，應該在產品層控制。

自動刪除不是附加功能，是信任本體

另一個我覺得更重要的點，是自動刪除聊天。這聽起來很小，但在 AI 產品裡，這其實是信任機制，不是設定頁角落那種可有可無的小開關。

翻譯一下就是：如果使用者知道對話會自動消失，他就比較敢拿它做真正私人的事；如果他不知道資料會留多久、會不會被拿去訓練、會不會被另一套系統偷偷保存，他就只會把這助手當玩具。這不是心理學廢話，這是產品使用率。

我以前也犯過這種錯。以為刪除功能是法務或資安才會在意的東西，結果上線後才發現，使用者根本不是在問「你合不合規」，他們是在問「你會不會把我剛剛講的話留著」。這兩件事差很多。前者是內部語言，後者才是人話。

我會把刪除拆成三層，這樣比較不會裝睡：

• 原始聊天內容：真正的訊息紀錄，該自動刪就刪。
• 衍生記憶：偏好、摘要、長期記憶，獨立管理，不要跟聊天紀錄混在一起。
• 操作稽核資料：只留最少的必要紀錄，盡量匿名化、時間盒化。

很多團隊最愛偷懶的地方，就是把「看得到的聊天」刪掉，卻把有用資訊換個欄位藏到別張表。使用者不管你欄位名稱叫什麼，他只在乎你有沒有真的刪。

Gemini 進 Siri，代表 orchestration 終於比模型更重要

如果這個報導是真的，那 Siri 就不是單純的模型問題了，而是 orchestration 問題。這句話我講得很硬，因為我真的看過太多人把 AI 產品做成「一個超大 prompt」，然後每天祈禱模型別發瘋。

翻譯一下就是：你需要先決定這個請求該不該進模型、該不該走本地工具、該不該直接查結構化資料、還是該拒答。不是每個問題都值得把 token 丟給大模型。像計時器、聯絡人查詢、裝置控制這種事，本來就應該走 deterministic path，不要浪費錢也不要增加延遲。

我之前做過一個內部文件助手，前期也犯過同樣的毛病。模型很會講解，但它很不會判斷自己應不應該先去搜資料。後來我加了一層 intent router，把請求分成幾類，整個系統瞬間正常很多。不是因為模型變神了，是因為我終於不再把它當萬能。

實操上，我現在會這樣做：

• 語言生成、摘要、改寫交給模型。
• 結構化任務交給工具或資料庫。
• 先路由，再決定要不要送進模型。

如果 Apple 夠聰明，Siri 不會是「一個巨型 prompt」，而是「一個 policy engine 包著模型供應商」。這才是能活下來的架構。

隱私不是文案，是資料流裡的硬規則

Apple 把 AI 跟刪除機制放在一起談，我不覺得只是巧合。它很清楚自己的用戶吃這套，也很清楚 AI 助手本質上就是資料吞噬機器。你只要讓它多記一點，它就會多吃一點。

翻譯一下就是：隱私不能放在發表會簡報裡，得放在資料流裡。請求什麼時候離開裝置、送到哪裡、存多久、怎麼摘要、何時清除，這些都要在產品設計階段就定死，不是上線後再補公告。

我最怕的就是那種「先上線再補隱私」的做法。這種產品通常會先把最方便的路徑做滿，等到真的有人問資料怎麼處理，才開始加 consent、加 retention、加刪除按鈕。結果整個系統像貼膠帶補破洞，越補越難看。

如果是我在做，我會至少做到這幾件事：

• 需要時先取得明確同意，再做雲端處理。
• 每個聊天都能單獨刪，不要只給整包清空。
• 保留時間要明講，不要只寫「我們可能保存一段時間」。
• 送出模型前，先做明顯敏感欄位的 redaction。

最後這點很重要。電話、地址、帳號、身分資訊，能先遮就先遮。不要把模型當第一道防線，那個方向本來就錯了。

Apple 真正可能做對的，是把權責切清楚

這則消息最有意思的地方，不是 Gemini 本身，而是它透露出 Apple 可能終於接受一件事：最好的模型不一定要自己做，重要的是你能不能把使用者體驗、裝置整合、刪除控制、權限管理做好。

翻譯一下就是：Siri 如果真的變強，不會是因為它「更像人」，而是因為它終於比較像一個可靠的介面。Gemini 負責 reasoning 和 generation，Apple 負責 UX、裝置、隱私與權限。這樣拆，比硬逼一個內建模型什麼都會好得多。

我不是在說外部模型依賴沒有代價。當然有。延遲、成本、供應商風險、政策漂移、行為變動，這些都是真麻煩。尤其是上游模型一更新，你的助手行為也跟著飄，這種事我吃過虧，不想再吃第二次。

但就算這樣，我還是寧可要一個會變動、但架構清楚的系統，也不要一個封閉、脆弱、永遠只會說「我們正在努力改善」的助手。前者至少能修，後者通常只是包裝比較像樣。

所以如果你現在也在做 AI 產品，我給你的建議會很無聊，但通常無聊的才是真的：

• 你要控制的是使用者接觸面，不是硬把模型全包。
• 模型供應商一定要抽象化。
• 刪除要做成一等公民，不要當附屬設定。
• fallback 要先設計，不要等故障發生才想。

可抄的模板

# AI 助手架構模板：模型可替換 + 自動刪除 + fallback 路由

## 1) 核心原則
- assistant UI 不知道目前接的是哪一家模型。
- 每段對話都能單獨設定保留政策。
- 刪除要作用在原始聊天，不只是畫面上的紀錄。
- 送出上游前先做敏感資訊 redaction。
- 先路由，再決定是否要進模型。

## 2) 資料結構
conversation {
  id: string
  user_id: string
  provider: "gemini" | "openai" | "anthropic" | "local"
  retention_policy: {
    mode: "manual" | "auto_delete"
    delete_after_hours: number | null
  }
  raw_messages: []
  derived_memory: []
  audit_metadata: []
}

## 3) 請求流程
1. 使用者送出訊息。
2. redaction 層先遮掉明顯敏感欄位。
3. router 分類 intent：
   - local_tool
   - cloud_model
   - retrieval
   - refusal
4. 如果需要 cloud_model，就走 provider adapter。
5. 儲存回應。
6. 依照 retention policy 排程刪除。
7. 到期後刪掉 raw_messages。
8. 若法規需要，只保留最少的 audit metadata。

## 4) Provider adapter interface
interface ModelProvider {
  generate(input: {
    systemPrompt: string
    messages: Message[]
    tools?: Tool[]
    temperature?: number
  }): Promise
}

## 5) 刪除規則
- raw chats 可在 N 小時後自動刪除。
- derived memory 只有在使用者取消同意或刪帳號時清除。
- 不要另外偷偷留一份 raw messages。
- 刪除事件可以記錄，但不要記內容。

## 6) 對使用者顯示的設定文案
- 自動刪除聊天：24 小時 / 7 天 / 30 天 / 關閉
- 立即刪除這段對話
- 清除我被記住的偏好
- 查看這個助手存了什麼
- 匯出我的資料

## 7) 失敗處理
- provider 掛掉就走本地 fallback 或直接道歉。
- 刪除失敗要重試，並顯示狀態。
- router 不確定時，選更安全的路徑。
- 模型回覆格式不對，不要自己亂猜。

## 8) 最小 API
POST /chat
POST /chat/:id/delete
POST /chat/:id/retention
GET  /chat/:id/export
GET  /settings/privacy

## 9) 一句產品規則
如果使用者看不懂資料存什麼、誰在處理、什麼時候消失，這個助手就還沒準備好。

這就是我會拿來重做 Siri 或任何 AI 助手的版本。模型供應商可以換，但信任契約不能亂改。

來源我主要看的是 CNET 這篇對 Mark Gurman 報導的整理；架構模板是我自己拆完後整理的衍生版，不是原文內容。若你要回頭看原始脈絡，先從 CNET 這篇開始最省事。