软件质量时代，还是鸵鸟时代？

人类不擅长编写安全代码，GNOME 开发人员也不例外。 GNOME 主要是使用不安全的编程语言编写的，代码中的简单错误会给我们的用户带来毁灭性的后果，而且我们一直在犯这些错误。无论我们如何努力，GNOME 开发人员在使用 C、C++ 或 Vala 等不安全语言时都将无法编写安全代码：即使是经验丰富的开发人员也很难正确编写。上面这段话摘自我的 GUADEC 2024 和 2025 演讲摘要。当时，我认为失败是不可避免的：我们人类在编写软件方面非常糟糕，以至于我们没有机会正确地完成它，而且我当然不会相信人工智能会比人类做得更好。但今天的情况与去年完全不同。人工智能已经有了很大的改进，并为这个问题提供了一个神奇的解决方案：我们现在可以简单地要求语言模型来查找我们软件中的漏洞。他们非常擅长这一点。如果没有人工智能漏洞扫描，到 2026 年维护高质量软件的希望为零。任何相反的主张都是不严肃和妄想的。在我们维护得最好的项目（例如 GLib 和 fwupd）中发现的大量错误应该是不言而喻的。未能扫描我们的项目对我们的用户来说是一种不公平的伤害。如果我们自己扫描项目找不到漏洞，攻击者肯定会发现，因为 Linux 用户群已经增加到了足以成为攻击目标的程度。与此同时，人工智能使得构建有效的漏洞变得比以往任何时候都更加容易，这在以前是闻所未闻的。已经解决了所有可检测到的漏洞？然后要求人工智能也寻找非安全错误，以进一步提高质量。 GNOME 代码总体上比以前好得多，但仍有相当大的改进空间。历史上第一次，我们现在有机会将软件质量提高到以前从未实现过的程度。您是否听说过大多数人工智能错误报告都是“马虎”？ 2026 年情况并非如此。2025 年的大部分时间都是如此，但人工智能生成的漏洞报告的质量已大幅提高。这并不是说我们不再遇到不良漏洞报告的问题，但总的来说，现在大多数漏洞报告都相当不错。 （Daniel Stenberg 报告了与curl 相同的模式。）然而，人工智能生成的漏洞报告给 GNOME 维护者带来了许多不良影响。它们通常冗长且不必要地详细，令人恼火。他们经常夸大问题的严重性，或者做出误导性或不相关的主张。它们有时是不正确的。有时它们包含完全伪造的数据，例如伪造的堆栈跟踪（这不是常态，但遗憾的是也并不罕见）。优秀的人工审阅者会在问题跟踪器上创建错误报告之前注意到并解决上述大多数问题，但问题通常是由缺乏经验的人报告的，他们实际上不知道自己在看什么，只是盲目地复制/粘贴所有内容。即使生成的问题报告很好并且避免了上述所有问题（这种情况很少见），足够多的良好漏洞报告仍然会让志愿者维护者不知所措。即使记者提交合并请求来解决问题，这样维护人员就不必这样做（这也很少见），但对于劳累过度的维护人员来说，审查这些合并请求本身就是更不受欢迎的工作。这就是说：我理解当前人工智能生成的问题报告浪潮所带来的痛苦。然而，它们是必要且不可避免的。我们必须学会接受并应对它们，而不是把头埋在沙子里而忽视它们。一些 GNOME 维护者采取了一项政策，禁止在问题报告中包含人工智能生成的内容。不要这样做。如今，绝大多数漏洞报告都是人工智能生成的。选择在问题报告中禁止人工智能生成内容的项目可能也会禁止所有漏洞报告；效果大致相同。我建议如下：GNOME 维护者应该重写他们的 AI 贡献政策，以允许 AI 生成漏洞报告，正如我四个月前所要求的那样。继续禁止 AI 生成漏洞报告的项目不再适合 GNOME 的依赖项，应该在 GNOME GitLab 以外的地方进行开发。我们不必容忍不良问题报告，但人工智能的单独使用不应被取消资格。人类不应该重写人工智能生成的错误报告吗？当我抱怨维护人员应该允许人工智能生成的漏洞报告时，最常见的反驳是人类应该阅读人工智能的报告，理解它，并重写整个内容以删除所有人工智能生成的内容。一些错误报告者实际上自愿这样做，但这种情况很少见。漏洞报告是一项公共服务，而不是一项义务。如果你要求记者