Chrome扩展开发玩了把大的：AI现在能直接"看见"浏览器了

传统Chrome扩展开发有个死循环：改代码→打包→手动测试→发现DOM结构变了→再改。一位开发者统计过，光是定位第三方网站的minified class name，就能吃掉40%的工时。

最近一套新工具链在GitHub技术圈传开。它把开发周期从小时级压到分钟级，核心思路很直白：让AI代理直接操作浏览器，而不是在黑暗里猜。

三件套拼在一起：WXT + Chrome DevTools MCP + Cursor

WXT是个Chrome扩展框架，把文件路由、热重载、TypeScript支持打包成开箱即用的配置。它的隐藏技能在于runner模块——能带着自定义Chromium参数启动浏览器。

关键参数就一行：--remote-debugging-port=9222。这串数字打开的是Chrome DevTools Protocol（CDP）的入口，让外部程序能远程控制浏览器。

MCP（Model Context Protocol，模型上下文协议）是Anthropic推出的开放标准，让AI代理调用外部工具。Chrome DevTools MCP把它桥接到CDP上，AI于是获得了导航页面、执行JavaScript、截图、审查DOM的能力。

配置极简。在Cursor项目的.cursor/mcp.json里写几行，启动时自动连接：

「When Cursor starts, it spins up the MCP server, which connects to Chrome on port 9222. The AI agent can now see and interact with your browser.」

开发者用shell脚本把流程封装成四个命令：./dev.sh dev启动热重载+AI调试，start测生产包，stop杀进程，status查连接状态。端口冲突、PID管理、连接验证都自动处理。

为什么第三方网站改造特别需要这套

企业级SaaS的DOM是黑箱。class名被压缩成a1b2c3，下次部署变成x9y0z1，没有官方API可hook。传统做法是用 brittle 的CSS选择器硬匹配，一改版就崩。

AI代理的优势在于能实时观察实际DOM状态，而不是依赖过时的代码假设。它可以截图对比、执行试探性查询、验证修改是否生效——相当于给扩展开发配了个24小时在线的QA。

具体场景：你想在Notion或Figma的界面里注入自定义按钮。以前要手动打开DevTools，一层层展开DOM树，试错十几次定位元素。现在AI代理直接"看"到当前页面结构，生成选择器的准确率显著提升。

这套方案目前有个明显边界：它解决的是"观察-验证"环节，代码生成质量仍依赖底层模型。如果AI对Chrome扩展的manifest v3规范理解有误，还是会产出权限配置错误。

技术社区的反馈分化

支持派认为这代表了"agentic development"的落地——AI从代码助手进化到能操作运行时的协作者。反对声音则担心调试端口的安全风险，以及AI在复杂DOM操作上的可靠性。

一个未被充分讨论的点是：当AI能实时读取任意网页的完整DOM，隐私边界在哪里？开发者强调这套工具仅用于本地调试，但技术能力的扩散往往超出设计者的控制。

目前该工具链的GitHub仓库star数增长曲线陡峭，但生产环境采用率尚不明朗。WXT maintainer 在讨论区回复称，正在评估把MCP集成做成官方插件的可能性。

那位最早分享这套方案的开发者，在文档末尾留了句备注：「dev is the primary mode — WXT handles everything and you get hot reload. start is for testing production builds with MCP inspection.」

你更信任AI代理的实时观察，还是人类开发者对DOM结构的静态分析？