今日主題
AI Product Design 面試題近幾年變得特別重要,因為幾乎每個 PM 職缺現在都要回答「怎麼幫這個產品加一個 AI 功能」。這類題目真正考的不是你懂不懂 LLM 或 RAG 這些技術名詞,是你能不能在「AI 會犯錯、而且犯錯是機率性的,不是非黑即白」這個前提下,還設計出一個使用者敢用、敢信的功能。最常見的失分點是把 AI 當成魔法——只顧著講功能多厲害,卻沒講清楚犯錯的時候怎麼辦。今天用兩個框架拆一道真實面試題。
核心框架速記
框架一:風險分級任務分配
這個框架幫你決定「這一步該讓 AI 自己做,還是要先給人看過」,依據是兩個變數交叉出的分級,不是憑直覺猜。
| 犯錯成本 | 動作可逆嗎? | 該用的監督方式 |
|---|---|---|
| 高 | 不可逆 | 先經人核准才執行(approve before action) |
| 中 | 可逆 | 事後抽查(sample after action) |
| 低 | 可逆 | AI 自己處理,只回報例外與蒐集回饋(exceptions + feedback) |
容易犯的錯:看到「AI 功能」就預設要做成全自動,沒先問這一步犯錯的代價有多高、做錯了能不能收回。一個會寄出去的訊息、一筆會轉出去的款項,屬於「高成本、不可逆」,不該是第一版就做成全自動。
框架二:信任校準
信任校準的目標是「適度依賴」(appropriate reliance),不是讓使用者無條件信任 AI,也不是讓他每一步都要盯著重新檢查。失敗有兩種方向,都要避免:
| 失敗類型 | 長什麼樣 | 怎麼發生的 |
|---|---|---|
| 過度依賴(automation bias) | 使用者不檢查就接受 AI 的輸出 | 介面讓「接受」比「檢查」容易太多 |
| 監督崩潰(supervisory collapse) | 自動化程度太高,人被推出迴圈太遠,該介入的時候已經不注意了 | 一開始就給太多自主權,使用者漸漸不看了 |
常見錯誤:以為加一個信心分數(confidence score)就解決了信任校準的問題。研究顯示信心分數能幫助校準信任的「感覺」,但不會自動讓使用者做出更好的判斷——真正有用的是讓使用者能便宜地查證,例如附上可以點開核對的引用來源、明確標示「這是草稿還是已經執行的動作」、給一個清楚的「我不確定」狀態加下一步建議,而不是一串裸的百分比。
今日練習題
題目
「你會怎麼設計一個幫銷售開發代表(SDR)寫 outreach 訊息的 AI 功能?」 (來源:ZoomInfo PM 面試真題,收錄自 knok.work 整理的候選人面試回報)
拆解思路
- 釐清問題:先問面試官這個功能是「全自動產生並發送」還是「產生草稿、SDR 看過才送出」——這決定了接下來整個設計方向,沒問清楚等於自己假設了一個可能不成立的範圍。
- 定義使用者:這題有兩個使用者,需求會互相拉扯——SDR 想要的是效率(少打字、發得快),收件人(潛在客戶)想要的是不要收到看起來像罐頭信的垃圾訊息。只優化 SDR 這一邊,很容易做出一個發信量很大、但回覆率很差的功能。
- 用風險分級框架評估該不該做成全自動:這個動作(把訊息發給真實潛在客戶)犯錯成本高(寄錯語氣或資訊會得罪潛在客戶,傷害的是公司對外的第一印象)、而且不可逆(信一發出去,收件人就看到了,無法收回)——落在「高成本、不可逆」這一格,結論是第一版不該做成全自動發送,要先停在「AI 產生草稿、SDR 核准才送出」。
- 提出方案:AI 根據潛在客戶的公開資料與公司過去成功的 outreach 範例產生草稿,並附上「為什麼這樣寫」的簡短理由(引用了哪些客戶資料),SDR 可以直接編輯後送出;當系統觀察到某個 SDR 對某類草稿連續多次幾乎不修改就送出,才考慮把那一類放寬成「預覽後批量送出」,而不是一開始就全面開放自動化。
- 定義成功指標:主要指標不是發送量或草稿產生速度,是正向回覆率(reply rate),因為發得快但沒人回等於沒用;同時追蹤 SDR 對草稿的編輯幅度作為引導指標,如果每次都大幅改寫,代表模型還沒學到位,不該急著放寬自動化範圍。
範例回答(面試時可以這樣講)
我會先跟面試官確認這是「AI 幫忙寫草稿」還是「AI 自動發送」,因為這兩者的風險等級完全不同,決定了我接下來的設計方向。先看這個動作的風險:一封 outreach 訊息一旦發出去,收件人就看到了,沒有辦法收回;如果內容寫錯語氣或引用錯資料,傷到的是公司在潛在客戶心中的第一印象。這是高成本、不可逆的動作,我不會在第一版就做成全自動發送,會先做成「AI 產生草稿,SDR 核准後才送出」。
草稿本身要讓 SDR 容易判斷要不要信:AI 根據這個潛在客戶的公開資料(職稱、公司近期動態)和過去回覆率高的 outreach 範例生成草稿,並附上一句「為什麼這樣寫」,讓 SDR 一眼就能核對這些引用的資料是不是真的對,而不是給一個裸的信心分數——因為單看一個百分比,沒辦法幫 SDR 判斷這封信到底可不可以直接送出。
自動化程度會隨著觀察到的行為逐步放寬,不是一步到位。如果系統發現某個 SDR 對某一類潛在客戶的草稿,連續很多次幾乎原封不動就送出,代表模型在這一類已經學得夠好,可以考慮放寬成批量預覽後一次核准,而不是逐封核准——但這個放寬是根據實際行為資料決定的,不是因為「AI 功能就應該全自動」這個預設。成功指標我會用正向回覆率,不是發送量,因為發得多但沒人理,對業績沒有幫助;同時追蹤 SDR 的編輯幅度,如果編輯幅度一直很高,代表還不該放寬自動化範圍。
自我核對清單
用這張表檢查你的回答有沒有漏掉關鍵點:
| 核對項目 | 有提到? |
|---|---|
| 有先問清楚是草稿輔助還是全自動,鎖定範圍 | |
| 有定義兩種使用者(操作者與受影響的第三方),不是只顧操作者的效率 | |
| 用具體框架(風險分級或信任校準)決定監督強度,不是直接假設要全自動 | |
| 方案裡有「怎麼讓使用者容易核對 AI 輸出」的具體機制,不是只給信心分數 | |
| 成功指標對應的是結果品質(如回覆率),不是產出速度或數量 | |
| 加分項:自動化程度隨真實行為資料逐步放寬,而非一次到位 |
今日案例
Anthropic Claude Code:93% 的批准率,藏著信任校準失敗的警訊
Anthropic 在自家工程部落格公布一個數字:Claude Code 使用者對權限提示(permission prompt)的批准率高達 93%。乍看是個正面訊號——代表 AI 的建議大多是對的,使用者放心接受。但 Anthropic 自己把這個現象定性為「批准疲勞」(approval fatigue):人看多了重複的核准請求,會漸漸不再認真檢查,只是機械式地按下「允許」。這正是框架二裡「過度依賴」的真實案例——高批准率本身不能證明信任校準做得好,也可能只是使用者已經停止真正審查。
面試連結:這個案例可以直接拿來回答「怎麼知道你的 human-in-the-loop 設計真的有效」這類追問——示範不要只看表面的批准率或使用率當成「信任校準成功」的證據,要進一步問這個批准是「認真判斷後同意」還是「看久了疲乏後的機械式放行」,並在設計上主動偵測這種疲乏(例如對長期全部批准、幾乎不修改的使用者,改用抽樣深度檢查取代每次都要求核准,反而比持續要求逐一核准更能維持真正的注意力)。
延伸閱讀
- AI Product Manager Interview Questions and Answers 2026 (55 Questions) - CloudSoftSol — 風險分級任務分配框架的完整版本,附多道 AI PM 案例題與結構化答案
- Human-in-the-Loop UX Patterns for AI Review - Tcules — 八種 human-in-the-loop UX 模式的完整圖譜,附 Claude Code 批准疲勞數據與 EU AI Act 對人類監督的具體要求
- How to Crack AI Product Sense Interviews - IGotAnOffer — AI 產品設計面試的完整答題結構,附 Anthropic、Meta、Google、OpenAI 的真實 Glassdoor 面試題
參考資料
- ZoomInfo Product Manager Interview: Questions & Prep - Knok — 今日練習題(SDR AI outreach 功能)出處
- AI Product Manager Interview Questions and Answers 2026 (55 Questions) - CloudSoftSol — 風險分級任務分配框架來源
- Human-in-the-Loop UX Patterns for AI Review - Tcules — Claude Code 93% 批准率與「批准疲勞」案例來源
- Human-Centred AI UX: Designing Interfaces People Trust - Futurense — 信任校準(適度依賴)與監督崩潰概念來源