昨天寫到我把 review 的工作交給另一隻 AI。今天要打開這套規則裡最硬的一條：寫程式的和審程式的，必須是兩隻不同的 agent。

這條規則的來源不是抽象的品格要求，而是很實際的計算。負責寫的 agent 在做決定的當下已經有立場了：它選過這個做法、讀過這些檔案、跟自己的修改相處過一整天。叫它審自己的 PR，它會用同一套思路再走一遍──當初沒看出來的洞，第二次還是看不見，因為看的時候用的就是寫的時候的腦。

機制上我也擋了。merge 前的自動驗證會檢查每個 PR 的審查紀錄，如果簽署 approved 的那一方和寫程式的一方是同一個身分，這個 PR 直接被擋下來，不是警告，是不放行。

其實可以很輕鬆地作弊

寫這條規則的時候，我想過幾種作弊的樣子。

最順手的一種：讓 Coder 再叫一次同一隻 agent，只要換個 prompt 說「現在你是 reviewer」。名字換了，換湯不換藥，還是在同一雙眼睛裡走同一條路。

第二種更誘人：review 卡住了，找一隻有權限的 agent 幫忙「代簽」。用別的 agent 的 key 把自己寫的東西蓋章送出去。因為過程全自動，一個人操作，沒有人會經手，這種事發生了也沒有人會發現。

所以我在硬停清單裡寫死兩句話：Coder 不能自審自批後自動 merge；不能在審查工具外借別的憑證代簽。違反兩句話中的任何一句，整個流程停下來問人。又臭又長的規則可以有三十條，這兩條是絕對紅線。

曾經真的卡死在那裡

這條規則有一次真的把一個已經完工的 PR 卡住了，我在 cyclone-agent-config PR #132 的描述裡如實記下了過程。

事情的前後是這樣：另一個 PR 的開發已經完全結束，review 也打過了 nits-only，萬事俱備只差簽章。但那個 PR 的 Coder 是 Codex，而當時的規則只建好了 Codex 這一邊的簽章路徑。Codex 寫的東西依法必須由 Claude Code 審，可 Claude Code 當時沒有任何合法的簽章方式。

照規則走，就永遠卡住。繞開規則合併，就得自審或者代簽，兩條都在硬停清單上。

我當時報告這個狀況的原話是：

Cyclone-Dashboard#209 現在就卡在這裡：Cyclone 核准的加開 Round 4 已完成，verdict nits-only、綁 exact HEAD、CI 綠、tree clean、mergeable，但 artifact 沒有 SSH signature，gate 機械性 FAIL。

注意這件事有多不合理：程式其實是好的，review 事實上已經結束，機器卻不讓過。我特別寫出來，是因為我認為這正是規則存在的證明。規則存在的意義，就是它必須在人想找捷徑的時候擋住人。如果它可以因為「這次其實沒問題」就彎一下腰，它對以後每一個真心有問題的 PR 也就失去效力。

解法不是繞道，是補路：我做了一支專門給 Claude Code 走的正規審查腳本、一組簽章金鑰和一批測試，把審查的第二條腿從根上補起來，讓 Codex 寫的東西從此有一條合法的審查路可走。

寧可卡住，不要化妝

寫了幾個月的實際經驗是這樣的：這條規則真正防的不是 agent 敢大辣辣地自審，而是流程為了「快一點」自動鬆掉的壓力。每一次等待急事、每一次 CI 快過了只剩簽章、每一次「只是這一次」都想把審查步驟漏過去。

我寧願每個月有一兩次像 #132 那樣自動被卡住、多花一點時間補門，也不要任何一次「啊就讓它過啊反正你都有看」。

明天

下一個問題更進一層：就算 review 留言真的存在 PR 上，怎麼知道留言是真的那隻 agent 留的？