審查中的分歧：Faros 的危機擴大，CMU 則趨於收斂

問題#

Faros 認為審查不足是一場持續擴大的危機；CMU 的非廠商 GitHub 遙測資料則發現，隨著組織學會審查代理程式程式碼，代理程式 PR 的未審查率正逐漸趨近人類基準（>50%→~14%）。這種分歧是真的嗎（企業與開放原始碼族群不同、採用深度橫斷面與日曆時間趨勢不同），還是審查不足的壓力只會在 PR 數量最高的地方浮現？（摘自 Acceleration Whiplash 的未解問題）

簡答#

**這種分歧大多不是真的——兩項研究衡量的是不同族群、不同時間軸、不同作者單位的不同數值，而且都符合一個共同的底層故事：**AI 湧入流程時，未充分審查的輸出總量隨之增加（Faros）；團隊學會按風險分流審查後，未經檢查便合併的代理程式 PR 佔比則下降（CMU）。問題中的第二種可能性有證據支持：審查不足是集中於特定範圍、受數量與風險分流影響的行為，並非普遍性的侵蝕。真正尚有爭議的不是資料，而是預測——當代理程式撰寫的 PR 佔比從今天的 <1% 升至兩位數時，已形成的分流紀律是否仍能維持。兩個來源都明確指出，這正是尚未驗證的轉折點。

四個無法直接比較的面向#

標題中的數字並非對同一對象採用相同方式所做的衡量。並列如下：

數字之間的調和方式很直接：**只要數量成長夠快，比率下降和數量上升就能同時發生。**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 數量特別高的離群值所留下的印記。
• **專案依據感知到的風險分流，而非一概而論。**代理程式 PR 的未審查率依 PR 類型而異——測試 69%、重構 41%、錯誤修復 25%——人類 PR 的比率則幾乎持平（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 的論點則需要把審查視為可調控的控制點）。

真正尚待釐清之處#

1. **數量測試尚未發生。**Faros 的資料集中，代理程式撰寫的 PR 佔比為 <1%，並警告把人類移出迴圈會使每項指標承受「大一個數量級」的壓力（AI as Primary Author）；CMU 自己的未解問題則是，當代理程式撰寫的 PR 佔比「從 <1% 跨入兩位數」時，收斂是否仍會維持（Review as the Control Point）。兩個來源都認同，目前觀察到的情境尚未驗證下一個關鍵情境。收斂證明團隊能夠在目前的數量下調適，卻不能證明在數量增加 10 倍時，分流紀律仍能維持。
2. **不同研究對監督變化的方向也有爭議。**CMU 在專案層級觀察到的收斂，與 Yu 等人發現的審查者內部習慣化相反（核准增加、留言減少時，監督會變弱）——兩者的單位不同（專案覆蓋率與個別審查者行為），也可能同時成立：專案設立審查關卡，但其中的個別審查者卻更常直接蓋章核准（Review as the Control Point）。
3. **定義不同，結果方向就會翻轉。**代理程式 PR 是否比人類 PR 更常接受獨立審查，取決於是否把呼叫代理程式的開發者算作獨立審查者（代理程式是作者），或算作作者自行審查（代理程式是工具）——這也呼應 CMU 自己的警告：無論廠商與否，表層遙測資料若缺乏因果模型，就無法裁定此事（Telemetry vs. Survey Measurement）。
4. **族群差距尚未接合。**目前仍沒有非廠商的企業遙測資料；開放原始碼中的收斂情形未必能套用到企業，Faros 觀察到的企業惡化也未必會出現在開放原始碼。兩份資料都無法在對方的適用範圍內推翻對方。

結論#

如果把這種分歧視為矛盾，矛盾便消失了：**按採用深度觀察未審查 PR 數量的變化幅度（企業、所有 PR、廠商），與觀察未審查 PR 佔比隨日曆時間下降（開放原始碼、代理程式 PR、非廠商），回答的是不同問題。**兩者一致的解讀是：AI 帶動的數量成長會增加未充分審查程式碼的絕對量；與此同時，團隊——尤其是最先感受到壓力、處理量最高的團隊——學會按風險分流審查，使代理程式 PR 的未審查率降至人類基準。真正存在的分歧是預測，而非實證：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 等人的相反發現（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%）