移动端自动化测试的朋友应该都有过类似经历脚本越写越多维护成本却一路走高。每次App发版最先挂掉的不一定是业务代码反而是那堆写满控件ID的测试用例。控件一改、页面一重构、动态弹窗一挡几十条用例就当场报废。我最近在团队内部落地了一套代号为ARTEMIS的LLM自动化测试体系核心方向就是移动端自动化。这一篇是这个系列的第5篇也是移动端自动化的第一篇重点拆解ARTEMIS的双模式架构。如果你是做测试开发、质量平台或者正在纠结怎么把LLM真正用到自动化测试里而不是停留在写PPT阶段这篇文章应该能给你一个具体的架构参考。这套双模式架构并不复杂一句话概括一个是“引导编排模式”管稳定回归一个是“自主探索模式”管探索未知问题。两个模式共用一套中间表示既能各自独立运转又能互相转化结果。下面我从设计思路、实现细节、踩坑经历三个层面把这套架构的里子翻出来聊一聊。1. 移动端自动化测试的痛点以及LLM为什么不只是噱头1.1 传统脚本维护的“隐形债务”到底有多大很多人一开始觉得自动化测试难难在写脚本。真正干过之后才发现写脚本只是入门维护脚本才是无底洞。我见过一个模拟项目X的移动端测试仓库版本发布之后600多条用例里有80多条失效原因无非是控件ID变更、页面层级重构、某些功能从入口改到了更深位置。每条失效用例平均要花20到40分钟定位原因再花10到20分钟修改。一个版本下来光修脚本就要占掉一个人两三天的工作量。移动端和Web端相比这个问题更严重。Web端的DOM结构相对稳定至少还有个id能兜底移动端的控件树经过原生渲染和跨平台框架转换之后原始ID经常丢失、被篡改甚至同一控件的resource-id在不同Android版本上都不一样。再加上iOS和Android两套系统并存测试脚本往往要写两套维护量直接翻倍。这种“隐形债务”平时没人提但每个迭代周期都在消耗时间。传统方案也不是没有尝试过比如图像识别、可视化回归、录制回放。但图像识别遇到主题换肤就废录制回放遇到动态页面就断而且这些方案都缺少一个关键能力理解页面变化背后的语义。同一块“登录按钮”从坐标(100, 200)移动到(300, 400)在人类测试工程师眼里还是同一个按钮但在传统脚本里就是一次失效。LLM恰好能在这个语义层面发力。1.2 LLM在自动化测试里真正能发力的三个环节先说结论我并不是把LLM当成一个什么都能干的Agent来用而是把它拆成三个具体角色用例生成器、元素定位器、异常分析器。第一个环节是用例生成。传统测试用例是写在Excel或用例管理平台里的自然语言要变成自动化脚本靠的是人去翻译。LLM可以直接把自然语言需求转成可执行的步骤序列至少省掉“翻译”这一步。第二个环节是元素定位。与其写死一句复杂的XPath不如让LLM理解“点击页面底部的登录按钮”这种语义描述再结合当前屏幕的控件树动态推断出目标元素。它不依赖具体IDID变了也能通过语义找到。第三个环节是异常分析。脚本执行过程中遇到弹窗、加载失败、网络超时以前只能靠硬编码规则去猜测现在可以让LLM看截图和状态信息像测试工程师一样判断是继续、重试还是报失败。这三个环节不一定都需要在线调用模型。比如用例生成可以离线做生成完固定下来元素定位只需要在运行时调用一次异常分析则是在失败发生时兜底使用。这样拆分的价值在于LLM不是在所有环节都介入而是“按需介入”既控制了成本又把易失效的部分变成了可应对的变化点。1.3 为什么必须设计成双模式而不是一个Agent解决所有问题我在项目初期也想过能不能直接做一个通用Agent给它一个目标让它自己在手机上点来点去把所有测试都搞定。实际跑了几轮之后发现这种“全知全能Agent”在真实移动端测试里根本不现实。原因有三个。第一是可控性差。回归测试要求每次执行结果可复现一个自由发挥的Agent上一次走流程A下一次走流程B脚本结果对不上你根本没法判断是业务问题还是Agent路径漂移。第二是成本高。探索模式下每一步操作都要调用模型思考一个完整流程动辄几十步模型调用数量膨胀得很厉害时间成本和费用都兜不住。第三是稳定性和发现能力天然冲突。稳定意味着严格按照预期路径执行而发现新问题往往需要脱离预期路径去乱跑。这两个目标放在同一个Agent里很容易互相干扰。所以我把执行过程拆成两个模式引导编排模式偏向“确定性”自主探索模式偏向“未知发现”。两个模式各司其职再通过调度层按任务类型选择。这样既保证了回归测试的可靠性又保留了探索性测试的价值。这也是ARTEMIS整套架构最核心的设计判断。2. ARTEMIS的双模式架构我到底是怎么拆的2.1 两个模式的定义和分工引导编排模式我习惯叫它Guided Mode。它的工作方式是测试人员用自然语言描述一个业务场景ARTEMIS把场景解析成可回放的脚本脚本由若干步骤构成步骤包含动作、目标、预期状态。执行时每一步都走固定逻辑正常情况不调用LLM只有遇到异常或断言失败时才让LLM介入分析。这个模式适合冒烟测试、回归测试目标是验证已知功能是否正常。自主探索模式也就是Explorer Mode。它更接近一个真正的Agent系统把当前屏幕的语义快照发给LLMLLM输出下一步动作执行完后再次抓取快照循环往复。它不需要预设脚本只需要一个目标比如“尝试完成从首页到下单的流程”或者“逛遍所有设置页”。这个模式适合探索性测试、兼容性测试目标是发现预期之外的崩溃、卡顿和逻辑漏洞。两个模式的分工用一张表可以看得很清楚维度引导编排模式自主探索模式适用场景回归测试、冒烟测试探索性测试、兼容性测试执行速度快正常流程无LLM调用慢每步决策都可能调用LLMLLM参与时机生成脚本时 异常时每一步决策时执行稳定性高路径固定中存在漂移可能核心目标验证已知功能发现未知问题产出物可回放脚本操作轨迹 发现的问题这张表基本上就是双模式架构的顶层需求。后面所有实现都是围绕这些差异点展开的。2.2 整体分层感知层、决策层、执行层、闭环层ARTEMIS不是简单地在测试框架上套一个模型而是分成了四层第一层是感知层。负责采集屏幕截图、控件树、OCR文本、设备状态、手势信息等然后清洗、去重、压缩成一个结构化的“语义快照”。这层是双模式共用的无论哪个模式首先都要“看清楚”当前页面长什么样。第二层是决策层。根据任务类型选择走哪个模式在引导模式下负责把需求变成步骤序列在探索模式下负责把语义快照变成下一步动作。决策层是LLM能力最集中的地方。第三层是执行层。负责把决策层给出的动作翻译成真实的设备操作比如点击、滑动、输入、返回同时处理等待、重试、超时等执行细节。这里不引入LLM保证执行速度和可靠性。第四层是闭环层。负责把执行结果收集起来做覆盖率分析、失败分类、轨迹回放并且把探索模式中发现的新路径沉淀成引导模式的用例。没有这一层双模式只是两个孤立的工具有了这一层双模式才能形成循环。用生活化的类比理解感知层是眼睛和耳朵决策层是大脑执行层是手闭环层是记忆和复盘。大脑虽然聪明但没有记忆和复盘同样的错误会反复犯。这也是很多团队的AI测试Agent跑不起来的原因——只做了前三层忘了第四层。2.3 双模式如何共用一个“中间表示”双模式最怕的问题是两套逻辑各写各的数据格式对不上最后变成两个独立系统。我在设计ARTEMIS时第一步就是定义统一的中间表示IR。简单说所有动作、状态、预期结果都统一描述成一种结构化的JSON格式。举个例子一段引导模式生成的脚本可能长这样{ task: 登录流程回归, steps: [ {action: tap, target: 账号输入框, semantic: true}, {action: input, text: test_user, target: 账号输入框}, {action: tap, target: 登录按钮}, {action: wait, condition: 主页加载完成, timeout: 15} ], assert: 页面上出现用户头像 }探索模式的每一步动作也会被记录成类似的结构只是额外增加“reason”字段用来保存模型当时为什么做这个动作。统一中间表示的好处非常明显执行器只需要实现一份报告系统只解析一份失败分类器只消费一份。更重要的是后续可以让探索模式产出的轨迹直接转换成引导模式能够回放的脚本因为格式本来就是同一套。3. 引导编排模式把“自然语言用例”变成可回放脚本的实操细节3.1 从需求文本到Page Object的生成链路引导编排模式的输入通常是这样的句子“启动App进入首页未登录状态下点击我的订单应该跳转到登录页”。要把它变成可执行脚本不能只靠LLM一次输出因为缺少页面结构信息。我设计的链路是需求文本 - 场景解析 - 页面匹配 - 动作序列生成 - 静态校验 - 回放。场景解析阶段LLM会把一段自然语言拆成“页面”、“动作”、“断言”三个关键元素。页面匹配阶段系统会拿解析出来的页面名去匹配现有的页面模型库。这个模型库类似传统测试里的Page Object但每条记录不只有控件ID还有控件的语义描述、常见别名、截图样本。如果匹配不到目标页面系统会让LLM基于当前屏幕快照来补建页面模型。这里有一个容易被忽略的细节LLM生成的步骤序列在真正执行前必须做静态校验。比如检查步骤里有没有不存在的页面名动作类型是否在允许列表中引用的语义描述是否在页面模型库中注册过。静态校验能拦掉大部分明显错误避免把问题拖到执行阶段才暴露。我实际用下来这个链路中“页面匹配”是最大的瓶颈。页面模型库越完整LLM生成的脚本越靠谱。所以团队会花时间把核心流程的页面模型先录全再让LLM去扩场景。模型库稀烂时LLM生成脚本的准确率会直线下降这个锅不能让模型背。3.2 元素定位的“语义优先 视觉兜底”策略移动端控件定位传统做法是依赖resource-id、XPath、text属性。这些属性在跨平台工程里经常不稳定。ARTEMIS在引导模式里使用了三级定位策略。第一级是语义定位。由LLM把步骤里的“账号输入框”转换成一句可计算的语义表达式然后遍历当前控件树找到文本、描述、类型都匹配的控件。第二级是视觉定位。如果语义匹配不到就使用截图区域识别通过OCR或者图像模板匹配找到对应的点击区域。第三级是属性定位。最后才退回到resource-id、content-desc等属性匹配。每一步执行前系统会计算一个“匹配置信度”。置信度高于阈值直接执行低于阈值但高于某条安全线执行后增加额外断言校验如果太低就会暂停并把截图发给LLM让它重新理解目标到底在哪里。这套策略的实际效果是ID变了不一定挂脚本只要语义描述没有变仍然有大概率定位成功。我自己踩过最深的坑是语义描述可能因为场景不同产生歧义。比如“点击提交按钮”在支付页和表单页分别对应不同按钮。所以语义定位不能只靠一句话必须结合当前页面名称和上下文。ARTEMIS在生成语义表达式时会把页面名作为前缀比如“登录页-提交按钮”这样能大幅降低歧义。3.3 稳定性的关键每一步都要有“预期状态”很多测试脚本只在最后做一个断言中间过程不设防。这种做法在页面结构稳定的老系统里还行但移动端页面加载是异步的、控件出现是动态的很容易出现“元素还没出现就点击了结果点击落空”的偶发失败。ARTEMIS的要求是每一步执行后都要校验“预期状态”。这个预期状态不是写死一段代码而是一个状态锚点支持文本出现、控件可用、页面出现特定组件、网络请求完成等类型。如果状态锚点在超时时间内没有满足系统会先按预设策略重试重试两次仍失败就把截图和当前步骤发送给LLM让它判断是控件定位错了、加载太慢还是业务流程真的出了问题。比如点击登录按钮之后可以定义一个锚点specs: - scene: 登录页 step: 点击登录按钮 wait: type: text value: 欢迎回来 timeout: 20 on_timeout: strategy: llm_analyze fallback: screenshot_action这个做法的代价是每个步骤都要多写一点配置换来的是执行稳定性提升。我把一组核心回归用例从平均85%的通过率拉到了97%以上靠的就是把“执行动作”和“确认结果”绑在一起。3.4 脚本回放时为什么默认不调用LLM有人问既然都用了LLM为什么回放时不每一步都让模型看一眼我的回答是成本和确定性都不允许。模型调用延迟通常在1到3秒一个流程30步每步都调用光模型耗时就要一两分钟这还不算超时重试。而且模型输出具有随机性同样的情况这次判断是重试下次可能是失败回放结果无法稳定。所以ARTEMIS把LLM定位成“离线和异常时介入”。离线生成脚本时你想怎么调都行回放时只有遇到未预期的异常才激活LLM分析。这也意味着引导模式在正常执行路径上是一套纯传统的自动化框架可控、快速、结果可复现。LLM只是让这套传统框架不再那么脆弱。这里有个反直觉的经验越是关键的回归场景越不应该让LLM频繁参与执行。把LLM用在异常分析和脚本生成阶段效果远比让它当“现场指挥官”好。4. 自主探索模式让LLM Agent“摸着屏幕找问题”的工程化解法4.1 屏幕感知不只是截图还有“语义快照”探索模式的最大特点是要让模型理解“当前屏幕是什么”。直接截图丢给模型当然可行但问题很多截图文件大传输慢同一个页面不同主题下视觉差异大截图看不到可访问性属性比如控件的类型、是否可点击、是否被禁用。所以ARTEMIS会同时抓取控件树、OCR文本、截图缩略图和设备状态组合成一个压缩后的语义快照。语义快照并不是把原始XML堆在一起。XML太冗长有大量无意义节点直接丢给模型会浪费token还会让模型抓不住重点。ARTEMIS会经过一个清洗和摘要过程去掉invisible节点合并同类嵌套提取关键控件的信息最后输出一段自然语言描述比如“页面顶部有搜索框中间是商品卡片列表底部有Tab栏当前有一个登录弹窗”。这个过程很像人看屏幕时的大脑处理你不会关注每一个像素而是快速抓住核心区域和交互元素。给模型的输入越接近这种“已整理好的认知”模型的决策质量越高。我在探索模式上线初期直接把控件树丢给模型准确率只有60%左右改成语义快照后决策准确率提升到了80%以上token消耗还下降了一半。4.2 动作决策与“结构化约束”探索模式里让LLM直接输出“我想点击某个坐标”是非常危险的。坐标会随屏幕大小变化而且模型对坐标的感知并不精确。ARTEMIS把动作空间限制在一个白名单里tap、swipe、input、back、wait、open_url、stop。每个动作的目标必须来自当前语义快照中列出的元素。同时模型不能自由输出一段话必须输出JSON包含四个字段reason、action、target、expected。{ reason: 当前页面出现登录弹窗先关闭弹窗才能继续操作, action: tap, target: 关闭按钮, expected: 登录弹窗消失 }这个约束的意义不只是格式统一更重要的是给后续执行器和异常分类器提供结构化信息。reason字段可以用来审计模型的决策逻辑expected字段可以用来校验动作是否真正起到了预期效果。如果执行后页面状态不符合expected系统就可以判断“这一步执行失败”而不需要等下一步才发现问题。动作空间白名单还有一个隐藏好处避免模型做出破坏性操作比如反复横滑、连点、跳到系统设置。系统状态机也会拦截一些明显不合法的动作比如当前页面根本没有target元素或者重复执行和上一个完全相同的动作。4.3 探索任务的上下文与记忆自主探索模式最典型的问题是模型会“失忆”。它在第10步可能完全忘记自己第3步已经访问过某个页面导致绕圈子重复操作。我见过一次探索任务在同一个页面来回点了8次白白浪费了十几分钟。ARTEMIS在决策层引入了一个“上下文环”包含三块内容最近N步的操作摘要、已访问页面指纹、当前覆盖率地图。页面指纹由关键控件列表加布局哈希生成可以用来判断是否进入重复页面。当模型尝试连续多次跳转到一个已经访问过的页面时系统会给它一个警告并把它的注意力引向未覆盖区域。上下文环不是简单地存一堆历史记录而是在每次决策前由系统动态生成一段摘要塞进Prompt里。例如“你已经完成了首页、分类页、商品列表页的探索当前处于购物车页之前未尝试过清空购物车操作”。这种摘要比原始历史列表更高效模型不用自己从大量日志里找规律。4.4 失败到底算不算Bug异常分类器探索模式执行过程中会遇到大量非预期状态网络请求失败、权限弹窗、广告页遮挡、用户被强制登出、WebView白屏。这些不一定都是被测App的Bug有可能只是环境干扰。如果全部当Bug上报会淹没真正的问题。ARTEMIS在探索模式后面接了一个异常分类器。它先用规则过滤常见干扰权限弹窗、系统弹窗、网络超时时直接按预定策略处理比如点掉弹窗、等待重试。过滤不掉的状态再交给LLM结合截图和操作上下文判断是稳定的可复现问题还是偶发的环境异常。LLM的结论只能写“疑似问题”或“环境异常”且必须附带理由。这样可以控制误报率。我自己的经验是规则和LLM的结合顺序很重要。规则在前能把60%到70%的干扰直接消掉LLM只需要处理剩余的高难度样本整体成本会低很多。如果所有异常都让LLM判断Prompt一复杂准确率反而下降。5. 双模式协同与切换如何避免“两套系统各干各的”5.1 模式选择规则双模式不是让用户手动选而是通过调度层根据任务特征自动路由。我总结了一套简单的选择规则。如果任务的输入是明确的业务场景有固定路径可走同时这次执行是为了回归验证那么走引导编排模式。如果任务是开放式的“找问题”比如新版本上线前的探索、跨机型兼容验证或者测试人员自己也不确定应该有哪条路径那么走探索模式。更具体一点调度层会看三个维度任务确定性、覆盖目标、历史执行频率。历史执行频率高、路径稳定的任务直接命中引导模式针对新功能的探索性任务命中探索模式。这套规则写在一个配置里测试人员只需要创建一个测试任务系统决定用哪种模式去执行。我见过很多团队把模式选择做成人脸识别一样的“智能”方案其实没必要。测试任务在创建时就已经带有语义标签调度层做的就是标签映射。5.2 从探索模式发现的路径自动沉淀为引导模式用例双模式协同最有价值的部分不是并行跑两个任务而是探索模式的产出能反哺引导模式。探索模式运行时每一条操作轨迹都会被记录成中间表示。当它在某个页面上发现了异常并且经过人工确认为真实Bug之后系统会把这条轨迹提取出来生成一个引导模式的回归用例模板自动补充到回归集里。比如探索模式发现“从个人中心连续更换三次头像后页面出现崩溃”那它记录的轨迹就是点击个人中心-点击头像-选择相册-确认裁剪-保存-再次更换头像。这段轨迹可以一键转换成引导模式脚本后续每个版本都跑一遍验证这个Bug不会复发。这个闭环需要前面提到的统一中间表示作为基础。如果两个模式的数据格式不一致轨迹转换就要写专门的适配层麻烦且容易出错。统一中间表示在这里发挥了真正的作用。5.3 切换时的上下文传递还有一种更细粒度的切换发生在任务执行中途。比如引导模式执行到第5步失败系统让LLM分析后发现继续往下走可能需要尝试一些没有预设的路径这时候会临时从“引导执行”切换成“局部探索”。切换时需要把当前页面状态、已执行步骤、失败上下文全部传给探索模块探索完成后再把新发现的稳定路径交给引导模式继续执行。这个切换过程本质上只是换一个决策策略底层的感知层和执行层可以无缝复用。如果当初没有做分层设计这种切换会非常痛苦。实际实现时只要在中间表示里增加一个“session_id”字段把上下文挂到这个ID下面两个模式共享读取就能完成。6. 落地过程中的常见问题与避坑实录6.1 元素识别不准先别急着换模型探索模式跑起来后最频繁出现的问题是“模型说要点击的按钮在执行时找不到”。很多人第一时间会想是不是模型太笨换更大的模型。其实大多数时候问题出在感知层语义快照生成得太晚页面还没加载完控件树里有WebView内容原生层取不到目标元素被遮挡但控件树显示可见。我的排查顺序是先看快照的生成时间是否晚于页面真正渲染完成再看目标元素是否出现在控件树或OCR结果里然后确认目标元素是否被其他控件遮挡。如果快照里根本没有这个元素那问题在感知层不是模型的问题。如果快照里有但模型输出的语义描述无法匹配到元素再考虑调整Prompt或换模型。这个顺序能省掉大量无效的模型调参时间。6.2 任务漂移与无限循环自主探索模式跑久了不可避免会出现任务漂移。最典型的情况是模型被某个吸引眼球的元素带偏比如本来在探索登录流程结果看到推荐商品就开始点商品卡片。刷了十几分钟商品页仍然没进度。我在ARTEMIS里做了三层防护。第一是深度限制一个任务最多只会连续执行N步达到上限后强制总结。第二是循环检测通过页面指纹判断是否在重复访问同一个页面如果连续几次都停留在同一区域就触发“随机回退”动作跳到之前没访问过的分支。第三是目标Prompt定期注入每隔10步重新提醒模型原始任务目标是什么让它不要忘记初心。有一次内部演示探索任务在购物车页面反复点击“推荐商品”跳转出去然后又回到购物车循环了6次。加上循环检测后系统会在检测到页面指纹重复时自动选择“返回购物车”以外的动作问题立刻解决。6.3 权限弹窗和系统级UI的干扰移动端测试逃不掉权限弹窗。定位权限、通知权限、相机权限一弹出来就可能中断当前操作。如果让模型自己去理解弹窗不仅浪费token还可能误点“不允许”导致后面流程不可用。ARTEMIS维护了一张“系统级干扰元素黑名单”把所有常见权限弹窗的允许按钮和关闭按钮都加入规则处理器。规则处理器优先级高于LLM任何动作执行前都会先判断当前屏幕是否有系统弹窗有的话先处理弹窗再继续原动作。这个处理对iOS和Android都适用而且不需要模型参与。实践中这个规则处理掉了70%以上的弹窗干扰剩余的罕见弹窗才交给LLM临场判断。6.4 成本控制调用量如何从每分钟上百次降下来探索模式下模型调用频率会非常高。最初版本的探索模式一个任务每步决策大概要调用一次模型再加上异常分类每分钟可能产生几十上百次调用。长期跑下去成本压力很大。我用三个办法把成本压了下来。第一是语义快照缓存同一个页面的快照生成一次短时间内重复访问直接复用。第二是决策摘要裁剪控制历史记录和上下文长度不让Prompt无限膨胀。第三是异常分类的规则前置前面已经提过大量异常直接用规则处理不需要模型介入。优化后一次典型的探索任务模型调用量减少了大约60%而覆盖率没有明显下降。7. 实测效果与调优心得7.1 内部测评用哪几个维度和数据为了评估ARTEMIS我在某内部模拟项目上做了一轮对照测试。用同一组移动端测试需求分别用传统脚本方式和ARTEMIS引导模式来做。结果很明显用例编写时间从平均每条40分钟降到6分钟日常回归用例的通过率从85%提升到97%。在探索模式方面跑完一个新版本的核心功能遍历平均能发现3到5个潜在问题其中大约一半是传统手工回归可能漏掉的。这套数据并不代表所有项目都能达到但至少说明方向是对的。关键是评测维度要定好脚本产出速度、维护成本、执行稳定性、发现Bug数量、每任务模型调用成本。只看单一指标很容易被带偏。7.2 Prompt设计的几个关键细节Prompt设计在整个落地过程中占据的权重可能比你想象的要高。我总结了几个值得注意的点。第一引导模式和探索模式要使用完全不同的System Prompt不要共用一套。引导模式强调“严格按需求生成步骤不要自由发挥”探索模式强调“尽可能探索不同分支发现异常”。第二所有输出都必须限定为JSON格式并且给出一个具体的few-shot示例模型会更听话。第三不要让模型直接输出坐标或XPath而是输出语义目标定位交给执行层。第四模型给出的“reason”字段千万不要省它是后续排查问题的主要线索。有一次我把探索模式的Prompt写得太开放结果模型开始输出英文散文式的行为解释解析器崩溃了好几次。加了JSON格式限定和示例后问题立刻消失。7.3 给想复刻的朋友一个建议清单如果你也想搭建类似的双模式架构我有几个优先级建议。先把引导模式跑通再碰探索模式。引导模式相对可控能让你快速验证LLM在用例生成和异常分析上的价值。接着一定要先定义好中间表示哪怕一开始很简单也不要跳过。没有唯一的数据格式后面做轨迹沉淀会非常痛苦。然后日志系统要完整记录原始截图、语义快照、模型输入输出不能只存最终结果。否则遇到问题连复盘都无从下手。最后对LLM的成本要有提前预估在架构设计阶段就引入缓存和规则前置否则跑起来之后成本会吓到你。最后再分享一点我个人最大的体会。LLM自动化测试能不能落地关键其实不在于模型本身有多强而在于你有多了解自己的测试流程。ARTEMIS的双模式本质上是在“机器自动性”和“人工可预期”之间做妥协引导模式负责把人已经验证过的路径固定下来探索模式负责让人重新审视那些没走过的路。如果你也想做类似的东西建议从小而稳的需求开始把一条主流程完整跑通再慢慢扩大模式范围。这个系统的后续扩展空间其实很大比如把探索模式发现的问题自动聚类成风险报告或者根据代码版本差异自动推荐回归用例集都是可以继续深挖的方向。这些内容后面的系列里我再慢慢填。 
长河君 · 2026/10/22 11:34:35 · 阅读 1.2k LLM自动化测试双模式架构：移动端回归与探索的工程实践
移动端自动化测试的朋友应该都有过类似经历脚本越写越多维护成本却一路走高。每次App发版最先挂掉的不一定是业务代码反而是那堆写满控件ID的测试用例。控件一改、页面一重构、动态弹窗一挡几十条用例就当场报废。我最近在团队内部落地了一套代号为ARTEMIS的LLM自动化测试体系核心方向就是移动端自动化。这一篇是这个系列的第5篇也是移动端自动化的第一篇重点拆解ARTEMIS的双模式架构。如果你是做测试开发、质量平台或者正在纠结怎么把LLM真正用到自动化测试里而不是停留在写PPT阶段这篇文章应该能给你一个具体的架构参考。这套双模式架构并不复杂一句话概括一个是“引导编排模式”管稳定回归一个是“自主探索模式”管探索未知问题。两个模式共用一套中间表示既能各自独立运转又能互相转化结果。下面我从设计思路、实现细节、踩坑经历三个层面把这套架构的里子翻出来聊一聊。1. 移动端自动化测试的痛点以及LLM为什么不只是噱头1.1 传统脚本维护的“隐形债务”到底有多大很多人一开始觉得自动化测试难难在写脚本。真正干过之后才发现写脚本只是入门维护脚本才是无底洞。我见过一个模拟项目X的移动端测试仓库版本发布之后600多条用例里有80多条失效原因无非是控件ID变更、页面层级重构、某些功能从入口改到了更深位置。每条失效用例平均要花20到40分钟定位原因再花10到20分钟修改。一个版本下来光修脚本就要占掉一个人两三天的工作量。移动端和Web端相比这个问题更严重。Web端的DOM结构相对稳定至少还有个id能兜底移动端的控件树经过原生渲染和跨平台框架转换之后原始ID经常丢失、被篡改甚至同一控件的resource-id在不同Android版本上都不一样。再加上iOS和Android两套系统并存测试脚本往往要写两套维护量直接翻倍。这种“隐形债务”平时没人提但每个迭代周期都在消耗时间。传统方案也不是没有尝试过比如图像识别、可视化回归、录制回放。但图像识别遇到主题换肤就废录制回放遇到动态页面就断而且这些方案都缺少一个关键能力理解页面变化背后的语义。同一块“登录按钮”从坐标(100, 200)移动到(300, 400)在人类测试工程师眼里还是同一个按钮但在传统脚本里就是一次失效。LLM恰好能在这个语义层面发力。1.2 LLM在自动化测试里真正能发力的三个环节先说结论我并不是把LLM当成一个什么都能干的Agent来用而是把它拆成三个具体角色用例生成器、元素定位器、异常分析器。第一个环节是用例生成。传统测试用例是写在Excel或用例管理平台里的自然语言要变成自动化脚本靠的是人去翻译。LLM可以直接把自然语言需求转成可执行的步骤序列至少省掉“翻译”这一步。第二个环节是元素定位。与其写死一句复杂的XPath不如让LLM理解“点击页面底部的登录按钮”这种语义描述再结合当前屏幕的控件树动态推断出目标元素。它不依赖具体IDID变了也能通过语义找到。第三个环节是异常分析。脚本执行过程中遇到弹窗、加载失败、网络超时以前只能靠硬编码规则去猜测现在可以让LLM看截图和状态信息像测试工程师一样判断是继续、重试还是报失败。这三个环节不一定都需要在线调用模型。比如用例生成可以离线做生成完固定下来元素定位只需要在运行时调用一次异常分析则是在失败发生时兜底使用。这样拆分的价值在于LLM不是在所有环节都介入而是“按需介入”既控制了成本又把易失效的部分变成了可应对的变化点。1.3 为什么必须设计成双模式而不是一个Agent解决所有问题我在项目初期也想过能不能直接做一个通用Agent给它一个目标让它自己在手机上点来点去把所有测试都搞定。实际跑了几轮之后发现这种“全知全能Agent”在真实移动端测试里根本不现实。原因有三个。第一是可控性差。回归测试要求每次执行结果可复现一个自由发挥的Agent上一次走流程A下一次走流程B脚本结果对不上你根本没法判断是业务问题还是Agent路径漂移。第二是成本高。探索模式下每一步操作都要调用模型思考一个完整流程动辄几十步模型调用数量膨胀得很厉害时间成本和费用都兜不住。第三是稳定性和发现能力天然冲突。稳定意味着严格按照预期路径执行而发现新问题往往需要脱离预期路径去乱跑。这两个目标放在同一个Agent里很容易互相干扰。所以我把执行过程拆成两个模式引导编排模式偏向“确定性”自主探索模式偏向“未知发现”。两个模式各司其职再通过调度层按任务类型选择。这样既保证了回归测试的可靠性又保留了探索性测试的价值。这也是ARTEMIS整套架构最核心的设计判断。2. ARTEMIS的双模式架构我到底是怎么拆的2.1 两个模式的定义和分工引导编排模式我习惯叫它Guided Mode。它的工作方式是测试人员用自然语言描述一个业务场景ARTEMIS把场景解析成可回放的脚本脚本由若干步骤构成步骤包含动作、目标、预期状态。执行时每一步都走固定逻辑正常情况不调用LLM只有遇到异常或断言失败时才让LLM介入分析。这个模式适合冒烟测试、回归测试目标是验证已知功能是否正常。自主探索模式也就是Explorer Mode。它更接近一个真正的Agent系统把当前屏幕的语义快照发给LLMLLM输出下一步动作执行完后再次抓取快照循环往复。它不需要预设脚本只需要一个目标比如“尝试完成从首页到下单的流程”或者“逛遍所有设置页”。这个模式适合探索性测试、兼容性测试目标是发现预期之外的崩溃、卡顿和逻辑漏洞。两个模式的分工用一张表可以看得很清楚维度引导编排模式自主探索模式适用场景回归测试、冒烟测试探索性测试、兼容性测试执行速度快正常流程无LLM调用慢每步决策都可能调用LLMLLM参与时机生成脚本时 异常时每一步决策时执行稳定性高路径固定中存在漂移可能核心目标验证已知功能发现未知问题产出物可回放脚本操作轨迹 发现的问题这张表基本上就是双模式架构的顶层需求。后面所有实现都是围绕这些差异点展开的。2.2 整体分层感知层、决策层、执行层、闭环层ARTEMIS不是简单地在测试框架上套一个模型而是分成了四层第一层是感知层。负责采集屏幕截图、控件树、OCR文本、设备状态、手势信息等然后清洗、去重、压缩成一个结构化的“语义快照”。这层是双模式共用的无论哪个模式首先都要“看清楚”当前页面长什么样。第二层是决策层。根据任务类型选择走哪个模式在引导模式下负责把需求变成步骤序列在探索模式下负责把语义快照变成下一步动作。决策层是LLM能力最集中的地方。第三层是执行层。负责把决策层给出的动作翻译成真实的设备操作比如点击、滑动、输入、返回同时处理等待、重试、超时等执行细节。这里不引入LLM保证执行速度和可靠性。第四层是闭环层。负责把执行结果收集起来做覆盖率分析、失败分类、轨迹回放并且把探索模式中发现的新路径沉淀成引导模式的用例。没有这一层双模式只是两个孤立的工具有了这一层双模式才能形成循环。用生活化的类比理解感知层是眼睛和耳朵决策层是大脑执行层是手闭环层是记忆和复盘。大脑虽然聪明但没有记忆和复盘同样的错误会反复犯。这也是很多团队的AI测试Agent跑不起来的原因——只做了前三层忘了第四层。2.3 双模式如何共用一个“中间表示”双模式最怕的问题是两套逻辑各写各的数据格式对不上最后变成两个独立系统。我在设计ARTEMIS时第一步就是定义统一的中间表示IR。简单说所有动作、状态、预期结果都统一描述成一种结构化的JSON格式。举个例子一段引导模式生成的脚本可能长这样{ task: 登录流程回归, steps: [ {action: tap, target: 账号输入框, semantic: true}, {action: input, text: test_user, target: 账号输入框}, {action: tap, target: 登录按钮}, {action: wait, condition: 主页加载完成, timeout: 15} ], assert: 页面上出现用户头像 }探索模式的每一步动作也会被记录成类似的结构只是额外增加“reason”字段用来保存模型当时为什么做这个动作。统一中间表示的好处非常明显执行器只需要实现一份报告系统只解析一份失败分类器只消费一份。更重要的是后续可以让探索模式产出的轨迹直接转换成引导模式能够回放的脚本因为格式本来就是同一套。3. 引导编排模式把“自然语言用例”变成可回放脚本的实操细节3.1 从需求文本到Page Object的生成链路引导编排模式的输入通常是这样的句子“启动App进入首页未登录状态下点击我的订单应该跳转到登录页”。要把它变成可执行脚本不能只靠LLM一次输出因为缺少页面结构信息。我设计的链路是需求文本 - 场景解析 - 页面匹配 - 动作序列生成 - 静态校验 - 回放。场景解析阶段LLM会把一段自然语言拆成“页面”、“动作”、“断言”三个关键元素。页面匹配阶段系统会拿解析出来的页面名去匹配现有的页面模型库。这个模型库类似传统测试里的Page Object但每条记录不只有控件ID还有控件的语义描述、常见别名、截图样本。如果匹配不到目标页面系统会让LLM基于当前屏幕快照来补建页面模型。这里有一个容易被忽略的细节LLM生成的步骤序列在真正执行前必须做静态校验。比如检查步骤里有没有不存在的页面名动作类型是否在允许列表中引用的语义描述是否在页面模型库中注册过。静态校验能拦掉大部分明显错误避免把问题拖到执行阶段才暴露。我实际用下来这个链路中“页面匹配”是最大的瓶颈。页面模型库越完整LLM生成的脚本越靠谱。所以团队会花时间把核心流程的页面模型先录全再让LLM去扩场景。模型库稀烂时LLM生成脚本的准确率会直线下降这个锅不能让模型背。3.2 元素定位的“语义优先 视觉兜底”策略移动端控件定位传统做法是依赖resource-id、XPath、text属性。这些属性在跨平台工程里经常不稳定。ARTEMIS在引导模式里使用了三级定位策略。第一级是语义定位。由LLM把步骤里的“账号输入框”转换成一句可计算的语义表达式然后遍历当前控件树找到文本、描述、类型都匹配的控件。第二级是视觉定位。如果语义匹配不到就使用截图区域识别通过OCR或者图像模板匹配找到对应的点击区域。第三级是属性定位。最后才退回到resource-id、content-desc等属性匹配。每一步执行前系统会计算一个“匹配置信度”。置信度高于阈值直接执行低于阈值但高于某条安全线执行后增加额外断言校验如果太低就会暂停并把截图发给LLM让它重新理解目标到底在哪里。这套策略的实际效果是ID变了不一定挂脚本只要语义描述没有变仍然有大概率定位成功。我自己踩过最深的坑是语义描述可能因为场景不同产生歧义。比如“点击提交按钮”在支付页和表单页分别对应不同按钮。所以语义定位不能只靠一句话必须结合当前页面名称和上下文。ARTEMIS在生成语义表达式时会把页面名作为前缀比如“登录页-提交按钮”这样能大幅降低歧义。3.3 稳定性的关键每一步都要有“预期状态”很多测试脚本只在最后做一个断言中间过程不设防。这种做法在页面结构稳定的老系统里还行但移动端页面加载是异步的、控件出现是动态的很容易出现“元素还没出现就点击了结果点击落空”的偶发失败。ARTEMIS的要求是每一步执行后都要校验“预期状态”。这个预期状态不是写死一段代码而是一个状态锚点支持文本出现、控件可用、页面出现特定组件、网络请求完成等类型。如果状态锚点在超时时间内没有满足系统会先按预设策略重试重试两次仍失败就把截图和当前步骤发送给LLM让它判断是控件定位错了、加载太慢还是业务流程真的出了问题。比如点击登录按钮之后可以定义一个锚点specs: - scene: 登录页 step: 点击登录按钮 wait: type: text value: 欢迎回来 timeout: 20 on_timeout: strategy: llm_analyze fallback: screenshot_action这个做法的代价是每个步骤都要多写一点配置换来的是执行稳定性提升。我把一组核心回归用例从平均85%的通过率拉到了97%以上靠的就是把“执行动作”和“确认结果”绑在一起。3.4 脚本回放时为什么默认不调用LLM有人问既然都用了LLM为什么回放时不每一步都让模型看一眼我的回答是成本和确定性都不允许。模型调用延迟通常在1到3秒一个流程30步每步都调用光模型耗时就要一两分钟这还不算超时重试。而且模型输出具有随机性同样的情况这次判断是重试下次可能是失败回放结果无法稳定。所以ARTEMIS把LLM定位成“离线和异常时介入”。离线生成脚本时你想怎么调都行回放时只有遇到未预期的异常才激活LLM分析。这也意味着引导模式在正常执行路径上是一套纯传统的自动化框架可控、快速、结果可复现。LLM只是让这套传统框架不再那么脆弱。这里有个反直觉的经验越是关键的回归场景越不应该让LLM频繁参与执行。把LLM用在异常分析和脚本生成阶段效果远比让它当“现场指挥官”好。4. 自主探索模式让LLM Agent“摸着屏幕找问题”的工程化解法4.1 屏幕感知不只是截图还有“语义快照”探索模式的最大特点是要让模型理解“当前屏幕是什么”。直接截图丢给模型当然可行但问题很多截图文件大传输慢同一个页面不同主题下视觉差异大截图看不到可访问性属性比如控件的类型、是否可点击、是否被禁用。所以ARTEMIS会同时抓取控件树、OCR文本、截图缩略图和设备状态组合成一个压缩后的语义快照。语义快照并不是把原始XML堆在一起。XML太冗长有大量无意义节点直接丢给模型会浪费token还会让模型抓不住重点。ARTEMIS会经过一个清洗和摘要过程去掉invisible节点合并同类嵌套提取关键控件的信息最后输出一段自然语言描述比如“页面顶部有搜索框中间是商品卡片列表底部有Tab栏当前有一个登录弹窗”。这个过程很像人看屏幕时的大脑处理你不会关注每一个像素而是快速抓住核心区域和交互元素。给模型的输入越接近这种“已整理好的认知”模型的决策质量越高。我在探索模式上线初期直接把控件树丢给模型准确率只有60%左右改成语义快照后决策准确率提升到了80%以上token消耗还下降了一半。4.2 动作决策与“结构化约束”探索模式里让LLM直接输出“我想点击某个坐标”是非常危险的。坐标会随屏幕大小变化而且模型对坐标的感知并不精确。ARTEMIS把动作空间限制在一个白名单里tap、swipe、input、back、wait、open_url、stop。每个动作的目标必须来自当前语义快照中列出的元素。同时模型不能自由输出一段话必须输出JSON包含四个字段reason、action、target、expected。{ reason: 当前页面出现登录弹窗先关闭弹窗才能继续操作, action: tap, target: 关闭按钮, expected: 登录弹窗消失 }这个约束的意义不只是格式统一更重要的是给后续执行器和异常分类器提供结构化信息。reason字段可以用来审计模型的决策逻辑expected字段可以用来校验动作是否真正起到了预期效果。如果执行后页面状态不符合expected系统就可以判断“这一步执行失败”而不需要等下一步才发现问题。动作空间白名单还有一个隐藏好处避免模型做出破坏性操作比如反复横滑、连点、跳到系统设置。系统状态机也会拦截一些明显不合法的动作比如当前页面根本没有target元素或者重复执行和上一个完全相同的动作。4.3 探索任务的上下文与记忆自主探索模式最典型的问题是模型会“失忆”。它在第10步可能完全忘记自己第3步已经访问过某个页面导致绕圈子重复操作。我见过一次探索任务在同一个页面来回点了8次白白浪费了十几分钟。ARTEMIS在决策层引入了一个“上下文环”包含三块内容最近N步的操作摘要、已访问页面指纹、当前覆盖率地图。页面指纹由关键控件列表加布局哈希生成可以用来判断是否进入重复页面。当模型尝试连续多次跳转到一个已经访问过的页面时系统会给它一个警告并把它的注意力引向未覆盖区域。上下文环不是简单地存一堆历史记录而是在每次决策前由系统动态生成一段摘要塞进Prompt里。例如“你已经完成了首页、分类页、商品列表页的探索当前处于购物车页之前未尝试过清空购物车操作”。这种摘要比原始历史列表更高效模型不用自己从大量日志里找规律。4.4 失败到底算不算Bug异常分类器探索模式执行过程中会遇到大量非预期状态网络请求失败、权限弹窗、广告页遮挡、用户被强制登出、WebView白屏。这些不一定都是被测App的Bug有可能只是环境干扰。如果全部当Bug上报会淹没真正的问题。ARTEMIS在探索模式后面接了一个异常分类器。它先用规则过滤常见干扰权限弹窗、系统弹窗、网络超时时直接按预定策略处理比如点掉弹窗、等待重试。过滤不掉的状态再交给LLM结合截图和操作上下文判断是稳定的可复现问题还是偶发的环境异常。LLM的结论只能写“疑似问题”或“环境异常”且必须附带理由。这样可以控制误报率。我自己的经验是规则和LLM的结合顺序很重要。规则在前能把60%到70%的干扰直接消掉LLM只需要处理剩余的高难度样本整体成本会低很多。如果所有异常都让LLM判断Prompt一复杂准确率反而下降。5. 双模式协同与切换如何避免“两套系统各干各的”5.1 模式选择规则双模式不是让用户手动选而是通过调度层根据任务特征自动路由。我总结了一套简单的选择规则。如果任务的输入是明确的业务场景有固定路径可走同时这次执行是为了回归验证那么走引导编排模式。如果任务是开放式的“找问题”比如新版本上线前的探索、跨机型兼容验证或者测试人员自己也不确定应该有哪条路径那么走探索模式。更具体一点调度层会看三个维度任务确定性、覆盖目标、历史执行频率。历史执行频率高、路径稳定的任务直接命中引导模式针对新功能的探索性任务命中探索模式。这套规则写在一个配置里测试人员只需要创建一个测试任务系统决定用哪种模式去执行。我见过很多团队把模式选择做成人脸识别一样的“智能”方案其实没必要。测试任务在创建时就已经带有语义标签调度层做的就是标签映射。5.2 从探索模式发现的路径自动沉淀为引导模式用例双模式协同最有价值的部分不是并行跑两个任务而是探索模式的产出能反哺引导模式。探索模式运行时每一条操作轨迹都会被记录成中间表示。当它在某个页面上发现了异常并且经过人工确认为真实Bug之后系统会把这条轨迹提取出来生成一个引导模式的回归用例模板自动补充到回归集里。比如探索模式发现“从个人中心连续更换三次头像后页面出现崩溃”那它记录的轨迹就是点击个人中心-点击头像-选择相册-确认裁剪-保存-再次更换头像。这段轨迹可以一键转换成引导模式脚本后续每个版本都跑一遍验证这个Bug不会复发。这个闭环需要前面提到的统一中间表示作为基础。如果两个模式的数据格式不一致轨迹转换就要写专门的适配层麻烦且容易出错。统一中间表示在这里发挥了真正的作用。5.3 切换时的上下文传递还有一种更细粒度的切换发生在任务执行中途。比如引导模式执行到第5步失败系统让LLM分析后发现继续往下走可能需要尝试一些没有预设的路径这时候会临时从“引导执行”切换成“局部探索”。切换时需要把当前页面状态、已执行步骤、失败上下文全部传给探索模块探索完成后再把新发现的稳定路径交给引导模式继续执行。这个切换过程本质上只是换一个决策策略底层的感知层和执行层可以无缝复用。如果当初没有做分层设计这种切换会非常痛苦。实际实现时只要在中间表示里增加一个“session_id”字段把上下文挂到这个ID下面两个模式共享读取就能完成。6. 落地过程中的常见问题与避坑实录6.1 元素识别不准先别急着换模型探索模式跑起来后最频繁出现的问题是“模型说要点击的按钮在执行时找不到”。很多人第一时间会想是不是模型太笨换更大的模型。其实大多数时候问题出在感知层语义快照生成得太晚页面还没加载完控件树里有WebView内容原生层取不到目标元素被遮挡但控件树显示可见。我的排查顺序是先看快照的生成时间是否晚于页面真正渲染完成再看目标元素是否出现在控件树或OCR结果里然后确认目标元素是否被其他控件遮挡。如果快照里根本没有这个元素那问题在感知层不是模型的问题。如果快照里有但模型输出的语义描述无法匹配到元素再考虑调整Prompt或换模型。这个顺序能省掉大量无效的模型调参时间。6.2 任务漂移与无限循环自主探索模式跑久了不可避免会出现任务漂移。最典型的情况是模型被某个吸引眼球的元素带偏比如本来在探索登录流程结果看到推荐商品就开始点商品卡片。刷了十几分钟商品页仍然没进度。我在ARTEMIS里做了三层防护。第一是深度限制一个任务最多只会连续执行N步达到上限后强制总结。第二是循环检测通过页面指纹判断是否在重复访问同一个页面如果连续几次都停留在同一区域就触发“随机回退”动作跳到之前没访问过的分支。第三是目标Prompt定期注入每隔10步重新提醒模型原始任务目标是什么让它不要忘记初心。有一次内部演示探索任务在购物车页面反复点击“推荐商品”跳转出去然后又回到购物车循环了6次。加上循环检测后系统会在检测到页面指纹重复时自动选择“返回购物车”以外的动作问题立刻解决。6.3 权限弹窗和系统级UI的干扰移动端测试逃不掉权限弹窗。定位权限、通知权限、相机权限一弹出来就可能中断当前操作。如果让模型自己去理解弹窗不仅浪费token还可能误点“不允许”导致后面流程不可用。ARTEMIS维护了一张“系统级干扰元素黑名单”把所有常见权限弹窗的允许按钮和关闭按钮都加入规则处理器。规则处理器优先级高于LLM任何动作执行前都会先判断当前屏幕是否有系统弹窗有的话先处理弹窗再继续原动作。这个处理对iOS和Android都适用而且不需要模型参与。实践中这个规则处理掉了70%以上的弹窗干扰剩余的罕见弹窗才交给LLM临场判断。6.4 成本控制调用量如何从每分钟上百次降下来探索模式下模型调用频率会非常高。最初版本的探索模式一个任务每步决策大概要调用一次模型再加上异常分类每分钟可能产生几十上百次调用。长期跑下去成本压力很大。我用三个办法把成本压了下来。第一是语义快照缓存同一个页面的快照生成一次短时间内重复访问直接复用。第二是决策摘要裁剪控制历史记录和上下文长度不让Prompt无限膨胀。第三是异常分类的规则前置前面已经提过大量异常直接用规则处理不需要模型介入。优化后一次典型的探索任务模型调用量减少了大约60%而覆盖率没有明显下降。7. 实测效果与调优心得7.1 内部测评用哪几个维度和数据为了评估ARTEMIS我在某内部模拟项目上做了一轮对照测试。用同一组移动端测试需求分别用传统脚本方式和ARTEMIS引导模式来做。结果很明显用例编写时间从平均每条40分钟降到6分钟日常回归用例的通过率从85%提升到97%。在探索模式方面跑完一个新版本的核心功能遍历平均能发现3到5个潜在问题其中大约一半是传统手工回归可能漏掉的。这套数据并不代表所有项目都能达到但至少说明方向是对的。关键是评测维度要定好脚本产出速度、维护成本、执行稳定性、发现Bug数量、每任务模型调用成本。只看单一指标很容易被带偏。7.2 Prompt设计的几个关键细节Prompt设计在整个落地过程中占据的权重可能比你想象的要高。我总结了几个值得注意的点。第一引导模式和探索模式要使用完全不同的System Prompt不要共用一套。引导模式强调“严格按需求生成步骤不要自由发挥”探索模式强调“尽可能探索不同分支发现异常”。第二所有输出都必须限定为JSON格式并且给出一个具体的few-shot示例模型会更听话。第三不要让模型直接输出坐标或XPath而是输出语义目标定位交给执行层。第四模型给出的“reason”字段千万不要省它是后续排查问题的主要线索。有一次我把探索模式的Prompt写得太开放结果模型开始输出英文散文式的行为解释解析器崩溃了好几次。加了JSON格式限定和示例后问题立刻消失。7.3 给想复刻的朋友一个建议清单如果你也想搭建类似的双模式架构我有几个优先级建议。先把引导模式跑通再碰探索模式。引导模式相对可控能让你快速验证LLM在用例生成和异常分析上的价值。接着一定要先定义好中间表示哪怕一开始很简单也不要跳过。没有唯一的数据格式后面做轨迹沉淀会非常痛苦。然后日志系统要完整记录原始截图、语义快照、模型输入输出不能只存最终结果。否则遇到问题连复盘都无从下手。最后对LLM的成本要有提前预估在架构设计阶段就引入缓存和规则前置否则跑起来之后成本会吓到你。最后再分享一点我个人最大的体会。LLM自动化测试能不能落地关键其实不在于模型本身有多强而在于你有多了解自己的测试流程。ARTEMIS的双模式本质上是在“机器自动性”和“人工可预期”之间做妥协引导模式负责把人已经验证过的路径固定下来探索模式负责让人重新审视那些没走过的路。如果你也想做类似的东西建议从小而稳的需求开始把一条主流程完整跑通再慢慢扩大模式范围。这个系统的后续扩展空间其实很大比如把探索模式发现的问题自动聚类成风险报告或者根据代码版本差异自动推荐回归用例集都是可以继续深挖的方向。这些内容后面的系列里我再慢慢填。