AI 讓寫程式變便宜之後，瓶頸搬到了 Code Review：22 萬個 PR 的實證分析

瀏覽次數: 4

本文大綱

這篇文章適合你，如果你是…

技術主管 / 架構師: 團隊導入 coding agent 之後，PR 數量暴增但東西沒有更快上線，你需要知道問題出在哪、以及怎麼量測
資深工程師: 你的日常正在從「寫 code」變成「審 code」，而且愈審愈累，你想知道這是不是普遍現象、有沒有系統解法
開源專案維護者: 你正在被 AI 生成的 PR 淹沒，想知道其他專案怎麼應對、哪些做法有實證支持

1. 前言：問題場景

Hook 開場

2026 年 3 月 14 日，Jazzband 宣布熄燈。

這不是一個沒人用的玩具專案。Jazzband 十年間維護 84 個 Python 專案——django-debug-toolbar、pip-tools、prettytable、sorl-thumbnail——月下載量超過 1.5 億次，3,135 名成員遍及南極洲以外的每一個大陸，累積約 93,000 顆 GitHub star，發布過 1,312 個 PyPI 版本。

它不是因為沒人用而死的。它是因為沒有人審得完而死的。官方公告裡寫得很直白：GitHub 的「slopocalypse」——AI 生成垃圾 PR 的洪水——讓 Jazzband「開放成員 + 共享 push 權限」的模式不再安全。公告中引用的數字是：只有十分之一的 AI 生成 PR 達到專案標準。

從系統架構的角度看，這件事一點也不意外，甚至是可以預測的。這是一個教科書等級的約束理論（Theory of Constraints）案例：

一條管線的總吞吐，由最慢的環節決定。過去二十年，軟體交付最慢的環節一直是「把程式碼寫出來」。AI 把這個環節的邊際成本壓到趨近於零——一個 agent 可以同時開十個 PR，凌晨三點也不會累。但下游的審查環節，服務率幾乎沒有變：一個人一次還是只能認真讀一個 diff，而且讀別人寫的 code 比讀自己寫的貴得多。

到達率暴增、服務率不變。接下來會發生什麼，Little's Law 早就寫好了答案。

而數據確實對上了。Faros AI 追蹤 22,000 名開發者的 telemetry 顯示，PR 審查時間的中位數上升了 441.5%。CircleCI 分析 2,873 萬個 workflow 後發現，中位數團隊的分支活動增加 15%，但主幹（main branch）的產出反而下降 7%。

程式碼確實被寫出來了。它只是卡在合併之前。

解決方案預告

這篇文章不打算再寫一篇「AI slop 好可怕」的情緒文。我想做三件更有用的事：

用一手學術研究（不是互相抄襲的二手部落格）證明這個瓶頸是真的、以及它的真實形狀
推翻一個最直覺但錯誤的解釋——「因為 AI 寫得爛」
給出一份基於實證數據的任務分工表，和一套把審查從「人力」重構成「管線」的做法

文章承諾

五份一手研究的完整拆解（涵蓋 22 萬個 PR、5 種 coding agent）
學術數據 vs 廠商 telemetry 的正面對決——它們互相打架，而這件事本身很有意義
一份實證的 agent 任務分工表（哪些放手、哪些別碰）
可直接落地的四種解法與量測指令
公開更正兩處在中英文圈廣泛流傳的數據歸屬錯誤

讀者收穫

讀完這篇文章，你將能夠：

判斷你的團隊是否已經進入「審查瓶頸」，並用三個具體指標量測出來
依據實證數據決定「哪些任務該派給 agent、哪些不該」
辨識四種在審查瓶頸下最危險的反模式（包括你可能正在做的那個）
在別人引用網路數字時，知道哪些數字是錯的、為什麼錯

1.5 TL;DR

瓶頸已經位移：審查時間中位數 +441.5%（Faros，22,000 開發者），主幹產出 −7% 但分支活動 +15%（CircleCI，2,873 萬 workflow）
不是因為 AI 寫得爛：22 萬個 PR 的研究顯示，agentic PR 的缺陷傾向與人類相當或更低；被拒絕的 PR 中只有 35.7% 是真正的 agent 失敗
真正的危險是審查在偷偷降級：78.9% 的 agentic PR 只有單人審查，而且單審（81.2%）與多審（80.3%）的合併率幾乎沒差——多一雙眼睛沒有改變任何結果
agent 有明確的能力邊界：CI 設定、相依套件、授權類任務合併率 >0.90；一進入 function implementation、LLM integration 就掉到 0.60 以下
不要引用任何外部數字當基準：學術說 65%、廠商說 32.7%，差 2.5 倍。唯一有意義的是量測你自己的管線

2. 核心概念解釋

2.1 什麼是「審查瓶頸」

定義：在 AI coding 普及後，軟體交付系統的限制因素從「產出程式碼的速度」，位移到「人類確認程式碼是否可安全合併的速度」。

我喜歡用一個比喻：你把工廠的沖壓機換成了雷射切割，產能翻十倍，但品管站還是那三個人拿著游標卡尺。

結果不會是「產能翻十倍」。結果會是三選一：

半成品堆滿倉庫（PR 佇列爆炸）
品管開始隨便看（審查降級）
或者最糟的組合——兩者同時發生，而且儀表板上看起來一切正常

2.2 為什麼這是結構必然，不是工具問題

四個機制疊加，缺一不可：

① 產能不對稱
生成端的邊際成本趨近於零。審查端的邊際成本幾乎不變——它受限於人類的閱讀速度與注意力，而這兩者在過去五萬年沒什麼進展。

