做 AI 產品的團隊常常說: 「我們的輸出很難做 eval」。AI Evals 課程講師 Hamel Husain(ihower 也上過這門課)最近這篇 “It’s Hard to Eval” Is a Product Smell 給了一個直接的回應: 這句話本身就是警訊。借用 code smell 的講法，「很難 eval」是一種 product smell: 問題通常不在 eval 技術，而在產品設計。

他的理由一句話就能講完: 「你自己很難驗證的產出，使用者通常也很難驗證。」你做 eval 時卡住的地方，就是使用者每天用你產品時卡住的地方。所以與其問「這要怎麼 eval」，不如回頭把產品重新設計成「容易驗證」。

小編覺得這篇對 AI 產品的 UX 設計很有啟發。降低幻覺、提升正確率當然是基本功，但錯誤率永遠不會是零: 就算輸出 95% 是對的，使用者分辨不出哪 5% 是錯的，還是不能放心用。所以除了「讓模型少出錯」，「讓使用者能快速驗證、建立信任」的 UX 也同樣重要。以下先整理 Hamel 的三個案例(Hamel 也錄了影片版，逐一 demo 每個案例的 UI 設計)，再擴大搜尋補幾篇相關文章一起看。

為什麼驗證變成了瓶頸

Hamel 點出一個關鍵變化: 在 AI 之前，驗證是在「做出工作成果」的過程中順帶完成的。自己寫的分析，每個數字怎麼來的自己都清楚。但 AI 讓產出瞬間完成，驗證卻沒有跟著變快，於是驗證成了整個工作流程中最花時間的一步。

這代表 AI 產品設計的重心也得跟著調整: 從「怎麼生成最好的輸出」，轉到「怎麼讓人最快確認輸出可不可信」。

案例 1: 資料分析 Agent，從「只給答案」改成「附上驗證路徑」

如果資料分析 Agent 只丟出「淨收入 $4.21M」這種最終答案，資料科學家不會直接採信: 要確認這個數字，等於把整個分析從頭再做一次。

Hamel 先整理資深資料科學家實際上怎麼驗證一個指標: 跟已驗證的儀表板或同事做過的分析對照、確認指標定義、對相關數字做合理性檢查、看聚合數字底下的明細、直接讀 SQL、標記無法驗證的部分。

好的設計就是把這些驗證動作直接做進產品。Hamel 拿 Hex 的 chat + notebook 雙介面當例子: 聊天介面給結論和圖表(本文封面圖)，旁邊的互動式 notebook 完整呈現分析過程，假設、指標定義、SQL 查詢、中間結果都可以逐一檢查; 數字對照過哪份已驗證分析、作者是誰，都標出來; 沒有可信來源可對照的項目，主動列成清單:

Hex 的 notebook 介面，chat 面板在右側同步顯示 圖片來源: Hamel 原文

案例 2: 課程生成器，從「生成」改成「檢索 + diff」

一個幫體育老師生成課程計畫的工具，從零生成 50 頁的完整計畫，老師得整份讀完才能放心用，跟自己寫一份差不多累。

Hamel 的解法是換一個問題來問: 不問「這 50 頁要怎麼 eval」，而問「老師實際在乎什麼」。答案是: 看到類似學校的老師已經在用這份計畫，比什麼都有說服力。

於是產品改成: 檢索一份已經被其他學校用過、驗證過的課程計畫(標明原作者、多少學校在用、跑過幾個學年)，再根據這位老師的條件客製修改，並把改動用 diff 標出來、附上修改原因。老師要審的東西，從 50 頁變成幾個修改。

這個設計還有一個附帶好處: 產品本身變簡單了。比起把幾百個範例放進 prompt 從零生成，檢索最接近的已驗證範本再改寫，工程上反而更容易做對。

案例 3: 醫療報告，從「報告生成器」變成「研究助手」

工傷保險的醫療意見書動輒 50 頁以上。如果工具直接生成整份報告，醫生要驗證每一條主張，等於把病歷重讀一遍，省不到什麼時間。

改法是調整工具的角色: 不要一開始就生成報告，先當研究助手，從病歷中提取相關事實，每一條都附上原始頁面的連結; 不同檢查結果有矛盾的地方特別標出來; 缺影像、缺資訊的開放問題也列出來。醫生逐條確認過事實之後，才從這些已驗證的事實生成最終報告。

這個流程讓信任可以逐步累積，驗證單位也變小了: 醫生不用一次判斷「整份報告可不可信」，而是判斷「這條矛盾是不是真的」「這個引用有沒有支持這個主張」這種小問題。

驗證導向設計: 四個問題

Hamel 把三個案例整理成通用的設計提問:

  1. 使用者實際需要檢查什麼?
  2. 他們手上有什麼可信的東西可以對照?
  3. 領域專家平常用什麼訊號或捷徑來判斷可不可信?
  4. 輸出能不能拆成可以個別接受、編輯、拒絕的小單位?

貫穿三個案例的手法也很一致:

  • 「溯源」(provenance): 輸出的每個部分都標明從哪來，附上可以點進去看細節的連結。Hamel 說這是讓輸出變得可檢查最快的方法
  • 「漸進揭露」(progressive disclosure): 初期把來源和假設清楚展示出來，幫使用者建立信任; 等信任建立之後，這些細節再改成預設收合、需要時展開
  • 拆成小單位: 不要求使用者一口氣評斷整個輸出，而是拆成可以個別接受、編輯、拒絕的部分

Hamel 還特別提到: 連 coding 這種最容易驗證的領域(有測試、型別、diff)，Cursor 和 Devin 都還會多錄一段 UI 操作影片，讓你不用自己重現就能確認改動有效。連條件最好的領域都做到這個程度了，難驗證的領域更沒理由不做。

從 UX 視角看: 除了降低錯誤率，還要縮短發現錯誤的時間

把這篇跟其他幾篇談 AI 產品 UX 的文章放在一起看，會更清楚「可驗證」為什麼是核心。

Karpathy 在 Software Is Changing (Again) 演講裡把人跟 AI 的協作描述成「生成與驗證的迴圈」: AI 負責生成，人負責驗證，這個迴圈轉得越快越好。他認為 GUI 的價值就在這裡: 讓人用視覺快速稽核 AI 的工作，例如 Cursor 的紅綠 diff、Perplexity 的引用來源。這跟 Hamel 講的是同一件事: 縮短驗證那一半的時間，跟提升生成品質一樣重要。

Google 官方的 People + AI Guidebook 在 Explainability + Trust 這章把目標講得很清楚: 設計的目的不是讓使用者「盡量信任 AI」，而是幫使用者「校準信任」(calibrate trust): 該信的時候信，該存疑的時候存疑。過度信任和過度懷疑都是設計失敗。溯源、模型的信心程度、解釋，都是幫使用者校準信任的工具。

另外社群也開始把這類做法整理成 pattern library，像 Shape of AI 收錄了 Citations 等 AI UX 模式，做產品時可以當 checklist 翻一翻。

小結

「很難 eval」和「使用者不信任輸出」是同一個問題的兩面。把產品設計成可驗證，好處是一連串的: 使用者驗證成本下降，才會真的把工作交給它; 標註成本也跟著下降，eval 的訊號品質變好。下次團隊再說「我們的輸出很難 eval」，先別急著研究更強的 LLM judge，回頭檢查一下: 產品是不是把使用者當成「只需要一個答案」的人。