企业官网建设流程全解析

移动端自动化测试的朋友应该都有过类似经历：脚本越写越多，维护成本却一路走高。每次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理解“点击页面底部的登录按钮”这种语义描述，再结合当前屏幕的控件树，动态推断出目标元素。它不依赖具体ID，ID变了也能通过语义找到。第三个环节是异常分析。脚本执行过程中遇到弹窗、加载失败、网络超时，以前只能靠硬编码规则去猜测，现在可以让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：系统把当前屏幕的语义快照发给LLM，LLM输出下一步动作，执行完后再次抓取快照，循环往复。它不需要预设脚本，只需要一个目标，比如“尝试完成从首页到下单的流程”或者“逛遍所有设置页”。这个模式适合探索性测试、兼容性测试，目标是发现预期之外的崩溃、卡顿和逻辑漏洞。

两个模式的分工用一张表可以看得很清楚：

这张表基本上就是双模式架构的顶层需求。后面所有实现，都是围绕这些差异点展开的。

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的双模式本质上是在“机器自动性”和“人工可预期”之间做妥协：引导模式负责把人已经验证过的路径固定下来，探索模式负责让人重新审视那些没走过的路。如果你也想做类似的东西，建议从小而稳的需求开始，把一条主流程完整跑通，再慢慢扩大模式范围。这个系统的后续扩展空间其实很大，比如把探索模式发现的问题自动聚类成风险报告，或者根据代码版本差异自动推荐回归用例集，都是可以继续深挖的方向。这些内容，后面的系列里我再慢慢填。