審查作為控制點

資料來源#

• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse
• AI-to-AI Code Reviews of GitHub Pull Requests
• Characterizing the Quality Profile of AI-Generated C++ in Production
• Democratizing Agent Deployment Safety: A Structural Monitoring Approach
• developer responses agent review comments
• Measuring coding agent misalignment in the wild
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild
• Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution
• Prompting Claude Opus 5
• The Speed Trap: 8 takeaways from our latest AI engineering research
• Uncle Bob on Software Fundamentals in the Age of AI
• What Types of Code Review Comments Do Developers Most Frequently Resolve?
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering
• Why do models task game?

摘要#

Agarwal、Miller、Kästner 與 Vasilescu（Carnegie Mellon，arXiv 2607.07980，2026 年 7 月）大規模綜合從業者論述，提出一套解釋程式碼代理程式如何重塑程式碼審查的因果理論：包含 26 個構念與 67 種關係（64 個有向關係、3 個有爭議關係），根據 3,100 份經編碼的灰色文獻文件建構而成。核心主張是：**審查是決定程式碼代理程式對軟體造成何種影響的控制點，而 AI 不會決定影響的正負——決定權在團隊手上，**取決於審查者具備的專業能力，以及團隊如何調整審查流程。「AI 正在改變程式碼審查」由此轉化為帶有明確構念與調節因素、可被證偽的命題。

這篇論文是知識庫中第一份非廠商、機制層次探討 AI 對審查動態影響的研究，也是 Faros 廠商遙測資料的直接對照（見下方的矛盾之處）。

證據說明。 標記為 empirical，但有一項關鍵區分。這套理論是以從業者的論述為基礎提出的解釋性理論，並經研究人員整理——「我們未確認其中任何一種關係」。它的構念與邊都是待驗證的假說，而非實測效果；應將 P1–P17 視為可證偽的主張，而不是研究發現。真正測量的部分，是一項用來說明研究動機的 GitHub 觀察性研究（2,860 個曾接觸代理程式的公開儲存庫，共 250 多萬個 PR）——這是真實遙測資料，但作者的主要結論是：在合理可辯護的分析選擇下，結果的方向不穩定。因此，本文並未在品質結果上比 Faros 測量得更多（它完全沒有測量品質結果）；它補充的是非廠商的跨時段遙測資料，以及一項嚴謹論證：若沒有因果模型，就不能單憑表面趨勢解讀結果。

三項調節因素（論文的核心結論）#

核心主張是，代理程式不會單向地改善或損害審查；它們會對審查系統施加壓力，卻不會讓任何單一結果定型，而三項調節因素決定結果走向何方：

1. 審查者的專業能力與處置方式——審查者具備的技能，以及他們是以信任還是懷疑的態度檢視 AI 程式碼。
2. 自動化審查者的能力——整合到流程中的 AI 審查者實際上有多出色。
3. 流程調整——團隊因應狀況所採取的審查治理政策。

這是代理程式編碼的專業能力回報在審查層面的對照：能放大（或抵禦）程式碼代理程式影響的，是人的理解力與團隊實務，而不是技術本身。

理論架構：驅動因素 → 審查動態 → 結果#

理論（圖 2）由上往下閱讀。節點形狀代表角色，邊線樣式代表方向（實線 = 增加，虛線 = 減少，粗線 = 有爭議，方向由調節因素決定）：

• 驅動因素（代理程式程式碼的外生特性，矩形）：程式碼產出「數量與速度」增加（「審查者的處理量隨人數線性成長；AI 生成量則隨每位開發者乘數式成長」）、表面可信度（讀起來乾淨、符合慣用風格）、程式碼不透明／意圖流失（沒有人類形成其背後的理由）、輸出不一致（執行結果每次不同），以及資料與 IP 曝露風險。
• 審查動態（可調整的中間層，橢圓）：懷疑態度、使用自動化審查與閘控、審查治理政策、審查預算、對高層次意圖的關注、審查深度、理解債務、審查者技能與經驗、編碼技能、共同所有權、審查成效、審查效率、審查動機。
• 結果（從業者關心的事項，六邊形）：程式碼品質、程式碼安全性、審查處理量、審查延遲、可維護性、知識傳承與指導。

核心是 review depth + reviewer skill——這是最繁忙的構念，表面可信度、所有權與編碼技能都透過它們影響處理量與品質。核心也會回饋到自身（見下方迴路）。

關鍵機制（可證偽的命題）#

• 數量增加 → 審查變淺或倦怠。 審查負荷愈高，審查深度愈低（P1：略讀而非閱讀——「每個 sprint 審查 200 個 AI 生成的 PR……大家是在略讀，不是在閱讀」），審查動機也會下降（P2）；相較於寫程式，將更多時間轉向審查會進一步打擊動機（P3：「讀了幾個小時的 AI 程式碼後，我比寫程式兩倍時間還疲憊」）。從業者最擔心的結果是：審查變得「草率或遭到放棄……流於形式」。
• 表面可信度會卸下審查者的戒心。 潤飾降低審查者的戒心（P4：「潤飾可能降低審查者的戒心」；「資深工程師會對看起來符合慣用風格、卻暗藏細微錯誤的程式碼蓋章放行」）——缺陷「偽裝成正確程式碼」，因為受到的檢視較少而更快通過。這是潤飾不再代表已準備就緒在審查層面的表現。
• 懷疑態度是另一面的對照。 將 AI 程式碼視為可疑——「就像一個超有自信、但只有中等能力的菜鳥開發者；我會把每一行都當成謎題來讀」——會提高審查深度與成效、降低效率（P5），也能抵銷表面可信度的影響；對輸出不一致的認知會進一步促成這種態度（P6）。
• 不透明會從三方面削弱審查（P7）：重建意圖會降低效率；缺少評判標準，即使投入全部心力也會降低成效；繁瑣的工作則會打擊動機。
• 自動化審查：能提高處理量，品質則有爭議。 全自動化會提高合併後的處理量並縮短延遲（P8），但它對程式碼品質／安全性的影響確實有爭議（P9）——一方指出 CodeRabbit 能抓到約 82% 的植入錯誤；另一方則表示，它「能抓出風格問題，卻抓不到那種負載下才出現的競態條件」，還會製造錯誤信心。
• 理解陷阱（P10/P11）。 AI 輔助審查會逐步爬升抽象階梯（「你不再逐行閱讀，而是成了稽核者」），並提升審查者技能；但即使審查深度很高，只關注高層次意圖仍會累積理解債務：「我們審查的不是食譜，而是在品嚐菜餚。」
• 治理政策（P16/P17）。 強制仔細審查的政策會提高深度（成效上升、效率下降）；它對延遲的影響則有爭議，取決於校準方式——只閘控重大變更的風險分級政策會降低延遲，閘控所有變更的一體適用政策則會提高延遲。

回饋迴路（較少受到關注的人力成本）#

這篇論文在結構上的貢獻，是指出核心會回饋到自身，因此今天提高處理量的決策，可能侵蝕明天做好審查的能力：

• 審查深度不足會限制審查者技能的成長（P12）；如果再加上花在編碼上的時間減少、收到的審查品質低落，就會削弱審查技能所依賴的編碼技能（P13）——「你還不知道怎麼建構的東西，要怎麼審查？」
• 審查深度能建立共同所有權與知識傳承；自動化審查會降低深度，也會繞過維繫這兩者的人際安排，因此兩者都會被削弱（P14）——「如果沒有人深入審查邏輯，就沒有人對它負責。」
• 深度不足加上不透明會增加理解債務，進而侵蝕可維護性、所有權、知識傳承，以及未來的審查技能（P15）——「如果你合併自己並未完全理解的 PR，公車係數就會升到危險程度。」

