张苏丽如果你和我一样，日常开发的大部分时间都泡在 VS Code 里，那你大概率也有过这种体验：AI 能帮你改代码、能解释报错，可真要查一个网页上的最新接口文档、跑一遍测试流程、或者把某个后台表单逐项填完，你还是得自己切到 Chrome，一顿操作之后再把结果搬回来。
我一直想把这个“搬砖过程”也扔给 AI。于是最近就折腾了一套很直接的工具链：在 VS Code 里装一个支持 MCP 的 AI 助手，再通过 Chrome 的 MCP Server 把浏览器控制权交给它。换句话说，我可以直接在编辑器对话框里发指令，让 AI 自己打开 Chrome、访问页面、点击按钮、提取内容，甚至把结论写进项目文档。
这套链路里用到的东西都不复杂：VS Code 作为工作台，Chrome 作为操作目标，MCP（Model Context Protocol）负责把 AI 和浏览器连起来。我实际跑通了几条工作流，包括让 AI 替我去新闻页抓最新标题、去控制台定位问题、以及验证本地页面上的交互效果。这篇文章把完整实现过程、选择思路和踩坑记录都整理出来。
1. 为什么“会截图”远远不够，我们需要一个能让 AI“看见结构”的通道
早在 MCP 流行起来之前，就有人尝试让 AI 直接操作浏览器，常见做法是给模型截一张页面图，然后让它猜按钮坐标。说实话，那套方案用起来非常痛苦。
浏览器页面是动态渲染出来的，同一个按钮不同窗口尺寸下位置完全不一样，页面一滚动坐标就全废，弹窗和懒加载更是能把“坐标流”方案直接击穿。真正稳定的能力是读取 DOM 结构、触发事件、等待网络返回，这些恰恰是大模型最容易学会、又最不擅长亲自动手做的事。
MCP 解决的就是这个错位问题。打个比方，MCP 很像给 AI 配了一套“标准 USB 接口”，鼠标、键盘、屏幕、文件系统都可以通过同一套协议接入。模型不需要关心你用的是 Chrome 还是 Edge，不需要知道你机器上有没有装 Playwright 驱动，只需要知道自己能调用哪些“工具”（tools）。
当这套协议被用在浏览器场景时，AI 拿到的不再是一张看不懂的截图，而是页面里结构化的信息：当前网址、可见文本、标题层级、可点击元素、表单字段标签。它就像真的“读过”了这个页面，而不是“看过”这个页面。这带来一个很直接的变化：模型做出判断的可靠性高了不少，尤其是在页面结构经常改版的时候。
Chrome 的 DevTools MCP Server 就是顺着这个思路实现的。它把 Chrome 开发者工具的能力包装成 AI 可调用的工具集，包括但不限于：打开新网址、点击页面元素、向输入框填写内容、获取完整页面文本、执行一段 JavaScript、切换标签页、以及截取当前页面图。严格来说，这不是“让 AI 代替 Chrome”，而是“让 AI 通过 DevTools 协议访问 Chrome”。
关键点在于，这套工具完全跑在本地，Chrome 窗口就是你自己屏幕上那个正在运行的浏览器。你不需要额外部署服务器，不会有“云端浏览器打开之后也不知道在干嘛”的失控感。所有动作都在你自己眼皮子底下发生，这一步对实际开发来说太重要了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我的工具组合：VS Code 做指挥台，Chrome MCP Server 当双手
动手之前先理清整个链路里的角色分工。整个系统里不需要自己写多少代码，但每个组件承担什么职责，一定要先搞清楚，不然之后排查问题会一头雾水。
2.1 三个必要组件，缺一个都跑不起来
第一是 AI Agent，也就是你真正发指令的那个对象。在 VS Code 里可以用支持 MCP 的 AI 扩展，目前主流的有 Cline、Roo Code，以及部分官方智能编程扩展的 Agent 模式。它们负责读懂你的中文指令、拆解步骤、决定调用哪个工具。这层相当于“大脑”。
第二是 MCP Server，我选的是 Chrome DevTools MCP Server。它跑在本地，由 AI Agent 主动拉起，然后通过 Chrome DevTools Protocol（CDP）和浏览器对话。简单说，Agent 说“我需要点击页面上的登录按钮”，MCP Server 帮它翻译成 DevTools 能理解的底层命令，再把页面结果带回来。这层相当于“神经和肌肉”，直接把想法变成动作。
第三是 Chrome 浏览器本体。MCP Server 启动时一般会自动拉起一个带调试端口的 Chrome 实例。为了不影响自己日常用的浏览器配置，最