AI 互審停不下來？先訂停止條件，再加下一個 Agent

不是沒人審，而是一直審不完

你請 AI 修一個錯誤，它改完了；再請另一個 AI 檢查，得到幾項建議。修完重送，又冒出幾項新的建議。你看著提交紀錄越疊越高，卻越來越難回答：現在究竟還有什麼會讓使用者出錯？

這不是「多找一位審查者」就一定能解決的問題。假如每一輪都把命名偏好、既有問題和本次缺陷混在一起，審查就會不斷擴張，原本很小的修正也可能變成一場沒有終點的整理工程。

Claude Code 團隊在 2026 年 10 月 15 日的工程文章提到一個內部 PR 曾經整夜互審、修正超過五十輪。團隊後來加入輪數上限、增量複審和不重貼既有 finding 等收斂做法。這是該團隊公開的實務經驗，不是所有專案都應照抄的標準，更不是三輪後可以帶著已知缺陷上線的許可。

下面的五欄表、搜尋情境與判斷方式，是本文整理的教學方法；沒有宣稱經過實測，也不把其他團隊的結果當成自己的成效。

先讓每個意見回答一個具體問題

收到審查意見時，先別急著讓 AI 全部照改。要求每項意見說清楚「什麼輸入、什麼狀態、什麼操作會造成什麼錯誤」，才有機會分辨它是缺陷、改進方向，還是單純偏好。

這不是說寫不出測試的問題就不存在。權限設計、資料外洩、付款和架構決策，有時需要人工分析或實際環境證據。表格的用途是把未知攤開，不是用格式把風險刷掉。

教學例：搜尋框，怎麼從修錯變成大翻修

以下是虛構情境，並非客戶案例或工具實測。

原本的需求只有一項：搜尋框送出空白時，不要顯示整份資料。第一輪 AI 發現空白字元沒有被處理；第二位審查者則認為搜尋服務應該重新分層。兩件事看起來都和搜尋有關，卻不是同一種待辦。

對第一項，可以建立具體檢查：一般文字仍能查詢、空字串和純空白不列出資料、沒有符合結果時狀態正確。對第二項，先問現有結構到底造成哪個可觀察錯誤；如果只是未來擴充想像，就另立議題，不必把它塞進本次修錯。

但假如審查者接著指出：未登入的人也能用搜尋 API 讀取私人資料，這就不是「不在原本題目裡，所以不管」。應立即停止受影響的發布，交由負責人確認範圍與修正方式。避免擴張，不等於忽略高風險證據。

複審要知道上一輪已經決定了什麼

把同一整包程式重新交給一個沒有歷史的審查者，它可能再次提出已回覆過的意見。更好的交件內容包括：這次相對上一版改了什麼、對應哪個問題、用了哪個驗證、哪些地方沒有動，以及已接受或不採納的理由。

增量複審不等於只讀幾行 diff。修正可能改到呼叫端、資料格式或錯誤處理；審查者仍需要讀足夠的周邊脈絡。只是範圍應由改動的影響推導，而不是每一輪都順便找一套新的整潔標準。

同樣地，檢查結果要綁定具體版本。舊版測試通過，不能替後來新加的修改背書；只跑本機測試，也不能宣稱正式環境已經正常。版本、環境與證據要對得起來，才知道目前的「通過」到底指哪一件事。

停止條件，是停止無限互改，不是停止負責

開始前先和負責人約定：到哪一輪需要停下來重新判斷做法、哪些未解問題一定擋發布、哪些建議可以附理由延後。輪數是一個重新決策的訊號，不是品質保證。

本文建議每輪結束問三句：原本的錯誤是否已有相符證據？還有哪個未解問題會影響這次交付？新增修改是否值得承擔新的驗證成本？答不出來，就先釐清，不用再開一輪互審來掩蓋不確定。

對低風險文字調整，過度審查可能只是浪費時間；對登入、付款、刪資料和部署流程，則不能因為輪數到了就降低要求。該補的驗證與必要人工批准仍要完成。這套方法也不取代專案原有的安全、法規、授權或發布規則。

交件時，留下能接手的結論

最有用的結案摘要不是「已經找很多 AI 看過」，而是這次解決了什麼、如何確認、還有哪些限制，以及出問題時由誰處理。沒有新缺陷時可以明確寫沒有，不必為了顯得有工作量，硬補幾項不影響結果的修改。

下一次遇到審查卡住，可以先拿五欄表回頭整理最後一輪的意見。你可能會發現，卡住的不是少一個 Agent，而是大家一直沒有同意：什麼叫做修好了。

作者：奧微軟體 AugurSoft。本文為一般工程知識整理與原創教學情境，非特定產品的品質、安全或成本保證；不涉及個案法律判定。查核日期：2026-10-20。第一方參考為上文連結的 Claude Code 團隊工程文章；引用的內部經驗不代表獨立成效驗證。