前言
最近在做企业内网系统的自动化测试，顺带处理一些个人的批量操作任务。Windows 环境，流程固定，没有什么动态决策的需求。
我以为随便找个浏览器自动化方案就能搞定，结果接连踩了三个坑，兜兜转转才发现 playwright-cli 才是这个场景下最顺手的工具。
写这篇文章的目的很简单：如果你的需求和我类似，希望帮你少走弯路。
一、踩坑对比：我试过的三个方案
在找到 playwright-cli 之前，我试过市面上几乎所有主流方案，每一个都让我以各种姿势摔跤。
坑 1：browser-use —— 每次操作都在烧钱
browser-use 是基于 Python 的 AI 浏览器框架，思路很好：用大模型理解页面、自动决策点哪里。但问题在于，每一个页面交互都要调用 LLM，截图 → 发给模型 → 模型返回操作 → 执行 → 再截图……一个登录流程下来，token 就没了一大块。
在企业内网测试场景下，流程固定、步骤明确，根本不需要模型"思考"，纯粹是在烧冤枉钱。
坑 2：Agent Browser / Skyvern —— Windows 兼容性是噩梦
Agent Browser 类方案在 macOS/Linux 上表现尚可，但一到 Windows 就各种问题：依赖装不全、路径转义报错、WSL 里能跑主机里不行……折腾了半天环境，还没开始干正事。
企业环境大多数机器是 Windows，这条路基本堵死了。
坑 3：Playwright MCP（官方）—— 不是为脚本化设计的
官方 Playwright MCP 是给 AI Agent 调用的，适合"让 Claude/GPT 帮你操浏览器"的场景。但如果你想写一个固定流程的 sh 脚本、定时跑、零人工干预，它就显得笨重了——要起 MCP server，要 AI 在中间，根本不是这个用法。
二、playwright-cli 是什么
@playwright/cli 是微软 Playwright 团队出的一个独立 CLI 工具，可以把 Playwright 的核心浏览器操作直接在命令行里敲，无需写 JS 代码：
npm install -g @playwright/cli@latest
核心能力一览：
| 命令 | 作用 |
|---|---|
playwright-cli open | 打开浏览器（支持 headed/headless） |
playwright-cli goto <url> | 导航到 URL |
playwright-cli fill <selector> <value> | 填写表单 |
playwright-cli click <selector> | 点击元素 |
playwright-cli screenshot | 截图 |
playwright-cli snapshot | 抓取页面快照（含元素结构） |
三、两个核心设计：为什么它适合固定流程自动化
3.1 --profile —— 继承登录态，再也不用重复登录
这是我认为最被低估的一个参数。
playwright-cli open --browser=chrome --profile=./.pw-profile --headed
.pw-profile 是一个持久化的浏览器配置目录，Cookie、LocalStorage、Session 全部保留。你第一次手动登录之后，后续每次脚本运行直接继承登录态，不需要再填用户名密码。
对于企业内网系统来说，这意味着：
- 不需要在脚本里明文写密码（安全）
- 不需要处理验证码、MFA 等登录干扰
- 脚本更短、更专注于业务流程本身
把
.pw-profile加入.gitignore，不要提交到仓库。
3.2 输出 .sh 脚本 —— 零 token 运行
这是和 browser-use 最本质的区别。
playwright-cli 的操作是命令行指令，可以直接写成 bash/sh 脚本：
#!/bin/bash
playwright-cli open --browser=chrome --profile=./.pw-profile --headed
playwright-cli goto https://your-app.com/dashboard
playwright-cli click e38
playwright-cli screenshot --filename=./doc/result.png
保存为 run.sh，chmod +x run.sh，之后每次直接 ./run.sh 执行。
整个过程：零 API 调用，零 token 消耗。
如果你用 AI（比如 Claude）来生成这个 sh 脚本，token 只在"写脚本"这一步花一次，之后脚本可以无限次复用。这才是正确的成本控制姿势。
四、标准操作流程
Step 1：首次启动，手动登录
playwright-cli open --browser=chrome --profile=./.pw-profile --headed
playwright-cli goto https://your-app.com
# 此时浏览器窗口打开，手动输入账号密码登录
# 登录成功后，用 snapshot 确认页面状态
playwright-cli snapshot --depth=3
Step 2：用 snapshot 获取元素 ID
snapshot 会输出页面的可交互元素列表，类似这样：
e20: input[name="username"] - 用户名输入框
e25: input[name="password"] - 密码输入框
e32: button[type="submit"] - 登录按钮
这些 eXX 就是后续 click/fill 的 selector。
Step 3：固化为 sh 脚本
#!/bin/bash
# 复用已登录的 profile，无需再次登录
playwright-cli open --browser=chrome --profile=./.pw-profile --headed
playwright-cli resize 1920 1080
playwright-cli goto http://your-app.com/dashboard
playwright-cli screenshot --filename=./doc/01-dashboard.png
# 导航各模块
playwright-cli click e38
playwright-cli screenshot --filename=./doc/02-develop.png
playwright-cli click e39
playwright-cli screenshot --filename=./doc/03-controlled.png
echo "=== 完成 ==="
五、和其他方案对比
| playwright-cli | browser-use | Playwright MCP | Selenium | |
|---|---|---|---|---|
| Windows 兼容 | ✅ 好 | ⚠️ 一般 | ✅ 好 | ✅ 好 |
| token 消耗 | ✅ 零 | ❌ 每步调用 LLM | ❌ 需要 AI 驱动 | ✅ 零 |
| 登录态复用 | ✅ --profile | ⚠️ 需手动处理 | ⚠️ 需手动处理 | ⚠️ 需手动处理 |
| 适合固定流程 | ✅ 最佳 | ❌ 杀鸡用牛刀 | ❌ 设计目标不同 | ✅ 可以 |
| 上手难度 | ✅ 低（CLI） | ⚠️ 中（Python） | ⚠️ 中（MCP配置） | ❌ 高（代码量大） |
结论：流程固定 → playwright-cli；需要 AI 动态决策 → browser-use 或 MCP。
六、常见问题
Q：元素 ID（e38）每次运行会变吗？
A：会。snapshot 的编号是动态生成的，建议在脚本里加一步 snapshot，确认编号后再固化操作。或者用更稳定的 CSS selector 替代。
Q：headless 模式可以用吗？
A：可以，去掉 --headed 参数即可。CI/CD 环境推荐 headless。
Q：profile 目录可以多人共享吗？
A：不推荐。每个人的登录态不同，建议各自维护自己的 .pw-profile。
七、总结
如果你的场景是流程固定的自动化测试或批量操作，playwright-cli 是目前我用过最顺手的方案：
- 🪶 轻量，npm 一行装好，无额外依赖
- 🪟 Windows 友好，企业环境无障碍
- 💰 零 token，sh 脚本写一次无限复用
- 🔐
--profile继承登录态，安全且省事
AI 负责生成脚本，playwright-cli 负责执行脚本——各司其职，才是正确的人机协作姿势。
我是海潮，专注前端/全栈技术分享，深耕前端工程化领域 5 年，关注我，一起成长、少踩坑 ✨。