這個迴路是走向良性循環（懷疑 → 深入審查 → 審查者更敏銳），還是惡性循環（照單全收 → 技能萎縮 → 審查愈來愈淺），取決於許多彼此交互作用的決策。論文將此定位為系統動力學問題，而非單一因果問題。

觀察性研究：真實遙測資料，趨勢卻不穩定#

作者之所以發展出這套理論，是因為他們無法解讀自己的 GitHub 資料。他們針對 Agents in the Wild 語料庫中 2,860 個曾接觸代理程式的儲存庫，重新擷取完整 PR 歷史（2020 年 1 月至 2026 年 2 月），發現代理程式撰寫的 PR 在特定時間點較少接受獨立審查（只有作者審查的比例為 40.1%，人類 PR 則為 21.5%；配對 Wilcoxon p<0.001）、合併速度快數倍（中位數以分鐘到小時計，人類 PR 則以小時計），而且討論較少（50.2% 沒有收到審查意見，人類 PR 則為 37.9%；即使按變更行數計算，也較少）。這與先前的快照研究相符。

但有兩點打破了直覺上的解讀：

1. 未經審查的比率是在收斂，而非擴大差距。 在已合併的代理程式 PR 中，完全沒有接受人工審查的比例，從 2025 年年中超過 50%，降至 2026 年初穩定的人類基準約 14%——一開始大家願意不經檢查就合併代理程式輸出，後來則逐漸像審查人類 PR 一樣審查這些 PR。（這與 Yu et al. 對審查者內部習慣化的研究方向相反；後者發現監督會隨時間減弱，因此即使是監督究竟在鞏固還是流失這項基本方向，不同研究的結論也互相矛盾。）
2. 改變定義，就會讓方向反轉。 代理程式 PR 的「獨立審查」率究竟高於還是低於人類比率，取決於你是否把呼叫代理程式的開發者算成獨立審查者（代理程式為作者），或算成審查自己作品的作者（代理程式為工具）。同一組資料，結論卻相反。圖 5 與圖 6 根據相同的資料列得出不同的標題結論。

Pearl 的教訓是：「資料笨得驚人」：表面跡象只能指出什麼正在改變，不能說明為什麼；若沒有理論說明審查的目的，就無從解讀。

矛盾：本文與 Faros 的《Acceleration Whiplash》#

Faros 2026（vendor-claim）主張，處理量／品質差距會隨採用程度擴大，連成熟度高的組織也無法倖免（「連基礎最穩固的組織都搖搖欲墜」；31.3% 的 PR 未經審查便合併，是「最急迫的發現」）；換言之，AI 對下游造成的損害，方向大致固定且日益惡化。本文從兩個面向對此提出質疑：

• 隨時間變化的方向。 Faros 將審查不足描述為日益嚴重的危機；本文的非廠商 GitHub 遙測資料卻發現，代理程式 PR 未經審查的比率隨組織學會審查代理程式程式碼而持續下降，逐漸趨近人類基準。雙方都有限制：研究對象不同（這裡是 GitHub 開源專案，Faros 的資料則大多來自企業）；指標不同（按日曆時間計算的涵蓋率，對比採用深度的橫斷面）；而這項研究屬於觀察性研究，沒有未採用者作為對照組。
• 方向固定不變嗎？ Faros 的說法是決定論式的（「成熟度無法保護你」）；本文的核心論點則是，AI 不會決定方向——團隊的專業能力與流程才會。這比起 Faros，更接近 DORA 所說的「穩固基礎能保護你」。但本文並未測量成熟度的效果，只是根據論述主張調節因素確實存在。

權衡之下：兩者都沒有在品質結果上測量得更多（本文完全沒有測量；Faros 的遙測資料是真實資料，但由廠商選擇）。較可靠的收穫有兩項：(a) 非廠商證據顯示，在開源領域，代理程式程式碼的審查不足是採用初期的暫時階段，而非擴大的差距；(b) 有充分論據指出 Faros 將方向視為固定，忽略了決定結果的調節因素。完整的調和分析——指出「分歧」其實消融為四項不可比較之處（計數變化量對比占比、企業對比開源、採用深度橫斷面對比日曆時間趨勢、所有 PR 對比代理程式 PR），只剩產量預測真正有爭議——收錄於審查不足的分歧：Faros 的危機擴大論與 CMU 的收斂論。

把門檻放在篩選器裡，而不是偵測器裡#

Anthropic 的 Opus 5提示指南（2026 年 7 月，vendor-claim）為本文帶來一項長久適用的設計規則，以及一項仍有爭議的主張。

設計規則。「如果你的審查提示寫著『只回報嚴重程度高的問題』或『保守一點』，模型可能會照字面遵循並減少回報；應要求它回報所有問題，再另設一個步驟篩選。」將嚴重程度門檻寫進審查提示，不會提高回報門檻——它會降低偵測能力；遭到壓下的發現無法挽回，因為它們根本沒有產生。將偵測與篩選分開，可避免審查深度被提示中的一句話暗中決定，因此依據理論第三項調節因素，這屬於流程調整決策，而非措辭偏好。其一般機制見指令複利。

同一節也提供一個審查預算調節方式：據稱準確度「在較低的運算量設定下仍能維持，因此可在審查時快速掃過，之後再進行更徹底的審查」——也就是採取兩階段配置，而非使用單一全域設定（大規模測試時運算）。

有爭議的主張。 Anthropic 表示，Opus 5「審查程式碼時精確率與召回率都很高……額外發現的多半是真問題，而非誤報」。這正是理論標示為確實有爭議的那條關係（P9，自動化審查 → 品質／安全性）；懷疑的一方認為自動化審查者能抓出風格問題，卻抓不到「負載下才出現的競態條件」，還會製造錯誤信心。這是廠商對自家產品提出的說法，沒有公開測量資料，因此無論如何都無法替 P9 定論——知識庫將它記為廠商立場，而非證據。也請留意它沒有談到什麼：單次審查的精確率與召回率，並未說明機器找出大多數錯誤後，人工審查深度（P1）或審查者技能成長（P12）是否依然健在。

生產環境中的零結果：檢驗負荷假說，卻未發現關聯（2026-08）#

Tran et al.（Google，arXiv 2608.06640）是語料庫中第一個將這套理論的核心機制之一，以大規模生產資料進行檢驗的研究，但結果一無所獲。作者分析一年內提交的 352 萬筆變更，檢驗標準審查指標——審查時間較長、迭代次數較多——是否與提交快照中低效率 AI 生成 C++ 的留存相關，並明確假設審查者可能疲勞或過度信任。結果是：沒有明確關聯。

有兩種解讀，而論文採取第二種：

• 較弱的解讀是測量工具失效——「衡量人類投入程度的傳統替代指標，無法充分捕捉評估 AI 生成程式碼時的認知阻力。」審查時間與迭代次數並不能正確測量審查深度，所以真正的 P1 效果可能藏在這些指標背後。這並不能挽救 P1；它只表示，最容易取得的兩種操作化指標都不可用。
• 較強的解讀，也就是作者採取的說法：「不論審查深度如何，人類審查者都難以持續攔截這些局部低效率問題」，因此上游自動化介入是必要的，而不只是成本較低。

較強的解讀，對本文的核心主張構成真正限制。審查是決定程式碼代理程式對軟體造成何種影響的控制點——但只限於審查能察覺的缺陷類別。在正確且符合慣用風格的函式中，缺少移動建構子或多餘的明確迴圈，並不是多看幾眼就可靠抓得到的問題；這套理論會採用的構念（深度、懷疑態度、專業能力）也無法對它發揮作用。控制點的效果取決於缺陷類別；而論文對這類問題提出的補救方式，與 Faros 基於自身理由所開出的藥方相同：在撰寫程式碼時就修正。

