Playwright MCP 页面捕获：Snapshot、截图、HTML 到底选哪个？

🚀 省流助手（速通结论）

Accessibility Snapshot 是语义地图，截图是照片，HTML 是设计图纸------三者看到的世界完全不同。

Snapshot 告诉你"页面能交互什么"，截图告诉你"页面长什么样"，HTML 告诉你"源码写了什么"，而绝大多数自动化场景只需要第一个答案。

默认用 Snapshot 作主力交互定位，token 成本极低、ref 定位稳定、自动过滤不可见元素；只在分析视觉风格时补一张截图，研究组件实现时才掏 HTML。

格局建议：不要再用"截图+坐标"这种给人看的思路驱动 AI agent。理解页面的可访问性结构，让 AI 用"母语"阅读交互，才是 Playwright MCP 自动化的第一性原理。

一个问题引出三种答案

你用 Playwright MCP 让 AI 分析一个登录页面。它有三种方式"看"这个页面：

browser_snapshot --- Accessibility Snapshot
browser_take_screenshot --- 截图
browser_evaluate("document.body.innerHTML") --- HTML

三者都能拿到页面信息，但内容完全不同。用错了，要么浪费 token，要么分析结果差之千里。

这篇文章用一个登录表单把三种方式掰开讲透。

同一个页面，三种方式各看到什么

假设页面上有一个简单的登录表单：

html 复制代码

<form class="login-form" style="border-radius: 8px; background: #fff;">
  <input type="email" placeholder="请输入邮箱" class="ant-input" />
  <input type="password" placeholder="请输入密码" class="ant-input" />
  <button class="login-btn" style="background: #1677ff; border-radius: 6px;">
    登 录
  </button>
  <span class="error-tip" style="display: none;">邮箱格式不正确</span>
</form>

HTML 看到了什么

ini 复制代码

<input type="email" placeholder="请输入邮箱" class="ant-input" />
<input type="password" placeholder="请输入密码" class="ant-input" />
<button class="login-btn">登 录</button>
<span class="error-tip" style="display: none;">邮箱格式不正确</span>

看到了 DOM 结构、class 名、属性。但你看不到：

这个按钮实际渲染出来是蓝底白字还是灰的？
那个隐藏的错误提示现在到底有没有显示？
这个表单在页面上是居中还是靠左？

HTML 告诉你"页面声称有什么"，不是"用户实际看到什么"。

截图看到了什么

看到的内容：蓝底按钮、圆角、白色表单容器、输入框的边框、字体大小、间距比例。

看不到的内容：按钮的"登录"文本对 AI 来说需要 OCR 和视觉理解来提取，不够精确；隐藏的错误提示完全不可见；元素的语义角色（这是个 button 还是个可点击的 div？）全靠视觉推断。

截图告诉你"页面长什么样"，不是"页面能做什么"。

Accessibility Snapshot 看到了什么

csharp 复制代码

- textbox "邮箱" [ref=f1]
- textbox "密码" [ref=f2]
- button "登 录" [ref=f3]

看到了：元素角色（button / textbox）、可访问名称（"登录"）、层级关系、唯一引用 ID（ref=f3）。

而且那个 display: none 的 <span>------不会出现在 snapshot 里。因为它不可访问。

Snapshot 告诉你"页面当前能交互什么"，既不是长得像什么，也不是源码写的是什么。

一张表彻底理清

	Accessibility Snapshot	截图	HTML
本质	语义结构树	像素渲染结果	原始标记文本
能看到	元素角色、名称、状态、层级	视觉外观：颜色/布局/间距/字体	DOM 结构、属性、CSS 类名
看不到	视觉样式、非语义装饰元素	隐藏元素、语义角色、交互状态	渲染结果、JS 动态插入的内容、CSS 效果
AI 处理	结构化文本，直接定位交互	需要视觉模型，x/y 坐标不稳定	需解析 DOM，且可能是过时或残缺的
Token 成本	极低	高（截图 1-3K tokens/张）	中等（整页 HTML 可能上万字符）

三个坑

坑一：HTML 不等于用户看到的页面

SPA 动态渲染、AJAX 回填、懒加载组件------HTML 源码里可能什么都没有。你抓到的 .innerHTML 是一个"当前快照"，但：

CSS display: none 隐藏的元素在 HTML 里完好无损，你分不清哪些元素真的可见
动态弹窗、Toast、通知可能挂在 <body> 末尾，跟源码的结构风马牛不相及
::before/::after 伪元素在 HTML 里完全不存在

HTML 是源码的视角，Snapshot 是用户的视角。用 HTML 判断交互逻辑会误判。

坑二：过度依赖截图

截图看起来"直观"，但对 AI agent 来说：

需要额外的视觉模型来理解
同样的页面截图两次，像素级差异可能巨大（动画、时间戳、随机验证码）
按钮改个颜色就要重新截图，用 snapshot 的话 ref ID 稳定不变
Viewport 不同导致布局变化，原本的坐标直接失效

截图适合给人看，Snapshot 适合给 AI 用。

坑三：不是所有页面都有好的无障碍树

一些页面（Canvas 渲染的游戏、WebGL 图表、某些 CSS 艺术页面）的无障碍树可能是空的或残缺的。这时候 Snapshot 退化为"几乎无用"，截图和 HTML 成为备选。好在大多数业务页面（表单、列表、仪表盘）的无障碍树都很完整。

最后

Playwright MCP 的 browser_snapshot 不是你想象的"另一个截图工具"。它是一个全新的范式：AI 不像人一样需要"看见"页面，它需要"理解"页面的交互结构。

下一次你在写 Playwright MCP 的捕获脚本时，先问自己：我是想让人看这个结果，还是想让 AI 基于这个结果做决策？

答案是后者的话，Snapshot 几乎总是正确答案。