昨天收在一個問題：你怎麼知道系統這次做得比上次好？今天進最後一層。Loop Engineering（這系列的 L4）做的事一句話講完：把你自己從迴圈裡拿出來，讓系統自己轉，而且越轉越好。

這個詞有明確的身世。2026 年 6 月，Google Chrome 的工程主管 Addy Osmani 把 Boris Cherny、Peter Steinberger 等人的實踐收攏成文（連結在文末），Steinberger 的一句話是最好的濃縮：別再自己 prompt agent，去設計會 prompt agent 的迴圈。你的角色從聊天框前的提問者，變成設計迴圈的工程師：系統自己找工作、自己執行、自己驗證、自己記住做過什麼。也先消個歧：這個 loop 跟 Day 18（Agentic Loop）的 loop 撞名但不同層，那邊管一次執行怎麼跑完，這邊管你不在場之後，系統怎麼繼續正確地跑、並且一天比一天好。

這個概念你可能已經摸過。Claude Code 的 /loop 讓 Claude 自己安排下一次執行的時機；/goal 給一個完成條件，每個 turn 結束由一個小模型檢驗條件成立了沒，沒成立就回饋原因、自己開下一輪，到達成為止。Osmani 講的自動觸發（trigger）、驗證器（verifier）、停止規則（stop rules），這兩個指令就是最小可體驗的版本，而 /goal 的文件裡有一句設計指南值得先記著：把條件寫成 Claude 的輸出能證明的東西。

放手的前提只有一個：驗證。Osmani 點名的頭號風險正是驗證不足，沒有可重複的品質判斷，放出去的迴圈會過度擬合測試、帶著錯誤的認知自主行動，而你渾然不覺。所以 L4 的第一課是評估：先能驗證，才敢讓迴路轉起來。

「看起來對」撐不過兩個月

很多 LLM 系統的第一版測試長這樣（我的也是）：把 prompt 貼進去，看輸出，覺得 OK 就繼續。沒有 assert、沒有門檻、沒有資料集。初期這樣很快，問題出在兩個月後：prompt 改了幾次、模型換了版本，輸出開始變奇怪，但你說不出奇怪在哪裡，因為從來沒有定義過什麼叫「對」。每次測試都人工跑一遍，每次「感覺沒問題」都是噪音。

那把傳統測試搬過來呢？assert output == expected 的前提是同樣輸入產生同樣輸出，LLM 直接破掉這個前提：它在可能輸出的機率分佈上取樣，temperature（取樣隨機度）大於零，兩次輸出就不會一樣。更根本的麻煩在 expected 本身：「法國首都是哪裡」有標準答案，「幫我整理這份會議記錄的重點」沒有，兩份輸出可以都合理，措辭和取捨各不相同。expected 從一個點變成一個空間，傳統測試問「輸出一樣嗎」，eval 要問「輸出夠好嗎」。

驗證的黃金標準：確定性優先

expected 變成空間之後，先別急著把所有驗證都交給模糊的評分。Osmani 給的優先序很清楚，驗證的黃金標準是確定性驗證：測試、型別檢查、編譯器，它們給出模型無法迴避的通過或失敗。Day 15（Harness Engineering）引過 Cherny 的做法：給 agent 高層次的任務、明確的出口條件、還有驗證工具，讓模型自己找路，那個「驗證工具」的本體多半就是這些確定性信號。能寫成測試的品質要求，先寫成測試，迴圈拿著這種信號自我修正，才不會在「感覺不錯」裡打轉。

問題是確定性信號蓋不滿品質空間：測試能告訴你程式跑不跑得動，回答不了摘要忠不忠實、答案有沒有基於 context。剩下的空間，才是 eval 機制的主場。

評估要看三層，因為壞掉的地方會躲

Amazon 的團隊在大規模 agentic 系統的經驗分享裡給過一個提醒：別把整個系統當黑盒評估，光看最終輸出，你不知道問題出在哪裡。他們把評估拆成三層。

底層：模型基礎能力。 這個任務上哪個模型更合適。它回答的是選型，跟你的系統好壞是兩回事。中層：元件行為。 retrieval 召回的東西相關嗎？工具選對了嗎、參數填對了嗎？多輪對話的 context 有正確保留嗎？上層：系統結果。 任務完成了嗎？使用者的需求被滿足了嗎？

中層是除錯的關鍵：最終輸出爛掉，根因可能在任何一個元件，只量上層你只知道爛了，不知道哪裡爛。這跟 Day 7（Prompt 的極限）的三問分流是同一個精神：先定位問題在哪一層，再拿對的工具。

LLM-as-Judge：讓模型當裁判，說得通嗎

「夠好嗎」最直觀的判法是讓人來看，但人工評估無法 scale：每次 prompt 改版都人工跑一輪，不現實。LLM-as-Judge 讓另一個模型來評。聽起來循環，但有它的道理：給 judge 清晰的準則（「這個回答有沒有基於提供的 context？」「這段推理前後一致嗎？」），它的一致性其實比人好，人類評估者會疲勞、受順序影響、對同一套標準的解讀會漂移，模型在固定準則下至少可重複。

它的已知 bias 也要攤開：傾向給中間分數、對 prompt 格式敏感、給自家模型的輸出評分偏寬鬆。實作上有一個提升穩定性的細節：別讓 judge 直接輸出 1 到 10 的數字，改用 logprobs（模型對每個候選 token 的機率）把各個分數加權平均，取到的值更接近機率分佈的重心，而非模型當下的偏好。一句話定位這個工具：它讓評估可以 scale，省不掉的是你自己想清楚準則是什麼。

能驗證了，下一題是量什麼

評估建起來之後，它同時在兩個位置工作：CI 裡當品質閘門（golden cases 擋 regression），執行時當迴圈的自我修正信號。今天回答的是「怎麼知道好不好」的機制，還沒回答「好，指的是什麼」。可以量的東西太多，正確率、相關性、忠實度、延遲、成本，全部都量等於什麼都沒量。明天講指標怎麼選：選對，不要選多。

參考：Loop Engineering（Addy Osmani）、/loop 排程任務與/goal（Claude Code 文件）