北京
周三下午，一个前端工程师对着屏幕发呆。他的AI助手刚"修完"一个bug，页面看起来正常了，但结账按钮依然点不动。他打开Chrome开发者工具，发现是CORS策略拦截了支付接口——而AI全程只盯着截图，对控制台的红字一无所知。
这不是个例。今天Chrome for Developers宣布Chrome DevTools MCP正式稳定， coding agent终于能直接调用浏览器的诊断能力。消息本身技术味很重，但背后的信号很直白：靠截图调试的AI，正在被淘汰。
截图能告诉你"坏了"，但说不清"怎么坏的"。一张静态画面可以显示按钮变灰，却暴露不了是401未授权、429限流、还是CSP规则拦截了脚本。它看不见hydration失败、本地存储过期、或者用户登错了工作区。HTML快照稍好一点，但依然缺了运行时行为、网络时序、认证状态这些关键上下文。
人类开发者遇到这种事会本能地按F12。现在，有用的AI助手也该有同样的权限。
Chrome DevTools MCP给的正是这个：控制台堆栈、网络请求详情、性能追踪、Lighthouse报告、DOM实际渲染结果、cookie与存储状态、多标签页会话上下文。这些不是"更好看的信息"，而是可行动的runtime evidence。模型从"猜测图片里发生了什么"变成"基于结构化数据推理"。
这个模式正在扩散。开发者社区里，让AI驱动真实Chrome、检查多标签会话、返回机器可读结果的工具越来越多。浏览器面板在agent工作区里，正从"预览窗口"变成"审查界面、协作界面、交接界面"。
方向很明确：浏览器工作正在成为agent runtime的一部分。下一步不是"让AI看见Chrome"，而是让浏览器证据以AI能直接处理的形式送达——动作记录、URL与frame定位、观测到的错误与性能警告、最终DOM状态。截图强迫模型做视觉推断，结构化结果让模型真正思考。
那个前端工程师后来手动复制了控制台的错误日志给AI，问题才解决。这种 workaround 很快会显得很 archaic。当AI能直接查询runtime state，调试将从"看症状猜病因"变成"读化验单开处方"。
对做AI coding工具的团队来说，这是个分叉口：继续卷截图清晰度，还是接入真实的浏览器诊断能力？Chrome已经选了边。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
