你有没有遇到这两种情况: 自己写的 Playwright 脚本跑不通,不知道哪里出问题,只能反复改反复猜 每次靠 AI 完成一个操作,用完就没了,下次还得重新来一遍 这两个问题,playwright-cli 都解决了。

微软最近在 GitHub 上低调发布了playwright-cli,目前已有 9000+ stars。

核心能力只有一句话:让 AI 接管你的浏览器,边看真实页面边帮你调代码,调完直接生成可独立运行的 Python 脚本

用一次,沉淀一个脚本,之后定时跑、服务器跑、断网跑,完全不依赖 AI 环境。

这是很多人没想清楚的区别:AI 负责探索和生产脚本,不参与后续运行

具体来说,它能帮你做这些事:

场景

以前怎么做

现在怎么做

自己写的脚本有 bug

加 print、猜原因、反复改跑

AI 盯着真实浏览器帮你实时定位

想固化一套操作流程

学 Playwright API、自己写

AI 探索完直接生成 .py 脚本

每天手动下载报表

一步步点,重复操作

脚本跑一下,自动完成

按钮点了没反应

看 F12、猜事件绑定

AI 直接扒出前端逻辑

政务系统全是 iframe

定位失败、脚本报错

AI 自动识别 iframe 结构

生成的脚本是标准 Python 文件,不依赖任何 AI 服务,放服务器上定时跑没有任何问题。

这跟以前的浏览器自动化有什么不一样?

浏览器自动化不是新鲜事。Selenium、Playwright、RPA 工具……大家可能都听说过。但这些工具有一个共同的门槛:你得写代码

playwright-cli 的思路完全不同。

它把 Playwright 的能力封装成一个个简洁的命令行指令,AI 助手可以直接调用这些指令来操控浏览器。你只需要用自然语言告诉 AI 你的目标,剩下的交给它。

举个例子,你想测试一个待办事项网站,只需要告诉 AI:

"用 playwright-cli 测试一下 https://demo.playwright.dev/todomvc/ 这个网站,截图保存所有成功和失败的场景。"

AI 会自己执行一系列命令:

playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli type"Buy groceries"
playwright-cli press Enter
playwright-cli check e21
playwright-cli screenshot

整个过程你不需要写任何代码。

为什么 CLI 比 MCP 更受编程代理青睐?

这里有个值得关注的技术趋势。

目前 AI 操控浏览器有两种主流方式:MCP(模型上下文协议)和 CLI(命令行)。微软在文档里明确解释了两者的区别:

CLI 的优势在于"省 Token"。

MCP 每次调用工具,都需要把大量的工具描述、页面可访问性树等信息塞入模型上下文,消耗大量 Token。而 CLI 命令简洁,AI 只需要知道命令本身,避免了冗余信息的加载。

对于需要同时处理大型代码库 + 浏览器操作的编程代理来说,Token 窗口就是生命线,CLI 方式明显更实用。

MCP 则适合"深度探索"。当你需要 AI 持续盯着一个页面、反复调整策略、做复杂的自主推理时,MCP 的持久状态更有优势。

简单说:CLI 是高效执行,MCP 是深度分析。两者不是替代关系,而是互补。

五个真实场景,感受一下场景一:每天下载报表太烦人

很多企业系统的数据导出需要登录、点几个菜单、选条件、导出……每天重复。

现在你只需要:

  1. 启动带调试端口的浏览器(一次性配置)

  2. 告诉 AI:"帮我把 XX 系统里本月的销售报表导出来"

  3. AI 接管浏览器,自动完成所有步骤

场景二:按钮点了没反应,排查半天

有没有遇到过点击"导出"按钮没有任何反应,也不报错?

用 playwright-cli 可以让 AI 直接扒出按钮背后绑定了什么 JavaScript 逻辑:

// 检查按钮是否有时间限制
jQuery._data(document.getElementById('export'), 'events')

某位用户就是这样发现了一个政务系统的隐藏限制:导出按钮只在工作时间生效,前端直接写死了时间校验,从不告诉用户原因。

场景三:下载文件捕获不到

Python Playwright 脚本里用expect_download却捕获不到通过form.submit触发的下载?

AI 可以直接用 CDP 协议绕过:

const cdp = await page.context.newCDPSession(page);
cdp.send('Browser.setDownloadBehavior', {
behavior: 'allow',
downloadPath: 'D:\\Downloads',
});

告诉 AI 你的问题,它会帮你找到解法并直接改好代码。

场景四:政务/企业系统满是 iframe

这类系统几乎全是 iframe 嵌套,普通自动化脚本经常定位不到元素。

AI 会自动识别 iframe 结构,选择正确的进入方式:

const frame = page.frames.find(f => f.name === 'mainframe');
await frame.evaluate( => { /* 在 iframe 内直接执行操作 */ });
场景五:自己写的 Playwright 代码跑不通
打开网易新闻 查看精彩图片

很多人学了 Playwright 之后自己写脚本,结果运行起来各种问题:元素定位失败、点击没有效果、下载捕获不到……

传统调试方式是:加print、看报错、对着文档猜、改了再跑……循环往复。

现在换一种玩法:让 AI 边看着真实浏览器,边帮你改代码

你只需要:

