前幾天開始整理 AI 系統的輸入、輸出和錯誤之後，我慢慢發現一個以前做 Demo 時很容易忽略的問題，每次修改 Prompt，我通常會立刻拿幾個熟悉的問題測試，只要答案看起來比上一版完整，就會覺得這次修改有效，然後繼續往下一個功能做。

這種測試方式在開發初期很方便，幾分鐘就能知道大概有沒有改善，但問題也很明顯，因為每一次測試的題目可能都不一樣，今天問三題、明天換另外五題，最後其實很難確定系統是真的變好了，還是剛好這次測到比較簡單的問題。

所以 Day 7 我開始做一件看起來有點麻煩，但之後應該會一直用到的東西：固定測試資料。

先留下同一批問題

我先把平常測試 AI 系統時會問的問題整理起來，不需要一開始就準備幾百筆資料，先從十幾個有代表性的案例開始，裡面刻意放不同難度，也包含一些容易出錯的情況。

這樣下一次修改 Prompt、換模型或調整 RAG 設定時，就不用再憑感覺隨便問幾題，而是重新跑同一批案例，再比較前後輸出的差異。

做完之後才發現，光是把測試問題固定下來，開發時的感覺就差很多。

以前我很容易看到一個回答變好，就覺得整個版本有進步，但現在同一批問題全部跑過一次，可能會看到其中六題真的改善了，兩題幾乎沒差，另外兩題反而變差，這時候就不能只看那個最漂亮的答案。

Prompt 的修改其實可能有副作用

這件事在 AI 系統裡特別明顯。

假設我今天為了讓回答更完整，在 Prompt 裡加入「請詳細解釋原因」，某幾題的結果可能真的變得比較清楚，可是另外一些原本只需要簡短回答的問題，開始出現一大段不必要的內容；如果再加入更多限制，模型可能變得比較穩定，卻也有可能讓某些正常輸入被限制得太死。

如果沒有固定測試案例，我通常只會注意自己正在修的那一題，修好之後就繼續往下走，其他原本正常的案例有沒有被影響，很可能到之後才發現。

這跟一般程式開發裡的 regression 有點像，修掉一個問題之後，還是得確認原本正常的功能沒有一起壞掉，只是 AI 的輸出比較難直接用「成功／失敗」兩種結果判斷，所以測試資料本身就更重要。

先不要急著追求一個分數

整理測試案例時，我原本有想過是不是要直接幫每個回答算分數，例如正確性、完整度、相關性各自給幾分，最後算一個平均值，這樣看起來會很清楚。

但目前資料還不多，我決定先把問題、預期重點、實際輸出和版本留下來。

原因很簡單，如果連「什麼叫做好的回答」都還沒有定義清楚，太早做出一個漂亮的分數，反而容易讓自己以為評估已經很完整，所以現階段先保留比較原始的測試結果，等案例累積多一點，再慢慢決定哪些指標真的值得量化。

從 Demo 開始留下可以比較的東西

做到 Day 7，我覺得 AI Engineering 有一部分其實很像是在幫開發過程留下痕跡。

Prompt 改了什麼、模型換成哪一版、RAG 的參數怎麼調、同一批問題的結果有沒有改變，這些東西如果完全沒有記錄，Demo 還是可以正常跑，但每一次調整都很像重新開始。

今天先把固定測試案例留下來之後，至少下一次有人問「這版真的有比較好嗎」，我不用只回答「我測起來感覺比較好」。

我可以把前一版和這一版放在一起，看哪些案例改善、哪些退步，再決定這次修改到底要不要留下，接下來幾天我也會繼續把這套測試方式補完整，看看一個原本靠感覺調 Prompt 的 Demo，能不能慢慢變成一個可以被反覆驗證的系統。