每天早上打開GitHub，維護(hù)者們的通知中心就像一個炸了鍋的群聊。幾十條新拉取請求堆在最上面，標(biāo)題從“修復(fù)了一個錯別字”到“重構(gòu)了整個模塊”都有，中間還夾著幾條明顯的垃圾信息。這些請求都等著同一個人的同一份注意力，但人的審查速度，十幾年來幾乎沒變過。

過去，創(chuàng)一個拉取請求實在太容易了，幾秒鐘點(diǎn)幾下鼠標(biāo)就好?？勺聛碜屑?xì)看代碼、跑測試、想明白這改動對項目有沒有用，還是得花掉至少十幾分鐘。當(dāng)高質(zhì)量的貢獻(xiàn)和低質(zhì)量的噪音混在同一個隊列里，那些真正值得關(guān)注的改動反而更難被翻出來。

這就是GitHub推出拉取請求數(shù)量限制的直接原因。這個功能盯住了一個被抱怨最多的問題：涌進(jìn)來的拉取請求太多，低質(zhì)量噪音太吵，能管住這個流量的手段又太少。

數(shù)據(jù)更能說清楚壓力有多大。2023年1月，整個GitHub上開發(fā)者每月合并的拉取請求大約在2500萬個。到了現(xiàn)在，這個數(shù)字已經(jīng)沖破了9000萬。創(chuàng)建成本遠(yuǎn)遠(yuǎn)把審查成本甩在了身后。

新推出的拉取請求限制，工作方式很直接：倉庫可以設(shè)定一個最大數(shù)量，用來卡住沒有寫權(quán)限的用戶能同時打開的拉取請求數(shù)。一旦到了上限，這個用戶就得先把已有的關(guān)閉或合并一個，才能再開新的。

而且這個限制把現(xiàn)在的新生態(tài)也考慮進(jìn)去了。由Copilot或其他AI代理打開的拉取請求，同樣會被計入這個配額。也就是說，如果用AI生成了好幾個改動想一起提交，這些都會被數(shù)進(jìn)去，不可能靠工具無限刷數(shù)量。

對于信得過的貢獻(xiàn)者，倉庫維護(hù)者可以把他們放進(jìn)一個繞過名單。這些人不受數(shù)量上限的限制，但也不會因此拿到更完整的寫入權(quán)限，只是被豁免了限制而已。另外，草稿拉取請求不算在額度里，這給還在打磨中的工作留了一條路。

GitHub之前就有過交互限制功能，但那些是臨時的冷卻措施，像是某個用戶太猛了就給降降溫。而這次的拉取請求限制是持續(xù)生效的，而且各項參數(shù)都可以自己配置。用維護(hù)者們反饋的話來說，這就是他們一直覺得缺少的那個控制開關(guān)。

這個上限不但改變了倉庫的節(jié)奏，也直接扭轉(zhuǎn)了貢獻(xiàn)者的行為模式。在誰都能幾秒鐘內(nèi)丟一個拉取請求過來的環(huán)境下，一個打磨了很久的精心改動和一個剛拼湊出來的粗糙草稿，在隊列里看起來幾乎沒差別。兩者靜靜排在一起，等著維護(hù)者一個個點(diǎn)開才能分清。

可一旦每個人只能同時開著很少幾個拉取請求，情況就不一樣了。貢獻(xiàn)者不得不主動做一次篩選，把自己最想讓維護(hù)者看到的那一個或幾個挑出來。這個判斷在拉取請求還沒到達(dá)你眼前的時候就已經(jīng)發(fā)生過了。

于是，維護(hù)者眼前剩下的池子小了很多。那些真正準(zhǔn)備好了的、思考得更清楚的改動，就更容易被人注意到。用AutoGPT的Nicholas Tindle的話來說，這種變化讓他們重新愿意做審查這件事?！爸缹Ψ?jīng)]有一口氣開五到十個全是湊合質(zhì)量的拉取請求，心里會輕松很多，也更容易想認(rèn)真看看。”他還提到，往后這能幫他們管好積壓的工作，并且確保大家正在做的都是真正需要的東西。

Homebrew的Mike McQuaid也對這個功能點(diǎn)了贊。他回憶起在Homebrew項目里遇到過的那種情況：一批熱情很高的用戶，接連提交了許多拉取請求，但每一個需要做的審查幾乎都是重復(fù)的、極其相似的工作。AI的介入又進(jìn)一步加快了這種提交的速度，讓同類問題變得更加突出。

McQuaid覺得，現(xiàn)在的限制讓他們既能繼續(xù)接納來自外部的貢獻(xiàn)，也能把用戶提交的拉取請求數(shù)量控制在自己團(tuán)隊能夠應(yīng)付的水平上。維持一個開源項目，不至于被過量的熱情沖垮節(jié)奏。

OpenClaw的Vincent Koc則講述了另一個側(cè)面。由于接收到海量的社區(qū)拉取請求，他們之前甚至不得不自己動手開發(fā)專門的機(jī)器人來對付垃圾信息?？吹紾itHub這次直接給出了維護(hù)者可以開箱即用的解決方案，他直言非常高興，認(rèn)為這終于能讓他們更省力地去管好這個體量的流量。

拉取請求的創(chuàng)建成本跌到幾乎為零的今天，審查成本卻依然嵌在人的時間表里。被數(shù)量淹沒不再是某一天的例外，而是每天一睜眼就會遇到的常態(tài)。GitHub這次給出的回答，是把篩選的動作提前到提交之前，讓人重新拿回一點(diǎn)選擇先看什么的權(quán)利。