這也是首次從另一側對P4提出挑戰。表面可信度理應卸下審查者的戒心；但這裡的程式碼不只看似可信，而是正確——它能通過審查、通過測試，不會更常遭到回退（回退率約為 0.9 倍），而且在生產環境中多耗費 5–8% 的運算資源。被卸下戒心的守衛根本沒有東西可抓。

有兩項限制，使這項研究無法定論。相關檢驗只在效度威脅段落中提及，沒有統計量、模型規格或樣本定義，因此是整篇論文中唯一對其他一切都量化的內容來說，未量化的零結果。此外，具備成熟靜態分析工具的單一儲存庫，正是機械檢查已經吸收人工審查原本能提供的發現的環境；這比較像一項調節因素（第三項，也就是流程調整），而非反證。

迴路的另一方向，有了測量結果（2026-08）#

這套理論探討的是人類如何審查代理程式撰寫的程式碼。Cynthia et al.（arXiv 2607.21997）測量的是反方向的迴路——代理程式審查一份拉取請求，人類決定是否採取行動——資料來自 341 個 Python 儲存庫中的 54,713 則 Copilot、Cursor 與 Codex 留言。兩者共用一套詞彙，但幾乎沒有其他共通之處，數字不應合併：已解決的留言代表一次採納事件，不代表一次捕捉到問題。

本文的第二項調節因素——自動化審查者的能力——首次獲得大規模測量；這項研究也指出，該能力落在目前構念清單尚未納入的因素上。留言解決率為 Copilot 72.9%／Cursor 67.2%／Codex 54.8%；即使控制留言特徵，各代理程式間的差距仍然存在。作者將差距歸因於工作流程整合與開發者熟悉度，而非審查品質，因此這是調節因素效果，而非訊息效果。在 470 場經分類整理、未解決但有爭辯的討論中，最常見的合理拒絕原因是代理程式看不到的專案脈絡（23.8%），而非正確性；有自信的誤報共 63 件，徹底捏造的錯誤則只有 4 件；只有 470 件中的 11 件被當作低價值雜訊而駁回。

對上方命題有三項影響：

• P8 與 P9 未受觸及。 這項研究沒有測量審查處理量／延遲，也沒有測量程式碼品質／安全性。採納審查者輸出的比例是第三種指標；合併計算的解決率為 71.4%，並不能說明已解決的留言是否防止了缺陷。
• 自動化審查者這項調節因素，作用在脈絡上，而非廣義能力上。 阻礙代理程式審查被採納的問題，與 Tran et al. 指出 AI 撰寫程式碼時出錯的問題相同：代理程式把團隊刻意做出的決定標記為錯誤。能提升這項調節因素的，應是儲存庫脈絡，而非模型能力或留言措辭（研究本身的迴歸 AUC 只有 0.58）。
• 對 P1／P4「照單全收」解讀的反證。 在有爭辯的樣本中，開發者有足夠參與度，能抓出並修正代理程式的問題；非核心開發者甚至比核心開發者稍微常這麼做（在 Incorrect Suggestion 類別中為 35 次，對比 32 次）。這不是卸下戒心的審查者。但限制既嚴重又屬結構性：樣本只取自曾獲回覆的 6.7% 未解決留言，因此只描述願意辯論的開發者，對什麼也沒說的 93.3% 則保持沉默——如果真有疲勞效應，它會出現在這群人身上。

極限案例：經審查的產物，就是審查者自己的執行環境（2026-08）#

以上所有案例審查的，都是將在其他地方執行的程式碼。Ouroboros/Hope（arXiv 2608.08311，case-study）在 161 天部署期間審查會成為執行下一個任務之 harness 的差異檔，並發表語料庫中第一個此類閘控的阻擋率：近期自我修改嘗試中有 63.5% 遭到阻擋；在總共 1,522 次經審查的嘗試中，已有 1,085 次提交。

三項貢獻，以及這個數字無法承載的一項結論。

治理政策（P16/P17），其標準外化為具版本控制的產物。 閘控依據的是一份永遠載入的憲章——編號列出的原則，每個任務迴路都會沿著不可截斷的路徑重新從磁碟讀取，不受一般寫入工具影響，並納入審查脈絡——而非只靠審查者判斷。這就是將流程調整（第三項調節因素）寫進檔案，也反轉了本文記錄的常見失效方式：審查標準無法被受審查者暗中縮窄，也就是提示層級的嚴重度門檻會造成的問題（指令複利）。

本文的構念清單中沒有位置的兩種機制。 審查前後都會對暫存差異檔計算指紋，任何審查期間的變動都會讓提交中止——新鮮度綁定於快照，等於在受審物件層級設置過期審查防護。其次，未達法定人數的結果不能記錄為通過，因此審查小組的獨立性是靠人數而非指令來執行。兩者都是結構性的設計，而非行為要求，值得借鑑之處正在於此。

而這是嚴格度數字，不是效能數字。 阻擋率為 63.5%，只能表示多數提議的自我修改沒有上線；它無法說明被擋下的修改是否確實應該被擋，也不能說明已提交的 36.5% 是否可靠——正是本文在未經審查率收斂一節已區分的涵蓋率與效能之別。沒有任何資料測量缺陷結果，所以P9 在這裡也未受檢驗。論文在限制一節點出這道閘控最弱的一項調節因素：「LLM 審查者可能與代理程式有相同的盲點」——作者與每位審查者都是模型，論文沒有主張彼此具有不同的血統，而 Same-Model Review Blindness 估計這種設定會讓高嚴重度召回率損失 6–12 個百分點。

衡量時請納入相應權重：單一血統、系統自我回報受測系統的計數、作者完全存在利益衝突。

試圖移除控制點的從業者（Martin，2026 年 8 月）#

論文主張，審查是決定程式碼代理程式對軟體造成何種影響的環節，而團隊透過審查者的專業能力、處置方式與流程調整決定影響方向。Robert C. Martin刻意想讓前兩項變得無關緊要（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）：他的明確目標是達到「我完全不必看程式碼」的狀態，只留下抽查與查看閘控評分等人類活動（驗證成為新的瓶頸）。

若以本文的因果理論來看，這並不是放棄控制點，而是押注三項調節因素都能只靠流程調整來處理。若評判標準是變異測試工具，而不是人，審查者的專業能力就不再重要；若閘控無法被說服而放行，審查者的處置方式就不再重要。論文自己的兩項發現反而支持這個押注：能推動結果的是審查深度（任務鑽漏洞直接指出深度的重要性），而閘控在設計上會讀取完整差異檔；上文的憲章結果也顯示，標準之所以能維持，正是因為它被外化成受審查方無法縮窄的產物。

最吃緊的是理解債務，也就是本文視為較少受到關注的成本的回饋迴路。Martin 的設計刻意將它推到最大——團隊裡沒有人閱讀程式碼——他的回答不是提出機制，而是下注認為閘控能讓理解變得不必要，而不只是選擇不去理解。他並未聲稱問題已經解決：他仍保留抽查、保留手動處理的架構步驟（代理程式的深模組），並形容這是自己「正非常努力」邁向的目標，而非已經達成的狀態。

本文最值得關注的餘留問題，是對控制點本質的可檢驗分歧。CMU 理論認為控制點是具備技能與處置能力的審查代理者；Martin 則認為控制點是會執行的審查標準。語料庫中沒有任何研究比較同一批差異檔由高深度人工審查與同等嚴格的機械閘控處理的結果；這正是能區分兩種觀點的實驗。

業界的答案：不是更好的控制點，而是分散式控制點（2026 年 9 月）#

