作者 | kate holterhoff（RedMonk）

譯者 | 平川

策劃 | Tina

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

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

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

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

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

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

什么是“AI Slop”？

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

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

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

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

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

策略演變

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

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

Hashimoto 對待 AI 貢獻(xiàn)的方式也發(fā)生了變化。2025 年 8 月，他們開始 要求 強制披露?！叭绻闶褂昧?* 任何形式的 AI 輔助** 來為 Ghostty 做貢獻(xiàn)，就必須在拉取請求中進(jìn)行說明?！钡?2026 年 1 月底，他采取了零容忍態(tài)度。AI 生成的貢獻(xiàn)僅限于已經(jīng)接受的問題和維護(hù)者。Hashimoto 澄清說：

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

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

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

像 Hashimoto 一樣，Ruiz 承認(rèn)自己也在使用 AI，并且發(fā)現(xiàn)修復(fù)代碼比清理 AI 生成的 PR 更容易。其中一些最糟糕的 PR 是因為他自己編寫的 AI 腳本——他編寫的 Claude Code 命令，用于捕捉（/issue）和解決（/take）匆忙創(chuàng)建的問題——正在導(dǎo)致需要他關(guān)閉的 AI Slop 問題。貢獻(xiàn)者將這些糟糕的問題輸入他們自己的 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)度，維護(hù)者和負(fù)責(zé)人正積極探討如何應(yīng)對這個不斷變化的問題。

Debian 便是其中一例。關(guān)于該項目內(nèi)部成員反復(fù)拉鋸的詳細(xì)記錄，可參閱 Joe Brockmeier 的文章：Debian AI 通用決議撤回。FluxCD 項目亦是如此。據(jù) 核心維護(hù)者 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 月份就過時了。許多開源項目的推進(jìn)速度依賴于共識，而不是命令。像 Debian 這樣的項目之所以采用一般決議和漫長的郵件列表討論這樣的運作模式，正是因為其合法性來自社區(qū)的認(rèn)同，而不是自上而下的命令。Linux 內(nèi)核的開發(fā)流程——眾所周知由 Linus 的個人偏好和分布式維護(hù)者網(wǎng)絡(luò)主導(dǎo)——往往需要數(shù)年時間才能吸納重大的程序變革。即便規(guī)模較小的項目，也往往缺乏能像 Stenberg 、Hashimoto 和 Ruiz 那樣果斷決策的單一維護(hù)者權(quán)威結(jié)構(gòu)——多數(shù)項目由指導(dǎo)委員會、共識模式或純粹基于默契的合作機(jī)制來管理，無人能單方面拒絕 AI 貢獻(xiàn)。面對海量的 AI 貢獻(xiàn)，許多項目選擇暫時順勢而為，而非徹底退出這一浪潮。

開源基金會怎么說

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

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

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

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

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

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

極端選項

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

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

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

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

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

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

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

激勵問題

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

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

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

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

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

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

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

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

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

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

AI Slop 時代的最終建議

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

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

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

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

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

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

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

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

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

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

會議推薦

QCon 全球軟件開發(fā)大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節(jié)跳動、小米、百度等一線科技企業(yè)與創(chuàng)新團(tuán)隊的技術(shù)專家，圍繞 AI 工程化、系統(tǒng)架構(gòu)與研發(fā)模式演進(jìn)展開深入探討。更多詳情可掃碼或聯(lián)系票務(wù)經(jīng)理 18514549229 進(jìn)行咨詢。

今日薦文

你也「在看」嗎？