AI 正在毀掉開源：從“協(xié)作圣地”到“垃圾洪水”，維護者士氣跌至谷底，開始集體掀桌

作者 | kate holterhoff

譯者 | 平川

策劃 | Tina

本文最初發(fā)布于 RedMonk 官方博客。

AI Slop 正在撕毀開源開發(fā)中維護者和貢獻者之間不可或缺的社會契約。從業(yè)者們一再得到保證，AI 將為他們的社區(qū)注入強勁的動力，但到目前為止，情況并非如此。看看上個月發(fā)生的事情就知道了。Mitchell Hashimoto 的 Ghostty 項目 實施 了一項零容忍政策，提交 AI 生成的糟糕代碼將導致永久封禁。tldraw 創(chuàng)始人 Steve Ruiz宣布，他將自動關(guān)閉所有外部拉取請求。與此同時，cURL，這個默默支撐著幾乎所有互聯(lián)網(wǎng)服務(wù)的命令行工具，剛剛終止了其漏洞懸賞計劃。在連續(xù)六年、支付 8 萬 6 千美元后，cURL 創(chuàng)始人兼首席開發(fā)者 Daniel Stenberg 終止了這項計劃。為什么？AI Slop。

為什么這是個大問題？因為我們所熟悉的“開放貢獻”時代可能即將結(jié)束。數(shù)十年來，開源貢獻者和維護者之間存在著某種隱性契約。通過參與其中，貢獻者可以獲得學習的機會、豐富自己的簡歷、推進所屬公司的目標，并成為比自身更宏大的事物的一部分。與此同時，維護者承諾培育社區(qū)、指導項目和貢獻者。這份契約意味著，雙方都已經(jīng)預見到這個過程中會出現(xiàn)一些糟糕的 PR，從歷史上看，糟糕的 PR 成本很高。編寫代碼需要耗費時間。理解代碼庫需要耗費精力。貢獻行為本身（在很大程度上）篩除了那些不認真的人。

AI 破壞了那個篩選器。現(xiàn)在，任何人都可以生成看似合理的貢獻，不需要理解代碼，不需要做出努力。貢獻的數(shù)量已經(jīng)使系統(tǒng)不堪重負。正如 Python 軟件基金會駐場安全開發(fā)者 Seth Larson 所 說：

我主要擔心的是那些獨自處理這個問題的維護者。如果不知道 AI 生成的報告越來越常見，那么他們可能會把大量的時間浪費在虛假的報告上，然后才知道發(fā)生了什么。浪費寶貴的志愿服務(wù)時間做你不喜歡的事情，并最終一無所獲，這會讓維護者們精疲力盡或遠離安全工作。

在這篇文章中，我將討論 AI Slop 時代的開源現(xiàn)狀，以及許多已經(jīng)精疲力盡的維護者的應(yīng)對方式。我研究了幾個已經(jīng)明確立場的項目，同時也關(guān)注了來自知名開源組織的具有代表性的生成式 AI 政策。最后，我提出了幾點關(guān)于繼續(xù)推進相關(guān)工作的總體建議。

什么是“AI Slop”？

在進一步討論之前，我們先定義下術(shù)語。AI Slop 不只是糟糕的代碼。開源社區(qū)一直在處理低質(zhì)量的貢獻，從一開始就一直如此。只要問問 Linus Torvalds 就知道了。1991 年，他在 comp.os.minix 新聞組里首次宣布了 Linux，從那時起他一直在發(fā)送“怒火郵件”。在開源軟件的（OSS）術(shù)語中，AI Slop 是指這樣一種情況：有人將 GitHub 問題粘貼到 ChatGPT 中，按下回車鍵，然后把輸出的東西直接提交，也不檢查它是否有效。一份看似合法的漏洞報告實際上描述了不存在的漏洞。一個聲稱能夠修復項目的拉取請求修復的卻是一個不存在的項目。這些通過氛圍編碼生成的補丁看似合理，卻暗含幻覺般的假設(shè)，或是干脆就是爛代碼。

Stacklok 聯(lián)合創(chuàng)始人兼首席執(zhí)行官 Craig McLuckie 對“氛圍編碼貢獻”的 看法 如下：

