GitHub 草稿 PR 也可計入限制：先設計代理工作的入口

代理產生程式碼越快，審查佇列也可能越長。草稿 PR 表示尚未準備好，不會讓工作從儲存庫負擔中消失。GitHub 的變化是重新檢視入口的機會。

10月8日的變化

GitHub 於2026年10月8日宣布，可設定 PR 限制將草稿也計算在內。過去草稿不計入使用者上限。這不代表所有儲存庫設定已自動改變。

公告旨在減少低品質貢獻及垃圾提交帶來的雜亂、通知與 CI 執行。沒有通用建議數值。先查看真實設定及適用範圍。

草稿表達準備程度，上限控制進入的工作量。未完成的工作也需要維護。但不能說所有草稿都執行昂貴 CI，應查看觸發條件與實際歷史。

為同一 issue 的三個方案各開草稿，方便比較，卻留下三個分支和 diff。它們是實驗，不是三次發布承諾。可行時在 issue 比較方案，再開目的明確且可審查的 PR。

記錄草稿和一般 PR 數量、負責人及目標、最後有意義的更新，再查看 CI、等待時間與重複 issue。憑通知太多的感覺設定上限，可能擋住有效貢獻。

代理流程應連結儲存庫、issue 和既有 PR。建立失敗時不要立刻換名字再開一個。先確認既有工作並更新。這是團隊營運建議，不是 GitHub 新增自動行為。

指引應包括如何繼續既有工作、審查準備標準與聯絡人。不要把轉成一般 PR 當作繞過策略的方法。關閉或封存前查看負責人和有用內容。

相依的多個 PR 不能只按數量判為低品質。小 diff 堆疊與重複提交不同。上限保護入口，不取代審查、測試或部署判斷。

在一個儲存庫記錄策略與例外，確認實際設定。同期間比較草稿成長、既有 PR 重用、等待時間與有效貢獻受阻。項目減少不等於品質提升。

先讓同一任務回到同一 PR，再提高代理頻率。GitHub 提供設定回饋管道。本文沒有編造未驗證的反應或改善數據。

2026年10月9日核驗。區分產品變化與營運建議。