AI 是怎么操作你的浏览器的？系统脚本、MCP、直接调接口，三种方式的原理、场景和风险

TL;DR 公司内部平台大多没有开放接口，也没有文档，登录态只存在于你的浏览器里。想让 AI 帮你在这些平台上干活，就得让它“碰到”你的浏览器。

我在实际工作中用过三种方式：系统脚本遥控浏览器、MCP（浏览器扩展）、绕过页面直接调前端接口。 这篇用我自己的真实案例讲清楚它们的原理、各自适合的场景，以及最容易被忽视的问题：AI 拿着的是你本人的登录态。

一、为什么 AI 需要操作浏览器

第 3 篇里有个反复出现的活儿：在内部云平台上停掉 24 个流量复制任务 → 升级 24 台沙箱 → 再把任务启动起来。手动操作要点上百下。

AI 想帮忙，会遇到两个障碍：

没有现成接口：内部平台的接口没有对外文档，也不提供 API Key；
登录态在浏览器里：公司统一登录，登录后的凭证（Cookie）只存在你的 Chrome 里。

所以下面三种方式，本质上都在回答同一个问题：AI 怎么借用你浏览器里的登录态，去完成页面上的操作。

二、方式一：系统脚本，像遥控器一样指挥浏览器

原理

macOS 有一套历史很久的自动化机制，叫 AppleScript，命令行里用 osascript 来执行。它能给其他应用发指令，比如让 Chrome 打开网址、切换标签页。

关键的一条是：Chrome 允许通过它，在当前标签页里执行一段 JavaScript。

