Evals 是 AI 產品的最高 ROI：從 Error Analysis 到 LLM Judge 的完整實戰流程

Evals 是 AI 產品的最高 ROI：從 Error Analysis 到 LLM Judge 的完整實戰流程

(摘要自 Lenny’s podcast) https://www.youtube.com/watch?v=BsWxPI9UM4c

🧠 為什麼「會做 Evals」正在變成 AI 產品的核心技能？

這場對談最鮮明的訊息是：要做出很好的 AI 產品，你得很會做 evals（評估／評測）。而且這不是「加分項」，而是高報酬、能直接改變產品成敗的工作。主持人說，兩年前他從未聽過「evals」這個詞；現在它卻成了節目最常出現的熱門主題之一——甚至連 Anthropic 與 OpenAI 的兩位 CPO 都說：evals 正成為產品打造者最重要的新技能。

更有趣的是：世界上成長最快的一些公司，本質上就是在「替 AI labs 建立、販售、提供 evals」。主持人提到他剛訪談過 CF Mercor（此處按原文保留名稱），讓他覺得「有很大的事情正在發生」。

而這集來賓 Hamel Hussein 與 Shreya Shankar，正是把 evals 從「小眾、神秘」推向「AI 產品必修技能」的重要推手。他們在 Maven 上教授 evals 課程，且是 Maven 平台排名第一的課程；已教過 2,000+ 位 PM 與工程師、橫跨 500 家公司，包含 OpenAI 與 Anthropic 團隊的大量成員，以及幾乎所有主要 AI lab。

主持人在開場直接下結論式推薦：這集是他聽過最深、但也最容易懂的 evals 入門，甚至讓他在「明明沒有產品要寫 eval」的情況下，也被激起「好想去寫 eval」的興奮感。

📌 Evals 到底是什麼？不是只有「單元測試」那麼窄

對談一開始就把「什麼是 eval」講得很落地。

1) Hamel 的定義：系統化衡量與改進 AI 應用

Hamel 說，evals 是一種系統化（systematically）衡量與改善 AI 應用的方法。它不需要很可怕，本質上就是把 LLM 應用當成一個系統，做資料分析、在必要時建立指標（metrics），讓你能迭代、做實驗、改進。

2) 更具體的直覺：從「猜」走向「有回饋訊號」

他舉例：你做了一個「房地產助理」應用，可能會遇到：

  • email 寫得不像你想要的風格
  • 工具（tool）呼叫錯誤
  • 或各種不可預期的錯誤

沒有 evals 的時候，你只能：

  • 改 prompt，然後「希望不要把別的地方弄壞」
  • 靠 vibe checks（憑感覺檢查）——一開始可以，但產品變大很快就失控

evals 的價值在於：它給你一個可依循的回饋訊號，讓你能更有信心地改善產品，而不是靠猜。

3) 主持人提的比喻：Evals 是不是像 Unit Tests？

主持人把 evals 想像成「LLM 的單元測試」。Shreya 的回應很關鍵：這個比喻不完全錯，但太小了。

她說 evals 是個很大的光譜：

  • 單元測試只是其中一小部分：用於檢查一些「不可妥協」的功能
  • 但 AI 助理常常處理開放式任務，你也得評估更模糊的面向，例如：
    • 面對全新型態的使用者需求
    • 新進來的使用者族群（distribution shift / 新 cohort）
    • 長期追蹤使用者回饋（例如 thumbs up、互動等）
    • 定期看資料找出新問題

結論是：unit tests 是 evals 的一部分，但 evals 不等於 unit tests。

🧪 「Show, not tell」：他們用真實產品資料示範 Evals 的起點

這集很重要的特色是：不是抽象講概念，而是直接看產品 logs。

1) 案例公司：Nurture Boss（物業管理 AI 助理）

