10 月 22 日同一天發佈的三份報告，從不同角度給出了同一個結論：AI 編程智能體讓程式碼量和評審工作量一起漲，但真正交付的價值沒有同比例增加。
數字對不上
哈佛的一篇工作論文統計了 718 家企業、3 億條工作事件：採用 AI 編程智能體後，程式碼行數增長 30%、提交增長 20%、拉取請求增長 23%，但 Jira 裏 issue 與 Epic 的完成率沒有統計顯著變化。論文把落差主要歸給評審——PR 從提交到合併的平均時長漲了 49%，被要求修改的比例接近翻倍，每個 PR 的評論數漲了 35%。
評審成了新的瓶頸
LinearB 基於 810 萬個 PR 的基準更直白：AI 智能體提交的 PR 平均要等 17.6 小時才有人評審，是普通 PR（3.4 小時）的 5.25 倍；30 天內合併率 32.7%，普通 PR 是 84.4%。Faros AI 另一組來自 2.2 萬名開發者的數據裏，PR 評審中位時長漲了 441%。
程式碼質素的那筆帳
同一批報告裏，缺陷數與每 PR 事故率都在走高。LocalStack 的調查顯示，65% 的團隊程式碼產出至少翻倍，54% 回饋 AI 生成程式碼缺陷變多，約 40% 的 AI 生成程式碼從未進入生產。原因不神秘：模型不理解你們系統的約定與架構決策，寫出來的東西「看着對」。
對企業意味着什麼
- 別拿程式碼行數或 PR 數當生產力指標，那只是活動量，不是產出。
- 把評審容量當稀缺資源排期。評審人力不增加，AI 只會把隊列拉得更長。
- 給 AI 生成的程式碼配獨立的質素門禁：靜態檢查、單測覆蓋、變更範圍限制，缺一不可。
- 先從有測試兜底的模塊開始用，別拿沒有迴歸驗證的老系統試刀。