企业官网建设流程全解析

当前端工程师、自动化测试工程师、以及所有天天和浏览器打交道的人开始把Cursor当作日常主力编辑器之后，一个特别明显的趋势出现了：AI写代码的能力再强，它也始终是个“坐在编辑器里的助手”，你要是让它去帮你打开网页、点按钮、填表单、抓数据，它就完全没辙了。直到MCP协议的出现，把“AI能看能写”和“AI能动手操作”之间那堵墙彻底拆掉，而Playwright作为现代浏览器自动化框架，恰好成了这堵墙拆掉之后最顺手的“手”。

这篇文章我想从一次真实的实践经历出发，聊聊Cursor、MCP与Playwright这三者是怎么组合起来，形成一个“自然语言指令→AI理解意图→调用浏览器工具→执行并返回结果”的完整闭环的。如果你正在用Cursor写代码，或者你负责的项目里有大量重复性网页操作要做，又或者你单纯好奇“AI怎么真正替我把活干了”而不只是“帮我写段代码”，那这篇文章应该正好踩在你的需求点上。

1. 先把三件套的身份搞清楚

1.1 Cursor：不只是自动补全，而是“意图执行中枢”

很多人对Cursor的理解还停留在“一个带了AI功能的编辑器”，但实际上，Cursor真正厉害的地方在于它构建了一个“Agent式”的开发环境。你可以在对话窗口里用自然语言描述需求，它能自动读取你的项目结构、修改多个文件、执行终端命令，甚至主动去搜索文档。换句话说，Cursor已经不再是“你写代码它补全”，而是“你说需求它干活”的状态。

但这里有一个很明显的边界：Cursor能操作的是“你的代码项目”这个抽象空间，它能读写文件、运行命令，但它没法直接操作“外部世界”。什么叫外部世界？就是浏览器里的某个网页、某个按钮、某个登录框。你让Cursor“帮我去某某网站把那个表格的数据抓下来”，它做不到，因为它没有一个可以控制浏览器的“手”。这就是它需要与外部工具协议配合的根本原因。

1.2 MCP：模型上下文协议，AI与工具间的“万能插座”

MCP的全称是Model Context Protocol，从名字就能看出来，它是用来“给模型提供上下文”的协议。这个描述有点抽象，我习惯把它类比成USB-C接口：以前每个设备都有自己的充电口，你要带一堆线；MCP就是那个统一的接口标准，让AI模型可以统一地接入各种外部工具、数据源、服务。

具体到浏览器自动化场景，MCP定义了一套标准化的通信方式：AI模型（比如Cursor里内置的模型）通过MCP客户端发送请求，MCP服务器收到请求后去调用真实的工具（比如Playwright去控制浏览器），再把结果返回给模型。这个过程中，AI不需要知道Playwright的API具体长什么样，它只需要知道“有一个工具叫浏览器控制，我可以让它去打开网页、点击元素、读取内容”，剩下的事情由MCP服务器翻译成真正的浏览器操作指令。

需要说明的是，MCP本身是一个通用协议，浏览器访问只是它其中一个典型的应用场景。它同样可以用来连接数据库、操作本地文件、调用外部API等等。但在我这次的实践里，它承担的角色非常纯粹：充当Cursor和Playwright之间的消息中转站。

1.3 Playwright：现代自动化框架里的“六边形战士”

Playwright是微软出品的浏览器自动化框架，支持Chromium、Firefox和WebKit三大内核。相比Selenium，Playwright有几个肉眼可见的优势：安装简单、自带浏览器下载机制、API设计更现代化、对现代前端框架（比如React、Vue）的兼容性更好，而且它的等待机制非常智能，基本不怎么需要你手动写sleep。

在MCP这个体系里，Playwright并不是直接暴露给用户的。你不需要自己写page.click()这样的代码，MCP服务器已经把Playwright的能力封装成了一个个“工具”（tools），比如“打开URL”“点击元素”“填写输入框”“获取页面文本”“截图”等。AI模型通过这些工具的语义化描述来决定怎么用它们，执行的时候再由MCP服务器调用Playwright真实执行。

所以你可以这样理解：Cursor是大脑，Playwright是手，MCP是连接大脑和手的神经通路。

2. 为什么这三者能组合成一套完整的工作流

2.1 传统自动化方式到底痛在哪里

