Cursor+MCP+Playwright：从AI写代码到AI操作浏览器

当前端工程师、自动化测试工程师、以及所有天天和浏览器打交道的人开始把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三大内核。相比SeleniumPlaywright有几个肉眼可见的优势安装简单、自带浏览器下载机制、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.10Playwright的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(headlessTrue) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()如果这个脚本能正确打印出页面标题说明Playwright本身没问题可以进入下一步。3.3 将MCP服务器接入CursorCursor对MCP的支持是通过一个配置文件实现的路径在你的项目目录下的.cursor文件夹里文件名通常叫mcp.json。我这里的配置内容是这个样子的{ mcpServers: { playwright: { command: npx, args: [ playwright/mcplatest ] } } }配置好之后在Cursor的命令面板里找到MCP相关的刷新命令或者直接重开窗口让它重新加载。加载成功之后对话框里会多出MCP工具列表能看到类似“browser_navigate导航到URL”“browser_click点击元素”“browser_snapshot获取页面快照”这样的工具描述。这里有个细节要注意npx首次运行需要下载包如果网络状况一般会有一定延迟甚至超时失败。建议先手动在终端执行一遍npx playwright/mcplatest让它把包拉下来缓存住后续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跑三分钟我再花五分钟验收。这种工作方式的迁移比加班加点写代码给效率带来的提升要实在得多。