059 · 五個訊號，算出 PR 的審查債
AI 寫程式碼讓 PR 暴增，但沒人真的在審查，這場示範怎麼用五個訊號把審查債換算成具體數字。
原標題：ReviewDebt: a practical framework for scoring every pull request — Sachin Gupta, Ebay
重點摘要
- 審查債的定義agent 產出的程式碼與人類真正審查、理解、信任的程式碼之間，會出現一道不斷擴大的落差，這就是 review debt。它像技術債一樣會複利累積，但付出的利息是人的注意力，而且會透過三個回饋迴圈自我強化：agent 從尚未被仔細審查的程式碼學習、生成量一多注意力就縮回語法層級、團隊看到吞吐量提升後也不會按比例增聘審查人力。
- 產業數據對不上GitHub 2025 年 10 月的報告顯示 commit 量年增 25%，但 comment 數卻年減 27%；在 AI 採用程度最深的團隊裡，Faros AI 的 2026 基準顯示 PR 審查時間中位數暴增 441.5%，中位數 PR 大小也從 44 行漲到 72 行。
- 五個可計算的訊號家族diff 大小與耦合、測試證據落差、目錄與 ownership 分散、AI authorship 指標、PR 說明與實際變更的落差，全部是確定性檢查，刻意不用 LLM 當裁判，因為模型一換分數就會漂移，也沒辦法拿到管理層面前站得住腳。
- AI 標籤不等於高風險AI authorship 訊號本身只佔總分一小部分，真正把分數推高的是 diff 過大、跨團隊、缺測試；掃描三個公開倉庫共 524 個 PR 也證實，落在高負擔區間的都是大型結構性變更，跟是不是 AI 寫的無關。
- 分數怎麼落地把五個訊號依權重加總得出 0 到 100 分，切成四個等級，再用回填舊 PR、設門檻、貼留言、每週彙總、拿到會議上討論這五步驟推行，重點是讓對話從「感覺」變成「量測」。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場破題 | 講者說明 coding agent 正在製造一種沒人在計算的審查債，之後會攤開定義、五個訊號家族與跨倉庫掃描結果。 |
| 00:35 | GitHub 數據揭露落差 | GitHub 2025 年 10 月報告顯示 commit 量年增 25%，但 comment 數卻年減 27%，生產與審查的方向完全相反。 |
| 01:15 | 重度 AI 團隊更嚴重 | Faros AI 的 2026 基準顯示，PR 審查時間中位數暴增 441.5%，比過去慢 5.4 倍，31% 的 PR 完全沒經過審查就合併。 |
| 03:08 | 拆穿虛榮指標 | PR 數、PR 大小、cycle time 這些常被拿來報喜的數字，講者認為它們只反映生產速度，不反映團隊對程式碼的信任程度。 |
| 04:38 | 定義 review debt | review debt 是 agent 產出的程式碼與人類真正審查、信任、理解的程式碼之間不斷擴大的落差，會像利息一樣複利累積，付出的是人的注意力而非金錢。 |
| 06:06 | 五個訊號家族登場 | 講者主張用十個確定性檢查取代 LLM 當裁判，因為 LLM 評分會隨模型改變而漂移，也無法在管理層面前站得住腳。 |
| 08:05 | 測試證據落差 | 用測試行數除以 production 行數當指標，AI 寫的 PR 測試比例常偏低，就算有測試，也多半只斷言程式碼現在做了什麼，而不是應該做什麼。 |
| 09:41 | AI authorship 訊號 | 用 co-authored trailer、branch 命名、PR 內文用語三種方式偵測 AI 參與痕跡，講者強調這不是拿來扣分，而是放大其他訊號的存在。 |
| 12:28 | 評分公式與四個等級 | 五個訊號依權重加總成 0 到 100 分，切成四級：0 到 24 極低負擔、25 到 49 正常、50 到 74 需要作者補證據、75 以上建議拆分或要求更多脈絡。 |
| 14:37 | 高審查債 PR 案例 | 真實案例分數 60、標記需要證據，預估要花 86 分鐘審查；其中 AI authorship 訊號只貢獻 5 分，其餘 55 分來自 diff 過大與缺測試。 |
| 17:06 | 三個公開倉庫的掃描結果 | 對 524 個 PR 的掃描顯示，AI authorship 比例穩定維持在 5% 到 20%，但審查負擔差異很大；真正落在高負擔區間的 4 個 PR 全是大型遷移、SDK 重寫等結構性變更。 |
| 19:51 | 給團隊的具體建議 | 每個 PR 只做一個邏輯變更、測試要斷言程式碼該做什麼而非現在做什麼、留在同一個 owner 範圍內、PR 內文由作者自己寫而不是讓 agent 代寫。 |
| 21:03 | 導入的五個步驟 | 先回填過去 200 個已合併的 PR 校準門檻，設定超標線要求作者補充說明，把分數貼成 PR 留言但不擋合併，每週依團隊彙總斜率，再拿到回顧會議上討論。 |
| 23:34 | 收尾三個行動呼籲 | 建議先拿上週 20 個 PR 用五個訊號手動算一次分數、觀察審查債的斜率比單一數值更重要，並呼籲團隊別再無腦按 LGTM。 |
值得記的話
名詞與人物
| Review debt | 這場定義的核心指標：agent 產出但人類還沒真正審查、理解、信任的程式碼落差，會像利息一樣複利累積。 |
|---|---|
| Faros AI | 追蹤工程團隊生產力與 AI 採用狀況的基準機構，這場多次引用它 2026 年的報告數據。 |
| DX | 另一個引用來源，涵蓋 16 個月、400 個組織的長期工程資料研究，用來佐證 PR 規模與速度的變化。 |
| Co-authored trailer | commit message 裡標記共同作者的欄位，這場拿它當偵測 AI 參與 PR 最強的訊號之一。 |
| LGTM | 審查者常用的「看起來沒問題」留言，講者呼籲團隊別再無腦打這句話交差了事。 |
延伸
- GitHub 2025 年 10 月的公開報告，這場只引用 commit 與 comment 量的結論數字，沒有展開完整方法論。
- DX 2026 年、涵蓋 400 個組織的長期工程資料研究，這場只取用其中 PR 規模與吞吐量的數字。
- 講者提到掃描器原本有可以即時操作的 CLI，但這場只用截圖說明評分結果，沒有實機展示。