企业官网建设流程全解析

先说一个我在移动端自动化测试上反复撞墙后的真实感受：大多数团队从纯手工点按切换到自动化脚本之后，省下的时间并没有想象中那么多，反而多出一堆修脚本、调选择器、处理弹窗超时的活儿。这两年LLM的出现确实把不少顽疾松动了，但真正落地的移动端自动化方案并不多，能说清楚架构设计的更少。这篇文章想拆解的ARTEMIS，就是一套围绕LLM设计的移动端自动化框架，核心是它的双模式架构：一个模式面向确定性的功能回归，另一个模式面向探索性的异常发现。两者的设计逻辑、分工边界、以及在实际调试中踩过的坑，我会在下面展开聊。

1. 传统移动端自动化卡在哪：三个绕不开的死穴

移动端自动化测试不是没有工具，相反工具非常多。但这么多年下来，真正能用出效果的团队并不多。问题不总是工具不好用，而是移动端QA在三个层面存在结构性缺陷。

1.1 元素定位的“字面依赖”与页面改版灾难

传统移动端自动化最核心的操作就是定位元素，然后对元素做点击、输入、滑动。定位方式大致依赖资源ID、文本内容、坐标，以及基于控件层级关系的表达式。这些定位方式本质上都是“字面依赖”：必须精确知道页面上某个控件叫什么名字、或者在层级结构里的哪个位置。

问题在于移动端页面改动太频繁了。改版、换字体、调布局、加一个外层容器，都会让原先写好的定位路径直接失效。举个很普通的例子，列表页某个按钮从id=login_button改成了id=login_btn_new，整条用例就可能从第3步开始全挂。更麻烦的是，很多定位表达式是层层嵌套的，页面改一个节点，牵一发动全身。

我在实际项目里见过最夸张的情况是，一次常规改版后，一个原本稳定执行了半年的150条用例，直接报废了60多条，而且每条报废的定位错误都长得不一样。修完这一批，下一批又因为另一个页面改造开始报警。这种循环消耗的时间，比手工回归还要多。

LLM能改善的恰恰是这一层：定位从“精确匹配”转向“语义匹配”。只要页面截图和控件树能提供给模型，模型就能理解“页面右上角那个登录按钮”这种自然语言描述，并在新页面上找到对应控件。等于说，脚本不再绑定某个特定UI实现，而是绑定产品层面的语义。这样页面改版时，只要功能没变，自动化用例就不需要跟着改。

1.2 断言与用例维护是人力黑洞

传统移动端自动化的第二个死穴是断言。大多数用例的断言都很简单，无非就是“等待某个文本出现”“判断某个控件是否可见”，偶尔会有截图对比。这些断言本身写得再精细，也只覆盖了业务结果的一部分，而且断言策略完全依赖写用例的人，凭感觉判断“这一步应该验证什么”。

带来的后果就是：要么断言过粗，页面白屏了用例还是绿的；要么断言过脆，某个不影响功能的文案变化就会让用例失败。更隐蔽的问题是，移动端业务往往有成百上千条用户路径，每条路径都有多个分支和边界条件，人工为每条路径设计合理断言，工作量极大。大多数团队根本没有资源做到这个粒度，最后只能回到“脚本就是代替手工点一点”的低水平状态。

LLM在这一层能做的，是把“人类精确断言”替换成“模型判断状态是否符合预期”。比如执行完“完成支付”这步之后，模型综合截图、页面控件树、当前Activity信息和前文操作日志，判断当前是否处于“支付结果页”，并给出相应的业务语义验证结论。这一步把断言从“写死的代码”变成了“动态的理解”。

1.3 跨端复用的低效妥协

第三个痛点是最容易被人忽略的：移动端不是一个平台，而是安卓和iOS两个体系。很多团队为了省成本，会把同样的用例在两端各写一遍，或者在封装层做一层通用抽象，但遇到平台特有弹窗、手势、权限对话框时，抽象层的保护伞立刻失效。真正执行起来，依然是两套代码、两套维护节奏。

ARTEMIS在设计上没有试图解决“一套脚本跑两端”这个伪命题。它遵循一个更务实的思路：两端共享的是任务描述和LLM决策层，平台差异交给下层的驱动适配器去消化。这样既避免了重复发明轮子，也不会为了强行统一而牺牲平台细节。