過去，我們常將 GitHub 問題標記為“新手友好問題”，充滿干勁的年輕工程師便會前來嘗試，通過解決這些問題積累經(jīng)驗，最終成長為社區(qū)貢獻者。這對我們有益，對他們也有益，最重要的是對整個社區(qū)大有裨益。 如今，如果我們把某個問題標記為“新手友好問題”，不用 24 小時就會被大量低質(zhì)量的氛圍編碼垃圾所淹沒，占用了本該真正用于做事的寶貴時間。這種通過代碼審查流程“將垃圾轉(zhuǎn)化為優(yōu)質(zhì)代碼”的模式，既損害生產(chǎn)力又打擊團隊士氣。

社區(qū)中的許多人正在集思廣益并設(shè)計解決方案原型。Hashimoto 建議 為 AI 生成的貢獻創(chuàng)建一個類似 “git blame” 這樣的東西，讓人們能夠分清“真正的專業(yè)知識或糟糕的代碼”。在 深入思考 了這個問題后，Continue 首席執(zhí)行官 Chad Metcalf 創(chuàng)建了 Leeroy（ AI 輔助代碼貢獻的歸屬透明化工具）來解決這個問題。

現(xiàn)在，流入維護者收件箱的垃圾數(shù)量呈數(shù)量級的增長，各地的維護者都在談?wù)撨@個問題。例如，在討論合并“為有效載荷字段模式添加 enable_hnsw 選項”功能的帖子中，Qdrant 聯(lián)合創(chuàng)始人兼首席技術(shù)官 Andrey Vasnetsov 就專門提到了垃圾代碼。過去幾年間，這一問題一直在持續(xù)不斷地惡化，對許多人而言，一月似乎是問題全面爆發(fā)的臨界點。

策略演變

維護者對 AI 提交的立場仍在不斷變化。

Stenberg 從 2024 年 1 月就開始抱怨 AI 生成的漏洞報告。到 2025 年年中，他報告說，curl 的漏洞賞金計劃中大約 20% 的提交是 AI Slop。那一年，只有 5% 的提交識別出了真正的漏洞，“有效率”與前幾年相比“顯著下降”。2025 年 5 月，Stenberg 添加了一個 復選框，要求提交者披露他們是否使用了 AI。這并沒有起到任何作用。7 月，他公開表示 考慮 完全取消漏洞賞金。到 2026 年 1 月，在十六小時內(nèi)收到 七份提交 后（其中部分是真實的 Bug；但均不是安全漏洞），他最終終止了該計劃。

Hashimoto 對待 AI 貢獻的方式也發(fā)生了變化。2025 年 8 月，他們開始 要求 強制披露。“如果你使用了任何形式的 AI 輔助來為 Ghostty 做貢獻，就必須在拉取請求中進行說明。”但到 2026 年 1 月底，他采取了零容忍態(tài)度。AI 生成的貢獻僅限于已經(jīng)接受的問題和維護者。Hashimoto 澄清說：

我們的立場不是反對 AI ，而是反對愚蠢。Ghostty 是在 AI 的大量輔助下編寫的，我們的許多維護者每天都使用 AI 。我們只是想要高質(zhì)量的貢獻，而不管它們是如何編寫出來的。

Ruiz 的反應(yīng)最激烈：tldraw 現(xiàn)在自動關(guān)閉了所有外部拉取請求，完全停止了。但他的理由指向了當今軟件開發(fā)領(lǐng)域中一個更哲學性的問題：

在一個 AI 編碼助手的世界里，外部貢獻者的代碼真的有價值嗎？如果編寫代碼變成了一項簡單的工作，我為什么要讓別人來寫呢？

像 Hashimoto 一樣，Ruiz 承認自己也在使用 AI，并且發(fā)現(xiàn)修復代碼比清理 AI 生成的 PR 更容易。其中一些最糟糕的 PR 是因為他自己編寫的 AI 腳本——他編寫的 Claude Code 命令，用于捕捉（/issue）和解決（/take）匆忙創(chuàng)建的問題——正在導致需要他關(guān)閉的 AI Slop 問題。貢獻者將這些糟糕的問題輸入他們自己的 AI 工具，而這些工具基于 Ruiz 所使用的 AI 的幻覺來生成 PR：“我那些敷衍了事的問題變成了敷衍了事的 PR，AI 包辦了雙方的工作。”一路上全是 AI Slop。

