UI自动化到底怎么AI化

这套方案说白了，就是把人操作网页的常识，翻译成系统能理解的数据结构我们点开弹窗后，会在弹窗里继续点，不会点底下我们跳新页面后，会找新页面上的元素，不会找旧的我们走错路了，会看看现在在哪，重新想接下来怎么走，不会从头再来就这么简单。把常识变成代码，稳定性自然就上去了。先给页面建模，再给动作加语义，关键节点重新感知，错了局部重规划。欢迎交流讨论，有更好的思路也请留言告诉我。

PIGnunu

12人浏览 · 2026-03-26 18:53:06

PIGnunu · 2026-03-26 18:53:06 发布

实战：解决 AI 自动化痛点 —— 动态页面稳定性提升 40% 的方案

做 AI 驱动自动化测试的同学，一定都被这个问题折磨过：为什么一到动态页面就GG？

灵魂拷问

你的 AI 自动化是不是也这样：

操作	结果
点一下弹窗	AI 继续点弹窗底下的按钮，被遮罩挡住点不到 ❌
提交表单跳页	旧页面元素全失效，AI 还抱着旧选择器不放 ❌
切换 Tab	原区域 DOM 被替换了，找不到元素 ❌
登录成功刷新	导航栏全变了，AI 一脸懵逼 ❌
筛选条件更新	表格按钮位置变了，点错地方 ❌

运行 10 次失败 5 次，其中 3 次都是因为页面状态变了。

这到底是为什么？

问题根源：你的 AI 还在用静态思维走一步看一步

目前绝大多数 AI 自动化系统，工作流程还是这样：

1. 打开页面 → 一次性分析所有元素
2. AI 把元素拼成一串线性步骤
3. 执行器严格按顺序点，不管页面怎么变

这种**“一次性分析，线性执行”**的模式，在静态页没问题，但在动态页就是找死。

核心问题：系统没有"页面状态"这个概念。

用户点一下，页面状态就变了。后续步骤得按新状态走，但你的 AI 还拿着旧状态的元素清单瞎找，能不失败吗？

问题	本质
弹窗出来了还点底层	不知道弹窗出现后底层元素不可点击
跳转了还找旧元素	不知道跳转后旧页面已经没了
切 Tab 还找原位置	不知道切 Tab 后 DOM 已经替换了

不是 AI 视觉识别不准，也不是选择器写得不对，是从根上就缺了状态建模这一环。

解决方案：把系统从"元素驱动"改造成"状态驱动"

我们在实际项目中重构了这套逻辑，把系统升级成了状态驱动的四层级架构：

┌─────────────────────────────────┐
│ 第一层：感知层                    │
│ → 执行关键动作后，重新抓取状态快照  │
├─────────────────────────────────┤
│ 第二层：规划层                    │
│ → AI 基于状态生成，不是瞎拼元素     │
├─────────────────────────────────┤
│ 第三层：校验层                    │
│ → 组合模块时提前检测状态冲突        │
├─────────────────────────────────┤
│ 第四层：恢复层                    │
│ → 错了只做局部重规划，不重头再来   │
└─────────────────────────────────┘

第一步：给当前页面拍一张「状态快照」

首先，你得让系统能说清楚"当前到底是什么状态"。我们定义了这些核心字段：

字段	说明
`url` + `title`	当前页面地址
`page_summary`	AI 总结的页面内容
`interactive_elements`	当前可见的可交互元素列表
`visible_regions`	有哪些区域：主页面/弹窗/抽屉/浮层
`active_tab`	当前激活的 Tab
`modal_open`	是否有弹窗
`auth_state`	登录状态
`filter_state`	筛选/排序/分页信息
`dom_signature`	页面结构指纹，判断是否变化

有了这个快照，系统才真正知道"我现在在哪儿"。

第二步：让每个动作都带上「状态语义」

原来的动作就是一个 click("#submit")，现在要补全状态上下文：

{
  "required_state": "弹窗已打开，在登录表单中",
  "action": "点击登录按钮",
  "produced_state": "登录成功，跳转首页",
  "invalidated_elements": ["登录页所有元素"],
  "risk_level": "高",
  "recovery": "失败返回登录页重试"
}

每个动作必须回答四个问题：

我需要在什么状态下才能执行？
执行完会把页面变成什么状态？
哪些旧元素会因为这个动作失效？
失败了该怎么恢复？