我有一个 Playwright 脚本 D:\...\export.py,
运行后点击"导出"按钮没有触发下载,
浏览器已经打开在 localhost:9222,帮我排查

AI 会:

  1. 读你的代码,理解下载逻辑

  2. 接管浏览器,实时看页面状态

  3. 检查按钮的事件绑定,看网络请求有没有发出去

  4. 直接定位问题,修改代码,保存

全程你不需要自己打一行调试代码,也不需要重复"改→跑→报错→再改"的循环。

场景六:探索完成后,固化成独立脚本

这是 playwright-cli 最容易被忽略的价值:它是探索工具,不是运行环境

很多人以为用了 AI + playwright-cli 就永远依赖 AI 才能运行。其实完全不是这样。

正确的工作流是:

第一阶段(一次性):AI + playwright-cli 探索
→ AI 接管浏览器,找元素、测操作、排查问题
→ 确认操作路径完全可行

第二阶段(固化):AI 生成 Python 脚本
→ 把刚才的操作流程写成标准 .py 文件
→ 保存到你的项目目录

第三阶段(后续):直接运行 .py,完全脱离 AI
python export.py
→ 定时任务、批处理、CI/CD 全都支持
→ 不需要 Claude,不需要网络,不需要任何大模型环境

你可以告诉 AI:

刚才的操作流程已经验证可行了,帮我把它整理成一个标准的
Python Playwright 脚本,保存到 D:\scripts\export.py,
要支持命令行传参(开始日期、结束日期)

AI 生成的脚本可以直接丢到服务器上跑定时任务, 和普通 Python 脚本没有任何区别——AI 只参与了生产这个脚本的过程,不参与运行

这解决了很多人对"AI 自动化"的顾虑:企业环境、内网服务器、断网场景,都没有问题。

场景七:接口有前端限制但后端没有

发现某个导出功能在前端做了权限限制,但后端接口其实可以直接调用?AI 可以帮你分析请求,用fetch绕过前端直接拿数据(生成好后同样可以固化成脚本):

const resp = await fetch('/api/exportData', {
method: 'POST',
credentials: 'include', // 带上登录态
body: formData
});
怎么开始用?

第一步:安装

npm install -g @playwright/cli@latest

需要 Node.js 18 或更高版本。

第二步:安装 Skills(让 AI 助手学会使用它)

playwright-cli install --skills

这一步会把操作指南安装到本地,Claude Code、GitHub Copilot 等助手会自动读取并学会使用。

第三步:启动浏览器时加上调试端口

# Chrome/Edge 启动时加上这个参数
--remote-debugging-port=9222

之后 AI 就可以通过这个端口接管你的浏览器。

第四步:告诉 AI 你要干什么

我的浏览器已经在 localhost:9222 运行了,已经登录了 XX 系统,
帮我把本月的数据导出到 Excel

剩下的事交给 AI。

一些实用的命令速查

如果你偶尔想手动操作,这些命令够用了:

# 打开网页
playwright-cli open https://example.com --headed

# 看页面结构(AI 最常用的命令)
playwright-cli snapshot

# 点击元素
playwright-cli click e15

# 填写表单
playwright-cli fill e5 "要输入的内容"

# 截图
playwright-cli screenshot --filename=result.png

# 接管已有浏览器
playwright-cli attach --cdp=http://localhost:9222

# 保存登录状态
playwright-cli state-save my-session
playwright-cli state-load my-session # 下次直接恢复,不用重新登录
关于安全和边界

有人会问:这样让 AI 操控浏览器,安不安全?

几个注意点:

  1. AI 不会主动乱操作。设计良好的提示词会让 AI 先告诉你要做什么,确认后再执行。

  2. 调试端口只在本地暴露localhost:9222只有本机能访问,不会对外开放。

  3. 敏感操作建议逐步确认。可以告诉 AI:"每一步先说明你要做什么,我确认后再执行"。

  4. 会话相互隔离。不同的会话(-s=name)使用独立的浏览器实例,互不干扰。

浏览器自动化并不是什么新技术,但 playwright-cli 的出现,让它第一次真正对非程序员变得友好。

核心变化只有一个:以前你要学工具,现在工具来适应你

你只需要用自然语言描述目标,AI 负责翻译成具体操作。那些需要"先学 Selenium"、"先学 XPath"、"先搞懂异步等待"的门槛,统统消失了。

更重要的是,它提供了一条从探索到固化的完整路径:

  • 遇到新需求?让 AI 接管浏览器探索,边试边确认

  • 自己的脚本有 bug?让 AI 盯着真实浏览器帮你调

  • 路径确认后?让 AI 生成标准 .py 脚本,之后完全脱离 AI 独立运行

最终跑在服务器上的,是一个普通的 Python 脚本,没有大模型依赖,没有网络要求,没有额外的运行环境。AI 只出现在"生产脚本"这一步,不参与后续运行。

如果你日常已经在用 Claude Code、GitHub Copilot 这类工具,playwright-cli 是一个值得立刻安装的扩展能力。

相关资源

  • playwright-cli GitHub 仓库:github.com/microsoft/playwright-cli

  • Playwright 官方文档:playwright.dev

  • 当前版本:v0.1.8(2026年4月)

如果你有具体的自动化需求想聊,欢迎留言。