最近面试听了不少 AI 做 UI 自动化的案例，
经常给我一种感觉：他们聊的测试，和我干的测试，好像是两个工种。
当然我是明白的——很多分享描绘的是一幅理想画卷，而大多数测试人每天面对的是另一幅现实图景。
我把这两个画面对比着列出来，聊些实话。
理想：AI 用自然语言驱动测试，不再需要写选择器，维护成本趋近于零
现实：UI 本身就在不断变化，异步渲染、动态 ID、环境差异、A/B 实验，这些是 UI 测试不稳定的根本原因。
AI 引入后非但没有解决这些问题，反而增加了一层 “视觉模型猜控件” 的不确定性。
实际上，UI 自动化测试的 flaky 问题在行业里长期存在，Google 等公司曾公开过其内部 UI 测试的随机失败率居高不下的问题。
把 “不稳定” 交给另一个黑盒模型去理解，结果往往是更不稳定，而且排障路径更长。
理想：AI 测试能够自愈，遇到 UI 变化时模型会自动适应
现实：自愈能力只在非常有限的范围内生效，比如按钮文案从 “登录” 变成 “Sign in”。
一旦涉及布局重构、组件替换、弹窗层级变化，视觉模型的自愈就会失效。
真实项目中，UI 组件的重构远比改文案常见。真正的自愈需要稳定的契约，但大多数 PPT 分享中刻意避开了这一点——因为一旦需要契约，所谓的 “零维护” 就不存在了，维护成本只是从前端选择器转移到了契约维护，加上模型调用的不确定性，成本反而更高。
理想：低成本接入，几行代码即可集成到 CI，快速见效
现实：企业级回归动辄成百上千条用例，一条用例可能多次调用模型（截图、分析、断言）。以公开的 VLM API 价格计算，单次调用可能花费几分钱，看似不贵，但数千次调用叠加，每轮回归的成本瞬间变成数十甚至上百元。
如果 flaky 导致重跑，成本翻倍。这还不算模型响应时间带来的 CI 时长膨胀。那些 “低成本” 的论证，几乎都建立在只有几条 Happy Path 的 Demo 上，从来没有在核心回归集上跑过一个完整的成本核算。
理想：多 Agent 协同，自动完成测试设计、执行、分析、报告
现实：大部分测试团队的痛点根本不是 “没有自动设计用例的工具”，而是测试环境不稳定、数据构造复杂、账号权限混乱、Mock 服务缺失。这些基建问题没解决，Agent 再多也只是在空中楼阁上跳舞。很多演示项目用的是静态假数据、固定账号、干净环境，完美避开了真实测试中的所有脏活累活。而这些脏活累活，才是真正占据测试工程师时间的地方。
理想：AI 测试是普惠的，任何团队都能开箱即用，快速提效
现实：真正落了生产还跑得稳的案例，绝大多数来自拥有自研模型、自建平台、专门合规团队的大厂。他们可以把模型部署在内部，截图不出网，数据全脱敏，审计全链路。而大多数公司的现实是：调用外部 API 有合规风险，数据出网审批过不去，截图里的用户信息无法自动脱敏，信息安全部门直接一票否决。这些方案从 “能跑” 到 “能上线”，中间的鸿沟根本不是几行代码能填平的。
最后说点个人的观察。
我不是不看好 AI 这个方向。我自己也试了，Demo 确实跑得比我手写快，这点没得黑。
但我发现一个规律：一个方案如果只能存在于探索项目和边缘系统里，那它对绝大多数一线测试同学来说，就是没用的。
真正有用的方案，敢把数据亮出来：在多少条真实回归上跑了多久？通过率多少？重跑率多少？单次成本多少？平均排障时长多少？合规审计怎么过的？
当然挺多人喜欢把 Demo 叫做 “生产级方案”，把理想包装成现实，然后用一句 “你们不跟上就淘汰” 来堵住所有质疑的嘴。
UI 本来就不稳定，AI 只是把不稳定变贵。 这句话，送给所有还在纠结要不要跟风的一线测试同学。