第三步：把可复用模块改造成「状态安全模块」

原来的模块只是"步骤集合"，现在升级成有输入输出状态的可复用单元：

每个模块必须声明：
┌───────────────────┐
│ required_state    │ ← 我需要什么状态才能进
├───────────────────┤
│ produced_state    │ ← 我出去的时候变成啥状态
├───────────────────┤
│ invalidated_elements ← 我会干掉哪些旧元素
├───────────────────┤
│ risk_level        │ ← 我这个动作风险有多高
├───────────────────┤
│ recovery_strategy ←  失败了怎么救
└───────────────────┘

这样做有什么好处？当你把多个模块拼成一个完整场景时，系统可以提前检查：

上一个模块产出的状态，正好匹配下一个模块需要的状态吗？

第四步：组合场景时，提前做「状态冲突检测」

很多问题不需要等到执行，在组合阶段就能发现。我们第一版就识别了这五种典型冲突：

冲突类型	场景
遮罩冲突	上一步打开弹窗，下一步操作底层 → 肯定点不到
跳转冲突	上一步已经跳转，下一步还用旧元素 → 肯定找不到
Tab 冲突	上一步切了 Tab，下一步还找原 Tab → DOM 都没了
表单冲突	上一步提交了，下一步还操作输入框 → 页面都走了
登录冲突	上一步切了账号，下一步还按老权限找 → 菜单都变了

提前发现冲突，比跑一半失败强一万倍。

第五步：高风险动作后，必须「重新感知」

哪些算高风险动作？只要可能改变页面整体结构的，都是：

页面跳转
表单提交
打开弹窗/抽屉
切换 Tab
切换登录账号
刷新/重载

执行完这些动作，必须停下来重新抓一次状态快照，然后和预期对比：

对比结果	处理方式
✅ 符合预期	继续往下走
⚠️ 轻微偏移	调整元素定位，继续走
❌ 未知状态	触发局部重规划

第六步：出错了别重头再来，做「局部重规划」

以前的处理方式很粗暴：只要一步错，整个流程全重跑。前面做的工作全白费，慢得要死。

现在呢？进入未知状态后，只给 AI 发这些信息：

输入给 AI：
- 当前页面的状态快照
- 当前能看到的所有元素
- 哪些步骤已经做完了
- 我们最终目标是什么
- 哪些元素已经失效了
- 刚才失败原因是什么

AI 只需要输出剩余路径的修正方案：

AI 输出：
- 从当前状态到终点，需要改哪几步
- 用哪些新元素代替失效的
- 要不要回退到上一步
- 是不是直接终止更合适

这样，90% 的情况只需要改两三步就能继续，不用从头再来。

落地指南：不推倒重来，五步渐进式重构

这个方案不需要你把现有系统删掉重写，我们是分阶段落地的：

第一阶段：先把数据结构补全（P0）

做什么：

新增状态相关的 Schema 和模型字段
扩展前后端接口，让状态能传能存
前端加上状态展示的位置

验收： 状态字段能在前后端正常流转就行，不要求有智能逻辑。

第二阶段：让 AI 生成时就带状态信息（P0）

做什么：

分析页面时生成状态摘要
改 Prompt，让 AI 生成模块时输出前置/产出状态
场景组合时加上基础冲突检测

验收： 新生成的模块都有 required_state 和 produced_state，能识别明显冲突。

第三阶段：给执行器加上重新感知（P1）

做什么：

在执行器里加判断：高风险动作后重新抓快照
对比预期状态和实际状态
把状态变化记到执行日志里

验收： 能区分"预期/偏移/未知"三种情况。

第四阶段：实现局部重规划（P1）

做什么：

新增局部重规划接口
未知状态自动触发
前端展示重规划过程

验收： 出错触发重规划后，能修正几步继续执行。

第五阶段：做效果量化统计（P2）

做什么：

统计：多少失败是状态变化导致的
统计：重规划成功率有多少
评估：改造前后稳定性对比

验收： 能说出改造后提升了多少。

优先级说清楚：

优先级	阶段	理由
P0	状态建模	不先建模，后面全乱
P0	生成带状态	生成链路要先对
P1	执行重新感知	稳定性提升关键
P1	局部重规划	价值高但复杂度也高
P2	统计评估	稳定了再来补