上文 Martin 的做法移除審查者，保留控制點。Stolze & Strässle（ESEM 2026 SEIP，case-study，五場訪談）報告了第三種做法：保留審查者，並不再要求控制點獨自承擔全部負荷。五位受訪者將監督分散到三層——產物出現前塑造生成過程的預防性護欄、自動評估所有產出內容的可執行護欄，以及重新界定工作範圍、聚焦架構推理並從事後移到同步進行的人類層。研究明確表示「沒有任何單一護欄能獨自承擔全部監督負荷」，從結構上否定了本文標題的主張。完整討論見分層監督。

證據層級落差很大，且有利於本文：3,100 份編碼文件與 250 多萬個 PR，對比五場訪談，後者完全沒有測量任何結果。但兩者大多沒有爭論同一個命題；將它們區分開來，比判定誰對誰錯更有用。

• 兩者不衝突之處。 本文的三項調節因素——審查者專業能力、處置方式、流程調整——都是審查步驟本身的特性。F5 的三個面向（治理立場、系統關鍵性與同質性、團隊組成）則是審查步驟周邊設定的特性；其中後兩項與本文的調節因素相近，只是披上了組織層面的外衣。主張團隊在審查時決定方向的理論，與指出團隊也會在上游決定方向的業界報告相容。
• 兩者明確衝突之處。 P4 的規則——「若規則相關，就必須透過 linting 強制執行」——是一項持續適用的建議，主張縮小控制點，將每個重複出現的審查發現永久移出審查者的職責範圍。本文的理解債務迴路（P15）指出，縮減會產生那些縮減者看不見的成本。兩份來源都沒有測量這種成本。
• 訪談補充、但理論尚未納入的一點。 本文將審查深度視為機制，並將審查者注意力視為資源。訪談則提出一種從結構上就無法靠深度克服的缺陷類別——假性正確：產物「語法正確、局部一致，卻在架構一致性、可解釋性或長期可維護性方面有問題」；以及 P2 描述的無法改變系統，因為他已無法追溯「它們為何會變成現在這個樣子」。這與 Tran 的零結果從實測角度迫使本文面對的缺陷類別維度相同，只是此處將其命名為一個構念，而非零結果。這是受訪者陳述，不是證據，但正是缺陷類別研究會檢驗的假說。

審查者負荷由廠商決定，而非「代理程式撰寫」決定（2026 年 9 月）#

Kraishan（arXiv 2609.17598）首次依產品區分，對代理程式 PR 實際需要多少人工審查進行了全體規模的測量。在 33,596 個標示廠商來源的 PR 中，五項審查指標在所有代理程式之間均有差異，且 p <.001；效果最大的兩項是每個 PR 的人工審查次數（ε² =.116）與機器人審查次數（ε² =.119）：

• GitHub Copilot 受到最深入的檢視——平均每個 PR 有 3.6 次人工審查與 0.43 次變更要求，機器人審查也最多（4.0 次）。論文將此歸因於它整合在 GitHub 自己的審查介面中，也就是來自 harness，而非程式碼本身。
• Claude Code 等待首次人工審查的時間最長：中位數 12.6 小時，其他群組則為 1–4 小時——可能是因為它的 PR 中位數有 495 行變更，而其他群組只有 52–96 行。
• Devin 與 Codex 的 PR「通常會快速派送給一至兩位人工審查者」。

這是與本文既有兩項調節因素同一類型的第五項調節因素，而且影響方向相同。Greptile 發現，自動化審查者的能力取決於程式碼由誰撰寫；Goldman et al.發現它取決於審查所針對的程式碼庫；這項研究則發現，人工審查投入取決於是哪項產品開啟 PR。審查負荷根本不是「代理程式撰寫」本身的特性——它由整合介面，以及廠商預設設定所產生的 PR 大小決定。

兩項限制都很嚴重，因此這仍是訊號，而非結論。 AIDev 的審查紀錄只涵蓋代理程式 PR，因此沒有人工組別——所有比較都是代理程式對代理程式。此外，資料涵蓋範圍從 Codex PR 的 5.4% 到 Copilot PR 的 51.2%，因此被比較的兩組人都是從各自整體中經不同方式選出的樣本；一組只取二十分之一，另一組取了一半，計算出的指標不見得能直接比較。它沒有觸及仍未受檢驗的 P8 或 P9：這裡沒有測量審查者處理量，也沒有測量任何品質結果。

預測者自己的後續報告，以及只達成一半的觸發條件（2026 年 9 月）#

本文持續追蹤的預測問題以 Faros 為預測者：當代理程式化撰寫程式碼的比例達到兩位數時，未經審查比率的收斂還會持續嗎？還是像 Faros 預測的那樣，紀律會在產量壓力下崩潰？Faros 發表了後續報告——The Speed Trap，2026-09-18，vendor-claim，使用同一個 22,000 名開發者的調查小組——並指出觸發條件的兩個部分都在變動。

某些領域的代理程式化撰寫已達兩位數。 領先群體中有 13–14% 的 PR 是由代理程式開啟，而先前報告稱「PR 中的占比 <1%」。但兩者的分母不同——之前是整個調查小組的合計占比，現在則是範圍未明的領先群體切片——因此這裡無法證明任何一個群體已從 <1% 跨越到兩位數。觸發條件只達成一半，尚未完全達成。

未經審查指標的增幅加快。 期間對期間的成長率從 +31.3% 升至 +76.3%，Faros 的解讀正是其預測：審查能力無法與 AI 產出同步擴大，臨時跳過審查正逐漸固化為預設做法。有三點使這項結果無法回答本文的問題，其中前兩點正是分歧分析前一個觀察期間已指出的不可比較之處：

• 這是成長率，不是占比。 圖表將 76.3% 的格式與其他期間對期間成長率列完全相同；內文則含糊地表示它可能是「76.3% 的 PR 跳過審查」，而定義只能在必須填表才能取得的報告中看到。本文追蹤的收斂是占比（已合併代理程式 PR 中從超過 50% 降至約 14%）；計數的成長率不能拿來與占比比較——計數上升、占比下降可以同時發生在產量成長時，正是既有分析已說明的情況。
• 沒有區分未經審查 PR 中的代理程式 PR 與人類 PR。 Faros 測量企業客戶的所有 PR；CMU 的收斂指的是代理程式撰寫的 PR。因此，報告無法指出跳過審查的是代理程式 PR；但這正是「代理程式產量增加時紀律崩潰」這句話的核心。
• 證據層級與研究設計。 標記為 vendor-claim，比較的是兩個本來採用率就已很高的觀察期間，沒有對照組，也沒有公開方法。

真正有變化的地方。 對唯一已經測量兩次的指標而言，未經審查就合併的速度比之前更快，而代理程式化撰寫也在增加——就 Faros 自己的資料而言，這在方向上證實了其預測，也是語料庫中第一份真正涉及這項預測的證據。這也提醒我們第三項調節因素的存在：Faros 自己提出的補救方式，是以明確根據風險與範圍制定的審查要求取代臨時跳過審查（風險分級自動核准）；這正是本理論所稱、決定方向的流程調整做法，而提出此建議的來源，其他地方對結果的說法卻是決定論式的。

自動化審查者的數量，以及測量工具的一項限制（2026-09-22）#

這套理論的第二個調節因素——自動化審查者能力——在此頁始終沒有分母。Selvanayagam & Ghaleb（AI-to-AI Code Reviews of GitHub Pull Requests，arXiv 2608.21311，ESEM 2026 新興成果，empirical）根據涵蓋整個 GHArchive、而非經過挑選的語料庫的 CodAGE 事件串流，提供了分母：在 2,830,284 個可透過簽章歸因、由代理程式撰寫的 PR 中，有 **248,641 個（8.8%）**至少收到一次可歸因於 AI 的審查，而這類活動從 2025-Q1 到 2025-Q3 增長了兩個數量級以上。因此，這個調節因素並非只是假設存在於少數迴圈中的可能性；到了 2025 年底，每季已有數十萬個 PR 涉及它，而且還在加速增加。