Hamel 展示他合作過的公司 Nurture Boss，這是一個服務「公寓物業管理者」的 AI 助理，處理：

  • inbound leads（來客線索）
  • customer service（客服）
  • booking appointments（預約）
  • 多通道互動：chat / text / voice
  • 大量 tool calls（訂房、查空房等）
  • RAG retrieval（取回住戶、房源資訊）

Hamel 強調它很適合當教學案例，因為它包含「現代 AI 應用」的典型複雜度。他也提到資料已做匿名化（例如公寓名改成 Acme Apartments），並感謝對方允許他用作教學。

2) 觀測工具（Observability）與 Trace：你要先能「看見」系統在做什麼

Hamel 在一個觀測工具裡載入 logs（他用的是 Braintrust，但他強調工具不重要，也提到：

  • Phoenix Arize（他們與主持人合作的部落格文章版本用它；主持人提 Amon 的文章也用 Phoenix Arize）
  • LangSmith 這些都是可用的選項。

畫面上展示一筆互動的trace：一連串事件的記錄（工程術語）。他說 trace 的概念很久以前就有，但對 AI 應用特別重要，因為系統由多個元件、工具、檢索等組成。

例 1：真實 system prompt

他展示 system prompt（主持人驚訝這通常是公司「皇冠上的寶石」），內容包括：

  • 你是 Acme Apartments 的 leasing team AI 助理
  • 主要回覆文字訊息
  • 目標是提供準確、有幫助的資訊
  • 還包含 tour scheduling、applications、不同 persona 的說話方式等各種指引

例 2：使用者問一房帶書房，AI 回覆不理想

使用者：「有沒有一房帶 study？我在 virtual tours 上看到」 LLM：

  • 呼叫工具查個人資訊（get individuals information）
  • 查社區空房（availability） AI 回覆：「有幾個一房，但沒有特別列出有 study 的。這裡幾個選項…」 使用者追問：「有帶 study 的什麼時候有？」 AI 回：「我目前沒有關於帶 study 一房的具體可用資訊。」 使用者：「謝謝」 AI：「不客氣，有問題再問。」

Hamel 問主持人：以 lead management 產品來說，這樣好嗎？主持人說「不理想」。Hamel 補充：很多人會以為 AI「誠實」說不知道就是對，但產品角度應該要「轉接人工」或做更積極的引導。因此在此筆 trace 的 note 寫：「should have handed off to a human」。

📝 第一個關鍵步驟：Error Analysis（錯誤分析）＝ Open Coding（開放式編碼）

這段是整集的核心：他們強調多數人一開始就犯錯——直接跳去寫測試。

1) 為什麼不能直接「寫 tests」？

Hamel 說，常見陷阱是「立刻寫 tests」，但對 LLM 應用通常不是最好的起點，因為：

  • LLM 系統的行為更「stochastic（隨機）」、表面積更大
  • 你需要先用資料去「落地」：到底哪裡壞、最常壞在哪

因此應先做 error analysis：抽樣看資料、逐筆記筆記。

2) Open coding 怎麼做？原則：只寫「最上游、第一個看到的錯」

Hamel 說做法其實很「chill」：

  • 先抽樣，不用看完所有 logs
  • 用產品帽（product hat）看每筆 trace
  • 只寫下你第一個看到的錯（最 upstream 的錯）就停，繼續下一筆
  • 一開始前幾筆可能痛苦，但很快會越做越快
  • 每個 observability 工具基本都能寫 notes

他甚至說：「每個人做了都會上癮。」因為能在很短時間內學到產品真相。

3) Open coding 的示範：各種「真實世界的亂」

他連續展示不同類型的錯誤，呈現「錯誤的多樣性」：

例 3：文字訊息被切碎，對話流程很卡

使用者的訊息被拆成短片段、甚至斷字，AI 不知如何回應。Hamel 說這比較像技術問題（channel 的特性），可寫 note：conversation flow is janky because of text message（他用 “janky” 形容很口語，主持人也注意到這個「很不正式但可行」的風格）。

例 4：AI 幻覺：說提供 virtual tour，但實際沒有

