AI 幫團隊寫了更多程式碼，等待審查的 PR 卻越積越多。開發者持續提交變更，資深工程師忙著確認測試、追問修改原因、判斷風險，大家都在等同一批人點頭。

要減少這些等待，可以把審查分成三層：先用自動化檢查找出明確錯誤，再由 AI 檢查程式碼品質，最後讓人類確認修改目的與風險。

這是 Matt Pocock 在《Fixing the PR Bottleneck》演講中提出的做法。他還建議，把人類審查時反覆發現的問題寫成檢查規則，避免下一次又花時間提醒同一件事。

本文依演講逐字稿整理，並在文末提供延伸的 PR 說明範本與團隊試行建議。觀看直播來源：Fixing the PR Bottleneck — Matt Pocock, AIHero。

為什麼 AI 寫程式更快，PR 審查卻成為瓶頸？

PR 是 Pull Request，指開發者提出程式碼變更，請團隊審查並合併的請求。Code Review，也就是程式碼審查，是這個過程中確認修改是否合適、有沒有問題的工作。

PR 堆積早在 AI 普及前就存在。現在 AI 寫得更快，能審查的人卻沒有變多，等待的工作就可能越來越多。

Matt 描述的「軟體工廠」，連發起工作都能自動化。系統收到問題訊號後，可以觸發 agent 分析、重現或修正問題，再產生新的程式碼變更。如果產出持續加快，品質檢查卻沒有跟上，團隊就會收到大量難以審查的 PR。程式碼庫裡累積的複雜度，也會成為 AI 下一次工作的負擔。

因此，Matt 用「煞車」形容三層品質檢查：

層次	主要工作	希望減少的人工負擔
自動化檢查	執行測試、型別檢查與程式碼規則	反覆確認已有明確判定標準的錯誤
AI 自動審查	檢查測試漏掉的情境、程式結構與團隊規範	一再指出相同的品質問題
人類審查	理解修改目的，判斷影響與風險	處理需要人決定的事情

三層各有要處理的問題。前面檢查得越可靠，人類收到 PR 後，需要重新確認與修改的地方就有機會減少。

第一層：自動化測試通過，不等於程式碼可靠

自動化檢查的執行成本通常較低，可以多用。但 Matt 提醒，有些測試雖然通過了，卻沒有驗證到我們在意的事情。

第一種是把實作再寫一次。程式設定「貼文字數上限為 280」，測試就確認這個常數等於 280。數值是對的，但使用者輸入超過上限時，系統會怎麼處理？這個測試沒有回答。

第二種是檢查原始碼的排列。為了確認畫面上的影片區塊排在內容規劃之後，測試直接搜尋原始碼中的文字位置。它沒有呈現畫面，也沒有檢查使用者實際看到的順序。

第三種是把模擬物件做得太簡單。測試用假物件取代真實 API，卻沒有模擬真實環境可能出現的錯誤。測試每次都過，正式環境仍可能出問題。

測試綠燈只能告訴我們，程式通過了目前這些檢查。測試有沒有漏掉重要情境，還是得看。

用深模組減少對實作細節的依賴

要減少這類測試，Matt 建議從程式碼設計著手。他介紹 John Ousterhout 在《A Philosophy of Software Design》中提出的「深模組」（deep modules）。

深模組把複雜的內部行為藏在簡單的對外介面後面。測試只要透過介面確認結果，就不必過度依賴內部常數、函式怎麼拆，或原始碼怎麼排列。

沿用字數限制的例子，可以測試「輸入超過限制的內容後，系統是否正確拒絕」。只要對外行為不變，開發者就能調整內部寫法，不必連帶修改一批只跟實作細節有關的測試。

這樣也比較容易讓 agent 知道該從哪裡修改、要驗證什麼。不過，介面設計得清楚，仍要配上能驗證實際行為的測試案例，才能知道程式是否正確。

第二層：讓 AI 實作與程式碼審查分工

實作 agent 得先找程式碼、修改檔案、執行檢查，再處理錯誤。Matt 認為，如果同一次任務還要它顧到大量設計規範，很容易顧此失彼。

• 實作階段：完成功能，讓程式正常運作。
• 審查階段：交給另一個有獨立上下文的 agent，對照修改內容與團隊標準，檢查並改善品質。

他建議把詳細規範放在 coding-standards.md，讓審查 agent 讀取，避免全部塞進實作 agent 每次都要處理的 AGENTS.md。

這是 Matt 根據自身經驗提出的方法。演講沒有提供比較實驗，不能據此認定所有團隊採用後都會更好，但可以先檢查自己的做法：是不是要求同一個 agent 在一次任務裡，同時顧到太多事情？

AI 審查完，人的工作有沒有變少？

