前言
近期团队完成了 UI 自动化重构，将底层驱动从 Selenium 迁移至 Playwright。在 AI 大模型的加持下，脚本的稳定性和编写效率均有显著提升。本文不追求面面俱到地教会你如何写代码，而是重点分享从原理对比到架构设计的思路，希望能为你提供参考。
一、Playwright 与 Selenium 对比
关于两者的差异，业界已有不少总结。这里从原理层面简单梳理一下，便于理解核心区别：
- Selenium：使用'代理'WebDriver 协议来统一接口对接不同厂家的浏览器。
- Playwright：直接与各浏览器的原生底层调试协议通信（如 Chrome DevTools Protocol, CDP）。
从原理上看，Selenium 是在众多浏览器之上'套了一层'，导致它无法获取浏览器原生的底层数据，例如网络请求参数、控制台信息等。执行速度上，Playwright 也天然更快。在 AI 时代，由于底层原理的限制，Selenium 相关的 AI 应用落地较难见到明显成果。反观 Playwright，结合 AI 的应用场景更为丰富，这也是我们近期切换底层驱动的主要原因。
二、AI + Playwright MCP
如何让 AI 与 Web 自动化有效结合？核心在于利用 MCP（Model Context Protocol）让 AI 模型分析页面 DOM 元素，并驱动浏览器交互。
MCP 能告诉 AI 记住页面交互的细节，它会抓取页面情况并分析元素结构和交互过程。有了这些源数据，AI 能很好地辅助编写 UI 自动化脚本。如果你本身有良好的代码结构，AI 生成的脚本工作量会大幅减少。
关于模型选择，目前 LLM 百花齐放，对于普通开发者而言，第一梯队的大模型差异并不大。建议根据实际体验，哪个顺手用哪个。
需要注意的是，AI 也会犯错，甚至可能带偏方向。利用好 AI 是一门学问，个人建议遵循以下原则：
- AI 辅助，半自动配合：不要偷懒不去 Review AI 生成的代码，有错误必须反馈。
- 积累有效 Prompt：建立自己的提示词库。
- 及时止损：如果 AI 生成代码毫无逻辑，立即停止，手动 Coding 教会它如何写。
- 拆分模式：在 AI 生成代码复杂时，手动拆分模块加入合理设计，这样更高效。
演示效果
试运行生成的脚本，可以看到 AI 分析页面并输出脚本的能力。在实际业务中仍需根据具体需求进行调整，大家可举一反三。
三、Playwright 封装设计建议
在分层设计思想的指导下，考虑到可维护性和可扩展性，主要的封装思路如下：
- 基础层封装：Playwright 提供了原生操作浏览器的能力（如 click、input 等），基于此封装一个业务层的
XxxPlayWright。 - 组件化：每个公司的业务控件大多经过定制，基于
XxxPlayWright将告警框、下拉框等操作模块化，可考虑使用 Mixin 等结构型设计模式。 - 业务关键字层：基于模块组件化代码，封装业务关键字，提供业务的 UI 操作能力。
- 用例层：Case 上层只调用 UI 业务代码关键字。
RobotFramework-Browser 介绍
博主使用的自动化测试框架是 Robot Framework，因此针对 RF 简单介绍相关配置。如果使用 Pytest，原理类似。
Robot Framework Browser Library 由 Playwright 驱动。关键点在于 new browser、new page 等资源无需手动清理，RF 框架会自动处理资源隔离和关联。这大大降低了资源管理的复杂度。
