審查不足的分歧：Faros 擴大的危機 vs. CMU 的收斂

問題#

Faros 將審查不足解讀為一場擴大的危機；CMU 的非供應商 GitHub 遙測資料則發現，隨著組織學會審查代理程式碼，代理程式未審查率正收斂至人類基準（>50%→~14%）。這個分歧是真實存在的嗎（企業與開源族群、採用深度的橫斷面與日曆時間趨勢），還是加速反彈的審查不足壓力只會出現在 PR 數量最高的地方？（來自 Acceleration Whiplash 的未決問題）

簡短回答#

**這個分歧大多不是真實的——兩項研究測量的是不同族群、不同時間軸、不同作者單位上的不同數量，而且兩者都符合一個共同的底層故事：**當 AI 將大量內容灌入 AFT pipeline 時，未充分審查輸出的總量上升（Faros）；而團隊學會按風險分流審查後，未經檢查就合併的代理程式 PR 所占的比例下降（CMU）。問題的第二個部分獲得支持：審查不足是集中於數量與風險分流的行為，而不是一致性的侵蝕。真正尚未解決的不是資料，而是預測——當代理程式主導的撰寫從今天 PR 的 <1% 走向兩位數時，已學會的分流紀律是否仍能維持。兩個來源本身都明確指出，這正是尚未經過測試的斷點。

四個不可比的軸向#

標題中的數字不是對同一件事所做的同一種測量。並列如下：

軸向	Faros（Acceleration Whiplash、`vendor-claim`）	CMU（Review as the Control Point、`empirical`）
指標	PR 在未經任何審查下合併的增幅 +31.3%——數量／發生率上的差值（「最迫切的發現」）	代理程式 PR 的未審查比例：>50%（2025 年中）→~12%（2026 年 2 月），相對於穩定約 14% 的人類基準——隨時間變化的水準
族群	企業遙測資料：22,000 名開發者、4,000 個團隊（Faros 平台客戶）	公開 GitHub：2,860 個已包含代理程式 PR、且至少有 10 顆 star 的儲存庫（超過 250 萬個 PR；沒有未採用者對照組）
時間軸	採用深度的橫斷面：公司內低 AI 採用期與高 AI 採用期	日曆時間趨勢：2020 年 1 月至 2026 年 2 月的完整 PR 歷史，重新抓取
作者單位	在 AI 輔助的人類主導撰寫占主導地位的環境中，所有 PR（根據 AI as Primary Author，代理程式主導的撰寫占 PR <1%）	明確區分與代理程式相關的 PR 與人類 PR

算術上的調和很直接：**只要總量成長得夠快，比例下降與數量上升就能同時存在。**Faros 自己的吞吐量數字提供了總量——每個團隊的程式碼專屬任務增加 +210%、PR 合併率增加 +16.2%、任務吞吐量增加 +33.7%（Acceleration Whiplash）。如果已合併 PR 的總量大致翻倍，而未審查比例從早期高峰下降，未審查合併的絕對數量仍會增加——Faros 的 +31.3% 與 CMU 的 >50%→~12%，可以同時如實描述各自的族群。

時間軸的差異則補上其餘部分。採用深度的橫斷面會混淆族群學習：在任何一個日曆時間點，採用最深的群體同時也在處理最多 AI 輸出，因此會呈現最多審查不足——即使每個群體的比例都隨著學習而在日曆時間中下降，而這正是 CMU 縱向序列所顯示的結果。Faros 的比較看不到學習曲線；CMU 的比較看不到企業採用深度。（Faros 自己的 2025→2026 比較明確是「僅供方向性參考——獨立的橫斷面，而非縱向面板」——Acceleration Whiplash。）

總量集中條款：獲得支持#

問題的另一種可能性——「審查不足的壓力是否只出現在 PR 數量最高的地方？」——在 CMU 附錄的細節中得到直接支持（3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse）：

**每個專案的未審查率中位數，在每個月份對兩類作者都接近 0%，**但合併後的代理程式比例起初超過 50%。未經審查就合併是少數行為，集中於部分專案——而合併後的序列由推送最多代理程式 PR 的儲存庫主導。早期的「危機等級」數字從來不是採用代理程式專案的普遍特徵；它其實是高代理程式總量離群值的特徵。
**專案是按感知風險分流，而不是不加區分地處理。**代理程式未審查率依 PR 類型而有很大差異——測試 69%、重構 41%、錯誤修復 25%——而人類的比例幾乎持平（8–14%）。在跳過審查的地方，跳過的是低風險變更。
收斂本身就是適應總量的故事：「一開始願意讓代理程式輸出未經檢查地合併，後來轉為像審查人類 PR 一樣審查它」——也就是說，壓力最初出現在代理程式總量最高的地方，之後流程完成適應。這就是 CMU 的第三個調節因素（流程適應）在真實環境中的運作方式（Review as the Control Point）。