假設 AI 看完一個 PR，留下十幾條評論，人類仍得逐條確認、決定要不要採納，再安排修改。這樣做，審查者不一定比較輕鬆。

因此，Matt 主張，審查 agent 對明確能修正的問題，應直接修改並提交變更；有疑慮、需要人判斷時，再留言。

團隊也要逐步寫下自己的審查標準。人工審查時經常提醒的要求，就可以交給 AI 在下一次檢查。實際採用時，需要先說清楚哪些修改可以自動進行，以及改完後必須重跑哪些檢查。評估效果時，要看人類後續處理的工作有沒有減少，光看 AI 找出了多少問題還不夠。

第三層：依照風險安排人工 PR 審查

人類要花多少時間審查一個 PR，得看修改能不能撤回，以及出錯會影響多大範圍。

類型	判斷重點	審查方式
雙向門	修改容易還原，後果可以控制	視影響範圍減少審查投入
單向門	後果難以撤回，或恢復代價很高	仔細確認可能出錯的情況與防護措施

例如，一個看似簡單的修改，可能不小心寄信給六萬人。程式碼可以還原，寄出去的信卻收不回來。資料遺失與昂貴的資料遷移，也需要特別留意。

改的行數少，風險不一定小。能還原程式碼，也不代表能恢復它造成的所有影響。

所以，PR 說明要讓審查者知道：改了什麼、為什麼改、可能影響哪裡，以及出問題時怎麼恢復。

Matt 也建議用偽程式碼、流程圖或前後對照，幫助審查者理解變更。先看懂整個修改要做什麼，才比較容易判斷哪些細節需要仔細看。

用回顧機制，避免同一種問題反覆人工審查

演講最後，Matt 介紹了 retro，也就是回顧機制。它可以檢視一次 agent 工作紀錄、一個 PR，或一段時間累積的審查結果，找出下次可以調整的做法。

Matt 希望，同樣的審查意見不要一直由人重寫。如果 agent 反覆犯同一類錯誤，就要回頭檢查：

• 能不能新增自動檢查，在交給人之前就發現問題？
• 能不能寫進程式設計標準，讓 AI 審查？
• agent 是否找不到必要資訊，需要更清楚的文件導引？
• 使用工具的方式，有沒有造成不必要的消耗？
• 指令文件是否太長，反而讓重要要求不容易被注意到？

一次人工審查的發現，可以寫成後續工作能重複使用的檢查、規範或指引。

團隊如何開始改善 AI 程式碼審查流程？

以下是根據演講延伸的做法，並非講者提供的原始範本。

可以先挑最近幾個 PR，找出哪些問題一直需要人工處理，再決定交給哪一層檢查。例如，固定規則交給自動檢查，設計標準交給 AI 審查，需求取捨與高風險判斷留給人。

也可以先統一 PR 說明，省下每次追問背景的時間：

• 變更目的：這次要解決什麼問題？為什麼現在需要修改？
• 行為差異：修改前會怎麼運作？修改後有什麼不同？
• 驗證結果：執行過哪些檢查？還有哪些情境尚未驗證？
• 風險與影響範圍：可能影響哪些使用者、資料或外部系統？
• 恢復方式：能否還原？是否有無法撤回的外部效果？
• 需要人工判斷：有哪些疑慮或取捨，需要審查者決定？

試行後，可以觀察 PR 從提交到開始審查的等待時間、相同問題需要人類重複提醒的次數，以及合併後的缺陷與返工是否增加。這些紀錄能幫助團隊判斷，新工具與流程有沒有讓交付更順利。

從團隊管理的角度，我在意的是：審查者發現問題之後，團隊有沒有跟著調整工作方式？如果少數人不必再重複處理同一類錯誤，就能有更多時間討論需求、風險與需要取捨的事情。

下一次回顧會議，可以先拿出一條最近重複出現的審查意見，討論怎麼讓下一個 PR 在交到人手上之前，就先處理好這個問題。

資料來源：Matt Pocock（AIHero），《Fixing the PR Bottleneck》直播影片。本文依逐字稿整理；PR 範本與團隊試行步驟為延伸建議。演講未提供量化成效比較，實際改善程度仍需由團隊驗證。

作者簡介

范育銘是 Scrum Inc. 認證培訓師及台灣敏捷協會常務理事，曾陪伴不同規模的企業推動數位與組織轉型。我協助主管對齊目標、釐清決策邊界，建立回饋與協作機制，讓主管能放心授權，團隊也能承擔決策與成果責任。

我也持續在 WeAgile 分享組織變革與敏捷實務文章，並提供公開課、企業內訓及教練顧問服務，幫助企業把自組織與自管理，從理念轉化為真正能運作的管理能力。