7.2 内核的开发统计
Linux 内核 7.2 的开发统计显示，自 2026 年中以来，每个版本修复的 bug 数量大幅上升，这与 AI 编码工具和代理的更广泛使用同时发生。评论者争论这究竟反映了真正的质量提升，还是只是机器生成补丁的大量涌入，把工作转移给维护者，并可能用巧妙的绕行掩盖新 bug。虽然许多人把 AI 看作务实的生产力提升——这与内核社区过去采纳新工具的经历相呼应——但也有人担心“slop”代码、人类对实现理解变弱，以及缺乏严格方法来衡量长期可靠性。
编辑框架与内核统计
- 原始 HN 标题为了强调“每个版本修复的 bug 数量”而被编辑化处理；版主将其改回，并提醒提交者不要通过标题重构文章。
- 一些评论者将“每个版本修复的 bug 数量上升”视为 LLM 驱动贡献增加的证据；另一些人强调文章本身更为谨慎，把当前 LLM 的使用称为对内核社区和流程的一场“巨大实验”。
LLM 作为工具 vs. “slop”
- 支持者认为，LLM 显著降低了上手门槛，尤其是在内核开发或类似项目中处理复杂流程和样板代码时。
- 他们报告了真实的生产力提升：代理可以复现 bug、调试并提出修复方案，而人类主要负责审查。
- 批评者指出大量低质量（“slop”）补丁和 PR 涌入，称这会打消开源贡献积极性，并让维护者不堪重负。
能力、理解与工具使用
- 一方声称使用 LLM 与能力强弱并无相关性；关键在于贡献者是否理解自己提交的改动。
- 另一些人则认为，在实践中，严重依赖 LLM 往往与浅薄的理解和走捷径相关。
- 一则有争议的类比把禁止 LLM 比作要求所有代码都必须用汇编写，以证明理解；有人认为这并不恰当，因为编译器是确定性的，而 LLM 不是。
- 讨论还涉及：理解一种高级语言（如 C）是否意味着能可靠地建立机器行为的心智模型；未定义行为和复杂性被用作反例。
正确性、bug 与验证
- 怀疑者认为 LLM 代码只是“概率上合理”，并不可靠正确，还可能引入细微 bug（例如数据竞争），即便在非常有经验的开发者参与的 LLM 辅助补丁中也是如此。
- 另一些人反驳说，人类也会犯类似错误；代码审查和测试至少在发布前捕获了一个被强调的数据竞争问题。
- 支持者建议使用强自动化测试，甚至形式化方法，来限制人类和 LLM 带来的回归；但批评者强调测试只是基于样本，无法覆盖完整输入空间。
下游影响与生态行为
- 一些维护者观察到用户提交的 bug 报告变少，怀疑代理在悄悄绕过问题，而不是进行报告。
- 还观察到 LLM 会生成脆弱或“疯狂”的变通方案（例如子进程技巧和日志解析），这可能破坏 API 设计和语义化版本承诺。