LLM 生成的 Bug 报告正在淹没开源项目

QEMU 项目维护者 Alex Bennée 日前撰文，详细记录了过去一年多来 AI 大模型生成的 Bug 报告给开源项目带来的冲击。他将这一现象称为「Bugpocalypse」，并指出其已成为开源协作中不可忽视的新问题。

Bug 报告量在 3 月出现拐点

据 Bennée 介绍，QEMU 团队在今年 6 月更新了安全漏洞提交流程，将安全 Bug 的处理方式与普通 Bug 报告统一，差别仅在于要求报告者使用 GitLab 的机密标记限制可见范围。此前依赖志愿者值守的专用邮箱，因为报告量激增而难以为继。

回顾过去一年的 Bug 统计曲线，他指出今年 3 月前后出现了一个明显的拐点——这与 LLM 在代码安全诊断能力上的跃升时间高度吻合。除统计数字外，团队还反复遭遇休眠账号突然激活、向 Bug 追踪器大量投递 AI 生成报告的情况。最高记录是一位报告者在几分钟内提交了 120 个看似有效的问题。随着时间推移，AI 生成的报告越来越难以辨别，内容也愈发「可信」。

长篇报告的隐性成本

随着 LLM Agent 能力增强，报告者越来越愿意填写详尽信息，甚至超出模板要求。Bennée 举了一个 iommu 迁移 Bug 报告为例：

• 报告长达近 4000 字。
• 附带一个从零搭建的测试框架，用于修改迁移流并触发问题。
• 通读之后才能发现，其核心其实只是「乱改迁移流会让接收端 abort()」，并非关键漏洞。

Bennée 写道：「人不同于机器，在持续数小时阅读源源不断的看似合理的报告后，人会感到疲惫。」颇具讽刺意味的是，团队也在尝试用 LLM 来做 Bug 的初筛分流，以期让问题更快到达合适的开发者手中——但最终拍板的，依然需要人来判断。

QEMU 的代码体量与维护现状

QEMU 的 Git 历史可追溯到 2003 年，如今代码规模在 500 万到 1150 万行之间（取决于统计口径）。在维护方面：

• 大约三分之二的代码有能积极审阅、入排上游补丁的维护者。
• 其中相当比例是带薪投入工作时间的全职维护者。
• 仍约有近一半处于机密状态的未解决问题位于维护力量薄弱的代码区域。

Bennée 提醒，在长期无人打理的代码角落发现陈年问题并不意外——这些区域历史上风险也更低，并不直接面向虚拟化生产场景。

仍然需要真正的人类参与

Bennée 在文中强调，QEMU 项目本质上仍是由人协作维护的虚拟化栈关键组件。没有人愿意把时间耗费在筛选大量 AI 生成的「垃圾」报告上。他欢迎真正有价值的提交，但这些提交必须由人来完成、由人来判断。对于 LLM 时代下如何平衡效率与质量、如何保护开源维护者精力，Bennée 没有给出明确答案，但他以第一手视角记录的现象本身，已成为行业讨论 AI 与开源协作关系时的重要参考。