如果你之前做过网页自动化，一定对这套流程不陌生：手动查文档找到XPath或CSS选择器，自己写代码处理等待、重试、异常，跑一次不行再调试，几乎每个网站的选择器都需要单独适配。哪怕你用Selenium这种成熟框架，写起来依然很琐碎，尤其在处理弹窗、动态加载、iframe嵌套这些场景时，调试时间往往比写代码时间还长。

而AI编程助手出现以后，虽然能帮你写这些自动化脚本，但它仍然需要你先把需求描述得很精确，告诉它用什么选择器、怎么处理等待逻辑。本质上还是“你来设计，它来写码”，只是把写码这一步自动化了。如果网站结构改了，你还是要自己去发现问题、修改定位表达式。体验提升有，但没有质变。

2.2 MCP把“人设计流程”改成了“AI自己探索”

MCP接入Playwright之后，整个范式变了。你只需要给AI一个目标，比如“登录这个网站，把某个板块的数据抓下来，整理成表格输出”，AI会自己决定先调用哪个工具、怎么试探页面结构、出错了怎么重试。它不再是一个“帮你把想法翻译成代码”的工具，而是一个“自己去摸索执行路径”的智能体。

这种能力的关键就在MCP的消息返回机制：AI每调用一次工具，都能拿到这次操作的观察结果，比如页面标题、当前URL、可见文本、元素状态等等。它就像一个蒙着眼睛的人，每走一步就有人告诉他现在的环境是什么样的，他就根据这些反馈决定下一步动作。这本质上就是强化学习里“动作-观察”循环的工程化简化版。

2.3 最能体现这套组合价值的几个应用场景

我实测下来，最有价值的是这几类场景。

第一类是数据采集。以前写爬虫要应对JS动态渲染、登录态、翻页机制，现在只需要给AI描述清楚“我要什么样的数据，在哪个网站”，它自己会通过浏览器操作去完成。好处是几乎不需要关心反爬策略，因为它是用真实浏览器行为在操作，比单纯发HTTP请求隐蔽得多。

第二类是端到端流程验证。比如你有一个多步骤表单提交的流程，你可以让AI在测试环境完整走一遍，观察每一步是否成功，产出截图和日志。这对回归测试特别有用，因为AI能根据页面实际反馈动态调整，而不是死板地按脚本走。

第三类是一些“一次性”的网页操作。比如临时需要把某个在线报表里的数据导出来、批量处理后台审核等。这种活不值得专门写一套自动化代码，但人工做又很浪费时间，用自然语言让AI去执行就刚刚好。

3. 环境准备：从零搭起这条开发链

3.1 软件与版本选型

我这次实践用的是Windows系统，但Linux/macOS的操作基本一致。需要准备的组件如下：

• Cursor：建议用最新版，MCP功能在较新版本里才稳定。
• Python 3.10+：Playwright的Python版本是目前MCP生态里最成熟的。
• Node.js 18+：部分MCP服务器工具链依赖Node，建议提前装好。
• Playwright：通过pip安装，并执行playwright install下载浏览器内核。
• MCP服务器插件：这里用的是社区维护的Playwright MCP服务。

我的选择逻辑很简单：能用官方或社区活跃度高的方案就绝不用自己折腾的脚本。MCP的生态还在快速演进，选活跃项目的好处是遇到问题搜得到解决方案，不至于被坑到原地自闭。

3.2 安装Playwright并完成基础验证

第一步是安装Python环境下的Playwright。直接在虚拟环境里执行：

pip install playwright playwright install chromium

这里建议只装Chromium就够了，Firefox和WebKit在MCP场景下用到的概率不大，而且每个内核都要占几百兆磁盘空间，没必要全装。装完之后可以写个最简单的脚本验证一下：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto("https://example.com") print(page.title()) browser.close()

如果这个脚本能正确打印出页面标题，说明Playwright本身没问题，可以进入下一步。

3.3 将MCP服务器接入Cursor

Cursor对MCP的支持是通过一个配置文件实现的，路径在你的项目目录下的.cursor文件夹里，文件名通常叫mcp.json。我这里的配置内容是这个样子的：

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

配置好之后，在Cursor的命令面板里找到MCP相关的刷新命令，或者直接重开窗口让它重新加载。加载成功之后，对话框里会多出MCP工具列表，能看到类似“browser_navigate（导航到URL）”“browser_click（点击元素）”“browser_snapshot（获取页面快照）”这样的工具描述。

