Day 7｜一筆 case 通過的條件誰來寫？寫完誰來驗？

判斷標準要在動手改 prompt 或寫功能之前先寫下來，寫完還得再花一次力氣驗它。沒被驗過的判斷標準可能會把對的產出判成失敗，結果就是有人回頭去修一個其實沒壞的東西。

昨天把 eval、dataset、grader、scorer、harness 五個詞擺好位置，其中一句是今天的起點，一筆 case 通不通過的條件要放在那筆 case 裡，不寫進判定的程式。條件雖然是人寫的，但人寫的東西第一遍就會對嗎？

自己寫的期望值，第一遍就對嗎？

這隻需求釐清 agent 整理完優惠碼那張 ticket 後應該長什麼樣，那份期望值是人寫的。人第一遍逐條讀 7 條 AC，數出 3 個標註，也就是第 3、4、7 條各被標出一個問題。第二遍回頭讀 ticket 的 description，才發現第 3 條「可以無限次使用」除了跟第 2 條打架，也違背 description 裡「不要被亂用」那句，同一條 AC 同時有兩種問題，標註變成 4 個。

前兩天講過，改一行 prompt 會讓這 4 個標註掉成 3 個，但這個 4 在第一遍其實只數到 3。要是第一遍就把 3 寫進檔案當標準，agent 標出 4 個反而會被判成多報，做對的那一次被判成失敗，只因為這條判斷標準沒有人驗過。

需求方那 7 條 AC 也是同一種東西，寫完就送出，沒人驗過，第 2 條「一人只能用一次」跟第 3 條擺在一起就是衝突。agent 的工作是挑它們的毛病，而人寫的判斷標準，沒有人在挑。

自己寫的判斷標準，要怎麼驗？

更麻煩的是，寫的人記得自己當時為什麼這樣寫，很難懷疑它。

手邊有一份跑完的實驗可以當證據，跟這隻需求釐清 agent 是兩回事。

那份實驗叫另一隻 agent 照一份寫作規範產出 Trello 卡片，4 個 case，規範放進輸入與不放各跑 3 次，判斷標準是一條一條寫進 metadata 的 assertion，附在各自的 case 上，其中一個 case 有 16 條。把規範放進輸入的那三次，16 條裡每次都失敗 1 條，三次都是同一條，那條寫的是 Out of Scope 欄位不該出現。

三次都是同一條失敗，該先懷疑判斷標準還是產品？

先懷疑判斷標準，理由是失敗的方式。真的不穩定會每次不一樣，這次少一句、下次換個地方錯。三次都錯在同一條，大概就不是不穩定造成的。

但三次一致只是讓不穩定的可能性變低，還剩兩種可能，判斷標準寫錯了，或者產品每次都在同一個地方出錯，某段輸入每次都讓它走同一條錯的邏輯，三次當然都錯在同一條。

分辨方法只有一個，拿那條失敗的產出對著規範看，它到底做對還是做錯。先查判斷標準是因為最省事，規範就在旁邊，翻一次就知道。

而且那三次是各自獨立跑的，第二次看不到第一次寫了什麼，所以是三個獨立的結果，不是同一個結果重複三次。

回頭翻規範，判斷標準確實寫反了。規範明寫 Out of Scope 的觸發條件之一是「輸入明確提及不做 X」，而那筆輸入明確要求某一類永久性的錯誤不要重試。產出把它寫進 Out of Scope，完全照規範做。是判斷標準把對的產出判成了錯的。

那條 assertion 是從更早一輪實驗直接沿用的，中間沒人重新看它一眼。

判斷標準改了，agent 要重跑嗎？

不用，這份實驗把 agent 每一次的產出都存成檔案，判定是另一支程式事後讀這些檔案打分，兩件事是分開的。這次改的是判斷標準，agent 的產出一個字都沒動，所以拿同一批檔案重新判一次就好，那條失敗就會變成通過。

這裡有一個副作用要留意，分數變好看了，但產品一行都沒改。所以判斷標準每一次改動都要記一筆，改了哪一條、為什麼改，不然下次看到「這次比上次好」，分不出是產品變好，還是判斷標準變鬆。

判錯的那條，最後是誰去修？

最輕的後果是浪費時間，有人回頭去修一個沒壞的東西，翻半天找不到原因。

真正的問題在下一步，修的人有可能為了讓紅字變綠 (覺得變綠燈就是修好)，把本來對的行為改掉去迎合那條錯的判斷標準。產品到這一步是真的會故障了，而且是判斷標準帶壞的，修改紀錄上還寫著「已修正」。

反過來的話，判斷標準太鬆、把錯誤的放過去，會在判斷標準壞掉那一天單獨討論。

所以動手的順序是什麼？

Anthropic 那篇談 agent eval 的文章對時間點的講法是：

Evals get harder to build the longer you wait. Early on, product requirements naturally translate into test cases. Wait too long and you're reverse-engineering success criteria from a live system.
（Demystifying evals for AI agents）

同一篇還有一句，定義 eval 的任務本身，就是在檢驗需求具體到可以開工了沒有。換成這裡的說法，如果一筆 case 寫不出這筆通過的條件，通常代表需求本身還沒講清楚，跟判斷標準難不難寫沒有關係。

需求方那 7 條 AC 裡的第 4 條「結帳流程要順」就是這樣，「順」是三步內結完、是不用跳頁、還是沒有人客訴，需求方沒說，所以沒有人寫得出這一條要怎樣才算通過。

所以順序是固定的：

• 寫 code 之前先寫「這筆通過的條件」，一條一條附在那筆 case 旁邊，寫完再對著 description 讀一遍，第一遍的 3 就是這樣變成 4 的。
• 同一條連續失敗，第一個要翻的是那條判斷標準。
• 判斷標準旁邊留一個欄位寫「這條現在驗不到」。 驗不到就寫驗不到，比假裝驗過安全。

明天要處理什麼？

規矩立完，下一個問題馬上來，判斷標準要先寫，但第一批 case 拿什麼來寫？憑空想「理想的測試案例」最慢，明天改從會讓 agent 出錯的 ticket 開始，先看這種 ticket 要去哪裡找。