企业官网建设流程全解析

做浏览器自动化这块快十年了，从PhantomJS到Selenium再到Puppeteer，每个阶段都有让人眼前一亮的东西。但说句实话，以前写自动化脚本，最磨人的不是框架本身，而是“页面一改版，选择器全失效，脚本得重写”。 Playwright 出来后，这类体验好了不少，但依然需要人去手动写代码、调逻辑、处理各种异常。

直到我把 Playwright 和 MCP 接上之后，这个局面才真正被打破。MCP全称 Model Context Protocol，它让 AI 不只能生成代码，还能直接握住浏览器这个“方向盘”，屏幕上发生了什么，AI看得见、也操作得了。你只需要说一句“帮我打开某某网站，找到某某信息，整理成表格”，AI就会自己导航、点击、提取、截图，整个过程像有个远程操作员坐在电脑前干活。

这也是我写这篇实战指南的初衷。我会先用大白话讲清楚 MCP 和 Playwright MCP 到底是什么、解决了什么问题；再带你一步步装环境、配置到常用客户端里；然后拆解它最核心的十几个工具能力，最后用一个完整的实战案例，演示怎么用自然语言指挥 AI 操作浏览器完成数据收集任务。无论你是做自动化测试的、搞数据采集的，还是想给 AI Agent 加上“眼睛和手”的应用开发者，这篇内容都能给你一条可以照抄的落地路径。

1. 认识Playwright MCP：AI与浏览器之间的一座桥

1.1 MCP协议到底是个啥：一个USB-C的类比

首先把MCP讲清楚。Model Context Protocol，模型上下文协议，是Anthropic在2024年底开源的一套标准协议，目的就一个：给 AI 模型和外部工具之间定义一套统一的调用规范。

你可以把它想象成USB-C接口。在USB-C统一之前，每个设备一个充电口，手机、耳机、相机各带各的线，出门得背一团。AI工具链之前也是这个状态：这个Agent只认自家的插件格式，那个Agent用另一套工具调用协议，换个平台就得重新适配。MCP试图终结这种混乱，它定义了三类角色：

• MCP Host：运行AI模型的载体，比如Claude Desktop、Cursor、Claude Code，负责接收用户指令、调度模型。
• MCP Server：提供具体能力的服务端，比如Playwright MCP就是专门提供浏览器控制能力的服务端。一个Server可以暴露多个工具给模型调用。
• MCP Client：Host和服务端之间的连接器，负责协议层面的通信。

过去的一年里，MCP生态发展得非常快。从Figma到MySQL，从设计协同到数据库查询，各类MCP Server层出不穷，几乎你能想到的工具链都有人在接。浏览器自动化这块，微软官方直接下场做了Playwright MCP，把整个Playwright的能力打包成一个MCP Server，模型按需调用它的工具就能操作真实浏览器。这个项目的仓库就叫microsoft/playwright-mcp，目前社区热度非常高，相关热搜词里那些“dify使用的浏览器自动化工具”“chrome mcp server”背后，十有八九都指向同一个解决方案。

1.2 从“写代码”到“直接干活”：Playwright MCP带来的改变

以前用Playwright写自动化，流程大概是：打开编辑器，写一个脚本，启动浏览器，跑一遍，报错了，打开DevTools看元素，改选择器，再跑一遍。这个循环里最耗时间的不是写代码，而是“观察-修正”的过程。

MCP把这一段的体验彻底改了。AI不再只是“负责生成代码”的旁观者，它变成了“亲手操作页面”的执行者。举个最直观的例子：

传统Playwright脚本：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto("https://example.com") page.click("text=登录") page.fill("#username", "test") page.fill("#password", "123456") page.click("button:has-text('提交')") page.wait_for_selector(".result") print(page.inner_text(".result")) browser.close()

这套流程要求开发者在编写前就得知道页面大概有哪些按钮、哪些输入框，选错了就得调试半天。页面结构一变，脚本基本等于作废。

