🎯 什麼情境該想到我
當你「調完一版 prompt／做完一個 skill，覺得好像變好了，但講不出憑據」的時候。
⚙️ 怎麼用（步驟 / 公式）
- 寫題目與 assertion（放 JSON）：每題 3–5 條，用自然語言描述「好回答該具備的性質」，不是預期輸出。
例：「至少用一個小孩聽得懂的類比（玩具、動物、遊樂場）」「平均句長低於 15 字」。 - 一定要有對照組：同一題跑兩次——A 帶你的改動、B 什麼都不帶（模型預設）。
沒有 B，你分不出「分數高」是你的功勞還是模型本來就會。這是整套的重點。 - 兩邊用同一組 assertion 送給另一個 LLM 當評審，並鎖死輸出格式：
prompt 要明講「只輸出這些行，不要任何其他文字」，才好機器統計。PASS|<編號>|<簡短證據> FAIL|<編號>|<簡短證據> - 跑不只一次，看趨勢不看單次。評審本身會飄（原作者實測同一組跑兩次 10/12 → 11/12）。
- 判準看穩定區間不看單次差距：A 穩定 80–90%、B 穩定 40–50%，那是真訊號；單次高個幾 % 很可能整個是雜訊。
🧪 我實際套用的紀錄
- 2026-08-23：（待填）
⚠️ 注意 / 什麼時候不適用
- 評審的變異就是你的雜訊底線。沒先量過「同一組跑 N 次的全距」，任何「A 比 B 高 5%」都不能當結論——先量雜訊，再看差距。
- 這套測「內容有沒有用」，不測「會不會被觸發」。腳本是把 skill 路徑塞進 prompt 叫模型先讀；真實情境是靠 description 自動觸發。觸發失敗這條路沒被測到，而那才是實際最常壞掉的地方。
- 有標準答案的任務不需要這套，用自動指標（精確比對、相似度）更便宜更穩，見 工具-AI系統評估。
- assertion 的兩個極端都會壞：寫太模糊（「語氣好」）評審會亂飄；寫太死（「必須出現 X 字」）就退化成字串比對，失去 eval 的意義。