导读：AI 能写测试脚本，但"写"不等于"测"。真正拉开差距的，是你给它配的哪双"手"。本文拆解 5 件 AI 浏览器兵器，再讲讲我用一个技能把整个 QA 流程交给 AI 的实战。

〇、先问三个问题

• 让 AI 写过 Playwright 脚本吧？跑起来红一片，修脚本的时间比手动点一遍还长。
• 发版前还在人肉回归吧？登录、点菜单、填表单，一套流程半小时。
• 最扎心的是第三个：AI 写的测试"看起来很对"，但真正的 bug，它一个都没抓到。

如果以上都中招，这篇文章就是写给你的。

AI 写测试脚本 ≠ AI 做测试。

前者是文员，后者是测试员。区别只有一个：AI 手里有没有浏览器。

一、测试的瓶颈，从来不是脚本

传统自动化测试的死穴就一个字：脆。

UI 改个 class 名，选择器断一片；产品加个弹窗，等待逻辑全乱；流程换个顺序，整条用例作废。脚本省下的时间，最后都还给维护了。

AI 带来的变化是：它不需要提前写死的选择器——它能像人一样"看"页面，临场决定点什么。

前提是，它得真的能操作浏览器。市面上的"手"主要有五件。但逐个点名之前，得先搞懂一件事：这些工具凭什么能"看"、凭什么能"点"。看懂原理，后面的取舍都是白送的。

手决定 AI 测试的上限，流程决定下限。

二、先讲原理：所有工具，最终都要和 CDP 对话

AI 操作浏览器，要过两关：看见页面，和动手操作。

看见：截图是给人的，树是给 AI 的

让 AI"看见"页面，有两条路线。

第一条是截图：渲染成图片，扔给视觉模型认。直观，但一张截图几千 token，模型还会"猜"——小图标、密集列表经常认错。

第二条是可访问性树（Accessibility Tree）。这不是 AI 时代的发明，浏览器本来就在为屏幕阅读器维护它：页面上每个按钮、输入框、链接都是一个节点，标着角色（button）、名字（"登录"）、状态（是否禁用）。纯文本，结构化，语义无歧义。

截图是给人看的，树是给 AI 看的。 主流工具全部押注第二条路线——上下文砍掉 90%，靠的就是它。

动手：CDP，浏览器暴露出来的控制总线

那怎么"点"按钮？答案是 CDP——Chrome DevTools Protocol，Chrome 开发者工具协议。

你按 F12 打开的 DevTools 面板，并不长在浏览器里面。它是个前端页面，背后通过 WebSocket 跟浏览器内核通信，用的就是这套协议。启动 Chrome 时加一个 --remote-debugging-port=9222，这条控制总线就对任何程序开放。

CDP 按"域"（domain）分工，像总控台上的一排开关：

这张表看明白，五件兵器的底牌就全亮了：它们干的事情完全一样——拿树、发事件。差别只在包装层。 至于每家怎么包装，下面点名时一并说。

MCP、CLI、Python 库，都是不同牌子的手套，CDP 才是手。

包装千姿百态，协议殊途同归。

三、Playwright MCP · 微软出的"机械臂"

让 AI 通过 MCP 协议驱动 Playwright，装机量最大的一件。

微软官方出品，2025 年 3 月发布。

架构上是两层：AI 通过 MCP 协议跟 Playwright 通信，Playwright 再跟浏览器通信。在 Chromium 上，走的正是上面说的 CDP；但 Firefox 和 WebKit 走的是各自的私有协议——所以"全都依赖 CDP"这句话，严格来说只对 Chromium 系成立。

它的定位是"顺手"：Claude Code、Cursor 这类 Agent 装上就能点页面，确定性高、速度快，不依赖视觉模型。日常让 AI 帮忙操作几下浏览器，它是出错率最低的选择。

但它不管诊断。想查性能、抓网络，得看下面这件。

四、Chrome DevTools MCP · 谷歌出的"手术刀"

不是又一个"会点按钮"的工具，而是把 Chrome DevTools 的整个面板交给了 AI。

谷歌 Chrome 团队 2025 年 9 月推出，底层是 Puppeteer——谷歌官方的 CDP 封装库。因为离 CDP 近，它拿到了"DevTools 面板级"的能力：性能 trace、网络瀑布、console 日志、内存快照。你平时按 F12 干的活，AI 全都能干。

真正打动我的是另一点：它能接管你本地真实的 Chrome。登录态、Cookie 直接继承，不用在测试环境里重新登录——被"测试脚本绕不过登录页"折磨过的人，懂这个分量。

代价是重。只想让 AI 轻量点几下页面，杀鸡不必用牛刀。

五、agent-browser · 为 Agent 而生的"原生手"

一条 CLI 命令就是一次浏览器操作，快照即标注，省掉 90% 的上下文。

Vercel Labs 开源，2026 年初发布，很快冲到 1 万多 star。在 MCP 当道的今天，它反潮流地选择了 CLI——这个选择反而成了它最大的优势。

为什么？MCP 工具要常驻上下文，每次调用都是一次协议往返；CLI 是用完即走，AI 需要时执行一条命令，输出就是全部上下文。加上它的快照做了激进裁剪——AI 看到的不是几万行 HTML，而是一张 20 行的元素清单，每个可交互元素打上 @e1、@e2 这样的 ref，直接用 ref 操作：

agent-browser snapshot -i                      # 拿树 + refagent-browser click @e3                        # 点agent-browser fill @e5 "test@example.com"# 填agent-browser screenshot page.png              # 留证