今天有人發(fā)布了 7 份安全報告，就我們項目的語境來看，它們完全不合邏輯顯然全是 AI 生成的這妨礙了我們對真正有效的報告作出響應(yīng)——那些報告才是來自真正理解我們項目的人https://t.co/WS7AxObOfl — dax (@thdxr) 2026 年 1 月 20 日

尚未決定立場的

盡管 AI Slop 問題在開源社區(qū)中普遍存在，但上述案例因其決斷性而顯得尤為獨特。如今，絕大多數(shù)開源項目仍持觀望態(tài)度，維護者和負責人正積極探討如何應(yīng)對這個不斷變化的問題。

Debian 便是其中一例。關(guān)于該項目內(nèi)部成員反復拉鋸的詳細記錄，可參閱 Joe Brockmeier 的文章：Debian AI 通用決議撤回。FluxCD 項目亦是如此。據(jù) 核心維護者 Stefan Prodan 所述：

“在 FluxCD，我們還沒有決定如何處理這個問題。因為它是一個 CNCF 項目，所以我們需要與其他項目保持一致。我們正在 Flux Operator 中嘗試系統(tǒng)提示功能，接下來我們將添加技能模塊。這是我們目前的 AI 指南：https://github.com/controlplaneio-fluxcd/flux-operator/blob/main/AGENTS.md”

等待觀望一下是個明智的做法。AI 工具生態(tài)每個月都在變化——今天的 Slop 明天可能就與人類編寫的代碼無法區(qū)分，1 月份制定的政策可能 6 月份就過時了。許多開源項目的推進速度依賴于共識，而不是命令。像 Debian 這樣的項目之所以采用一般決議和漫長的郵件列表討論這樣的運作模式，正是因為其合法性來自社區(qū)的認同，而不是自上而下的命令。Linux 內(nèi)核的開發(fā)流程——眾所周知由 Linus 的個人偏好和分布式維護者網(wǎng)絡(luò)主導——往往需要數(shù)年時間才能吸納重大的程序變革。即便規(guī)模較小的項目，也往往缺乏能像 Stenberg 、Hashimoto 和 Ruiz 那樣果斷決策的單一維護者權(quán)威結(jié)構(gòu)——多數(shù)項目由指導委員會、共識模式或純粹基于默契的合作機制來管理，無人能單方面拒絕 AI 貢獻。面對海量的 AI 貢獻，許多項目選擇暫時順勢而為，而非徹底退出這一浪潮。

開源基金會怎么說

你可能會想：關(guān)于這個問題，就沒有一個機構(gòu)來幫助我們指引方向嗎？各種開源基金會沒有政策嗎？他們有！如果你仔細看的話，有一點。問題是，這些政策大多數(shù)都聚焦在許可上，并沒有解決維護者面臨的 AI Slop 危機。AI 生成的代碼所有權(quán)歸誰？如果 Copilot 將遵循 GPL 協(xié)議的代碼重新復制到遵循 MIT 許可的項目下會怎樣？這些都是實實在在需要擔憂的問題！但那不是讓 Stenberg 寫下“死于千百個 AI Slop ”這篇博文的原因。

Linux 基金會官方有一個 生成式 AI 政策，基本上是說，只要許可問題解決，AI 生成的代碼就可以作為貢獻。他們專注于確保 AI 工具條款與開源許可的兼容，并且貢獻者有權(quán)使用任何混入輸出結(jié)果的第三方代碼。

Apache 軟件基金會在 2023 年發(fā)布了 生成式工具指南，建議貢獻者在提交消息中使用 “ Generated-by: ” 標簽披露 AI 使用情況。他們明確承認，這是“一個快速發(fā)展的領(lǐng)域”，需要不斷更新。

Eclipse 基金會有一份提交者指南，其中強調(diào)了 AI 容易出錯的問題，并提醒提交者他們有責任確保代碼的準確性。他們還建議在版權(quán)和許可標題下方加上 AI 生成代碼的免責聲明，如“某些部分由 Co-Pilot 生成。”

開放基礎(chǔ)設(shè)施基金會采用了 “ Generated-By: ” 和 “ Assisted-By: ” 標簽，并要求審核者將 AI 生成的代碼視為來自“不可信來源”，需要加強審查。

這個列表并不全面，但是我所見過的情況中比較有代表性的。問題在于，許多基金會制定的政策都基于這樣一個世界觀：法律責任是唯一需要考慮的問題。維護者精疲力竭？質(zhì)量控制指導？這些根本不屬于他們的職責范圍。盡管維護者們?nèi)缃裾钕堇a的泥潭，但各基金會至今仍未挺身而出，給他們拋個救生圈。