使用者問兩到三房、是否有 virtual tour。AI 回覆不只給房型價格，還說「我們提供 virtual tours」。但實情是：根本沒有 virtual tour。因此要記錄：hallucinating something that doesn’t exist。

🤖 常見誤解破解：能不能叫 AI 直接幫你做 error analysis？

主持人問：能不能讓 LLM 取代人工看 trace？

Shreya 的回答非常直白：在 free form note-taking（自由筆記）這一步，不是 LLM 擅長的地方。原因是：

  • LLM 很可能會說「這 trace 看起來很好」
  • 它缺乏產品語境：例如 virtual tour 那例子，LLM 很可能判斷「回答得很好」，但人知道功能根本不存在

她也澄清：未來或現在有些部分可以用 LLM 輔助，但至少此刻，open coding 這步不該交給 LLM。

👑 「仁慈的獨裁者」：避免委員會把流程搞到做不下去

這是訪談中一個非常有記憶點的概念（主持人說他很喜歡）：benevolent dictator（仁慈的獨裁者）。

Hamel 解釋：許多團隊在 open coding 會陷入「大家一起討論、開會、共識決」的泥沼；但很多情境下這是完全沒必要的。你需要的是：

  • 指定一個你信任品味（taste）的人
  • 讓流程保持可負擔、可持續
  • 不然成本太高，最後乾脆不做，等於輸掉

誰適合當這個人？

  • **domain expert（領域專家）**一定要是
    • 法律 → 法務／律師
    • 心理健康 → 精神科醫師等專家
    • 這個公寓租賃案例 → 了解 leasing 業務的人
  • 很多時候也會是 產品經理（PM）

主持人補一句：這個人可能覺得不公平（怎麼我變獨裁者），但「是仁慈的」，重點是快速前進、不是追求完美。

🔎 做多少筆才夠？100 筆、理論飽和（theoretical saturation）

對於「要看多少筆 trace？」他們給了兩層答案。

1) 操作上：先做 100 筆，讓你心理不卡住

Hamel 說他們建議至少 100 筆，不是因為 100 是神奇數字，而是：

  • 做到 20 筆時，你通常已經覺得超有用、會想繼續
  • 說「100」能讓人心理上解除「無止盡」的恐懼：你知道先做完這一段就好

2) 理論上：做到「你不再學到新東西」

Shreya 補上學術術語：theoretical saturation（理論飽和），意思是：

  • 當你再看下去已經不會產生新類型的 notes/概念
  • 或不會實質改變你下一步要做什麼
  • 初學者還沒直覺很正常，做幾輪就會建立感覺，有人可能 40、60、甚至 15 筆就飽和，取決於產品與你的熟練度

🧩 從 Open codes 到 Axial codes：開始用 AI 做「整理與歸類」

當你累積了很多 open code（自由筆記），下一步是把混亂變成可行動的結構。

1) Axial codes 是什麼？＝ failure modes 的分類標籤

Shreya 解釋得很清楚：

  • open codes 不是 100 個獨立問題，很多只是同一類問題的不同說法
  • 你不該在 open coding 當下硬建 taxonomy（分類法）
  • axial code 可以理解成「失敗模式（failure mode）」的類別標籤
  • 目標是把問題聚成「少數幾類」，找出最常見／最重要的，才能去攻擊它

2) 這一步可以用 LLM 幫忙，但要人放在迴圈裡

Hamel 示範把 notes 匯出成 CSV，丟到 AI 工具做分析。他提到他在錄節目前用三種 AI 工具做過分類：

  • Claude（他展示 Claude 解析 CSV，產生分類）
  • ChatGPT（同樣 prompt 可用）
  • Julius AI（他喜歡用，因為它走 notebook / Jupyter 的資料科學風格）

他還提到一個細節：他在 prompt 裡直接用「open codes」「axial codes」這些術語，因為這些概念源自社會科學、存在很久，LLM 知道這些詞，能幫你快速對齊任務。

