在傳統的軟體開發流程中，維持「小型 Pull Request (PR)」一直被視為一種最佳實踐。Pull Request 是開發者在將新代碼合併到主分支前，請求團隊成員審查變更的機制。為了降低審查壓力並減少錯誤，許多公司會強制要求每個 PR 的變更行數必須保持在低限度，例如僅限於幾百行，並鼓勵將大型功能拆分成多個連續的小型 PR（即 Stacked PRs）。然而，隨著 AI 代理（Agentic AI）開始主導代碼生成，這種以「行數」為核心的審查邏輯正在失效。
事端管理平台 Rootly 最近分享了他們放棄小型 PR 規則的經驗。Rootly 的共同創辦人兼技術長 Quentin Rousseau 指出，過去對小型 PR 的堅持是基於人類編寫代碼的速度與認知負荷。當代碼由人手撰寫時，較小的差異（Diff）確實更容易審查且方便回滾。但 AI 代理的運作邏輯完全不同，它們傾向於以「功能」而非「增量」來思考。當 AI 接收指令時，它會一次性產出完整的實作方案，包含資料庫遷移（Migrations）、模型（Models）、服務層（Services）、控制器（Controllers）、測試案例以及前端組件。
如果強行要求 AI 將這些完整功能拆分成多個小型 PR，反而會造成更嚴重的問題。審查者必須在多個分頁之間切換，且某個 PR 的審查意見往往取決於另一個 PR 的決定，這增加了認知負荷，將原本旨在簡化流程的規則變成了額外的管理成本。
核心內容：從審查行數轉向評估影響範圍
Rootly 意識到，AI 產生的 Bug 通常不是語法錯誤，而是「上下文錯誤」（Context Bugs）。也就是說，代碼本身在技術上運作正常，但被應用到了錯誤的場景中。例如，AI 可能會刪除一個資料庫欄位，卻忽略了該欄位仍被某個後台作業（Background Job）使用，或者寫入了一個其他團隊正在讀取的資料表。
為了應對這種轉變，Rootly 停止用審查人類代碼的方式來審查 AI 代碼，並開發了一套內部 AI 代碼審查工具。這個工具不再試圖模仿人類審查者的直覺，而是專注於回答一個核心問題：如果這次變更存在 Bug，會導致哪些面向使用者的行為崩潰？
這套 AI 審查系統會針對每個 PR 產出結構化的風險評估，包含標準化分數、信心水準以及按嚴重程度分組的具體發現。它會區分變更的性質，例如區分「改變系統行為」的變更與僅影響「效能或外觀」的變更，並賦予不同的風險配置文件。這讓人類審查者不再面對原始的代碼差異，而是擁有一份明確的風險地圖作為審查起點。
技術脈絡：將安全邊界從合併移至發佈
在這種新模式下，安全性的保障不再依賴於合併前的審查（Merge），而是移轉到了發佈階段（Rollout）。Rootly 大量使用特性標記（Feature Flags），這是一種允許在不重新部署代碼的情況下，透過開關控制功能是否對使用者可見的技術。
現在，所有重大功能在合併並推送到生產環境後，初始狀態均為關閉。真正的審查發生在「漸進式發佈」過程中：首先僅對內部團隊開啟，接著對少數客戶開啟，隨後擴展至 10% 的使用者，最後才全面開放。在這種機制下，PR 的行數不再是有效的信號，真正的關鍵指標變成了「影響範圍」（Blast Radius），即一旦出錯，受影響的範圍有多大。
影響與限制
這種轉向不僅發生在 Rootly，其他公司如備份服務商 Rewind 也採取了類似的風險導向模型，開發名為 Diff Vader 的工具，強調 PR 的風險與行數幾乎沒有關聯。甚至 DevOps 的推手 Patrick Debois 在 AI Native DevCon London 上提出，對於內部目標一致且共享上下文的團隊而言，傳統的 PR 審查流程在 AI 代理的高速運作下可能已變成一種反模式（Anti-pattern），因為其產生的協作開銷過高。
此外，AI 代理的成本（Token 費用）也強制團隊提升流程紀律。在純人力時代，低效的審查流程可能不易量化，但現在每一分浪費的 Token 都直接反映在帳單上。
然而，AI 無法完全取代人類，特別是在「為什麼」和「是什麼」的上下文定義上。Rootly 明確禁止 AI 代理生成 PR 的動機與範圍說明，要求由下達指令的人類負責填寫。這是為了捕捉 AI 所缺失的商業邏輯：為什麼要做這次變更？為什麼是現在做？商業理由是什麼？同時，每個 PR 必須詳細描述如何安全地撤銷變更，包括任何必要的數據修復方案。
總結來說，小型 PR 規則是針對人類手寫代碼的正確答案，但在協調 AI 代理交付完整功能的時代，將重心從「審查代碼」轉向「管控發佈風險」才是更高效且可靠的選擇。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。