🔧 阿川の電商水電行
也就是說，能夠提出拉取請求（Pull Request，以下簡稱 PR）的使用者，預設是在某種程度上理解程式碼。
開發者（Collaborator）與外部貢獻者（Contributor）之間是基於信任模型連結的。
反過來說，不理解程式碼的人所提出的 PR 往往一眼就能看出問題，因此對開發者造成的認知負荷並不高。
因此 GitHub 上的 PR 並沒有存取控制機制，而且也無法刪除 PR。
雖然可以針對合併做出控制（例如要求審查或禁止直接合併），但根本上並沒有「限制能否提出 PR」的概念。
這個模型在數年前運作得非常良好。
然而，AI 的發展把這一切都打破了。
現在可以極為容易地大量產生那些由幾乎不理解程式碼、或完全不理解程式碼的使用者所提交、表面看起來很像樣但實際上胡亂的貢獻。
這導致審查者的負擔暴增，許多專案正在發出悲鳴。
不用說，單靠「教化使用者」絕對無法解決這個問題。
因此出現了像 Vouch — 拒絕低品質貢獻工具 這類的做法。
到了這個地步，GitHub 終於動了起來，於 2026/02/13 推出、終於推出了 對拉取請求的存取限制。
現在可以在「誰可以提出拉取請求」上選擇：『全部使用者』、、『僅協作者（Collaborator）』、或『停用』。
若選擇停用，拉取請求的分頁會直接消失。
對於鏡像儲存庫或未來不打算更新的儲存庫等不需要 PR 的情況，可以禁止 PR。
例如 Linux 的 GitHub 儲存庫 本身是放在其他地方的主體鏡像，對這裡的拉取請求一直都是被忽略的。
過去如果提出 PR，會有類似「本倉庫不接受 PR」的機器人回應；隨著此次功能加入，該倉庫的拉取請求分頁已經消失了。
順帶一提，自從先前的「驅逐俄國開發者」騷動之後，該處曾被大量提交刪除 MAINTAINERS 的 PR 攻佔，頗有趣，但現在看不到了有點可惜。
此功能自一月底左右便在 GitHub 社群中討論，最終實現。
存取控制的機制不會止於 PR 限制，未來還預計會持續加入更多功能。
以下是對應的討論串 Exploring Solutions to Tackle Low-Quality Contributions on GitHub 的介紹。
探索應對 GitHub 低品質貢獻的解決方案
針對影響開源社群的一項重要問題，我們提供最新消息：
低品質貢獻已成為維護者在營運上承受的重大負擔。
有意見指出，維護者被迫花費大量時間審查不符合專案品質標準的貢獻。
原因包括違反專案指引、提交後立刻失聯，以及這些貢獻常為 AI 生成。
在 AI 持續改變軟體工作流程的情況下，我們欲著手解決此問題，並開發短期與長期的解方。
我們正在探討的方向
我們彙整了社群回饋、與維護者直接交流，並嘗試各種解決方案。
目前正在檢討的方案概要如下。
■ 短期方案
-
控制拉取請求的權限。
這是自 2016 年以來就被廣泛要求的功能，將成為維護者客製化 PR 權限的第一步。
儲存庫擁有者可以將可提交貢獻的使用者限制為僅協作者，或在鏡像儲存庫禁止 PR，從而細緻控制 PR 存取。
這可以取代許多專案自行實作的貢獻管理機制。 -
刪除拉取請求的功能。
維護者可以刪除低品質的 PR 或垃圾內容。
■ 長期方向
-
強化權限模型。
提供能客製化 PR 權限的工具。不僅能封鎖所有使用者或限制為協作者，還能更細緻地控制誰能建立與審查 PR，並定義 PR 必須符合的準則。 -
改善分流（Triage）工具。
以 AI 根據專案指引與標準評估貢獻，並突出值得優先審查的貢獻。 -
明確標示 AI 協助的貢獻。
在 PR 生命週期中，清楚顯示使用 AI 工具時的可視性與歸屬。
下一步
這些只是出發點，我們會持續尋求短期與長期的改進方案。
歡迎提供回饋、問題或關切事項。
留言區
目前已累積超過 200 則留言。
Mossaka
你好！
我在 Azure Core 團隊，團隊裡有很多 OSS 的維護者。
在公司內部舉辦了關於 Copilot 的討論會，維護者反映出他們被要求的審查嚴格度，與 AI 生成程式碼之間的落差越來越大，變得日益難以為繼。
- 以「提交者能夠充分理解原始程式碼」為前提的信任模型已崩壞。
- AI 生成的 PR 在結構上看似沒問題，但在邏輯或安全性上可能錯誤。
- 審查者習慣做逐行審查，但面對 AI 產生的大規模 PR 無法應付。
- 我們不願意對不理解規格的人給予核准，但 AI 讓這種情況容易發生。
- 審查者現在不得不同時評估程式碼是否恰當，以及 PR 提交者是否真的理解程式碼。
審查負擔不但沒有因 AI 而減輕，反而越來越重。
MuchuCAT
以維護者的觀點來說，問題並非 AI 本身，而是成本的非對稱性。
提交貢獻的成本變得非常低，但相對地，審查、分流與溝通的成本完全沒有降低。
iBug
作為 mmistakes/minimal-mistakes 的維護者，我面臨大量垃圾 PR。
若有某種品質管制介入，會有很大改善。
我現在使用這個 Action自動關閉無用的 PR，但更希望從源頭避免這些 PR 被提交。
sirosen
可以考慮限制新成為協作者的人，只能同時擁有一個開放中的 PR。
另外希望能有功能把 PR 明確標記為 abandoned 並關閉。這不是拒絕，但表示我們不打算替提交者完成缺少的工作，作為一個訊號。
xavidop
可以在專案中預先定義規則或提示，並根據這些規則評估 PR。
不符合規則的 PR 可以被標記或自動關閉。
moraesc
xavidop，那是我們正在考慮的項目之一。
例如把 CONTRIBUTING.md 作為指引來活用。
duskwuff
希望有政策功能，讓儲存庫擁有者可以明確說明如何處理 AI 協助的貢獻。
若政策禁止 Copilot，則在該儲存庫中自動停用 Copilot。
ann4belle
一個很好的想法：禁止 AI 生成的 PR 與議題，除非專案明確允許。
sanny-io
GitHub 把所有負擔丟給社群，但對低品質 PR，甚至垃圾訊息（SPAM）都沒有做足夠處理。
我多次向支援反映垃圾問題，但每次都很失望。
最近一次回應是在三週後才來，且認為這則垃圾留言毫無問題，令人失望。
rmacklin
若在中途禁止 Issue，會導致過往的 Issue 全都無法瀏覽，這是明顯的缺點。
會有改進計畫嗎？
PraiseTechzw
我擔心這會對想要開始貢獻的新手造成過大影響。
或許不是全面性限制，而是找方法過濾 PR 的方向會比較有希望。
moraesc
PraiseTechzw，例如可以要求在提出 PR 前先開一個 Issue，或依據 CONTRIBUTING.md 的規則來驗證 PR。
funnelfiasco
Ghostty 採用的是「以討論為先（discussion-first）」的方法。
把 PR 與 Issue 或討論串連結的做法我覺得不錯。
weisdd
funnelfiasco，那個方法的問題是熱門專案往往有大量被放置的 Issue，這會成為 AI 大量生成 PR 的來源。
我最近就看到這類帳號，結果不得不花時間整理 Issue。
感想
不過你們當初無視大量的疑慮而強行導入 Copilot，不是嗎？
至少現在能夠方向轉變，還算值得一點肯定。
目前來說，短期方案的第一步終於啟動了。
限制拉取請求提交者的第一道解方已經實裝，不過刪除 PR 的功能還沒有。
不過這應該不會太久才會被補上。
例如不小心在 PR 裡洩漏密碼的問題，也終於有望被徹底解決。
另一方面，長期願景還遠未開始。
例如若想「基本上禁止 PR，但對少數使用者個別允許 PR」，目前只能把那些人設為協作者，這樣的權限過大。
要做那種細緻的控制，仍然得依賴像 Vouch 這類工具。
話說回來，寄到 mmistakes/minimal-mistakes 的那些 PR 明顯是 AI 生成，但根本看不出他們的目的到底是什麼。
原文出處：https://qiita.com/rana_kualu/items/78fdef38b201985cb0d9
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
![![01.png]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F26088%2F1cfc683f-c6d5-44e5-bb64-ffc4dcc43c53.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=114eb32cf912ca00181d7144b9fb98dd){kind=link}