一張付款流程的 PR，CI 綠燈、Copilot review 留了幾則意見，工程師處理完便合併。過幾天，另一張 PR 修掉它留下的錯誤。前一張在週報裡算「已完成」，後一張卻被算成新的工作。如果團隊用合併數評估 coding agent，這筆帳很容易算得太漂亮。

這是假設情境，不是我親手遇到的事故。重點在於：PR 合併是一次決策，不是缺陷觀察期的終點。

研究數字該怎麼看

近期一項針對開源專案的研究追蹤了 6,774 張已合併的 agent PR，並與同批專案、同時期的 5,044 張人工 PR 比較。樣本來自至少有 500 顆 stars 的開源 repo。研究將候選後續改動再做驗證，區分真正的直接修補與同一區域的增量工作；在可比較的觀察窗內，agent PR 出現「經驗證後續修補」的 odds 是人工 PR 的 1.62 倍。

這裡的 1.62 是 odds 比，不是「bug 多了 62%」，更不是放到自己公司的 repo 就會得到相同比例。任務難度、專案習慣與 PR 切分方式都可能不同。研究還指出，agent PR 經驗證的修補中有 69.6% 由同一個 agent 完成；這只告訴我們誰產生了修補，不代表定位問題、重新審查和驗收都沒花人力。

所以值得追的不是「用了 agent 後合併幾張」，而是合併後是否還要回頭修，以及誰花時間把它收乾淨。

Review API 能接流程，不能替你定義通關條件

GitHub 近期讓團隊透過 REST 或 GraphQL 發起 Copilot code review，也能對單次 review 指定 effort；預設 effort 改為 Balanced。這讓 review 更容易放進既有 PR 流程，但「已收到 review」仍不是「符合合併政策」。

團隊要分開核對三件事：CI 是否真的跑過這次提交、review 留的是意見還是核准、repo 的必要核准規則是否已滿足。Copilot review 在未啟用 approvals 的預設情況下留的是 Comment，不計入 required approvals；Copilot approvals 另有須明確啟用的公開預覽設定，不能把「永遠不算核准」寫死。PR 後來又推了 commit，也要查這次提交是否重新接受檢查，不要把舊留言當作新版本的檢查結果。

如果團隊是透過 API 整合 review，先拿去識別化的測試回應，確認拿到的確實是可解析的 JSON，再展開樹狀結構，對照實際回應與目前 API 文件核對需要的欄位。我會把這一步交給JSON 格式化與語法驗證工具這類瀏覽器工具處理，但不把 token、客戶資料或原始私有程式碼貼進去。語法通過只表示資料可解析；它不會判斷 review 是否足夠，更不會代替 GitHub 的核准規則。

合併後留一段看得見的觀察窗

我會先在一個 repo 試行，挑風險與改動規模接近的 agent PR、人工 PR，約定相同的觀察窗。每張 PR 留下合併時間、對應測試或重現連結；若後續需要修改，再標記是修正原 PR 引入的問題、同區域新需求，還是根本無關的變動。光是同一個檔案被改過，不能算一次 bug。

直接修補另外記缺陷嚴重度、修補者、人工定位與驗收所花的時間；有回歸測試就連回測試結果。觀察窗多長，應看團隊部署頻率與問題通常多久會浮現，不要把任意天數說成研究規定。週報除了產出與合併數，至少並排看「需要直接修補的 PR」與「人工收尾時間」。樣本太小時，逐件看案例就好，別急著做精美的百分比圖。

如果 agent 讓 PR 更快合併，但付款路徑的修補和人工驗收負擔也跟著增加，就先縮小它承接的任務範圍；如果修補可控，才逐步放大。要判斷它有沒有幫忙，帳必須算到下一張修補 PR 結束。

資料來源

• Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests
• GitHub Changelog：Copilot code review API support and new default effort level
• GitHub Docs：使用 Copilot code review
• GitHub Docs：Copilot code review 概念與 approvals