開發 AI 應用有一個常見的誤解: 以為只要給一份 PRD，條列清楚需求規格，AI Agent 就能乖乖照做。但現實是——你不是在寫傳統軟體，光靠一份需求文件搞不定 LLM。你需要的是上百、上千條的 eval 資料集，才能真正「塑造」一個 Agent 的行為。

這個觀念叫做 Eval 就是 Spec——在 AI 產品中，eval 資料集才是你真正的規格書。

品質是分布，不是一個數字

傳統軟體測試是確定性的: 輸入 A 就該產出 B，對就是對、錯就是錯。但 LLM 不是這樣運作的。你的模型可能 87% 的時候是對的，但那 13% 的失敗長尾，偏偏集中在你的重度使用者最在意的場景上。

如果你只看平均準確率就發佈產品，那你發佈的是錯的產品。品質是一種分布，你需要理解整個分布的形狀，而不是只盯一個數字。

為什麼 PRD 在 AI 時代行不通

傳統軟體中，PRD 描述要做什麼，工程師照著做就好。但 AI 產品本質上是機率性的——同一個輸入跑兩次可能得到不同輸出，不存在「唯一正確答案」。傳統的驗收清單假設了確定性的世界，套在 LLM 上根本不夠用。

Andrew Ng 在 DeepLearning.AI 的文章 Best Practices for AI Product Management 裡直接講了這件事:

「就像機器學習演算法需要訓練範例來學習，AI 產品開發團隊也需要具體的範例來定義我們希望 AI 系統做什麼。換句話說，資料就是你的 PRD。」

他舉了一個例子: 如果產品經理提出「做一個回答銀行帳戶問題的聊天機器人」，這種規格太模糊了——要回答餘額查詢就好? 還是也要回答利率、轉帳流程? 但如果產品經理直接寫出 10 到 50 筆具體的對話範例，展示「這個聊天機器人應該怎麼回答」，範圍一下就清楚了。工程師可以評估技術可行性，然後朝著這些範例去建構系統。

Andrej Karpathy 早在 2017 年的 “Software 2.0” 文章就從更底層的角度點出了一樣的事: 傳統軟體是人類一行一行寫指令，但 AI 軟體的「原始碼」本質上就是資料集加上模型架構。人類定義目標、提供資料，系統自己學出實作方式。

Ng 在另一篇 Coping With Product Specification 更具體地說: AI 產品的規格應該包含「量測指標」加上「用來評估指標的資料集或資料分布」。而且要針對不同的資料切片(slice)分別設定效能門檻——比如一個醫療 AI，對嚴重疾病和輕微疾病的準確率要求可能不同，對不同年齡、性別的使用者群體也要分別檢查公平性。這已經不是傳統 PRD 能處理的事了。Groundy 有一篇 Data IS Your PRD 把 Ng 的這套思路整理得蠻完整的，推薦一讀。

把這個思路推到極致就是: eval 資料集才是規格書。 如果你的團隊在第一天沒有一套共享的 eval 評分標準，之後每次談論品質，都只會變成「憑感覺」的討論。

Eval-Driven Development 這個社群把這件事講得更明白: 軟體開發已經進入 Agent 時代，工程師的工作不再只是產出能動的程式碼——而是定義什麼叫做「能動」，量測它，然後把系統壓在這個定義上。eval 套件不是開發之後的驗收階段，而是開發之前就該建好的規格。

編按: Hamel Husain 和 Shreya Shankar 開設的 AI Evals 課程 已經訓練了超過 4,000 名學員，也替 OpenAI、Anthropic、Google、Meta 等公司的團隊做過顧問。他們的核心訊息很直接: 「每個人都在 demo AI 功能，很少人能可靠地上線。差距在哪? Eval。」Hamel 在他的 Field Guide 裡甚至主張: AI 產品的路線圖不該用「上了幾個功能」來衡量，而是「跑了幾個實驗」——而跑實驗的前提就是有可信的 eval 基礎設施。

每一條 Eval 都是一個向量

Viv Trivedy (LangChain) 提出了一個很精準的比喻: 每一條 eval 都是一個向量，會推動你整個 Agent 系統的行為偏移。

舉例: 如果一條「高效讀取檔案」的 eval 失敗了，你會去調整 system prompt 或是 read_file 工具的描述，直到這條 eval 通過為止。你加進去的每一條 eval，都在對整個系統施加壓力，持續把行為往你想要的方向推。

但 Viv 也強調了一個關鍵: 更多 eval 不等於更好的 Agent。 盲目丟進幾百幾千條測試，只會製造一種「Agent 在進步」的假象——因為你可能在一個不反映真實生產環境的 eval 上刷分。重點不是數量，而是每一條 eval 是否精準對應到你在線上環境想要的行為。

LangChain 的 Deep Agents 怎麼做 Eval

LangChain 團隊發了一篇 How we build evals for Deep Agents，完整示範了這套做法，蠻值得細看的。

Deep Agents 是 LangChain 開源的 Agent 框架，驅動了 Fleet 和 Open SWE 等產品。他們建構 eval 的流程分三步:

  1. 先決定要什麼行為: 列出 Agent 在線上環境需要展現的行為(例如跨多個檔案檢索內容、連續組合 5 個以上的工具呼叫)，再針對這些行為設計可驗證的 eval
  2. 每條 eval 自帶文件: 每條 eval 都附文件說明它測量的是什麼能力，並用標籤分類(如 tool_use、retrieval)，方便分組執行
  3. 從追蹤紀錄回饋更新: 檢閱輸出的追蹤紀錄來理解失敗模式，持續更新 eval 覆蓋範圍