② 佇列非線性爆炸
排隊理論的基本結果：當系統利用率逼近 100%，等待時間會指數上升而非線性上升。這解釋了一個關鍵觀察——「等待被審」的時間漲得比「實際審查」的時間兇得多。LinearB 的數據正是如此：AI PR 的等待時間是未輔助 PR 的約 5 倍（約 1,000+ 分鐘 vs 約 200 分鐘）。

③ 系統會偷偷降低服務標準
這是最容易被忽略、也最危險的一點。當佇列壓力超過臨界，人類系統不會乖乖排隊——它會降低單位服務成本來維持吞吐。表現形式就是：單人審查、快速 approve、掃過去而不是讀進去。

吞吐看起來維持住了，但驗證強度被偷偷拿掉了。而這件事不會出現在任何 DORA 指標上。

④ 不對稱的認知成本
讀一段不是自己寫的 code，成本遠高於讀自己寫的。而 AI PR 又普遍更大——LinearB P75 數據：未輔助 157 行，AI 輔助 400+ 行。單位審查成本因此進一步上升。

2.3 關鍵術語表

術語	英文	說明
約束理論	Theory of Constraints	系統吞吐由最慢環節決定；優化非約束環節只會累積在制品，不會提升總吞吐
撿起時間	Pickup Time	PR 開出到「第一次有人開始審」的等待時間。本主題最靈敏的指標
審查時間	Review Time	開始審到結束的時間。必須與 pickup time 分開看，否則會得出完全相反的結論
加速甩尾	Acceleration Whiplash	Faros 提出：上游被 AI 加速、下游仍是人類節奏，系統被自己的產出反噬
Agentic PR	Agentic Pull Request	由 agent 自主開立的 PR。與「人類用 AI 輔助後自己開的 PR」統計特性不同，常被混為一談
橡皮圖章審查	Rubber-stamp review	形式上 approve、實質未驗證。審查瓶頸下最危險的適應行為
AI slop	AI slop	大量、表面合理但實質低品質的 AI 產出

視覺素材 1：概念示意圖——「沖壓機 vs 品管站」的產能不對稱示意

3. 五份一手研究的深度拆解（本文核心）

資料品質聲明：本節嚴格區分三層證據——① Tier 1 學術研究（arXiv / MSR 2026，有明確母體與方法）② Tier 2 廠商 telemetry（母體大但非同儕審查、判定標準未公開）③ Tier 3 生態系事件。兩層之間的數字不可直接相加或相除。

3.1 目前規模最大的 agentic PR 縱貫研究

來源：Mazloomzadeh, Morovati, Khomh, How Do AI Coding Agents Contribute to Software Development?, arXiv:2607.21832（2026-07-23 投稿）

原理簡述：分析 220,612 個已關閉 PR，來自 489 個 Python repo（stars ≥ 100），其中 agentic PR 9,428 個（7,293 合併、2,135 被拒），涵蓋 OpenAI Codex、GitHub Copilot、Claude Code、Cursor、Devin 五種 agent，資料截至 2025-08-10。主題模型分類經 100 個 PR 人工驗證，87% 正確，Cohen's κ = 84.2%。

發現一：不同 agent 的合併率差距接近兩倍

Agent	合併機率
Claude Code	84.3%
OpenAI Codex	73.5%
Cursor	63.9%
GitHub Copilot	59.6%
Devin	43.0%

說白了：「AI 寫的 code」根本不是一個同質類別。Claude Code 和 Devin 之間差了 41 個百分點。任何把所有 agent 混在一起算的統計，都會被組合比例（mix）帶偏——這也是後面 §5 數據矛盾的原因之一。

發現二：合併率明顯低於人類，而且沒有隨時間改善

Agentic PR 各季合併率：Q1 65.4%、Q2 63.7%、Q3 68.2%、Q4 67.7%
論文明言：沒有任何一組成對比較達到統計顯著
人類 PR 穩定在 0.850 ~ 0.856

這是對「等下一代模型就好了」的直接反證。 在整個觀測窗內，模型世代確實在更新，但 agentic PR 的整體合併率沒有實質提升。如果問題出在模型能力，這條線應該要往上走。它沒有。

發現三：agent 的貢獻高度集中在低風險雜務

出現頻率前三：文件（documentation）、相依套件管理（dependency）、測試（testing）
最少：token 管理、授權合規

合併率	任務類型
≥0.80，多數季度 >0.90	GitHub Action workflow、CI & build、asset management、dependency、hook management、license、token management
≤ 約 0.60	LLM integration、model evaluation、JSON template、function implementation

這是全文最有實務價值的一張表。 它是一份實證的分工說明書：愈接近真正的功能實作，合併率掉得愈明顯。 我在 §4 會把它轉成可直接執行的紅黃綠分區。

發現四（反直覺，但必須誠實面對）

論文指出：agentic PR 的缺陷傾向（defect proneness）與人類 PR 相當或更低，多數差異不具統計顯著性。 兩者在 commit 數、貢獻者數、變更檔案數、程式碼行數上的差異「實務量級有限」。

Before/After 對比（Tier 3）：論文另外觀察到，後期季度的 agentic PR 整合更順暢，反映的不是模型變強（見發現二），而是開發者累積了與 agent 協作的經驗。改善來自人的一側，不是模型的一側。

這推翻了最直覺的解釋。 如果 agentic PR 的品質不比人類差，為什麼合併率低 20 個百分點？答案不在程式碼裡——在流程裡。下一份研究接手回答。

3.2 「被拒絕」嚴重高估了 agent 的失敗率

來源：Peralta 等 11 位作者, Why Are Agentic Pull Requests Merged or Rejected?, arXiv:2605.22534（2026-05-21，已被 MSR 2026 接受）

