背景

内部有套系统只提供页面，没有 API：待办清单、审批、发布记录，全靠人点。每天重复的点击累积起来很可观，于是想把它交给自动化。

一开始写的是传统脚本：Playwright + 固定选择器。跑了两周，问题很集中——页面一改版，page.click('#submit-btn') 就全部失效，维护成本比手点还高。

后来换成 Playwright MCP：不再硬编码选择器，而是让模型读页面的可访问性快照，自己判断「点哪个」。

环境准备

MCP 的注册只有几行配置，写在 mcp.json 的 mcpServers 下面：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

写完之后不会自动生效，需要在客户端的连接器管理里手动「信任」一次。

三个真正省时间的点

1. 会话可以复用

浏览器配置目录持久化之后，登录态就留在里面了。第一次登录，后面几次直接进后台——页面上能看到「我的博客」「退出登录」这些入口，说明会话还在。

这一步的意义比看起来大：省掉的不只是敲密码，而是验证码、二次确认那一整串等待。

2. 定位用 ref，不用 CSS

MCP 给出的元素引用（ref）是从当前快照里生成的一次性编号：

textbox "标题" [ref=f2e132]
button "编辑器: Markdown" [ref=f2e874]

先取快照、再按 ref 操作，元素即使换了 class、换了层级，只要它在语义上还在那儿，就还能被找到。这和「选择器考古」完全是两种工作方式。

3. 一次填多个字段

表单类操作可以一次提交多个字段，减少来回往返；而像「切换编辑器」这种需要先点开下拉、拿到菜单项 ref、再点的交互，模型也能自己走完。

踩过的坑

• iframe 里的富文本编辑器：快照只到 iframe 一层，里面是空的。要么切到 Markdown 编辑器（纯 textarea，最好处理），要么用代码片段进 frame 内部操作。
• 前端框架的渲染时序：单页应用刚打开时快照可能是半成品，等一拍再取才完整。
• 下拉菜单要先展开：菜单项在展开前根本不在快照里，不存在「提前把 ref 记下来」这回事。
• 截图和快照分工不同：截图给人看，快照给模型用。拿截图去推元素位置，是给自己找麻烦。

纪律比技巧重要

自动化能碰到的都是真实账号和真实数据，所以给自己定了几条：

1. 只读操作随便跑，写操作（提交、发布、发送）必须明确授权；
2. 发布、发信这类外部动作，先看结果再确认，不静默执行；
3. AI 参与生成的内容，按平台要求如实声明。

小结

Playwright MCP 并没有让浏览器自动化变简单，它改变的是「谁来应对变化」：以前是写脚本的人不断改选择器，现在是模型每次看一遍页面重新判断。

真正需要人管的，从「元素怎么写」变成了「允许它做什么」。后一件事，其实更该由人盯着。

文章摘自：https://www.cnblogs.com/jichengwei/p/22937897