做了这么多年UI自动化，我有一半的时间不是在写用例，而是在修选择器。按钮的class改一个字母，层级里多包一层div，几十条用例跟着塌方；页面加个骨架屏，几秒的时序波动，整条流水线就飘红。传统UI测试这套玩法，越来越像是在流沙上盖楼——地基本身就脆。直到我接触了以Midscene.js为代表的AI视觉自动化方案，让AI直接“看”界面、理解界面，用自然语言下达操作指令，才真正感觉测试可以写得像人话一样自然。这篇内容我会围绕AI视觉自动化这个话题，结合Midscene.js的实际项目经验，重点拆解5个能直接落地的实战技巧。不管你是刚接触自动化测试的新手，还是被选择器折磨到想转行的老手，这5个技巧都能让你少踩几轮坑。
1. AI视觉测试的革命性：传统UI测试为什么会崩溃
1.1 传统UI测试的痛点逐一拆解
先说结论：传统UI测试的核心毛病不是框架不好，而是“定位”这件事本身太脆弱。过去我们写自动化用例，本质上是给元素发“身份证”——用ID、class、XPath、CSS选择器把某个按钮、某个输入框唯一地揪出来。问题在于，前端开发是高度动态的，尤其是现在组件化开发流行之后，class名经过混淆器一处理，完全没有规律；样式重构、响应式布局调整、A/B实验切版本，都会让选择器瞬间失效。
我做过一次统计：一个中大型后台系统的回归用例集，大约1200条用例，每次前端发版后平均有15%到20%的用例因为选择器失效而失败，其中真正是功能Bug的不到三分之一。也就是说，我们每天花大量时间在做“修选择器”这种纯机械劳动，而不是在验证业务逻辑。更麻烦的是，很多布局类问题、视觉类回归问题，根本没法用传统断言去捕捉，比如“弹窗遮挡了按钮”“文字溢出到容器外面”，这类问题在传统自动化里几乎是无解的，只能靠人工点一遍。
这里不是要否定传统自动化，它在接口稳定、结构规范的场景下依然高效，只是面对现代前端的高频迭代，维护成本已经高到反噬效率。这也是AI视觉测试出现的背景：既然DOM结构不稳定，那就跳过DOM，直接让AI理解渲染出来的画面，用人眼一样的视觉能力去定位和操作。
1.2 Midscene.js的核心原理：AI如何“看懂”界面
Midscene.js的思路其实很直接：它把多模态视觉大模型的能力接进了浏览器自动化流程里。你不需要给AI描述元素的DOM路径，而是直接给它一张页面截图、一段自然语言指令，比如“点击右上角的登录按钮”或者“找到表格中状态为已完成的订单，点击操作列里的详情”。AI理解截图中的视觉内容，结合指令推理出要操作的位置，然后转换为真实的光标点击、输入、滚动等动作。
这个流程看起来像魔法，本质上是一次“感知-推理-行动”的闭环。感知阶段，AI把截图像素变成视觉特征；推理阶段，结合自然语言指令判断意图和元素位置；行动阶段，由自动化底座把坐标或意图变成浏览器事件。关键点是，Midscene.js在行动前会把AI给出的结果映射回页面结构，而不是盲目地按像素坐标点击，这比纯粹的图像坐标识别要稳得多。
用生活类比来解释：传统自动化就像一个盲人摸象，靠手摸到固定的纹理来识别物体，物体换个摆放方式就不认识了；AI视觉测试就像一个视力正常的人，扫一眼就知道“那个红色按钮在右上角”，即使按钮换了个皮肤、挪了个位置，只要还是“红色按钮”，它就能认出来。
1.3 影响范围：从测试到研发流程的连锁变化
这套技术带来的影响远不止“少改几个选择器”。最直接的变化是，写测试用例的门槛大幅降低。传统自动化要求测试人员会写代码、懂DOM结构、了解框架API，而AI视觉测试只需要会描述需求——这一点产品经理、运营、设计师都能做到。我身边已经有个别团队开始尝试让业务同学直接写验收场景，再由测试同学做二次封装。
更深一层的影响是测试左移的可行性变高了。以前UI用例是最后一道关卡，因为准备成本和维护成本太高，等提测阶段再写已经来不及。现在用例写得快、改得快，开发过程中就可以拿AI视觉用例做冒烟验证。另外一个容易被忽略的影响在于视觉回归：传统方案对“好不好看”无能为力，而AI视觉方案天然能感知布局、颜色、遮挡这类视觉特征，这让UI回归测试从“功能有没有”升级到“界面对不对”，这是质的区别。
2. 环境准备与首个Demo：Midscene.js落地前的必修课
2.1 运行环境与依赖选型
在动手写第一个用例之前，先把环境说清楚。Midscene.js不是一个独立的“一键安装”工具，它需要依托一个浏览器自动化底座，在你安装好的环境里作为一个增强层存在。我建议用支持Chromium内核的自动化框架作为底座，这样视觉采样的稳定性和无头模式的成熟度都更好。
具体到项目里，我一般会新建一个独立的Node项目，单独管理依赖版本，不混进业务工程里。原因有两个：一是AI视觉测试的依赖升级频率相对高，混在业务项目里容易引发版本冲突；二是这个项目要跑定时任务、出测试报告，保持独立可以避免CI配置里各种上下文干扰。
依赖安装完之后，需要确认两件事：本地是否安装了对应版本的浏览器内核，以及配置文件里是否把浏览器路径指对了。很多新手第一次跑通Demo之后换台机器就乱，绝大部分是因为浏览器路径硬编码在代码里，换环境没同步改。建议把浏览器路径抽到配置项里，用环境变量覆盖。
2.2 首个AI视觉测试用例的写法示例
直接上代码，这个是我在模拟项目X里跑通的第一个用例，只做了一件事：打开首页，找到搜索框，输入关键词，点击搜索按钮，然后断言搜索结果里出现了预期内容。
import { setup } from 'midscene-sdk'; // 初始化连接，拿到一个可执行的runner const runner = await setup({ // 这里的air-console/remote等参数按实际环境配置 browserEndpoint: 'ws://127.0.0.1:9222', }); // 用自然语言驱动AI执行：打开页面、定位元素、交互 await runner.ai('打开首页，等待页面完全加载完成'); await runner.ai('在顶部的搜索框里输入关键词：自动化测试'); await runner.ai('点击搜索按钮'); // 用AI断言页面状态 const result = await runner.aiAssert('页面标题应包含“自动化测试”相关结果；如果没有结果显示，抛出明确提示'); console.log('断言结果：', result.pass ? 'PASS' : 'FAIL');你可能会觉得，这也太简单了吧？对，这就是关键——你不用再关心那个搜索框的id是search-input还是search_input_wrap，你只需要描述它的特征。第一次跑通这种用例的时候，我确实有种“以前那些定位方法都白学了”的感慨。不过这只是开始，实际项目中会遇到大量细节问题，后面会逐个展开。
2.3 核心概念：任务、提示词与执行模式
Midscene.js的使用过程中会反复遇到几个概念，提前建立清晰认知能省很多折腾。
任务(Task)：一次完整的AI驱动操作流程，可能包含多条指令。我习惯把一个业务场景拆成一个任务，比如“下单流程”“登录流程”，这样任务之间可以独立运行，也方便排查具体是哪一步出了问题。
提示词(Prompt)：这是给AI的自然语言指令。提示词的写法直接决定AI理解的准确度。核心原则是具体、可验证、无歧义。我刚上手时经常写“点击那个按钮”，AI只能靠猜，正确率自然不高；改成“点击页面上唯一一个带‘立即购买’文字、背景为橙色的按钮”之后，准确率明显提升。
执行模式：Midscene.js可以做全自动执行（AI自主决定操作序列），也可以做步骤化执行（每一步由你指定动作，AI只负责定位）。在关键业务流程上，我强烈建议用步骤化执行，因为全自动模式下AI可能出现创造性的步骤跳跃——它觉得自己已经完成了任务，但实际上跳过了某个必要环节，这在支付、提交订单这类流程里是绝对不能接受的。
3. 实战技巧才是重头戏：5个让AI视觉测试真正可用的方法
3.1 技巧一：自然语言提示词的“人话翻译术”
第一个技巧，也是最基础最重要的：学会把你的操作意图翻译成AI最容易理解的指令。这不是写作文，不需要修饰词，但需要足够的约束信息。我总结了一个公式：操作对象（核心特征）+ 操作动作（具体动词）+ 边界约束（位置、范围、前提条件）。
举例来说，如果你的需求是“在订单列表中把第一笔已取消订单删除”，提示词不要写成“删除一个订单”，而应该写成“在页面左侧订单列表中，找到状态标签为‘已取消’的第一行订单，点击该行的‘删除’按钮，如果页面上没有已取消的订单，请停止操作并提示‘无已取消订单’”。
这里有几个细节值得注意。第一，AI对“唯一性”非常敏感，你要帮它排除歧义，比如“页面顶部”“侧边栏”“表格倒数第二行”这类方位词能加就加。第二，条件分支要提前说明，“如果…就…如果没有…就提示”这种句式，能极大减少AI自作主张的概率。第三，动词要明确，“点击”“双击”“输入”“悬停”不要混用，AI不会自动脑补你想要的交互方式。
经验表明，提示词每增加一个有效的约束维度，定位准确率能提升一个档次。我在模拟项目X中做过统计，只写“点击按钮”时准确率不到70%，加上文字特征后提升到90%，再加上方位特征后稳定在96%以上。多花十秒钟把指令写得严谨，比出错后反复调试一个钟头划算得多。
3.2 技巧二：拿捏AI视觉执行的等待节奏
AI视觉模型的一次推理通常需要几秒钟，这意味着它不是一个瞬时动作。很多人第一次跑AI测试时最大的不习惯就是“怎么这么慢”。这个慢不是Bug，而是AI理解画面的必要开销。真正的坑在于：如果你没有为AI执行设置合理的等待策略，很多操作会在页面还没渲染完成时就触发，导致AI看到一张残缺的截图，做出错误判断。
我的做法是给关键动作前加一个“视觉稳定等待”。场景是动态加载的列表，比如表格数据来自接口，我会先加一条指令：“等待页面列表区域的加载状态图标消失，并确认表格内出现至少一条数据”。这比传统自动化里的固定sleep(3)要聪明得多，因为它是基于画面状态判断的，列表1秒加载完就只等1秒，加载10秒就等10秒。
另外要控制任务里的指令密度。不要在一条任务里堆二十个动作让AI一口气跑完，每执行五六个动作，我就会做一次阶段性校验，比如断言当前页面URL是否正确、某个关键元素是否出现。这种“每走几步回头看看”的做法，能避免AI一路狂奔跑到错误页而不自知。说到底，AI是个聪明的执行者，但它没有方向感，导航这件事还得靠你自己。
3.3 技巧三：混合定位策略——别把所有鸡蛋放进AI篮子里
很多接触AI视觉测试的人会走向一个极端：什么都让AI来做。我的建议恰恰相反——保持混合定位策略。稳定的、频繁使用的、性能敏感的元素，优先用传统选择器；动态的、复杂的、布局多变的元素，交给AI。简单来说，能用选择器就用选择器，搞不定了再请AI出马，而不是反过来。
这么做的理由很实际。第一，AI视觉推理有成本，无论从时间还是算力消耗上都比直接走DOM选择器高一个数量级；第二，AI存在幻觉，偶发性地定位错误是天然的，对稳定性要求极高的支付场景，你总不能接受100次里有1次点错按钮。混合策略的好处是：用传统方式守住底线，用AI拓展边界。
实操中，我给每个AI动作都加了传统方式兜底。具体做法是：优先尝试用稳定的选择器定位元素，如果元素不存在，再调用AI视觉定位。用一个简单的函数封装这个逻辑，让调用方无感知。这套机制上线后，我的用例集稳定性从94%提升到了99%以上，执行时间也缩短了大约40%，因为大部分高频操作都走了快速路径。
3.4 技巧四：把AI当作数据提取器——结构化断言
很多人的认知停留在“AI视觉测试就是AI帮忙点击元素”，其实AI在数据提取方面的能力同样有价值，这可能是最容易忽略的实战技巧之一。传统断言只能判断“在不在”“是不是”，而AI可以直接把页面上的非结构化视觉信息抽取成结构化数据，供你进行更丰富的校验。
举个例子，页面上有一张数据报表，里面有销售额、转化率、订单数等多个指标，传统做法是分别给每个数字写定位和文本断言。用Midscene.js，我直接给一条指令：“提取页面中核心指标区域的所有数据，返回JSON格式，包含指标名称和对应数值。”AI能把画面里的数字和标签解析出来，形成干净的结构化数据。
虽然不同项目的写法略有差异，但核心思路一致。拿到结构化数据之后，我一般做三件事：第一，与接口返回值做交叉比对，验证前端展示的数据准确性；第二，做趋势判断，比如“当天的订单数不能低于昨天”，这不再是简单的存在性断言，而是业务层面的规则校验；第三，把提取到的数据直接落到测试报告里，作为人工复核的依据。这个方法让AI测试从“界面操作验证”升维到“业务数据验证”，含金量高了一个层级。
3.5 技巧五：视觉回归与多场景复用
最后一个技巧，是把我前四个技巧串起来的“组合拳”。AI视觉测试天然适合做视觉回归测试，因为AI本身就是靠“看”来理解界面的。你可以让AI描述当前页面的关键视觉特征，比如布局、颜色、组件状态，然后与一个基准描述做相似度比对。这个能力在传统自动化里几乎无法实现，但现在只需要一段自然语言指令。
我在项目中是这样做的：每次发版前，让AI对几个核心页面进行一次“视觉巡检”，指令类似于“检查登录页是否包含背景图为蓝色系、卡片圆角、按钮文案为‘登录’；检查是否有元素重叠、文字溢出或遮挡”。这些描述在传统自动化里是无从谈起的，即使有截图对比工具，也只会机械地报像素差异，不知道差异是不是问题，而AI能直接理解“文字溢出”这种语义层面的异常。
多场景复用则是更高阶的用法。我的做法是把页面特征描述和操作步骤做分离：页面特征写在一个配置文件里，操作步骤写成一个通用脚本。新项目接入时，只需要替换配置文件，脚本主体完全复用。这样一套AI视觉测试框架，我可以在多个后台系统之间迁移，实际搭过之后你会发现，这比传统自动化每换一个项目就从头写定位器要爽太多了。
4. 实战中的坑与排查实录：稳定性是第一生命线
4.1 高频问题速查表
把这段时间踩过的典型问题整理成一张速查表，方便你遇到类似情况时快速定位。
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| AI点击位置偏移，总是点偏一点点 | 截图分辨率与页面渲染比例不一致；浏览器缩放比例不是100% | 统一设置浏览器窗口大小，关闭浏览器缩放，确保设备像素比一致 |
| 连续多次返回同一个错误结果 | 提示词存在歧义，AI在多个候选目标之间摇摆 | 增加约束维度：方位、颜色、文字、相对位置 |
| 完全空白的页面AI还在继续操作 | 页面加载失败或接口超时，AI看到的是错误页 | 强制在任务开头加“确认页面已加载出XX元素”的前置校验 |
| 执行速度慢到难以接受 | 任务里指令过多，单次任务串行执行大量动作 | 拆分任务，大批量操作批量场景用传统选择器兜底 |
| 偶发性定位到不同元素 | AI模型的概率性，相同截图可能给出不同结果 | 固定提示词格式，增加关键描述，必要时连续两次交叉验证 |
| 弹窗遮挡导致AI点击无效 | AI识别到目标元素，但没有感知弹窗遮挡 | 提示词里显式描述遮挡条件：“如果存在弹窗，先点击关闭按钮” |
4.2 稳定性建设的三个关键步骤
问题排查只是止血，真正的稳定性要从机制上解决。我稳定使用了三个月之后，总结出三个最有效的做法。
第一步，统一固定的浏览器视口配置。AI视觉定位严重依赖截图内容的一致性。如果有的用例在1920宽度的窗口跑，有的在1440宽度跑，AI对“右上角”这类方位描述的理解就会失真。现在所有项目的用例都固定使用同一个视口尺寸，横竖屏模式也统一锁定，这一个动作直接减少了大约30%的偶发定位问题。
第二步，建立AI动作的自愈重试机制。AI偶尔会点错，但概率不高，没必要每次失败都人工介入。我给每次AI操作包了一层自动重试逻辑：第一次定位失败或操作后页面状态不符合预期，等待1.5秒后自动重试第二遍。实测重试后成功率显著提升，而且重试导致的时间开销完全可以接受。
第三步，可视化日志与截图留痕。AI测试最大的噩梦是“到底AI刚才看到了什么”。我一律开启了全链路日志和操作截图，每一步AI的输入、输出、最终点击位置都记录下来。这不仅是排查问题的依据，也是反向优化提示词的素材——每次偶发问题，我都会翻出当时的截图与AI原始回复，找出是哪段描述让AI产生了误解，然后把提示词改得更严谨。这套反馈闭环，是AI测试稳定性持续提升的真正引擎。
5. 选型建议与适用场景：不是所有项目都适合上AI视觉测试
5.1 哪些场景值得用AI视觉测试
AI视觉测试不是银弹，我在实际项目中有明确的取舍标准。第一类适合的是：高度图形化、动态布局的C端应用。这类应用UI变化频繁，动画多、响应式场景多，传统选择器非常容易失效，而AI视觉测试几乎是为这类场景量身定制的。
第二类适合的是：视觉合规性要求高的项目。比如支付结果页、合同签署页、活动页，这些页面不能有遮挡、重叠、文案溢出，需要“长得对”而不只是“功能对”。第三类是跨项目复用的内部系统。多个后台管理项目共用一套组件库，外观和行为高度一致，用AI视觉测试做一套框架，在多个项目间复制，边际成本极低。
不适合的场景也要说清楚：如果页面完全静态、结构长时间不变、对执行速度和消耗极其敏感，传统自动化仍然是更优的选择。另外，如果业务对操作步骤有严格的路径依赖，比如必须经过特定顺序的流程，AI全自主执行模式可能反而危险，这种情况下请务必使用步骤化执行。
5.2 选型对比：AI视觉测试与传统自动化怎么配合
最后聊一个大家都会纠结的问题：上了AI视觉测试，传统自动化是不是可以扔了？我的态度很明确：它们是互补关系，不是替代关系。从我的对比经验来看，AI视觉测试最大的价值是覆盖“语义复杂”和“视觉敏感”两类场景，而传统自动化在“高频回归”和“性能敏感”场景下依然效率更高。
实操中最稳的组合方案是：高频主流程回归，用传统自动化（跑得快、够稳定）；复杂动态流程、视觉巡检、跨版本视觉对比，用AI视觉测试（看得懂、防得住）。这两个体系维护各自的脚本资产，通过同一个测试调度框架集成，跑完统一汇总到一个报告页面里。前面提到的混合定位策略，本质就是这种思想在单条用例内部的延伸。
我个人的体会是，没有必要去争“谁取代谁”，而是把每种工具的边际成本算清楚。凡是让AI理解画面比人写定位器更划算的地方，就是AI视觉测试的甜区。凡是成本低见效快的场景，继续用老办法也不丢人。工具是拿来解决问题的，不是拿来信仰的。
最后再分享一个小技巧：就算你暂时不打算全面引入AI视觉测试，也可以先用Midscene.js这类工具做“线上巡检机器人”，让AI每天定时把核心页面逛一遍，异常自动截图并描述问题。这个用途不需要维护任何选择器，几乎零成本就能获得一套24小时在岗的“视觉哨兵”。我是从这个小切口开始，才一步步把AI视觉自动化带进了整个测试流程，你不妨也从最小的一步试试。
