AI reviewer 也需要被審查
想像一個很普通的 pull request。
Coding agent 改了幾個元件、補了測試，也順手修改 repo 裡的 REVIEW.md。接著 AI reviewer 讀完這個 branch，留下六則看起來很完整的意見：型別沒有問題、錯誤處理可以再補、某段查詢可能拖慢頁面。
這時候最容易出現的誤會，是把「AI 已經 review 過」聽成「這個 PR 比較接近可以合併」。
但它剛才讀到的 review 規則，也在同一個 PR 裡被改過。CI 跑了什麼、branch protection 擋了什麼、誰有權批准，仍然是另外幾個問題。那六則留言可以很有用，卻沒有回答最重要的那一句：現在到底能不能合併？
這個場景沒有理由讓大家停用 AI code review。當 AI reviewer 開始有自己的 instructions、setup、網路限制和 runner，我們反而能用比較務實的方式看待它：一個會執行、會讀設定，也會受到環境影響的 runtime。
既然是 runtime，就該像 runtime 一樣被管理。
Review 規則已經是程式資產
GitHub 最近調整 Copilot code review，讓它從 PR 的 head branch 讀取 copilot-instructions...、AGENTS.md、REVIEW.md 等檔案。這個設計有很實際的好處：團隊不用先把一條未驗證的 review 規則合併進預設分支，才能知道 reviewer 會怎麼反應。規則可以跟著功能分支一起修改、測試，再經過 review。
問題不在於「head branch 不可信」，而是我們不能再把 reviewer instructions 當成藏在角落的提示詞。
只要一份文字會改變自動 review 的判斷，它就是 PR 行為的一部分。檔名可以是 Markdown，影響卻接近 lint 設定或 CI workflow。它應該出現在 diff 裡，也應該有清楚的 owner。若任何能推 code 的人都能悄悄放寬 reviewer 規則，最後那則「沒有發現重大問題」的留言，證據力自然會變弱。
我會先做一個很小的改動：替 reviewer instructions 所在路徑設定 code owner，讓規則變更至少經過另一雙眼睛。每次修改未必都很危險，重點是它已經會影響驗收結果，不該再被視為普通文件整理。
這種管理方式也比較不會掉進 prompt 恐慌。團隊不需要假裝每一行指令都是安全漏洞，只要承認它是可變更的 policy，讓變更留下 diff、review 和責任歸屬。
Reviewer 已經有自己的執行環境
另一個容易被忽略的變化，是 AI reviewer 現在有 review 專用的 setup workflow，也有預設 firewall 和獨立 runner 設定。
這些東西聽起來很像平台功能清單，其實透露了一個更直接的事實：reviewer 需要 dependencies，可能會執行命令，也可能需要存取外部資源。它有自己的 execution surface。
因此，coding agent 能用哪些權限，不應自動變成 reviewer 也能用哪些權限。兩者處理的是不同工作。Coding agent 可能需要安裝套件、啟動服務、修改檔案；reviewer 的任務通常窄得多。若只是為了檢查型別與測試結果，就不必順手拿到部署憑證或寬鬆的網路存取。
小團隊很常共用一套 runner，因為省事。這沒有錯，但至少要把共用變成一個清楚的決定，而不是沿用預設值之後就忘了。Reviewer 安裝了什麼、能連去哪裡、會讀到哪些 secret、失敗時留下什麼紀錄，都應該能被回答。
如果回答不了，AI 留言寫得再完整，我也只會把它當成一個待查的線索。
一則 AI comment 能證明什麼
Code review 本來就不是單一關卡。AI 加進來之後，這件事反而更需要說清楚。
AI reviewer 擅長找可疑的程式路徑、指出可能漏掉的 edge case，也能把 repo 裡寫明的慣例套到新的 diff。它提供的是 review evidence：這裡可能有問題，這段值得人再看一次，這項規則似乎沒有遵守。
Deterministic CI 回答的是另一類問題。測試有沒有通過、型別是否成立、格式是否符合、已知弱點掃描有沒有命中，這些結果應該可以重跑，而不是取決於模型這次怎麼解讀。
Branch protection 和人工批准處理的又是權責。哪些 checks 不得略過，誰可以接受風險，誰要為合併負責，不會因為 AI reviewer 留下一個勾就自動消失。
把這些證據疊在一起，AI review 很有價值。把其中任何一層拿來替代其他層，工作流就會開始說謊。
真正讓我不安的，往往是團隊在趕時間時說：「反正 AI 看過了。」這句話把「多了一份線索」偷換成「少做一個必要檢查」。久了之後，reviewer 沒有增加多少信心，只在介面上多留一個讓人放心的圖示。
PR 變多以後，注意力不會跟著擴充
AI coding agent 最容易被量化的成果，是它建立了多少 PR、寫了多少程式碼、完成多少任務。這些數字很好看，也很容易讓團隊誤判瓶頸。
GitHub 新增 repo 層級的 Copilot activity 指標，可以看到 coding agent 建立與合併的 PR，以及 Copilot code review 的活動。這比單看買了多少席次更接近真實工作，但 created、reviewed、merged 仍然只是在描述流量。
真正卡住交付的，常常是 PR 出現之後的那段時間。
第一次 review 等了多久？合併前來回幾輪？哪些 PR 開了三天還沒有人看？哪些最後被放棄，所以根本不會出現在只計算 merged PR 的報表裡？這些問題比較接近 review debt。
我喜歡「debt」這個說法，因為它不是單純的 backlog 數量。一個 PR 放得越久，原作者越容易忘記上下文，目標 branch 也可能繼續變動。Reviewer 接手時要重新載入更多背景，於是每一次延遲都可能讓下一次 review 更貴。
平行 agent 可以把一天的執行時間往上堆，人的注意力卻沒有同樣的橫向擴充方式。你可以同時啟動五個 coding agent，但很難同時仔細理解五包跨檔案 diff。產出速度一旦超過驗收速度，更多自動化只會更快地製造等待。
所以我不太在意一個團隊本週「用了多少 AI」。我更想知道，agent 建立的 PR 有多少真的合併、首次 review 要等多久，以及 queue 裡最老的那幾筆為什麼還沒動。
小團隊可以先改的四個地方
這不需要先建立一套龐大的 AI governance 制度。對只有幾位工程師的團隊，我會從四個地方開始。
第一，讓 review instructions 有 owner。規則變更要出現在 PR diff 裡，而且不能只由同一位作者自己放行。
第二，替 reviewer 保留一個窄的 setup。只安裝 review 確實需要的 dependencies，網路與 secret 也採同樣原則。若使用 self-hosted runner，別假設平台的預設 firewall 仍然替你兜底。
第三，把不可替代的 checks 留在 branch protection。單元測試、型別檢查、安全掃描或部署前驗證，該是 required check 的就不要降級成 AI reviewer 的建議。
第四，開始看 queue，而不只看產量。每週花十分鐘看首次 review 時間、review cycles、未合併 PR 年齡和放棄原因，通常就能發現 agent 是否正在把工作從「寫程式」搬到「等人驗收」。
這四件事都不新潮，甚至有點像普通的 CI 整理。也正因如此，它們才有用。AI reviewer 帶來的新問題，未必需要一套全新的管理語言；很多時候，只要把原本對執行環境、權限與證據的要求，老實套回去就夠了。
Reviewer 最有價值的時候
我並不期待 AI reviewer 成為最後一位批准者。
它真正有價值的時候，是能替人縮小注意範圍：指出哪段 diff 值得多看一眼、哪個 repo 規則可能被漏掉、哪條路徑需要補測試。人不必從零開始掃過所有細節，但仍然知道這些建議依據哪些規則、在什麼環境產生。
這個「知道」很重要。因為 review 的信任不該來自留言寫得像不像資深工程師，而要來自一條看得懂的證據鏈。
當團隊能說清楚 reviewer 讀了什麼、執行了什麼、被限制在什麼範圍，以及哪些 required checks 和批准仍然留在人手上，AI review 才真正替工作流增加了一層保護。
否則，我們只是讓另一個 agent 在 PR 裡說了一句很像結論的話。
Source notes
- Copilot code review: Customization and configurability improvements (github.blog/changelo...)
- Add review cycles and time to adoption phases in the usage API (github.blog/changelo...)
- Repository-level GitHub Copilot usage metrics generally available (github.blog/changelo...)
- How agents are transforming work (openai.com/index/how...)
- Are AI coding agents actually changing how developers work, or are we still in the autocomplete phase? (www.reddit.com/r/AI_...)