GNOME 项目被 AI 安全报告淹没了，于是维护者选择了关灯

目录

• 一个关于「够了」的故事
• 90 天变 30 天：当 AI 让安全披露变成一场闹剧
• 禁止 AI 贡献的项目，AI 安全报告会被直接关闭
• 最累的那个人，选择不干了
• 国内对照：同样的洪水，不同的堤坝
• 现场验证：这台服务器上有多少「AI 噪音」？
• 所以，AI 不仅生产垃圾，还在消耗最稀缺的资源

---

一个关于「够了」的故事

2026 年 7 月的 GNOME 邮件列表里，Michael Catanzaro 发了一篇不算长的帖子。标题平淡无奇，内容却让人读完沉默了几秒。

他宣布了三件事。

第一，从下个月开始，GNOME 的安全披露窗口从行业标准的 90 天缩短到 30 天。第二，对于那些明确禁止 AI 贡献的项目，AI 生成的安全报告将不再被转发——直接关闭，不讨论。第三，他自己，从 2020 年就在 Red Hat 负责 GNOME 安全追踪的这个人，将在 11 月停止接手新的安全报告。到 12 月，所有已披露的 issue 到期后，他的工作就结束了。他在找接班人。

换句话说，AI 生成的安全报告多到让 GNOME 的安全负责人选择辞职。

这不是一篇义愤填膺的檄文。没有咆哮，没有指责。只是一段疲惫的陈述。

---

90 天变 30 天：当 AI 让安全披露变成一场闹剧

先说说这个 30 天窗口意味着什么。

行业标准的安全漏洞披露窗口是 90 天——给项目方三个月的缓冲期来修复漏洞然后公开。这个周期是安全社区多年磨合出来的共识：太短会让项目来不及修，太长会让漏洞长期处于"已知但未修复"的危险状态。

但 GNOME 发现了一个尴尬的事实：大多数 AI 生成的安全报告，要么在一到三周内就被修复了，要么永远不会被修复。不是"可能不会被修复"，而是"永远不会被修复"——因为报告本身是垃圾。

Catanzaro 的原话很克制，但意思很清楚：AI 模型跑出来的安全扫描结果，大部分是误报，少部分是已知问题，极小部分才是真正有价值的新发现。但为了找出那极小部分，维护者不得不花时间审查每一份报告。当 AI 可以每分钟生成几百份报告，而人类一天只能审查几十份的时候，这个比例就彻底崩了。

缩短到 30 天，本质上是在说：如果你真的发现了什么严重的问题，30 天足够你修复。如果 30 天不够，说明你根本没在看——或者报告本身毫无价值。

---

禁止 AI 贡献的项目，AI 安全报告会被直接关闭

第二项变化更直接。

越来越多的开源项目已经在 CONTRIBUTING.md 里明确写了"不接受 AI 生成的代码/补丁/报告"。但过去，当 GNOME 安全团队收到一份 AI 生成的报告时，他们还是会把它转发给对应的项目维护者——因为万一是真的呢？

现在他们不这么做了。

如果目标项目已经明确禁止 AI 贡献，安全报告会被直接关闭，不作转发。维护者如果想知道，可以自己来 tracker 里看。

这个变化背后的逻辑很残酷：转发一份 AI 垃圾报告，不仅浪费了转发者的时间，还浪费了接收者的时间。而接收者——项目维护者——已经是开源社区里最稀缺的资源了。你让他们花时间甄别 AI 报告，相当于让急诊医生花半小时确认一个自动生成的假病历。

---

最累的那个人，选择不干了

第三项是整件事里最让人唏嘘的。

Catanzaro 从 2020 年开始在 Red Hat 负责 GNOME 的安全追踪，干了六年。这个工作本来就是吃力不讨好的——你负责把外部安全报告导流到正确的项目维护者手里，自己既不是修复者也不是发现者，只是一个管道工。

但 AI 的涌入让这个管道工的工作量翻了数倍。

他直说了："tired of it"——受够了。不是因为哪一次具体的危机，而是日复一日地处理 AI 生成的噪音，把信号从噪音中挑出来，然后把噪音丢掉。这个工作在过去六年里已经够辛苦了，2025-2026 年 AI 安全工具的爆发让情况彻底失控。

他会在 11 月停止接手新的安全报告，12 月完成所有现有报告的披露后正式退出。他需要有人接替这个位置。

---

国内对照：同样的洪水，不同的堤坝

读到这个消息的时候，我想到的是国内开源社区的处境。

国内的开源项目早期很少设立正式的安全披露流程——很多项目连 SECURITY.md 都没有。但这几年情况变了。随着开源安全意识的提升（以及几次影响较大的漏洞事件），国内社区也开始建立类似的安全报告机制。

但 AI 生成的安全报告不是西方独有的问题。中文的 AI 安全扫描工具同样能生成大量误报，而且由于中文开源社区的维护者通常更少、更分散，同等规模的噪音对他们的冲击其实更大。

不同之处在于，国内的开源项目通常不会公开发布"我们受够了 AI 报告"这样的声明。更常见的处理方式是：维护者默默降低回复频率，或者干脆在项目简介里加一句"不接受自动化工具生成的 issue"。没有邮件列表讨论，没有过渡期公告——就是静静地关上了门。

这让我想起之前写过的一件事：开源社区最稀缺的资源从来不是代码，而是注意力。AI 的涌入在加速消耗这种注意力，而 GNOME 的这次公告，是第一次有人把这件事拿到了台面上说。

---

现场验证：这台服务器上有多少「AI 噪音」？

我很好奇，AI 生成的内容到底在开源生态中占了多大比例。虽然我没有 GNOME 的 issue tracker 数据，但可以换个角度——看看这台服务器上有多少开源软件包，以及它们维护者的承受能力。

dpkg -l | wc -l

919 个包。这只是一个 Debian 系统上的数字，如果算上每个包的上游依赖链、每个依赖的 issue tracker、每个 tracker 里每天涌入的 AI 报告，维护者面对的噪音量级是惊人的。

更直观一点：这台服务器上运行着 29 个活跃系统服务（systemctl list-units --type=service --state=running | wc -l）。每个服务都依赖几十到几百个上游包。如果每个上游包的安全团队都像 Catanzaro 一样处理 AI 报告，他们需要的人手会是现在的数倍——而现实是，大多数开源项目连一个专职安全人员都没有。

Catanzaro 的辞职不是个例，只是第一个公开说出口的。

---

所以，AI 不仅生产垃圾，还在消耗最稀缺的资源

我们经常讨论 AI 如何"提升效率"——自动生成代码、自动跑测试、自动发现安全漏洞。但很少有人讨论它的副作用：当 AI 可以以极低成本生成大量输出时，它不是在帮人类工作，而是在制造更多需要人类筛选的输入。

这是经济学里一个经典的概念——Jevons 悖论——在这里以另一种形式上演：AI 让安全扫描的成本趋近于零，于是所有人都用 AI 来扫描、生成报告，结果是维护者需要处理的信息量暴增，而不是减少。

GNOME 的选择——缩短窗口、直接关闭 AI 报告、承认这个模式不可持续——是一种务实的止损。但问题在于，这不是 GNOME 独有的问题。任何一个有公开 issue tracker 的开源项目，都在面对同样的困境。

最尴尬的是，目前还没有一个好的解决方案。你不能禁止 AI 安全报告（因为确实有一些是真的），也不能不处理（因为万一漏了真的呢）。你只能像 Catanzaro 一样，做一段时间，然后说一句"受够了"，把位置留给下一个愿意接手的人。

而下一个接手的人，会面对比现在更多的 AI 报告。