一個包含 47 個變更檔案的 Pull Request 進入審查佇列。審查者打開它，看到 diff，花了前 15 分鐘只是理解改了什麼、為什麼改。哪些檔案是結構重構？哪些包含實際邏輯變更？測試覆蓋率足夠嗎？
對於每週做 10 個 PR 的團隊，這個導向時間——真正審查開始前的 15 分鐘——每週累計 2.5 小時。程式碼審查是有價值的，但搞清楚 PR 是關於什麼的這個階段不是。
工作流程做了什麼
PR Review Summarizer 工作流程在 PR 事件觸發時產生結構化審查摘要：
-
PR 開啟或更新 — 透過 GitHub webhook 觸發，擷取完整 diff、PR 描述、關聯 issue 和 commit 歷史。
-
AI 分析 diff — AI 讀取每個變更檔案並產出：
- 摘要：2-3 段描述 PR 做了什麼以及為什麼
- 變更分類：檔案按用途分組——測試、設定、核心邏輯、重構
- 風險評估：高/中/低風險評級及具體原因
- 潛在問題：審查者應該注意的具體問題
- 測試覆蓋：新程式碼是否有對應測試
-
摘要發布為 PR 評論 — 分析以格式化評論發布在 PR 上，審查者打開 PR 時立即看到。
分析在 30-60 秒內完成。
省下的時間
每週 10 個 PR：無摘要的導向時間約 15 分/PR = 2.5 小時/週，有摘要約 3 分/PR = 30 分/週。每週淨省 2 小時。品質的提升更有價值——審查者知道該聚焦在哪裡時，能在關鍵程式碼中發現更多問題。
人類仍然做什麼
AI 摘要和標記，人類審查。架構判斷、業務邏輯驗證、團隊標準、核准——這些仍然是審查者的責任。PR 摘要增強人類審查，讓每位審查者更快更專注。