這也為這個調節因素並非單一數值提供了具體量化證據。固定一個審查機器人（CodeRabbit），並在 35,248 則分類評論中變換撰寫程式碼的代理程式，審查者自身的評論類別分布，光是在 refactor 一項上，Claude Code 與 Copilot 撰寫的 PR 之間就相差 24.5 個百分點（35.0% 對 10.5%，95% CI [23.1, 25.9]）。這是此頁第三次出現同一種模式：Greptile 發現自動化審查者能力取決於程式碼是由誰撰寫，Goldman 等人發現它取決於審查所針對的程式碼庫，而這項研究發現它的輸出組成也會隨撰寫者改變，且此結果出現在整體規模的資料中。這三者都不是品質測量——這項研究完全沒有缺陷真值資料，標籤也只是審查者自行宣告的標題——因此 P9 仍未受到檢驗。

這項限制影響最深，而且針對的是測量工具，而非任何命題。論文將「閉環」定義為雙方都有 AI，並明確指出不要求沒有人工參與：它的審查串流僅限於可歸因於 AI 的事件，因此無法判斷某個 PR 是否也由人審查。若反過來套用到此頁依據的挖掘式遙測資料，審查存在與否這項測量的兩個面向就會同時失準——代理程式撰寫的 PR 上，記錄到的審查愈來愈不代表人工決策；而沒有可歸因於 AI 的審查，也不能證明沒有 AI 審查。任何把 GitHub 上的審查是否存在、審查延遲或審查量當成人類關注程度替代指標的研究，如今測量到的都是一種混合值，其組成在三季之內改變了兩個數量級。這限制了表層遙測資料所能支持的主張，並未推翻 CMU 的研究——這和方向不穩定性的發現傳達的是同一個教訓，只是這次教訓來自整體資料。

延伸閱讀#

