做 UI 自动化的同学应该能感受到，近几年 UI 自动化的技术框架一直在迭代更新。过去很多团队都在使用 Selenium，实际项目里经常遇到脚本不稳定、元素定位容易失效、多浏览器适配繁琐，后期脚本维护工作量大等问题。不少团队也在逐步替换这套方案。
Playwright 凭借运行稳定、多浏览器兼容、原生配套能力完善等优点，现在已经被很多企业用于 UI 自动化项目。
但换框架不等于自动化就能顺利落地，难题依然存在：
脚本怎么来？手写耗时，全 AI 生成又十分消耗 Token；
演示环境跑通的脚本，回归时能不能保持稳定；
人工流程控制、工程化资产沉淀、页面探查，能不能拆分独立使用。
我基于 Playwright 本身的三大核心能力，搭配自研 Skill，整理出三套可直接实践的 UI 自动化方案，可以适配快速调试、日常回归、降低 Token 消耗、人工介入管控等不同业务场景。这篇文章给大家分享下三套方案的思路和差异。
Playwright核心能力介绍
过去几个月，我基于 Playwright 的官方原生组件，实践出三套 UI 自动化落地方案，分别围绕 Playwright CLI、Playwright Test、Playwright Codegen 来搭建。不少测试同学容易混淆这三者，搞不清各自的定位与差异，下面就逐一展开说明。
1、Playwright CLI（页面探查工具）
Playwright CLI 是面向命令行、Agent 的浏览器操作入口。通过简单指令就可以实现打开页面、抓取页面结构（包含无障碍快照）、点击输入、截图录屏等一系列操作。
**优点：**可以让 AI 直接读取页面信息并执行操作，反馈速度快，很适合用来做可视化的页面探索。
**缺点：**它拿到的元素引用只适用于当前会话，如果直接拿来做长期回归用例，脚本稳定性不足，也缺少完整的报告能力，并不适合直接作为正式测试资产。
2、Playwright Test（测试运行框架）
Playwright Test 是官方主推的端到端测试运行框架，用例管理、断言、Fixture、自动等待、并行执行、HTML 报告、Trace 排查这些工程化能力，都由它来提供。
**优点：**可以把自动化脚本变成能够版本管理、可反复执行的测试资产，最终产出一般是.spec.ts 这类测试文件，配合官方运行器执行。
**缺点：**前期调试大多需要修改代码反复试错，做页面探索时不如 CLI 轻便。我实际落地的思路，一般先用 CLI 完成页面探查，再把内容迁移到 Playwright Test 中做正式用例。
3、Playwright Codegen（人工录制工具）
Codegen 是 Playwright 内置的录制工具。我们在浏览器里手动完成点击、输入、页面跳转等操作，工具就会实时生成可运行的代码，会优先生成稳定性更好的元素定位，也可以同步录制一部分断言。
**优点：**业务流程由人工把控，脚本初稿直接由工具生成，不需要大模型从零去解析和猜测页面，节省token。
**缺点：**录制出来的代码会夹杂不少多余操作，缺少完善的断言和封装逻辑，最好借助 AI 或者 Skill 做二次加工，才能成为方便长期维护的测试脚本。
3套 Playwright UI自动化方案
基于上面三大官方能力，结合自研 Skill，我实践了三套UI自动化方案
表格对比 
## 方案 1：Playwright CLI + Skill
思路
针对脚本难写、视觉方案慢、MCP Token 贵等问题，把 CLI + 无障碍树 封装进 Skill：
提供页面 URL + 需求/用例
↓
AI 调 Playwright CLI 采集无障碍快照
↓
生成结构化用例（常见为 JSON）
↓
一键执行 → 失败自愈 / 录屏留证在playwright-cli的基础上，我这边生成了配套实现 UI 自动化的 skill，该方案的所有逻辑都是写在Skill里面，主要有3个主 skill，以及一个辅助 skill，如下：
案例实践
输入： 后台登录页 URL + 「校验账号密码登录成功进入首页」
执行过程： Skill 驱动 CLI 采快照 → 生成用例 → 有头执行
输出： 可复跑的结构化用例 + 执行日志 / 录屏
详细步骤见往期：
基于playwright-cli +Skills实现UI自动化测试实战案例
基于playwright-cli +Skills实现UI自动化测试实战案例2️⃣（附常见问题处理）
方案 2：Playwright Test + CLI + Skill
痛点：
解决方案1在使用过程中存在的问题：由于ref 仅为会话级临时标识，页面一旦发生变更，原有元素引用便会失效，需要重新抓取定位元素，稳定性较差，难以适配常态化自动化执行场景
我的思路：
playwright CLI 负责探路（有头浏览 / 采结构 / 试交互）
↓
把临时引用收敛成稳定定位，并生成 Playwright Test 脚本
↓
playwright Test 负责回归（断言 / 报告 / 并行 / CI）✅ 探索阶段保留 CLI 的速度：不必每改一步就改 spec、整包重跑
✅ 回归阶段切到 Playwright Test：脚本成为可版本管理的工程资产
✅ 临时引用不再直接进回归：探索结束后转为更稳妥的定位写法
✅ 成功率更贴近常态化执行：适合重复跑
探索用 CLI 提效，固化用 Test 保底。两者叠用，而不是二选一。
案例实践
输入： 业务模块 URL + 需求要点 / 手工用例
执行过程： CLI 探路 → Skill 收敛定位并生成 .spec → Playwright Test 执行出报告
输出： 可维护测试代码 + 标准报告 / Trace
详细步骤见往期：基于 Playwright Test + CLI + Skill 实现 UI 自动化实战案例
方案 3：Playwright Codegen + Skill
痛点：
不少测试同学在利用AI进行UI自动化测试的时候，都想要尽可能降低大模型的 Token 消耗，希望能先由人工完成页面操作录制，再交由 AI 基于录制结果生成可执行的自动化脚本。
我的思路：
借助 Playwright codegen 录制能力，让人工操作页面完成流程录制，产出基础录制代码，封装对应的 Skill，对录制代码做优化、补全逻辑，最终得到可以稳定运行的自动化脚本。
人工操作页面（codegen 录制）
↓
产出基础录制代码 / 操作轨迹
↓
AI 生成用例计划 → 优化并生成可执行脚本
↓
执行 → 报告 → 失败则修复重跑案例实践：
输入： 在对话框调用 playwright-codegen skill，并贴上要测试的系统URL
执行过程： 出录制底稿 → 生成计划与优化脚本 → 执行与修复
输出： 用例计划 + 可复跑脚本 + 报告
``
tests/
├── conftest.py # pytest 公共 fixture / Trace 挂报告
├── specs/ # 用例层（一功能模块一文件）
│ ├── test_login.py # TestLogin（TC-001～004）
│ └── test_apartment_management.py # TestApartmentManagement（TC-005～015）
├── pages/ # 页面对象
│ ├── login_page.py
│ └── apartment_management_page.py
├── data/ # 测试数据工厂
│ └── apartment_factory.py
├── helpers/ # 通用工具
│ ├── captcha.py
│ └── trace_support.py
├── fixtures/
│ └── auth.json # 登录态 storage state
│
├── plans/
│ └── login-test-plan.md # 用例计划
│
└── recorded/
└── login.py # codegen 原始录制
``
详细步骤见同期推文：基于 Playwright Codegen + Skill 进行UI自动化测试的实战方案...
小结
随着AI技术的迭代，UI自动化测试的门槛也在慢慢降低，**但是要如何更好利用AI去辅助我们落地，提高效率的同时又能节省成本？**这是很多测试同学的困惑，我这边也一直在持续探索更适配的方案，目前出的几个方案是能解决一些不足的，但是不一定适配所有人，大家可以结合自己的实际情况去选择和优化，Raina主要是提供思路。
三套方案的完整实操步骤、Skill包、落地案例都更新在知识星球，跟着步骤操作就可以上手，学习过程中有疑惑也可以提问，感兴趣的小伙伴可以加入了解哦～