關鍵在於，**Faros 所建議的正是 CMU 觀察到正在自然形成的行為。**Faros 的補救措施第 2 點承認「每個 PR 都必須有人類審查……會在總量的重壓下失效」，並建議按風險分級的閘門——高風險路徑由人類檢視、較低風險區域由代理程式審查、沒有 PR 可以不經閘門（AI Engineering Report 2026: The Acceleration Whiplash）。這正是 CMU PR 類型分析中的按風險分流模式。在機制上，供應商與非供應商來源是一致的；只有標題不同——而標題上的分歧反映了它們的誘因與框架（Telemetry vs. Survey Measurement：Faros 的「擴大的危機」能推銷可見性平台；CMU 的論點則需要讓審查成為可操控的控制點）。

真正仍未解決的問題#

**總量測試尚未發生。**Faros 的資料集中，代理程式主導的撰寫占 PR 的 <1%，並警告將人類移出迴圈會使每項指標承受「高出一個數量級」的壓力（AI as Primary Author）；CMU 自己的未決問題則詢問，當代理程式主導的撰寫「從 PR 的 <1% 走向兩位數」時，收斂是否仍會維持（Review as the Control Point）。兩個來源都同意，目前觀察到的情境尚未測試下一步真正重要的情境。收斂證明的是團隊能夠在當前總量下適應——不是證明分流紀律能在多出 10 倍的情況下維持。
**不同研究對監督變化的方向甚至仍有爭議。**CMU 在專案層級的收斂，與 Yu et al. 的審查者內部習慣化相反（隨著核准增加、留言減少，監督變弱）——單位不同（專案覆蓋率與個別審查者行為），兩者可能同時為真：專案建立審查閘門，但閘門內的個別審查者更常蓋章通過（Review as the Control Point）。
**定義選擇會使符號翻轉。**代理程式 PR 是否比人類 PR 得到更多或更少的獨立審查，取決於呼叫代理程式的開發者是否被算作獨立審查者（代理程式作為作者），或被算作作者自行審查（代理程式作為工具）——這是 CMU 自己的警告：無論是否來自供應商，表面遙測若沒有因果模型，都無法裁決這個問題（Telemetry vs. Survey Measurement）。
**族群差距尚未彌合。**目前仍沒有非供應商的企業遙測資料；開源的收斂未必能轉移到企業，而 Faros 的企業惡化也未必能轉移到開源。兩個資料集都無法在自身所處的場域反駁對方。

結論#

若將其讀作矛盾，這個分歧就消失了：**在採用深度上比較未審查 PR 數量的差值（企業、所有 PR、供應商），與在日曆時間上下降的未審查比例（開源、代理程式 PR、非供應商），回答的是不同問題。**一致的共同解讀是：AI 驅動的總量成長提高了未充分審查程式碼的絕對數量；與此同時，團隊——首先是總量最高、最早承受壓力的團隊——學會按風險分流審查，使代理程式未審查率下降至人類基準。真正保留下來的分歧是預測性的，而非實證性的：Faros 固定方向的「基礎正在崩解，總量會突破閘門」對上 CMU 的「團隊透過流程適應決定方向」。下一個可觀察的測試，是當代理程式主導撰寫的 PR 比例超過個位數時，約 14% 的收斂是否仍能維持——這條趨勢線值得拿任何 2026 年後的重新抓取資料或未來 Faros/DORA 版本再次核對。

資料來源#

Acceleration Whiplash — Faros 的 +31.3% 審查不足發現、吞吐量差值、與成熟度無關的主張、橫斷面限制（AI Engineering Report 2026: The Acceleration Whiplash）
Review as the Control Point — CMU 的未審查收斂（>50%→~12%，相對約 14% 基準）、發現不穩定性、三個調節因素、Yu et al. 的反面觀點（3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse，§II-B + Appendix 1）
Telemetry vs. Survey Measurement — 方法論框架：遙測的延遲優勢是真實的，但沒有因果模型，表面遙測的方向不穩定
AI as Primary Author — <1% 代理程式主導撰寫的邊界條件，以及接受／審查的定義模糊
AI Engineering Report 2026: The Acceleration Whiplash — 建議第 2 點（按風險分級的審查閘門；「會在總量的重壓下失效」）
3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse — 附錄 1：每個專案未審查率中位數約 0%、合併後趨勢、PR 類型分流分析（測試 69%／重構 41%／錯誤修復 25%，相對人類 8–14%）