AI 功能該不該讓使用者感覺到？Apple 說不該

為什麼讀這份文件

在寫蒸餾精華第 4 段筆記的時候，我需要一個設計框架來回答：「AI 功能到底該怎麼跟使用者互動？」結果發現 Apple 的 Human Interface Guidelines 裡有一整章在講 Machine Learning，而且寫得非常克制——不談技術細節，只談使用者體驗。

Apple 的核心立場只有一句話：最好的 AI 是你感覺不到它存在的 AI。

這跟很多產品拼命標榜「Powered by AI」完全相反。以下是透過 Claude 協助閱讀原文後整理的導讀，標出關鍵觀點和延伸思考。

一、三種互動模式

Apple 把 ML 功能分成三種模式，每種模式使用者的容忍度完全不同：

1. 被動型（Reactive）——你問，我答

使用者正在做某件事，ML 在旁邊提供建議。

典型例子：iPhone 鍵盤的 QuickType。你打字打到一半，上面浮出三個建議字。你可以用，也可以無視。

延伸思考： 因為是使用者主動在做事，ML 只是「順便幫忙」，所以就算建議不準，使用者的反應頂多是「喔，不對」然後繼續打字。容忍度高。

2. 主動型（Proactive）——我沒問，你跳出來

ML 主動推送使用者沒有要求的東西。

典型例子：Siri Suggestions 在鎖定畫面上建議你「該出發去開會了」。

Apple 原文講得很直接：

People may have less tolerance for low-quality information.

延伸思考： 這種模式風險最高。因為你是「打斷」使用者，如果推送的東西不準確或不相關，使用者不會覺得「喔，AI 還在學」，而是覺得「煩死了」。所以主動推送的門檻應該極高——不確定就別推。

這讓我想到一個反面教材：很多 App 愛推通知，「你可能喜歡這個」、「好久沒用了，回來看看」。這就是門檻設太低的結果，使用者的反應不是感謝，是關掉通知權限。

3. 使用者主導型（User-controlled）——你來指揮 ML

使用者明確告訴系統要怎麼用 ML。

典型例子：相簿裡手動標記某張臉是「媽媽」，之後所有有這張臉的照片都會歸類在一起。

延伸思考： 這種模式最安全，因為使用者有掌控感。但代價是需要使用者付出學習成本。Apple 的做法是：能自動的先自動（被動型），讓使用者在有需要時才介入修正（使用者主導型）。

二、輸入：隱性回饋 vs 顯性回饋

ML 要進步，需要回饋。Apple 把回饋分成兩種，各有一條鐵律。

隱性回饋（Implicit Feedback）

使用者自然使用產品的行為，系統默默觀察。

例子：你在 Apple Music 每次都跳過某首歌 → 系統知道你不喜歡。你在 Safari 常常點某個書籤 → 系統把它排到前面。

Apple 的鐵律：

Don’t let implicit feedback decrease people’s opportunities to explore.

延伸思考： 這就是「資訊泡泡」（Filter Bubble）問題。如果系統根據你的行為越來越窄化推薦範圍，使用者就會被困在自己的偏好裡。Apple 的意思是：你可以學習使用者的偏好，但不能因此把其他選項藏起來。

YouTube 的推薦演算法就是反面教材——你看了一部陰謀論影片，接下來首頁全是陰謀論。Apple 顯然認為這不是好設計。

顯性回饋（Explicit Feedback）

直接問使用者覺得好不好。

Apple 的規則出乎我意料：

Don’t ask for both positive and negative feedback.

意思是：不要同時問「你喜不喜歡」。只在使用者看到不喜歡的東西時，提供「我不喜歡這個」的按鈕。

延伸思考： 為什麼？因為如果你同時放「讚」和「倒讚」，使用者會覺得每一筆結果都需要被評價，變成一種負擔。Apple 的邏輯是——好的結果不需要確認（使用者自然會用），壞的結果才需要修正管道。

還有一條：顯性回饋必須是自願的。不能強迫使用者評分才能繼續用。

校準（Calibration）

只在功能完全無法運作時才收集初始資訊。

例子：首次設定 Face ID 時需要你掃臉。

延伸思考： Apple 的標準是——能不問就不問。只有在「不問就真的沒辦法動」的時候才校準。很多 App 喜歡在使用者還沒體驗到任何價值之前就問一堆偏好設定，這在 Apple 的框架裡是不及格的。

三、輸出：模糊時多選、不確定時明說