2. 双模式架构的总体设计：一套框架的两种工作姿态

ARTEMIS并不是一个只有一个Agent跑到底的五花八门框架，它对“测试任务”做了切分，认为移动端测试本质上只有两类需求：一类是明确的、可描述的路径回归；另一类是模糊的、需要主动探索找问题的场景。这两类需求的工作方式完全不同，硬塞进同一个执行循环里，会出现不伦不类的结果。

2.1 双模式的定义：Plan-Act 与 Probe-Verify

先说两种模式分别是什么。

Plan-Act模式，中文可以叫“规划-执行模式”。它接收的是一个高层次的用户目标，比如“完成新用户注册流程并退出登录”。这个模式下，LLM先基于任务目标和当前页面信息，生成一份初步的操作计划，然后逐步执行：每一步都先观察当前页面，再决定具体动作，执行之后检查状态变化是否和预期一致，不一致时做反馈修正。

Probe-Verify模式，可以叫“探索-验证模式”。它不需要人类提供明确任务，而是让框架在一个页面图结构中进行遍历和变异操作，比如随机输入、异常滑动、快速点击等，然后通过比对状态差异来发现异常候选。发现可疑状态变化后，LLM再介入判断：这是正常业务行为，还是潜在缺陷。

这两种模式的差异本质上是“已知与未知”的差异。Plan-Act应对的是已知路径，追求高确定性和高可解释性，每一步都可以追溯到具体预期；Probe-Verify应对的是未知缺陷，追求覆盖面和异常召回率，允许大量无效尝试。

2.2 共享中间表示：UI状态流与操作日志

双模式虽然执行逻辑不同，但它们底层共享同一套“中间表示”。这套表示是我认为ARTEMIS里最值得参考的设计，它由两个核心数据对象构成。

第一个是UI状态流。框架在每次操作前后都会采集当前页面的快照，包括截图像素信息、空间信息、关键文本和可交互控件列表。这些信息不是简单堆叠，而是被组织成一个结构化的状态节点，并标明节点的父子关系和页面跳转方向。整条用例执行过程，会形成一张“UI状态图”，每一步操作都对应图里的一条边。

第二个是操作日志。每执行一次操作，框架都会记录动作类型、目标控件描述、屏幕坐标、操作耗时、前后状态哈希值，以及LLM在决策时的输入输出摘要。操作日志的作用是让整个测试过程可以被精确回放和审计，不管是排查框架自己的问题，还是给开发同学复现Bug，都极其有用。

这两个数据对象串起了一条可逆的执行链路。Plan-Act模式依赖它做逐步验证，Probe-Verify模式依赖它做状态差异分析。这也是为什么双模式可以共用同一套下层驱动和报告体系的原因。

2.3 为什么不做成单模式的“万能Agent”

很多人在设计这类框架时，第一反应是做一个纯粹的“Agent测试员”：给模型一个目标，让它自己连续操作直到完成。这个思路不是不行，但在移动端场景下，效果往往很不理想。原因是移动端UI操作存在很强的状态依赖和反馈延迟，中间任何一个误判都会让后续动作全部建立在错误的前提上。如果Agent一口气规划20步然后闷头执行，中间只要错一步，后续19步基本全废，而且很难定位是哪一步错的。

ARTEMIS把单Agent模式拆成双模式，实际是做了一个分治：有明确目标时，采取小步快跑、逐步修正的Plan-Act；没有明确目标时，采用覆盖率优先、后置判断的Probe-Verify。这相当于把“让模型自由发挥”收敛成“在框架约束下让模型做局部决策”，既保留LLM的语义理解能力，又不至于让模型的无序性毁掉整个测试过程。

3. Plan-Act 模式拆解：从自然语言需求到可执行操作序列

Plan-Act模式是这个框架里最常用到的工作姿势，也是团队把日常回归用例迁移到LLM时最先接触的部分。下面按执行顺序拆开讲。

3.1 任务意图解析与前置约束注入

Plan-Act的输入不是一串步骤，而是一段自然语言目标，比如“验证游客状态下看不到个人中心的订单入口”。这个目标会被送入意图解析模块，转换成机器可理解的任务描述和约束清单。

