Linux 7.2：修复量翻倍，LLM 成主力
Development statistics for the 7.2 kernel
Linus Torvalds 发布的 Linux 7.2 内核见证了开发史上的繁忙时刻，新增近 60 万行代码，提交量创下历史第二高。更引人注目的是，自 2026 年 4 月以来，每个版本修复的 Bug 数量翻了一番。这一变化背后，LLM 辅助开发正悄然改变格局：虽然仅有不到 7% 的提交标记了 Assisted-by 标签，但实际使用 LLM 修复 Bug 和审查代码的规模可能远超统计。从 Sashiko 审查系统到大量新开发者涌入，内核社区正经历一场由 AI 驱动的效率革命，修复速度首次显著超越 Bug 引入速度。
准确的追踪由 LLM 辅助开发的提交可能最终被证明是不可能的，但这有时让人觉得内核社区并没有足够在意去真正尝试。
HN 评论区
104- ogoffart
我在自己的项目中也注意到了同样的情况。
Agent 在修复 bug 方面帮了大忙。只需把 Agent 指向 bug 报告，它们就能完成复现、调试和修复。我们“只需”负责审查（有时需要追问更多细节，或表示我们更倾向于另一种方案）。这让 bug 修复变得更快、更自动化。
与此同时，似乎我们收到的库的 bug 报告也变少了。
我觉得用户直接用他们的 Agent 来写代码，而 Agent 不会报告 bug，它们只是以某种方式绕过去。
所以总体而言，未修复的 bug 数量在下降。这感觉还挺好。
另一方面，我们收到了大量由其他人的 Agent 提交的 PR，如果只是一大堆代码直接丢过来，确实有点让人应接不暇，我们很难进行审查。
- zdw
Greg KH 做了一个关于 LLM 生成内容泛滥的视频：https://www.youtube.com/watch?v=NnV_cWeoo5Q，HN 讨论串：https://news.ycombinator.com/item?id=49929391
视频涵盖了他如何应对并抵制这些内容，同时也要求提供补丁（而不仅仅是 bug 报告）。
- 05kqhg
标题是“7.2 内核的开发统计”，而最后一段对 LLM 持高度批判态度，这与经过编辑加工的标题“Linux 每个版本修复的 bug 数量随时间变化：自 2026 年 4 月以来增长超过 2 倍”形成鲜明对比，后者似乎暗示了某种神话般的 bug 发现能力。
最后一段原文：
“Linux 内核旨在用于生产环境，而非研究或实验。但目前，内核的开发流程和社区正在经历一场大规模的实验。”
- jayd16
这类摘要的主要问题在于缺乏对照组。
历史数据不再有效，因为资金充足的实体的激励因素已经改变。要想以可量化的方式真正衡量影响，就需要在没有 LLM 的情况下，同样投入大量资金来增加补丁数量。
- AmazingEveryDay
机器生成的 amdgpu 头文件究竟能变得多大？也许该设定一些限制了。
- dash2
看来值得对引入的 bug 做一个生存分析（vibecoding）。但又不太像标准的生存分析，因为在我们发现 bug 之前，甚至不知道它们的存在……有没有公开可用的数据集？如果有，请提供 URL。
- tosti
给那些升级到 7.3 的人提个醒：我刚把 Slackware 系统从 7.3-rc7 降级到了 7.2.10，因为 /dev/input/events 缺失。结果键盘和鼠标只能在控制台里用。
YMMV
- cwillu
请不要在标题中加入主观评论。
（编辑：标题已修正）