调试网页要一直切窗口我折腾了三年，今天 Chrome 把 DevTools 直接交给 AI 了——chrome-devtools-mcp 把这件事彻底收了

调试网页要一直切窗口我折腾了三年，今天 Chrome 把 DevTools 直接交给 AI 了——chrome-devtools-mcp 把这件事彻底收了

以前调试页面，你大概也经历过这个流程：AI 生成的代码跑起来了，但效果不对，然后你开始漫长的来回切换——让 AI 改一行样式，切到浏览器看效果，切回来继续描述问题。一晚上下来，光切换窗口就消耗了大量注意力。

Chrome DevTools 团队今年给这个问题给出了一个官方答案：chrome-devtools-mcp。这是一个基于 MCP 协议的 Chrome DevTools 服务端，把浏览器所有的调试能力以标准化接口暴露给 AI 编程助手。Claude Code、Cursor、Copilot 现在都能直接操控 Chrome 的内部状态，而不只是拿到一个页面截图。

它的核心能力

这个 MCP Server 暴露了 20 多个工具，基本覆盖了 DevTools 所有核心功能：网络请求抓包、控制台日志读取、性能 trace、内存堆快照、DOM 查询与修改、页面截图。你可以让 AI 直接读某个按钮的 computed styles，调出某个请求的 header 参数，或者抓一段 interaction trace 让它自己分析卡顿原因。

配置只需要两步

先启动一个带调试端口的 Chrome：

google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug

然后在 Claude Code 或 Cursor 的 MCP 配置里加一行：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp"]
    }
  }
}

配置完，AI 就能直接对你的浏览器发指令了。

这不是又一个浏览器自动化工具

之前业界有 Puppeteer、Playwright 这套方案，它们的定位是「控制浏览器执行操作」。chrome-devtools-mcp 的定位不一样——它是「调试感知」，让 AI 看到浏览器的真实运行状态。你让它分析 INP 问题，它可以直接拉 Lighthouse trace；你让它检查样式，它可以直接读 computed panel；你说「这个动画为什么卡」，它可以抓一段 performance profile 给你指出主线程卡在哪一行。

落地场景

我跑了几个真实场景下来，有三个特别顺：一个是让 AI 帮我在几十个网络请求里找出哪个 response time 异常，它直接筛出了那个超时请求的详情；一个是让 AI 帮我分析 CLS 问题的来源，它拿了 LCP 前后两张截图对比告诉我布局偏移发生在哪个元素；还有一个是让 AI 直接帮我验证修复后的效果，不用我再手动刷新比对。

下一步

如果你在用 Claude Code，可以先跑一下这个配置，感受一下「描述问题 → AI 直接检查浏览器状态 → 拿到精准答案」的流程。这和之前的「描述问题 → 猜答案 → 试 → 描述下一层问题」的循环是完全不同的体验。