Cursor把Chrome插件开发效率抬了10倍

开发浏览器插件最折磨人的不是写代码，是改一行就要手动刷新、切窗口、看效果。一个第三方网页的DOM结构黑箱、类名随机、API封闭，传统开发像蒙眼射箭。

这套流程平均每次迭代3-5分钟。有人算过，一天能浪费2小时在"保存-刷新-检查"的死循环里。

现在有个新玩法：让AI直接"看"到浏览器状态，实时验证自己的修改。开发者@akshaykumar90最近开源了一套配置，把WXT框架、Chrome DevTools MCP和Cursor串成闭环。

核心思路很简单：给AI开一双能操作浏览器的"手"，让它自己调试自己写的代码。

1. WXT：给Chrome插件装上热更新

WXT是个Chrome插件开发框架，主打文件路由、热重载、TypeScript开箱即用。它的隐藏技能是启动Chrome时注入自定义参数——包括--remote-debugging-port调试端口。

配置里关键几行：

```typescript
// wxt.config.ts
runner: {
chromiumArgs: [
'--remote-debugging-port=9222',
`--user-data-dir=${process.cwd()}/.chrome-debug-profile`,
'--exclude-switches=enable-automation',
],
startUrls: ['https://example.com'],
}
```

运行wxt或npm run dev，框架自动拉起Chrome、加载插件、监听文件变更。开发者不用手动管理浏览器实例。

2. MCP：给AI发一把浏览器钥匙

MCP（Model Context Protocol，模型上下文协议）是AI调用外部工具的通用接口。Chrome DevTools MCP把Chrome DevTools协议包了一层，让AI能执行导航页面、执行JavaScript、截图、检查DOM这些操作。

Cursor里的配置长这样：

```json
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest",
"--browserUrl=http://127.0.0.1:9222"
]
}
}
}
```

Cursor启动时自动拉起MCP服务，连上9222端口。AI从"盲写代码"变成"边看边改"。

3. 一个脚本管全流程

作者写了个shell脚本dev.sh封装四种模式：

| 命令 | 作用 |
|:---|:---|
| ./dev.sh dev | WXT开发模式（热重载+MCP）|
| ./dev.sh start | 测试生产构建（无热重载，保留MCP）|
| ./dev.sh stop | 杀掉调试Chrome |
| ./dev.sh status | 检查CDP连接状态 |

脚本处理了端口冲突、PID管理、连接验证这些脏活。开发主用dev模式，WXT包办一切；start模式用来测打包后的扩展。

这套组合把单次迭代从分钟级压到秒级。AI能看到DOM变化，立刻知道自己的代码有没有生效，不用人当"人肉测试机"。

但有个隐患被评论区反复提起：AI操作浏览器会不会越界？比如误触生产环境、截图敏感页面、或者在调试端口暴露时引入安全风险。作者目前的方案是用独立用户数据目录隔离，但权限边界怎么画，社区还没共识。