OpenAI 最近给 Codex 做了个 Chrome 插件。

我知道。你听到“浏览器插件”四个字，大概率眼皮都没抬一下。

毕竟这年头谁还没见过几个浏览器插件？广告拦截、翻译、截图、自动填表，Chrome 商店里一抓一大把，没什么好稀奇的。

但是你先别划走。

这个插件进的是你已经登录的 Chrome。

你细品一下这句话。

你每天打开的那个 Chrome。里面存着公司后台、SaaS 系统、客户 dashboard、发布按钮、删除按钮、付款按钮、管理权限、cookie、token……

现在 AI 要进去了。

说实话，我看到这个消息的时候，第一反应不是“牛逼”，而是：这东西真能给吗？

你会不会也经常干这种事？

先讲个场景，你大概率经历过。

你让 Codex 帮你修一个 bug。

它读代码、改代码、跑测试，一通操作猛如虎。然后告诉你：“搞定了。”

你很开心。打开浏览器，登录后台，找到那个页面。

报错了。

红色提示一闪而过。

于是你开始了一项特别原始的工作：当传话筒。

“我刚点了保存，右上角弹了个红色的提示。”“不是弹窗，是一个 toast，红的。”“Network 里有个接口报了 400。”“不是这个页面！左边菜单第三个，进去之后还有一个二级页面！”“这个字段要用管理员账号登录才能看到。”

你越说越像个客服。

AI 明明挺聪明的，但你把自己活成了它的人肉浏览器插件。

Codex 这个 Chrome 插件要解决的，就是这个事。

一句话概括：以前 AI 只能在代码仓库里帮你改东西，现在它能自己打开真实页面看一眼了。

这一眼，比你想象的重得多。

别急着说“这跟 Playwright 有什么区别”

OK，我知道你们这些搞工程的，脑子里已经弹出防御机制了。

“Playwright 不就能点按钮吗？Puppeteer 不也能？Selenium 不也行？这玩意有什么新意？”

打住。

Playwright 的看家本事是稳定复现。

你写脚本，它照着跑。今天跑，明天跑，CI 里跑，结果都一样。这是它的看家本事，没人否认。

但真实世界修 bug，很多时候是另一回事。

你连“第一步该干啥”都不太确定。

保存失败了？可能是某个字段偏偏是空的。菜单少一项？可能是权限判断有隐藏条件。数据和接口对不上？可能是返回结构悄悄变了。表单提交没反应？可能是页面把隐藏字段漏了。

这些情况下，你让 AI 一上来就写 Playwright 测试？

那属于强行加戏。

更自然的流程是这样的：

1. 1. AI 先打开页面，去现场看一看；

2. 2. 找到规律，理顺复现步骤；

3. 3. 回代码里修掉；

4. 4. 修完再到页面上验证一下；

5. 5. 最后把稳定路径写成 Playwright，交给 CI 跑。

Playwright 是巡逻路线。Codex 插件是第一次去事故现场。

先摸清现场，再画巡逻路线。这个逻辑不难理解吧？

也别急着说“这不就是 DevTools 吗”

还有一拨人会说：“Chrome DevTools 不够用吗？F12 一开，Network、Console、DOM、Performance 什么看不到？”

没错。DevTools 是好东西，开发者的命根子。

但它有一个隐形前提：你知道你该查什么。

它是一套精密仪器，但不是医生。

你生病了，给你一台显微镜和一把手术刀，你大概率也不知道该往哪看、该切哪。

Codex 插件的价值在于，它让 AI 带着任务进页面。

你说一句“帮我从这个保存失败的现象，一路查到代码问题”，它至少能把页面现象带进任务里：打开页面、操作表单、观察状态、回到代码里找可能原因。

如果问题继续落到 Network、Console、堆栈这些线索，再配合 DevTools 或 MCP 工具查。和过去相比，区别在于你不用一直在浏览器和对话框之间来回复制信息。

简单说：DevTools 是显微镜，Codex 插件是让 AI 自己拿着显微镜去找线索。

还有一个更底层的：CDP

技术向的东西我尽量说人话。

还有一层叫 Chrome DevTools Protocol，简称 CDP。它是浏览器控制的底层协议，很多工具（包括 Playwright、Puppeteer）本质上都在 CDP 上面跑。

它很强。真的强。但它不是给人日常用的。

你想想，你要处理 WebSocket 连接、session 管理、domain 命令、事件监听、状态维护、异常恢复……

这就像一台发动机。很猛，但你不会每天抱着发动机上班。

Codex 插件做的是上层的事：你能不能看到真实页面？能不能理解任务？能不能把结果带回代码里？高风险的能不能让人确认？

产品层看的是这些问题，而不是协议本身。

最像它的其实是 Chrome DevTools MCP

如果要找一个近亲，我会说 Chrome DevTools MCP。

它把 live Chrome 的调试能力通过 MCP 协议暴露给 AI，让 agent 能用 Network、Console、性能 trace 等。已经很接近“AI 操作真实浏览器”了。

但它和 Codex 插件还是有差别：

• • Chrome DevTools MCP 像个通用工具箱，给各种 agent 拿来用；

