我的第一个AI产品实战:AI视觉兼容性测试

1.1 需求起点：不是用户访谈，是日常对话

这个产品需求的起点，不是什么正式调研，而是一次再普通不过的日常对话。

场景重现（某次版本发布前）：

测试同事A（打开手机，指着屏幕）："你看，这个页面上次在华为Mate 60上测是好的，今天在小米14上跑，按钮直接错位了。"

我："分辨率不一样？"

测试同事A："对，一个1080×2400，一个1080×2340，差了60个像素。然后这个弹窗在OPPO上又被虚拟键盘顶上去了一半。我这一下午光测这几个页面的兼容性了，还没开始测功能呢。"

这是整个需求的起点——不是什么精心设计的访谈，而是工作场景里真实的摩擦。我把这段对话记了下来，然后开始有意识地留意类似的声音：

关键发现：4次对话里，有3次反复指向同一个问题——不同分辨率设备的兼容性测试，纯靠手工，效率极低。

1.2 追问提炼：8次对话的结构化需求

从那天起，我开始有意识地追问细节。每次遇到兼容性问题时，记录三个信息：

1. 具体场景："什么情况下兼容性问题最频繁？"

2. 耗时："测试一轮大概多久？"

3. 理想状态："如果AI能帮你做，你最希望它做什么？"

8次追问（涉及2位测试同事）的结论：

关键发现：测试同事的核心诉求是——"能不能让AI替我看一遍所有分辨率的屏幕，然后告诉我哪里有问题"。不是"写脚本"，不是"配置设备池"，而是"像人一样看屏幕，但比人看得快、看得多"。

1.3 问题本质：分辨率碎片化已超出人工可控范围

结合测试同事的反馈和行业资料，我梳理了问题的全貌：

Android分辨率碎片化的现状：Android机型的屏幕分辨率种类极多——1080×1920、1080×2340、1440×2560……不同品牌、不同尺寸、不同像素比，组合起来几乎无法穷举。更棘手的是，除了分辨率，还有水滴屏、刘海屏、挖孔屏、折叠屏等各种屏幕形态，这些都是UI兼容性最容易出问题的地方。

测试人员的真实困境：兼容性测试很难覆盖全部机型，通常需要通过第三方数据平台（如友盟、TalkingData的设备占比报表）获取用户设备分布，选择Top机型来覆盖。即便如此，"页面显示问题如覆盖、留白、错位、拉伸、遮挡，特别容易遗漏顶部时间栏、业务顶部栏"——这些缺陷，纯靠手工排查，既耗时又容易遗漏。

从测试同事的视角看：

• "每一款新机发布，就得想办法弄一台真机来测一遍。华为、小米、OPPO、vivo……每个品牌都得有，不然线上出了问题就来不及了。"

• "一个页面在1080p上显示正常，在2K屏上可能就变形了。每个分辨率都得手动开一次App看一遍，翻来覆去就为了确认'没变样'。"

量化一下这个痛点：假设覆盖Top 10机型 × 每个App 20个核心页面 = 200次人工查看，按每次2分钟算，一轮兼容性测试就要 400分钟 ≈ 6.7小时。而每个迭代都要跑一遍——这就是测试同事"一下午光测兼容性"的由来。

这里的核心矛盾是：产品需要兼容多种分辨率，但测试手段只有"肉眼+手工"。这直接指向了一个产品假设——如果AI能"看懂"屏幕，自动验证UI在不同分辨率下的表现，就能大幅降低这部分成本。

1.4 目标用户画像

二、竞品分析

2.1 现有方案概览

在投入开发前，我调研了国内外已有的兼容性测试方案，避免重复造轮子：

2.2 从竞品中学到的3件事

第一，传统像素diff不可用，必须走语义理解路径。像素级对比会把"2K屏比1080p多渲染的内容"全部标红，误报率极高。Squish Vision和Midscene.js都验证了同一个方向——必须从语义层面理解UI元素，而非逐像素比较。这坚定了我用多模态大模型做差异检测的技术选型。

第二，云真机方案解决了"设备不够"，但没解决"人工看"。 BrowserStack这类平台能让你远程操作几百台设备，但每台设备上的UI还是要人去看。它解决的是设备获取问题，不是检测效率问题——测试同事说的"一下午光测兼容性"，用BrowserStack依然是一下午，只是不用跑去找真机了。

第三，语义定位是跨分辨率测试的技术基础。 Midscene.js证明了"让AI看界面而非记坐标"的可行性。这让我意识到，如果兼容性测试的输出不仅是"报告"，还能转化为"可在任意分辨率上执行的语义脚本"，价值会成倍放大。

2.3 差异化定位

基于竞品分析，本项目不重复做"又一个云真机平台"或"像素diff工具"，而是定位为：

面向测试团队的AI视觉兼容性测试助手——用多模态大模型"看懂"UI差异，自动输出结构化报告，让测试人员从"逐台肉眼看"变成"确认AI发现的问题"。

与竞品的关键差异：

