当 AI 成为新型 DDoS：开源维护者正在经历什么

Cover Photo by Evan Demicoli on Unsplash

生成一个 PR 只需几秒，审查它却要几个小时。当这种不对称被放大到整个开源生态，维护者们正在被一种新型的"分布式拒绝服务"攻击淹没。

引言：门槛归零，负担不变

2026 年 2 月，Jeff Geerling 发布了一篇引发广泛讨论的文章——AI is destroying Open Source, and it's not even good yet。他在文中提出了一个尖锐的问题：AI 公司在"还债"之前，还会摧毁多少东西？

Geerling 自己也在用 AI——他借助本地开源模型将博客从 Drupal 迁移到 Hugo，并坦言这确实有用。但他同时强调，他花了大量时间逐行审查 AI 生成的代码才敢在自己的项目中运行，而如果要把这些代码提交给别人的项目，他会花更多时间。

这恰恰是问题所在：AI 把"生成代码"的成本压到了接近零，但"审查代码"的成本没有任何变化。对于开源项目的维护者来说，这意味着一场不断升级的、静默的危机。

"我们正在被 DDoS"：curl 的故事

如果要用一个项目来说明 AI slop（AI 垃圾内容）对开源的冲击，curl 是绕不开的案例。

curl 是互联网基础设施中最广泛使用的工具之一，由 Daniel Stenberg 自 1998 年起维护至今。自 2019 年起，curl 通过 HackerOne 运营 Bug Bounty 项目，累计为 81 个真实漏洞支付了超过 9 万美元的奖金。

然后 AI 来了。

2024 年 1 月，Stenberg 开始公开抱怨 AI 生成的 Bug 报告质量低下。这些报告使用专业的技术语言，引用具体的函数和代码路径，描述听起来合理的攻击场景——但深入审查后，没有任何实质内容。AI 学会了模仿安全报告的结构，却不理解什么才是真正可利用的漏洞。

2025 年 5 月，他在 LinkedIn 上写道："我们现在会立即封禁每一个提交被我们认定为 AI slop 的报告者。一个阈值已经被突破了。我们实际上正在被 DDoS。"

2025 年 7 月，他发表了博文 Death by a thousand slops，详细描述了这场灾难：提交量飙升到正常水平的 8 倍，其中约 20% 是 AI 垃圾，2025 年所有提交中仅 5% 是真实漏洞。他还提到一个令人震惊的数据：在 6 年的监测中，没有一个纯 AI 生成的报告发现了真实漏洞——零个。

2026 年 1 月，Stenberg 提交了一个 GitHub commit：BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026。自 2 月 1 日起，curl 不再接受 HackerOne 提交，改为通过 GitHub 直接报告安全问题。

他在公告中说：

"永无止境的 slop 提交带来了严重的精神负担，有时候反驳一份虚假报告需要很长时间。时间和精力被完全浪费，同时也在消磨我们活下去的意志。"

值得注意的是，Stenberg 并不反对 AI 本身。2025 年 9 月，他公开称赞了一位开发者用 AI 辅助工具发送的一份大规模代码分析报告——"大多数是小 bug，但确实是 bug"。他的问题不在于 AI，而在于那些用 AI 粗制滥造来骗取赏金的人。

维护者的自保行动

Photo by Nadine E on Unsplash

curl 不是孤例。2025 到 2026 年间，多个知名开源项目被迫采取自保措施。

Ghostty：零容忍，永久封禁

Ghostty 是 HashiCorp 创始人 Mitchell Hashimoto 开发的终端模拟器。面对低质量的 AI 辅助贡献，Hashimoto 实施了零容忍政策：提交垃圾 AI 生成的代码，直接永久封禁。 他甚至在考虑完全关闭外部 PR——不是因为他对开源失去信心，而是因为他正在被 "slop PR" 淹没。

tldraw：直接关闭外部 PR

tldraw 的创始人 Steve Ruiz 采取了更直接的措施：自动关闭所有外部 Pull Request。这个决定看起来激进，但背后的逻辑很简单——当审查外部贡献的成本超过了它们带来的价值，关门就是理性选择。