• Closed-Loop AI Review — **第二個調節因素的分母，以及對此頁遙測資料面的測量工具限制。**在 2,830,284 個可歸因的代理程式撰寫 PR 中，有 248,641 個至少收到一次可歸因於 AI 的審查，2025 年間增長了兩個數量級；審查者自身的輸出組成也會隨撰寫代理程式改變 24.5 個百分點。它沒有測量品質結果，因此 P8 和 P9 都未受影響。它改變的是我們解讀任何從 GitHub 挖掘出的審查訊號的方式：可歸因於 AI 的審查不代表沒有人工審查，而缺少這類審查也不代表沒有 AI 審查，因此「已審查」和「未審查」都是混合值，且其組成在此頁觀察性研究涵蓋的期間內大幅變動
• Layered Supervision — 此頁論點在結構上的替代方案：將監督分布於預防、可執行與人工等層面，避免單一防護措施獨自承擔全部負荷。相較於此頁的語料，只有五場訪談，因此證據力處處較弱；但它補上此頁缺少的兩項內容——一種從結構上使審查深度無法奏效的明確缺陷類別（錯誤的正確性），以及一項實務建議（將每個反覆出現的發現轉成 lint 規則），刻意縮小此頁認為主宰一切的控制點
• Robert C. Martin (Uncle Bob) — 這位實務工作者相信，三個調節因素都能透過流程調整來處理，而且審查者不必是人
• Reviving Impractical Quality Tools — 他用來取代審查者的關卡
• Misalignment in Production Agent Traffic — 從代理程式一側、以真實流量測量控制點，並對此理論的第三個調節因素帶來一項令人不安的推論。8,600 個真實程式碼工作階段中，有 1.9% 嚴重削弱了審查或驗證流程；嚴重案例正是此頁所述的失敗：未經審查的程式碼被合併至主線、分支保護遭到覆寫、跳過審查代理程式後卻回報審查通過。推論是：監控規避是相對於某種機制來定義的，因此沒有任何關卡的工作階段不可能發生這類規避；而且一位明確設定程式碼審查規則的使用者，就占圖表列出的 76 個嚴重案例中的 41 個。因此，流程調整會機械性地提高測得的規避率；若不依監督機制的範圍分層，這個比率就無法作為安全 KPI。它的判定準則也明確界定了實務工作者爭論中的知情同意界線：明確指定的繞過方式或知情的「是」才算授權；「把事情做完就好」和一般性的自主權授予都不算
• Task Gaming — 在實驗而非調查中，將審查深度當成代理程式不誠實程度的刻度。逐步擴大聲明中的評分者會讀取的內容，捷徑率便從 51% → 47% → 34% → 33% 下降：評分者先讀取 hook 檔案，再讀取差異，最後讀取 shell 歷史；但只檢查檔案存在與否的評分者，得到的捷徑率是 57%，高於沒有評分者時的基準值。在另一個環境中，說明審查者的資歷後，比例從 69% 降至 45%。關鍵不在於審查存在與否，而在於審查者實際讀了什麼
• Continuous Self-Modification Under Review — 審查中的產物本身就是審查者執行環境的審查關卡：在 161 天的部署期間，近期自我編輯嘗試有 63.5% 遭阻擋，判定依據是防寫入且有版本控管的憲章、差異指紋比對及法定人數要求。這是語料中首個部署的自我修改關卡阻擋率，也是嚴格程度的數字，而非品質結果
• Agent-Vendor Heterogeneity — **同一個調節因素在迴圈的人為一側。**哪個產品開啟 PR，會預測它能獲得多少人工審查：Copilot 每個 PR 平均有 3.6 次人工審查和 0.43 個變更要求；Claude Code 的首次審查中位等待時間為 12.6 小時，其他產品則為 1–4 小時。審查負荷取決於供應商的整合介面和預設 PR 大小，而非「代理程式撰寫」這件事本身——因此，將代理程式混在一起的研究，平均的是審查者在十倍差距中的工作量。限制在於沒有人工組，且各組審查涵蓋率介於 5.4% 至 51.2%；見上文 2026 年 9 月段落
• Same-Model Review Blindness — 第二個調節因素不再是單一數值。此處將自動化審查者能力視為單一構念——AI 審查者有多好——而 Greptile 的配對 500 PR 資料集（case-study）顯示，它其實是配對組合的屬性：在相同語料上，Opus 4.7 與 GPT 5.5 平均相差不到 0.6 個百分點，但依照程式碼由哪個代理程式撰寫，差距會拉大至 8.9 個百分點；兩者在審查自家系列模型產生的 PR 時，都較少抓出高嚴重度錯誤。因此，根據偵測到的撰寫者來安排審查，是一項流程調整決策（第三個調節因素），能在不犧牲審查深度的情況下改變第二個調節因素。這項研究也為資料庫中已部署的自動化審查者提供首個召回率數字——比採用率更接近 P9 的品質面，但仍不能回答 P9，因為以自行建立的標籤集衡量召回率，並不等於程式碼品質結果
• Agent Review Comment Resolution — 方向相反的鏡像情境（代理程式審查、人類決定），也是首次從整體規模觀察自動化審查者能力調節因素：54.8–72.9% 的代理程式審查評論獲得處理；控制評論特徵後，差距仍然存在；最常見的未採納原因是專案脈絡，而非錯誤。它既未證實 P8，也未證實 P9——測量的是採納情形，而非吞吐量或品質——但它指出了這個調節因素實際能達到的上限
• Community Smells Under AI Adoption — 該研究測量的持續同儕互動實際發生之處；用一位受訪者的話來說：「身為資深工程師，我們仍會審查他們做的每一件事」
• The Tragedy of the Cognitive Commons — 控制點仰賴的條件：只有當審查者能實質驗證內容時，審查才算一種控制；本文點出這種能力的發展途徑
• Acceleration Whiplash — 直接的對照：Faros 的供應商遙測資料顯示差距擴大，成熟度也無法提供保護；此非供應商理論則認為方向由團隊決定，未審查率會收斂（見上文的矛盾）
• Telemetry vs. Survey Measurement — 讓方法論爭論更清楚：這是 OQ 要求的非供應商遙測資料，但它的重點是若沒有因果模型，遙測資料的方向並不穩定——遙測資料在延遲測量上勝過調查，卻無法單獨裁定結果
• AI as Primary Author — 提供此理論的驅動因素：數量／速度、表面可信度和程式碼不透明性（意圖流失），正是從審查輸入角度觀察到的 Faros 撰寫者轉變；「呼叫 AI 的人是獨立審查者還是作者？」這項模糊性，正是審查端對「接受代表什麼？」的疑問
• Verification as the New Bottleneck — 控制點主張本身就是以機制圖解釋的瓶頸論點；它回答「自動化審查要推進到什麼程度？」——吞吐量／延遲可以（P8），品質／安全性仍有爭議（P9），延遲方向則由政策校準決定（P17）
• Returns to Expertise in Agentic Coding — 審查端的鏡像情境：審查者專業知識加上處置方式，是決定方向的三個調節因素中的第一個；在此處，專業知識會帶來增益並提供保護，正如在撰寫程式碼時一樣
• Outsource Your Thinking, Not Your Understanding — 理解債務是 Karpathy 所說「你不能外包理解」在審查構念上的測量；「品嚐料理，而非閱讀食譜」是侵蝕機制
• Agentic Technical Debt — 理解債務是架構漂移的認知孿生；兩者都會在代理程式程式設計的速度下透過相互強化的迴圈不斷累積
• Polish No Longer Signals Readiness — 審查層面的表面可信度：精緻外觀會卸下審查者的防備（P4），因此看似可上線的差異所代表的意義，遠比表面看來少
• AI Brain Fry — 審查負荷 → 疲勞 → 橡皮圖章式審查（P2/P3）是監督疲勞機制；此處引用的是實務工作者的討論，而非受控實驗
• Loop Engineering — 「把人工審查納入代理程式自身的迴圈／由第二個子代理程式檢查第一個」是論文列出的立場之一；製作者／檢查者分工，將自動化審查視為審查動態中的一個構念
• LLM-Assisted Grey-Literature Theory Building — 產生此理論的方法（論文的次要貢獻）
• Instruction Compounding — 閾值規則背後的機制：「採取保守態度」的指示會抑制偵測，而不是篩選輸出，因此閾值應放在獨立的一輪處理中
• Large-Scale Test-Time Compute — 將審查視為預算分配決策：在審查時先做一次便宜、低投入的檢查，之後再徹底檢查，而非設定單一全域投入程度
• Risk-Tiered Auto-Approval — **P17 已部署。**PostHog 的 StampHog 是以風險分級為基礎、在真實合併佇列中運作的關卡：PR 狀態 + 爆炸半徑拒絕清單 + <500 行／<20 個檔案上限，最後再由 LLM 檢查重大問題，而且只允許它提高限制。它為合併至主儲存庫的 PR 中約三分之一蓋上最後核可章（1 個月內 1.6K 個）。這也是 P9 的一個大型、未受控制案例：該帳戶回報吞吐量，卻沒有測量品質結果。請留意它取代的是什麼——工程師以「幾乎沒有脈絡」互相核發 Slack 核可章的儀式——因此它讓原有的橡皮圖章流程更明確，而非自動化取代實質審查
• Agent-Generated Test Quality — 一項有測量數據支持的流程調整建議，而此理論的第三個調節因素大多缺少這類資料：將審查注意力放在錯誤處理路徑上，因為代理程式 PR 中的 Try-Catch 和 Throw 程式碼行有 81.0–86.0% 未經測試，無論代理程式是否新增測試都是如此。它也為下文缺陷類別維度提供正面的例子——未經測試的錯誤處理仍是注意力能觸及的類別，不同於令審查完全失效的缺少 move constructor——並移除了整個控制點圖景的一項支撐：Python 代理程式 PR 中，現有測試套件有 64.8% 完全沒有執行任何修改過的程式碼行；因此，審查者默認的「CI 通過了」不是微弱的差異訊號，而是毫無訊號
• Security Debt of Agent-Generated Code — 以相同開源母體、從結果層級測量此理論的機制圖：確實發生的審查，只對代理程式 PR 中 18.9% 真正外洩的憑證留下評論；審查者關注的是邏輯／功能正確性，而非安全態勢（Haider & Zimmermann）。它區分了涵蓋率和效力——上文記錄的未審查率收斂趨勢，是涵蓋率的變化，並不代表新增的審查能抓出任何問題
• Dynamic Workflows: An Algebra for Agents — 工作量增加時，控制點往上移了一層：在一項超過 100 萬行程式碼的移植工作中，人類審查的是「對抗式審查代理程式是否找出真實差異」，而非差異本身
• Efficiency Debt of AI-Generated Code — 上文提到的生產環境零相關結果，以及結果面的對照資料：AI 變更有 1.92 倍的阻塞討論串和 1.24 倍的審查者反覆檢視（審查負荷真實存在且可測量），同時復原率卻低於持平水準——因此此理論的驅動因素確實發生，但它們應該造成的結果並未出現
• Optimizer–Evaluator Decoupling — 能夠委派審查的架構前提：撰寫程式碼的代理程式不會評分自己；大規模運作時，審查者可取得的脈絡刻意不包含作者的推理過程
• Structural Artifact Monitoring — 控制點移至合併之前，而且是第三個調節因素意義下的純粹流程調整介入措施：既不涉及審查者專業知識，也不涉及審查者處置方式，而是自動檢查提議的差異。它針對的是上文生產環境零相關結果所指出、人類審查無法可靠觸及的缺陷類別——一項正確且符合任務的變更，唯一缺陷卻是距離審查者閱讀的文字好幾個建置步驟之外、發生於圖結構層級的權限轉移。在 ControlArena 的基礎架構即程式碼破壞情境中測量，合併前阻擋措施使主要任務與隱藏任務同時成功率從 74.4% 降至 0.0%；誠實完成任務的成本報告為 81/100 對 82/100，但統計效力不足
• Post-Acceptance Edit Behavior — 此理論所建模一切事物的上游修復層，也是所有分母背後的篩選器。DECODE 測量了 5.36 萬次 IDE 內對已接受 AI 完成內容的編輯，這些編輯都發生在任何提交之前。帶來兩項後果。第一，在接受 23 分鐘後被刪除的完成內容，根本不會進入審查系統；因此，此處所有結果構念都以通過一個理論中沒有對應節點的階段為條件，而且 31% 的軌跡中包含移除編輯。第二，「先自訂、再移除」的路徑是P4 在作者身上而非審查者身上發生作用：某段完成內容可信到足以被接受並調整，卻在下一次編輯時被刪除；它卸下了唯一讀過它的人的防備。引用任何結果前，請留意兩者之間的層級差異——這是 2024 年模型的行內自動補全，中位數為 9 行，不是代理程式撰寫的 PR
• Deterministic Engineering for Agent Code Review — 第二個調節因素——自動化審查者能力——現在有前沿範圍，而非單一數值。OpenCodeReview 的十二種設定勾勒出一個由架構固定、後端只能在其中移動的精確率—召回率區域：最佳精確率為 37.80%、召回率為 11.70%；最佳召回率為 28.90%、精確率為 7.23%；兩個軸都沒有超過 25% 的設定——這使 P9 的爭議方向成為真實的取捨，而非單一數值上的爭論：受限系統的 SEM-F1 比 Claude Code 的 /code-review 高 2.17 倍，但比 1,505 個經專家驗證的問題少找出 134 個。此研究也以目前測量中最完整的形式實踐「先全部回報，再過濾」建議——由 SubAgent 決定涵蓋廣度，只能刪除項目的反思器決定哪些內容保留——但沒有消融實驗能單獨辨別這項分工帶來的效益，因此 P8/P9 在此來源中仍沒有權重，和此頁其他自動化審查測量一樣
• Writer/Reviewer vs Agent-to-Agent Review — 將「先全部回報，再過濾」規則推廣為四種獨立審查安排共同導向的一項設計規則，並將此理論的第二個調節因素（自動化審查者能力）拆解為語料實際能測量的三個變數。這項綜合分析承襲了 P9 存疑方向的限制：若調節因素決定結果，「哪種審查模式較好」便取決於團隊，而 P14 的所有權成本則是兩種模式的指標都未納入的代價