1. 不是像素对比，是语义理解：AI理解"这是按钮、那是输入框"，区分正常适配与真实缺陷，降低误报

2. 不只给设备，还给结论：输入截图，直接输出"哪里错了位、哪里被遮挡、严重度多高"，而非让人自己看

3. 遮挡检测是原生能力：异形屏、虚拟键盘遮挡这类高频缺陷，作为P0功能内置，而非靠人眼发现

三、最小成本验证

3.1 第一件事：把"吐槽"变成"追问"

（详见1.2节，8次追问得到3个高频需求信号。）

关键收获：测试同事要的不是"自动化脚本"，而是"替我看屏幕"。这个认知决定了后续技术选型——不做脚本生成，做视觉理解。

3.2 第二件事：用Coze跑通"截图对比+AI分析"最小原型

我在Coze上搭建了一个简单的工作流：

1. 输入：同一个页面在不同分辨率设备上的截图（如1080p vs 2K屏）

2. AI处理：调用视觉模型分析两张截图的UI差异（按钮位置偏移、文字遮挡、元素重叠等）

3. 输出：结构化报告——标出差异点，圈出疑似问题区域

用3个页面做了验证：

关键发现：AI确实能"看"出UI差异。3个验证case全部命中真实缺陷，没有误报。虽然当时这个流程还需要人工介入（截图的收集、对比的触发），但核心能力已经验证——视觉模型能够识别跨分辨率的UI布局差异。

我把这个结果拿给测试同事B看，她的第一反应是："这个能自动跑，那就不用一台台设备翻着看了。"

3.3 第三件事：验证"AI能不能自动适配分辨率变化"

我进一步验证了另一个方向：如果界面元素的位置发生了变化，AI能不能"自适应"地找到它？

参考Midscene.js和Squish Vision的技术路径——用计算机视觉模型从语义层面理解GUI元素，不依赖坐标或像素精确匹配，即使UI在颜色、缩放比例或位置上发生了变化，测试也能继续运行。

我在Coze上用视觉模型做了简易验证：给AI看一张高分辨率设备上的按钮截图，然后在低分辨率截图中找同样的按钮。结果显示，AI能够基于"按钮的语义特征"（位置、形状、文字）而不是"精确像素坐标"来定位。

这意味着——如果测试脚本不再依赖"点击坐标(x=320, y=540)"，而是依赖"点击那个写着'登录'的按钮"——那分辨率变了，脚本也不会断。这正是"跨分辨率自动化测试"的技术基础。

3.4 验证结论与已知局限

已验证可行的：

• 视觉模型能识别跨分辨率UI布局差异（3/3命中）

• 视觉模型能基于语义特征在不同截图中定位同一元素

• 遮挡检测（键盘/异形屏）在原型层面可行

已知局限（必须诚实说明）：

这些局限不影响"方向可行性"的判断，但决定了MVP必须明确边界——先做"已验证能跑通"的场景，再逐步扩展。

四、需求规格

4.1 功能需求清单

基于测试同事反馈、竞品分析和验证结论，列出针对"多分辨率兼容测试"场景的需求：

4.2 优先级划分依据

优先级不是拍脑袋定的，基于三个维度综合判断：

维度一：需求频次（来自8次追问）

• C-01提到5次、C-02提到3次、C-03提到3次 → 高频痛点，P0

• C-04来自行业验证非直接用户诉求 → P1

维度二：技术可行性（来自Coze验证）

• C-01/C-02/C-03已在原型中验证可行 → P0，MVP必做

• C-04验证了可行性但工程化复杂度高 → P1

• C-05/C-06涉及设备底层控制，工程量重 → P1/P2

维度三：MVP闭环必要性

• P0三件事（对比+报告+遮挡检测）构成最小可用闭环：输入截图→输出报告

• C-05截图自动采集虽重要，但MVP阶段可用"人工上传"兜底，不阻塞闭环

• 上一版将C-06设备池列为P2，但它实际上是C-05规模化前提——修正为P2仍合理，因为MVP阶段手动上传足够

优先级修正说明：相比初版，C-03遮挡检测从P1提升到P0（测试同事B三次提及且是高频线上缺陷），C-05截图采集从无到有新增（验证中发现人工截图是端到端闭环的最大瓶颈）。

4.3 非功能需求

说明：准确率指标>80%/>15%是基于3个验证case的初始估算，MVP上线后需要用真实数据持续校准。

五、产品架构

5.1 架构总览

AI视觉兼容性测试架构图

整个系统分为5层，从上到下依次为：

架构设计原则：

• 每层职责单一：AI能力层只管"看懂"，设备执行层只管"采集"，互不耦合

• 知识库贯穿检测全程：设计稿库提供基线，历史缺陷库过滤误报，设备信息库提供屏幕形态参数

• 意图层负责编排：用户一次操作可能触发多个AI能力（如"对比+遮挡检测+报告"三步串联）

5.2 模块与需求映射

架构图的模块与需求清单的对应关系：

5.3 用户使用流程

AI视觉兼容性测试用户使用流程