Claude 產出一批分類（例如 capability limitations、misrepresentation、process/protocol violations、human handoff issues、communication quality 等）。但 Hamel 說：

  • 有些太泛（例如 capability limitations 太不 actionable）
  • 需要人介入改名、改成更可執行的分類

📊 最樸素也最強：Count（計數）＋ Pivot table，把「混亂」變成「優先級」

他們強調一個近乎「反直覺但很真」的觀點：最強的分析技巧常常就是基本計數。

流程是：

  1. 把你喜歡的 axial codes 整理成清單（Hamel 甚至示範用 Excel 公式把 codes 拉成逗號分隔）
  2. 用試算表的 AI 功能（他用 Gemini in Sheets）把每個 open note 自動歸類到某個 axial code
    • 重要細節：open code 要寫得夠具體
    • 你不能只寫「janky」，不然 AI（甚至人）都不知道你在說哪種 janky
  3. 設一個「none of the above」類別（Shreya 建議），用來偵測分類不完備，反過來提醒你補新類別或改寫類別
  4. 做 pivot table 計數各類出現頻率

結果（在他們示範的資料中）：

  • conversational flow issues 出現 17 次 Hamel 說 pivot table 很好用，還可以 double click 追到該類的所有原始資料。

但他也提醒：頻次不一定等於優先級。有些低頻問題可能風險更高、更該先修。

他也指出：不是每個問題都需要做 eval。像 formatting error 可能只是 prompt 沒寫清楚，直接修 prompt 就好；甚至某些檢查可以用純 code（不用 LLM）完成，因為成本更低。

🧑‍⚖️ 兩種「自動評估器」：Code-based vs LLM-as-a-Judge

這裡他們把「自動化評估」拆得很清楚。

1) Code-based evaluator：能用程式判斷就用程式

Shreya 說，與其糾結「eval 是否等於某種形式」，你可以把它想成：automated evaluator（自動評估器）。

適合用 code 的例子：

  • 輸出是否為 JSON
  • 是否符合 Markdown
  • 長度是否太長／太短
  • 格式是否符合規範
    這些都可用 Python function 或規則近似判斷，成本低、穩定。

2) LLM-as-a-Judge：針對「難以用 code 表達」的狹窄問題

對於更主觀、更語境化的 failure mode，就用 LLM 當裁判，但要注意兩個原則：

  • 範圍要小：一次只判斷一個 failure mode（例如「handoff 是否該發生」）
  • 輸出要二元：pass/fail、true/false
    他們非常反對 1 ～ 5、1 ～ 7 這類 Likert scale，因為：
  • 很容易變成「不做決策的逃避」
  • 報表上 3.2 vs 3.7 沒人知道代表什麼
  • 也容易導致大家對 eval 失去信任

Shreya 補強：LLM judge 沒你想的那麼難，因為 judge 只做一件事、輸出也是二元，它可以非常可靠。它不只可放在 CI／unit tests，也可用於線上監控（production monitoring）：每天抽樣 1000 筆 trace 去跑 judge，看失敗率。

✅ LLM Judge 不是寫完就算：一定要做「對齊人類標註」與錯誤矩陣

這段是他們在「人們為什麼會被 evals 燒傷」上給出的關鍵解方。

1) Hamel 的 handoff judge prompt

他展示一個 handoff 的 judge prompt（他說可用 LLM 協助生成，但人要審、要改）。這個 prompt 指示 judge 輸出 true/false，並列出何時應 handoff，例如：

  • 使用者明確要求人工
  • 使用者被忽略或陷入 loop
  • 政策要求轉接
  • 敏感住戶議題
  • 工具資料不可用
  • 當天 walk-in 或 tour 的需求等

2) 最大地雷：把 judge 當福音，直接上線

Hamel 警告：很多人寫好 judge 就「信了」，覺得 judge 說錯就是錯。這會讓 eval 與現實不匹配，最後團隊失去信任，「反 eval」就誕生了。

所以你必須做：judge alignment（對齊）
方法是：把 judge 的判斷和人類（你在 axial coding 時的標註）比對。

