前兩天寫的 cyclone-hermes PR #140，故事在第三輪結束。但第三輪不是 reviewer 自己決定要繼續審的，而是觸發了一條我自己訂的規則，然後由我人工核准才開的那一輪。今天寫這個。

迴圈為什麼需要出口

review 流程最危險的時候，不是一輪就直接噴回來，而是無限收斂不下去：改了、再審、又出新 findings、再改、再發現。每一輪看起來都有進展，沒有人提出停，run 一直在燒。

我手上是 quota 這種東西有限制的人，每輪 review 的背後是真實費用。更早的經驗也不樂觀：有一次流程跑到十二輪，PR #136 的事故讓我發現有流程收不住，機器不會自己覺得「這樣細追沒效益」。

所以我在 review 契約裡訂了輪次預算。一開始是三輪，後來改成二輪：超過兩輪沒有走到 approved，流程停下來問我，由我判斷值不值得繼續，而不是讓它繼續滾下去。

停下來不等於放棄

「停下來問人」聽起來像是逃跑，但我把它做成了一個有規範的動作：超過輪次的時候，agent 必須把現在還剩什麼問題列清楚，我不批准就停著，我批准那就變成「加開輪」，有明確範圍。

PR #140 就是這樣走到第三輪的。第一輪四條 findings，全部修完。第二輪三條新的 findings，也處理掉了，但那時已經用掉兩輪的預算，契約此刻介入。我核准的加開不是一輪普通的 review，而是指定範圍的第二型：只審第二輪修正 commit 之後的改變，不再互動式重讀整個 PR。

好處有兩個。一是省錢：第三輪不用再做整個 PR 的大檢查。二是聚焦：reviewer 不再重讀完整份程式，只對焦最後那一次修正的 patch，而那裡才是這幾天唯一新增過風險的地方。

那一輪的結論是 approved，三項修正全部確認正確，沒有新問題。依契約 merge。

收斂判準的每一階段

整套流程裡的「什麼時候叫做審完了」，我現在拆成四個不同的事件：

第一，approved。reviewer 沒有再遇到會影響正確性或安全的問題，依契約可以出貨。

第二，nits-only。剩下的全部是措辭、排版、命名這類小地方。契約上明文允許自動合併，意見留成留言，等其他機會再清。

第三，輪次耗盡。超過兩輪還有實質 findings，停下來問人，由人決定加開 delta review 或走人工放行。第四，硬停。碰到紅線──secrets、個資、force push──整個流程當場停，不討論、不升級。

前兩天經歷的 PR #140 是第三型走過去的一個例子：兩輪之後，我核准，加開一輪 delta，收斂至 approved。不是所有的 stop 都要走到第三那麼隆重，但它為每個具體狀態準備一個明確對應的動作，流程不會一遇到意外就懸在那裡等臨場判斷。

為什麼要寫得那麼繁瑣

回頭看真正的收斂判準是什麼。不是「reviewer 覺得差不多了」，不是「看起來沒問題了」，是 verdict 落在哪一個事先寫好的格子裡。

格子裡的每一個狀態，附帶清楚的下一次動作和擁有決定權的人。機器不用每一輪都重新判斷一次人生，我都那樣也不行。流程光是走到哪裡、只剩什麼問題、由誰決定，三件事寫清楚，就足以讓「審查什麼時候算完」變成一個普通問題，不再需要印象分數。

明天

到今天為止，「讓 AI 審 AI」這個單元收尾了。下個星期開始的 Unit 3，要面對一個問題：這麼多 agent 同時在做事，怎麼知道它們真的在做事？