一名用户发现Chrome浏览器播放B站等网站视频时，CPU单核长期满载、核心温度升至约70°C，风扇噪音明显，随即展开排查。最初怀疑硬件解码失效，设置后无效；通过进程监控发现chrome的SpeechRecognitionService子进程CPU占用在20%至135%间波动，且人声密集的视频负载更高，暂停视频后占用立即归零。禁用全部扩展、怀疑字幕翻译插件均未奏效，而无痕模式下播放恢复正常，成为关键线索。用户离线检查配置文件，发现唯一激活的字幕项为headless_caption_enabled=true，但手动改为false后，Chrome运行时会在数秒内将其写回true；删除SODA目录后重启又会重新生成，常规手段无法关闭。通过逆向分析chrome.dll，确认真凶是Chrome 155内置的Glic（Gemini in Chrome）媒体理解模块，该模块会自动分析网页视频音频，且代码中将YouTube排除在外。由于chrome://flags中无相关开关，作者编写Python脚本，在Chrome完全退出的状态下修改Local State与各Profile的Preferences文件，显式禁用headless-live-caption、glic.media_understanding_enabled等配置项。应用修复后，播放视频时CPU核心温度降至40°C，风扇恢复安静。
事件分析
此事件揭示了浏览器厂商强推AI功能的典型路径：默认开启、配置回写、无官方开关，用户即便手动修改也会被运行时覆盖。从技术层面看，Glic媒体理解模块依赖本地语音识别进程实时处理网页音频，其算力开销在低配置机器上足以引发明显的温控与功耗问题，而代码中将YouTube排除在外的细节，也暴露出平台对自身流量的保护逻辑。产业层面，浏览器正成为AI能力的分发入口，Google借助Chrome的庞大装机量将Gemini下沉到日常浏览场景，但缺乏透明度与用户控制权的设计容易引发信任危机。后续值得关注的是是否出现更大范围的负载异常报告，以及Google是否会在舆论压力下提供官方关闭入口或企业策略键。
核心观点：浏览器正沦为AI功能的强制分发渠道，用户对自身设备算力的支配权，正在被默认开启的策略悄然收回。
原文链接：Linux.do
