「感覺變好了」不算數：為什麼你的 prompt 需要評測

很多人以為 prompt 寫得順、讀起來舒服，就代表寫得好。不是，那只是起點。真正決定一個 AI 應用可不可靠的，是你有沒有辦法把這個 prompt 的表現量出來。

這篇要把兩件常被混在一起講的事分清楚：prompt engineering 與 prompt evaluation。憑感覺改 prompt，遲早會在正式環境付出代價。

兩個名詞：一個管怎麼寫，一個管寫得好不好

prompt engineering 是你的寫作工具箱，裡面裝著各種讓 prompt 更有效的技巧：multishot prompting 多給幾個示範例子、用 XML 標籤把結構標清楚，還有許多最佳實務。這些技巧的共同目的，是讓 Claude 準確理解你在問什麼、希望它怎麼回。

prompt evaluation 走的是另一條路：它不管你怎麼寫，而是用自動化測試去量測 prompt 的實際效果。你可以拿輸出和預期答案比對、讓同一個 prompt 的不同版本互相較量，或是系統性地檢查輸出有沒有錯誤。一句話講完：engineering 負責把 prompt 寫好，evaluation 負責證明它真的好。

寫完 prompt 之後，你面前有三條路

「寫完 prompt 之後要做什麼」，攤開來看其實只有三條岔路。

1. 路線一：測一次，覺得可以就上線。風險最高，使用者丟進來的輸入千奇百怪，正式環境很容易直接翻車。
2. 路線二：多測幾次，順手修掉一兩個邊角案例。比路線一好，但使用者給的輸入常常超出你的想像，漏網之魚還是很多。
3. 路線三：把 prompt 丟進評測管線打分數，再根據客觀指標迭代。前期要多花工夫和成本，換到的是對 prompt 可靠度的信心。

這三條路沒有絕對的對錯，差別在賭注的大小。寫個一次性的小腳本，路線一也許夠用；但只要這個 prompt 會進到正式產品、面對真實使用者，路線一和路線二賭的就是你的產品品質。評測管線的本質，是把「我覺得應該沒問題」換成「我測過這一批案例，平均分數是多少」。

為什麼大家都掉進前兩條路

老實說，路線一和路線二是所有工程師都會掉進去的陷阱，連經驗再老的人也不例外。人很自然會低估真實使用者能踩出多少邊角案例：在你有限的測試裡看起來很穩的 prompt，一碰到五花八門的真實輸入，很快就會露出破綻。

我認為這不是能力問題，是方法問題。只要「測試」仍然停留在手動抽查幾筆，你得到的就只是印象，不是證據。改了一版 prompt 之後覺得「好像變好了」，很可能只是這次剛好抽到幾個順眼的輸出而已。

更糟的情況是：新版在你看的那幾題進步了，卻在你沒看的題型退步了，而你毫無察覺。

評測優先，買到的是四件事

• 在弱點變成正式環境事故之前，先把它找出來。
• 不同版本的 prompt 可以客觀比較，不再各說各話。
• 每次修改都有可量測的依據，迭代起來有信心。
• 整體應用的可靠度，隨著每一輪評測穩定累積。

評測優先的核心精神是：問題要在開發階段被你抓到，而不是在上線之後被使用者撞到。前期多投入的時間和測試基礎建設，會在應用的穩定性上加倍還給你，而且資料集與評分器都能重複使用，愈往後迭代成本愈低。

那分數長什麼樣子？

典型的做法是：準備一批有代表性的測試輸入，逐筆套進 prompt 跑過 Claude，再由評分器對每個輸出打 1 到 10 分，最後取平均。

來看一個實際的例子：三個問題分別拿到 10 分、4 分、9 分，平均 7.66 分，就是這一版 prompt 的成績。接著在 prompt 裡補一句指示再跑一輪，平均升到 8.7 分，你就有證據說這次修改是真的進步，而不是換了一種寫法而已。

測試輸入從哪裡來？範例為了方便理解只放三題，真實評測的資料集常常是數十、數百甚至上千筆。你可以手工整理，也可以請 Claude 幫你生成一批，重點是這批輸入要貼近正式環境會遇到的樣貌。

有了分數之後，不同版本的 prompt 就能用數字直接比較：留下分數最高的那一版，然後繼續迭代，看能不能找到更好的寫法。猜測從此退場，換上來的是證據。