工作 16 年，其中测试做了 9 年。最近一直在琢磨怎么把 AI 用到 UI 自动化里。
起因有两个。一是这阵子 AI 测试很火，我自然会想：它能不能真的帮上我手里的活？二是实在忙不过来，最多的时候 4 个项目并行跑，手工点测根本跟不上。AI 到底能不能提效，这个问号就落到了我头上，于是我开始自己动手试。
网上看到的演示大多是「一句话生成用例，自动跑完」，看着很爽。但我自己试下来，最头疼的不是 AI 不会点，而是它点完了，你不知道这个结果能不能信。所以这篇不讲具体实现，只说说我现在脑子里的分层和几个取舍，想听听大家的意见。
我现在大致按下面这张表来分：
| 层 | 做什么 | AI 参与吗 |
|---|---|---|
| 用例输入 | 自然语言或录制 | 可参与 |
| 理解与定位 | 怎么找到元素、怎么点 | 主要在这 |
| 执行 | Playwright 之类真正跑起来 | 一般不改 |
| 程序断言 | 点完应该是什么样 | 不碰 |
| 证据 | 截图 / 视频 / 日志 | 不碰内容，只按规则留证 |
| 修复建议 | 失败后给改法 | 可提建议，合入前人工审 |
整条线里，我守得最死的是这一条：AI 可以改「怎么点」（定位、路径、等待），不能改「点完应该是什么样」（断言和预期值）。 断言失败后如果让 AI 去改断言，测试就从「检查产品」变成了「迁就产品」，报告一片绿，问题还在。所以修复建议里只要动到断言或预期值，我直接打回，交给人看。
执行通过也不等于业务正确。步骤全跑完、没报错，只能说明脚本没崩。页面对不对，要靠程序断言，而不是让 AI 看一眼截图说「看起来没问题」。断言顺序上，我习惯先 toBeVisible 再 toHaveText——文字在 DOM 里，不代表用户真能看到。我真遇到过：有段说明藏在很小的问号图标后面，要点一下或悬停才出来；人测会顺手去点，Agent 可能根本不点，结果它「看不到」。要是只查文字存不存在，这种情况就漏了。
证据层也有个小规矩：关键截图放在断言通过之后再截。步骤一结束就截，那一刻页面可能还在加载，图和结论对不上。另外 passed 和 passed_on_retry 要分开记——重试才过的和一次就过的混在一起，通过率好看，不稳定的用例全被藏起来了。
还有一点：整条流水线不能依赖模型一直在线。模型挂了，就退回已经固化的脚本照常自动执行，失败的交给人修。AI 是加速，不是前提。
我还没想清楚两件事：自然语言用例要写多细，AI 才能稳定定位——写粗了它会猜，写细了又和直接写脚本差不多；修复建议要人工审核，怎么审才不会变成新瓶颈。这两块有一些尝试，整理清楚了再单独写。
最后想问问做 UI 自动化的朋友：你们让 AI 改过测试脚本吗？有没有遇到它「顺手」改了断言或预期值的情况？你们是怎么拦的？