3) 別只看「agreement 百分比」：那會騙人

Hamel 說只看 agreement 很危險，因為錯誤常在長尾。假設某錯誤只占 10%，judge 若永遠判定「pass」，也能有 90% agreement——看似很高但完全沒用。

正確做法：看混淆矩陣（confusion matrix），關注：

  • human=false、judge=true（誤報）
  • human=true、judge=false（漏報） 也就是矩陣裡非對角線的錯誤格子。如果有人只拿「75% agreement」就說 OK，卻沒有矩陣、也沒迭代 prompt 去降低誤差，這就是「bad smell」。

🧾 「Evals 是新的 PRD？」——他們的回答是：像，但更動態、來自真實資料

主持人提出很有力的觀察：這個 judge prompt 看起來像 PRD（產品需求文件）：

  • 明確列出行為要求
  • 可自動、持續運行
  • 甚至像「產品應該如何回應」的可執行規格

Hamel 同意，但 Shreya 加了一個更深的點：你從資料中會發現你原本想不到的需求。也就是說：

  • 不要在看資料前就把「期望」全寫死
  • 因為你根本不知道 failure modes 會長什麼樣
  • 你會不斷修正「什麼叫好」

這也呼應 Shreya 的研究。

📄 研究支撐：Shreya 的論文《Who Validates the Validators》

Hamel 特別把一份研究報告拿出來介紹：由 Shreya 與合作者撰寫的 《Who Validates the Validators》（他稱「你想懂 evals 最酷的研究之一」）。

Shreya 解釋他們在 2023 年底做的 user study：讓開發者嘗試寫 LLM judges 或驗證輸出。關鍵發現是 criteria drift（評判標準漂移）：

  • 你無法一開始就把 rubric（評分規則）完全定義好
  • 專家看了 10 個輸出才想到新 failure mode
  • 「什麼是好／壞」會隨著你看更多資料而改變
    這就是為什麼這波 AI 開發「特別難」：不是因為 ML/AI 新，而是因為輸出空間與需求理解是動態演化的。

🧰 Evals 做到哪一步算「落地」？Unit tests + 線上監控 + Dashboard

他們描述「接下來怎麼用」的方式很實務：

  • 把 LLM judge 放進 unit tests/CI：每次 code 變更都跑，確保以前看過的失敗案例不再復發
  • 做 production monitoring：每天抽樣跑 judge，追蹤 failure rate
  • 建 dashboard：把特定 failure mode 的表現長期可視化

Hamel 補一句很現實的觀察：很多公司其實做得很系統，但不太公開談，因為這是護城河（moat）。如果你是 email writing assistant，這套「如何把品質做得更好」的方法論與資料資產，本來就不想讓競爭者輕易複製。

⚔️ 為什麼 Evals 這麼有爭議？他們認為是兩大原因

主持人提到他在 X（Twitter）看到很多「drama」，有人說不要做 evals、有人說只靠 vibe 就好。

Shreya 的觀點很「和解」：其實大家不一定站在對立面，更多是因為：

1) 每個人對「evals」的定義太狹窄、彼此雞同鴨講

有人以為 evals 只等於 unit tests；有人以為只等於 LLM judge；有人以為不含產品指標／監控。定義不同就會吵。

2) 很多人曾被「做得很爛的 evals」燒傷

典型燒傷方式：

  • 用 Likert scale judge
  • 沒做對齊與混淆矩陣
  • 後來發現 judge 跟人類期望差很大 → 從此不信 evals → 變成反 evals

Shreya 說她完全同理，而且她也「反 Likert scale LLM judge」。

🧑‍💻 「Claude Code 說他們不做 eval，只看 vibes」——他們怎麼回應？

主持人把爭議拉到具體事件：有人（主持人說可能是 Claude Code head engineer）上 podcast 說「我們不做 eval，我們只 vibe」。那 evals 真的必要嗎？

