AI 改完页面别急着收工，Playwright MCP 能让它打开网页接着查

AI 写完登录页，回复“已完成”。可真正打开页面才发现，错误提示挡住按钮，或者提交后根本没有跳转。代码能编译，与用户能顺利走完流程，中间还隔着一次浏览器检查。

微软维护的 Playwright MCP 把浏览器操作提供给支持 MCP 的助手。它的价值不是再生成一份页面代码，而是让助手能打开实际页面、读取控件结构、执行交互，再根据页面反馈继续排查。

它看到的是按钮和输入框

项目的主要工作方式是结构化可访问性快照。与每一步都根据截图猜坐标不同，模型可以看到页面上哪些内容是链接、按钮或输入框，再针对对应元素操作。官方说明因此不要求必须使用视觉模型。

例如检查一个中文资料列表：输入关键词，提交搜索，打开结果，再确认返回后筛选条件是否仍在。这是教学情境，未在本文执行。对这类任务，有用的观察不是“页面看着还行”，而是结果列表是否变化、当前筛选是否明确、链接去了哪里。

如果页面把所有控件都做成没有名称的通用容器，结构快照能够提供的信息也会变差。给按钮清楚的标签、使用恰当的语义元素，既帮助读屏用户，也让自动化工具更容易判断页面关系。

MCP 可以理解为客户端与工具之间的一种连接约定。Playwright MCP 负责暴露浏览器能力，决定下一步做什么的仍是你使用的模型与助手。它本身不会附送模型，也不会自动知道产品应该怎样交互。

官方列出多种客户端配置方式，基本要求包括 Node.js 18 或更新版本和一个 MCP 客户端。开始时按自己客户端对应的说明连接，再让它检查本地开发页面即可。无需为了“接浏览器”先把整套业务迁到新平台。

浏览器状态也需要区分：一个空白的隔离会话，与接入已有登录状态，并不是同一种权限范围。检查公开页面可以从干净会话开始；要使用业务账户时，先确认工具会接到哪个会话、页面操作会产生什么后果。不能把本地服务可连接理解成所有后台都已获授权。

结构化信息适合确认按钮可点、输入能提交、状态会改变；封面是否裁坏、中文标题换行是否别扭、手机上的留白是否合理，仍需要看实际画面。一次成功点击不能证明页面有设计感，同样，一张漂亮截图也不能证明表单能用。

实际采用时，可以把两种检查放在同一个任务里：先按用户路径验证，再看桌面与手机画面。失败时保留具体触发步骤和页面反馈，才能让下一次修改有明确目标。

还有一个值得注意的新提示：官方 README并未把 MCP 当成所有编码场景的唯一选择，而是建议部分编码代理考虑 Playwright CLI 与 Skills，以减少工具结构和页面树占用的上下文。需要持续浏览器状态、细看页面结构时，MCP 仍有其位置。

如果你的助手总在“代码改好了”就停下，这个项目提供了一条把实际网页接回来的路。本文介绍官方接口与采用条件，没有执行浏览器测试，不把接入能力写成已经替任何页面完成验收。