今日主題
AI Product Design 面試最容易讓候選人答得空洞的地方，不是「這個功能要不要用 LLM」，而是被追問「模型在某些案例上會講錯，你怎麼辦」的時候。2026 年的面試越來越少問「你會不會做 demo」，越來越多問「模型出錯的時候，系統怎麼設計才不會垮」——因為大多數 AI 功能已經過了能不能做出來的階段，卡住產品上線的往往是「哪一步該讓人接手」這個具體分工問題，而不是模型能力本身。
核心框架速記
Human-AI Task Allocation（人機任務分配）框架不是籠統地說「人要留在迴圈裡」，而是先用兩個維度把一個功能拆成子任務，再決定每個子任務該怎麼分配：
| 維度 | 問題 | 決定什麼 |
|---|---|---|
| 錯誤代價 | 這個子任務做錯了，後果多嚴重、可逆嗎？ | 要不要在輸出生效前攔一道審核 |
| 使用者可驗證性 | 使用者看到輸出後，自己判斷得出對錯嗎？ | 要不要讓審核的人是「使用者」還是另外安排的人 |
依這兩個維度組合出三個分配桶：
- AI 自主執行：錯誤代價低、使用者自己一眼就看得出對錯的子任務（例如把長文件摘要成幾句話，使用者隨手對照原文就能核對）。
- AI 輔助 + 人工審核閘：錯誤代價高、或使用者難以自行驗證的子任務——AI 先產出，但必須有人核准才會生效或對外。
- 人類主導，AI 只建議：錯誤代價極高、幾乎不可逆、而且連事後都難以追查對錯的子任務——AI 頂多做建議，決定權完全留給人。
這個框架的重點是：不是整個功能二選一（全自動或全人工），而是拆到子任務層級分別分配，讓「人在迴圈裡」變成一個可以精準設計的介面問題，而不是一句口號。
今日練習題
題目
「你正在準備上線一個由 LLM 驅動的新功能。距離上線還有三週，你的模型評估結果顯示在邊緣案例（edge cases）上有明顯的幻覺（hallucination）比例。你的下一步是什麼？」
（來源：Amazon AI Product Manager 面試 Gen AI and LLM Knowledge 回合真題，收錄於 Aced／tryexponent.com《Amazon AI Product Manager Interview Guide》）
拆解思路
- 釐清問題：先問面試官「邊緣案例」具體是什麼——評估集裡這類案例的比例有多高、是不是代表真實流量的分布？這個功能一旦講錯，後果有多嚴重（純資訊性建議，還是會被使用者直接採信去做決定）？三週的上線時限是硬性商業承諾，還是可以談的目標？
- 定義使用者：把使用者拆成兩群——會落在邊緣案例分布裡的那一小撮人，跟其餘會看到正常模型表現的大多數人。同時留意「誰承擔後果」不一定是「誰在操作」，有些邊緣案例的受害者可能是看不到介面的第三方。
- 結構化分析：用 Human-AI Task Allocation，把這個功能拆成子任務，依「錯誤代價 × 使用者可驗證性」分進三個桶——正常流量落在的子任務多半可以維持 AI 自主執行；已知容易出現幻覺、且使用者難以自行判斷真假的邊緣案例子任務，先歸進「AI 輔助 + 人工審核閘」。
- 提出方案：不是整個功能延遲三週，而是分流上線——多數正常流量照原訂時間上線；已知的邊緣案例分布先用信心門檻或規則攔截，路由到人工審核或先行排除在此次上線範圍外，同時持續收集這批真實流量的樣本，拿去修正模型。等修正過的版本把邊緣案例的幻覺比例壓到可接受範圍，再逐步擴大自動化涵蓋範圍。
- 定義成功：分流量追蹤三個指標——邊緣案例分布與正常分布各自的幻覈率有沒有分開下降、被路由進人工審核閘的流量占比是否隨著模型迭代往下走（代表模型真的在進步，不是永遠靠人工補洞）、以及因為縮小上線範圍而付出的商業代價（延遲觸及的客群、少掉的營收）——把這個代價攤開來講，而不是假裝沒有取捨。
範例回答（面試時可以這樣講）
先框定範圍：我不會把「三週後要不要上線」當成唯一的二元選擇。我會先搞清楚這個幻覺集中在評估集的哪個子集、佔真實流量的比例大概多少，以及這個功能一旦講錯，使用者有沒有辦法自己看得出來——如果有，風險其實比表面上低；如果沒有，那才是真正需要擋下來的地方。
接著談怎麼拆解：我會把整個功能拆成幾個子任務，用錯誤代價跟使用者可驗證性兩個維度分桶。正常流量常見的子任務，如果使用者自己能一眼核對，我會讓它照原訂時間上線；已知容易觸發幻覺、而且使用者難以自行判斷的那一小塊，我會先用信心分數或規則把它攔下來，路由給人工審核，或者乾脆在這次上線範圍裡先排除掉，而不是為了這一小塊犧牲掉對多數使用者有價值的功能準時上線。
最後講怎麼知道有沒有做對：我會分開追蹤正常流量跟邊緣案例流量各自的幻覺率，確保兩者都在往下走，而不是被平均數字蓋住問題；我會看人工審核閘的觸發比例有沒有隨著模型迭代下降，這代表模型是真的在學習而不是永遠靠人工補洞；我也會把「縮小範圍上線」付出的商業代價明講出來——少觸及的客群、可能的客訴——讓這個取捨變成一個可以被檢視的決定，而不是藏在「我們很安全」這句話後面。
自我核對清單
用這張表檢查你的回答有沒有漏掉關鍵點：
| 核對項目 | 有提到？ |
|---|---|
| 有先釐清邊緣案例的規模、分布與後果嚴重性 | |
| 有區分落在邊緣案例的使用者與一般使用者 | |
| 有用錯誤代價 × 使用者可驗證性把功能拆成子任務分配 | |
| 有提出「分流上線」而非「整體延遲或整體硬上」的方案 | |
| 有定義可量測的成功指標（分流量的幻覺率、審核閘觸發比例、商業代價） | |
| 加分項：有明講縮小範圍上線的商業取捨，而不是假裝沒有代價 |
今日案例
WorkStep「Retain」產品：AI 掃描留言，人類負責處理
WorkStep 是一個給 HR 與營運主管用的第一線員工意見管理平台，客戶每個月會收到數以千計的員工問卷留言，人工根本看不完。設計工作室 Neuron 重新設計這個產品時，把「掃描全部留言找出需要處理的」交給 AI——系統自動掃描跟安全、騷擾、歧視等相關的字詞，把需要關注的留言從大量留言裡挑出來，放進一個 alert 清單給管理者去看。但「怎麼回應」完全留給人：管理者要自己回覆員工留言、指派給對的人去處理、記錄最後是怎麼解決的。AI 不會自動回覆，也不會自動結案。這正是 Human-AI Task Allocation 的具體示範：AI 做人類在規模上做不到的事（一個月掃完上千則留言），人類做 AI 不該做的判斷（怎麼回應一則關於騷擾的投訴）。這個分工設計上線後，幫客戶在一年內讓規模成長了將近 400%（來源：Neuron, Workforce Case Study）。
面試連結：這個案例可以直接拿來回答「人機協作的分工要怎麼具體設計」這類問題——用它證明「human-in-the-loop」不是到處加人工核准按鈕，而是先想清楚哪一步是人類真正不可取代的判斷（涉及人際後果、需要同理心跟責任歸屬的決定），其餘交給 AI 去做規模化的篩選跟彙整。
延伸閱讀
- Amazon AI Product Manager Interview Guide — Aced (tryexponent.com) — 完整收錄 Gen AI and LLM Knowledge 回合的六大類真題與追問方式，不只今天這一題，還包括 evaluation framework 設計與企業客戶回報 bias 的情境題。
- Micro Interaction Design for AI Agents — reloadux — 拆解「用百分比顯示信心」為什麼常常失敗，是今天案例裡「AI 先篩選、人再判斷」分工邏輯在介面層的延伸案例。
- Google Product Manager Interview (questions, process, prep) — IGotAnOffer — 有專節講 AI PM 要「設計不確定性」，跟今天用錯誤代價分桶的邏輯互補，適合用來練 Google 風格的 AI PM 問題。
參考資料
- Amazon AI Product Manager Interview Guide — Aced (tryexponent.com) — 今日練習題「上線前三週發現模型在邊緣案例有明顯幻覺比例」出處，收錄於 Gen AI and LLM Knowledge 回合。
- Workforce (WorkStep) Case Study — Neuron — 今日案例出處，AI 自動標記留言、管理者負責觸發後續處理的分工細節與一年內規模成長近 400% 的數據出處。
- Micro Interaction Design for AI Agents — reloadux — 延伸閱讀對應之信任訊號設計細節。
Loading...