AI测试-06-AI视觉识别接入UI自动化后最常见的误判场景怎么治理
一提到 AI 视觉识别接入 UI 自动化，最容易先想到的是两个好处：
- 复杂页面不再完全依赖脆弱选择器
- 脚本可以用更接近业务语言的方式描述目标元素和页面状态
这些能力确实有价值，尤其是在下面几类场景里：
- 页面结构频繁变动，传统定位器维护成本很高
- 画布、低代码页面、复杂组件区块难以稳定挂语义属性
- 需要把视觉状态一起纳入断言，而不是只看 DOM
- 希望把自然语言步骤和 UI 自动化执行链路连起来
但 AI 视觉识别一旦真的进入回归体系，最先暴露出来的通常不是“能不能识别”，而是“会不会误判”。
误判一旦进入回归链路，影响会比普通定位失败更复杂：
- 不是直接报错，而是点错元素后继续往下跑
- 不是完全识别不到，而是识别了一个很像但不该点的目标
- 不是每次都错，而是在特定分辨率、特定主题、特定加载阶段才错
- 不是单纯脚本问题，而是页面状态、截图时机、模型阈值、环境差异叠加出来的结果
这也是 AI 视觉识别和传统 UI 自动化最大的治理差别之一。
传统定位失败通常更显性，元素找不到就会直接停住；视觉误判则更像一种“带偏航的成功”，表面上动作执行了，实际上现场已经被改坏。
所以这篇文章不写泛泛的视觉 AI 介绍，只回答一个更实际的问题：
AI 视觉识别接入 UI 自动化之后，最常见的误判场景有哪些，应该怎么做分层治理、证据留存和持续收敛。
一、先把误判边界说清：误判不只是“识别错了”
在 UI 自动化里，视觉识别误判至少可以分成 4 类：
- 目标识别错
- 页面状态判断错
- 时机判断错
- 结果断言错
这 4 类误判看起来都像“AI 没识别准”，但治理手段并不一样。
1. 目标识别错
最典型的是把视觉上相近的元素认成目标元素，例如：
- 把“保存”识别成“提交”
- 把顶部主操作按钮识别成弹窗里的同名按钮
- 把主列表里的“删除”识别成浮层菜单里的“删除”
- 把灰态按钮识别成可点击按钮
这类问题的本质不是完全没看见，而是候选目标太多、约束条件不够。
2. 页面状态判断错
例如：
- 还在骨架屏阶段，就被识别成页面已加载完成
- 弹窗还没完全打开，就被识别成可交互状态
- 列表还在局部刷新，却被判断成页面稳定
- 登录超时后的重定向页，被识别成原业务页
这类问题往往不是元素层误判，而是页面阶段判断错了。
3. 时机判断错
例如：
- 页面动画还没结束就开始点
- 异步数据还没回填就开始断言
- 首屏截图抓到过渡帧
- 懒加载区域还没滚进视口就开始识别
这类问题在本质上更接近“执行窗口错了”，不是视觉模型本身理解错了页面。
4. 结果断言错
例如：
- 把提示条一闪而过的旧文案识别成最终结果
- 把列表局部刷新前的旧状态识别成断言结果
- 把视觉上成功的按钮状态当成业务成功
- 把截图里显示“提交成功”当成后端写入成功
这一类最危险，因为它已经不是单点点击误判，而是把错误结果写进了测试结论。
所以视觉识别接入 UI 自动化以后，首先要做的不是继续堆更多视觉能力，而是先建立统一的误判分层。
二、误判分层：先知道误判发生在哪一层，再决定怎么治
更适合落地的做法，是把误判按 5 层来看：
- 环境层
- 页面层
- 识别层
- 执行动作层
- 断言层
1. 环境层误判
这类问题不是模型本身出了问题，而是输入给模型的视觉现场本来就不稳定，例如：
- 浏览器缩放比例不一致
- 分辨率、DPI、字体渲染不一致
- 系统主题、语言、时间格式不一致
- 测试环境数据不同，页面布局发生变化
- 执行机性能波动导致渲染时机不同
环境层不收稳，视觉识别误判会一直呈现“偶发”和“难复现”的特征。
2. 页面层误判
这类问题发生在页面还没有进入可识别状态之前，例如：
- 骨架屏和真实内容混在一起
- 弹窗遮挡主页面
- toast、引导气泡、全局 loading 影响截图
- 滚动位置不一致导致目标不在稳定区域
这时即使视觉模型能力提升，误判也不会根本消失，因为页面本身还没达到适合识别的阶段。
3. 识别层误判
这一层才是最容易先想到的“模型识别错”：
- 候选区域选错
- 同名目标歧义大
- 相似样式过多
- 阈值设置不合理
- 语义描述太抽象
识别层误判需要用更明确的上下文、更窄的候选范围和更稳定的目标描述去收。
4. 执行动作层误判
有时候模型其实识别对了，但动作执行阶段又把结果带偏，例如：
- 点击坐标落点偏移
- 滚动后元素位置变化，但动作沿用旧坐标
- 识别结果是容器，执行动作却点击到容器边缘空白区
- 页面重排后，旧定位快照已经失效
这类问题看起来像识别错，实际上是视觉结果到自动化动作之间的收口不完整。
5. 断言层误判
最后一层是结果判断问题：
- 只看视觉提示，不校验真实状态
- 只看页面局部，不看链路结果
- 把一次偶然可见的文案当成稳定结果
- 视觉断言通过，但接口或数据库状态没变
断言层如果没有补双重校验，视觉自动化就很容易变成“截图看起来没问题，但真实业务状态已经偏了”。
三、治理骨架：不要把误判治理理解成只调 prompt 或阈值
AI 视觉识别接入 UI 自动化后的误判治理，更适合拆成一套固定骨架：
- 先稳输入
- 再缩候选
- 再加前置判断
- 再收动作结果
- 最后补双重断言和证据链
1. 先稳输入
视觉识别要先稳定输入现场，而不是先优化模型提示词。至少要先统一：
- 浏览器窗口大小
- 缩放比例
- 主题与语言
- 字体和系统渲染差异
- 截图触发时机
- 滚动定位策略
如果这一步不做，后面的误判治理很容易变成“某台机器好、某台机器坏”的随机修补。
2. 再缩候选
不要一上来就让模型在整页里找一个模糊目标。更合适的做法是：
- 先缩到页面区域
- 再缩到功能模块
- 再缩到操作分组
- 最后才做目标识别
例如寻找“提交订单”按钮时，更稳的路径通常是：
- 先确认当前页是订单确认页
- 再确认右侧提交区域已出现
- 再在提交区域内找主要动作按钮
- 再判断按钮是否可点击
这样可以显著降低同名按钮和干扰元素带来的误判。
3. 再加前置判断
视觉识别接动作前，最好先过一层页面可执行判断，例如：
- 当前页面标题或关键区域是否稳定
- loading 是否消失
- 弹窗是否已关闭或已完全展开
- 目标区域是否已经进入视口
- 页面是否存在遮挡层
这一层的目标不是替代视觉识别，而是先把“明显不该识别的窗口期”排掉。
4. 再收动作结果
AI 视觉识别找到目标之后，不应该直接把“已执行”当成“已成功”。
更稳的收口方式是每个动作执行后都要求返回结构化结果，例如：
- 命中了哪个候选区域
- 点击前后的截图
- 实际动作坐标
- 动作完成后的页面变化
- 是否进入预期下一状态
只有把动作结果收口，后面才能判断问题到底发生在识别、执行还是页面状态变化上。
5. 最后补双重断言和证据链
视觉结果最好不要单判。
更稳的方式通常是：
- 视觉断言 + DOM 断言
- 视觉断言 + 网络请求断言
- 视觉断言 + URL/路由断言
- 视觉断言 + 后端状态断言
这样可以显著降低“页面看起来像成功，其实业务没成功”的结果误判。
四、最小可执行治理方案：先把视觉自动化收成一条受控链路
如果当前已经准备把 AI 视觉识别接入现有 UI 自动化体系，第一版更适合采用下面这条最小落地路径。
1. 只挑高收益场景接入
不要一开始全量替换传统定位器。更适合优先接入的通常是：
- 低代码页面、组件树复杂页面
- 传统定位器改动频繁的流程
- 明显依赖视觉状态的断言场景
- 需要快速验证页面布局或视觉反馈的场景
不适合第一批就接入的通常是：
- 高危业务写操作
- 对结果一致性要求极高的核心支付链路
- 完全可以稳定使用语义定位器的简单场景
- 页面过于动态、渲染极不稳定的实验页面
2. 用增强层接入，而不是替换层接入
第一版最稳的做法，通常不是“视觉识别替代现有 UI 自动化”，而是：
- 原有选择器仍然保留
- 视觉识别只处理传统方式不稳定的步骤
- 关键步骤允许视觉识别失败后降级到传统定位
- 高风险步骤必须保留保守模式
增强层接入的价值在于：
- 降低全链路风险
- 可以做同场景 A/B 对比
- 容易识别误判到底来自视觉层还是业务层
- 回退成本低
3. 固定执行顺序
一条视觉步骤更适合固化为：
- 页面稳定检查
- 目标区域定位
- 视觉识别
- 候选校验
- 执行动作
- 动作结果确认
- 双重断言
- 证据写回
顺序固定之后，误判排查才能有统一抓手。
4. 固定记录表
每次视觉步骤都至少记录：
- 任务 ID
- 页面名称
- 动作名称
- 目标描述
- 截图时间
- 环境信息
- 识别候选数
- 最终命中区域
- 动作结果
- 后续断言结果
- 证据路径
这张表的价值不是为了留档，而是为了后续做误判聚类和趋势治理。
五、证据链设计：没有证据链，就没法谈误判治理
AI 视觉识别接入 UI 自动化之后，证据链必须比普通 UI 自动化更完整。
因为误判本身往往不是一个单点报错，而是一段逐步偏航的过程。
更适合保留的证据至少包括：
- 动作前全页截图
- 目标区域裁剪图
- 候选区域列表和排序
- 最终命中区域标记图
- 动作前后页面截图对比
- 页面 URL、路由或关键状态值
- 控件树或 DOM 快照
- 控制台日志和网络摘要
- 失败后录屏片段
如果条件允许，再补两类证据会更有价值：
- 模型输入的目标描述与上下文
- 模型输出的候选解释和置信信息
证据链设计的关键不是“多存点东西”，而是让后续排查能回答下面这些问题：
- 当时页面真的稳定了吗
- 候选目标是不是本来就有歧义
- 模型有没有把错误目标排在第一
- 动作有没有点到候选区以外
- 点完之后页面有没有进入预期状态
- 这次失败是模型识别错、动作执行错，还是断言链路错
只有这些问题都能被证据链回答，误判治理才不是凭感觉调参数。
六、最常见的 6 类误判场景
1. 同名按钮误判
页面里同时存在多个“保存”“提交”“确认”，视觉识别只按文字匹配，最容易点错。
治理重点：
- 先收区域，再找目标
- 给目标加业务语境描述
- 明确主按钮、弹窗按钮、列表按钮的层级边界
2. 骨架屏与真实页面混淆
骨架屏、占位块、半透明 loading 最容易被错误识别成页面内容。
治理重点：
- 引入“页面稳定”前置判断
- 在截图前确认关键区域已出现真实文本或真实控件
- 把过渡态识别成不可执行状态
3. 弹窗遮挡导致误判
弹窗、引导层、toast、权限框最容易遮挡主页面目标。
治理重点：
- 执行动作前先做遮挡检查
- 弹窗与主页面动作分层
- 有全局浮层时禁止继续识别主页面目标
4. 暗色主题、缩放比例、字体差异导致误判
这类问题通常在线下不明显，但一接入 CI 或远程执行机就开始出现。
治理重点：
- 执行环境标准化
- 固定窗口与缩放比例
- 固定主题与语言
- 把环境信息写进证据链
5. 滚动后目标漂移
识别时目标在视口里，动作执行前页面又滚动或重排，导致点击落点偏移。
治理重点：
- 识别和动作之间不要隔太多步骤
- 滚动完成后重新确认目标区域
- 动作前重新校验候选区域是否仍然有效
6. 视觉通过但业务未通过
最典型的是看到“提交成功”就判通过，但后台实际没写成功。
治理重点：
- 关键流程必须补网络、接口或数据库侧断言
- 页面成功提示只作为辅助证据，不作为唯一结论
- 最终结果必须回到业务状态上确认
七、常见坑：误判治理最容易做偏的地方
1. 把误判问题全部归到模型能力上
实际现场里，环境波动、页面状态、动作收口和断言设计往往同样关键。
2. 只统计成功率，不统计误判类型
如果报表里只有“通过 / 失败”，就很难知道到底是：
- 识别错
- 动作错
- 页面状态错
- 断言错
误判治理要能按类型聚类，才能知道先修哪一层。
3. 没有降级路径
一旦视觉识别失败，脚本就整个失败，或者反过来继续瞎点，都会让链路变脆。
更稳的方式是按步骤设置：
- 可降级
- 不可降级
- 必须人工确认
4. 只留失败截图，不留候选过程
最后只保留一张失败截图，往往根本看不出问题发生在哪个阶段。
5. 误判出现后只调阈值
阈值调整当然有用，但如果根因在页面时机、环境差异或断言链路，单纯调阈值只会把问题拖到下一轮。
6. 视觉步骤和传统自动化步骤混写，没有独立标识
一旦混在一起，后续就很难从报告里看出到底是传统定位失败还是视觉识别偏航。
八、真实案例：一次“识别成功但步骤全错”的误判是怎么收回来的
场景
一个后台运营页面需要执行“筛选订单 -> 打开详情 -> 审核通过”这条回归流程。
列表区有多个“审核”入口，右侧还会弹出详情抽屉，抽屉底部也有“审核通过”按钮。
传统定位器在这个页面经常因为低代码组件重排失效，因此接入了 AI 视觉识别。
执行
回归脚本按下面顺序执行：
- 打开订单列表页
- 输入筛选条件
- 在列表区域识别“审核”按钮并点击
- 等待详情抽屉出现
- 识别“审核通过”按钮并点击
- 断言页面出现“提交成功”
现象
报告显示脚本执行成功，但第二天复核业务数据时发现：
- 目标订单状态没有变化
- 页面里出现过“提交成功”
- 日志里没有真正的审核接口调用
这说明视觉步骤没有直接失败，而是走成了一条错误路径。
排查
排查按固定顺序展开：
- 先看动作前后截图，发现第一次点击命中的不是列表区主按钮，而是页面顶部筛选栏旁边的快捷操作按钮。
- 再看候选区域记录，发现“审核”这个目标在整页里被识别出了 4 个候选，但脚本没有先收窄到列表区域。
- 再看动作结果截图，发现第一次点击后页面并没有打开详情抽屉，而是弹出一个轻量提示框。
- 再看第二次识别过程，脚本把提示框里的“确认”路径当成了详情页里的“审核通过”路径。
- 最后看网络摘要，整个过程没有出现目标审核接口，只触发了一次无关的快捷操作请求。
修复
最终修复没有只调识别阈值，而是同时收了 4 件事：
- 先把第一次识别限制在列表区域，不再允许整页搜索“审核”
- 点击后增加“详情抽屉已展开”的前置断言，没有出现抽屉就不允许进入下一步
- 把“提交成功”从唯一断言改成“页面提示 + 审核接口返回 + 订单状态变化”三重断言
- 把候选区域列表、命中区域标记图和动作后页面截图写入证据链，后续误判可直接复核
修完之后，同类页面的“视觉识别成功但业务路径错误”问题明显下降，后续再出现类似问题时，也能在报告里更快看出是候选收窄问题、页面状态问题还是断言问题。
九、收尾：视觉识别真正难的不是第一次跑通，而是误判能不能被工程化治理
AI 视觉识别接入 UI 自动化之后，真正决定它能不能进入长期回归链路的，通常不是第一次演示是否惊艳，而是误判出现后有没有办法快速回答这些问题：
- 误判发生在哪一层
- 这次偏航是环境问题、页面问题、识别问题还是断言问题
- 有没有足够证据支持复核
- 能不能在不放大风险的前提下做降级、回退和收敛
所以更合适的落地方向通常不是：
- 继续堆更大的模型
- 继续放宽更自由的目标描述
- 继续把更多关键路径直接交给视觉识别
而是先把下面这些基础能力收稳：
- 误判分层
- 页面稳定判断
- 区域收窄
- 动作结果收口
- 双重断言
- 证据链留存
- 误判趋势治理
只有这些基础能力先收稳，AI 视觉识别才更有机会从“看起来很聪明的辅助能力”，变成“真正能进入 UI 自动化主链路的工程能力”。