作者：林岚｜OC 开发者生态编辑

据 TechCrunch 报道，Google 称内部 AI 工具帮助 Chrome 团队在最近一个月修复 1072 个缺陷，数量超过此前两年合计的 1036 个。同期公开统计中，微软修复约 570 个相关缺陷，苹果没有出现同等规模的跃升。

一句话结论：AI 已经能显著扩大大型代码库的缺陷处理吞吐量，但“修复 1072 个”只说明流水线跑得更快，不能单独证明漏洞更严重、补丁更正确，或用户风险下降了同样倍数。

浏览器特别适合测试 AI 修复能力。Chromium 代码量巨大，包含渲染、JavaScript 引擎、网络、图形、媒体和多平台兼容层；很多缺陷不是需要天才灵感的零日漏洞，而是边界检查、生命周期、空指针、测试缺口和重复模式。AI 擅长从相似修复中生成候选补丁，也能补测试、解释编译错误并完成机械修改。

这类工具真正节省的是工程师在“发现问题”和“合入可靠补丁”之间的时间。传统流程里，维护者要定位所有受影响路径、写跨平台测试、等待持续集成，再处理回归。AI 可以并行生成候选方案，缩短最耗人力的重复环节，让工程师把注意力放在设计判断和高风险审查上。

问题不在这里。数字越大，越需要知道统计口径：其中有多少是安全漏洞，多少是普通 bug；有多少由 AI 发现，有多少只是 AI 帮忙修；是否包含同一根因的批量修改；补丁进入稳定版前经历了什么审查。若没有这些信息，1072 更像一项生产率指标，而不是安全效果指标。

修复数量还可能暂时上升，因为 AI 把积压问题一次性清出来。一个项目在某月关闭大量 issue，不代表代码质量突然下降；也可能代表扫描、分类和补丁生成能力变强。相反，如果团队为了追求数量合入低质量补丁，回归、重复报告和维护成本会在后面出现。

Chrome 的优势在于它已经有成熟的 fuzzing、持续集成、代码审查、灰度发布和崩溃遥测。AI 生成补丁嵌入这套系统后，失败会被多层机制拦截。小团队若只复制“让 Agent 自动修漏洞”这一环，却没有同等测试与发布控制，得到的可能只是更多看起来合理的改动。

关键事实

• 来源：Google 对外披露、TechCrunch
• 涉及项目：Chrome、Chromium 及 Google 内部 AI 工具
• 核心技术：自动缺陷分析、补丁生成、测试生成与持续集成
• 关键数字：单月修复 1072 个缺陷；此前两年合计 1036 个

OC 判断

先别急着把“修复数量”换算成“安全提升倍数”。AI 在这里最可信的价值是吞吐量：它让维护者更快处理已知问题。真正决定质量的仍是可复现测试、人工代码审查、独立安全评估和稳定版遥测。自动修复不是替代这些机制，而是把更多候选修改送进这些机制。

为什么重要

• 对开发者：AI 最适合先处理模式明确、测试可验证的缺陷，而不是无监督地重写安全核心。
• 对企业：评估自动修复工具时，应统计回归率、修复时长和漏洞重开率，不只看关闭数量。
• 对用户：Chrome 更新可能更快消除已知问题，但及时升级浏览器仍然不可省略。

参考来源

• Google says it fixed more Chrome bugs in June than over the past two years thanks to AI
• Chromium Security
• Google Project Zero