这两年做UI自动化最烦的一件事就是：写脚本的时间比跑脚本还长。后来我开始在Cursor里引入Playwright MCP，把“打开页面、输入账号、点击登录、断言结果”这些操作全部交给自然语言去驱动，实测下来脚本生成效率提升非常明显。这篇文章就围绕“如何用自然语言一键生成UI自动化测试脚本”这个主题，把我从环境搭建到实战落地、再到避坑排查的整个过程完整拆开来讲。无论你是刚接触自动化测试的新手，还是已经在维护UI用例的测试开发，这套组合都值得花一个下午试试。
1. 整体思路拆解：这三样东西凑在一起能干什么
1.1 为什么是Cursor+Playwright+MCP
先说结论：Cursor负责“思考”，Playwright负责“执行”，MCP负责“把思考和执行连起来”。这三者缺了任何一个，都没法形成真正的自然语言驱动测试闭环。
Cursor本质上是基于VSCode的AI编程编辑器，但它比普通插件强在“Agent模式”下可以自主调用工具、修改文件、执行命令。Playwright是微软出品的端到端测试框架，支持Chromium、Firefox、WebKit三大浏览器，定位器、自动等待、断言体系都比较完善，也是当前UI自动化测试的主流选择之一。MCP（Model Context Protocol）是一个开放协议，它给AI模型提供了一种标准化的方式去调用外部工具，Playwright MCP属于一个具体的工具服务，把浏览器能力封装成“打开网页、点击元素、输入文字、截图取快照”等一个个可被AI调用的工具函数。
这三者配合的核心价值在于：传统做法是“人写代码给机器跑”，现在变成了“人提需求给AI，AI通过MCP在真实浏览器里看页面、点元素、做验证，然后把测试脚本生成出来并运行给你看”。整个过程比单纯让AI写一段Playwright代码靠谱得多，因为AI不是凭空想象，而是真的“睁着眼睛”看了一遍页面结构。
1.2 自然语言生成测试脚本的完整链路
我实际走通的链路大致是这样：
- 在Cursor中配置好Playwright MCP Server，让AI拥有浏览器的操作工具。
- 在对话窗口用自然语言描述测试场景，比如“打开登录页，输入demo账号，点击登录，断言页面右上角出现用户名”。
- Cursor里的Agent会按顺序调用MCP工具：先
browser_navigate打开页面，再browser_snapshot获取当前页面的可访问性快照，接着调用点击、输入相关工具完成操作，最后用browser_assert或页面快照内容做断言。 - 当整个流程在浏览器里跑通之后，再让Cursor把刚才的每一步操作整理成标准Playwright测试脚本，保存到项目的test目录里，最后用
npx playwright test一键运行。
这条链路里最值得关注的是browser_snapshot。很多人以为AI写页面自动化脚本靠的是看HTML源码，但在MCP这套体系里，AI获取的是页面的可访问性快照，也就是经过浏览器渲染、并且带有元素角色和可访问名称的简化树结构。这种快照比原始HTML更接近用户视角，也更容易让AI判断该点哪里、该输入什么。
2. 环境准备：Cursor、Playwright与MCP的安装配置
2.1 Cursor安装和界面语言问题
Cursor的安装本身很简单，官网下载对应平台安装包，一路下一步。很多中文用户关心的“Cursor怎么设置中文”其实有两种情况：第一种是界面汉化，第二种是让AI用中文回答。界面汉化可以走VSCode生态的扩展方案，在扩展市场搜“Chinese (Simplified) Language Pack”，安装后按Ctrl+Shift+P打开命令面板，找到“Configure Display Language”选择中文即可，但实际测试下来部分界面仍是英文，不用纠结，核心功能就那几个入口。
更关键的是在设置里确认两件事：一是确认AI模型可用，Cursor支持多款模型，日常生成脚本用官方推荐模型就够；二是在Rules里写清楚你的偏好，比如“默认使用中文回答问题”“生成Playwright脚本时优先使用getByRole定位器”。这些规则会影响后续Agent的实际输出质量，建议提前配置好。
2.2 安装Playwright框架和环境
无论是否使用MCP，你都需要在项目目录里安装Playwright。如果是Node项目，执行npm init playwright@latest，会自动创建测试目录、示例配置和playwright.config.ts。如果想用Python版本，则是pip install playwright，随后执行playwright install下载浏览器内核。
我建议初学者从Node版入手，因为Playwright MCP本身也是Node生态的工具，同一套环境既能跑MCP又能跑测试脚本，少踩很多依赖冲突的坑。安装完成后先跑一下官方自带的示例用例，确认浏览器能正常启动，避免后面把环境问题错当成MCP问题来排查。
2.3 配置Playwright MCP Server
这是整篇文章最核心的配置步骤。先在项目根目录找到.cursor文件夹（没有就新建），在mcp.json里添加如下配置：
{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }如果你希望浏览器以无头模式运行，或者固定使用Chromium，可以加参数：
{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--headless", "--browser", "chromium"] } } }保存后在Cursor中打开MCP设置面板，检查playwright这条服务是否显示为绿色Enabled状态。首次启动时npx会自动下载@playwright/mcp包，需要等一会儿。看到状态正常后，重启一下Cursor的对话会话，让Agent重新加载工具列表。
然后开始写AI提示词时，也要注意：不要在对话里用以往的“帮我写脚本”这种空泛表述，而是要明确告诉AI“你可以使用Playwright MCP工具，请先打开浏览器查看页面，再进行操作并生成测试脚本”。
注意：如果你是Windows系统，第一次连接MCP时防火墙可能会弹出Node.js网络访问提示，务必允许。否则AI调用浏览器工具时会卡住，表现为MCP工具一直转圈或直接报连接超时。
3. 实战演示：用一句话生成可运行的登录测试脚本
3.1 准备一个目标测试页面
本地搭建一套真实项目代价太高，我建议用公开的演示站点或自己项目里的临时页面。为了演示完整流程，我以典型后台登录页为例，页面包含：用户名输入框、密码输入框、登录按钮，以及登录成功后的欢迎横幅。这个场景覆盖面广，能展示输入、点击、断言、等待多个基本操作，也最容易迁移到其他业务系统。
在开始之前，先手动打开目标页面，确认关键的定位信息：比如用户名的placeholder是“请输入用户名”，密码输入框的type是password，登录按钮的文本是“登录”。如果页面里有iframe，还要额外注意层级关系。准备好这些信息后，回到Cursor对话窗口。
3.2 给AI下达自然语言指令并观察MCP执行
我的常用提示词模板是这样的：
请使用Playwright MCP工具，帮我完成以下UI自动化测试场景的验证： 1. 打开 https://example.com/login 2. 在用户名输入框输入 demo 3. 在密码输入框输入 123456 4. 点击“登录”按钮 5. 验证登录成功后页面是否出现“欢迎回来，demo” 先实际操作一遍，确认流程通过后，再把整个操作整理成test目录下可运行的Playwright测试脚本。这一段提示词涵盖了“目标URL”“操作步骤”“预期结果”“交付物要求”四个要素。AI收到指令后，会依次调用browser_navigate、browser_snapshot、browser_type_text、browser_click等工具。你可以在Cursor的输出面板和浏览器窗口里实时看到它的动作。
我第一次跑的时候，AI在点击“登录”之后并没有立即断言成功，而是再次browser_snapshot确认页面变化，然后才判断“出现了欢迎字样”。这种“先核实，再下结论”的行为模式，正是引入MCP之后带来的最大价值：AI不再是一口气写出一大段未经验证的代码，而是每一步都拿到真实的页面反馈再走下一步，生成的脚本自然也就更接近可运行状态。
3.3 从浏览器操作整理成规范脚本
当AI执行完操作并确认流程通过后，我通常会在最后追加一句：“请基于刚才的浏览器操作过程，生成完整的Playwright测试脚本，要求使用getByRole/getByLabel定位器，并包含等待和断言。”这样它就会把刚才的对话过程“翻译”成规范的测试代码，写入文件中。
生成后的脚本大致长这样：
import { test, expect } from '@playwright/test'; test('用户登录成功', async ({ page }) => { await page.goto('https://example.com/login'); await page.getByLabel('用户名').fill('demo'); await page.getByLabel('密码').fill('123456'); await page.getByRole('button', { name: '登录' }).click(); await expect(page.getByText('欢迎回来，demo')).toBeVisible({ timeout: 10000 }); });这里要特别提醒：AI在对话过程中生成的是一次性浏览器操作，不一定适合直接当长期回归脚本。你需要让它输出标准测试格式，并且检查它使用的等待策略和断言方式，避免出现固定睡眠等待（page.waitForTimeout(3000)）。我一般在生成后还会要求它替换掉任何“硬编码等待”，换成显式等待或自动等待断言。
4. MCP协议与工具原理：AI是怎么在浏览器里“长出手脚”的
4.1 MCP协议的基本构成：Host、Client、Server
MCP采用的是客户端-服务器架构，包含三个核心角色：Host是宿主应用，比如Cursor或Claude Desktop；Client是Host内部负责和Server通信的组件；Server则是具体能力的提供端，比如Playwright MCP。
我用一个生活化类比来理解：MCP很像通用的电源插座协议。Cursor是家里的墙插，MCP Server是各种电器，而具体连接用的数据线则是MCP Client。只要电器按统一标准造出插头，换任何品牌的墙插都能插上，不需要为每台电器单独设计专用线。所以理论上你今天在Cursor里配了一套Playwright MCP，明天换成支持MCP的其他AI编辑器，同样的配置和工具能力可以迁移过去，这是这个协议最值钱的地方。
4.2 Playwright MCP暴露的核心工具清单
理解Playwright MCP，关键是知道它到底暴露了哪些工具。实际使用中你会频繁接触到下面这些：
browser_navigate：让浏览器跳转到指定URL。browser_snapshot：抓取当前页面的可访问性快照，AI用这个来判断页面结构和元素位置。browser_click：点击某个定位到的元素。browser_type_text：在输入框内填写文本。browser_select_option：操作下拉框。browser_hover：悬停元素，常用于处理下拉菜单。browser_assert：对页面状态做断言，比如断言URL、元素可见性等。browser_evaluate：在页面上下文执行JavaScript表达式，适合读取数据或做复杂操作。browser_tab_switch/browser_tab_close：处理多标签页场景。browser_pdf_save/browser_screenshot：保存PDF或截图，用于留存证据。
你并不需要把这些工具一个个都背下来，Cursor的Agent会自动根据需求选择合适的工具调用。但了解工具边界很有必要，才能自然描述任务。比如你想关注某个登录接口的返回状态，光靠快照是不够的，需要明确告诉AI“请用browser_evaluate去监听window.performance的资源条目”。
4.3 为什么能处理动态iframe和请求监听
热词里有“scrapy playwright 动态 iframe”，说明很多人被内嵌页面折腾过。传统爬虫或自动化测试遇到iframe，要么需要用frame_locator精确切入，要么等待动态渲染完成，处理起来很繁琐。
在Playwright MCP这套机制里，AI拿到的快照通常已经把可访问的iframe内容合并进去了，所以常见的非跨域iframe，AI可以直接“看到”里面的按钮和输入框，不需要你手动指定frame。但如果遇到跨域iframe或极端复杂的嵌套结构，快照可能无法完整暴露元素，这时候我一般会让AI用browser_evaluate执行document.querySelectorAll('iframe')去检查框架结构，再决定是否切frame。
至于请求监听，接入MCP之后可以有两种玩法：一种是在对话中让AI用browser_evaluate注入performance.getEntriesByType('resource')来观察页面加载了哪些资源；另一种是导出脚本后在Playwright测试代码里通过page.on('request')做正式断言。前者适合前期探索，后者适合沉淀为回归用例，两者互相配合。
5. 常见问题与排查技巧实录
5.1 同时使用Sync与Async API导致报错
很多人在Jupyter或交互式环境里用Playwright时看到一个报错：“It looks like you are using Playwright Sync...”。这其实是API模式混用问题。Playwright同时提供sync_playwright和async_playwright两套API，同步和异步不能混着来。
比如你在一个已经运行asyncio事件循环的解释器里，执行了使用同步API的代码，就会触发这个错误。解决办法也很直观：要么统一改成异步API并在代码里用asyncio.run()包住主入口，要么干脆切到普通Python脚本文件里运行同步API，不要在Jupyter单元格里反复启动playwright对象。我自己的习惯是：涉及MCP和浏览器交互的探索放在Jupyter里只用异步版本，正式测试用例全部统一走Playwright的pytest插件或Node test runner，避免混用。
5.2 MCP服务无法启用或浏览器不启动
这类问题我排过好几次，有四个高频原因。一是npx拉取包太慢或失败，可以先手动执行npx @playwright/mcp@latest --help看能否正常输出版本信息；二是MCP Server要求Node版本足够新，低于18会直接报错，升级Node就能解决；三是防火墙拦截了Node进程，Windows用户尤其常见，需要在防火墙面板确认node.js的专用网络和公用网络都被允许；四是Cursor的MCP配置路径不对，注意mcp.json要放在.cursor目录下，而不是项目根目录下。
还有一个很隐蔽的问题：如果你在mcp.json里同时配置了多个MCP Server，其中一个异常启动失败，可能会导致Cursor整个MCP面板都卡住。我建议排查时先只保留playwright这一条，确认它能独立工作，再逐步加其他服务。
5.3 自然语言生成脚本不稳定、定位器总变，怎么破解
有不少朋友说AI生成的脚本跑一次就崩，大多是定位器问题。我踩过坑之后总结出三条经验。
第一，在提示词里明确要求AI优先使用面向用户的定位方式。getByRole和getByLabel这类定位器对应的是可访问性信息，比依赖CSS类名或XPath稳定得多。我一般会在Cursor的Rules里写死这条规则。
第二，页面结构发生变化后，不要直接让AI“盲改”定位器，而是先用browser_snapshot看一遍当前页面结构。手动模式下降一次容易，如果脚本多了，建议把MCP的“浏览器内核实”作为改脚本的标准动作：先让AI打开页面、重新拍快照、再修改定位器，改完立刻跑一次测试验证。
第三，给AI尽量准确的上下文。直接说“登录按钮找不到了”，它只能猜；说“页面快照里出现了‘手机号登录’和‘账号登录’两个Tab，我需要点的是账号登录Tab下的登录按钮”，它能直接定位。这本质上是一个提示词工程问题，但也反映了自然语言驱动测试的一个核心原则：需求越具体，输出越可靠。
5.4 测试脚本如何从“能跑”变成“可维护”
生成脚本只是第一步，真正能长期使用的脚本还需要几道工序。我把常用的维护清单列在这里：
- 把测试数据和断言分离，不要硬编码用户名密码在脚本里。
- 使用
test.describe.configure({ retries: 1 })或配置文件里的重试策略，减少偶发失败对团队的噪音。 - 在关键操作前后添加截图，失败时自动保存截图，方便定位问题。
- 把Playwright脚本纳入项目代码仓库，配合CI流水线在每次代码合入后自动执行冒烟用例。
如果你用的是Node版本，还可以引入@playwright/test的webServer配置，在跑测试前自动启动前端服务，整个流程可以真正做到从零开始一键回归。
写在最后的体会
我实际用Cursor+Playwright MCP写了几个星期的UI测试用例，最大的感受是：这个组合最擅长的不是替代测试开发，而是把“从需求到可运行脚本”中间的试错成本大幅降下来。过去一个新业务的冒烟用例，从阅读页面结构到写定位器再到调试通过，快则半天慢则一整天；现在借助MCP，AI能在真实浏览器里边看边做，第一版脚本的可用率就相当高，剩下的人工工作主要是审查、补充边界断言和维护定位器。
另外一个很实用的建议：不要一次性让AI生成整个大型测试套件，而是每个冒烟场景单独对话生成。这样每一段脚本都有清晰的上下文，出问题时也方便定位。日常迭代中，我会把经常变化的页面元素记录在一份说明文档里，每次让AI动脚本前先告诉它“页面上有哪些坑”。这套玩法用顺手之后，你会发现UI自动化测试最大的瓶颈已经从“写脚本”变成了“想清楚到底要测什么”——这反而是一件好事。
