最近一直在思考 AI / LLM 在 UI 自动化测试里的落地方式。
如果把现有方案粗略归类，我觉得基本可以分成三类：
- 视觉方案
- RAG / Knowledge Base 方案
- LLM + DOM / 对象树方案
这三类方案各有优势，也各有明显短板。很多时候不是谁替代谁，而是适合解决的问题不同。
1. 视觉方案
视觉方案最直观：把当前界面截图给模型，让模型像人一样“看屏幕”，再根据任务目标决定下一步点击哪里、输入什么。
典型输入是：
截图 + 用户目标
比如：
请完成登录流程
请找到充值入口
请判断当前页面是否有错误提示
视觉方案的优点很明显：
- 不依赖 DOM 或控件树
- 对游戏、远程桌面、原生客户端更通用
- 更接近人类真实使用软件的方式
- 对 WebView、Canvas、Unity、Qt 这类场景更友好
但问题也很明显。
第一，纯视觉定位不稳定。模型知道“按钮大概在右下角”，但真正要点击时，需要把语义映射成准确坐标。这个过程容易受分辨率、缩放、遮挡、动画影响。
第二，视觉方案很难理解隐藏状态。比如一个按钮是不是 disabled、一个元素是不是可点击、一个弹窗是不是阻塞主流程，单靠截图不一定可靠。
第三，长流程成本高。每一步都截图、识别、推理，延迟和 token 成本都会上来。
所以我觉得视觉方案更适合作为“兜底能力”或“跨端泛化能力”，尤其适合 DOM / 对象树拿不到的场景。但如果有结构化信息，完全只靠视觉并不是最优解。
2. RAG / Knowledge Base 方案
第二类是 RAG 或 Knowledge Base。
它的核心思路不是让 LLM 每次从零探索页面，而是把已有自动化资产、测试用例、页面知识、业务流程沉淀下来，需要执行任务时先检索相关知识，再让 LLM 基于这些上下文生成步骤或判断。
典型输入是：
用户目标 + 检索到的历史用例 / 页面知识 / 业务文档
这种方案的优点是：
- 对业务流程理解更强
- 能复用历史自动化资产
- 更适合复杂业务系统
- 可以把隐性知识显式沉淀下来
- 对回归测试、用例生成、影响分析很有价值
但它有一个前提：必须有历史资产。
如果团队本来就没有足够的自动化用例、页面说明、业务文档、操作日志，那么 RAG 很容易变成“空库检索”。没有知识沉淀，RAG 就只能检索到一些泛泛的内容，最后还是靠 LLM 猜。
这也是很多 RAG 自动化方案落地时的问题：
方案看起来很完整，但知识库里没东西。
或者：
有文档，但文档和真实系统不一致。
所以 RAG / Knowledge Base 更适合已经有一定测试积累的团队。它不是凭空生成能力，而是放大已有资产的价值。
我理解它更像一个“经验增强层”：
- 过去怎么测
- 哪些页面有哪些入口
- 哪些流程容易失败
- 哪些字段有特殊规则
- 哪些断言是业务关键点
这些东西沉淀得越好，RAG 的效果越好。
3. LLM + DOM / 对象树方案
第三类是 LLM + DOM / 对象树。
Web 场景里是 DOM、Accessibility Tree；Unity 里可能是 Poco 树；Android 是 UIAutomator 层级；iOS 是 Appium / XCTest 树；Windows 是 UIA 树。
它的核心思路是：不要只给模型截图，而是把当前界面上的可交互元素结构化给模型。
比如：
[1] 登录按钮 button enabled
[2] 手机号输入框 input empty
[3] 密码输入框 input empty
[4] 忘记密码 link
然后让 LLM 根据任务选择动作：
click element 1
input element 2: xxx
这种方案的优势是工程上更可控：
- 元素有 ID 或路径，方便点击
- 可以知道控件类型、文本、状态
- 比纯视觉更容易做动作落地
- 更容易记录、回放和调试
- 更适合和传统自动化框架结合
但它的问题也不少。
第一，对象树质量不稳定。Web DOM 很丰富，但可能有大量无意义节点；Unity / 游戏 UI 的对象树可能命名混乱；原生客户端控件树也可能拿不到完整信息。
第二，结构化信息不等于用户看到的信息。有些元素在树里存在，但被遮挡了；有些元素 visible=true，但用户根本点不到；有些 WebView 或 Canvas 内容，树里完全没有。
第三，LLM 依然需要做语义理解。对象树只是告诉模型“有什么”，但不一定告诉它“业务上应该点哪个”。比如页面上有多个“确认”按钮，如果没有业务上下文，模型也会犹豫。
所以 LLM + DOM / 对象树的方案更像是当前最实用的主干方案：
结构化元素负责可控执行，LLM 负责语义决策。
三类方案的对比
简单对比一下：
| 方案 | 优点 | 短板 | 更适合 |
|---|---|---|---|
| 视觉 | 通用，跨端强，不依赖结构 | 坐标不稳定，状态理解弱，成本高 | 游戏、远程桌面、Canvas、兜底识别 |
| RAG / KB | 复用历史经验，业务理解强 | 依赖历史资产，知识维护成本高 | 回归测试、用例生成、复杂业务流程 |
| LLM + DOM / 对象树 | 可控、可执行、易调试 | 树质量不稳定，缺少业务语义 | Web、App、桌面端主流程自动化 |
我的判断是：单一方案都不够。
真正可落地的 AI 自动化，很可能是三者组合：
LLM + 对象树作为主路径
视觉作为补充和兜底
RAG / Knowledge Base 提供业务上下文
也就是：
- 先从对象树里拿到可交互元素。
- 用 RAG 找到历史流程、页面说明、业务规则。
- 让 LLM 结合任务目标和上下文决策。
- 如果对象树缺失、点击失败、页面异常，再用视觉能力兜底。
我更看好的方向
我目前更看好“LLM + 对象树 + 少量视觉 + 业务知识”的混合方案。
原因很简单：
- 纯视觉太不可控。
- 纯 RAG 太依赖历史资产。
- 纯对象树又缺少业务理解和视觉补偿。
混合方案虽然工程复杂，但更符合真实 UI 自动化环境。
尤其在复杂业务系统里，LLM 不应该只回答“点哪里”，还应该理解：
- 当前页面是不是符合预期
- 这个操作是不是业务上合理
- 失败时应该重试、回退还是换路径
- 哪些断言才是真正有价值的
这就不是单纯的视觉识别或 DOM 解析能解决的了。
结论
AI + LLM 做 UI 自动化，不是简单地把 Selenium 脚本换成自然语言，也不是把截图丢给大模型就结束。
我更倾向于把它拆成三层能力：
感知层：视觉 / DOM / 对象树，解决“当前界面有什么”
知识层：RAG / Knowledge Base，解决“历史上怎么做、业务上怎么理解”
决策层：LLM，解决“下一步应该做什么”
这三层结合起来，才更接近一个能落地的自动化 Agent。
短期看，LLM + DOM / 对象树会是主流工程路线；视觉会成为跨端和异常场景的补充；RAG / Knowledge Base 则决定它能不能真正理解复杂业务。