今日主題
「AI 功能該在哪裡放人工審核」是 AI 產品設計面試裡最常出現、卻最容易答成口號的題型。候選人幾乎都會說「重要的動作要有人看過」,但面試官真正想聽的是：你能不能把「重要」拆成可操作的判準,並且知道「有人看過」不等於「真的有審核到」。今天的框架與練習題,都在練這個從口號到可執行設計的落差。
核心框架速記
框架一：風險 × 可逆性 → 審核強度(Cloudsoft Solutions)
決定人工審核該放在哪裡,先別想 UI,先把輸出按「錯誤成本」與「可逆性」分類：
| 錯誤成本 | 可逆？ | 審核強度 |
|---|---|---|
| 高(金流、醫療、法律、關閉帳戶) | 不可逆 | 事前核准(approve before action) |
| 中(高量輸出) | 可逆 | 事後抽查(sample after action) |
| 低 | 可逆 | 例外處理 + 使用者回饋(exceptions + feedback) |
分級不是一次定終身——隨著證據累積(某類輸出長期零錯誤),可以把它從「事前核准」降到「事後抽查」,這個「分級會隨證據移動」的動態性,是面試官用來分辨候選人有沒有真的做過這件事的關�键問題。
框架二：approve 按鈕不等於有效監督(Tcules)
Tcules 整理了八個人機協作 UX 模式(事前核准、對等的核准/編輯/拒絕、強制使用者先表態、按風險分流、預授權範圍、中途暫停接管、可撤銷時間窗、附理由的覆寫記錄),但更重要的是背後的研究發現：自動化偏誤(automation bias)在專家與生手身上都會出現,而且訓練或提醒無法消除它。Anthropic 自己的數據是最好的證明——Claude Code 使用者核准了 93% 的權限提示,這個高核准率本身無法證明審核是認真的還是疲勞的,必須另外設計「核准速度」「不同難度案件的核准率有沒有差異」「種進已知錯誤案件測試有沒有被抓到」這類指標去驗證審核真的在發生。
今日練習題
題目
「你負責一個 AI 輔助的信用貸款核准系統,模型對每筆申請都會給出核准建議與信心分數。目前公司要求所有案件都要人工覆核才能放款,業務單位抱怨審核太慢、影響轉換率。你會怎麼重新設計這個審核流程?」
(自擬,綜合 Cloudsoft Solutions《55 AI Product Manager Interview Questions》Q33「How do you decide where to put a human in the loop」與 Tcules 人機協作 UX 模式整理)
拆解思路
- 釐清問題：先問面試官——「全部人工覆核」是公司政策還是風險部門的硬性要求?現在的核准/拒絕錯誤各自造成多大損失(誤放款 vs. 誤拒絕流失客戶)?同時帶出假說：「我會假設目標不是『要不要有人工審核』,而是『審核強度要不要分級』,因為一刀切通常代表沒有針對風險做分類。」
- 按錯誤成本分級：用「風險 × 可逆性」矩陣拆案件——大額、信用薄、模型信心偏低的案件屬於高成本不可逆,維持事前核准;小額、信用記錄良好、模型高信心的案件屬於可逆中低風險,改成「自動放款 + 事後抽查」;模型信心中等但金額小的案件走「例外處理」,只有模型自己標記不確定時才轉人工。
- 設計審核本身,不只是分流：覆核介面要讓審核員看到模型依據(信用資料、相似歷史案件、信心分數),而不是只有一個「核准/拒絕」按鈕——按 Tcules 的研究,光給理由反而會提高接受錯誤建議的機率,除非理由讓審核員「容易驗證」,所以要把驗證成本做低,而不是把解釋文字做多。
- 驗證審核真的有效：不要只看最終核准率,要主動在審核佇列裡放已知有問題的測試案件,量「有沒有被抓到」;比較模型信心低但審核時間很短的案件,找出可能在橡皮圖章的審核員。
- 讓分級隨證據移動：約定一個時間窗(例如三個月),拿抽查結果重新評估——如果某個信心區段的小額貸款長期零錯誤,把它從「事後抽查」進一步放寬;如果某類案件覆寫率持續偏高,代表模型在那個區段系統性地錯,要送回模型評估而不是一直靠人工補。
範例回答(面試時可以這樣講)
先拒絕一刀切的框架：「我不會直接回答『要不要全部人工審』,因為這題的關鍵不是有沒有人在審,而是審核強度有沒有對應風險。我會先把案件按『錯誤成本』與『可逆性』分三層——大額、低信用分數、模型信心低的案件維持事前核准,小額、高信用、模型高信心的案件改成自動放款加事後抽查,中間地帶走例外處理。」
把審核介面也當成設計範疇：「分級只解決了『誰需要被審』,沒解決『審核有沒有真的發生』。我會確保覆核員看到的是模型依據本身——信用資料、相似歷史案例——而不是一段模型生成的解釋文字,因為研究顯示解釋文字容易讓人更容易接受錯誤建議,除非它讓人更容易驗證,而不是更有說服力。」
用測試而不是核准率驗證審核品質：「我會定期在審核佇列裡混入已知有問題的測試案件,追蹤被抓到的比例,而不是只看核准率,因為 93% 的核准率可能代表審核員很仔細,也可能代表他們疲勞了在橡皮圖章——這兩種情況光看核准率分不出來。隨著證據累積,我會把確認安全的區段逐步從『事前核准』移到『事後抽查』,把人力留給真正高風險的案件。」
自我核對清單
用這張表檢查你的回答有沒有漏掉關鍵點：
| 核對項目 | 有提到？ |
|---|---|
| 有拒絕「全部人工審」或「全部自動放」的一刀切答法 | |
| 用錯誤成本 × 可逆性做分級,不是憑感覺判斷風險 | |
| 審核介面設計本身(看什麼依據)也納入方案,不只是分流 | |
| 有設計「怎麼驗證審核真的有效」,不只看核准率 | |
| 加分項：提到分級會隨證據累積動態調整 |
今日案例
Anthropic Claude Code auto mode：把「每個動作都要人核准」重新設計成三層架構
2026 年 3 月,Anthropic 公開了 Claude Code auto mode 的設計細節,起點正是今天框架二引用的那個數字——使用者核准了 93% 的權限提示,形成「審核疲勞」。他們沒有選擇完全關掉提示(等同拿掉所有防護),也沒有維持每個動作都要人工核准(等同不解決疲勞問題),而是設計三層：第一層是不能修改狀態的安全工具白名單直接放行;第二層是專案內的檔案操作(可用版本控制復原)直接放行;只有真正有下行風險的動作(shell 指令、外部網路請求、專案外的檔案操作)才送進第三層的分類器審核。分類器本身又拆成兩階段——第一階段快速且寬鬆地抓可疑動作,第二階段才用完整推理覆核,把整體假陽性率從 8.5% 壓到 0.4%,但在真實的危險動作測試集上仍然有 17% 的漏判率,Anthropic 誠實寫明「這不是取代高風險基礎設施上的人工審核,是用可接受的殘餘風險換掉審核疲勞」。
面試連結：這個案例可以直接用在任何「AI 功能要不要人工審核」「怎麼降低審核疲勞但不犧牲安全」的題目裡,示範怎麼把抽象的「分級審核」做成真正出貨的架構(白名單/低風險自動放行/分類器把關),以及怎麼誠實呈現 trade-off 的具體數字,而不是宣稱系統「安全又好用」。
延伸閱讀
- What are good human-in-the-loop UX patterns?, Tcules — 今天框架二八個模式的完整出處,附自動化偏誤、解釋文字提高誤接受率等研究引用
- 55 AI Product Manager Interview Questions, Answered Practically, Cloudsoft Solutions — 今天框架一「風險 × 可逆性」矩陣(Q33)與橡皮圖章偵測(Q34)的出處,另有 53 題涵蓋評估集、成本、定價等 AI PM 常考題
- How we built Claude Code auto mode: a safer way to skip permissions, Anthropic — 今天案例的完整技術細節,含分類器架構、威脅模型與完整的 FPR/FNR 數據
參考資料
- What are good human-in-the-loop UX patterns?, Tcules — 對應「核心框架速記」框架二與「今日練習題」審核介面設計的出處
- 55 AI Product Manager Interview Questions, Answered Practically, Cloudsoft Solutions — 對應「核心框架速記」框架一矩陣與「今日練習題」驗證審核品質段落的出處
- How we built Claude Code auto mode: a safer way to skip permissions, Anthropic — 對應「今日案例」Claude Code auto mode 三層架構與數據的出處