糾正紀錄應該變成可驗證的工作規則
上週整理一個 multi-agent system 的 worklog 時，我發現最有價值的內容，常常藏在人類留下的幾句糾正，不在完整 prompt 裡：
「你有查資料嗎？」
「can you also check the logs？」
「still wrong。」
最近看到 Eugene Yan 寫的一篇文章，提到可以從約 2,500 個過往 user turns 搜尋這類修正語句。它把「agent 不夠好」轉成可分析的資料。真正重要的下一步，是不要把每次糾正直接塞回 prompt。那很像實驗室裡每看到一個 outlier，就在假設後面加一條例外，最後沒有人知道哪條規則有效。
先把糾正分類
我會把修正紀錄分成三類。第一類是知識缺口，例如 agent 不知道 repo 裡的最新 API 文件。第二類是流程缺口，例如完成修改後沒有跑 test。第三類是判斷缺口，例如測試全綠卻漏掉權限邊界，這需要新增反例或 review gate。三類問題混在一起，prompt 會越長，失敗率卻不一定下降。
我會用這種格式維護規則：
trigger: agent 回報完成
check: 讀取 diff，執行 test，檢查 log error
pass: 3 個檢查都完成，且結果被記錄
fail: 任一檢查缺失，回到修正流程
owner: repo/worklog.md
每條規則都要有 trigger、check、pass，還要有唯一 owner。「請仔細一點」無法驗證，不該算工作規則。
用數字判斷它有沒有用
可以每週抽樣 50 次 agent task，記錄修正率、首次通過率、重複犯錯率。假設第一週有 18 次需要人類糾正，其中 7 次都是「沒有檢查 log」。新增 log verification 後，連續兩週各抽 50 次，若這個錯誤降到 2 次以下，才算規則有證據支持。若修正率從 36% 降到 20%，但時間增加 80%，也要檢查驗證成本。
相同錯誤在 14 天內出現兩次，就表示規則沒有落在 agent 真正會經過的流程上。這時應移到 worklog 的權威位置。
設定也會互相衝突。system prompt 說要簡潔，repo guideline 卻要求列出完整證據，agent 當然會搖擺。我會每月做一次 configuration refactor，搜尋重複和矛盾要求，每個偏好只保留一個 canonical source，其餘位置只放連結。
簡單來說，好的 agent 設定像可測試的研究 protocol，不像永遠加長的說明書。人類的糾正是昂貴的 supervision，至少應留下觸發條件、驗證方法和失敗案例。博士念到第十年，我還在學怎麼把「你又漏了」改寫成下一次真的能避免的規則。
作者：十年大博士