通过Playwright MCP操作时，你只需要给AI一句任务描述：打开某网站，输入账号和密码点击登录，把登录后的首页数据提取出来。AI会自己去调用导航工具打开页面，用快照工具看页面当前的DOM快照，找输入框的可用选择器，用输入工具填文本，用点击工具按按钮，登录后再抓取目标内容。整个过程中的每一步，AI都能看到结果并动态调整下一步动作。换句话说，AI从“写代码的人”变成了“用工具干活的人”。

核心差别在于闭环反馈。传统脚本是人写、机器跑、人看结果再改；MCP模式下是AI计划、AI执行、AI观察结果、AI自我修正，人只负责定义目标和验收标准。下面这张表把两种方式的对比整理得更直白。

2. 环境准备与MCP Server安装

2.1 装之前需要准备的东西

开始操作之前，先把依赖理清楚。Playwright MCP不是一个独立的桌面应用，它本质上是运行在Node.js环境里的一个服务进程，需要客户端把它拉起来。所以环境和依赖包含三层：

• Node.js 18.0以上。底层靠它运行npx指令，版本太低会直接报错，推荐装最新的LTS版本。
• 浏览器内核。Playwright运行时会下载Chromium、Firefox、WebKit，首次启动的时候如果没有，MCP Server会提醒你执行安装命令。
• 任意一款MCP客户端。目前比较常见的包括Claude Desktop、Claude Code、Cursor、Codex，下面会演示前两种的配置方法。

这里解释一下为什么特别强调浏览器内核要单独装。Playwright的设计理念是“自带浏览器”，它不直接用你系统里那个Chrome，而是下载独立的Chromium构建，保证测试环境一致。这也意味着它的下载包体积不小。第一次拉MCP Server的时候如果没有全局装过Playwright，会自动触发浏览器下载；如果卡住或者失败，就需要手动跑一条命令：npx playwright install chromium。看到“Executable doesn't exist”这类字样时，基本就是这一步没到位。

2.2 在Claude Desktop里配置（两种方式）

Claude Desktop是体验MCP最省事的方式，因为它自带MCP客户端，不需要装额外插件。配置文件在：

• macOS：~/Library/Application Support/Claude/claude_desktop_config.json
• Windows：%APPDATA%\Claude\claude_desktop_config.json

编辑这个文件，加入以下内容：

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

保存后重启Claude Desktop，在界面右下角应该能看到一个插头图标，点开后如果列表里出现playwright，就说明连接成功。第一次点开会触发npx下载包，稍微等一两分钟属正常现象。

补充一个Windows上容易踩的坑：如果你安装Node.js时没有勾选“Add to PATH”，那么npx这个命令在Claude Desktop启动的子进程里可能找不到。解决方法是把command改成npx的绝对路径，比如C:\Program Files\nodejs\npx.cmd。Linux/macOS也有类似情况，如果command记成"npx"但环境变量没带上，可以考虑用which npx查一下绝对路径填进去。

2.3 在Claude Code / Cursor里配置

Claude Code是命令行工具，配置方式更直接。执行：

claude mcp add playwright -- npx @playwright/mcp@latest

再加一行查看是否加载成功：

claude mcp list

看到playwright出现在列表里且状态是connected，就说明可以和AI对话了。

Cursor的用户在Settings里搜MCP，点Manage MCP Servers，在Global或Project级别的配置里新增Server，填法也一样：

Name: playwright Type: command Command: npx @playwright/mcp@latest

保存后回到对话界面，如果输入框旁边多出一个tools标识，打开能看到browser_navigate、browser_click这些工具，就说明MCP已经在工作。用Cursor的MCP有一个额外的好处：同一个对话里，你既能用AI写普通代码，又能让它切换到浏览器环境直接验证页面，很适合做前后端联调。