Eval 資料從哪來? 他們混合三種來源:

  • 每天自己使用 Agent，每個錯誤都變成一條 eval
  • 從外部基準測試 (Terminal Bench 2.0、BFCL) 挑選並改造成適合自家 Agent 的 eval
  • 團隊手工打造的 eval，針對特定行為(比如測試 read_file 工具的表現)

他們有一個蠻值得參考的做法: 把 eval 按「測試什麼能力」來分類，而不是按「eval 從哪來的」。比方說，一條從外部 BFCL 基準測試改造來的 eval 和一條內部手寫的 eval，只要都在測工具呼叫能力，就歸在同一類。這樣做的好處是，你可以一眼看出 Agent 在「檔案操作」很強、但「記憶」很弱——而不是只有一個籠統的總分。他們的分類包含: 檔案操作、檢索、工具使用、記憶、對話、摘要等維度。

量測指標也不只看「對不對」。 兩個模型可能都能完成同一個任務，但一個多繞了幾步、多呼叫了不必要的工具、延遲更高——在線上環境這就是更高的成本和更差的體驗。所以他們定義了「理想軌跡」的概念: 對每個任務設定最佳路徑(最少步數、最少工具呼叫)，然後量化實際表現和理想的差距。模型選擇就變成一個兩階段的決策: 先看哪些模型夠準確，再從中挑效率最好的。

Eval 是飛輪，不是一次性的事

Viv 在另一則貼文中畫出了完整的飛輪:

🔹 第零步: 打開追蹤，收集 Agent 的所有行為軌跡

🔹 第一步: 分析追蹤紀錄，理解 Agent 行為、切分有用的任務、找出錯誤模式

🔹 第二步: 把追蹤資料轉成 eval，用來改善 Agent

🔹 第三步: 選擇改善路徑——提示詞工程、微調、或兩者兼用

🔹 第四步: 持續滾動，收集更多追蹤紀錄、產生更好的 eval、做人工審查、迭代出更好的 Agent

這個飛輪的核心邏輯是: 從線上環境的追蹤紀錄萃取出來的 eval，會比任何通用基準測試更準確地反映使用者真正在做什麼。通用基準測試能測到一些基本能力(長推理、工具呼叫等)，但針對你的特定場景，客製化的 eval 幾乎一定更有效。

Matt Stockton 的回應也點出了關鍵: LLM 是一個超有能力但高度不確定的技術，整個遊戲就是把它推向你自己定義的「主觀確定性」版本。你可以靠手動看輸出來憑感覺猜，或者你可以用 eval 量化地定義什麼叫做好。建 eval 很辛苦，因為你得真的去看你的資料、去決定什麼是好的輸出——但如果你做了這個辛苦的工作，很多其他事情就變簡單了。

Eval 也是你擺脫貴模型的方法

Aparna Dhinakaran 最近寫了一篇很到位的長文: 如果你被困在昂貴的模型上，eval 就是你脫身的方法。核心論點:

前兩年大家預設「明年的模型會更便宜、更快、更強」，但這個假設正在崩塌。前沿實驗室都在搶算力——Anthropic 租下了整個 SpaceX Colossus 資料中心，OpenAI 用股權換算力，Google 砍了免費 API 額度。前沿模型的推理成本短期內不會如預期下降。

在這個現實下，eval 不再是可有可無的東西，而是讓你可以換到更便宜模型的唯一機制。你有一個跑在 Opus 上的工作負載，想知道能不能搬到 Sonnet 或 Haiku? 唯一誠實的答案就是: 跑 eval。

關鍵是你的 eval 必須夠格:

  1. 覆蓋使用者真正碰到的情境，按頻率加權——從線上追蹤紀錄開始，不是從想像開始
  2. 品質標準要具體到可以被反證——「有幫助」不是標準；「提取所有五個必要欄位，欄位準確率 97% 以上，無幻覺欄位值」才是
  3. 用你信任的評判者——用 LLM 當裁判可以，但必須對齊人類標註的結果
  4. 跑起來夠便宜——跑不動的 eval 等於文件，不是基礎設施

Eval 是護城河

回到 Viv 的觀點: eval 可以成為你的護城河，因為它是幫你定義和量測 Agent 行為的核心物件。你的 eval 在覆蓋率和行為量測上越好，你的 Agent 就越好。而且這個護城河會隨時間加深——當你部署 Agent、收集追蹤資料、從線上環境的失敗模式中產生更好的 eval，整個正向循環就開始轉動。

甚至不用一開始就搞得很完美——Viv 說得好: 就算只有 5 條 eval，只要是團隊坐下來一起討論出來的，就已經是建立護城河和啟動改善迴圈的起點了。

給決策者的重點

如果你是 AI 產品的決策者或開發者，請記住:

不要期待一份 PRD 就能讓 AI Agent 做對事情。 PRD 能描述「要做什麼」，但沒辦法精確定義 LLM「該怎麼做好」。你需要的是一套 eval 資料集——幾十條、幾百條、最終上千條——去描述「在各種情境下，好的輸出長什麼樣」。這些 eval 不只是測試，更是規格本身。它們定義 Agent 的行為、驅動改善的方向，最終決定產品品質的上限。

傳統軟體工程有句名言: 「沒有測試的程式碼就是遺留程式碼。」在 AI Agent 時代，這句話要改寫成: 沒有 eval 的 Agent 就是在碰運氣。