為什麼需要 prompt eval

TL;DR

• 沒 eval 的 prompt 改進 = 不知道有沒有變好，只是換個寫法
• Eval = test cases + grading rubric——把「好不好」變成可比較的數字
• 一開始 5–10 個 test case 就夠，重點是跑得快、能比較

一個情境：demo 沒事，user 一進來就崩

你寫了一個客服信分類 prompt，自己挑三封信丟進去測，分得不錯，老闆說可以上。

上線第二天：

• 一封中英夾雜的信被分成「其他」（其實是退款）
• 一封整封都是 emoji 的被丟進「技術問題」
• 一封很長的客戶抱怨被截斷在第一段，分到「帳號」

你開始一個一個改 prompt——加一句「處理多語言」、加一句「忽略 emoji」、再加一句「看完整封信」。改完再試那三封原本的 demo 信，還是分得對，安心了。

但你不知道的是：你加那句「忽略 emoji」順便讓另外 30 封信的分類變糟了。因為你只看那三封原本的 demo case。

這就是沒 eval 的 prompt 工程：每次改完都像在賭。

Manual review 的天花板

最常見的「測 prompt」流程：

1. 寫 prompt
2. 自己腦中想幾個 case 丟進去
3. 看起來對 → 出貨

這個流程的問題不在「不認真」，在規模根本不夠。三個 case 涵蓋不了 prompt 的真實 input 分布。Prompt 改一改 demo 對了，user 一進來各種你想不到的輸入照樣崩。

做法	多少 case	怎麼判斷好不好	改 prompt 後能比較嗎
隨手測幾下	1–3	主觀「看起來對」	沒紀錄、沒辦法
一輪 manual QA	10–20	人盯每一個輸出	很慢，且人會疲勞，case 一多就放水
Eval pipeline	50–500+	grader 給數字分數	可以，直接比平均分

Eval 之於 prompt，像 test 之於 code

寫 code 沒人會「跑一次沒爆就上 production」。我們會：

• 寫 unit test 鎖住 expected behavior
• 改完 code 跑全部 test，看哪個壞掉
• regression 立刻被抓到

Prompt 該用一樣的態度：

• Test cases：一組有代表性的 input（user 真實會丟的那種）
• Grader：一個能對「這次的輸出好不好」打分的東西（code 或 LLM 都行）
• 改 prompt → 跑 eval → 看分數：取代「改 prompt → 自己看一眼 → 感覺更好」

Eval 不是 prompt 工程的「後續優化」，而是 prompt 工程的前提。沒有客觀分數，你連「v2 比 v1 好」都證明不了。

「我沒時間做這個」是錯的直覺

很多人覺得 eval 是「公司有錢請 ML team 才在做的事」。其實剛好相反：沒資源的時候才更需要，你經不起上線後才發現 prompt 廢掉。

Eval 不需要一開始就完美：

• 5–10 個 test case 就能起跑，後面再慢慢加
• Grader 可以從 regex / JSON parse 開始，不一定要叫 LLM
• 跑一次 30 秒——比你手動測三個 case 還快

第一版 eval 的目的不是抓所有 bug，而是建立一個能反覆比較的基準。有了基準，每改一次 prompt 才知道是真的好還是只是換個說法。

三條路，選哪條

寫完 prompt 後常見的三種選擇：

選項	做法	風險
1	自己測一兩次就出貨	user 進來各種崩，你不知道哪裡崩
2	多測幾個 corner case，手調 prompt	改 A 修了，B 壞了，你也不知道
3	跑 eval pipeline 拿分數，再迭代	前期多花時間，但每次改都有數字撐腰

選項 1、2 是所有工程師都掉過的坑（包括我）。寫給人玩的 demo 用 1、2 沒差；寫進 production 的 prompt 一定要 3。

跟 上一篇談 temperature 與 structured output 是同一個邏輯：production LLM code 該被當「會壞掉的系統」對待，不是「神奇黑盒子」。Eval 就是這個態度的延伸。

接下來

下一篇 eval-workflow 實際走完一輪：怎麼定義任務、怎麼叫 Claude 自動生 dataset、怎麼把第一版 prompt 故意寫爛當 baseline、怎麼從 2.3 分爬到 8 分。