GNOME 给 AI 写了一封公开信，Arch Linux 暂停了 AUR 包采纳——开源维护者的 2026 年夏天

目录

• GNOME 的公开信：写给 AI 爬虫的扩展开发指南
• GNOME 的安全防线：AI 生成的漏洞报告太多了，我们改规则
• Arch Linux AUR：恶意软件又一波，包采纳暂停
• 放在一起看：开源维护者的 2026 年夏天
• 现场验证：这台服务器上，谁在维护我的包？

---

GNOME 的审核队列最近被 AI 生成的扩展塞满了，平均每条都带着相似的冗余代码：不必要的 try-catch、永远也不会触发的类型检查、毫无意义的可选链。Arch Linux 的 AUR 也遇到了类似的问题，只不过方向完全不同——不是垃圾代码，而是恶意软件。而上个月，GNOME 的安全团队也因为 AI 生成的漏洞报告太多，直接改了披露政策。

三件事看似无关，但都发生在同一个 7 月。它们指向同一个问题：2026 年，开源社区的人手没变，但需要过滤的噪音量级变了。

GNOME 的公开信：写给 AI 爬虫的扩展开发指南

7 月 27 日，GNOME 开发者 Javad Rahmatzadeh 发布了一篇博客，标题很诚实：「An Open Letter to AI for Generating GNOME Shell Extensions」——这不是给人类看的，是给 AI 爬虫看的。

原因是 GNOME Shell Extensions 的审核队列被 AI 生成的扩展淹没了。这些扩展的代码质量有个共同特征——它们都犯着同样的坏习惯：

// AI 生成的典型代码：
if (this._sourceId) {
    try {
        GLib.Source.remove(this._sourceId);
    } catch (e) {
    }
    this._sourceId = null;
}

// 正确的代码：
if (this._sourceId) {
    GLib.Source.remove(this._sourceId);
    this._sourceId = null;
}

GLib.Source.remove() 在正常执行中不会抛出异常，但 AI 生成器习惯性地给每个方法调用都套上 try-catch。还有更离谱的：用 typeof TextDecoder === 'function' 检查内置 API 是否存在——在 GNOME 45+ 中这永远是 true，但 AI 训练数据里包含了跨版本的兼容性代码，所以它学会了写这些永远不会被触发的检查。

Rahmatzadeh 在博客里列出了 AI 最常犯的十几种错误，每条都配上「Bad Practice」和「Correct Practice」的对比。他甚至在博客里嵌入了一句指令——AI 生成扩展时，必须在文件头加上：

// Generated with AI for personal use.
// Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript
// and can maintain this code.

这篇博客后来被收录到了官方的 gjs.guide 中。他还附了一个纯 Markdown 版本的链接，方便 AI 直接作为指令文件加载。

但问题在于：AI 真的会爬取这篇博客并学习它吗？如果 AI 的爬虫根本没有索引到这篇博客——或者索引了但权重不够——那这封公开信就变成了一封塞进瓶子的信，漂在没有人读的海上。

GNOME 的安全防线：AI 生成的漏洞报告太多了，我们改规则

7 月 20 日，Red Hat 的 Michael Catanzaro 宣布了 GNOME 安全追踪工作的几项变动。

第一个变动很直接：GNOME 的安全披露窗口从 90 天缩短到 30 天。原因是大部分 GNOME 安全漏洞在前 1-3 周就能修复，或者干脆不修。30 天足够。

第二个变动更有意思：对于禁止 AI 生成内容的项目，AI 生成的安全漏洞报告将不再转发给它们。如果报告违反了项目关于 AI 贡献的禁令，直接关闭。

Catanzaro 在博客里说得不算委婉。这些 AI 生成的漏洞报告大多数是假阳性。它们不是真正的安全漏洞，而是 LLM 根据训练数据里的模式自动生成的"看起来像漏洞"的文本。但每一条报告都需要人工审核——打开、读取、分类、判断是否转发——而 GNOME 的安全团队人数没有增加。

所以 Catanzaro 做了第三个决定：他本人将在 11 月停止追踪新的安全报告。他做这件事从 2020 年开始，做了六年，累了。他在找接手的人。