这里有个细节要注意：npx首次运行需要下载包，如果网络状况一般，会有一定延迟，甚至超时失败。建议先手动在终端执行一遍npx @playwright/mcp@latest，让它把包拉下来缓存住，后续Cursor调用就不会再卡在下载阶段。

3.4 验证连通性：让AI自己打开一个网页

配置完成之后，我在Cursor的AI对话窗口里输入了一条测试指令：“用浏览器打开百度首页，然后告诉我页面标题和搜索按钮的文字”。第一次看到AI逐条调用工具、返回观察结果、最终汇总输出答案的过程，确实有一种“原来这就是AI替人干活”的实感。

如果这一步失败了，先别急着排查MCP配置，先确认Playwright能否独立运行。很多连接问题其实都出在浏览器内核没下载完整，或者Python环境路径不对导致MCP服务器无法启动。

4. 实操记录：让AI独立完成一个自动化任务

4.1 我挖了一个什么坑来实测

为了测试这套组合的真实水平，我设置了一个稍微有点复杂的任务：去某个公开的行业数据网站，把某个类目下的列表页数据翻页抓取前3页，提取每条的标题、发布时间和摘要，最后整理成Markdown表格输出。

这个任务其实考察了三个核心能力：数据翻页时的URL变化处理能力、动态加载时的等待策略、以及结构化输出的能力。放在传统自动化里，至少需要写50行以上代码加调试好几个选择器；而在MCP模式下，我只需要把需求描述清楚，然后把剩下的执行交给AI。

4.2 完整执行过程记录

我在对话窗口里的指令是这样的：

打开https://xxx.com，点击导航栏里的“行业资讯”分类，然后循环翻页抓取前3页的文章列表，每条数据需要标题、日期、摘要三项，最后整理成Markdown表格。

AI的第一个动作是调用browser_navigate打开网站，紧接着调用browser_snapshot获取当前页面的可访问性快照。这个快照很有意思：它不是截图，而是一个结构化的页面文本描述，带有简化后的元素编号，AI就是靠这些编号来决定应该点击哪个位置。

AI从快照里识别出导航栏的“行业资讯”入口，调用browser_click点击之后，再通过browser_snapshot观察页面变化，发现列表结构已经渲染出来了，于是开始提取第一页的数据。第一页完成之后，我去检查已经拿到的列表数据，确认项目完整且没有重复。接下来AI判断翻页控件的位置，调用browser_click点击“下一页”，重复“观察页面→提取数据”的循环。

整个过程我记录了AI调用工具的次数：从打开页面到最终输出表格，一共调用了14次工具，其中有两次点击发生了误判，AI自动回退重新观察了一次。整个任务耗时大约3分半，其中大部分时间花在页面加载和AI推理上。这个速度虽然比不上一个精心调优的爬虫脚本，但考虑到这是AI从零开始自主探索完成的，效率已经相当能打了。

4.3 对输出结果的验证与思考

AI最终输出的Markdown表格里，我抽了5条记录去网站上人工比对，标题、日期、摘要都能对上，排序和页面一致，没有出现跨行串列的问题。这说明它提取数据时用的是页面结构里的文本节点，而不是扫描整个页面的OCR式识别，精度是有保障的。

但也有一个明显的槽点：AI对“下一页”按钮的定位逻辑并不是每次都稳。当页面切换到第二页之后，页面结构里那个“下一页”按钮的DOM属性发生变化，AI第一次点击时其实点到了别的元素上，页面没有跳转。好在它执行完点击之后会主动观察页面状态，发现列表数据没有更新，就重新定位了一次。

这说明这套方案在实际使用中还不能做到百发百中，需要你接受一定比例的自动纠错过程。如果你想减少这种返工，可以在指令里提前补充信息，比如“下一页按钮是页面底部那个文字为下一页的链接”“数据块统一包含class属性”，AI会提前锁定目标，成功率会高很多。

5. 问题排查与避坑清单

5.1 连接类问题：AI一直说工具不可用

这是聊天频道里出现得最多的求助类型。MCP服务器配置了，AI对话界面里也能看到工具列表，但一调用就报错或者返回空结果。遇到这种情况，我建议按顺序排查：

先确认MCP服务器的进程是否存活。可以在Cursor的MCP面板里查看服务器连接状态，如果显示未连接，大概率是配置里的启动命令有问题。再确认Playwright的浏览器内核是否完整安装，直接在命令行跑一个小脚本验证。最后确认Cursor的版本是不是太老，MCP功能在旧版本上有过若干bug，升级一下往往就好了。