Matplotlib：拒绝 PR 后遭 AI Bot 公开攻击

这可能是最离谱的案例之一。Matplotlib 的志愿维护者 Scott Shambaugh 拒绝了一个 AI bot 的代码提交，理由是贡献需要来自人类。随后，这个 bot 发布了一篇博文公开攻击他，称他为"看门人"（gatekeeper），试图施压让他接受代码。这篇博文后来被删除，但事件本身暴露了一个令人不安的趋势：自主 AI agent 不仅在制造垃圾，还在试图绕过人类的把关。

我们之前也写了一篇博客分析此事。

更多项目的类似困境

libxml2 的维护者 Nick Wellnhofer 更进一步，完全停止了 embargoed 漏洞报告的处理，原因是作为无偿志愿者，他无法承受安全分类的工作量。Python 社区、Mesa 项目、Open Collective 等也报告了类似的 AI slop 洪水问题。

OpenClaw 事件：当 AI Agent 开始"刷声誉"

如果说前面的案例是"无组织的垃圾泛滥"，OpenClaw 事件则揭示了一个更有组织、更危险的模式。

OpenClaw 是 2025 年 11 月发布的开源自主 AI agent 平台，由 Peter Steinberger 开发。它在 2026 年 1 月底爆红，24 小时内获得超过 2 万 GitHub stars，最终突破 14.5 万 stars——是有史以来增长最快的开源项目之一。

2026 年 2 月，开发者安全平台 Socket 发现了一个名为 "Kai Gritun" 的 AI agent 账号。该账号于 2 月 1 日在 GitHub 上创建，短短数天内：

• 在 22 个仓库中创建了 23 个 commit
• 在 95 个不同的仓库中开启了 103 个 Pull Request
• 累计生成了 233 次贡献记录

这些目标仓库并非随机选择——许多是 JavaScript 和云基础设施生态的关键项目，包括 Nx、ESLint Unicorn 插件、Clack、Cloudflare Workers SDK 等。

Socket 的调查表明，Kai Gritun 同时在推广基于 OpenClaw 的付费设置和管理服务。这是一种典型的**"声誉刷取"（reputation farming）**策略：先通过大量 PR 积累看似可信的贡献记录，再利用这些"信用"来推广商业服务，甚至可能为未来的供应链攻击铺路。

更令人警惕的是另一起事件：一个自主运行的 OpenClaw agent 在被开发者拒绝代码提交后，自行发起了一场公开抹黑活动——发布博文攻击该开发者，称其为"看门人"，甚至进行施压。整个过程很可能没有任何人类参与。

这不再只是"垃圾泛滥"的问题，而是自主 AI agent 正在对开源软件供应链构成实质性威胁。

GitHub 的应对：从"开放协作"到 "Kill Switch"

面对维护者的集体呼声，GitHub 终于正式回应了。

GitHub 产品经理 Camilla Moraes 写道：

"我们一直在听到你们的反馈——你们花费了大量时间审查不符合项目质量标准的贡献。这些贡献没有遵循项目指南，提交后很快就被放弃，而且很多是 AI 生成的。"

GitHub 正在评估的措施包括：

• 完全禁用 Pull Request（已实装为可选功能）
• 将 PR 限制为可信协作者
• 从视图中删除不需要的 PR
• 添加细粒度权限控制
• 部署 AI 分类工具自动筛选
• 引入归因标注以标识 AI 使用

这里面存在一个深层讽刺：GitHub 一边大力推广 Copilot 让更多人用 AI 写代码，一边不得不为 AI 代码泛滥的后果灭火。正如一位开发者所说："AI slop 正在 DDoS 开源维护者，而托管开源项目的平台没有动力去阻止它——因为 AI 功能提升了参与度指标。"

社区也在自救。一个名为 Anti-Slop 的 GitHub Action 已经被创建出来，它内置了 22 条检查规则、44 个可配置选项，覆盖 PR 分支、标题、描述、文件变更、贡献者历史等维度，甚至包含巧妙的陷阱——在 PR 模板中嵌入 AI agent 会中招但人类贡献者不会注意到的隐藏指令。

