GitHub 近期宣布將 Stacked Pull Requests 功能推向公開預覽階段。這項功能旨在讓開發者能將龐大的軟體變更拆解為一系列彼此依賴的小型 Pull Request，並允許審核者獨立地對這些小片段進行審查與合併。這不僅是開發流程的優化，更是 GitHub 針對現代軟體開發中，AI 產能與人類審核能力之間失衡問題所提出的解決方案。
開發瓶頸的轉移與背景
在傳統的開發流程中，開發者通常會建立一個功能分支，完成所有開發後提交一個大型的 Pull Request（簡稱 PR，即請求將程式碼變更合併回主分支的機制）。然而，隨著 AI 輔助開發工具的普及，程式碼的生成速度大幅提升，AI 能在短時間內產出大量可運行的代碼。
這種速度的提升帶來了一個嚴峻的矛盾：雖然寫程式的速度快了，但代碼審核（Code Review）本質上仍是一項高度依賴人類認知能力的活動。當一個 PR 包含數百甚至數千行代碼時，審核者的認知負荷會劇增，容易導致審核品質下降、遺漏缺陷，或者因為 PR 過大而導致審核週期被無限拉長。這使得代碼審核變成了軟體交付流程中的主要瓶頸。
Stacked Pull Requests 的運作核心
Stacked Pull Requests 引入了一種層疊式的開發模式。開發者不再提交一個巨大的單一 PR，而是將工作組織成一串邏輯上的序列。例如，開發一個新功能時，可以將其拆分為：第一個 PR 建立 API 定義，第二個 PR 更新資料庫結構，第三個 PR 實作具體的業務邏輯。
每個後續的 PR 都建立在前一個 PR 的基礎之上。這種方式允許審核者一次僅專注於一個邏輯步驟，大幅降低了理解成本。同時，開發者不需要等待整個功能完全開發完成才開始提交，而是可以隨著進度逐步推送。GitHub 的這項實作保留了原有的分支保護規則、審核工作流與合併政策，讓這種層疊開發模式能自然地融入現有的儲存庫管理實踐中，而不需要強迫團隊改變既有的管理習慣。
提升開發流動性與工程品質
除了減輕審核壓力，層疊式開發更能有效改善開發者的工作流（Developer Flow）。在傳統模式下，基礎功能的開發往往會阻塞後續工作的推進，直到基礎部分被審核通過。而透過 Stacked PR，開發者可以在前一個層級仍處於審核狀態時，直接在該基礎上繼續構建下一層的功能。
這種做法減少了對長週期功能分支（Long-lived Feature Branches）的依賴，進而降低了頻繁發生合併衝突（Merge Conflicts）或代碼過時的風險。從工程文化來看，這鼓勵開發者將軟體變更視為漸進式的架構改良，而非單次的大規模交付，這在實務上已被證明能降低部署風險並縮短反饋週期。
技術脈絡與行業趨勢
層疊開發的概念並非創新，Meta 內部早已普及所謂的 Stacked Diffs 工具，而 Graphite 和 Sapling 等第三方工具也圍繞此概念建立產品。許多 GitHub 用戶先前必須依賴這些外部工具或繁瑣的手動分支管理來達成類似效果。GitHub 將此功能原生化，消除了導入第三方工具的運作成本，讓更多團隊能低門檻地採取這種高效工作流。
相關研究顯示，儘管 AI Agent（能自主執行任務的 AI 代理）生成的 PR 越來越多，但成功的整合依然高度依賴經驗豐富的人類審核者。代碼審核已成為決定 AI 是提升還是降低軟體品質的關鍵控制點。
影響與限制
GitHub 推出此功能，反映了軟體工程重心從生成代碼轉向管理代碼的趨勢。當 Copilot 等 AI 工具能快速產出代碼時，工程組織的核心競爭力將不再於寫程式的速度，而是在於如何安全、透明且大規模地審核並整合這些代碼。
雖然 Stacked PR 解決了審核範圍過大的問題，但它對團隊的協作紀律提出了更高要求。開發者需要具備更強的拆解能力，將複雜功能切分為合理的邏輯單元。此外，當底層的 PR 發生重大修改時，上層依賴的 PR 可能需要重新調整（Rebase），這在複雜的依賴鏈中仍具有一定的管理挑戰。
總結而言，隨著 AI 持續加速開發速度，層疊式 PR 可能從一種便利的選項變成一種必然的基礎設施。在自動化生成代碼的時代，能夠高效審核並安全整合代碼的能力，將定義高績效工程組織的標準。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。