第 3 步：做檢分離，配一個 Reviewer

循環裡很重要的一條：寫活的 agent 不許給自己的活判分。

為什麼不能自己給自己打分

模型給自己評分時經常太寬。你叫同一個 agent 寫程式碼、然後問「這樣對嗎？」——它大概會說「對，沒問題。」不是它在騙你，是它真的看不出自己的盲點。

這個問題在手動 prompt 時還好，你本人可以把關。但在自動循環裡，你不在現場，誰把關？

做檢分離原則

答案是：配一個單獨的、只讀的、常用更便宜模型的 reviewer，它跑測試、對照規範，只回 PASS 或 FAIL。

這就是「做檢分離」原則：

• 做事的 agent：負責讀程式碼、改程式碼、跑命令
• 檢查的 agent：負責跑測試、對照規範、判斷通過或失敗
• 兩個 agent 不能是同一個

Reviewer 怎麼設計

一個好的 reviewer 有三個特徵：

1. 只讀不寫 Reviewer 不修改程式碼，只判斷。讀程式碼、讀 diff、跑測試、看輸出——然後說 PASS 或 FAIL，附上理由。

2. 標準明確 Reviewer 要對照的規範必須寫清楚，否則它還是在猜你的意思。例如：

• 單元測試全過
• 程式碼沒有 TODO 未解決
• 輸出格式符合範本

3. 用便宜點的模型 Reviewer 的工作是「執行檢查清單」，不需要最強的推理能力。用輕量一點的模型，省 token，讓循環跑得起來。

GAN 類比：調教懷疑者，而非修正謙虛的作者

Anthropic 工程師 Prithvi Rajasekaran 在實務中發現：讓一個獨立的懷疑者變得挑剔，遠比讓生成者對自己更嚴格來得容易。

這跟 GAN（生成對抗網路）的邏輯一樣——一個網路負責生成，另一個負責挑錯。你不需要讓寫程式碼的 agent 學會自我批評（它做不到），你只需要換一個帶著完全不同指令的 agent 進來，從頭開始看，不帶任何「我為什麼這樣寫」的自我說服。

Evaluator 的預設立場應該是懷疑，不是信任。 一個常見的校準做法：告訴 evaluator「假設這段程式碼是壞的，除非你能證明它是好的」——預設有罪，而非預設無罪。

更進一步：evaluator 不該只「看」，它該動手驗證。不是讀 JSX 說「看起來沒問題」，而是透過 Playwright MCP 打開頁面、點按鈕、截圖、檢查 DOM。判斷的依據從「看起來對」變成「我點了這個按鈕，頁面跳到了這裡」。

子 Agent 費 Token，用在值得的地方

子 agent 更費 token，每個都跑自己的模型和工具。把它花在值得第二意見的地方，比如任何會在你不盯著時提交東西的循環；只讀的小雜活就別配了。

判斷要不要配 reviewer 的問題只有一個：

這個循環會在我不盯著的時候自動提交、發出、修改什麼重要的東西嗎？

是 → 配 reviewer。 否 → 不需要。

AI 協作：學了這個，跟 AI 怎麼配合？

做檢分離的邏輯在人類協作裡早就存在——寫程式碼的人和 review 程式碼的人不是同一個人。AI 循環也該這樣設計。你的工作是決定哪些自動化動作需要獨立驗收，以及驗收標準是什麼。

你的人類優勢：

• 定義「什麼算通過」——驗收標準只有你知道業務現實
• 決定失敗時的後備方案——機器失敗幾次後要通知誰、怎麼通知

可以這樣跟 AI 說：

我想在自動化循環裡加一個 reviewer agent。這個循環的 worker 會自動幫我回覆客服工單草稿。幫我設計 reviewer 的驗收清單：reviewer 要檢查哪些項目才算 PASS？背景是電商平台，工單類型主要是退換貨和出貨查詢。