由于 AI 的帮助，Google 在 6 月修复的 Chrome Bug 比过去两年还多

原文 ↗ Hacker News 讨论 ↗

Google 声称，借助 AI 辅助工具，Chrome 工程师在最近一个发布里程碑中发现并修复的安全漏洞，比过去两年加起来还多，这引发了关注与怀疑并存的反应。评论者指出，大语言模型在与测试和工具紧密结合时，确实能在代码分析、重构和安全审查方面很有用，但也质疑 AI 同时引入了多少 Bug、使用了哪些模型，以及结果是如何衡量的。讨论进一步扩展到对炒作式 AI 采用、开发者工作流，以及 Google 对网络平台日益增强控制的担忧，同时也提到 AI 在更高层次设计、UX 质量和长期存在的功能性 Bug 方面的局限。

对 Google 这一说法的总体反应

  • 许多人认为，借助 AI 辅助发现 Bug 是合理的，尤其是对于像 Chrome 这样庞大而复杂的 C++ 代码库。
  • 也有人持谨慎态度，认为这篇博客更像是一家在 AI 上投入巨大资金的公司的营销内容。
  • 不少人指出，这篇文章讨论的是跨多个发布里程碑的 安全 Bug，而不是单个月份里的所有 Bug。

AI 如何用于 Bug 和安全

  • 评论者表示，LLM 在以下方面表现不错：
    • 类静态分析、对抗性测试和重构建议。
    • 大规模代码库扫描、重复 Bug 检测和安全审查分流。
    • 在外部研究人员利用漏洞之前自动搜索漏洞。
  • 有人将其类比为 fuzzers、linters 和形式化工具：AI 就像“另一种更强大的自动检查器”，但它运行在更接近人类推理的层面。

怀疑、缺失的指标以及潜在缺点

  • 很多人会问：
    • 有多少借助 AI 修复的 Bug 被回滚了？
    • AI 又引入了多少新 Bug？
    • AI Bug 发现器的误报率是多少？
  • 有些人怀疑管理层在玩 KPI 游戏（例如把 AI 用在容易修、影响较小的积压 Bug 上），并抱怨这篇文章只给出“胜利”，没有失败数据。
  • 也有人反驳说，哪怕关闭了许多小问题或难以利用的问题，只要整体安全性提高就是净收益，因为漏洞利用链往往需要很多 Bug。

AI 也创造了 Bug 吗？

  • 一条批评意见是：AI 生成的代码可能会抬高 Bug 数量，所以“修复更多”未必显然是好事。
  • 反驳观点：
    • Chrome 已有约 20 年历史；大多数严重 Bug 早于 LLM 的使用时代。
    • 仓库统计并没有显示近期新代码出现爆炸式增长。
    • 即使 AI 引入了一些 Bug，修复许多问题、打断漫长的漏洞利用链仍然有价值。

更广泛的 AI 开发体验

  • 很多人反馈 LLM 在以下方面很有帮助：
    • 代码审查、依赖和安全更新，以及小型重构。
    • 当以真实遥测/剖析数据为依据，并在闭环中运行时，性能调优也很有效。
  • 也有人觉得 LLM 在高层设计、系统简化或深度性能方向上表现不佳，并抱怨代码和内部沟通里充斥着“AI slop”。

关于 Chrome、C++ 以及生态控制的担忧

  • 有些人认为这凸显了大型 C++ 系统有多脆弱，并主张用内存安全的语言重写（例如 Rust）；另一些人则为 C/C++ 辩护，认为更好的工具链就够了。
  • 除了 AI，本身还有人对 Google 对网页技术栈的主导地位以及由广告驱动的产品决策感到不安；修复更多 Bug 并不能解决这种结构性问题。