Shreya 的回應有兩層：

  1. Claude Code 站在很多 eval 的肩膀上
    因為 Claude 的（微調後的）模型本身就是在多種 coding benchmarks 上被大量評測過，這些評測結果也公開可見。不能否認背後有 eval 系統。

  2. 他們很可能在做「隱形的 eval」
    就算不用「eval」這個詞，他們也可能在做：

  • 使用者與互動指標的監控（多少人用、對話多長等）
  • 內部 dogfooding
  • 有問題就進 queue、回饋給負責人
    這些本質上也是 error analysis 與評估。

Hamel 補充一個重要差異：coding agent 的情境很特殊，因為：

  • 開發者本身就是 domain expert
  • 會整天使用（強 dogfooding）
  • 能「看見輸出的 code」快速判斷好壞
    所以它的 eval 流程可以更短路；但別把這種情境推廣到醫療、法律等領域（醫生不會容忍「AI 給錯建議」來幫你 dogfood）。

🧪 「AB testing vs evals」是稻草人之爭：AB test 也是 eval 的一種

他們認為「AB tests vs evals」本身就是混淆。

  • AB test 需要指標（metric）來比較，而指標本質上就是 eval
  • 他們對 evals 的定義是：系統化衡量品質，所以 AB test 當然在其中

但 Shreya 提醒：很多人過早做 AB test，基於「想像中的需求」下假設，而不是先做 error analysis。真正好的方式是：

  • 先從資料裡找出真實 failure modes（像 text message 斷字、handoff 的怪問題）
  • 再用它來形成假設與 AB test
    否則 AB test 可能在測一堆不重要或方向錯的東西。

🏢 主持人追問：OpenAI 收購 Statsig（A/B 工具）代表什麼？

主持人問 Statsig 被 OpenAI 收購是否意味著 AB test 更重要。Hamel 說他不掌握內情，只推測可能有策略性；但他更想強調的是：

  • labs 一直都有做 evals（foundation model 的 MMLU、HumanEval 等）
  • OpenAI 甚至會回頭分析 Twitter 情緒、Reddit 貼文抱怨，試著把外部訊號拉回產品改善
  • 希望未來 labs 能更重視「產品特定（product-specific）」的 eval，而不是只看通用 benchmark（因為 handoff 這種問題跟數學解題分數不相關）
  • 很多 labs 的 eval 產品還停在「cosine similarity、hallucination score」這種泛用工具，長期來看不夠，需要更多資料科學式的 error analysis 流程

Shreya 甚至半開玩笑說：「我們不該是地球上唯二在推這種結構化方法的人，太荒謬了。」

❌ 最常見的三個誤解（Misconceptions）

Hamel 提了最常見的兩個：

  1. 「買個工具插上去，AI 會自己幫我 eval」
    他說這是最大誤解：大家太想要這件事，所以市場上也有人賣，但「不 work」。

  2. 不看資料
    他說他做顧問時，客戶常帶著問題來，但一問「我們看 trace 吧」對方會愣住。只要真的去看 trace，100% 都會學到很多，也常常直接找到問題。

他補充第 3 點：eval 沒有唯一正解；錯的方法很多，但對的方法也不只一種。你得看產品階段、資源、脈絡來設計做法；但無論如何「某種形式的 error analysis」幾乎不可或缺。

✅ 兩個最重要的實作建議：目標是改善產品，不是把 eval 做得漂亮

Shreya 的建議聚焦在心法：

  • 不要怕自己做得不完美：eval 的目標不是完美，而是「能採取行動地改善產品」
  • 在整個過程中善用 LLM：用來整理想法、改善 PRD、把 open codes 回寫成更好的需求文件
    但重點是：別用 AI 取代你自己（仍然要人放在迴圈裡）