无论用哪个客户端，第一次都会自动安装依赖包，如果输出“Executable does not exist”这一行，多半是浏览器没装好，下一步运行npx playwright install chromium即可，后面常见问题章节会专门讲。

3. 核心能力拆解：AI能控制浏览器做什么

3.1 页面导航与信息提取：AI的“眼睛”

接入成功之后，AI手里其实就多了一把“远程操作浏览器”的工具。Playwright MCP暴露给模型的核心工具，完全可以按浏览器功能来分组理解。

第一组是导航和读取类。导航工具负责跳转URL，快照工具负责抓取当前页面的可交互元素快照。这两个常常成对出现：AI先导航到目标网址，再拍一张快照，看看页面上到底有哪些按钮、输入框、链接，然后决定下一步怎么走。

这里有个细节：MCP的快照不是普通的源代码，而是一个经过处理的可访问性快照，会把按钮的角色、文本、可用状态都列出来。这让AI比普通爬虫更聪明，因为它能区分“这是个可以点的按钮”和“这只是个长得像按钮的div”，定位可靠性高很多。

第二组是交互类。核心是点击、输入、填充表单、悬停、下拉选择这几个。AI会根据快照里的信息，自动挑一个最稳妥的定位方式，再执行操作。拿填表单举例：AI先看快照里有哪些输入框，然后逐个填内容，最后点击提交按钮。

第三组是多媒体输出类。截图和生成PDF。这两个最大的用途是“视觉验证”：让AI截一张图，然后它自己或者配合视觉模型，判断页面布局是否正常、某个元素是否真的渲染出来了。我经常拿这个功能做前端验收，省得一遍遍打开浏览器肉眼检验。

3.2 表单填写与点击操作：交互闭环的细节

表单操作是浏览器自动化的重头戏，也是MCP模式下最容易出问题的环节之一。先说结论：让AI填表单，最忌讳的是“凭想象力填”，最可靠的是“让AI先拍照再看”。

实际操作时，我会先给AI一个明确的任务：访问某个注册页面，然后注册一个测试账号。AI的执行路径一般是：

1. 调用导航工具打开注册页面。
2. 调用快照工具获取页面结构。
3. 根据快照识别用户名、密码、邮箱等输入框。
4. 逐个填充表单字段。
5. 勾选同意协议复选框。
6. 点击注册按钮。
7. 截图或读取提示信息，确认注册是否成功。

看起来很简单，但对AI来说，最难的是第3步的“识别”。如果页面的输入框没有明确label，只有placeholder和乱七八糟的class名，AI就得靠上下文猜。这时候，我们作为人类，可以在指令里给一点提示：比如“用户名输入框在页面右侧”“搜索框上面写着站内搜索”。这些额外信息能显著降低AI的误判率。

另外，点击操作也分单击和悬停。悬停一般用在鼠标悬停出现下拉菜单的场景，比如电商网站的“我的账户”菜单。实际使用中，我遇到过好几回AI直接点击导致菜单来不及展开的情况，后来让AI先hover再click，问题就没了。这个经验值得记一下。

3.3 截图与视觉验证：把“看到”变成一种断言

传统自动化测试里，要判断一个页面渲染得对不对，通常得靠断言代码比对元素属性。而MCP模式下，截图简直成了最高效的“断言工具”。

举个例子，我最近测一个登录页的移动端适配，用传统思路得写viewport设置、截图比对、像素级diff，麻烦得很。用Playwright MCP，我给AI一句指令：把浏览器窗口设置成375x812，打开登录页，截一张全屏图，判断输入框和按钮有没有超出屏幕。AI调用调整窗口尺寸的工具，然后截屏，最后通过视觉模型看图，直接告诉我“按钮右侧有一小块被裁掉了”。整个过程不到一分钟，效果立竿见影。

这种做法现在被叫做“视觉验证”。它没法100%替代像素级回归测试，但在探索性测试、快速验收、多端适配检查这些场景里，效率高得惊人。如果你把MCP接入到CI流程里，还可以让AI每次发版后截图若干关键页面，自动检查有没有明显样式错乱，这比人眼抽查靠谱得多。