方法：11,048 個已關閉 agentic PR → 篩出 9,799 個經人類審查者 → 717 個案例人工檢閱，還原真實的決策理由。

被拒絕的 PR，理由分布：

拒絕原因	佔比
真正的 agent 失敗	35.7%
流程 / 工作流限制（重複、時機不對、範圍外、政策不收）	31.2%
完全看不到可觀察的決策理由	33.1%

被合併的 PR：

15.4% 需要審查者明確介入（feedback 或直接 commit）
5.5% 完全沒有任何互動痕跡

論文結論的原話大意是：拒絕結果實質上高估了 agent 的錯誤率，且合併/拒絕本身「在不考慮審查互動的情況下，無法可靠反映 agent 能力」。

這段有兩個殺傷力極強的意涵：

把「合併率」當 agent 的 KPI 是錯的。 近三分之一的拒絕根本不是 agent 寫錯，是流程不收。你用這個指標去評估工具，會得到系統性錯誤的結論。
那 5.5% 的「零互動合併」，是橡皮圖章的量化證據。 沒有留言、沒有 commit、沒有任何痕跡，就進主幹了。

3.3 合併之後，人類還要改多少

來源：Watanabe, Li, Kashiwa, Reid, Iida, Hassan, On the Use of Agentic Coding, arXiv:2509.14745（2025-09-18，最新版 2026-02-09）

母體：567 個 Claude Code PR，橫跨 157 個開源專案

指標	數值
最終被合併	83.8%
合併且完全未再修改	54.9%
合併但需要人類修訂	45.1%

交叉驗證的價值：這裡的 83.8% 與 §3.1 中 Claude Code 的 84.3%，是兩份母體完全不同的獨立研究，給出幾乎一致的數字。這種一致性讓我對這個量級有信心——這在這個充滿互抄數字的主題裡很難得。

實務意涵：即使合併了，將近一半（45.1%）仍需要人類動手改。所以「合併率」不只高估了失敗，也低估了成本。真正的成本是「合併率 × 修訂率」的複合。

3.4 介入變少了，但每一次都更貴

來源：Khelifi（ÉTS Montréal）, Ouni（ÉTS）, Khemaja（University of Sousse）, Behind Agentic Pull Requests, MSR 2026 Mining Challenge（AIDev dataset）

指標	Agent 開的 PR	人類開的 PR
有人類介入的比例	52.17%	83.59%

介入種類分布（agent PR）：

介入層級	佔比
指導層（guidance）	58.02%
決策層（decision）	21.16%
直接改 code	17.05%
操作層（operational）	3.69%

關鍵發現：agent PR 的介入次數較少，但一旦發生，需要更大的 code churn 與更長的處理時間。

論文的結論很值得引用：人機協作正在把開發者的工作「從實作轉向監督、指導與品質控制」。

這解釋了一個常見的管理誤判。 主管看到「介入率從 83.59% 掉到 52.17%」，很容易讀成「agent 變可靠了」。實際上是分布的尾端變重了——平均數下降，但少數幾個又大又難的案例吃掉更多時間。平均數在騙人。

3.5 審查層正在變薄【本週新研究】

來源：Raida, Hou（Rochester Institute of Technology），報導於 2026-07-22

母體：25,264 個 agentic PR，2025 年 5–7 月，repo stars ≥ 100，涵蓋 Copilot、Codex、Claude Code

發現	數值
小團隊（1–5 貢獻者）平均每季 agentic PR	50.2 個（遠高於中大型團隊）
多數 repo 每季 agentic PR	僅 1–2 個
由單一開發者審查的 PR	78.9%
接近九成 PR	只有一人監督、無群體參與
單一審查者的合併率	81.2%
多審查者的合併率	80.3%

這是本文最關鍵的一塊拼圖，理由是那 0.9 個百分點的差距。

如果審查真的在做實質把關，多一雙眼睛應該要改變結果——應該要抓出更多問題、拒掉更多 PR。結果幾乎完全一樣（81.2% vs 80.3%）。

**** 這強烈暗示：在很多情況下，審查已經不是決定性關卡了。它更像一道儀式，而不是一道閘門。而且注意 §3.2 的 5.5% 零互動合併——兩份獨立研究從不同角度指向同一個結論。

再加上小團隊是 agent 的重度使用者（每季 50.2 個 PR）——而小團隊恰恰是最沒有審查人力冗餘的一群。壓力最大的地方，防護最薄。

研究自陳限制（必須誠實標註）：此研究只量測「立即接受與否」，revert 與長期程式碼品質不在資料集範圍內。也就是說，真實的成本可能比這些數字更高，因為「合併了但三週後被 revert」不會被算進去。

視覺素材 2：五份研究的母體與核心發現對照表
視覺素材 3：agent 合併率長條圖（Claude 84.3% → Devin 43.0%）
視覺素材 4：拒絕原因的三分圓餅圖（35.7% / 31.2% / 33.1%）

4. 廠商 telemetry：規模更大，但要小心讀

⚠️ 以下是 Tier 2 資料。母體極大，但判定標準未完全公開（例如「AI PR」如何被標記），且觀測窗與 Tier 1 不同。只看趨勢方向與量級。

4.1 Faros AI《AI Engineering Report 2026: The Acceleration Whiplash》

母體：22,000 名開發者的 telemetry

指標	變化
審查時間中位數	+441.5%
審查時間平均數	+199.6%
被撿起前的等待時間（中位數）	+156.6%

Faros 早期研究（10,000+ 開發者、1,255 個團隊），高 AI 採用 vs 低採用團隊：

指標	變化
完成任務數	+21%
合併 PR 數	+98%
PR 審查時間	+91%
平均 PR 大小	+154%
每位開發者的 bug 數	+9%