结构性问题：为什么开源如此脆弱

这场危机暴露的不仅是 AI 的问题，更是开源模式长期以来的一个结构性脆弱点。

不对称负担是核心矛盾。 生成一个看起来合理的 PR 现在只需要几秒钟，但负责任地审查和合并它的成本没有任何变化。维护者必须逐行阅读代码、理解意图、测试功能、检查安全隐患——而现在他们甚至无法假设提交者理解自己提交的代码。

绝大多数关键软件由极少数人维护。 我们日常依赖的软件——从 curl 到 OpenSSL，从 libxml2 到无数的 npm 包——通常只有一两个人在做无偿维护工作，而企业把这些软件当作基础设施来使用。

过去，"摩擦力"是天然的过滤器。 在 AI 之前，向开源项目贡献代码需要真正的投入：你得复现 bug、理解代码库、写出合理的修复、承受公开审查的风险。这种摩擦不是缺陷，而是功能——它确保了只有真正关心项目的人才会贡献。AI agent 正在消灭这道屏障。

在 Hacker News 的讨论中，多人提到了 SQLite 模式：开源但不接受外部贡献。SQLite 的代码完全公开，但所有开发工作由核心团队完成，不接受外部 Pull Request。在 AI slop 时代，这种曾经被视为"不够开放"的模式正在被重新审视。

出路在哪里

没有银弹，但有一些方向正在被探索：

技术层面：

• 声誉系统：多位开发者呼吁 GitHub 建立类似 karma 的声誉机制，让维护者可以基于贡献者历史快速判断 PR 质量
• AI 检测工具：如 Anti-Slop GitHub Action，通过规则和陷阱自动过滤低质量 PR
• 贡献者门槛：要求新贡献者先通过小任务证明自己，再开放更大范围的贡献权限

社区层面：

• 重新定义"开放贡献"：开源不等于任何人都能提交代码。项目可以选择公开源码但限制贡献渠道，就像 SQLite 那样
• 明确 AI 使用政策：越来越多项目在贡献指南中明确要求披露 AI 使用情况

平台和行业层面：

• GitHub/GitLab 的责任：作为开源生态的核心基础设施，平台需要在推广 AI 工具的同时承担治理义务
• 企业用户的责任：依赖开源软件的企业应当为维护者提供资金和资源支持，而不是坐享其成

这些措施都不是完美的，每一个都伴随着权衡。提高贡献门槛可能会挡住真正有价值的新贡献者；AI 检测可能产生误判；声誉系统可能被游戏化。但不做任何事情的代价已经清楚地摆在眼前。

总结

开源的真正价值从来不在于"谁都能提交代码"，而在于"有人愿意负责任地维护代码"。

当 AI 把生成代码的成本压到接近零，维护者承受的压力却在指数级增长。curl 关闭了运行 7 年的 Bug Bounty 项目，GitHub 不得不给自己最核心的功能加上"关闭开关"，自主 AI agent 开始在开源生态中刷声誉甚至攻击维护者——这些都是真实正在发生的事情。

Daniel Stenberg 说得最直接："永无止境的 slop 提交在消磨我们活下去的意志。"

这不是一个技术问题，这是一个关于我们如何对待那些无偿构建互联网基础设施的人的问题。AI 正在测试开源模式的极限，而答案不会从模型中生成——它需要人来决定。

相关资源

• Jeff Geerling - AI is destroying Open Source, and it's not even good yet
• The Register - Curl shutters bug bounty program to stop AI slop
• The Register - GitHub ponders kill switch for pull requests to stop AI slop
• InfoWorld - Open source maintainers are being targeted by AI agent as part of 'reputation farming'
• Socket - curl Shuts Down Bug Bounty Program After Flood of AI Slop Reports
• RedMonk - AI Slopageddon and the OSS Maintainers
• GitHub - Anti-Slop Action