本文最初发布于 RedMonk 官方博客。
AI Slop 正在撕毁开源开发中维护者和贡献者之间不可或缺的社会契约。从业者们一再得到保证，AI 将为他们的社区注入强劲的动力，但到目前为止，情况并非如此。看看上个月发生的事情就知道了。Mitchell Hashimoto 的 Ghostty 项目实施了一项零容忍政策，提交 AI 生成的糟糕代码将导致永久封禁。tldraw 创始人 Steve Ruiz 宣布，他将自动关闭所有外部拉取请求。与此同时，cURL，这个默默支撑着几乎所有互联网服务的命令行工具，刚刚终止了其漏洞悬赏计划。在连续六年、支付 8 万 6 千美元后，cURL 创始人兼首席开发者 Daniel Stenberg 终止了这项计划。为什么？AI Slop。
为什么这是个大问题？因为我们所熟悉的“开放贡献”时代可能即将结束。数十年来，开源贡献者和维护者之间存在着某种隐性契约。通过参与其中，贡献者可以获得学习的机会、丰富自己的简历、推进所属公司的目标，并成为比自身更宏大的事物的一部分。与此同时，维护者承诺培育社区、指导项目和贡献者。这份契约意味着，双方都已经预见到这个过程中会出现一些糟糕的 PR，从历史上看，糟糕的 PR 成本很高。编写代码需要耗费时间。理解代码库需要耗费精力。贡献行为本身（在很大程度上）筛除了那些不认真的人。
AI 破坏了那个筛选器。现在，任何人都可以生成看似合理的贡献，不需要理解代码，不需要做出努力。贡献的数量已经使系统不堪重负。正如 Python 软件基金会驻场安全开发者 Seth Larson 所说：
我主要担心的是那些独自处理这个问题的维护者。如果不知道 AI 生成的报告越来越常见，那么他们可能会把大量的时间浪费在虚假的报告上，然后才知道发生了什么。浪费宝贵的志愿服务时间做你不喜欢的事情，并最终一无所获，这会让维护者们精疲力尽或远离安全工作。
在这篇文章中，我将讨论 AI Slop 时代的开源现状，以及许多已经精疲力尽的维护者的应对方式。我研究了几个已经明确立场的项目，同时也关注了来自知名开源组织的具有代表性的生成式 AI 政策。最后，我提出了几点关于继续推进相关工作的总体建议。
什么是“AI Slop”？
在进一步讨论之前，我们先定义下术语。AI Slop 不只是糟糕的代码。开源社区一直在处理低质量的贡献，从一开始就一直如此。只要问问 Linus Torvalds 就知道了。1991 年，他在 comp.os.minix 新闻组里首次宣布了 Linux，从那时起他一直在发送“怒火邮件”。在开源软件的（OSS）术语中，AI Slop 是指这样一种情况：有人将 GitHub 问题粘贴到 ChatGPT 中，按下回车键，然后把输出的东西直接提交，也不检查它是否有效。一份看似合法的漏洞报告实际上描述了不存在的漏洞。一个声称能够修复项目的拉取请求修复的却是一个不存在的项目。这些通过氛围编码生成的补丁看似合理，却暗含幻觉般的假设，或是干脆就是烂代码。
Stacklok 联合创始人兼首席执行官 Craig McLuckie 对“氛围编码贡献”的看法如下：
过去，我们常将 GitHub 问题标记为“新手友好问题”，充满干劲的年轻工程师便会前来尝试，通过解决这些问题积累经验，最终成长为社区贡献者。这对我们有益，对他们也有益，最重要的是对整个社区大有裨益。
如今，如果我们把某个问题标记为“新手友好问题”，不用 24 小时就会被大量低质量的氛围编码垃圾所淹没，占用了本该真正用于做事的宝贵时间。这种通过代码审查流程“将垃圾转化为优质代码”的模式，既损害生产力又打击团队士气。
社区中的许多人正在集思广益并设计解决方案原型。Hashimoto 建议为 AI 生成的贡献创建一个类似 “git blame” 这样的东西，让人们能够分清“真正的专业知识或糟糕的代码”。在深入思考了这个问题后，Continue 首席执行官 Chad Metcalf 创建了 Leeroy（ AI 辅助代码贡献的归属透明化工具）来解决这个问题。
现在，流入维护者收件箱的垃圾数量呈数量级的增长，各地的维护者都在谈论这个问题。例如，在讨论合并“为有效载荷字段模式添加 enable_hnsw 选项”功能的帖子中，Qdrant 联合创始人兼首席技术官 Andrey Vasnetsov 就专门提到了垃圾代码。过去几年间，这一问题一直在持续不断地恶化，对许多人而言，一月似乎是问题全面爆发的临界点。
策略演变
维护者对 AI 提交的立场仍在不断变化。
Stenberg 从 2024 年 1 月就开始抱怨 AI 生成的漏洞报告。到 2025 年年中，他报告说，curl 的漏洞赏金计划中大约 20% 的提交是 AI Slop。那一年，只有 5% 的提交识别出了真正的漏洞，“有效率”与前几年相比“显著下降”。2025 年 5 月，Stenberg 添加了一个复选框，要求提交者披露他们是否使用了 AI。这并没有起到任何作用。7 月，他公开表示考虑完全取消漏洞赏金。到 2026 年 1 月，在十六小时内收到七份提交后（其中部分是真实的 Bug；但均不是安全漏洞），他最终终止了该计划。
Hashimoto 对待 AI 贡献的方式也发生了变化。2025 年 8 月，他们开始要求强制披露。“如果你使用了**任何形式的 AI 辅助**来为 Ghostty 做贡献，就必须在拉取请求中进行说明。”但到 2026 年 1 月底，他采取了零容忍态度。AI 生成的贡献仅限于已经接受的问题和维护者。Hashimoto 澄清说：
我们的立场不是反对 AI ，而是反对愚蠢。Ghostty 是在 AI 的大量辅助下编写的，我们的许多维护者每天都使用 AI 。我们只是想要高质量的贡献，而不管它们是如何编写出来的。
Ruiz 的反应最激烈：tldraw 现在自动关闭了所有外部拉取请求，完全停止了。但他的理由指向了当今软件开发领域中一个更哲学性的问题：
在一个 AI 编码助手的世界里，外部贡献者的代码真的有价值吗？如果编写代码变成了一项简单的工作，我为什么要让别人来写呢？
像 Hashimoto 一样，Ruiz 承认自己也在使用 AI，并且发现修复代码比清理 AI 生成的 PR 更容易。其中一些最糟糕的 PR 是因为他自己编写的 AI 脚本——他编写的 Claude Code 命令，用于捕捉（/issue）和解决（/take）匆忙创建的问题——正在导致需要他关闭的 AI Slop 问题。贡献者将这些糟糕的问题输入他们自己的 AI 工具，而这些工具基于 Ruiz 所使用的 AI 的幻觉来生成 PR：“我那些敷衍了事的问题变成了敷衍了事的 PR，AI 包办了双方的工作。”一路上全是 AI Slop。
今天有人发布了 7 份安全报告，就我们项目的语境来看，它们完全不合逻辑
显然全是 AI 生成的
这妨碍了我们对真正有效的报告作出响应——那些报告才是来自真正理解我们项目的人
— dax (@thdxr) 2026 年 1 月 20 日
尚未决定立场的人
尽管 AI Slop 问题在开源社区中普遍存在，但上述案例因其决断性而显得尤为独特。如今，绝大多数开源项目仍持观望态度，维护者和负责人正积极探讨如何应对这个不断变化的问题。
Debian 便是其中一例。关于该项目内部成员反复拉锯的详细记录，可参阅 Joe Brockmeier 的文章：Debian AI 通用决议撤回。FluxCD 项目亦是如此。据核心维护者 Stefan Prodan 所述：
“在 FluxCD，我们还没有决定如何处理这个问题。因为它是一个 CNCF 项目，所以我们需要与其他项目保持一致。我们正在 Flux Operator 中尝试系统提示功能，接下来我们将添加技能模块。这是我们目前的 AI 指南：https://github.com/controlplaneio-fluxcd/flux-operator/blob/main/AGENTS.md”
等待观望一下是个明智的做法。AI 工具生态每个月都在变化——今天的 Slop 明天可能就与人类编写的代码无法区分，1 月份制定的政策可能 6 月份就过时了。许多开源项目的推进速度依赖于共识，而不是命令。像 Debian 这样的项目之所以采用一般决议和漫长的邮件列表讨论这样的运作模式，正是因为其合法性来自社区的认同，而不是自上而下的命令。Linux 内核的开发流程——众所周知由 Linus 的个人偏好和分布式维护者网络主导——往往需要数年时间才能吸纳重大的程序变革。即便规模较小的项目，也往往缺乏能像 Stenberg 、Hashimoto 和 Ruiz 那样果断决策的单一维护者权威结构——多数项目由指导委员会、共识模式或纯粹基于默契的合作机制来管理，无人能单方面拒绝 AI 贡献。面对海量的 AI 贡献，许多项目选择暂时顺势而为，而非彻底退出这一浪潮。
开源基金会怎么说
你可能会想：关于这个问题，就没有一个机构来帮助我们指引方向吗？各种开源基金会没有政策吗？他们有！如果你仔细看的话，有一点。问题是，这些政策大多数都聚焦在许可上，并没有解决维护者面临的 AI Slop 危机。AI 生成的代码所有权归谁？如果 Copilot 将遵循 GPL 协议的代码重新复制到遵循 MIT 许可的项目下会怎样？这些都是实实在在需要担忧的问题！但那不是让 Stenberg 写下“死于千百个 AI Slop ”这篇博文的原因。
Linux 基金会官方有一个生成式 AI 政策，基本上是说，只要许可问题解决，AI 生成的代码就可以作为贡献。他们专注于确保 AI 工具条款与开源许可的兼容，并且贡献者有权使用任何混入输出结果的第三方代码。
Apache 软件基金会在 2023 年发布了生成式工具指南，建议贡献者在提交消息中使用 “ Generated-by: ” 标签披露 AI 使用情况。他们明确承认，这是“一个快速发展的领域”，需要不断更新。
Eclipse 基金会有一份提交者指南，其中强调了 AI 容易出错的问题，并提醒提交者他们有责任确保代码的准确性。他们还建议在版权和许可标题下方加上 AI 生成代码的免责声明，如“某些部分由 Co-Pilot 生成。”
开放基础设施基金会采用了 “ Generated-By: ” 和 “ Assisted-By: ” 标签，并要求审核者将 AI 生成的代码视为来自“不可信来源”，需要加强审查。
这个列表并不全面，但是我所见过的情况中比较有代表性的。问题在于，许多基金会制定的政策都基于这样一个世界观：法律责任是唯一需要考虑的问题。维护者精疲力竭？质量控制指导？这些根本不属于他们的职责范围。尽管维护者们如今正深陷垃圾代码的泥潭，但各基金会至今仍未挺身而出，给他们抛个救生圈。
极端选项
一些项目选择完全禁止 AI 生成的代码。这种做法虽显粗暴，且批评者认为难以执行，但对选择这条道路的项目而言，禁令不仅是简单的门槛把控，更具有多重意义：它能筛除临时客串的贡献者，同时向外界传递项目希望培育何种文化的信号。
Gentoo Linux 在 2024 年 4 月完全禁止了 AI 生成的贡献，理由是版权问题、质量问题和伦理问题（特别是训练这些模型时对环境造成的影响）。提出禁令的 Michał Górny 向 Register 解释说：
我认为，这对 Gentoo 来说是一个不错的公关举措……当许多项目对 AI” 充满热情时，我觉得许多 Gentoo 用户真的更欣赏那种老派的软件工程方法，人类比“生产力”更重要。
Górny 的表述似乎有一种反文化的东西。在一个痴迷于速度和自动化的行业中，Gentoo 的立场与一个一直重视工艺而非便利性的社区产生了共鸣。
NetBSD 在其提交指南中也效仿了这一做法，将 LLM 生成的代码归类为“已被污染（tainted）”——这意味着没有核心团队的事先书面批准，不能提交这些代码。BSD 项目有一个额外的担忧：他们的许可协议意味着他们要避免意外地合并遵循 GPL 协议的代码，而 AI 工具在 GitHub 上训练时有一个坏习惯，那就是复制 GPL 代码。想进一步了解的话，可以看下由日本开源组织主席 Shuji Sado 撰写的文章：GPL 许可传播至基于 GPL 代码训练的 AI 模型的理论现状。
关于开源的未来，这些极端选项告诉了我们什么？首先，它们表明，对于一些社区来说，AI 生成代码的感知风险超过了任何潜在的生产力增益。这些项目正刻意选择优先优化信任与溯源机制，而非追求吞吐量。其次，它们凸显了一个令人不安的事实——这种趋势只会愈演愈烈：合规性审查终究只是象征性举措。随着 AI 生成的代码与人类编写的代码日益难以区分，违规检测将从具有挑战性转变为几乎不可能完成的任务。。
今天的 AI Slop 还是显而易见的——幻觉导致的函数调用、自以为正确却实则错误的表述、令人费解的冗长描述。但这些模型正在快速进化。一两年内，问题将不再是“我们能否检测到 AI 生成的代码？”，而是“如果检测不到有什么问题吗？”这些禁令的真正意义可能不在于它们的可执行性，而在于它们揭示了开源社区越来越多的人不再将 AI 辅助开发视为一个需要管理的必然性，而是看成是对协作式软件开发这一人类事业的根本性威胁。
激励问题
（点击这里查看动图）
AI Slop 危机不仅仅是一个技术问题或文化问题，它还是一个经济问题。在开源维护者和托管其工作的平台之间，这一点表现得尤为明显。
2025 年 5 月，GitHub 推出了一个功能，允许用户使用 Copilot 生成问题。你只需向 AI 描述问题，它便会生成格式规范的 Bug 报告文本，随后即可提交。在宣布该功能的博文中，GitHub 承诺，此举将使问题的创建过程“更快更轻松且不会牺牲质量”。对这个“质量”，维护者们提出了不同的看法。
几乎同时，人们开始询问能够阻止 Copilot 生成的问题进入他们存储库的方法。GitHub 的回应基本上是“没有办法”。用户无法被屏蔽 Copilot 机器人，Copilot 生成的问题甚至没有标明它们是 AI 生成的。相反，它们出现在人类用户的名下，没有任何迹象表明是机器人输入的。所以你无法过滤。
于许多担心 AI Slop 的开发者来说，这是一个无法解决的问题。正如 Andi McClure 在 2026 年 5 月的一个 GitHub 问题中所解释的那样：
如果我们得不到这样的工具，而 “AI” 垃圾提交确实成了一个问题，我可能被迫采取极端行动，比如在我的存储库上完全关闭问题和 PR，并把问题托管转移到像 Codeberg 这样的网站[一个非营利性代码库]，它们没有将这些对维护者不友好的工具直接内置在网站中。
根本问题在于激励机制的一致性。当人们使用 GitHub 时，GitHub 会赚钱，而 AI 功能增加了用户粘性指标。对于这种情况，Prodan 做出了负面的诊断：
AI 生成的低质量代码正在对开源软件（OSS）维护者进行分布式拒绝服务攻击（DDOS），而托管开源项目的平台并没有动机去阻止这种行为。相反，他们有比较大的动力去夸大 AI 生成的贡献，以便向他们的股东展示“价值”。
作为开源开发的主导平台，这种紧张关系使 GitHub 几乎成为所有 AI Slop 讨论的核心。当 GitHub 决定不允许屏蔽 Copilot 生成的问题时，这一决策影响了数百万个存储库及其维护者。在解释 tldraw 项目完全关闭外部贡献的决定时，Ruiz 明确指出了这种关联，并暗示该策略是根据 GitHub 提供的工具情况而定的：
这是一个临时政策，但在 GitHub 提供更好的贡献管理工具之前会一直有效。
这向 GitHub 传达的信息再清楚不过了：你提供的工具有可能迫使一些维护者放弃开放贡献模式。但 GitHub 是否理解到了这层信息，或者是否有恰当的动机去采取行动，还尚未可知。这家公司似乎在赌，AI 功能吸引的用户会比因此而失去的用户多，那些威胁要离开去 Codeberg 或采用自托管解决方案的维护者最终会留下来，因为 GitHub 的网络效应太强，无法放弃。问题是，AI Slot 危机是否会成为一个转折点，抑或维护者们将被迫适应这样一个世界——他们所依赖的平台更注重用户参与度而非可维护性。
AI Slop 时代的最终建议
外面简直是他妈的战场啊兄弟。维护者士气跌至历史最低点。我完全理解那些直接掀桌子完全禁止所有 AI 的项目。我快要宣布只有维护者和已接受的问题才能使用 AI 了。
—— Mitchell Hashimoto (@mitchellh) 2026年1月16日
如果你是贡献者：展示你的工作。以人类的身份参与。理解你提交的内容。如果你使用 AI，请像 Joshua Rogers 那样使用它：他向 Stenberg 发送了一个潜在问题列表，上面有“大量”通过 AI 辅助工具发现的问题，其结果是有五十个真正的 Bug 得到了修复。Rogers 展示了如何正确地使用 AI 而不取代批判性思维。
如果你是维护者：制定清晰的政策，公开记录它们，而不要默默地忍受。你并不孤单，你的挫败感是合理的。
如果你在平台工作：构建服务于维护者的工具，而不仅仅是专注于参与度指标。为他们提供过滤、阻止和管理洪水的能力。
如果你在基金会工作：现在是时候解决质量和疲劳问题了，而不仅仅是许可问题。法律问题很重要，但你的社区现在正处于水深火热之中。
如果你是那些向开源项目提交 AI Slop 的人，希望用零努力的 PR 来填充你的 GitHub 贡献图？请不要再这样做。
免责声明：GitHub / 微软和谷歌是 RedMonk 的客户。
文章开头的图片由 Google Nano Banana 生成。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：https://redmonk.com/kholterhoff/2026/02/03/ai-slopageddon-and-the-oss-maintainers/