上下文就是钱，也是 Agent 的脑子，省下来的都是算力。

还有个细节深得我心：snapshot -i -a -o page.png 一条命令，截图上直接标注每个 ref 的位置。结构化数据和视觉对照同时到手，AI 的犯错率直线下降。

五件里我最终选了它，第九章细说。不适合谁也很明显：不在终端里干活的人。

六、Web Access · 只有眼睛，没有手

能读网页，但不能点网页——它是情报员，不是测试员。

说的是 AI 内置的网页访问能力：Claude Code 的 WebFetch/WebSearch、ChatGPT 的浏览功能、各家"联网搜索"。

把它放进清单，是因为这是最常见的误判：很多人以为 AI"能上网"就等于"能做 Web 测试"。不能。第二章说过，它压根没有浏览器——只是个 HTTP 客户端，抓回来的 HTML 是静态的：看到登录页，点不了登录按钮；看到表单，提交不了。

它连的不是浏览器，是服务器。

做资料调研、读接口文档，它零配置、足够快；需要交互的场景，别找它。能读 ≠ 能测，记住这条，少走一个月弯路。

七、browser-use · 全自主的"外包测试员"

你下自然语言指令，它自己规划、自己点、自己纠错，全程不用你插手。

Python 开源库，GitHub 6 万多 star。底层早期架在 Playwright 上，0.7 之后换成自研的 cdp-use 直连 CDP——但它的特别之处从来不在底层，在最顶层：一个"观察 → 决策 → 行动"的 LLM 循环。

from browser_use import Agentagent = Agent(    task="登录后台，创建一篇文章，验证它出现在列表页",    llm=llm,)await agent.run()

前面四件是"AI 的遥控手"，它是"自带大脑的机器人"：任务说给它听，它自己拆步骤、操作浏览器、走错了退回来重试。还有云端版本，本地连浏览器都不用装。

硬币的另一面：自主性是有代价的。同一个任务，它每次走的路径未必相同。对"验收外包"这是优点，对"每步确定可控"的回归测试这是缺点——看你的场景属于哪种。

八、五件兵器，一张表说清

别急着选，先横向看一眼：

我的选择路径：

• 只是查资料、读文档 → Web Access，别折腾
• 想让 AI 顺手点点页面 → Playwright MCP
• 还要查性能、抓网络、过登录墙 → Chrome DevTools MCP
• 想把验收任务整个外包 → browser-use
• 在终端里做正经的、可复现的 E2E 测试 → agent-browser

九、我的实战：一个技能，顶替整个 QA 流程

选工具只是第一步。工具是手，流程才是脑。

用 agent-browser 测了几个月之后，我把踩过的坑沉淀成了一个 Claude Code 技能：e2e-test。现在我的日常是：功能写完，敲一句 /e2e-test，去接杯水，回来拿报告。

只讲要点，四个。

1. 先探测，不假设。 技能启动先做技术栈探测：go.mod 是 Go、pyproject.toml 是 Python、路由目录在哪、前后端端口多少、连的是 MySQL 还是 SQLite——全部从 marker 文件和真实配置里读出来，填成一张环境表。技术栈无关不是口号，是探测出来的。

2. 像用户一样测，不看源码。 测试阶段的铁律是只操作浏览器：snapshot 拿 ref、click/fill 走旅程、screenshot 留证。每条用户旅程一个任务。UI 上点完还不算完——要连数据库验证：刚才创建的文章，表里真的有了吗？字段和输入一致吗？这一步抓到过最典型的 bug：UI 提示"创建成功"，数据库里却是空的。UI 说成功不算成功，数据库点头才算。

3. 发现即修，一个 bug 一个 commit。 发现 bug 按严重度分级，critical 和 high 当场修：定位源码、最小修复、单独 commit、重新截图验证，然后补一个回归测试——断言"返回正确值"，而不是"不崩溃"。同一个 bug 修 3 次还失败，停下来质疑架构，不试第 4 次。

4. 报告结案，分数说话。 跑完出一份 QA 报告：发现几个问题、修了几个、推迟几个，外加一个 before → after 的健康分。所有截图按旅程归档，每张都是证据。

截图是证据，不是仪式感。

看不到截图的验证，等于没验证。

这套流程最反直觉的一点是：测试的价值不在"跑"，在"修"。 发现问题谁都会，难的是修完验证、补上回归、留下证据——一次 /e2e-test 跑完，bug 修了，回归测试也进了仓库，下次发版它替你站岗。

十、把浏览器交给 AI

回到开头的问题。

你是不是还在人肉回归？还在维护那堆一碰就碎的脚本？

答案一句话：给 AI 配一双手，再给它一套流程。 手，从五件兵器里按场景挑；流程，如果你用 Claude Code，e2e-test 这条路我已经蹚出来了。

两年前，"AI 测试"的意思是 AI 帮你写脚本。今天，它的意思是 AI 自己打开浏览器、点完所有流程、修好 bug、留下证据。

会点按钮的 AI，才算会做测试。

这个周末，花 15 分钟：npm i -g agent-browser，对你正在做的项目跑一次 snapshot -i，让 AI 点完你的主流程——登录、创建、提交。你会第一次真切地感到：浏览器这双手，AI 已经长出来了。

如果你也有一个"每次发版前都要人肉点一遍"的项目，把这篇文章转给那个还在手动回归的同事。

评论区聊聊：你的测试流程里，哪一步最想让 AI 接手？