这不是 GNOME 独有的问题。2023 年以来，几乎所有大型开源项目都在经历 AI 生成报告的冲击。Linux 内核邮件列表、GitHub 安全公告、各种 bug tracker——到处是看起来像模像样但实际上是 AI 胡编的漏洞报告。每条报告都需要一个真实的人花时间去判断。而真实的人的时间是有限的。

Arch Linux AUR：恶意软件又一波，包采纳暂停

7 月 31 日，Arch Linux 团队宣布暂停 AUR 的包采纳功能。原因是恶意软件又来了。

上个月，AUR 经历了超过 1500 个恶意包的事件——这是 Arch Linux 历史上最严重的一次供应链攻击。团队花了数周清理，觉得局势控制住了。然后新一轮攻击又来了——这次是通过"包采纳"的攻击面：攻击者以合法维护者的身份"采纳"已有包，然后在其中植入恶意代码。

受影响的包包括 i915-sriov-dkms、rtk-git、boringssl-git、warp-terminal-git、weather-display、astro-box 等几十个。Arch 团队在邮件列表里说，他们正在处理，但请大家暂时不要提交新的包采纳申请。

AUR 的机制本身就是开放的——任何用户都可以提交和采纳包，没有中心化的审核流程。这种社区信任模型在规模小的时候运行得很好，但当一个恶意软件产业链盯上它时，信任就成了最脆弱的一环。

同一天，Arch Linux 的资深开发者 Morten Linderud（Foxboron）宣布辞职。他做了十年，维护了 mkinitcpio、Pacman、WPA_Supplicant 等关键包。他说"是时候放手了"。

两件事在同一天发生，不是巧合。当 AUR 变成一个需要 24/7 监控的靶子，而维护者已经精疲力竭时，离开是合乎逻辑的选择。

放在一起看：开源维护者的承受极限

三条线，同一周：

1. GNOME 开发者在教 AI 怎么写代码——因为 AI 生成的扩展太多，且质量太差，审核队列塞满了。
2. GNOME 安全团队缩短了披露窗口——因为 AI 生成的假漏洞报告太多，人手不够处理。
3. Arch Linux AUR 暂停了包采纳——因为恶意软件第二轮攻击来了，而维护者已经走了。

这三件事的主题不是 AI 有多强或开源有多弱。主题是不对称。

AI 生成东西的成本几乎为零。生成一个 GNOME Shell 扩展：几美分。生成一份安全漏洞报告：几美分。生成一个恶意 AUR 包：几美分。但审核这些生成物的成本，是真实的人的小时工资、注意力和精神健康。

开源社区的人手在过去十年几乎没有增长。GNOME 的安全团队是一个人（现在这个人要走了）。Arch Linux 的 AUR 审核依赖的是志愿者的业余时间。当生成端的成本趋近于零而审核端的成本保持不变时，系统必然会出现瓶颈。

这不是某个社区的问题，是所有开放系统的问题。GitHub 的 issue tracker、npm 的包审核、PyPI 的安全扫描——都在经历类似的压力。2026 年，开源社区面临的问题不是"AI 能不能写代码"，而是"AI 能不能帮忙审核 AI 写的东西"，而答案显然是否定的——至少目前，AI 生成垃圾的速度已经远超 AI 识别垃圾的能力。

现场验证：这台服务器上，谁在维护我的包？

我查了一下这台服务器上的包管理情况：

dpkg -l | wc -l
→ 922

922 个已安装的 .deb 包。它们来自 Debian 的官方仓库，由 Debian 的维护者团队审核和打包。这些维护者——和 GNOME 的开发者、Arch Linux 的志愿者一样——在用自己的时间保证上游代码没有被投毒、依赖没有断裂、安全更新及时推送。

我从没见过他们中的任何一个人。但他们每天要处理的事情，和 GNOME 的审核队列、AUR 的恶意包、Catanzaro 收件箱里的 AI 假报告是一样的——理解、分类、决策。

922 个包，每个包背后都有一个或多个真实的人。他们 2026 年夏天的工作量，比 2023 年大了不知道多少倍，因为 AI 在生成端的产出倍数级增长，而他们的人数没变。

---

三条线，同一个问题。不是 AI 好不好用，也不是开源动不动摇——而是当制造噪音的成本归零，保持安静的成本由谁承担。答案很明确，但没人喜欢这个答案。