一個容易被略過但很重要的統計細節：注意「中位數 +441.5%」大於「平均數 +199.6%」。

通常平均數會被長尾拉高於中位數。這裡反過來，代表整個分布的主體都在往右移，而不是被少數極端案例帶動。

這是系統性惡化的訊號，不是離群值。 你不能安慰自己「那是別人家的爛專案拉高的」。

4.2 LinearB《2026 Software Engineering Benchmarks Report》

母體：810 萬個 PR、約 4,800 個工程團隊、42 個國家

指標	未使用 AI	AI 輔助	Agentic AI
PR 大小（P75，行數）	157	400+	~290
Pickup time（等待被審）	~200 分鐘	~1,000+ 分鐘（約 5 倍）	—
Review time（開始審之後）	252 分鐘	~194 分鐘（更快）	—

指標	數值
人工 PR 合併率	84.5%
AI PR 合併率	32.7%
開發者固定使用 AI 比例	88.3%

這裡有兩個必須講清楚的洞察：

① 「等待」與「審查」是往相反方向走的。
AI PR 等更久（約 5 倍），但一旦開始審，反而更快（194 vs 252 分鐘）。

表面上這像好消息。但請想一想：一個更大（400+ 行 vs 157 行）、而且不是你寫的 diff，為什麼會被更快審完？

**** 最合理的解釋是：審查者在掃，不是在讀。這是 rubber-stamp 的行為指紋，而且它與 §3.2 的 5.5% 零互動合併、§3.5 的單審多審無差異，形成三方交叉印證。

② agentic PR 比 AI 輔助 PR 更小（290 vs 400+ 行）。
反直覺，但完全合理：agent 通常被派去做界線清楚的小任務（見 §3.1 的任務分布），而人類用 AI 輔助時傾向一次堆更多東西進去。

這帶出一個實用結論：真正該被限制大小的，可能是「人類用 AI 寫的 PR」，而不是 agent 開的 PR。

4.3 CircleCI《2026 State of Software Delivery》

母體：28,738,317 個 workflow（2025 年 9 月），限定 ≥2 貢獻者且執行 ≥5 次的專案

指標	數值
平均 throughput 年增	+59%
前 5% 團隊	+97%
中位數團隊	僅 +4%
後四分位團隊	無可量測增幅
中位數團隊：feature branch	+15%
中位數團隊：main branch	−7%
前 10% 團隊：feature branch / main branch	約 +50% / +1%
main branch 成功率	70.8%（五年多來最低，CircleCI 基準為 90%）
復原時間	72 分鐘（年增 +13%）

這是「約束位移」最乾淨的量化證據。

分支上的活動大增（+15%），主幹上的產出卻在倒退（−7%）。程式碼確實被寫出來了，但它卡在合併之前。

同時，主幹健康度掉到五年新低（70.8%，基準 90%）——擠過去的那些，品質在下滑。

還有一個容易被忽略的分佈事實：平均 +59% 這個亮眼數字，是被前 5%（+97%）拉起來的。中位數團隊只有 +4%，後四分位完全沒有可量測的增幅。

說白了：AI 的交付紅利高度集中在少數團隊手上，而那些團隊的共同點不是用了更好的模型，是他們的管線撐得住。

視覺素材 5：CircleCI 分支 vs 主幹 throughput 對比圖（+15% vs −7%）
視覺素材 6：pickup time vs review time 的反向走勢圖

5. 數據矛盾分析：agentic PR 的合併率到底是多少？

這是我認為這個主題最有意思、也最沒有人處理的部分。

來源	數值	母體
arXiv 2607.21832（Tier 1）	~65%	9,428 agentic PR，489 個 ≥100 star Python repo
arXiv 2509.14745（Tier 1）	83.8%	567 個 Claude Code PR，157 個 OSS 專案
RIT 研究（Tier 1）	81.2% / 80.3%	25,264 agentic PR，≥100 star repo
LinearB（Tier 2）	32.7%	810 萬 PR，4,800 個企業團隊

最高與最低差了 2.5 倍。

大部分文章的做法是挑一個最聳動的用（通常是 32.7%）。我認為誠實列出五個可能原因更有價值：

① 母體完全不同。
Tier 1 全部限定「GitHub stars ≥ 100 的公開 repo」——這是已經有審查文化、有 CI、有貢獻規範的專案。LinearB 是企業內部團隊，包含大量沒有這些條件的組織。

② 「AI PR」的判定方式不同。
Tier 1 靠 agent 帳號 / 簽章明確識別 agentic PR。LinearB 把「AI 輔助」與「agentic」分開統計，但外界看不到標記規則。

③ 時間窗不同。
Tier 1 資料多截至 2025 年中（2607.21832 截至 2025-08-10），LinearB 是 2026 年資料。而這段期間正是 agent 使用量爆炸期——大量新手在這段時間湧入。

④ 倖存者偏差。
公開 repo 的 agentic PR 多由已經懂得怎麼用 agent 的人開出。企業內全員推廣則包含大量還在摸索的使用者。

⑤ 「關閉」的語意不同。
企業內未合併的 PR 常常只是被放棄、或被 squash 進別的分支，未必等於「被審查者拒絕」。

這個矛盾給你的真正結論

不要引用任何一個外部數字當作你團隊的基準。

這些數字之間的離散度本身就證明了：這個指標高度依賴脈絡。一個在 LinearB 母體裡「正常」的團隊，放到 arXiv 母體裡可能是災難，反之亦然。

唯一有意義的做法是：量測你自己的管線，而且分開統計 agentic 與人類 PR。

上面每一份研究，本質上都是在示範這件事該怎麼做。

6. 決策框架：實證任務分工表

