AI Slop 正在把开源社区逼急:以后不是会用 AI 就能提交 PR

这两天我翻技术社区，发现一个词出现得越来越频繁：AI slop。它不是在骂“所有 AI 内容”，而是在骂那些看起来像成果、实际没验证、没理解、没价值的 AI 生成物。放到开源社区里，它最典型的形态就是：AI 生成的低质量 issue、PR、安全报告，正在把维护者的时间一点点吃掉。

过去一年，很多程序员都有一个明显感受：

AI 写代码越来越快了。

以前一个人憋半天的工具函数，现在几分钟就能生成；以前不敢碰的开源项目，现在把错误贴给 AI，它也能给你改个七七八八。

这当然是好事。

但开源社区最近开始出现另一面：

生成代码的成本越来越低，审查代码的成本却没有降低。

甚至更麻烦了。

因为维护者现在不只要判断一段代码对不对，还要判断提交者到底有没有理解自己改了什么。

这就是 AI slop 在开源里的真正问题。

先说结论

AI 没有毁掉开源。

真正让维护者头疼的，是下面这类贡献：

• 没跑过测试的 AI PR
• 没有复现步骤的漏洞报告
• 看起来很专业、实际是幻觉的安全问题
• 改了代码却说不清为什么改
• 只会把维护者的问题继续丢给 AI 回答

这类东西的问题不在于“用了 AI”。

问题在于：提交者把生成当成交付，把维护者当成人肉验证器。

AI slop 到底是什么

slop 这个词，直译过来有点像“糊状垃圾”。

放到 AI 语境里，它通常指那种低成本批量生成、表面完整、实际低质的内容。

技术社区里的 AI slop，一般有几个特点：

1. 结构很完整
2. 语气很自信
3. 术语很像那么回事
4. 但没有真实验证
5. 一追问就露馅
6. 比如一个漏洞报告写得非常正式：
   

• 有标题
• 有影响范围
• 有严重等级
• 有修复建议
• 甚至有 CVE 风格描述

但维护者一看代码，发现这个漏洞根本不存在。

或者一个 PR 看起来像是在修 bug，文件也改了，注释也补了，但提交者没跑项目，没跑测试，甚至不知道这个函数为什么原来要这么写。

这类内容最恶心的地方是：

它不是一眼假的。

它会消耗真人的判断力。

cURL 为什么停掉漏洞赏金

今年 1 月，cURL 项目停掉了自己的 HackerOne 漏洞赏金计划。

cURL 这种项目不用多介绍，程序员基本都知道。它是全世界大量系统、脚本、服务、工具链都会用到的基础软件。

按理说，漏洞赏金计划是好事。

有人发现安全问题，提交报告，项目修复，大家都更安全。

但问题是，AI 让“生成一个看似严肃的漏洞报告”变得太便宜了。

维护者 Daniel Stenberg 公开提到，项目收到了大量低质量、AI 生成的报告。它们看起来像安全报告，但经过人工分析后，很多并不是实际漏洞。

这就造成一个荒唐结果：

真正维护项目的人，不得不花大量时间去证明“这不是漏洞”。

你想想这个成本有多高。

提交者让 AI 几分钟生成一份报告。

维护者可能要读代码、查历史、复现环境、分析调用链，最后才能确认：这东西不成立。

这不是安全研究。

这是把验证成本甩给别人。

Godot 也被 AI PR 搞烦了

类似的问题也出现在 Godot 这种大型开源项目里。

Godot 是一个开源游戏引擎，社区很活跃，也很欢迎贡献。

但维护者开始抱怨 AI 生成的 PR 越来越多，而且不少改动“看起来像修复”，实际却没有真正理解项目。

这对开源项目特别伤。

因为开源维护不是简单地看代码能不能编译。

一个 PR 至少要判断：

• 有没有破坏已有行为
• 有没有影响其他平台
• 有没有破坏兼容性
• 有没有符合项目设计方向
• 有没有引入长期维护成本
• 提交者能不能继续跟进问题

AI 可以帮你写出一段局部能跑的代码。

但它不一定理解项目的历史包袱、设计哲学、维护边界。

维护者真正怕的不是“你用了 AI”。

维护者怕的是：

你自己也不知道这段代码为什么应该被合并。

为什么普通程序员也该关心这件事

有人可能会说：

“我又不是开源维护者，这和我有什么关系？”

关系很大。

因为这种变化很快会进入公司内部开发。

以前团队 code review，大家主要面对的是同事写的代码。

以后你很可能面对的是：

同事让 AI 生成了一段代码，然后提交给你 review。

如果他自己理解了、跑过了、验证了，那没问题。

但如果他只是复制粘贴，然后等你来兜底，你的工作量就会变大。

这在公司里也会形成新的矛盾：

• 写代码的人效率看起来提高了
• review 的人负担变重了
• 项目里混入更多“没人真正理解”的逻辑
• 出问题后很难追责，因为大家都说“AI 这么建议的”

所以 AI slop 不是开源社区的小情绪。

它其实是在提前提醒所有开发团队：

AI 时代，代码生成不再稀缺，可信交付才稀缺。

什么样的 AI PR 会被讨厌