3.4 多标签页、控制台与网络请求：进阶能力

除了基础操作，Playwright MCP还暴露了几个关键进阶工具。多标签管理类：新开标签页、列出所有标签页、切换标签页、关闭标签页，专门应付在多个页面之间来回切换的场景。比如AI先打开首页搜索关键词，再开一个新标签页打开竞品页面，来回对比信息，最后汇总结果——这在传统脚本里写起来得很小心维护tab句柄，在MCP下就是一句话的事。

控制台消息和网络请求监听也很有用。控制台消息工具能把页面console的报错、警告抓出来，做前端排错非常方便；网络请求工具能看到每一个请求的URL、状态码和耗时，基本等于给AI配了一套简化版DevTools。我给AI布置“检查某个接口是否返回500”这种任务时，AI就是靠这个工具抓到关键证据的。

最后一类是代码执行工具，允许AI在页面上下文里直接执行一段JavaScript脚本，返回结果。这个工具的灵活度很高，比如页面里有些动态渲染的数据，DOM快照读不全，AI可以直接用一句脚本把想要的数据“掏”出来。不过功能越强越要小心，千万别让AI在不明来源的页面里执行不受信的脚本，安全边界问题得把握好。

4. 实战案例：用自然语言完成一个完整的浏览器自动化任务

4.1 任务设定：找出某开源项目在GitHub上的Issue活跃度

光讲工具太抽象，我直接用一个最近做过的实战任务，把整个链路串起来。任务背景：我准备评估一个开源项目是否值得引入，关心它最近三个月的Issue数量、关闭率、以及Issue标签分布。人工一个个翻页面太慢，写爬虫又有点重，正好用Playwright MCP跑一遍。

目标站点是GitHub的某个仓库issue列表页。任务要求：

1. 打开项目Issues页面。
2. 统计当前第一页所有Issue的状态（open/closed）。
3. 提取每个Issue的标题和标签。
4. 打开两个代表性的Issue详情页，提取正文内容和评论数。
5. 汇总成一张表格返回给我。

这个任务在传统脚本里不算难，但要用Playwright从头写，得先研究页面结构、设计数据解析逻辑、处理分页和异步加载，耗时半小时起步。用MCP，重点全在“怎么描述需求”上。

4.2 操作过程实录：AI实际上是怎么干的

我把任务直接输入给配置好Playwright MCP的Claude Code，原话大致是：“用浏览器打开https://github.com/xxx/yyy/issues，分析第一页所有issue的标题、状态和标签，然后打开第一条和最后一条issue，读一下正文，最后汇总成表格。”

AI的执行路径还原如下：

第一步，调用导航工具进入issues列表页，紧接着调用快照工具，获取整页DOM快照。这一步花了大概3秒，因为issues页面的元素很多，快照内容比较长。

第二步，AI发现页面里的Issue条目是用列表项标签包裹的，标题、标签、状态都在不同的子元素里。它为了精确拿数据，没有只依赖快照，而是补了一次代码执行工具，写了一段简单的JS把列表数据批量提取出来。这一步充分体现了代码执行工具的灵活度。

第三步，AI回到快照里找到“第一条Issue”的链接，点击进去，然后用快照工具读详情页的正文和评论数，记录后调用导航工具回到列表页。再点开最后一条，重复同样的流程。

第四步，AI把收集到的数据整理成Markdown表格返回，并且在最后补了一句提示：当前筛选条件下，第一页有几个issue标记为bug标签，open和closed的比例是X比Y。整个过程大约3分钟，其中大部分时间花在加载GitHub页面上，AI真正的决策时间很少。

4.3 效果评估：比写脚本快在哪里

