到昨天為止，這個系列前面把工作單寫清楚了，切片也切好了。下一步要是 review，問題就在這裡：我是一個人。

我可以在 GitHub 上把 PR 打開自己讀。但這樣做有兩個我親身遇過的問題。第一，程式不是我寫的那一半還好，agent 寫的那一半我常常只能看懂形狀、看不懂意思，看到「程式碼很工整」就點 approve，跟沒看一樣。第二，就算我真的看懂了，全天下審查它的人是我、寫它的人是 agent、批准出貨的也是我，三個身分疊在同一雙眼睛上，看不出來的東西就永遠看不到了。

所以我決定不要自己做，至少不要第一個做。

讓別隻 AI 當第一個 reviewer

我的規則現在是：一個 agent 寫完的 PR，指派給指定的另一隻 agent 審。審的過程不是私訊聊天，而是留在 PR 留言裡，任何人打開都能看：審到了哪個 commit、有哪些 findings、結論是什麼。

我把這套流程的第一版寫成 cyclone-agent-config issue #66。這是它當時的需求段落：

一人＋多 coding agent（Claude Code／Codex／Cursor）時，過死的「先問再 push／wiki 也要開 issue」會讓自動化卡住。需要在 cyclone-agent-config 落地無人值守出貨預設。

我不想讓人誤會這是一套懶人外掛。裡面真正的重點是幾個限制：

• Coder 和 Reviewer 必須是不同的 agent，不允許自己寫的 PR 自己批。
• 判斷不是靠 reviewer 的感受，而是固定的幾種 verdict：approved 才可以合併；nits-only 表示只剩不影響正確性和安全的小地方，可以合併但意見留著；changes-requested 就是回去改。
• 有輪次上限，不是審到天荒地老，也不是一來一回爆個不停。
• 全部弄好──review 過關、CI 綠燈、自動驗證也過──才合併。斷掉任何一關就問人，不是放水。

審的過程長什麼樣

review 後每一輪會在 PR 底下留兩則留言。一則是 reviewer 自己的報告：它看了哪個 commit、根據什麼腳本、用了什麼模型，逐條列出它發現的問題，最後一行是 verdict。另一則是我的處理：把每條 finding 修掉，附上新的 commit，等待下一輪。

一個後來反覆出現的細節是：reviewer 留言時，沒有辦法做修改。它只能讀、只能提案，動手的是 Coder 這邊。這個限制看起來麻煩，其實是設計出來的：如果審的人可以直接改程式，它會偷偷把自己的意見改完、自己批自己，那整個流程就只是表演。

所以我要的不只是一個厲害的 AI 陪審團，而是一雙不寫這支程式的眼睛，加上一套讓它的審查留下可驗證痕跡的機器。

我的角色變成什麼

我還是看。現在流程裡我的位置是第三雙眼：第一雙是 Coder agent 寫的時候自己檢查，第二雙是 reviewer agent 寫下 findings，我到第三位，看的東西也變了──從看程式碼，變成看「那雙眼睛看到了什麼，以及它說的對不對」。

用一個九歲小孩也聽得懂的方式說：以前我像一個老師批改自己出的功課，現在功課先給另一位老師批，我看的是批註，再判斷批得對不對。兩位老師誰都沒有一票否決誰，最後的裁決權在我，只是我不再站在第一現場。

這不是權下放給 AI，也不是信任祈禱。這是用固定套數，把原本被塞在一雙眼睛裡的「開發」「檢驗」「裁決」拆給不同的存在。

明天

明天專門寫整個系統裡最容易被繞過、也最不能放寬的一條規則：Coder 不能當 Reviewer。