Google 靠 AI 六月修复的 Chrome 漏洞超两年总和
Google fixed more Chrome bugs in June than over the past two years, thanks to AI
Chrome 安全团队正经历一场由 AI 驱动的变革。借助 Large Language Models，我们实现了从漏洞发现、分类到修复的全流程自动化。在 2026 年 6 月，Chrome 修复的安全漏洞数量甚至超过了过去两年的总和。通过 Gemini 等模型，我们不仅发现了潜伏 13 年的沙箱逃逸漏洞，还将漏洞分诊时间从数分钟缩短至秒级。多智能体工作流让 AI 能自动生成候选修复方案并编写测试，大幅提升了修复效率。面对日益复杂的网络威胁，Chrome 正加速发布节奏，计划每周进行两次安全更新，以最小化补丁窗口，确保用户安全。
在最近的两个里程碑版本 Chrome 149 和 150 中，我们修复了 1072 个安全漏洞，这一数字超过了此前 23 个版本修复漏洞的总和。
HN 评论区
601- VBprogrammer
最近在工作特别忙的时候，我大量使用 AI 进行性能优化。我得说，在高层方向上它几乎完全没用——比如它会指出 SQL 查询中可疑的部分，但连续测试下来，这些几乎从未带来任何性能提升。
事实上，如果不是因为它让我更容易实施我自己发现的改动（比如把这些 join 移到 CTE 中等等），它反而成了累赘。我不仅被一堆无用的建议带偏了，还得忍受别人把原始 AI 输出直接甩给我，好像那是什么有意义的贡献似的。
- unprovable
真正关键的数据点是：今年五月刚结束的柏林 Pwn2Own 竞赛中，Firefox 一分钱奖金都没发出去。这简直闻所未闻——自 2007 年以来，他们每届活动都发过奖（我查过）。这是否意味着我们终于得告别那些容易摘的果子了？大概吧……这确实表明这些模型有一定用处。
- truncate
我不是不相信修复大量漏洞是可能的，但我也好奇背后的实际情况是怎样的。团队里的人是不是也比平时更拼命了？既然是 Google，我不奇怪会有“内部推动”，要求在接下来 X 个冲刺周期内修复更多漏洞，好让他们能发布这篇博客，让某个经理向上司展示影响力和 AI 的适配成果。
- glimshe
这里很多人似乎活在一个和我完全不同的宇宙里，或者根本不懂怎么用 AI。我觉得反对者以为你应该让 AI 盲目地干完所有活，而不是把它当作加速你工作的工具。他们就像因为投资回报差而怪罪 Excel 一样生气。到了这一步，这种稻草人论证已经不值得反驳了。
我想放弃这场讨论，继续安静地使用 AI，同时和那些对正确、高效使用 AI 感兴趣的人交流技巧。
- ryanackley
这些自动修复中有多少被回滚了？有多少引入了新漏洞？发现代理的误报率是多少？这篇文章只统计了一切顺利的情况，对可能出错的地方却只字未提。
- branko_d
令人担忧。如果推演（推测性的）未来，这意味着 Google 会认为很快 Chromium 基础版就不再需要开源社区众包的漏洞挖掘了。我预计 Google 最终会停止在开源模式下开发 Chromium，而当前所有 Chromium 衍生版都将变成最后一个发布版本的“事实上的分叉”。由于这些维护团队无法获得像 Chrome 借助 Gemini 那样的补贴，这些分叉版将难以同等轻松地维护。
- dabedee
对 AI 的批评往往陷入一个狭窄的范畴：用 AI 盲目生成代码是错的。这点很容易同意。
但对抗性测试、检查开发者假设、重构建议、小型开发工具，甚至某些引导式编程，都位于你能用 AI 和代码做的事情的光谱另一端。对于越来越大的代码库，即使是追踪依赖关系或行为这类简单任务，也可能得到极大帮助。
而针对另一端那个狭窄范畴（盲目生成代码）的批评，太容易被与其余部分混为一谈了。
- voska
房间里的大象：这些漏洞中有多少最初就是由 LLM 写出来的？
因为制造 100 倍多的漏洞，然后修复 100 倍多的漏洞，这没什么值得骄傲的。