一、简单背景：没有 AI 时的 UI 自动化在做什么、难在哪里
在 Selenium / Appium 为主的时代，UI 自动化本质是 「用代码告诉电脑：’先找到那个按钮，然后点它’」：
听起来简单吧？但”找到那个按钮”这事儿，可比想象的要考虑的多了……
- Web：DOM 结构、动态 class、iframe、跨域、浏览器差异。
- 移动端：系统 WebView、原生混合栈、分辨率与厂商 ROM 差异。
典型困难
| 方面 | 常见痛点 |
|---|---|
| 定位脆弱性 | id/class 随发版变化；列表虚拟滚动导致「第 N 行」不稳定；shadow DOM、Canvas 难以断言。 |
| 等待与同步 | 显式 sleep 堆砌或复杂等待链；网络与动画导致偶发失败。 |
| 环境成本 | Driver 版本、真机/模拟器、CI 镜像与权限；多端要维护两套（甚至多套）工程。 |
| 断言表达力 | 业务语义（「侧栏空态出现」）与底层定位（几十行 locator）脱节，复盘困难。 |
| 维护成本 | 页面一改，成片用例红粉；新人读不懂「为什么当时这么写」。 |
总体上：
“跑一次还行，长期保持不挂？那就难了。而且用例越多，维护成本涨得越凶——不是加法，是乘法。”
二、当下形态：Skill 驱动 + 自然语言 + Playwright
Skill（技能包） 把「谁来测、测什么、怎么问、怎么落地到代码与命令」沉淀成 可被发现、可复用的说明 + 脚本；用户用自然语言触发后，由编辑器中的 Agent 按 skill 约束去：
- 选择 Web / H5 / 原生、新增 / 编辑 / 执行 / 看报告；
- 把场景拆成 可执行步骤与断言；
- 落到 真实仓库里的 Page Object、配置与 spec，而不是一次性临时脚本。
Playwright 的分工
Playwright 承担「稳定、跨浏览器、/trace、html report」的执行层，与 Skill 的分工大致是：
| 层级 | 职责 |
|---|---|
| Skill | 交互流程、模板话术、列表模块与用例、脚手架与打包校验； |
| Playwright | 浏览器自动化、项目结构、CI、报告。 |
相较于「仅录制」或「仅让模型随手写脚本」，Skill 将 工程约束（分层、配置、命名、登录态、多端开关）前置，减少不可维护的野代码。操作流程：
三、实战案例：一个「编辑」按钮的故事
重点：为什么会失败？怎么修正的？
| 踩坑现场 | 传统做法（要折腾多久） | Skill + Playwright 怎么搞定 |
|---|---|---|
「编辑」看着是按钮，其实是链接 <a class="ant-btn"> | 反复试 getByRole('button')、查 AntD 文档、猜是不是版本不一样……半小时起步 | Agent 看 DOM 结构，直接告诉你：”这是个链接按钮，用 getByRole('link', {name: '编辑'})“，一次搞定，还记到 Page 层，下次同类按钮直接复用 |
侧栏弹层误判成弹窗 Drawer ≠ Modal，等不到 .ant-modal-title | 猜是动画没加载完？加 sleep？换定位器？截图对比？越改越乱 | Agent 看到 .ant-drawer-title，直接纠正：”这是 Drawer，不是 Modal”，锚点改成 Drawer + 文案，定位稳了 |
| 配置散落各文件 BASE_URL、登录态、Tab 文案到处写 | 改一处漏三处，环境切换靠”复制粘贴大法” | Skill 引导你填 .env，src/config 统一管理，切环境只改一个变量 |
| Web / H5 两套脚本 | 要么复制一份改改，要么一堆 if (isMobile) 判断 | `TEST_TARGET=web |
这不是”AI 神奇地猜对了”，而是：
- Playwright UI 的 Pick Locator 把真实 DOM 结构摆在眼前
- Agent 理解结构后，告诉你”为什么之前错了、应该怎么改”
- 改完后的经验沉淀到 Page 层和 Skill，下次遇到类似问题秒解
一句话：踩坑 → 理解 → 修正 → 沉淀。下次不用再踩了。
四、应用场景与效能
实践使用场景
| 场景 | 举例场景 |
|---|---|
| 登录流程 | 下单页登录校验，卖家在商详页登录后页面刷新展示，web页面登录后菜单展示，功能按钮鉴权 |
| 表单提交 | 新增用例，商品发布流程，售后申述流程，后台订单处理 |
| 弹窗交互 | 商详、首页弹窗，弹窗点击跳转、弹窗关闭、弹窗频控、弹窗优先级 |
| 列表操作 | 分页逻辑、页面加载、页面按钮展示/点击、列表tab切换 |
| 搜索验证 | 输入关键词验证结果，搜索输入框、搜索中间页展示、搜索结果页 |
| 多端适配 | 移动端提交售后–后台售后处理，一个场景跨端处理 |
开发流程闭环
在编码用例平台需求时，先录制自动化用例作为基准快照，开发完成后进行回放，自动检测修改的组件是否影响了关联页面【References】的样式与逻辑是否正常运行，形成”录制→开发→回放→验证”的闭环，确保新增功能不破坏既有交互。
UI 自动化有效控制了代码变更的影响范围，降低了开发调试时的回归风险。
综合提效汇总
| 维度 | 传统耗时 | Skill + Playwright 耗时 | 提效幅度 |
|---|---|---|---|
| 首次编写 | 30-60分钟 | 5-10分钟 | ↓ 80% |
| 调试定位 | 30-60分钟 | 5-10分钟 | ↓ 85% |
| 维护修复 | 2-4小时 | 10-30分钟 | ↓ 90% |
| 协作参与 | 高门槛 | 低门槛 | PM/QA 可参与 |
| 多端复用 | 两套代码 | 一套代码 | ↓ 50%代码量 |
| 失败复盘 | 30-60分钟 | 5-10分钟 | ↓ 85% |
五、后续发展方向
- 目前 Playwright 的元素定位还是依赖人工 selector，页面 DOM 结构变动时易失效。
未来将评估引入 agent-browser-use 类的 AI 识别 + AI 执行方案：
- 视觉识别 + 语义理解：自动定位页面元素，无需人工维护 selector。LLM 自己看页面、自己定位元素，页面小改不影响
- 全场景覆盖：从测试扩展到所有网页操作（测试、爬虫、数据录入、账号管理、RPA）
- browser-use = LLM 驱动的浏览器智能体：自己会思考、会操作、会适配，有记忆，多模态理解，错误重试。写一句话任务，几分钟搞定，几乎不用调试
这决定了 browser-use 面向 AI 操作浏览器的形式会是 AI 时代的第一份 UI 自动化答卷。
六、结语：前后对比到底改变了什么？
| 场景 | 之前怎么搞 | 之后怎么搞 |
|---|---|---|
| 第一次写用例 | 翻文档找定位器，或者录一遍再手动改代码 | 说一句”测试编辑按钮”，Agent 帮你写到指定目录，不用想放哪儿 |
| 定位失败了 | 靠自己经验排查，解决了也没人知道，下次同事还得从头猜 | Agent 帮你看 DOM，告诉你”这是个链接按钮”，顺便记到 Skill 模式库——下次同类问题秒解 |
| 配置和登录态 | 账号密码写死在代码里，或者散落各文件，改一处漏三处 | Skill 提醒你用 .env，登录态统一存到 storageState——安全又方便 |
| 页面改版了 | 改个 class 名，一堆用例跟着挂，逐个修定位器 | Page 层集中管理定位，改一处全用例生效；spec 只管业务流程，不用操心底层 |
| 非开发同事协作 | 看脚本像看天书，”这行代码干嘛的？” | 用例步骤跟业务话术对齐，PM/QA 能看懂在测什么 |
| Web 和 H5 两端 | 要么两套脚本，要么代码里一堆 if (isMobile) | 同一套 spec，`TEST_TARGET=web |
| 失败后复盘 | 靠注释猜”当时为什么这么写”，日志不够还得靠回忆 | Playwright 自带 trace 和 HTML 报告，每一步截图、DOM、网络请求都有，版本库还能看改动历史 |
核心变化
不是”少写几行代码”，而是：
- 以前：踩坑经验散落在每个人的笔记里，走了就没了
- 现在：踩坑 → 沉淀到 Skill/Page → 下次同类问题秒解
想了解更多转转公司的业务实践，点击关注下方的公众号吧！
声明：来自转转QA，仅代表创作者观点。链接：https://eyangzhen.com/8055.html