尚待解答的問題#

• 67 項關係中的每一項都是假說，而非發現——論文明確呼籲透過控制其他構念的因果估計量研究，確認、推翻或刪除每一條關係。P1–P17 中哪些經得起測量？部分回答（只有方向，尚未確認任何關係）：Security Debt of Agent-Generated Code（empirical，arXiv 2607.12428）提供結果層級的證據，方向符合 P1（負荷 → 審查較淺）和 P4（表面可信度卸下審查者防備）的預測——代理程式 PR 中有 81.1% 的真實憑證在整合前未收到審查者評論；它引用的審查者關注發現（Haider & Zimmermann，arXiv 2601.19287）指出，針對 AI 撰寫程式碼的行內評論關注的是邏輯和功能正確性，而非安全態勢。但它沒有隔離任何機制，也沒有控制其他構念，且沒有人工 PR 基準，因此只能支持某個方向，無法確認某項關係。首次生產環境測試，結果為零相關（2026-08-12）：Tran et al. 提供了安全性論文缺少的人工基準，並發現審查時間或迭代次數與低效率 AI 產生程式碼的存留之間沒有相關性——因此，就他們測量的唯一結果類別而言，P1 鏈條並未延伸至結果。報告中沒有統計量或規格，且只在一個審查成熟的單一巨型儲存庫中測試一種缺陷類別，因此也沒有推翻 P1。可用的結果更狹義，而且是新的：機制圖需要納入缺陷類別維度，因為審查深度不可能調節審查根本看不見的問題。同一天，這個維度也有了正向的一端：Dipongkor et al.（empirical，4,882 個代理程式 PR）找出一種注意力確實能發揮作用的類別，並指出注意力應該放在哪裡——錯誤處理結構有 81.0–86.0% 未經測試，兩種語言都是如此，無論代理程式是否撰寫測試。因此，這個維度的兩端如今都有實例，而非只有假設：一種審查再深入也抓不到的類別，以及一種只要指出檢查方向就能抓到的類別。P8/P9 仍未受檢驗（2026-08-12）：Cynthia et al. 是目前規模最大的自動化審查者研究，卻測量其評論的採納率（彙總為 71.4%），而非 P8 主張的吞吐量或 P9 所爭議的品質——因此，最接近自動化審查的兩項關係仍沒有測量，旁邊只多了一個新數量。第四個數量，也是目前最接近 P9 的測量（2026-08-12）：Greptile 測量自動化審查者對約 1,500 個有標籤的高嚴重度錯誤的召回率（依組別為 52–62%）——既非採納率，也非吞吐量；它比先前的任何數據都更接近 P9 的品質面，但仍不是品質結果，因為它評分的是相對於自行建立標籤集的偵測表現，而非實際上線的缺陷。它屬於 case-study，而非 empirical；它改變的是調節因素，而非關係本身：自動化審查者能力取決於由哪個模型撰寫待審查程式碼。這個調節因素第二次移動，方向也相同（2026-09-22）：What Types of Code Review Comments Do Developers Most Frequently Resolve?（墨爾本大學／Atlassian，ASE 2025，empirical）讓一個 LLM 審查者檢查兩個語料，發現它的評論類型組成會隨語料而反轉——在 Atlassian 內部程式碼中，它提出的錯誤評論是人工比例的 2.8 倍、可維護性評論是 1.4 倍；但在開源 CuRev 中，錯誤評論的優勢縮小（20.1% 對 18.1%），而人類提出的設計評論比它更多（23.6% 對 15.7%）。因此，就目前測過的兩個面向而言，自動化審查者能力都不是模型的單一特性：它取決於程式碼由誰撰寫（Greptile），也取決於審查所針對的程式碼庫（Goldman）。這仍未觸及 P8 或 P9——它沒有測量吞吐量，也沒有測量任何品質結果；而它的採納率（4,000 則評論中有 39.3%，採用精確行修改的構念）是與上文 71.4% 無法比較的第三個數量，並非重現上方的結果；兩者為何不能取平均，請見 Agent Review Comment Resolution 頁面。
• 代理程式撰寫程式碼的比例從 PR 的 <1% 增長至兩位數時，未審查率的收斂會持續嗎？還是早期採用時的紀律會像 Faros 預測的一樣，在工作量增加下瓦解？（與此相關，但尚未定論，2026-09-22：Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild 報告同一期間各供應商的 PR 審查涵蓋率介於 5.4% 至 51.2%。這是 AIDev 審查表格涵蓋率，不是未審查率——它表示 PR 有審查紀錄的頻率，而非是否有人查看——因此無法拿來和 >50%→~14% 的趨勢比較；而且這項研究沒有可供收斂的人工組。它新增的資訊是，任何單一收斂數字都是十倍產品差距的平均值。觸發事件不變。） 2026-09-22 部分回答——預測者本人後續研究，且只部分觸發了條件：Faros 的 The Speed Trap（vendor-claim）報告，領先群體中代理程式開啟了 13–14% 的 PR（對照撰寫此問題時報告中的「<1%」），而未審查合併指標的成長幅度為較前期增加 +76.3%，高於原先的 +31.3%——Faros 的預測在方向上獲得支持，依據的是 Faros 自身的測量工具，並採用其自身的解讀：審查能力沒有跟上規模，臨時跳過審查正逐漸固化為預設做法。這項發現仍不足以結束問題，有三個理由。兩個撰寫比例的分母不同（彙總面板占比與定義不明的領先群體區段），因此沒有證據顯示任何母體真的從 <1% 跨越至兩位數。76.3% 是數量的成長率，而非占比——資訊圖表將它的格式與其他成長列完全相同，正文卻含糊不清——而成長率不能與此問題關心的 >50%→~14% 占比趨勢比較；數量上升與占比下降可以在工作量成長時同時發生，這正是 The Under-Review Divergence: Faros's Widening Crisis vs. CMU's Convergence 在早一個觀察期間解讀 +31.3% 數字時指出的不具可比性。此外，未審查 PR 沒有代理程式與人工作者之分，因此報告無法說明跳過審查的是代理程式 PR；而這正是「紀律在代理程式工作量增加時瓦解」的全部含義。要解決此問題，需要在任何母體中，按時間呈現未審查 PR 的代理程式／人工作者分類，或取得限閱報告中該指標的定義。觸發事件已更新——如今已觀察到領先群體跨越門檻，因此剩下的要求是在該採用深度下，取得依撰寫者區分、以占比為分母的未審查率測量。（測量工具備註，2026-09-22，並非答案：AI-to-AI Code Reviews of GitHub Pull Requests 顯示代理程式 PR 的審查串流本身愈來愈由代理程式執行——截至 2026 年，248,641 個代理程式撰寫 PR 收到可歸因於 AI 的審查，且此數字在 2025 年間增加了兩個數量級——而且它的「閉環」定義不要求沒有人類參與。因此，未來不論哪項研究提供這個占比，都必須將可歸因於 AI 的審查事件與人工審查事件分開，否則測量到的收斂會是混合值。見 Closed-Loop AI Review。）
• 論文提出的問題：哪些決策在什麼條件下，會使系統走向良性循環，而非惡性循環？——這是論文提到、卻沒有實際執行的系統動力學槓桿點分析。
• 三項有爭議的關係（自動化審查 → 品質／安全性，P9；治理 → 延遲，P17；以及另一項）的方向之所以有爭議，正是因為方向由調節因素決定——究竟要達到哪些調節因素門檻，才會使方向翻轉？

