前言：驗證跟判斷,可以是同一個人做嗎？

「反正都是同一個 AI 在跑，驗證跟判斷一起做，效率不是更高嗎？」

昨天講完乾淨基準比對，這是個很自然的疑問——為什麼不讓同一個對話裡的 AI，一邊跑測試、一邊順手判斷這些紅字重不重要，一次到位？答案是：能一次到位,不代表應該一次到位。把「跑出客觀結果」跟「判斷這個結果代表什麼」交給同一個當下的判斷過程，看起來省了一道手續，實際上是把兩件性質完全不同的工作黏在一起，而黏在一起的代價，往往要到出事之後才會顯現。

今日目標

• 理解「驗證」跟「判斷」是兩個性質不同的工作，混在一起會產生什麼風險
• 認識把驗證迴圈放進獨立 subagent／子流程的兩個具體理由
• 看一個「獨立視角審查另一個 agent 產出」抓到真實風險的案例
• 建立「什麼情境適合委派、什麼情境不適合」的判斷標準

驗證跟判斷,是兩種不同的工作

昨天的乾淨基準比對已經帶出一條邊界：AI 只負責產出差集報告,不負責判斷這個差集能不能忽略。今天要把這條邊界講得更完整——這不只是「差集比對」這一件事的規則，而是任何驗證迴圈都該遵守的分工方式。

驗證，是一個相對機械、可以被複製驗算的過程：跑測試、比對輸出、產生報告。判斷，是需要考量業務脈絡、風險承受度、優先順序的過程：這個失敗重不重要、能不能先擱置、要不要現在處理。這兩件事對「正確性」的要求完全不一樣——驗證只要跑對流程就有客觀答案，判斷卻沒有標準答案,要看情境。

把這兩件事放進同一個持續進行、還在被使用者追問下一步的對話裡做，會有一個隱性的風險：判斷會不知不覺地滲透進驗證過程本身。跑測試跑到一半，AI 心裡已經先有了「這應該沒事吧」的預期,接下來看報告的方式就會被這個預期帶著走——符合預期的紅字被輕輕放過，不符合預期的才仔細看。這不是 AI 故意偷懶，而是判斷跟驗證黏在一起時,幾乎必然發生的認知捷徑。

放進獨立流程的第一個理由：不讓雜訊污染判斷用的 context

驗證過程本身通常很吵。一次完整的測試套件輸出可能有上千行,還要跑兩次（帶改動、乾淨基準）才能做比對。如果這些原始輸出全部留在主線程的對話裡，接下來每一輪互動，AI 都得在一堆測試框架的樣板輸出裡，重新辨認出真正有意義的那幾行。

把驗證迴圈丟進一個獨立的 subagent 執行，讓它在自己的 context 裡把幾千行輸出處理完，最後只把「差集是空的」或「差集裡有哪幾個測試」這種精煉過的結論帶回主線程——主線程拿到的是一份乾淨的報告，不是一堆需要自己重新過濾的原始雜訊。這件事跟語言、工具鏈無關，任何需要跑大量輸出才能得出結論的驗證流程，都適用「把雜訊留在子流程、只把結論帶出來」這個設計。

放進獨立流程的第二個理由：逼自己把角色切乾淨

比效能更重要的理由，是流程本身能強制切開「驗證者」跟「判斷者」這兩個角色。當驗證迴圈被設計成一個獨立跑完才回報的流程，它天生就沒有機會在跑到一半時去揣測「這個結果大概沒事吧」——它只能老老實實把兩次測試都跑完、做完比對，然後把結果原封不動地交出去。判斷這個結果代表什麼，變成回到主線程之後、由呼叫端（人，或者上層 agent）另外要做的一件事。

用一組對照看這個差異：

❌ 驗證跟判斷黏在一起：
AI（在同一個持續對話裡）：「我跑了一下測試，
     大部分失敗看起來都是舊有的，應該沒問題,我繼續往下做。」
→ 沒有完整跑完比對流程就下了判斷，
   「看起來」代替了「真的比對過」

✅ 驗證跟判斷分開：
子流程回報：「差集比對完成。帶改動跑測試 12 個失敗，
     乾淨基準跑測試 11 個失敗，差集 1 個：XxxTest::yyy_test。」
主線程（人或上層 agent）：「這個差集裡的失敗，
     跟這次改動的目標有沒有關係？要不要先處理？」
→ 報告跟判斷是兩個獨立步驟，判斷者拿到的是完整資訊，不是結論

驗證迴圈的價值,不在於它跑得多快，而在於它逼所有人（包括 AI 自己）沒辦法跳過「完整跑過一遍」這一步,直接進到「憑印象下結論」。

一個更進一步的用法：獨立 agent 互相審查

把驗證跟判斷分開這個原則，還可以再往前延伸一步——不只是「同一個 AI 的驗證流程 vs 判斷流程」要分開，有時候連「執行任務的 agent」跟「審查這個任務產出的 agent」都值得分開。

我曾經讓一個獨立的 review agent，去審查另一批廠商接線任務的產出。這個 review agent 沒有參與原本的實作過程，帶著一個全新的、沒有被實作過程中任何假設污染的視角去看程式碼，結果抓到了一個實作過程中沒發現的真實架構風險。多 agent 協作不只是「把工作拆開分頭做」，也可以是「找一個完全獨立的視角，去審查另一個 agent 已經做完的東西」——這跟一個人自己寫完程式碼、換一個角度重新看一遍，是同一個道理，只是用獨立 agent 把這個「換角度」做得更徹底,不會被自己原本的思路帶著走。

什麼情境適合委派，什麼情境不適合

委派給獨立流程不是萬用解法，判斷標準不是「這次改動大不大」，而是**「使用者現在是不是在跟你即時來回討論、每一步都要立刻看到結果」**。如果使用者正在盯著螢幕、一句一句跟你確認下一步該怎麼做，把工作丟給獨立 subagent 反而多了一層溝通開銷——啟動子流程、等它跑完、把結果轉述回來，這些步驟本身就要花時間，比自己當場做還慢。獨立流程真正發揮價值的場合，是那種「跑起來要一段時間、過程雜訊多、不需要即時盯著」的工作,乾淨基準比對正是這種典型情境。

今日思考題

回想你上一次讓 AI 幫你跑驗證的經驗：AI 是老老實實把整個流程跑完才給你結論，還是跑到一半就開始下判斷、然後才補做剩下的驗證？如果是後者，那個「先有結論、再補驗證」的順序，其實已經讓驗證失去了原本該有的作用。

今日重點回顧

• 驗證（機械、可複製驗算）跟判斷（需要業務脈絡）是兩種不同性質的工作，黏在一起容易讓判斷滲透進驗證過程
• 放進獨立流程的第一個理由：不讓大量雜訊輸出污染主線程用來判斷的 context
• 放進獨立流程的第二個理由：強制切開「驗證者」跟「判斷者」角色，逼自己把流程跑完才下結論
• 這個原則可以更進一步延伸成「獨立 review agent 審查另一個 agent 的產出」，帶來沒被實作過程污染的全新視角
• 委派與否的判斷標準不是改動大小，是使用者現在需不需要即時來回討論

明日預告

明天要進入一個更具體的技術收斂規則：這套系統裡散落各處的裸寫 SQL，要怎麼收斂進 Repository 層——這是讓 AI 面對資料庫存取邏輯時,不用每次都重新判斷「這樣寫安不安全」的具體做法。