GitHub一邊慶祝AI為開源生態(tài)帶來的"巨大貢獻"，一邊卻對貢獻質(zhì)量的斷崖式下跌視而不見。當大多數(shù)科技公司都在歌頌AI輔助編程的生產(chǎn)力神話時，一個獲得VC支持的AI原生項目——Archestra選擇站出來說真話：AI垃圾正在系統(tǒng)性地毀掉開源生態(tài)。

今年早些時候，Archestra團隊在一個GitHub Issue上掛出了900美元的懸賞，希望吸引開發(fā)者為平臺添加MCP Apps支持。真正有價值的貢獻者很快出現(xiàn)了——他們提出方案、提出問題、提交嘗試，但接下來發(fā)生的事情完全超出了預期。AI機器人蜂擁而至，迅速將這個Issue的評論數(shù)推到253條，其中充斥著毫無意義的"實施方案"和對維護者的攻擊性言論。

這僅僅是開始。AI賬號不僅轟炸這一個Issue，而是橫掃整個代碼庫。每一條敷衍的評論都會觸發(fā)所有關(guān)注者的通知，GitHub通知變成了一堵噪聲之墻。真正在做事的人——比如正在攻克“懸賞issue”的@ethanwater、@developerfred、@Geetk172——他們的對話被淹沒在垃圾信息中。

更嚴峻的問題出現(xiàn)在PR層面。僅為了添加x.ai提供商支持這一個功能，Archestra就收到了27個PR，其中大多數(shù)貢獻者甚至沒有嘗試過運行他們提交的代碼。團隊成員不得不每周花費半天時間清理這些AI垃圾——刪除未經(jīng)測試的PR、關(guān)閉虛假Issue。當團隊忘記及時清理時，代碼庫迅速變成了一個對合法貢獻者完全敵對的地方。

安全風險也隨之而來。就在LiteLLM代碼庫中，攻擊者試圖利用AI機器人來引導對話走向——這不再是煩人的問題，而是真實的安全威脅。

面對這種局面，Archestra首先嘗試構(gòu)建"聲譽機器人"來計算貢獻者的可信度，但顯然無法阻止spam。隨后推出的"AI sheriff"甚至誤傷了合法PR。持續(xù)的垃圾信息流正在趕走真正的貢獻者，迫使團隊開始考慮：是否應(yīng)該停止用懸賞激勵貢獻？是否應(yīng)該停止向求職者提供有趣的測試任務(wù)？

最終，Archestra選擇了反擊：通過onboarding系統(tǒng)（https://archestra.ai/contributor-onboard）實現(xiàn)白名單機制。他們在網(wǎng)站上建立了一套五步onboarding流程，要求貢獻者必須通過ethical AI規(guī)則驗證和CAPTCHA測試。但問題在于GitHub本身并不提供"僅限白名單用戶評論或提PR"的選項——Archestra不得不利用Git commit的author字段和GitHub的"prior contributor"設(shè)置來實現(xiàn)這一目標。

具體方案頗為巧妙：GitHub將"prior contributor"定義為在main分支上有commit作者身份的人。通過Git的--author參數(shù)，可以用他人的身份創(chuàng)建commit——只要郵箱與他們的GitHub賬號匹配，該commit就會被歸因到他們名下，授予貢獻者身份。Archestra構(gòu)建了一套自動化流程：用戶在網(wǎng)站onboarding后，GitHub Action會自動查詢用戶的GitHub ID，生成一個以用戶身份創(chuàng)建的commit，將他們添加到外部貢獻者名單，從而獲得代碼庫訪問權(quán)限。

Archestra承認這是一個"終極手段"，對于一家用GitHub活動數(shù)據(jù)衡量團隊表現(xiàn)的VC支持的創(chuàng)業(yè)公司來說尤其敏感。但它的態(tài)度很明確：質(zhì)量重于數(shù)量，不要被AI垃圾填充的指標。

這不僅是某個項目的困境。當GitHub報告的指標增長中相當一部分來自AI生成內(nèi)容時，整個開源生態(tài)正在默默承受著清潔AI垃圾的沉重負擔。AI輔助編程的浪潮中，我們需要認真思考：所謂的生產(chǎn)力提升，是否正在以犧牲開源生態(tài)的健康為代價？

參考來源：https://archestra.ai/blog/only-responsible-ai