约束清单是容易被忽略但非常关键的部分。因为LLM对业务规则是不知道的，它可能会在测试过程中做出真实用户不会做的操作，比如在登录页随意输入一串手机号、在支付环节选择不可能的优惠券组合。这些行为在UI层面不一定报错，但会让测试结论失真。因此，意图解析阶段需要允许维护者注入前置约束，比如“不得使用已存在的真实手机号”“到达支付页后不要点击支付按钮”。约束会被存到本次任务的上下文里，后续每步决策都会带着它走。

解析输出的产物是一个初始计划草案，包含若干候选动作步骤。但这个草案并不直接执行，它只是给LLM一个起点。实际执行时，每一步都要结合当前页面状态重新确认，这也是Plan-Act稳定性的来源。

3.2 LLM驱动的元素定位：语义匹配、视觉锚点与坐标回退

移动端自动化的地基是定位。ARTEMIS在Plan-Act模式中设计了三级联动的定位策略，这是比传统框架多出来的核心机制。

第一级是语义匹配。LLM结合当前页面截图和控件树，理解“那个用于输入手机号的输入框”这类描述，将其映射到具体控件。这一级依赖多模态能力，截图提供视觉信息，控件树提供精确边界。两者结合的优势是：控件树可以拿到精确位置，截图可以解决控件树信息不足的页面（比如自定义绘制的控件）。

第二级是视觉锚点。当控件树无法提供有效候选时，比如页面是一个重度自定义渲染的图表，框架会退回到视觉层面，在截图中根据语义描述寻找目标区域，裁出候选图片块，再让LLM确认哪个区域是操作目标。这一步本质上是把定位问题转成了目标检测问题，虽然速度慢一些，但扩展了可操作范围。

第三级是坐标回退。前两级都失败时，框架会直接基于语义描述生成屏幕坐标区域（比如“右上角四分之一区域”），执行一个修正性的点击。坐标回退的成功率不高，但它保证了用例不会因为一次定位失败而直接中断，而是尽可能试探继续执行。

这三级的切换逻辑是：语义匹配失败，自动降到视觉锚点；视觉锚点置信度不足，再用坐标回退。每一级的结果都会写入操作日志，方便后续复盘为什么定位失败。

3.3 逐步执行与错误反馈修正

Plan-Act模式每执行一步动作之后，都会重新采集页面状态，做一次“预期一致性校验”。这里的预期不是写死的断言，而是LLM在动作之前生成的一段自然语言描述，比如“执行点击后，页面应切换到礼物选择面板，并且底部购物车角标消失”。执行后，框架把实际截图和控件树再喂给LLM，让它判断结果是否与预期吻合。

不一致时，框架会组装一条反馈信息，包含错误截图、当前页面控件概要、上一次动作描述和预期描述。LLM看到反馈后，有四个可选动作：重试当前动作、放弃当前动作改用其他等价操作、跳过当前步骤并调整后续计划、直接判定用例失败并给出原因分析。这个反馈闭环是Plan-Act模式下成功率显著提升的关键所在。

值得说明的是，LLM在反馈闭环中并不是无限重试的。ARTEMIS给每个动作设置了默认重试上限（通常2到3次），超过上限就整体失败退出。这个设计非常务实，避免模型陷入“不停点击但页面毫无变化”的原地打转状态。

3.4 防抖机制与“假成功”拦截

我在真实调试中遇到最尴尬的情况，不是用例失败，而是用例一路绿灯，但最后人工复盘发现，页面其实卡在同一个界面重复执行了十几步。LLM会在每次执行后都生成了“看起来合理”的预期描述，但实际情况是操作没有产生任何状态变化。

ARTEMIS对这个问题做了两层拦截。第一层是状态哈希比对：每次采集页面状态后，框架会生成一个轻量级状态指纹，如果连续N步操作后状态指纹没有变化，就触发重复动作预警。第二层是操作本体比对：如果当前动作和最近3步内的动作高度相似，并且状态没有变化，框架会主动终止当前步骤，要求LLM重新审视页面和任务目标。

这两层机制叠加起来，基本堵住了“假成功”这个坑。也正因为如此，回归测试的稳定性才有了底线。

4. Probe-Verify 模式拆解：遍历、变异与异常语义分类

如果说Plan-Act解决的是“把已经知道的路径跑稳”，那么Probe-Verify解决的则是“把不知道的角落翻出来”。这个模式更适合兼容性检测、新版本发布前的冒烟探索，以及长期无人维护的历史模块巡检。