極端選項

一些項目選擇完全禁止 AI 生成的代碼。這種做法雖顯粗暴，且批評者認為難以執(zhí)行，但對選擇這條道路的項目而言，禁令不僅是簡單的門檻把控，更具有多重意義：它能篩除臨時客串的貢獻者，同時向外界傳遞項目希望培育何種文化的信號。

Gentoo Linux 在 2024 年 4 月完全禁止了 AI 生成的貢獻，理由是版權(quán)問題、質(zhì)量問題和倫理問題（特別是訓練這些模型時對環(huán)境造成的影響）。提出 禁令的 Micha? Górny 向 Register 解釋說：

我認為，這對 Gentoo 來說是一個不錯的公關(guān)舉措……當許多項目對 AI” 充滿熱情時，我覺得許多 Gentoo 用戶真的更欣賞那種老派的軟件工程方法，人類比“生產(chǎn)力”更重要。

Górny 的表述似乎有一種反文化的東西。在一個癡迷于速度和自動化的行業(yè)中，Gentoo 的立場與一個一直重視工藝而非便利性的社區(qū)產(chǎn)生了共鳴。

NetBSD 在其 提交指南 中也效仿了這一做法，將 LLM 生成的代碼歸類為“已被污染（tainted）”——這意味著沒有核心團隊的事先書面批準，不能提交這些代碼。BSD 項目有一個額外的擔憂：他們的許可協(xié)議意味著他們要避免意外地合并遵循 GPL 協(xié)議的代碼，而 AI 工具在 GitHub 上訓練時有一個壞習慣，那就是復制 GPL 代碼。想進一步了解的話，可以看下由日本開源組織主席 Shuji Sado 撰寫的文章：GPL 許可傳播至基于 GPL 代碼訓練的 AI 模型的理論現(xiàn)狀。

關(guān)于開源的未來，這些極端選項告訴了我們什么？首先，它們表明，對于一些社區(qū)來說，AI 生成代碼的感知風險超過了任何潛在的生產(chǎn)力增益。這些項目正刻意選擇優(yōu)先優(yōu)化信任與溯源機制，而非追求吞吐量。其次，它們凸顯了一個令人不安的事實——這種趨勢只會愈演愈烈：合規(guī)性審查終究只是象征性舉措。隨著 AI 生成的代碼與人類編寫的代碼日益難以區(qū)分，違規(guī)檢測將從具有挑戰(zhàn)性轉(zhuǎn)變?yōu)閹缀醪豢赡芡瓿傻娜蝿?wù)。。

今天的 AI Slop 還是顯而易見的——幻覺導致的函數(shù)調(diào)用、自以為正確卻實則錯誤的表述、令人費解的冗長描述。但這些模型正在快速進化。一兩年內(nèi)，問題將不再是“我們能否檢測到 AI 生成的代碼？”，而是“如果檢測不到有什么問題嗎？”這些禁令的真正意義可能不在于它們的可執(zhí)行性，而在于它們揭示了開源社區(qū)越來越多的人不再將 AI 輔助開發(fā)視為一個需要管理的必然性，而是看成是對協(xié)作式軟件開發(fā)這一人類事業(yè)的根本性威脅。

激勵問題

（點擊這里查看動圖）

AI Slop 危機不僅僅是一個技術(shù)問題或文化問題，它還是一個經(jīng)濟問題。在開源維護者和托管其工作的平臺之間，這一點表現(xiàn)得尤為明顯。

2025 年 5 月，GitHub 推出了一個功能，允許用戶使用 Copilot 生成問題。你只需向 AI 描述問題，它便會生成格式規(guī)范的 Bug 報告文本，隨后即可提交。在宣布該功能的博文中，GitHub 承諾，此舉將使問題的創(chuàng)建過程“更快更輕松且不會犧牲質(zhì)量”。對這個“質(zhì)量”，維護者們提出了不同的看法。

幾乎同時，人們開始詢問能夠阻止 Copilot 生成的問題進入他們存儲庫的方法。GitHub 的回應(yīng)基本上是“沒有辦法”。用戶無法被屏蔽 Copilot 機器人，Copilot 生成的問題甚至沒有標明它們是 AI 生成的。相反，它們出現(xiàn)在人類用戶的名下，沒有任何跡象表明是機器人輸入的。所以你無法過濾。