6.1 紅黃綠分區（源自 §3.1 的合併率數據）

風險區	任務類型	實證合併率	建議做法
🟢 綠區	CI/build 設定、GitHub Action、相依套件更新、授權合規、asset、hook 管理	≥0.80，常 >0.90	放手讓 agent 做。用 CI 當唯一 gate，不需要人眼審查
🟡 黃區	文件、測試、重構	中等（agent 使用頻率最高的區段）	可以做，但測試必須另外驗（見 §6.3 反模式三）
🔴 紅區	function implementation、LLM integration、model evaluation、JSON template	≤ ~0.60	人類主導，agent 只產草稿。這一區不要看合併率，要看 revert 率

6.2 決策樹（文字版）

這個任務要不要派給 agent？
│
├─ 這個變更能被 CI / type check / 靜態分析完整驗證嗎？
│   ├─ 是 → 🟢 綠區：放手做，CI 就是 gate，不排人審
│   └─ 否 → 往下
│
├─ 這個變更會改變執行期行為（business logic / 外部整合 / 資料模型）嗎？
│   ├─ 否（文件、測試、純重構）→ 🟡 黃區
│   │      └─ 限制 PR ≤ 200 行 + 人審 + 測試獨立驗證
│   └─ 是 → 往下
│
├─ 出錯的話，多久會被發現？
│   ├─ CI 立刻抓到 → 🟡 黃區處理
│   └─ 要等到生產環境 / 使用者回報 → 🔴 紅區
│          └─ agent 只產草稿，人類重寫關鍵路徑，強制 2 人審 + 明確 revert 計畫

6.3 三個真實場景

場景 A：5 人新創，重度使用 coding agent

環境：小團隊、無專職 reviewer、每季 agentic PR 約 50 個（正是 RIT 研究中的高風險族群）
推薦：把 90% 的審查責任移交給 CI。人只審紅區。強制 PR 大小上限。
理由：你沒有審查人力冗餘，硬要人審的結果一定是橡皮圖章——那比不審更危險，因為它製造了虛假的安全感。

場景 B：50 人的企業工程團隊，剛全員導入 AI

環境：有 reviewer 文化，但 PR 數量在三個月內翻倍
推薦：先做量測，不要先做政策。分開統計 agentic / AI 輔助 / 純人工三類 PR 的 pickup time 與 revert 率，跑滿一個月再決定。
理由：你現在最缺的不是規則，是能見度。看不到就管不了（見 §6.4 的量測腳本）。

場景 C：開源專案維護者，正在被 AI PR 灌爆

環境：外部貢獻者不受你控制，審查完全是無償勞動
推薦：把成本推回貢獻者端。要求 PR 附上可複現的測試、通過完整 CI 才進入人工審查佇列、明確的 AI 貢獻揭露政策。
理由：Jazzband 的教訓是——當到達率不受控時，唯一可持續的槓桿是提高提交門檻，而不是提高審查產能。curl、Ladybird、tldraw 走的都是這條路。

6.4 實戰最佳實踐：把審查從「人力」重構成「管線」

四種解法（依槓桿大小排序）

① 減少到達率（最有效、最常被忽略）

不是所有 agent 產出都值得成為一個 PR。在 agent 端就加 gate：

# .github/workflows/agent-gate.yml
# 基於架構原則設計：讓「開 PR」這件事本身有成本
# 目的：跑不過基本驗證的 agent 產出，根本不該進入人類的佇列
name: Agent PR Gate
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  gate:
    # 只對 agent 開的 PR 生效（依你的 agent 帳號調整）
    if: contains(fromJSON('["claude[bot]","copilot-swe-agent[bot]","devin-ai-integration[bot]"]'), github.actor)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 關鍵一：PR 太大就直接擋，不讓它進入人類佇列
      # 依據：LinearB P75 顯示 AI 輔助 PR 達 400+ 行，是審查成本主因
      - name: Enforce PR size limit
        run: |
          CHANGED=$(git diff --stat origin/${{ github.base_ref }}...HEAD \
            | tail -1 | awk '{print $4+$6}')
          echo "Changed lines: $CHANGED"
          if [ "${CHANGED:-0}" -gt 300 ]; then
            echo "::error::PR 超過 300 行（實際 $CHANGED）。請拆成多個 PR。"
            exit 1
          fi

      # 關鍵二：測試必須存在且通過——不信任 agent 自陳的「已測試」
      - name: Run full test suite
        run: make test

      # 關鍵三：改了執行期程式碼卻沒動測試 → 標記為紅區，要求人審
      - name: Detect untested runtime changes
        run: |
          SRC=$(git diff --name-only origin/${{ github.base_ref }}...HEAD \
            | grep -E '^src/.*\.(py|ts|go)$' | wc -l)
          TST=$(git diff --name-only origin/${{ github.base_ref }}...HEAD \
            | grep -E '^tests?/' | wc -l)
          if [ "$SRC" -gt 0 ] && [ "$TST" -eq 0 ]; then
            gh pr edit ${{ github.event.number }} --add-label "needs-human-review"
          fi
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

② 把審查左移進管線

用 CI、type check、靜態分析、政策檢查，取代人眼審查「機械可判定」的部分。

人只審機器判不了的東西：架構契合度、需求正確性、安全邊界、對既有不成文慣例的遵循。

**** 這是整套做法的核心哲學：人類審查是稀缺資源，就該像稀缺資源一樣被配置。 你不會讓資深架構師去人工檢查程式碼縮排，同樣的邏輯應該推廣到所有機器可判定的項目。

③ 限制 PR 大小

AI 輔助 PR 在 P75 達 400+ 行（vs 未輔助 157 行）。這是審查成本的主要來源，也是最直接的槓桿。

