给本地 Claude Code / Codex / Copilot 装上 Chrome MCP，可以很大程度释放双手

王荣超

给本地 Claude Code / Codex / Copilot 装上 Chrome MCP，可以很大程度释放双手，它会直连到你当前打开的浏览器，网页各种登录态和浏览器插件依旧都在，也省却了很多环境配置复杂度。

无论是文档写作、表格处理、资料搜索还是网页开发，甚至是游戏开发、后台运营，它都可以长时间跑下去，20～60min，直到将任务完成。

这些任务，凭借着自己的“眼疾手快”和“经验丰富”，需要的时间其实也差不多，但现在可以交给 AI 了，何乐而不为呢？😄，推荐大家都试一试，把自己的工作流跑通。

我验证下来，让 AI 操作浏览器去解决问题，对 Token 的消耗没有想象中那么大。很多人会直觉认为浏览器自动化一定很重，但只要把链路设计清楚，它就是一种可控的观测系统，关键在于如何做任务拆解。举几个例子：

如果你的 AI 不够聪明或者表现不好，就把下面这段话发给它，让它先学习学习。

第一个是样式验证。
很多人第一反应是截图对比，但 Chrome MCP 更稳定的方式是先做结构确认。先拿页面快照，关注 DOM 结构和可访问性树，确认关键节点是否存在、层级是否正确，再用脚本读取计算样式，例如 getComputedStyle 或直接读 class、style 字段。只有在结构和样式都符合预期的情况下，才做一次截图作为最终确认。这样做的好处是把“视觉问题”拆成“结构问题 + 样式问题”，前两步都是低成本、低 token 的判断，截图只是兜底，用的不多。

第二个是模拟用户操作。
这里的核心不是“点按钮”，而是让每一步都有状态反馈。AI 会先确认当前页面和上下文，再去执行 click、fill、键盘输入等操作，但关键在于它不会连续盲点。每一次交互之后，都会用脚本去读状态，比如页面是否跳转、某个节点是否出现、文本是否变化、某个状态位是否被更新。如果没有变化，它会判定这一步“无效”，进而调整策略，比如重新定位元素、等待异步完成，或者回溯上一步。这其实是在浏览器里构建了一个非常轻量的状态机。

第三个是执行流校验。
人做这件事，往往靠感觉，觉得“好像不对劲”。AI 的方式更偏显式约束。你在一开始就定义好几个关键断点，例如页面标题、URL、关键 DOM、某个接口返回值、甚至是某段文本的存在与否。每走一步，它都会去对齐这些断点。如果某一步之后，断点没有满足预期，它就会认为执行流发生偏移，然后触发排查路径，一般是查看控制台日志、网络请求和当前状态快照。通过这三块信息，它可以定位是前端状态没更新、接口失败，还是页面结构发生了变化。

第四个是接口与数据链路验证。
Chrome MCP 并不直接替你发请求，它更像一个旁观者，去观察真实页面发生的请求。AI 会在关键操作之后抓取网络请求列表，定位到目标请求，再分析请求参数和响应结果。如果发现接口返回异常，它可以把这一步和前面的用户操作串起来看，从而判断问题是在输入阶段、交互阶段，还是后端返回阶段。相比直接写接口测试，这种方式更接近真实用户路径。

从上面四个例子就可以看出来，它为啥不怎么耗 Token：先定位上下文，再读取结构和状态，然后执行最小必要操作，最后用多维信号去验证结果。一旦验证失败，就回到观测层重新判断，而不是继续往下硬跑。

大家可以尝试将自己的工作做经验拆解，定义好清晰节点，配置好显式化的验证规则。剩下的，就交给 AI 吧～😄