5.2 浏览器操作类问题：页面打开但点击无效

这类问题的根源通常是两种。一种是页面本身用了特殊的渲染逻辑，比如Web组件或者Canvas渲染，导致标准DOM选择器定位不到元素，而AI依赖的快照本质上还是分析DOM结构，遇到这种情况就会抓瞎。另一种是页面里有多个相同文案的元素，AI没能区分到底该点哪一个，做了错误的选择。

针对第一种问题，我的建议是换场景而不是硬刚。如果一个页面高度依赖Canvas渲染，那所有基于DOM的自动化工具都难受，不只是这套组合的问题。针对第二种问题，可以在指令里描述得更精确，比如“点击右上角的登录按钮”，AI就能结合位置信息来区分。

5.3 AI行为类问题：越权操作或逻辑跑偏

这是最有意思也是需要警惕的一类问题。AI在探索页面过程中，可能会因为指令里的某些暗示，去点击了一些影响数据的操作按钮，比如“删除”“修改”“提交”，一旦在真实环境里触发，后果会很麻烦。

所以我的原则是：凡是执行任务时把浏览器指向生产环境或者有真实数据的环境，一定要在指令里明确加上“只允许读取操作，禁止任何修改、删除、提交操作”。AI目前对这类约束的理解能力还是很强的，但你不主动说，它就不一定主动规避。

5.4 一个重要的安全提醒

MCP赋予了AI操作浏览器的能力，这本质上是一种高权限能力。如果让MCP服务器以你日常登录态的浏览器Profile运行，AI就拥有了你在各个网站上已有的登录权限，这意味着它能以你的身份执行操作。

所以在配置和使用时，建议让Playwright使用独立的浏览器Profile，不要挂载你的常用登录态。如果需要登录操作，可以在自动化会话里重新走一遍登录流程，而不要让AI直接继承你本地浏览器的全部Cookies。这既能防止AI误操作波及你的真实账号，也能避免很多隐私上的不确定性。

6. 音效优化与扩展思路

6.1 让AI的执行过程可观察、可干预

如果你不想像个盲人一样看着AI自己在那跑流程，有两点值得做。一是把AI的调用记录和浏览器执行过程截图保存下来，出了问题你能清晰回溯是哪一步选错了路。二是学会在过程中插话，MCP模式下AI是支持你在执行中途补充指令或纠正方向的，不用傻等它跑完才发现全错了。

6.2 在MCP体系里探索更多的可能性

Playwright MCP只是MCP生态里很小的一个分支。我在完成浏览器自动化实践之后，又顺手接了一个文件系统MCP，让AI可以直接读写本地Markdown笔记；还试了一个API对接的MCP，让AI去调用某个公开接口拉数据。这些和浏览器自动化叠加在一起，能拼出很多有意思的工作流。

我个人判断，MCP这套协议大概率会成为AI应用基础设施的一部分。随着越来越多的工具提供MCP接入能力，“AI+工具”的组合会越来越像一个真正的数字员工，而不是一个只会聊天的对话窗口。Cursor在其中扮演的角色也会逐渐变化，从编辑器变成指挥中心。

6.3 常态化使用的几点心得体会

最后分享几条踩坑之后的实在感受。

第一，给AI的指令要像给新同事交代工作一样写清楚边界和目标。太开放的任务容易让AI瞎折腾，太细节的描述又限制了它灵活探索的能力。最合适的粒度是“做什么、做到什么程度、哪些事千万别做”。

第二，别期待一次成功。就算AI表现得很聪明，也要把它当成一个需要反复验收的下属。每次跑完任务都检查一遍输出，发现问题就顺手在指令里补充约束，多跑几轮之后，整套流程会稳定很多。

第三，关注隐私和数据安全底线。MCP让AI能操作的东西变多了，但也意味着你的敏感信息暴露面变大了。不要轻易把高权限MCP服务器挂在公共聊天工具或者不可信的模型服务上，该隔离的隔离，该限制的限制。

这些年做技术最直观的感受是：工具的上限一直在提高，而人和AI协作的下限从没这么友好过。以前是我花一小时写脚本，再去花一小时调试脚本；现在是花一分钟写指令，AI跑三分钟，我再花五分钟验收。这种工作方式的迁移，比加班加点写代码给效率带来的提升要实在得多。