Hamel 的建議更偏工具化：

  • 既然「看資料」是最高 ROI，就應該用 AI 協助你把「看資料的摩擦」降到最低
    他展示 Nurture Boss 自己做的內部工具介面截圖，包含：
    • voice/email/text 分 tab
    • thread 列表
    • system prompt 預設隱藏（提升可讀性）
    • axial coding 的錯誤計數可視化（紅色顯示數量） 他說這些介面幾小時內就能做出來（在 AI 幫忙下更容易），而且「one size fits all」很難，所以乾脆自己做最貼合需求的工具。

⏱️ 這會花多久？一週入門、之後每週半小時

主持人問最現實的問題：第一次要花多久？

Shreya 給出她的節奏：

  • 初期：3 ～ 4 天，做多輪 error analysis、大量標註，直到能做出像 Hamel 那個試算表，並產出一些 LLM judge evaluators
  • 後續：把流程接進測試、寫腳本、設 cron job 每週跑
    維護時間可能只要：每週 30 分鐘
    她也坦承自己很「data hungry」，常花更多時間是因為好奇，但不是必須。

🎉 這流程其實「很好玩」：產品帽的快樂與殘酷

Hamel 分享他前一天看客戶資料的故事：那是一個自動寄 recruiting emails 的應用。他們一打開 trace，看到信件開頭「Given your background, …」他立刻說：

  • 「我討厭這種 email，我看到 Given your background 就刪掉」
  • 客戶一開始還覺得 AI 已經把名字、連結、資訊放對了，很「對」
  • 但從產品角度看，這是「很泛、像罐頭」的感覺
    他用這故事強調：error analysis 的樂趣來自你用產品品味去挑戰「看似正確」的輸出。

🎓 他們的 Maven 課程教什麼？有哪些「福利」？

主持人說這集只是表面，請他們介紹課程。

1) 課程內容（syllabus）

Shreya 說課程涵蓋：

  • error analysis 全生命週期
  • automated evaluators
  • 如何建立「改善飛輪（flywheel）」把 eval 變成持續改進系統
  • special topics：如何為 error analysis 自己做介面（他們會 live code）
  • 成本優化：當你的 eval 與產品都很強但太貴，如何用較便宜模型（她舉例：把昂貴的 GPT-5 類模型部分替換成 5 nano、4 mini 等）降低成本、維持品質

2) 課程福利（perks）

Hamel 說他最喜歡的福利是：

  • 一本 160 頁、寫得非常仔細的書（book），把整個 eval 流程完整記錄，學生不用狂抄筆記
  • 他們做了一個像 LennyBot 的「課程專用 bot」
    • 用的是和 LennyBot.com 相同的軟體
    • 把他們「所有談過 evals 的內容」灌進去：每堂課、office hours、discord chat、公開文章、論文等
    • 並給學生 10 個月免費、無限制使用
  • 另有一個非常活躍的 discord：所有歷屆學生都在，活躍到他說「我坐飛機度假也一直跳通知」，苦樂參半

主持人還建議他們用 Delphi 的 voice mode 訓練 bot（他說那是他最愛的功能之一，且「11 labs powered」），並說既然這集 podcast 產出，也可以拿來訓練。

💡 這場訪談真正的主張（把所有細節串成一句話）

他們整套方法，其實不是在宣傳某個工具或某種神秘工程，而是在把「AI 產品開發」拉回一個可重複的基本功流程：

  • 先看 trace（觀測）
  • 做 open coding（人工、領域專家、仁慈獨裁者）
  • 用 LLM 做 axial coding（整理、不是取代判斷）
  • 用最基本的 count／pivot table 找出優先級
  • 能用 code 寫 evaluator 就別用 LLM
  • 必要時做 LLM-as-judge，但一定要二元輸出、做對齊與混淆矩陣
  • 把 evaluator 放進 CI 與線上監控，形成改善飛輪
  • 別追求完美 eval，追求可行動的產品改善

而所有爭議（vibes vs evals、AB tests vs evals）在他們眼中，多半是定義誤會或做壞了被燒傷。真正成熟的團隊，無論叫不叫 evals，終究都在做某種形式的系統化品質衡量——只是差別在於：你做得有沒有方法、能不能規模化、能不能被信任。