評估的護城河不在 AI，在人的品味
評估不能只靠 AI 自動生成：自上而下的標準它很擅長，但真正決定產品好壞的自下而上評估——從錯誤數據裡提煉的品味——必須由人來提供，再借助 Claude Code 規模化執行。
核心論點 · 點時間戳可跳到原聲
模型能替你寫標準，替不了你的口味
Shreya 把評估分成兩類：自上而下是根據任務本質預先設定的，比如長度、可執行性；自下而上則是瀏覽大量樣本後，把直覺性不滿沉澱成規則。Claude 對自上而下很在行，但自下而上必須由人來提供，因為模型無法憑空知道你的口味。這也是為什麼評估必須迭代：每發現一個新失敗模式就補一條規則，但要注意別過度擬合到單次訪談上。
— Shreya評估標準太長，模型會偷偷跳過
Shreya 建議把評估標準分成兩組，讓子代理分組評估，避免模型面對長清單時偷懶忽略。同時讓技能自動生成一張電子表格（或透視表），列出每條標準的通過與失敗情況，這樣你能快速判斷哪些標準對當前任務更重要，甚至手動加權，而不必盲從統一權重。
— Shreya15 分鐘搭個界面，勝過盯著表格看
Shreya 演示了她的 error discovery skill：第一步讀數據並判斷語義類型（是文章、代碼還是 trace）；第二步設計視覺編碼，用顏色、間距、透明度凸顯數據差異，讓人更容易看；第三步用 HTML 和 Python 搭建審查界面；第四步由 AI 聚類並挑選多樣化的樣本；第五步進入交互循環——你在界面上給開放反饋，Claude Code 實時讀取並把反饋整合成新樣本或評估標準。整套流程約需 15 分鐘，但換來的是遠超表格的可讀性。
— Shreya人只管說不喜歡，歸類交給 AI
Hamel 解釋這套交互背後的機制：人讀樣本時順手給出開放式評論，比如「我不喜歡否定對比」「這很煩但說不清為什麼」，後臺的 Claude monitor 工具會持續消化這些評論，在積累到約十條後自動開始歸納主題，並主動掃描全部樣本，把同類問題自動標註出來。核心哲學是：人類負責品味和判斷，AI 負責規模化地發現和歸類，而不是替人發明標準。
— Hamel錯誤分析的產物就是你的評估標準
Shreya 指出，錯誤分析產生的不只是問題列表——這些失敗模式可以直接變成你的 rubric，也就是評估標準。她演示中自動生成的 361 條建議裡，最常見的是少於四詞的 staccato 碎片（249 條）。把這些標準寫進技能，以後每次生成後就能用 LLM judge 逐條判定；同時，由於你已經有了人工標註的數據集，還可以反向驗證這些評估標準本身是否可靠。
— Shreya自動評估工具漏掉的正是產品判斷
Hamel 分享了他們對 Brain Trust、Arize、LangSmith 這類自動評估工具的基準測試：它們能捕捉工具調用失敗、用戶表達不滿這類明顯錯誤，但普遍漏掉需要產品判斷的隱性錯誤——比如一個房產銷售 bot 面對「你們沒有這個房源」的異議時，只會說「抱歉沒有了」，而不會推薦替代方案。更值得注意的是，Claude Code、Codex 等編碼代理與這些工具表現相同，因為底層模型和提示詞本質一致。
— Hamel精確率 90% 也不夠，誤報會歪曲方向
Shreya 補充說，自動化評估工具在最好情況下的精確率也只有 80%-90%，意味著 10%-20% 的報錯其實是誤報，如果盲目照做會歪曲產品方向。所以真正有效的做法是：用工具快速找出明顯錯誤，再手動審查數據，驗證工具的發現、補充它漏掉的地方，並確保你的品味注入產品。這才能和競爭對手拉開差距。
— Shreya用評估換便宜模型，成本能砍 100 倍
提到課程深度，Shreya 說除了錯誤分析與生產化，還覆蓋瞭如何把評估接入 CI/CD、監控長期漂移、對抗性評估（防止租戶數據洩露）等。最實用的部分是改進模塊：用評估來指導模型切換——換便宜模型時，通過評估優化其準確率，他們實際幫學生和客戶把成本砍掉了 100 倍。這是純評估技能之外的工程能力。
— Shreya原話 · 已逐字校驗
Now Claude is very very bad at coming up with bottomup evals. That's all you
Claude 非常非常不擅長提出自下而上的評估，這完全靠你。
Shreya6:03
we joke that writing is the final boss for LLMs
我們開玩笑說，寫作是 LLM 的終極 Boss。
Hamel11:05
the interface that it comes up with is going to be so much better than me looking at my data in say Google spreadsheets or something
它生成的界面會遠好過我在 Google 表格裡查看數據。
Shreya16:08
the hardest part of eval is error analysis which is coming up with this rubric
評估最難的環節是錯誤分析，也就是想出一套評分標準。
Shreya34:22
There's there is no world in the future. Even if you have AGI, if you're building a product, you have to look at your data.
未來也不存在這樣的世界。即使你有 AGI，只要在構建產品，就必須親自看數據。
Hamel39:25
It's really hard for humans to upfront think of like from top down like what are all the things that are good and bad. It's like almost impossible.
要讓人類預先從頭想清楚什麼是好什麼是壞，真的很難，幾乎不可能。
Hamel47:31
數字與實體
| 錯誤發現技能自動生成的建議總數 | 361 條 | 34:22 |
| staccato 碎片（≤4 詞短句）數量 | 249 處 | 34:22 |
| 審查界面構建耗時 | 15 分鐘 | 24:15 |
| 自動化評估工具最高精確率 | 80%-90% | 50:33 |
| 通過評估優化實現的成本下降 | 100 倍 | 52:35 |
| 觸發自動標註所需的人工反饋數 | 約 10 條 | 28:19 |
術語
- bottom-up evals自下而上的評估
- 從大量真實輸出中，由人提煉失敗模式而形成的評估標準。
- top-down evals自上而下的評估
- 基於任務本質與領域知識預先設定的評估標準，與數據無關。
- LLM judgeLLM 評判器
- 讓模型根據明確標準對輸出做出通過/失敗的判斷。
- error discovery錯誤發現
- 通過審查數據找出失敗模式並固化為評估標準的工作流。
- staccato fragments短句殘片
- 少於四個詞的破碎句，AI 寫作常見的湊字數風格。
- slop廢話/水詞
- AI 生成中空洞、套路化、缺乏信息量的套話。
收聽指南
用 LLM 構建產品（尤其聊天機器人、寫作工具、Agent）的工程師與創業者，正在頭疼怎麼設計評估體系的人。
[08:04] 廣告插播可跳過。