趋势变化

Chrome安全竞争转向修复吞吐

Chrome两次Stable更新合计列出862项安全修复，CodeMender已用于内部代码库，AI开始进入生产级修复流程。

By All We Need Editorial System

Chrome安全工程更重要的变化，不是一个夸张的修复总数，而是AI开始进入从发现问题到生成补丁的生产流程。官方记录显示，Chrome 149和150的初始Stable公告分别列出429项和433项安全修复；Google DeepMind则确认CodeMender已被用于Chrome等内部代码库。

修复吞吐成为新变量

Chrome 149于6月2日进入Windows、Mac和Linux的Stable channel，Chrome 150随后于6月30日发布。两份初始公告列出的安全修复合计为862项。这个数字至少表明，浏览器团队正以更高密度处理安全改动；但官方记录没有把每项修复逐一归因于AI，也没有据此证明6月的修复量超过此前两年的总和。

AI从扫描器走向补丁流水线

DeepMind披露，Gemini 3.5 Flash Cyber已通过CodeMender用于Chrome等内部代码库。在固定模型调用次数的V8测试中，该模型发现55个确认问题，高于Gemini 3.5 Flash的47个和Claude Opus 4.6的36个。若同一系统还能生成、验证并提交补丁，安全竞争的约束就会从单纯发现漏洞，转向测试容量、代码审查和发布速度。

数量不能代替安全结果

最强的反例来自统计口径。若直接相加两份Stable Channel初始公告，结果是862，而不是传播中出现的1,072；差异可能来自更新范围、后续补丁或计数方式。DeepMind的V8评估也由Google自行设计，尚不能代表跨代码库表现。修复数量还会受到版本节奏和缺陷分类影响，不能直接等同于严重漏洞减少或用户风险下降。

接下来关注什么

下一项可验证变化是Chrome 153计划于9月8日开始采用两周milestone周期。届时应比较严重问题的中位修复时间、AI补丁的接受与回退比例、发布后回归数量，以及第三方对CodeMender结果的复现；这些指标将决定AI是在提高净安全水平，还是仅增加改动吞吐。

信源