4.1 UI图遍历与状态约束管理

Probe-Verify的第一步，是让框架自动遍历App内的UI状态图。它从启动页开始，持续寻找可交互控件并执行点击，进入新的页面后再重复这个过程。遍历策略可以配置为首选广度优先，或按控件类型加权（比如优先尝试列表项、Tab、菜单入口）。

移动端遍历有一个传统自动化容易忽略的问题：状态约束。有些页面在没有登录态时和被系统弹窗遮挡时，遍历结果会完全不同。比如首次启动会弹出多个权限请求弹窗，如果框架不去处理这些弹窗，后面的遍历基本在错误状态下进行。ARTEMIS在遍历引擎里内置了弹窗预处理策略，每次发现系统弹窗，先尝试关闭，再进行页面节点采集。

另一个约束是业务深度的限制。有些业务需要登录、需要特定账号等级、需要前置数据，Probe-Verify模式不会尝试构造这些复杂前置条件，而是记录“此处存在未探索分支”，留给Plan-Act模式用明确任务去覆盖。这也再次体现了双模式各司其职的关系。

4.2 变异操作与状态差异计算

遍历只能发现“页面能进去”，但发现不了“输入异常值时系统会不会崩”。所以Probe-Verify在遍历的基础上，加入了变异操作引擎。它会对可输入控件注入异常类型的数据，比如超长文本、特殊符号、空字符串、边界数值；对可点击控件执行连点、快速滑动、双击等非常规操作。

每执行一次变异操作，框架都会对比操作前后的状态指纹、页面跳转关系、关键业务标记字段。如果状态没有发生变化，说明这个变异被正常消化；如果发生了变化，框架就会产出一个“异动候选记录”，并把操作前后的截图、控件树、日志片段一起打包，供后续模型验证。

这个阶段最重要的是“宁滥勿缺”。哪怕是状态变化非常微小，比如某个隐藏控件突然变为可见，也要先记录下来。因为很多严重的Bug在出现初期，UI变化并不明显，如果过早过滤候选，就把真正的问题漏掉了。

4.3 LLM异常语义分类与复现路径生成

Probe-Verify收集到的异动候选记录数量通常很大，一次深度遍历下来可能有几十上百条，不可能让人类逐条去看。ARTEMIS把筛选任务交给LLM，对每一条候选记录做四分类：

正常业务行为、需要人工确认的疑似异常、明确缺陷（如崩溃、白屏、无响应）、以及测试环境因素导致的伪异常。分类的时候，LLM会结合页面截图、控件树、操作日志和业务上下文说明进行综合判断，输出判断理由和置信度。

对于标记为明确缺陷的记录，框架会把对应的操作步骤自动转成一份复现路径，格式上可以直接作为Bug单里的复现步骤。这一步极大减少了测试和开发之间的沟通成本。我自己体验最深的是，过去写一个崩溃复现步骤要整理半天，现在Probe-Verify跑完，连截图和日志都已经按步整理好了，开发拿到手就能开查。

5. 双模式的协同策略与工程集成

框架有了两种模式之后，紧接着的问题是：什么场景该用哪个模式？两种模式怎么协同？这在工程落地时是决定成败的细节。

5.1 选择模式的决策规则

我的经验是把选择规则做成一张简单的决策表，而不是靠测试人员临时判断。

另外还有一个比较通用的策略：一个版本周期内，Plan-Act负责每天跑固定回归，Probe-Verify在一个里程碑版本前做一次集中巡检。两者不互斥，更像是“日常巡检”和“定期体检”的关系。

5.2 与CI和设备矩阵的集成方式

无论哪种模式，最终都要包装成命令行工具才能接入现有测试基础设施。ARTEMIS对外的执行入口就是一个标准命令，输入是任务描述或探索配置，输出是统一格式的报告。

报告格式走的是兼容路线，直接输出成团队里常见测试报告工具能够识别的格式。这样就不需要推翻已有平台，只需要把ARTEMIS的执行结果当作一种新的测试来源接入即可。设备矩阵方面，两种模式可以并行分发到多台真机或模拟器上，Probe-Verify对设备数量更饥渴，因为它的成本大头在遍历广度；而Plan-Act对单台设备的执行稳定性更敏感。