典型使用流程（一次兼容性测试任务）：

1. 测试人员上传待测页面的多分辨率截图（或选择已连接设备自动采集）

2. 选择分辨率组合与对比维度（如"1080p vs 2K，检查错位+遮挡"）

3. AI测试助手调用视觉模型，逐组对比截图，识别差异点

4. 知识库提供设计稿基线和历史缺陷数据，辅助过滤误报

5. AI生成结构化报告：差异点列表+严重度+遮挡检测结果

6. 测试人员在线查看报告，确认真实问题/忽略误报，导出最终报告

效率对比：

六、技术方案

6.1 视觉UI差异检测

这是兼容性测试最核心的能力——让AI"看"出不同分辨率下的UI差异。

技术路径：直接调用多模态大模型（如GPT-4o、Qwen-VL），输入两张截图，让AI输出差异点列表。无需自己训练模型。

为什么不用传统像素diff：像素级逐点对比会把"2K屏比1080p多渲染的留白"全部标红，误报率极高。语义理解能区分"这是正常的分辨率适配"和"这是真实的UI缺陷"。

输出结构：差异点列表，每项包含——差异类型(错位/遮挡/留白/拉伸)、位置描述、偏移量估算、严重度(高/中/低)。

6.2 语义化UI定位

问题：传统自动化脚本依赖XPath或坐标定位元素，分辨率一变就失效。

方案：基于计算机视觉的语义定位——AI"看"到按钮的视觉特征（形状、文字、位置上下文），而不是"记住"它的坐标。即使按钮从屏幕左侧移到右侧，AI依然能识别出"这是同一个登录按钮"。

落地方式：将视觉模型作为定位层，替代传统的XPath/坐标定位器。这一能力在Coze原型中已初步验证可行（见3.3节）。

与竞品的关系：Midscene.js已在Web端验证此路径，Squish Vision用类似原理做GUI语义理解。本项目将其引入移动端兼容性测试场景。

6.3 设备连接与截图采集

问题：MVP阶段依赖人工截图上传，端到端未闭环。测试同事反馈"截图本身就很麻烦"。

方案：基于ADB通用控制层，配合视觉理解能力，实现对不同品牌、系统、分辨率设备的统一控制——同一指令"截取当前页面"，在1080p和2K屏幕上自动适配，无需修改配置。

双通道设计：

• 自动采集：连接真机后一键截图，适合有设备池的场景

• 手动上传：测试人员自行截图上传，适合MVP阶段或外协测试

6.4 降级与兜底方案

AI不是万能的，模型可能超时、限流、误判。设计两级降级机制：

误报处理：测试人员在报告中标记"忽略"的问题，写入历史缺陷库作为负样本，后续检测时优先过滤同类误报。用得越多，误报越少。

七、MVP范围与路线图

7.1 MVP核心目标

让测试人员把兼容性测试从"逐台肉眼看6小时"变成"确认AI报告1小时"。

MVP只做一件事：输入多分辨率截图 → 输出结构化兼容性报告。测试同事拿到报告后说"这个帮我省了好几小时"，MVP就成立。

7.2 MVP功能矩阵

7.3 产品路线图

八、实战总结与下一步

8.1 已验证的能力

• ✅ 从测试同事日常吐槽中识别出"多分辨率兼容测试"这个真需求（8次追问，3个高频信号）

• ✅ 用Coze跑通了"截图对比→AI分析→输出报告"的最小原型（3个页面验证，3/3命中真实缺陷）

• ✅ 验证了视觉模型识别UI差异的可行性

• ✅ 验证了语义定位作为跨分辨率测试技术基础的可行性

• ✅ 完成竞品分析，明确了差异化定位（语义理解+遮挡检测+结论输出）

• ✅ 形成含架构、需求、MVP、路线图的完整方案

8.2 已知局限与待验证风险

8.3 下一步行动计划

第一周：扩大验证规模

• 用公司实际App的10个核心页面 × 3组分辨率 = 30组对比测试

• 记录检出率、误报率、处理耗时三项核心指标

• 识别失败case并归类（是模型能力不足还是输入质量问题）

第二周：内部试用反馈

• 邀请3位测试同事试用完整流程（上传截图→看报告→导出）

• 收集两个关键反馈："这个帮你省了多少时间？""哪些问题是AI没发现但你觉得应该发现的？"

• 基于反馈迭代对比精度和报告可读性

第三至四周：MVP开发

• 基于验证结果确定技术选型（主模型/备模型）

• 开发前端上传+报告查看界面

• 打通"上传→AI检测→报告"核心链路

一句话总结：AI能不能自动做兼容性测试，能不能在不同分辨率下"看懂"UI——这不只是行业趋势，而是测试同事们每天都在问"能不能帮我看看这个"的具体问题。视觉模型在语义层面理解UI的能力，正在让"一次测试，适配所有分辨率"成为一个可实现的工程目标。但方向可行不等于工程就绪——MVP要做的是把"已验证可行的3个case"变成"可重复、可规模化、误报可控的产品能力"。

附录：界面原型