• • Codex Chrome 插件更像个专用入口，嵌在 Codex 自己的任务流里。

你在搭自己的 agent 系统？用 MCP。你平时就在 Codex 里干活？插件更顺手。

刺激的地方：AI 开始进真实业务系统了

前面都在聊“它不是什么”。现在聊聊它到底是什么，以及为什么这东西让人又兴奋又发毛。

以前的 AI coding agent，活动范围基本都在安全区：

• • 代码仓库 ✓

• • 本地终端 ✓

• • 本地测试 ✓

• • 沙箱浏览器 ✓

• • CI 日志 ✓

这些地方搞出问题，代价通常是可控的。最多代码改坏了，回滚一下。

但是 Chrome 插件来了以后，AI 能进的是你已经登录的真实浏览器。

这意味着：

你的 SaaS 后台，它能看到。你的管理权限，它可能碰到。你的客户数据，它能接触。你的发布、删除、付款、发消息按钮，它理论上都可能进入操作范围。

你开始焦虑了吗？

这个插件最妙也最吓人的地方就在这里：价值来自真实环境，风险也来自真实环境。

一方面，效率真的能提高。以前你截图、转述、复制报错、描述点击路径，来回折腾半小时。现在 Codex 自己看、自己查、自己回来改。

另一方面，真实浏览器里不只有 bug，还有权限、有数据、有一点击就生效的业务动作。

所以这件事的本质，不是“AI 能不能点网页”。

答案变成了：我们敢不敢让 AI 进真实业务系统？

那它到底怎么用？我是这么想的

先说明，这不是推销。我说说我个人打算怎么用它：

第一层：代码仓库里干活。这不用多说。改代码、跑测试、过 lint。一个问题连本地都过不了，你急着开什么真实后台？

第二层：本地页面用 in-app browser。OpenAI 还有个 Codex in-app browser，沙箱环境，测本地页面够用了。别一上来就接 Chrome 插件，那是你的真实浏览器，不是 playground。

第三层：需要登录态的问题，再开 Chrome 插件。问题一旦依赖真实账号、真实权限、真实数据，就该让它上场。

• • “这个客户页面为什么保存失败？”

• • “为什么登录后菜单少了一项？”

• • “提交表单之后页面到底发生了什么？”

• • “dashboard 的数据和接口返回对不上。”

这些场景，才是 Chrome 插件该上场的时候。

第四层：排查完了，固化成 Playwright。不要每次都让 AI 临场发挥。路径摸清了，就把 Playwright 写进 CI。

一句话：Codex 插件负责发现，Playwright 负责守住。

有些红线，我现在就得划清楚

我知道 OpenAI 有安全机制：沙箱、网络策略、审批确认。

但到了真实浏览器这一步，我觉得还得自己加点保险：

• • 用测试账号，别用最高权限的超级管理员；

• • 用单独的 Chrome profile，别跟你日常的浏览器混在一起；

• • 优先接测试环境、预发环境；

• • 生产环境先只读；

• • 删除、发布、付款、发消息、改权限的操作，必须人工确认，这事没得商量；

• • 别把“AI 看过了”当审计证据。

这不算保守过头。

一个进不了真实页面的 AI，能力会被限制；一个能进真实页面的 AI，必须被限制。

往后看，我关心三件事

我不太关心它会不会“点得更像人”。我更在意的是：

第一，权限能不能变细。

以后不能只是粗暴地“允许”或“禁止”访问 Chrome。合理的做法是按域名、按页面、按动作、按表单、按数据类型，一层一层设边界。

第二，过程能不能留下证据。

它看了什么页面？点了什么按钮？读到了哪些 Console 和 Network 信息？最后凭什么判断“修好了”？

这些东西如果不可追踪，团队根本不敢把它放进正经的工程流程里。

第三，探索能不能沉淀。

最好的状态不是 AI 每次去现场点一遍。而是第一次排查，第二次固化路径，第三次交给测试和 CI。这才叫工程化，否则只是把“人点页面”换成“AI 点页面”，爽是爽，但不稳。

最后，说句人话

Codex 这个 Chrome 插件，表面上就是个浏览器插件。

但它做的事，是把 AI 从代码仓库里拎出来，放到你的办公桌前。

过去你是 AI 的手和眼，帮它看页面、帮它传达信息。以后可能反过来了。

所以我的判断很简单：

• • Playwright 守住稳定路径，它负责稳定路径出现之前的现场勘查；

• • DevTools 仍然负责精密调试，它让 AI 也能参与这段调试过程；

• • 普通浏览器自动化负责跑动作，它试探的是 AI coding agent 能不能进入真实业务系统。

门已经开了一条缝。

接下来该关心的不是 AI 会不会点网页，而是我们能不能管住一个已经走进浏览器的 AI。

用得好，少掉无数“我帮你看看再告诉你”的低效拉扯。

用得不好，它就是个权限过大的自动点击器。

怎么选，看你。

反正我肯定会试的。测试账号，单独 profile，预发环境，只读模式。

毕竟这一天早晚要来。与其到时候手忙脚乱，不如现在就把边界想清楚。

有什么想聊的，评论区见。