設計 AI 產品有標準流程嗎？Google 整理了 6 章實戰框架

為什麼讀這份文件

在寫蒸餾精華第 4 段筆記的過程中，我想找一份「大規模驗證過」的 AI 設計框架。Apple HIG 給了設計哲學，但我還缺一份更偏產品策略的指南——什麼時候該用 AI、什麼時候不該用、怎麼跟使用者溝通 AI 的能力邊界。

Google 的 PAIR（People + AI Research）團隊剛好做了這件事。他們基於數百個 AI 產品的經驗，把設計原則整理成 6 章。這不是學術論文，是實戰手冊。

以下是透過 Claude 協助閱讀後的導讀，每一章標出最關鍵的原則和最反直覺的發現。

第一章：使用者需求與成功定義

核心原則：先問問題，再問技術

PAIR 的第一個提醒值得特別注意：

不要問「我們能用 AI 來 ____？」，要問「我們怎麼解決 ____？」以及「AI 能不能 uniquely 解決這個問題？」

這個翻轉很重要。太多產品的起點是「我們有 AI 技術，找個地方用」，而不是「使用者有這個痛點，AI 剛好能解」。前者做出來的東西叫 demo，後者才叫產品。

AI 適合與不適合的場景

PAIR 列了一張很實用的對照表：

AI 比較適合的： 個人化推薦、預測未來事件、自然語言理解、詐騙偵測。

AI 不適合的： 需要可預測性的場景、提供靜態資訊、不容許昂貴錯誤的決策、需要高度透明的流程。

延伸思考： 「不容許昂貴錯誤」這一項特別值得記住。AI 的本質是機率性的，它不保證每次都對。如果你的場景是「錯一次就出人命」或「錯一次就賠一千萬」，那 AI 頂多當參考，不能當決策者。

Automate vs Augment

這是整份文件裡我覺得最有操作性的框架：

自動化（Automate）： 適用於無聊的、重複的、危險的任務。但永遠要保留人類介入的機制（human-in-the-loop）。
增強（Augment）： 適用於人們享受做的事（寫作、設計）和高風險決策（飛行員、醫生）。

延伸思考： 如果使用者做這件事會感到成就感，你就不該把它自動化掉——你該讓 AI 幫他做得更好。醫生不會希望 AI 替他診斷，但他會希望 AI 幫他看到他漏掉的 X 光細節。寫作者不會希望 AI 替他寫文章，但他會希望 AI 幫他找到更好的措辭。

這就是 Centaur Model 的精神——人機協作，而不是人機取代。

第二章：資料收集與評估

核心原則：沒有真正中立的資料

“There is no such thing as truly neutral data.”

PAIR 把 AI 可能造成的傷害分成四類：

表徵傷害（Representational Harm）： AI 強化了某種刻板印象
機會剝奪（Opportunity Denial）： AI 讓某些群體失去機會（例如履歷篩選偏見）
不成比例的產品失敗（Disproportionate Product Failure）： AI 對某些群體的表現特別差
劣勢傷害（Harm by Disadvantage）： AI 讓已經弱勢的群體更弱勢

延伸思考： 這四類分法比泛泛說「AI 有偏見」實用太多。做產品的人可以拿這個清單逐項自我檢查。

資料文件和程式碼文件一樣重要

“Dataset documentation can be just as important as code documentation.”

這句話戳中了一個現實：大多數團隊會寫程式碼的 README，但幾乎沒人寫資料集的 README——這批資料怎麼收集的？取樣有沒有偏差？涵蓋了哪些群體、排除了哪些？

資料沒有文件，就像程式碼沒有註解——你不知道它為什麼是這個樣子，也不知道它什麼時候會出問題。

第三章：心智模型

核心原則：讓使用者正確理解 AI 能做什麼

這章給了一個我覺得超實用的 onboarding 模板：

“This is {product}, it’ll help you by {benefits}. Right now, it’s not able to {limitations}. Over time, it’ll change. You can help by {user actions}.”

然後 PAIR 給了正反例：

好的： 「RUN 是一個會根據你的體能狀況調整的跑步 app」
壞的： 「RUN 是唯一使用深度神經機器學習的智慧跑步 app」

延伸思考： 壞的版本犯了兩個錯——第一，它用技術術語來行銷，但使用者不在乎你用什麼技術；第二，「唯一」和「智慧」這種詞設定了不切實際的期待。

這跟我們在誠實介面那篇討論的完全一致：介面的外型就是承諾，文案也是。

不講清楚，就是欺騙

“If the algorithmic nature and limits are not explicitly communicated, they can lead to user disappointment or unintended deception.”

PAIR 用了一個很重的詞——deception（欺騙）。不是使用者太笨不懂 AI，是你沒講清楚。這個責任在產品設計者身上。

第四章：可解釋性與信任

核心原則：信任是分階段建立的

PAIR 把信任拆成三個因素和四個階段：

三個因素：

能力（Ability）： AI 是否有勝任的能力
可靠性（Reliability）： AI 的表現是否一致
善意（Benevolence）： AI 是否誠實

四個階段： 建立 → 成長 → 維持 → 重建（犯錯之後）