同样的任务，如果我用Python写Playwright脚本，粗估要40分钟到1小时：写定位逻辑、跑一遍排查、处理异常、再跑。这是“代码思维”的耗时。而用MCP走一遍，我只需要把需求说清楚，剩下的浏览器操作和数据处理AI都接管了。这次任务的实际结果是：耗时约3分钟，数据准确，表格结构清晰，中间没有需要人工介入的报错。

当然，这并不意味着MCP可以完全替代脚本。如果是每天固定跑一次的批量采集任务，我仍然会写成正式脚本放进调度，因为脚本的执行速度快、失败重试逻辑可控、对网络波动的容忍度也更高。MCP最大的价值是“快”，适合做一次性探索、想法验证、以及交给非专业开发者的交互式自动化；脚本最大的价值是“稳”，适合固化成重复执行的生产流程。两者配合，才是最高效的干活方式。

5. 常见问题与排查技巧实录

5.1 高频错误速查表：我踩过的坑

用Playwright MCP这段时间，我碰到过不少报错，下面把常见的高频问题整理成速查表，基本覆盖日常使用的80%场景。

这条速查表看着简单，但每一条背后都有真实耗费过时间的教训。比如“快照工具返回空”，我一开始很困惑，后来发现目标页面内部内容是由iframe加载的，DOM快照默认只能看到外层框架。解决办法也不是很麻烦：让AI先识别iframe元素，再针对iframe内部的页面做快照和提取。

5.2 实战避坑心得：几条过来人的建议

最后分享几条跟MCP浏览器自动化直接相关的实操心得，这些在官方文档里基本看不到，都是真金白银换来的经验。

第一，指令要带“验收标准”。给AI布置任务时，别只说“打开网站看看”，最好明确说清楚“打开后，确认右上角登录按钮是否存在，并将结果告诉我”。有了明确的验收标准，AI才知道什么时候算任务完成，也会主动截图或输出证据，你不会等来一个模糊结果。

第二，善用快照但别迷信快照。快照工具提供的是可访问性树，不能覆盖所有动态内容。遇到动态表格、Canvas、WebGL这类内容，直接让AI用代码执行工具去读更靠谱。我一般会跟AI说：如果快照内容不足以完成任务，可以考虑用evaluate方式获取数据。

第三，复杂页面分步骤下达指令。一次让AI做太多事，比如“打开三个网站、对比价格、还要登录后看历史价格”，大模型容易遗漏关键环节。最好拆成三步：先A再B最后C，每一步结束都让AI汇报。别嫌麻烦，步骤拆得越细，成功率越高。

第四，注意安全边界，不要用这个工具去做破解验证码、绕过风控等对抗性操作。一方面这违反平台使用协议，另一方面MCP的交互模式本身就不是为高对抗场景设计的，成功率低还容易把风险引到自己的环境里。老老实实做自动化测试、数据整理、AI辅助输入这些正经场景，工具能发挥的价值已经非常大了。

第五，版本锁pin。如果你把Playwright MCP用于生产环境，强烈建议不要一直用@latest，而是在package.json或者配置里锁定一个具体版本号。MCP Server迭代速度快，某个版本可能改动工具命名或者行为，今天能用的指令明天可能就失效了。锁版本能最大程度减少“升级即炸”的意外。

我自己这段时间用下来，最大的体会是：MCP不会淘汰写脚本的人，但它确实让“浏览器自动化”从一门需要精心维护代码的工程，变成了一项可以随时下达的自然语言指令。对我这种经常要验证各种网页、收集数据、检查前端细节的人来说，Playwright MCP就像给AI装上了一双实时能看的眼睛，效率提升非常明显。

最后再分享一个小技巧：在让AI操作长流程时，可以在任务描述里加一句“每完成一个动作，告诉我你观察到的页面状态”。这种输出方式会让AI主动汇报关键中间结果，一旦哪一步跑偏，你能第一时间发现并及时纠正，比闷头执行到最后再报错要省时间得多。如果你也在折腾AI Agent或者浏览器自动化，这套玩法值得上手试一次。