TDD 管代碼，誰管 Agent？評測驅動開發：分級門禁 + 基線對比，改壞立刻攔

大型語言模型（LLM）的輸出先天帶有非確定性，這使得開發者在調整提示詞（Prompt）時，經常陷入「以為變好，實則在某些場景下變差」的困境。缺乏系統性的評測把關，團隊往往只會注意到 Prompt 改動後表現提升的部分，卻忽略那些被悄悄破壞的邊際案例。這種「只看到進步、看不見退步」的認知偏誤，正是 AI Agent 開發最危險的陷阱，輕則導致應用行為失靈，重則讓產品在不知不覺中偏離預期設計。傳統軟體開發領域早有成熟的測試驅動開發（TDD）來鎖定程式碼行為，每次修改程式碼時，只要跑一遍單元測試，就能確保既有功能沒有被意外破壞。

然而，AI Agent 的行為由 Prompt 與 LLM 共同決定，單元測試難以簡單覆蓋 LLM 輸出的無限可能性。開發者可能只因為一個 Prompt 的微調，就讓代理在特定情境下產生完全不同的回應，而且這種改變往往是隱性的——除非有人刻意檢查所有已知場景，否則根本不會發現某個邊角案例已經失效。為了解決這個痛點，業界開始推動一種全新的開發方法論：「評測驅動開發」（Evaluation-Driven Development，EDD）。這套做法的核心概念，是為每一次 Prompt 修改建立量化評估機制，讓開發者不再只憑感覺或局部觀察來判斷改動的好壞。

具體來說，評測驅動開發包含兩大關鍵機制：分級門禁（Graded Gating）與基線對比（Baseline Comparison）。所謂分級門禁，是指系統會針對不同的 Prompt 變更，設定多重等級的評測關卡。例如最低層級可能只檢查基本格式與關鍵詞回應，中層級則驗證多輪對話的邏輯一致性，高層級甚至需要通過數百個精心設計的測試案例，涵蓋正常情況、邊際情境與惡意輸入。每一道門禁都像是一道關卡，只有通過所有必要檢驗的改動，才能被允許進入下一階段，最終部署到正式環境。而基線對比則解決了「改動後看不出退步」的問題。

每當開發者更換 Prompt，系統會自動在預設的評測集上執行全場景測試，並將結果與上一版基線進行比對。假如發現某個評測項目的分數出現顯著衰退——比如對話成功率從 95% 掉到 82%，或者特定類型的問題回答開始產生幻覺——改動就會被立即攔阻。這種做法等同於為 Agent 行為上了一道「改壞立刻攔」的防線，把 LLM 的非確定性風險控制在可視範圍內。這樣的機制之所以有效，在於它把原本模糊的「感覺」轉化成可追蹤、可比較的數據。過去開發者只能憑少數範例對照前後結果，但 LLM 的輸出隨機性高，偶爾一次表現好不代表整體有進步。

透過基線對比，團隊可以清楚看到改動前後的統計差異，甚至能細分到每個測試案例的得分變化。一旦發現退化，系統還能自動標註出哪些場景被影響，讓開發者迅速定位問題根源，不必大海撈針。此外，分級門禁的設計也避免了一次性要求所有改動都通過最高標準的負擔。開發者在初期小規模測試時，可以只通過低門檻的檢查，快速迭代；等到功能趨於穩定，再逐步提高門禁等級，確保最終品質。這種分層把關的方式，既保留了 LLM 應用的靈活迭代特性，又不會讓退步悄悄溜進正式環境。目前已有不少 AI Agent 開發團隊開始導入評測驅動開發，並將其整合進 CI/CD 流程中。

每當開發者提交 Prompt 修改，自動化管線就會觸發完整的評測任務，並生成一份對比報告，清楚呈現前後版本的效能差異。如果報告顯示多個關鍵指標下滑，該提交就會被自動拒絕，並通知團隊進行檢討。這樣一來，開發者可以放心大膽地實驗各種 Prompt 寫法，不必擔心無意中破壞了哪些看不見的角落。值得注意的是，評測驅動開發並非要取代傳統的單元測試或整合測試，而是與之互補。對於 AI Agent 這類仰賴自然語言生成的行為系統，傳統測試只能驗證程式碼邏輯是否正確，卻無法判斷對話品質、安全性、一致性等高階指標。而評測驅動開發正好補上了這一塊空白，讓團隊有能力系統性地管理 LLM 所帶來的不確定性。

總結來說，隨著 AI Agent 從實驗性專案走向生產級應用，如何確保每一次 Prompt 修改都不會犧牲既有品質，已經成為開發者必須正視的挑戰。評測驅動開發透過分級門禁與基線對比，提供了一個務實且可落地的解決方案，讓團隊能即時攔截退步，同時持續優化模型行為。這套方法不僅降低了 LLM 非確定性帶來的風險，更幫助開發者跳脫「只看進步、看不見退步」的盲點，真正讓 AI Agent 的演化過程變得透明、可控且值得信賴。