注意 §4.2 的發現：該被限制的主要是「人類用 AI 寫的 PR」（400+ 行），agentic PR 反而較小（~290 行）。很多團隊的政策方向搞反了。

④ 明確標記 agentic PR 並分開統計

這是所有改善的前提。看不到就管不了。

#!/usr/bin/env bash
# measure-review-bottleneck.sh
# 量測你自己管線的三個關鍵指標，分開統計 agent vs 人類
# 依賴：gh CLI (v2.40+), jq
# 用法：./measure-review-bottleneck.sh owner/repo 30

REPO="${1:?usage: $0 owner/repo [days]}"
DAYS="${2:-30}"
AGENTS="claude|copilot-swe-agent|devin-ai-integration|cursor|codex"

echo "== 量測 $REPO 最近 $DAYS 天 =="

gh pr list --repo "$REPO" --state all --limit 500 \
  --json number,author,createdAt,closedAt,mergedAt,additions,deletions,reviews \
| jq --arg agents "$AGENTS" --argjson days "$DAYS" '
  # 只看指定天數內建立的 PR
  map(select(
    (.createdAt | fromdate) > (now - ($days * 86400))
  ))
  # 依作者是否為 agent 分兩組
  | group_by(.author.login | test($agents; "i"))
  | map({
      # 這組是 agent 還是人類
      kind: (if (.[0].author.login | test($agents; "i")) then "AGENT" else "HUMAN" end),
      count: length,
      merge_rate: ((map(select(.mergedAt != null)) | length) / length * 100 | round),
      # pickup time：開 PR 到第一次 review 的等待（分鐘）——最靈敏的瓶頸指標
      median_pickup_min: (
        map(select(.reviews | length > 0)
            | ((.reviews[0].submittedAt | fromdate) - (.createdAt | fromdate)) / 60)
        | sort | if length == 0 then null else .[length/2 | floor] | round end
      ),
      median_size_lines: (
        map(.additions + .deletions) | sort
        | if length == 0 then 0 else .[length/2 | floor] end
      ),
      # 零互動合併率：rubber-stamp 的直接證據（對照研究中的 5.5%）
      zero_review_merge_pct: (
        (map(select(.mergedAt != null and (.reviews | length) == 0)) | length)
        / length * 100 | round
      )
    })
'
echo ""
echo "判讀：AGENT 組的 median_pickup_min 若是 HUMAN 組的 3 倍以上 → 佇列已飽和"
echo "      zero_review_merge_pct 若明顯高於 5% → 橡皮圖章審查正在發生"

反模式警告：五個你可能正在做的錯事

❌ 常見錯誤	✅ 正確做法	依據
用「合併率」當 agent 的 KPI	用 revert 率 + 合併後修訂率	§3.2：31.2% 的拒絕來自流程限制、33.1% 沒有理由
把「審查時間變短」當好消息	搭配 pickup time 一起看；變短 + 等更久 = 掃過去	§4.2：AI PR 開審後更快（194 vs 252 分鐘）
相信 agent 附的測試	測試獨立驗證（mutation testing / 覆蓋率門檻）	arXiv 2605.06464：agent 初版 PR 的測試常不足且需頻繁補寫
把「介入率下降」讀成「agent 變可靠」	看單次介入成本，不看平均介入率	§3.4：次數少但 churn 更大、時間更長
以為多加一個審查者就解決了	改變審查方式（左移進管線），不是增加審查人數	§3.5：單審 81.2% vs 多審 80.3%，幾乎無差異

7. 效能調優：三個立刻可以量測的指標

如果你只有一個下午，先做這三件事：

① 分開量測 pickup time（最靈敏）
把 agentic PR 與人類 PR 的 pickup time 分開畫。如果 agent PR 的等待時間是人類 PR 的 3 倍以上，你的審查佇列已經飽和了。 這個指標比合併率靈敏得多，因為它在品質出問題之前就會亮紅燈。

② 追蹤「零互動合併率」
對照組是研究中的 5.5%。你的數字明顯更高，代表橡皮圖章審查正在發生。這是唯一能直接量化「審查降級」的指標。

③ 把 PR 大小按來源分桶
未輔助 / AI 輔助 / agentic 三類分開看 P75。對照 LinearB 的 157 / 400+ / ~290。你會很快發現該對哪一類設限——通常不是你以為的那一類。

**** 如果你的管線已經有這三個指標，下一步是建立「審查預算」概念：把團隊每週的人類審查工時當成一個固定容量，明確分配到紅黃綠三區。當綠區吃掉超過 20% 的審查預算，就是自動化沒做夠的訊號。

8. 工具與資源推薦

工具	用途	連結
gh CLI	撈 PR metadata 做自訂量測（見 §6.4 腳本）	https://cli.github.com/
Danger JS / Danger Ruby	在 CI 內執行 PR 政策檢查（大小、標籤、測試存在性）	https://danger.systems/
Semgrep	把「架構規範」寫成可自動檢查的規則，左移審查	https://semgrep.dev/
AIDev dataset	MSR 2026 使用的 agentic PR 資料集，可自行複現分析	見 MSR 2026 Mining Challenge
CODEOWNERS	強制紅區檔案必須由特定人審查	GitHub 內建

延伸閱讀（一手來源）：

arXiv:2607.21832 — 目前規模最大的 agentic PR 縱貫研究
arXiv:2605.22534 — 拒絕原因的人工歸因分析（MSR 2026）
Faros AI《AI Engineering Report 2026》— 22,000 開發者 telemetry

9. 總結與展望

一表看完全部證據