多重選項（Multiple Options）

當使用者的意圖不明確時，給多個選項，而不是猜一個。

例子：Siri 搜尋「John」，手機裡有三個 John → 列出三個讓你選，而不是自作主張打給某一個。

延伸思考： 這跟 AI Chatbot 的設計完全呼應。當使用者的問題模糊時，好的設計是反問或列選項，而不是硬掰一個答案。

歸因（Attribution）

解釋系統為什麼做這個決定。

例子：「因為你昨天搜尋了機票，所以推薦這間飯店。」

延伸思考： 這是建立信任的關鍵。使用者不需要知道技術細節（什麼 Transformer、什麼向量搜尋），但需要知道「為什麼給我看這個」。不解釋的推薦會讓人不安——「它怎麼知道的？」

信心度（Confidence）

把模型的信心指數翻譯成人類能懂的語言。

例子：天氣 App 說「降雨機率 30%」而不是「模型信心度 0.7」。

延伸思考： 關鍵是「翻譯」。Raw 數字對使用者沒有意義。好的設計是把機器的確定程度轉換成使用者可以拿來做決策的資訊。「可能會下雨，建議帶傘」比「precipitation probability: 0.3」有用一萬倍。

局限性（Limitations）

Apple 原文：

Mistakes in machine learning are inevitable. Few models work 100% of the time.

延伸思考： 這句話看起來很平淡，但放在 Apple 的官方設計文件裡，份量很重。Apple 在告訴所有開發者：你的 AI 會出錯，你必須在設計裡就考慮到這件事，而不是假裝它不會出錯。

反面教材：那些聲稱「99% 準確率」的 AI 產品。99% 聽起來很高，但如果你一天用一百次，就是每天至少一次明顯的錯誤。使用者記得的永遠是那一次失敗，不是九十九次成功。

四、修正：錯了就好好修，但不能靠修來補救

Apple 對修正機制有幾條很嚴格的原則：

Never rely on corrections to make up for low-quality results.

延伸思考： 不能因為有「回報錯誤」按鈕，就覺得可以上線一個品質很差的模型。修正是最後一道防線，不是品質策略。

其他原則：

引導式修正優於自由輸入： 與其讓使用者打字告訴你哪裡錯，不如列出替代選項讓使用者選。例如語音辨識錯了，列出幾個可能的正確結果讓使用者點。
修正後立刻有反應： 使用者花時間修正你的錯誤，你至少要立刻讓他看到修正生效了。不能修了之後說「感謝回饋，我們會改進」然後石沉大海。
修正要被記住： 使用者修正過的東西，同樣的錯不能再犯。

五、隱形 AI——整份文件的底層哲學

如果只能從這份文件帶走一個概念，就是這個：

ML should feel seamless, not presented as a separate “AI feature.”

Apple 認為 AI 不是一個功能，而是一種讓功能變更好的手段。使用者打開 iPhone 不是為了「用 AI」，是為了拍照、傳訊息、查地圖。AI 的工作是讓這些事情更順暢，而不是跳出來說「嘿！我是 AI！看我多厲害！」

這跟目前很多產品的方向完全相反。現在到處都在加 AI 標籤、Sparkle icon、「Powered by GPT-4」。Apple 的立場是：好的技術不需要使用者知道它存在。

三個設計支柱：

支柱	意思	反面教材
信任（Trust）	使用者相信結果是對的	AI 幻覺但信心滿滿
透明（Transparency）	使用者知道為什麼	黑箱推薦，不告訴你原因
掌控（User Control）	使用者隨時能改	AI 自動做決定，沒有撤回鍵

我的收穫

整理完這份 HIG，可以看出 Apple 的設計哲學可以濃縮成一條規則：

AI 的工作是服務使用者的目標，不是展示自己的能力。

這意味著：

不確定的時候要敢說「我不確定」，而不是硬猜。
使用者沒問的東西，門檻要極高才推送。
回饋機制要輕量、自願、不打擾。
出錯是必然的，設計裡就要包含出錯的劇本。
技術越好，越應該隱形。

最後一點特別有意思：很多人覺得 AI 越強大就應該越顯眼，Apple 說的正好相反——越強大越應該隱形。當你感覺不到 AI 的存在，但一切都很順暢的時候，那才是 AI 設計的最高境界。

本文整理自 Apple Human Interface Guidelines — Machine Learning，是蒸餾精華第 4 段學習筆記的延伸閱讀。