于許多擔心 AI Slop 的開發(fā)者來說，這是一個無法解決的問題。正如 Andi McClure 在 2026 年 5 月的一個 GitHub 問題中所解釋的那樣：

如果我們得不到這樣的工具，而 “AI” 垃圾提交確實成了一個問題，我可能被迫采取極端行動，比如在我的存儲庫上完全關(guān)閉問題和 PR，并把問題托管轉(zhuǎn)移到像 Codeberg 這樣的網(wǎng)站 [一個非營利性代碼庫]，它們沒有將這些對維護者不友好的工具直接內(nèi)置在網(wǎng)站中。

根本問題在于激勵機制的一致性。當人們使用 GitHub 時，GitHub 會賺錢，而 AI 功能增加了用戶粘性指標。對于這種情況，Prodan 做出了負面的診斷：

AI 生成的低質(zhì)量代碼正在對開源軟件（OSS）維護者進行分布式拒絕服務(wù)攻擊（DDOS），而托管開源項目的平臺并沒有動機去阻止這種行為。相反，他們有比較大的動力去夸大 AI 生成的貢獻，以便向他們的股東展示“價值”。

作為開源開發(fā)的主導平臺，這種緊張關(guān)系使 GitHub 幾乎成為所有 AI Slop 討論的核心。當 GitHub 決定不允許屏蔽 Copilot 生成的問題時，這一決策影響了數(shù)百萬個存儲庫及其維護者。在解釋 tldraw 項目完全關(guān)閉外部貢獻的決定時，Ruiz 明確指出 了這種關(guān)聯(lián)，并暗示該策略是根據(jù) GitHub 提供的工具情況而定的：

這是一個臨時政策，但在 GitHub 提供更好的貢獻管理工具之前會一直有效。

這向 GitHub 傳達的信息再清楚不過了：你提供的工具有可能迫使一些維護者放棄開放貢獻模式。但 GitHub 是否理解到了這層信息，或者是否有恰當?shù)膭訖C去采取行動，還尚未可知。這家公司似乎在賭，AI 功能吸引的用戶會比因此而失去的用戶多，那些威脅要離開去 Codeberg 或采用自托管解決方案的維護者最終會留下來，因為 GitHub 的網(wǎng)絡(luò)效應(yīng)太強，無法放棄。問題是，AI Slot 危機是否會成為一個轉(zhuǎn)折點，抑或維護者們將被迫適應(yīng)這樣一個世界——他們所依賴的平臺更注重用戶參與度而非可維護性。

AI Slop 時代的最終建議

外面簡直是他媽的戰(zhàn)場啊兄弟。維護者士氣跌至歷史最低點。我完全理解那些直接掀桌子完全禁止所有 AI 的項目。我快要宣布只有維護者和已接受的問題才能使用 AI 了。 —— Mitchell Hashimoto (@mitchellh) 2026 年 1 月 16 日

如果你是貢獻者：展示你的工作。以人類的身份參與。理解你提交的內(nèi)容。如果你使用 AI，請像 Joshua Rogers那樣 使用它：他向 Stenberg 發(fā)送了一個潛在問題列表，上面有“大量”通過 AI 輔助工具發(fā)現(xiàn)的問題，其結(jié)果是有五十個真正的 Bug 得到了修復。Rogers 展示了如何正確地使用 AI 而不取代批判性思維。

如果你是維護者：制定清晰的政策，公開記錄它們，而不要默默地忍受。你并不孤單，你的挫敗感是合理的。

如果你在平臺工作：構(gòu)建服務(wù)于維護者的工具，而不僅僅是專注于參與度指標。為他們提供過濾、阻止和管理洪水的能力。

如果你在基金會工作：現(xiàn)在是時候解決質(zhì)量和疲勞問題了，而不僅僅是許可問題。法律問題很重要，但你的社區(qū)現(xiàn)在正處于水深火熱之中。

如果你是那些向開源項目提交 AI Slop 的人，希望用零努力的 PR 來填充你的 GitHub 貢獻圖？請不要再這樣做。

免責聲明：GitHub / 微軟和谷歌是 RedMonk 的客戶。

文章開頭的圖片由 Google Nano Banana 生成。

https://redmonk.com/kholterhoff/2026/02/03/ai-slopageddon-and-the-oss-maintainers/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。