層級	來源	母體	核心發現
Tier 1	arXiv 2607.21832	220,612 PR / 489 repo	agentic 合併率 ~65% vs 人類 ~85%；缺陷傾向相當或更低；agent 間差距 84.3%→43.0%
Tier 1	arXiv 2605.22534	11,048 PR（717 人工檢閱）	拒絕中僅 35.7% 是真失敗；5.5% 合併零互動
Tier 1	arXiv 2509.14745	567 Claude Code PR	83.8% 合併，但 45.1% 需人類修訂
Tier 1	MSR 2026 (AIDev)	—	介入率 52.17% vs 83.59%，但單次成本更高
Tier 1	RIT 研究	25,264 PR	78.9% 單人審查；單審 81.2% vs 多審 80.3%
Tier 2	Faros AI	22,000 開發者	審查時間中位數 +441.5%
Tier 2	LinearB	810 萬 PR	AI PR 等待約 5 倍，但開審後更快
Tier 2	CircleCI	2,873 萬 workflow	分支 +15%，主幹 −7%；主幹成功率 70.8%（五年最低）
Tier 3	Jazzband	84 專案 / 月下載 1.5 億	因審查容量被灌爆而熄燈

按讀者類型的建議

小團隊 / 新創：你是 agent 的重度使用者，也是審查冗餘最少的一群。把賭注壓在 CI，不要壓在人審。
企業技術主管：先建立能見度再訂政策。分開統計三類 PR，跑滿一個月。你現在最缺的是資料，不是規則。
開源維護者：提高提交門檻比提高審查產能可持續。成本要推回貢獻者端。

未來趨勢（三個方向）

開源的預設正在從「open by default」轉向「closed by default, earn your way in」。 curl 取消 bug bounty、Ladybird / tldraw 停收外部 PR、Jazzband 熄燈——這是 30 年來 OSS 協作模式最大的一次收縮。
「AI 審 AI」會被大量嘗試，但它解決的是產能問題，不是信任問題。 當人類已經不讀 diff，再加一層 AI 審查只是把橡皮圖章換成自動蓋章機。真正的解法是讓機器可判定的部分變成硬性 gate。
agentic PR 的標記與揭露會標準化。 因為沒有標記就沒有量測，沒有量測就沒有治理——這是所有工程治理的必經路徑。

今天就能開始的四步

跑一次 §6.4 的量測腳本，拿到你自己的 pickup time 與零互動合併率
用 §6.1 的紅黃綠表，把你團隊目前派給 agent 的任務重新分類
加一條 PR 大小上限（先從 300 行開始），觀察兩週
把一個「機器可判定」的審查項目從人審移進 CI——任何一個都行，重點是開始

9.5 可分享金句

「Jazzband 不是因為沒人用而死的。它是因為沒人審得完而死的。」

「AI 讓寫程式的邊際成本趨近於零，但讀程式的成本一點都沒變——瓶頸不會消失，它只會搬家。」

「更大、又不是你寫的 diff，卻被更快審完。這不是效率提升，這是橡皮圖章的指紋。」

「單人審查 81.2%、多人審查 80.3%。多一雙眼睛沒有改變任何結果——那還叫審查嗎？」

「不要引用任何外部數字當你的基準。學術說 65%、廠商說 32.7%，差 2.5 倍。唯一有意義的數字是你自己管線上的那個。」

10. 延伸思考

你的團隊上一次「認真讀完」一個 AI 開的 PR 是什麼時候？如果想不起來，那你們的審查流程實際上還在運作嗎？
如果明天起禁止人類審查任何 agent PR，只能靠 CI——你的 CI 需要補上哪三件事，才敢這樣做？這份清單，其實就是你現在真正欠的技術債。
你團隊裡「審查」是誰的 KPI？如果答案是「沒有人」，那它在資源競爭中一定會輸——這是不是問題的真正根源？

11. FAQ 常見問題

Q1: 這是不是就是在說「AI coding 沒用」？
完全不是。§3.1 的研究顯示 agentic PR 的缺陷傾向與人類相當或更低。問題不在 AI 的產出品質，在於下游系統沒有跟著改。這是流程債，不是工具問題。

Q2: 那我該不該繼續用 coding agent？
該。但要照 §6.1 的紅黃綠分區用。綠區（CI 設定、相依套件、授權）合併率超過 0.90，那是純粹的收益。紅區（function implementation、LLM integration）掉到 0.60 以下，那裡需要人類主導。

Q3: 為什麼學術研究說 65%、LinearB 說 32.7%？我該信哪個？
兩個都信，但都不要拿來當你的基準。母體、標記方式、時間窗都不同（詳見 §5 的五個原因）。去量你自己的。

Q4: 「審查時間 +441%」是 CircleCI 的數據嗎？
不是，這是常見的錯誤引用。 正確出處是 Faros AI《AI Engineering Report 2026》（22,000 開發者 telemetry），精確數字為中位數 +441.5%。CircleCI 的 2026 報告完全沒有 PR review time 數據。詳見 §12。

Q5: 我常看到「31% 更多 PR 未經審查就合併」，這數字可靠嗎？
我無法在 Faros 或 CircleCI 的一手材料中定位這個數字，所以本文不使用它。若要表達同一概念，請改用可查證的 arXiv 2605.22534：5.5% 的合併 PR 完全沒有互動痕跡。

Q6: 用 AI 來審查 AI 的 code，可行嗎？
可以作為分流（過濾掉明顯不合格的），但不能作為最終 gate。理由見 §9 趨勢二：當人類已經不讀 diff，再加一層 AI 審查只是把橡皮圖章換成自動蓋章機。AI reviewer 應該取代的是「機器可判定」的部分，那部分本來就該是 CI 的工作。

