今天本來要修一個我以為存在的問題。

導師每輪會判斷學生顯露了哪些錯誤觀念，寫進 Firestore 黑板，
第 3 期的出題 agent 再拿黑板上次數最多的觀念去挑下一題。
整條閉環的準確度，全押在那個判斷上。

而我的認知是：那個判斷從第 1 期到今天，都是模型讀著程式碼猜的。
即使從 Day 21 開始，旁邊就擺著一份真的跑過的結果。

結論先講：這個前提是錯的，而我是花了八次 API 額度才知道的。

做了什麼

兩處，都在 agents/tutor.py：

1. system prompt 那條規則原本寫死「判斷依據是【學生目前的程式碼】本身」，
   改成「與【評測結果】」
2. 加一條 EVIDENCE_RULE，只在真的執行過而且有失敗時放進 user prompt，
   教模型怎麼讀執行症狀

第 2 條裡我還做了一個自認漂亮的決定：不給完整對照表。

最誘人的做法是九個代碼全部配上典型症狀（逾時→loop、只印一筆→io-eof⋯）。
但 CPE 一星題最常見的逾時長這樣：

while True:
    n = int(input())

沒處理 EOF，輸入讀完了還在讀。症狀是逾時，觀念是 io-eof，
跟迴圈一點關係也沒有。照表操課會把這種最典型的錯誤系統性地記錯。

所以只列例外名稱直接指向觀念的那三條（EOFError→io-eof、
IndentationError→indentation、int() 的 ValueError→io-parse），
其餘給原則：症狀不是觀念，指不出程式碼裡的成因就不要記。

測試 314 → 323 支，全綠。寫完我還挺滿意的。

去量了

單元測試全綠只證明「那些字串有進 prompt」，不證明它有用。
所以接了真模型，把同一個情境跑改動前／改動後兩次。

四個情境，改動前後一模一樣。

第二列是最打臉的：那正是我整條設計的賣點——「照表操課會把逾時記成 loop」。
結果沒有表的時候，模型自己就答對了 io-eof。
我防的是一個不存在的錯誤。

為什麼前提是錯的

看第四列。我刻意拿掉 explanation，只留執行器吐出的原文：

ValueError: invalid literal for int() with base 10: '1 10'

模型照樣對到 io-parse。

所以真相是：Day 22 加的 explanation 早就讓導師在讀證據了，
而且就算沒有 explanation，traceback 原文本身對模型也夠清楚。
我以為缺的那條資料管線，兩天前就已經接好了，只是沒有人（包括我）
明講過它現在也是判斷觀念的依據。

我讀了程式碼、確認了資料有沒有到，卻沒確認行為有沒有變。
資料流的完整不等於行為的缺陷。

把它拿掉

留下第 1 條（那行「依據是程式碼與評測結果」——它只是把實際已經在發生的事寫進合約，
幾乎不花 token），刪掉 EVIDENCE_RULE 與它的六支測試。

刪掉的理由不是它錯，是它沒有掙到自己的位置。
每一句進 prompt 的話都是成本：佔 token、多一個要維護的東西、
多一個以後有人改壞了也沒人發現的角落。沒量到好處的東西不該留著佔位子。

留著也有說法——「換模型時可能有用」「測試能擋住日後有人拿掉證據」。
但這兩個理由的共通點是：它們講的都是想像中的未來，不是量得到的現在。
真到了那天再加，成本是今天的十分之一。

今天學到的

1. 加功能之前要確認的不是「資料有沒有到」，是「行為有沒有錯」。
   我看到 prompt 裡有 summary 就以為自己找到了缺口，其實缺口在我的認知裡。
2. 單元測試綠燈只證明字串進了 prompt。 prompt 的效果只能對著真模型量，
   而且要有對照組——沒有 before，after 是綠是紅都說明不了事。
3. 量出沒效果，就該拿掉。 這比「反正不會壞，留著吧」難，
   因為要承認自己剛寫的東西沒有價值。但 prompt 是會互相稀釋的，
   每多一段沒用的規則，真正重要的那幾條就淡一分。
4. 最漂亮的那個設計決定，有時候是在解一個不存在的問題。
   我為「不給完整對照表」想了很久，理由到現在我仍然認為是對的——
   只是這個問題模型自己就處理好了。

今天的淨產出是：一行 prompt、三支測試、以及一個被證偽的假設。
第三個最貴，也最值得寫下來。

測試 314 → 317 支，全綠。