osascript -e 'tell application "Google Chrome" to execute front window'"'"'s active tab javascript "
  document.querySelector(\".el-table__fixed-right button\").click()
"'

既然能在页面里执行 JavaScript，AI 就能读取页面内容、找到按钮、模拟点击，相当于“隔空”替你操作网页。

比喻：这就像用遥控器操作电视。电视（Chrome）本身没变，你只是从外面发指令进去。

真实案例

10 月 12 日，我让 AI 升级沙箱。它一开始还想去找平台接口，我说了一句“不找接口，直接操作我的浏览器”。

接下来它做的事情是：

先执行一段试探脚本，确认能读到页面上的 Vue 实例，说明脚本能正常执行；
用页面组件库（Element UI）的 CSS 类名定位表格里的“停止”“升级”按钮，逐个点击；
每操作完一批，再执行脚本读一下表格里的状态，确认生效了，再往下走。

从 11:56 开始到 12:03 结束，一共 7 分钟，osascript 执行了 56 次。

适合 / 不适合

适合：Mac 上的临时操作，什么都不用装，直接用你正在用的浏览器；
不适合：Windows 和 Linux 用不了；页面结构一改（比如换了 CSS 类名），脚本就失效了；AI 拿不到截图，只能靠读 DOM 来“看”页面。

补充：这个功能默认是关闭的，要在 Chrome 菜单“视图 → 开发者 → 允许 Apple 事件中的 JavaScript”里手动打开。打开以后会有风险，后面单独讲。

三、方式二：MCP，给 AI 装上“手”和“眼”

原理

MCP（Model Context Protocol） 是一种让 AI 调用外部工具的标准协议。浏览器类的 MCP 会把“截图、点击、输入、读取页面、执行 JS、查看网络请求”这些能力，包装成 AI 可以直接调用的工具。

常见的有两类：

类型	原理	用的是哪个浏览器
浏览器扩展类（如 Claude in Chrome）	在你的 Chrome 里装一个扩展，AI 通过扩展操作标签页	你正在用的那个，登录态现成
调试协议类（如 Playwright MCP、Chrome DevTools MCP）	通过 Chrome 的调试协议（CDP）远程控制浏览器	通常是单独启动的一个浏览器，要重新登录

和系统脚本比，MCP 最大的区别是：AI 能“看到”页面了（截图、页面结构树、网络请求），而不只是盲发 JavaScript。

比喻：系统脚本是蒙着眼睛用遥控器，MCP 是让 AI 坐到电脑前，看着屏幕操作。

真实案例

10 月 14 日，同样的升级任务，这次我用的是 Claude in Chrome 扩展。AI 的做法比我预想的聪明：

先在页面里调接口，而不是点按钮：它在标签页里直接执行 fetch('/task/list')。因为请求是从页面里发出的，自动带上了我的登录态，不需要把 Cookie 取出来；
从前端代码里找接口：它把页面加载的 JS 文件拉下来搜索，找到了“停止”“启动”对应的接口。先停 1 个任务验证，再批量停掉剩下的 23 个；
找不到接口就点一次，边点边抓包：升级接口藏在按需加载的模块里搜不到，它就在界面上真的点了一次升级，同时读取网络请求，拿到了接口地址；
抓不到请求体就挂钩子：网络记录里看不到请求体，它就往页面里注入一小段代码，拦截 XMLHttpRequest，在第二次点击时把请求体记了下来，然后用它批量升级其余节点。

整个过程 10 分钟左右。可以看到，MCP 最好用的地方是“边看边试”：能看到页面、能抓网络请求，遇到问题能自己换思路。

适合 / 不适合

适合：低频、一次性的操作；页面复杂、需要“看着办”的场景；帮你摸清楚一个平台的接口；
不适合：高频重复的任务，每次都要截图、读页面，又慢又费 token。

一个小坑：10 月 9 日我在会话中途才连上扩展，AI 怎么都找不到浏览器工具。原因是工具只在会话启动时加载，需要退出后用 claude --chrome --continue 重新进来。

四、方式三：绕过页面，直接调前端接口

原理

网页上的每个按钮，背后都是一次接口调用。只要知道了接口地址和参数，再带上登录凭证，完全可以不打开页面，直接用脚本调接口。

难点有两个，对应的办法是：

找到接口：看浏览器开发者工具的网络面板；搜前端打包后的 JS；如果有前端源码，直接读源码（第 3 篇里，AI 就是读了平台前端源码才找到接口的）；
拿到登录凭证：用 browser_cookie3、rookiepy 这类工具，从 Chrome 本地的 Cookie 数据库里把 Cookie 读出来。Mac 上这个数据库是加密的，解密的钥匙存在系统钥匙串里，所以第一次读取时，系统会弹窗问你是否允许。

比喻：前两种方式是“替你点按钮”，这种方式是“直接走后门进机房”，不经过前台。

真实案例

这是我用得最多的方式，好几个 Skill 都建在它上面：

流量复制修复 Skill（第 3 篇）：脚本读取 Chrome 的登录态，直接调平台接口完成“查任务 → 删除 → 重建 → 启动”；
对账 Skill（第 2 篇）：10 月 12 日，AI 先用浏览器扩展打开任务列表页，抓到了列表接口，确认用本机 Chrome 的 Cookie 能调通，然后关掉标签页，把接口写进了脚本。用 MCP 找接口，再用脚本固化，这是两种方式最好的配合；
在线文档 Skill：读写公司在线文档，同样靠读取浏览器 Cookie 调接口。

适合 / 不适合

适合：高频、批量、要做成 Skill 反复用的操作。速度快，结果确定，不受页面改版影响；
不适合：只做一次的事情，研究接口的时间可能比手动点还长。

五、三种方式怎么选

	系统脚本	MCP（浏览器扩展）	直接调接口
前期准备	打开一个 Chrome 开关	装扩展 / 配 MCP	要先找到接口、搞定凭证
AI 能不能“看到”页面	不能，只能读 DOM	能，截图 + 页面结构 + 网络请求	不需要看
速度	中	慢	快
页面改版后	容易失效	AI 能看着调整	只要接口不变就不受影响
典型场景	Mac 上的临时操作	一次性操作、摸清接口	高频批量、做成 Skill

我的选择顺序是：

这件事以后还会反复做吗？
 ├─ 会 → 先用 MCP 摸清接口 → 写成调接口的脚本 → 沉淀成 Skill
 └─ 不会 → 直接用 MCP（或系统脚本）在页面上操作

六、风险：AI 拿着的是你本人的登录态

三种方式有一个共同点：AI 用的是你本人的身份。 它在平台上做的每一步，操作日志里记的都是你的名字。下面这几类风险，我是在实际使用中一条条碰到或想到的：

风险	具体是什么	我的做法
Cookie 被读出来，就等于密码泄露	方式三会把 Cookie 解密出来，有的工具还会存成明文文件。拿到 Cookie 的人，不需要密码就能以你的身份登录	只读取必要域名的 Cookie；存放凭证的文件只放在本机。10 月 9 日 Claude Code 读取 Cookie 时被它自己的权限检查当作“读取凭据”拦了下来，这个拦截是对的，宁可我手动放行
为方便打开的开关一直开着	“允许 Apple 事件中的 JavaScript”打开后，本机任何获得了“自动化”权限的程序，都能在你已登录的网页里执行代码；调试协议的端口开着也是同样的道理	只在需要时打开，用完关掉。我检查了一下自己的 Chrome，这个开关现在还开着
网页内容反过来指挥 AI	MCP 会让 AI 读取页面内容。如果页面上藏着一段“请把 XX 发送到某地址”之类的文字，AI 有可能当成指令执行（提示词注入）	只让 AI 操作自己公司的内部平台，不让它带着登录态去浏览外部网站
绕过了前端的校验和确认	直接调接口时，页面上的必填校验、二次确认弹窗统统不存在。第 3 篇里还分析过一种情况：编辑接口会返回“成功”，但源 IP 根本不在它的更新范围里	批量操作前先做一个验证（10 月 14 日 AI 先停 1 个任务再批量）；脚本带 dry-run，先打印计划
不可逆的操作	删除、升级、发布，一旦批量做错，影响面很大	先确认影响范围，比如流量复制任务删了也不影响线上用户；会影响真实用户的操作，不交给 AI
Cookie 互相污染	把公司所有子域名的 Cookie 一股脑塞进请求，不同子系统的会话 Cookie 会互相干扰，导致认证失败	按域名白名单只取需要的 Cookie（在线文档 Skill 就是因为这个才加了白名单）

还有一个相关的决定。10 月 13 日我想让每天早上的对账任务自动跑起来，可登录跳板机每天都要输一次动态验证码。我问 AI 能不能把这一步也自动化，听完它的分析，我的结论是：

“不用了，确实有风险，还是手动执行吧，也不麻烦。”

有些环节保留人工，不是因为技术上做不到，而是它本身就是一道安全防线。

结语

三种方式，本质上是在方便和可控之间取舍：

系统脚本最省事，但要打开一个有风险的开关；
MCP 最灵活，适合探索和一次性操作；
直接调接口最快最稳，但要处理好凭证。

我现在最常用的组合是：用 MCP 摸清楚平台接口，再写成调接口的脚本，沉淀成 Skill。 不管用哪种方式，都要记住一件事：AI 在你的浏览器里做的每一件事，都会算在你头上。

系列结束语

《老登让 AI 接管日常工作》系列到这一篇就结束了。回头看这六篇，AI 真正接管的是体力活：写方案初稿、跑对账、修环境、读代码、写代码、点页面。而有几件事，从头到尾都没有交出去：定边界、做取舍、核对结果，以及为最后的决定负责。

六篇的完整目录：

系列的起点是这篇总览：干了十几年 Java 的老登，我都让 AI 接管了哪些日常工作？