Q7: 小團隊沒有人力做 code review，怎麼辦？
你正是 RIT 研究中每季 50.2 個 agentic PR 的高風險族群。答案是不要假裝在做 review——把資源全押在 CI 與測試，人只審紅區。硬撐出來的橡皮圖章審查比誠實地不審更危險，因為它製造虛假的安全感。

Q8: PR 大小上限設多少合理？
先看你自己的 P75（見 §7 第三點）。參考值：LinearB 未輔助 PR 的 P75 是 157 行。我建議從 300 行開始（保留緩衝），觀察兩週後再往下收。重點是先有這條線，不是一步到位。

Q9: Jazzband 真的是被 AI 搞垮的嗎？
不能這樣簡化。官方公告同時列出「對單一管理員的結構性依賴」與「2017 年起就未解決的治理問題」。準確的說法是：AI slop 是壓垮既有結構性脆弱的最後一根稻草，不是唯一原因。

Q10: 為什麼 agentic PR 反而比「人類用 AI 輔助」的 PR 小？
因為 agent 通常被派去做界線清楚的小任務（§3.1 顯示集中在文件、相依套件、測試），而人類用 AI 輔助時傾向一次堆更多東西進去。LinearB 數據：agentic ~290 行 vs AI 輔助 400+ 行。

Q11: 這些研究的資料是什麼時候的？會不會已經過時？
必須誠實說：Tier 1 學術資料的觀測窗多在 2025 年中（arXiv 2607.21832 截至 2025-08-10），Tier 2 廠商 telemetry 是 2026 年。存在時間差。但 §3.1 發現四季之間沒有統計顯著變化，暗示這個結構性問題不會因為幾個月的模型更新而消失。

Q12: RIT 那份研究說單審多審沒差，會不會只是因為好的 PR 本來就會過？
這是很好的質疑，也是該研究的限制之一——它只量測立即接受與否，revert 與長期品質不在範圍內。所以嚴格說，它證明的是「多一位審查者沒有改變立即接受的結果」，而不是「多一位審查者完全無用」。但配合 §3.2 的 5.5% 零互動合併與 §4.2 的審查時間反常變短，三方指向同一個方向。

12. 查證更正紀錄（本文的公開勘誤）

在研究這個主題時，我發現至少三處在中英文圈廣泛流傳的數據問題。列在這裡，也歡迎讀者指正本文：

「審查時間 +441%」的歸屬錯誤
多篇二手部落格與 SEO 內容站把此數字歸給 CircleCI 2026 State of Software Delivery。經查證，CircleCI 該報告完全沒有 PR review time 數據。正確出處是 Faros AI《AI Engineering Report 2026》，精確數字為中位數 +441.5%。
「31% 更多 PR 未經審查就合併」無法追溯到一手來源
此數字廣泛流傳且常與上一條並列，但在 Faros 與 CircleCI 的一手材料中皆無法定位。本文不使用此數字。
LinearB 的 pickup time 倍數有 4.6x / 5.3x / 2.47x 三種說法
經查一手內容：AI 輔助 PR 約 1,000+ 分鐘 vs 未輔助約 200 分鐘，約 5 倍。本文採用「約 5 倍」並附原始分鐘數。

13. 參考資料

學術研究（Tier 1）

Mazloomzadeh, I., Morovati, M. M., Khomh, F. (2026-07-23). How Do AI Coding Agents Contribute to Software Development? An Empirical Study of Agentic Pull Requests. arXiv:2607.21832. https://arxiv.org/abs/2607.21832
Peralta, S. R. O., et al. (2026-05-21, MSR 2026). Why Are Agentic Pull Requests Merged or Rejected? arXiv:2605.22534. https://arxiv.org/abs/2605.22534
Watanabe, M., Li, H., Kashiwa, Y., Reid, B., Iida, H., Hassan, A. E. (2025-09-18 / rev. 2026-02-09). On the Use of Agentic Coding. arXiv:2509.14745. https://arxiv.org/abs/2509.14745
Khelifi, S., Ouni, A., Khemaja, M. (MSR 2026). Behind Agentic Pull Requests. https://2026.msrconf.org/details/msr-2026-mining-challenge/26/
Raida, M. N., Hou, D. (RIT, 2026-07-22 報導). 25,264 agentic PR 分析. https://www.helpnetsecurity.com/2026/07/22/users-of-ai-coding-agents/
To What Extent Does Agent-generated Code Require Maintenance? arXiv:2605.06464. https://arxiv.org/html/2605.06464v1
AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent PRs. arXiv:2604.03551. https://arxiv.org/pdf/2604.03551

廠商報告（Tier 2）

Faros AI. AI Engineering Report 2026: The Acceleration Whiplash. https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
Faros AI. The AI Productivity Paradox Research Report. https://www.faros.ai/blog/ai-software-engineering
LinearB. 2026 Software Engineering Benchmarks Report. https://linearb.io/resources/software-engineering-benchmarks-report
LinearB Dev Interrupted. Why AI-assisted PRs merge at half the rate of human code. https://linearb.io/dev-interrupted/podcast/linearb-2026-benchmarks-ai-pr-merge-rate
CircleCI. 5 key takeaways from the 2026 State of Software Delivery. https://circleci.com/blog/five-takeaways-2026-software-delivery-report/

生態系事件（Tier 3）

Jazzband (2026-03-14). Sunsetting Jazzband. https://jazzband.co/news/2026/03/14/sunsetting-jazzband
The New Stack. Open source maintainers are drowning in AI-generated pull requests. https://thenewstack.io/ai-generated-code-crisis/
codenote.net. How OSS Contribution Policies Changed in Response to AI Slop — curl, Ghostty, tldraw. https://codenote.net/en/posts/oss-ai-slop-contribution-policy-shift/