5.3 可观测性设计：日志、回放与回归评估

LLM自动化测试和传统自动化有一个本质区别：传统脚本出了问题，看看代码和堆栈基本能定位；LLM决策链路出了问题，必须能看到模型当时看到了什么、想了什么、为什么这么操作。ARTEMIS在这块做得比较厚，每一步都保留完整审计，包括完整Prompt、模型返回、页面截图、操作结果。这也带来了存储成本压力，实际部署时通常只对失败用例保留完整审计，成功用例仅保留摘要信息。

还有一个容易被忽略的指标是“回归评估”：既然引入了LLM，就必须定期评估这套框架自己的回归效果。ARTEMIS会沉淀一批历史样本，每周用两种模式分别回放一次，统计通过率、误报率、漏报率和平均耗时。这些指标如果出现明显波动，说明框架配置、模型版本或页面结构可能发生了变化，需要及时介入。这个机制我认为是LLM测试工具能否长期可信运行的生命线。

6. 实测踩坑记录：从框架可用到稳定运行的最后一公里

最后这部分分享一些我在实际调试中的真实遭遇。任何一个LLM自动化框架，从Demo跑通到稳定使用，中间都有一条满是坑的路。

6.1 LLM的“假成功”与重复点击问题

前文提到框架层面做了状态哈希比对来防呆，但这是事后补救。真正深挖会发现，“假成功”的根源往往是Prompt设计里缺少“执行前普适性检查”这个环节。后来我在每个动作开始前，都会强制让模型输出“当前页面关键特征”和“目标控件是否仍然存在的判断依据”，这个看似多此一举的步骤，把方向性错误堵掉了大半。

处理重复点击还有一个心得：不要只比对页面指纹，还要比对当前操作和历史操作的相似度。没有这层操作本体比对时，经常出现一套流程中某个步骤被重复执行了三四次，每次都在不同页面上做了同样的点击动作，页面指纹虽然变了，但逻辑上已经乱了。

6.2 长任务执行中的上下文漂移

Plan-Act模式在处理超过15步的长流程时，会出现一个典型问题：模型越到后面越“忘记”最初的约束，开始按照自己的理解做计划外操作。比如任务说的是“游客状态下查看”，执行到后面它可能会自动进入登录流程。

应对方式是把原始任务摘要和约束清单做成常驻上下文，穿插在每一步的Prompt中；单步决策用的上下文尽可能精简，只保留最近3到5步的状态摘要。这比把全部历史都塞给模型要稳定得多，交互成本也更低。

6.3 Prompt工程与成本控制的小账本

LLM测试框架的成本是绕不开的话题。一份20步的Plan-Act任务，决策调用加上执行后验证，可能要消耗几十次模型请求。做成本优化时，我主要用了三招：第一，把页面截图的尺寸压缩到模型可理解的较小分辨率，减少图片Token；第二，页面元素清单做摘要化，只保留候选可交互控件的简要信息；第三，小模型先做粗糙判断，大模型只处理定位冲突、异常分类等核心决策。

按照这个思路优化之后，一个常规回归任务的平均调用成本是可以压到团队可接受范围内的，但如果完全不做控制，成本确实会很快失控。建议任何新接手的团队，先把这个账算清楚再上规模。

6.4 落地建议：先从哪条路径开始

基于上面的体验，我会建议刚接触这类框架的团队，不要一上来就把全部用例迁到LLM上，也不要同时启用两种模式。稳妥的做法是，选择一条最核心的高频回归路径，用Plan-Act模式跑通，把定位策略、反馈闭环和审计日志都验证熟练之后，再逐步扩容。Probe-Verify可以在一个测试版本发布之前做一次试点，通过它发现几个真实缺陷之后，团队对这套体系的信任度自然会建立起来。

移动端LLM自动化当前的边界还很明显，比如对于复杂的手势操作、动态页面无限加载、音视频场景都还不能做到完美覆盖。但双模式架构提供了一条务实的路径：想在某个局部场景获得确定性的结果，就用Plan-Act把路径钉死；想全局摸清状态和异常，就用Probe-Verify把触角铺开。这套思路不依赖某一家模型的能力爆发，更多是把LLM嵌进一套有边界的工程体系里，让它在该理解的地方理解，在该收敛的地方收敛。