延伸思考： 「重建」這個階段太重要了。大多數產品只想到前三個階段，但 AI 一定會犯錯——不是可能，是一定。你的產品有沒有準備好「犯錯之後怎麼重建信任」的劇本？

信心展示的五種方式

PAIR 列出展示 AI 信心程度的五種做法：

N-best 分類： 給出前 N 個最可能的答案
數字百分比： 「87% 確定」
分類式： 高 / 中 / 低
範例式： 用類似案例來說明
互動式： 讓使用者探索不同的可能性

然後 PAIR 補了一句非常關鍵的話：

“Don’t show confidence if it won’t impact user decision-making or could mislead.”

延伸思考： 不是所有場景都需要顯示信心分數。如果使用者看到「87% 確定」但他根本不知道該怎麼解讀這個數字，那你不是在幫他，是在增加他的認知負擔。更糟的情況是，使用者看到 87% 覺得「夠高了」就照做——但其實這個任務需要 99% 才安全。

第五章：回饋與控制

核心原則：回饋的品質有五個等級

這是整份文件裡我最喜歡的段落。PAIR 把「接收使用者回饋後的回應」分成五級，從最差到最好：

「感謝您的回饋」 ——沒有時間感、沒有範圍（最差）
「您的回饋有助於改善未來的推薦」 ——範圍太廣
「我們會改善您的未來推薦」 ——針對個人
「您的下一個跑步推薦不會包含爬坡」 ——具體
「我們已更新您的推薦，來看看」 ——即時 + 展示結果（最好）

延伸思考： 差別在於具體性和即時性。最差的版本讓使用者覺得自己的回饋掉進了黑洞；最好的版本讓使用者立刻看到改變。

這裡的設計智慧是：使用者願意給回饋，是因為他相信回饋有用。 如果你的回應讓他覺得沒用，他下次就不會再給了。

不要過度打擾

“Your product likely isn’t the focus of your users’ lives, so keep engagement requests strategic, minimal.”

延伸思考： 這句話應該刻在每個產品經理的桌上。你的 app 覺得自己是世界的中心，但使用者手機裡有 80 個 app，你不是。不要動不動就要回饋、要評分、要通知。每一次打擾都是在消耗信任。

第六章：錯誤與優雅失敗

核心原則：AI 一定會出錯，問題是怎麼出錯

PAIR 把錯誤分成三類：

情境錯誤（Context Errors）： 系統其實沒壞，但使用者覺得它壞了——期待落差
失敗狀態（Failstates）： 系統真的回答不了
背景錯誤（Background Errors）： 系統出錯了但沒人注意到

延伸思考： 第三類最危險。前兩類使用者至少知道出了問題，第三類是 AI 悄悄給了錯誤的答案，而且大家都信以為真。這在醫療、法律、金融場景裡可能造成真正的傷害。

犯錯要有人味

“When designing your error experience, be human, not machine. Address mistakes with humanity and humility.”

這跟誠實介面的核心主張完全一致——AI 犯錯時不要冷冰冰地顯示錯誤代碼，要像一個人在道歉：承認、解釋、提供替代方案。

然後 PAIR 補了一句很有哲學味道的話：

“Learning, machine or otherwise, can’t happen without making mistakes.”

不只是 AI，任何學習都需要犯錯。問題不是「如何避免所有錯誤」，而是「如何讓犯錯成為改善的起點」。

串聯思考：PAIR 與誠實介面

讀完這 6 章，我發現 PAIR Guidebook 和我們之前討論的「誠實介面」有幾個高度一致的主題：

1. 能力要匹配承諾

PAIR 第一章說「先問 AI 能不能 uniquely 解決這個問題」，第三章說「不講清楚限制就是欺騙」。這跟我們說的「介面的外型就是承諾」完全同源——你宣稱的能力和實際的能力之間，不該有落差。

2. 透明不是可選的

PAIR 第四章把「善意（Benevolence）」定義為誠實，而不是友善。友善是語氣，誠實是態度。你的 AI 不需要每次回答都加「好的呢~」，但它需要在不確定的時候說「我不確定」。

3. 犯錯是設計的一部分

PAIR 第六章專門用一整章講怎麼優雅地失敗。這不是附錄，是主體。一個不會處理犯錯的 AI 產品，不是還沒做完——是設計有缺陷。

關鍵收穫

AI 不是問題的答案，它只是解法的候選之一。 先定義問題，再決定要不要用 AI。
Automate vs Augment 是最重要的產品決策。 人享受做的事情，用增強；人不想做的事情，用自動化。
資料沒有文件 = 程式碼沒有註解。 你不知道它為什麼是這樣，也不知道它什麼時候會出問題。
信心分數不是越多越好。 如果使用者不知道怎麼用這個資訊，就別顯示。
回饋的回應品質有五級。 「感謝您的回饋」是最差的，「我們已經改了，來看看」是最好的。
犯錯要有人味。 AI 道歉的方式，就是產品品味的體現。

本文整理自 Google PAIR Guidebook，由 Google People + AI Research 團隊製作。是蒸餾精華第 4 段學習筆記的延伸閱讀。