我总结了一下，下面这几类最容易被维护者反感。

1. 没有复现的修复

比如你提一个 PR，说修复了某个 bug。

但你没有说明：

• bug 怎么出现
• 用什么版本复现
• 改之前是什么结果
• 改之后是什么结果
• 有没有测试覆盖

这种 PR 就算代码是对的，也会让人很累。

因为维护者要帮你补完整个证明过程。

2. 只改表面，不懂原因

比如某个地方报空指针，AI 给你加了一个判空。

表面上错误消失了。

但真正的问题可能是上游数据不该为空。

你加了判空，只是把问题吞掉了。

这种代码最危险。

它看起来像修复，实际是在把 bug 藏深。

3. 大范围格式化

AI 很喜欢“顺手优化”。

改一个小 bug，顺手格式化十几个文件。

维护者打开 diff，一半都是无关变更。

这会极大增加 review 成本。

普通程序员一定要记住：

PR 越小，越容易被信任。

4. 回答问题时继续甩给 AI

维护者问你：

“为什么这里要改成这样？”

你又丢给 AI，让它生成一段解释。

如果解释对不上代码，维护者很快就能看出来。

开源社区欢迎新手，但不欢迎装懂。

不会可以说不会。

但不能用 AI 生成一层又一层包装，把别人的时间也拖进去。

一个靠谱的 AI 辅助 PR 应该长什么样

如果你真的想用 AI 参与开源，我建议按这个模板来。

不是为了显得专业，而是为了降低维护者的判断成本。

## 这个 PR 解决什么问题

简要说明问题，不要超过 5 句话。

## 如何复现

1. 使用版本：
2. 操作步骤：
3. 预期结果：
4. 实际结果：

## 修改了什么

- 修改文件 1：说明原因
- 修改文件 2：说明原因

## 我如何验证

- [ ] 本地跑过项目
- [ ] 跑过现有测试
- [ ] 新增或更新了测试
- [ ] 手动验证了核心场景

## AI 使用说明

这个 PR 使用 AI 辅助生成/分析过。
我已经人工检查代码，并确认理解本次修改的影响范围。

最后这个“AI 使用说明”，我觉得未来可能会越来越常见。

它不是羞耻声明。

它是一种责任声明。

你可以用 AI。

但你要告诉别人：你不是把 AI 输出原封不动扔上来。

你已经检查过，你理解它，你愿意负责。

普通程序员怎么避免写出 AI slop

如果你现在也在用 AI 写代码，可以记住一个简单原则：

AI 可以帮你生成，但不能替你验证。

我给自己列了一个很土但有用的检查清单。

每次让 AI 改代码后，至少问自己 7 个问题：

1. 我能不能用自己的话解释这次改动
2. 我有没有跑过项目
3. 我有没有跑过相关测试
4. 这个改动有没有扩大范围
5. 有没有更小的修改方式
6. 有没有隐藏掉真正的问题
7. 如果线上出问题，我能不能负责回滚

如果这 7 个问题有一半答不上来，就别急着提交。

这不是保守。

这是职业基本功。

AI 时代，普通程序员最容易掉进一个坑：

觉得自己“会用了”，其实只是“会复制了”。

真正拉开差距的，不是你会不会问 AI。

而是你能不能判断 AI 生成的东西能不能进项目。

这反而是普通程序员的机会

听起来好像都是坏消息。

但我觉得这件事对普通程序员反而是机会。

因为当 AI 生成内容越来越多，真正稀缺的能力会变成：

• 能验证
• 能复现
• 能解释
• 能收敛范围
• 能对结果负责

这些能力不玄乎。

它们就是我们日常开发里的基本功。

以前很多人觉得普通程序员没有竞争力，因为写代码这件事越来越卷。

但现在看，AI 把“生成代码”这件事变便宜以后，工程经验反而更值钱了。

谁能把 AI 输出变成可靠交付，谁就有价值。

谁只会把 AI 输出转手丢给别人，谁就会变成团队里的噪音源。

最后一句

AI 当然会继续进入开发流程。

这个趋势挡不住，也没必要挡。

但开源社区现在的反击，其实是在重新强调一个老规矩：

贡献不是把代码扔过去，而是把问题解决掉。

AI 可以帮你写第一版。

但复现、验证、解释、负责，这些事还是要人来做。

以后一个程序员的价值，可能不再是“我能写多少代码”。

而是：

我能不能把 AI 生成的一堆可能性，筛成一份可靠的交付。

这件事，才是真正值得普通程序员练的。

资料来源：

• Ars Technica：cURL 因 AI slop 停止漏洞赏金计划

https://arstechnica.com/security/2026/01/overrun-with-ai-slop-curl-scraps-bug-bounties-to-ensure-intact-mental-health/

• The Register：Godot 维护者抱怨 AI slop PR 正在消耗维护者

https://www.theregister.com/software/2026/02/18/godot_maintainers_struggle_with_demoralizing/

• OpenSSF 讨论：为开源维护者制定 AI slop 应对实践

https://github.com/ossf/wg-vulnerability-disclosures/issues/178

• arXiv 论文：《An Endless Stream of AI Slop》

https://arxiv.org/abs/2603.27249