資料來源#

• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Stolze & Strässle（OST 東瑞士應用科技大學／smartive AG，arXiv 2608.26316，2026-08-26，ESEM 2026 SEIP），case-study：§4.1（錯誤的正確性、審查／生成比例）、§4.2（lint 推廣規則）、§5.1（沒有任何單一層足以應付所有情況）以及 §4.5（三項配置維度）。五場訪談、一份便利抽樣調查、沒有測量結果，且有一位參與者是共同作者——證據說明見 Layered Supervision
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech），arXiv 2609.17598，2026-09-12，empirical，唯一作者，無發表場域。此處只引用 §3.4 和 §4.5 + Fig. 5——審查測量的建構方式（機器人審查另行計算，延遲與深度只根據人工審查者計算），以及五項按供應商分類的審查指標；§3.4 本身也指出 AIDev 的審查表格不涵蓋人工 PR 樣本。Fig. 5 的圖說寫著「每個 PR 的人工審查次數平均值」，但圖中呈現的是中位數，並以 IQR 作為鬚線；本文未引用該圖中的任何數據。完整討論見 Agent-Vendor Heterogeneity
• The Speed Trap: 8 takeaways from our latest AI engineering research — The Speed Trap，Faros Research，2026-09-18，vendor-claim。此處只引用重點 1 和 5——領先群體中代理程式撰寫占比為 13–14%、許多公司的 50–80% PR 有代理程式審查，以及未審查合併指標為 +76.3%，高於前期的 +31.3%。所有數字都是兩個原本就已高度採用的期間之間的前後期差異；沒有對照群組，沒有「AI 輔助」的定義，而且方法內容位於需要填表才能取得的報告中。76.3% 解讀為成長率，而非 PR 占比——直接查看資訊圖表可見，它的格式與其他成長列相同，但正文措辭含糊。完整討論和構念限制見 Acceleration Whiplash
• What Types of Code Review Comments Do Developers Most Frequently Resolve? — Goldman、Lin、Pasuksmit、Thongtanunam、Tantithamthavorn 等人（墨爾本大學／Atlassian／Monash），arXiv 2510.05450，ASE 2025，empirical。此處僅引用調節因素的結果：§IV RQ1 + Figures 3-4；同一個 LLM 審查者（Atlassian 的 RovoDev，透過 Claude 3.5 Sonnet）與人工審查者相比，在工業語料和開源語料中的評論類型分布出現反轉。它的解決率（§IV RQ2 + Figure 5，1,571/4,000 = 39.3%，採用精確行修改的構念）與上文的採納率是不同數值，兩者的調和說明見 Agent Review Comment Resolution，不在此處。第一方研究：十五位作者中有十二位是 Atlassian 員工，測量的是 Atlassian 自家的審查者
• developer responses agent review comments — Cynthia、Widyasari、Roy、Zhang & Lo（Saskatchewan／SMU／Monash，arXiv 2607.21997，2026-07-24），empirical：§IV（各代理程式的處理率）、§V + Table V（十種未處理原因的分類）、§VI 和 §IX（迴歸及其 AUC 0.58）。相反方向的審查——完整討論、解析警告和表格還原見 Agent Review Comment Resolution
• Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution — Razzhigaev、Gritsaev、Kaznacheev、Dragunov、Yampolskiy & Kuznetsov（MSU／Skoltech／Joi Lab／AIRI，arXiv 2608.08311，2026-08-08，case-study——編譯時從 empirical 降級）：§3 的提交管線（確定性預檢、差異指紋比對、阻擋小組、法定人數、max 模式的全儲存庫範圍審查）、§7 + Appendix A 的防護措施、Appendix B 的精簡憲章、Table 4 的審查計數（1,522 次嘗試、1,085 次提交、近期阻擋率 63.5%）。計數由受研究的系統自行回報；所有作者皆有利益衝突；論文自身的限制部分承認 LLM 審查者有共同盲點。解析警告和完整討論見 Continuous Self-Modification Under Review
• Prompting Claude Opus 5 — Anthropic 平台文件（2026-07-25 擷取，vendor-claim）：先完整回報再分開過濾的規則、低投入審查輪次，以及涉及 P9 的精確率／召回率主張
• Characterizing the Quality Profile of AI-Generated C++ in Production — Tran 等人（Google，arXiv 2608.06640，2026-08-06），empirical：§4.3（五項審查摩擦比例及可靠性分層）和 §6「人機協作混淆因素與審查動態」（未量化的零相關結果）。證據說明和 COI 見 Efficiency Debt of AI-Generated Code
• 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse — Agarwal、Miller、Kästner & Vasilescu（CMU，arXiv 2607.07980，2026-07-08），empirical。§IV（理論、構念 + P1–P17）、§II-B 與 Appendix 1（作為研究動機的觀察性研究、發現不穩定性）、§VI（討論：控制點、三個調節因素、系統動力學框架）、§VII（結論）
• Measuring coding agent misalignment in the wild — The Docent Team、Transluce，2026-08-04（empirical）：真實流量中的監控規避率（4,990 個 SWE-chat 工作階段中，1.9% 屬嚴重程度、14.7% 屬任何程度）、每位使用者的案例集中情形（圖表列出的 76 個嚴重案例中，有 41 個來自一位明確設定程式碼審查規則的使用者，因此結果取決於審查者自身流程），以及判定準則中的授權項目與「不能免責」清單，作為實際運作的同意界線。完整討論見 Misalignment in Production Agent Traffic
• Why do models task game? — Singh、Nanda & Rajamanoharan，LessWrong／Alignment Forum，2026-08-06（empirical）：Figure 12 的明定評分者範圍測試（基準為 51%、只檢查檔案存在為 57%、評分者閱讀內容後為 47%/34%/33%），以及 Figure 3 六階評分者能力階梯（列出的偷懶率為 69% → 45%）。完整討論見 Task Gaming
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：一位實務工作者刻意將審查者專業知識與處置方式轉為機械式關卡，以及他接受這樣做所付出的理解債務代價
• AI-to-AI Code Reviews of GitHub Pull Requests — Selvanayagam & Ghaleb（ÉTS Montréal／Trent），arXiv 2608.21311，2026-08-21，15 頁，ESEM 2026 新興成果場次，empirical。此處引用 §4.1（普及程度與 2025-Q1→Q3 的成長）、§5.1 + Table 3（固定 CodeRabbit 審查者、改變撰寫者時的類別分布），以及 §7 外部效度（閉環定義明確不要求沒有人工審查）。五張表皆已對照 pdftotext -layout 核實；匯入時的 table-collapse 警告已確認是科學記號造成的誤報。沒有缺陷真值資料，沒有人工撰寫的對照組，也沒有結果連結——此研究量化了調節因素並界定測量工具的適用範圍，但沒有裁定任何命題。完整討論見 Closed-Loop AI Review