企业官网建设流程全解析

1. 移动端自动化测试的现状与角色级模型拆分的由来

移动端自动化测试这个领域，做了几年的人都有一个共同的感受：脚本写得越多，维护成本越高。早期大家用 Appium、UiAutomator、XCUITest 这些框架，靠元素定位和固定断言来驱动测试流程，一套用例写完，UI 一改，定位全废。后来有人尝试用图像识别、OCR 来兜底，但识别率和执行速度又成了新瓶颈。直到大语言模型的能力逐渐成熟，大家开始琢磨：能不能让模型直接“看懂”屏幕，然后决定下一步该点哪里、输入什么、断言什么？

这个思路听起来很美好，但真正落地的时候，第一个撞上的墙就是：一个通用大模型，既要理解当前页面的语义，又要判断操作意图，还要生成具体的点击坐标或元素选择器，任务太杂，效果很不稳定。于是，角色级模型拆分就成了一个非常自然的选择。所谓角色级拆分，就是不再让一个模型包揽所有事情，而是把移动端自动化测试的完整链路拆成几个独立的角色，每个角色只负责一类明确的判断或生成任务，各自用最适合的模型来承担。

这个思路其实和软件工程里的单一职责原则是一脉相承的。你让一个模型同时做“视觉理解”和“操作决策”，它很容易顾此失彼；但如果你把它拆成“页面解析员”“操作决策员”“断言校验员”三个角色，每个角色只关心自己那一亩三分地，准确率和稳定性都会明显提升。DroidRun 和 Mobilerun 这两个项目，就是在这样的背景下，把角色级模型拆分作为核心架构思路来设计的。

我最初接触这套思路的时候，心里也犯嘀咕：拆成多个模型，调用次数多了，延迟会不会爆炸？成本会不会失控？但实际跑下来发现，只要角色划分合理，每个角色的输入输出都做严格约束，整体延迟反而比单模型反复试错要低，因为单模型一旦判断失误，重试的成本更高。而且不同角色可以用不同量级的模型，重的理解任务用大模型，轻的决策任务用小模型，整体成本反而更可控。

这篇文章主要面向已经在做移动端自动化测试、并且对大语言模型应用有一定了解的读者。如果你还在用传统的元素定位方式写用例，看完之后可以思考一下哪些环节适合引入模型能力；如果你已经在尝试用大模型驱动测试，但效果不稳定，那角色级拆分这个思路大概率能帮你解决不少问题。接下来我会从整体设计思路、核心角色拆解、实操落地、常见问题排查几个方面，把 DroidRun/Mobilerun 这套角色级模型拆分的做法讲透。

2. 角色级模型拆分的整体设计思路

2.1 为什么不能用一个模型包打天下

先说说为什么“一个模型包打天下”在移动端自动化测试里行不通。移动端测试的核心链路大致是这样的：截取当前屏幕 → 理解屏幕上有什么 → 决定下一步操作 → 执行操作 → 截取新屏幕 → 判断是否符合预期。如果用一个模型从头做到尾，它需要同时具备几种差异很大的能力：视觉理解能力，能识别按钮、输入框、列表、弹窗；语义理解能力，能看懂页面上的文字含义；决策能力，能根据测试目标选择下一步动作；生成能力，能输出精确的坐标或选择器；校验能力，能判断当前状态是否满足断言条件。

这几种能力对模型的要求完全不同。视觉理解需要模型有强的多模态能力，决策需要模型有强的推理能力，生成精确坐标需要模型有强的结构化输出能力，校验则需要模型有强的对比判断能力。一个模型很难在所有维度上都做到最优，更麻烦的是，当它同时处理这些任务时，不同任务之间会互相干扰。比如模型在理解页面时可能被无关元素分散注意力，导致决策时选错目标；或者在生成坐标时因为要兼顾语义描述，输出的格式不够精确。

我实测过一个通用多模态模型直接做端到端操作，在简单页面上还能应付，一旦页面元素超过二十个，或者出现嵌套滚动、动态加载的情况，它的操作准确率就掉得厉害。而且失败之后你很难定位问题出在哪一环，是没看清页面，还是看懂了但决策错了，还是决策对了但坐标生成偏了。这种黑盒式的失败，在测试场景里是非常致命的，因为你没法针对性地优化。

2.2 角色拆分的核心原则与边界划定

角色级模型拆分的核心原则就一条：每个角色只做一件事，并且这件事的输入输出边界必须非常清晰。具体来说，拆分的时候要遵循几个原则。

第一，按“认知阶段”拆分，而不是按“功能模块”拆分。认知阶段指的是从感知到决策到执行的天然流程，比如“页面理解”是一个认知阶段，“操作决策”是另一个，“结果校验”是第三个。按功能模块拆容易拆出重叠，比如“点击操作”和“输入操作”都涉及决策，拆开之后反而要重复理解页面。

第二，每个角色的输出必须是下一个角色可以直接消费的结构化数据。比如页面理解角色的输出应该是一份结构化的页面元素清单，包含每个元素的类型、文本、位置、可交互状态；操作决策角色的输入就是这份清单加上测试目标，输出是一个明确的操作指令，包含操作类型和目标元素标识。这样角色之间通过结构化数据衔接，而不是通过自然语言描述衔接，能大幅降低信息传递的损耗。

第三，角色的粒度要适中。拆得太粗，等于没拆；拆得太细，调用链太长，延迟和成本都受不了。我的经验是，移动端自动化测试拆成三到四个角色比较合适：页面理解、操作决策、结果校验，如果涉及复杂断言，可以再加一个断言生成角色。DroidRun 和 Mobilerun 基本也是这个量级。

第四，每个角色要能独立测试和替换。这是拆分带来的最大好处之一。你可以单独拿一批页面截图来测页面理解角色的准确率，也可以单独拿一批决策场景来测操作决策角色的正确率。哪个角色效果不好，就针对性优化那个角色，换模型、改提示词、加微调，都不会影响其他角色。这种可替换性在工程上非常重要，因为模型迭代速度很快，今天最好的模型明天可能就被超越了，角色边界清晰的话，替换成本很低。

2.3 DroidRun 与 Mobilerun 的角色划分对比

DroidRun 和 Mobilerun 虽然都是角色级拆分思路，但侧重点略有不同。DroidRun 更偏向 Android 端的深度集成，它的角色划分里有一个专门的“设备状态解析”角色，负责处理 Android 特有的 Activity、Fragment、View 层级信息，把系统级的 UI 树和模型看到的截图做对齐。这个角色在纯视觉方案里是不需要的，但因为 Android 的 UI 树信息其实很丰富，善加利用能大幅提升理解准确率。

Mobilerun 则更偏向跨平台的通用方案，它的角色划分更抽象一些，页面理解角色同时处理截图和可访问性树，不区分具体平台。它的操作决策角色支持更丰富的操作类型，包括手势、多指操作、长按拖拽等，适合更复杂的交互场景。

两者共同的核心理念是：页面理解角色负责“看到什么”，操作决策角色负责“做什么”，结果校验角色负责“对不对”。这三个角色的输入输出定义清晰，可以独立演进。下面这张表是我根据实际使用经验整理的对比，供你选型时参考。

选哪个取决于你的测试对象。如果主要是 Android 原生应用，DroidRun 的设备状态解析角色能帮你省不少事；如果要覆盖 iOS 和 Android 两端，Mobilerun 的抽象层更省心。当然，你也可以借鉴两者的思路，自己搭一套适合团队现状的角色拆分方案。

3. 核心角色拆解与实操要点

3.1 页面理解角色：从截图到结构化元素清单

页面理解角色是整个链路的起点，它的任务是把一张屏幕截图（可能还加上 UI 树信息）转换成一份结构化的页面元素清单。这份清单的质量直接决定了后续决策的准确性，所以这个角色值得花最多精力去打磨。

输入方面，最基础的输入是截图。但只靠截图，模型对某些元素的判断会不准，比如一个没有文字只有图标的按钮，模型可能认不出它是按钮。所以实践中通常会加上辅助信息。Android 端可以加 UI 树的节点信息，包括每个节点的类名、文本、内容描述、可点击状态、边界框。iOS 端可以加可访问性树的类似信息。这些辅助信息和截图对齐之后，模型对页面的理解会准确很多。

输出方面，我建议定义一套固定的元素描述格式，每个元素包含这几个字段：元素标识（用序号或稳定 ID）、元素类型（按钮、输入框、文本、图片、列表等）、元素文本（可见文字或内容描述）、元素位置（边界框坐标）、可交互状态（是否可点击、是否可输入、是否可滚动）、以及一个简短的语义描述。这套格式用 JSON 表达最方便，模型也容易生成。

提示词的设计是这个角色的关键。我的经验是，提示词里要明确告诉模型：只输出元素清单，不要做任何操作决策，不要输出多余解释。同时要给几个示例，展示期望的输出格式。示例不用多，两三个覆盖典型页面就行。另外，提示词里要强调“如果某个元素不确定类型，标记为未知，不要猜测”，这样能减少模型瞎编的情况。

实操中有一个坑要注意：模型输出的坐标有时候会超出屏幕范围，或者边界框的格式不统一。我的做法是在提示词里明确坐标系的定义，比如“以屏幕左上角为原点，x 向右，y 向下，单位是像素”，并且在输出后加一层校验，把超出范围的坐标裁剪到屏幕内。这层校验用简单的代码就能做，但能避免很多后续问题。

还有一个经验是，页面理解角色不要追求一次性把所有元素都识别出来。移动端页面经常有滚动区域，一屏之外的元素看不到。我的做法是让页面理解角色只处理当前可见区域，滚动由操作决策角色来决定，滚动之后再重新调用页面理解角色。这样每个角色的职责更单一，准确率也更高。

3.2 操作决策角色：从元素清单到精确操作指令

操作决策角色拿到页面元素清单和当前测试目标之后，要输出一个明确的操作指令。这个角色的难点在于，它需要理解测试目标的语义，并且把它映射到具体的元素和操作上。

输入方面，除了页面元素清单，还需要传入当前测试步骤的目标描述。这个描述可以是自然语言，比如“在搜索框中输入关键词并点击搜索按钮”，也可以是更结构化的形式，比如“操作类型：输入，目标：搜索框，内容：测试关键词”。我倾向于用半结构化的描述，既保留灵活性，又减少模型的歧义。

输出方面，操作指令要包含这几个字段：操作类型（点击、输入、滑动、长按、返回等）、目标元素标识（对应页面理解角色输出的元素序号）、操作参数（输入内容、滑动方向、滑动距离等）、以及一个简短的理由说明。理由说明不是必须的，但在调试的时候非常有用，能帮你快速判断模型为什么选了这个元素。

提示词设计上，关键是要给模型明确的决策优先级。比如：优先选择文本匹配度高的元素；如果有多个候选元素，选择可交互状态为真的那个；如果目标元素不在当前可见区域，输出滚动操作而不是强行点击。这些优先级规则能显著提升决策的合理性。

我实测下来，操作决策角色最容易犯的错误是“选错元素”。比如页面上有两个“确定”按钮，一个在弹窗里，一个在页面底部，模型可能选错。解决这个问题的办法是在页面元素清单里加入层级信息，让模型知道哪个元素属于弹窗，哪个属于主页面。另外，在提示词里可以要求模型在多个候选时输出所有候选并说明选择理由，这样即使选错了，你也能从理由里看出问题所在。

还有一个实用技巧是给操作决策角色加一个“置信度”输出。让模型对自己的决策打一个分，比如高、中、低。对于低置信度的决策，可以触发人工确认或者走备用逻辑。这个机制在关键测试步骤上特别有用，能避免模型在不确定的情况下乱操作导致测试流程跑飞。

3.3 结果校验角色：从截图对比到断言判断

结果校验角色的任务是判断当前页面状态是否满足测试预期。这个角色看起来简单，其实很容易被低估。移动端页面的状态变化很微妙，有时候文字一样但颜色变了，有时候布局微调了但功能正常，模型需要区分“实质性变化”和“无关紧要的变化”。

输入方面，需要传入预期描述和当前页面信息。预期描述可以是“页面应显示搜索结果为‘测试关键词’”，当前页面信息可以是截图加元素清单。我建议同时传入操作前的页面信息和操作后的页面信息，让模型做对比判断，这样比只看操作后的单张截图要准确。

输出方面，校验结果包含这几个字段：是否通过、判断理由、以及如果不通过，具体哪里不符合预期。判断理由要具体，比如“页面显示了‘无搜索结果’提示，与预期的‘显示搜索结果列表’不符”，而不是笼统的“校验失败”。

提示词设计上，要明确告诉模型校验的严格程度。有些测试场景要求精确匹配，有些允许模糊匹配。比如校验一个提示文字，精确匹配要求一字不差，模糊匹配只要语义相近就行。这个严格程度应该作为参数传入，而不是让模型自己猜。

实操中有一个常见问题是模型过于宽松，明明页面没加载出来，它却判断通过了。解决这个问题的办法是在提示词里加入“如果页面处于加载中状态，应判断为不通过”这样的规则。另外，可以让校验角色输出一个“页面状态”字段，标记当前是正常、加载中、错误还是空白，这样即使校验通过，你也能知道页面当时是什么状态。

还有一个经验是，结果校验角色不要和操作决策角色用同一个模型实例。因为操作决策角色有“希望操作成功”的倾向，用它来做校验可能会有确认偏差。用独立的模型实例，甚至用不同厂商的模型，能获得更客观的校验结果。这一点在关键测试用例上尤其重要。

4. 实操落地：从零搭建角色级拆分流程

4.1 环境准备与基础依赖

动手之前，先把环境理清楚。移动端自动化测试的基础设施包括：一台真机或模拟器、ADB 工具（Android）或对应的设备连接工具、截图能力、以及操作注入能力。这些是传统自动化测试就需要的，这里不展开。重点说模型侧的准备。

模型侧你需要至少两个模型接入点：一个多模态模型用于页面理解，一个文本模型用于操作决策和结果校验。多模态模型负责看图，文本模型负责推理。如果你用的模型同时具备多模态和强推理能力，也可以用一个模型加不同提示词来扮演不同角色，但我的建议是至少页面理解和其他角色分开，因为页面理解的输出格式要求很严格，和其他角色的提示词风格差异较大。

依赖管理方面，建议把每个角色的提示词、输入输出格式定义、以及模型调用参数都放在独立的配置文件里。这样调整某个角色的时候不会影响其他角色。配置文件用 YAML 或 JSON 都行，关键是结构清晰。我通常会把每个角色的配置分成三块：模型参数（模型名称、温度、最大输出长度）、提示词模板、输出格式定义。

还有一个容易被忽略的准备是日志系统。角色级拆分之后，一次测试流程会调用多次模型，每次调用的输入输出都要记录下来。没有日志，出了问题你根本不知道是哪个角色、哪次调用出的错。日志里至少要包含：时间戳、角色名称、输入摘要、输出内容、耗时、token 消耗。这些数据不仅能用于排查问题，还能帮你分析成本分布，优化模型选型。

4.2 页面理解角色的实现与调优

页面理解角色的实现，第一步是截图和 UI 树信息的获取。Android 端可以用 ADB 命令截屏，同时用 UiAutomator 获取 UI 树。iOS 端可以用对应的工具获取截图和可访问性树。获取之后，把截图和 UI 树信息一起传给多模态模型。

提示词模板大概长这样：先说明任务，“你是一个移动端页面解析助手，你的任务是分析给定的屏幕截图和 UI 树信息，输出当前页面上所有可交互元素的结构化清单。”然后给出输出格式的 JSON schema，再给两三个示例。最后加上约束条件，“只输出 JSON，不要输出其他内容”“如果元素类型不确定，标记为 unknown”“坐标以屏幕左上角为原点”。

调优的时候，我建议先拿一批典型页面做基准测试。选二十到三十个有代表性的页面，覆盖列表页、详情页、表单页、弹窗、加载状态等。人工标注每个页面的正确元素清单，然后跑模型，对比准确率和召回率。准确率低说明模型输出了不存在的元素，召回率低说明模型漏掉了元素。针对准确率问题，可以在提示词里强调“只输出你确定存在的元素”；针对召回率问题，可以强调“不要遗漏任何可交互元素，包括图标按钮”。

温度参数方面，页面理解角色建议用较低的温度，比如 0.1 到 0.3，保证输出稳定。太高的温度会让模型在元素描述上发挥创意，这对测试场景是灾难。最大输出长度要设够，因为一个复杂页面可能有几十个元素，输出被截断的话后面的元素就丢了。

4.3 操作决策角色的实现与调优

操作决策角色的实现，输入是页面元素清单加测试步骤目标。这里有一个工程上的细节：页面元素清单可能很长，直接塞进提示词会占用大量 token。我的做法是对元素清单做一次预处理，过滤掉明显不可交互的元素（比如纯文本标签、装饰性图片），只保留按钮、输入框、可点击的列表项等。这样能把 token 消耗降下来，同时减少模型的干扰。

提示词模板的核心是决策规则。我会明确列出优先级：第一，如果目标描述中有明确的文本，优先匹配文本相同的元素；第二，如果有多个匹配，选择可交互状态为真的；第三，如果目标元素不在当前清单中，输出滚动操作；第四，如果目标描述模糊，选择最符合语义的元素并输出中等置信度。这些规则用自然语言写在提示词里，模型基本能遵守。

调优的时候，重点看两类错误：选错元素和选错操作类型。选错元素通常是页面元素清单不够清晰导致的，可以回头优化页面理解角色。选错操作类型通常是提示词里的操作定义不够明确，比如“点击”和“轻触”的区别，“滑动”和“拖拽”的区别，要在提示词里说清楚。

置信度机制我强烈建议加上。让模型在输出操作指令的同时，输出一个置信度字段。置信度低的决策，可以走人工确认，或者触发一次重新理解页面再决策。这个机制能大幅降低测试流程跑飞的概率。我实测下来，加了置信度过滤之后，整体测试通过率提升了差不多两成，因为很多低级错误在置信度低的时候就被拦下来了。

4.4 结果校验角色的实现与调优

结果校验角色的实现，输入是预期描述、操作前页面信息、操作后页面信息。预期描述来自测试用例，操作前后页面信息来自页面理解角色的输出。这里有一个技巧：不要只传元素清单，把截图也传进去。因为有些视觉变化（比如颜色、图标状态）在元素清单里体现不出来，但截图能看到。

提示词模板要强调对比判断。“你是一个测试校验助手，你的任务是判断操作后的页面状态是否满足预期。你会收到操作前的页面信息、操作后的页面信息、以及预期描述。请对比操作前后的变化，判断是否达到预期。”然后给出输出格式，包含是否通过、判断理由、页面状态。

调优的时候，重点是减少误判。误判分两种：假通过和假失败。假通过是页面没达到预期但模型说通过了，假失败是页面达到了预期但模型说没通过。假通过的危害更大，因为它会让有问题的版本蒙混过关。减少假通过的办法是在提示词里加入严格的检查项，比如“检查预期中的关键文字是否出现在页面上”“检查是否有错误提示”“检查页面是否处于加载中状态”。假失败通常是因为模型过于严格，可以在提示词里加入“如果页面状态与预期语义一致，即使文字表述略有不同，也判断为通过”。

校验角色的温度建议设为零或接近零，保证判断的一致性。同一个页面状态，多次校验的结果应该是一样的，不能这次通过下次不通过。如果发现校验结果不稳定，先检查温度参数，再检查提示词里有没有模糊表述。

4.5 角色间的衔接与异常处理

角色之间的衔接看起来简单，实际落地时有很多细节。页面理解角色的输出要经过校验才能传给操作决策角色，校验内容包括 JSON 格式是否正确、坐标是否在屏幕范围内、元素标识是否唯一。这些校验用代码做，不消耗模型调用。校验不通过的话，可以重试页面理解角色，或者降级到备用方案。

操作决策角色的输出也要校验，检查操作类型是否在支持列表里、目标元素标识是否存在于页面元素清单中、操作参数是否完整。校验不通过同样可以重试或降级。结果校验角色的输出相对简单，主要检查格式。

异常处理方面，要定义清楚什么情况下重试、什么情况下跳过、什么情况下终止测试。我的经验是：页面理解失败重试一次，还失败就跳过当前步骤并记录；操作决策置信度低就重新理解页面再决策，连续两次低置信度就终止当前用例；结果校验失败就记录失败详情，继续下一个用例。这些策略要根据你的测试容忍度来调整，没有标准答案。

还有一个衔接细节是上下文传递。操作决策角色可能需要知道之前几步做了什么，才能做出合理决策。比如一个多步表单，当前步骤该填什么，取决于前面填了什么。我的做法是在操作决策角色的输入里加入一个简短的“历史操作摘要”，只保留最近三到五步的操作和结果，太长会占用 token，太短又不够参考。

5. 常见问题与排查技巧实录

5.1 页面理解不准的排查思路

页面理解不准是最常见的问题，表现是元素漏识别、元素类型判断错误、坐标偏移。排查的时候按这个顺序来：先看截图质量，截图是否清晰、是否包含完整屏幕、是否有状态栏遮挡；再看 UI 树信息是否完整，有些应用会禁用可访问性，导致 UI 树为空；然后看提示词是否明确，输出格式定义是否清晰；最后看模型能力是否足够，换个更强的多模态模型试试。

我遇到过一个典型问题：某个应用的按钮是用自定义 View 画的，UI 树里没有文本信息，截图里按钮文字又很小，模型识别不出来。解决办法是在提示词里加入“注意识别图标按钮和自定义控件”，同时把截图放大后再传给模型。放大截图能显著提升小文字的识别率，代价是 token 消耗增加，需要权衡。

还有一个问题是坐标偏移。模型输出的坐标和实际屏幕坐标对不上，通常是坐标系定义不一致导致的。解决办法是在提示词里明确坐标系，并且在输出后做一次坐标变换校验。如果偏移是固定值，可能是状态栏高度没算进去；如果偏移不固定，可能是模型对坐标的理解不稳定，需要降低温度或换模型。

5.2 操作决策错误的排查思路

操作决策错误分几种：选错元素、选错操作类型、操作参数错误。选错元素最常见，排查时先看页面元素清单里有没有正确的候选元素，如果没有，问题在页面理解角色；如果有但模型没选对，问题在决策提示词或模型能力。选错操作类型通常是提示词里操作定义不清晰，比如“点击”和“长按”的区分没说明白。操作参数错误比如输入内容不对、滑动距离不对，通常是输出格式约束不够严格。

我踩过的一个坑是：模型在决策时倾向于选择页面上最显眼的元素，而不是最符合测试目标的元素。比如测试目标是点击“取消”按钮，但“确认”按钮更大更显眼，模型就选了“确认”。解决办法是在提示词里强调“严格按照测试目标选择元素，不要被元素视觉大小影响”，并且在元素清单里把元素文本放在显眼位置，让模型优先看文本。

还有一个经验是，操作决策角色不要一次决策太多步。有些测试步骤是连续的，比如“输入用户名、输入密码、点击登录”，如果让模型一次决策这三步，它可能会漏掉中间步骤或者顺序搞错。我的做法是每一步都单独调用决策角色，虽然调用次数多了，但准确率有保障。对于确实需要连续操作的场景，可以在提示词里明确步骤顺序，并且要求模型逐步输出。

5.3 结果校验误判的排查思路

结果校验误判分假通过和假失败。假通过的排查：先看预期描述是否明确，模糊的预期描述容易让模型放松判断；再看提示词里有没有严格的检查项；最后看模型是否被页面上的无关信息干扰。假失败的排查：先看预期描述是否过于严格，比如要求文字完全匹配但实际有细微差异；再看模型是否把正常的状态变化误判为失败。

我遇到过一个假通过的案例：测试预期是“登录成功后跳转到首页”，但实际页面卡在了加载中，模型却判断通过了，因为页面上有“首页”两个字。解决办法是在提示词里加入“如果页面处于加载中状态，应判断为不通过”，并且要求模型检查页面是否有加载指示器。这个案例说明，校验角色的提示词要覆盖各种边界状态，不能只考虑正常情况。

假失败的一个常见原因是模型对“预期”的理解和测试用例的意图不一致。比如测试用例的预期是“显示错误提示”，模型看到页面上有错误提示文字，但同时也看到了其他正常内容，就判断页面状态不符合“错误”预期。解决办法是在预期描述里写清楚“只要出现错误提示文字即视为通过，不要求页面其他内容”。

5.4 性能与成本优化的实操技巧

角色级拆分之后，模型调用次数增加，性能和成本是需要关注的。优化方向有几个。

第一，页面理解角色的输出做缓存。如果连续几步操作后页面没有变化，可以复用上一次的页面理解结果，不用重新调用模型。判断页面是否变化可以用截图哈希对比，简单有效。

第二，操作决策角色用轻量模型。决策任务的输入是结构化的元素清单，输出是结构化的操作指令，不需要太强的模型。用一个小模型就能做得不错，成本能降一个数量级。页面理解角色则需要强多模态模型，这个省不了。

第三，批量处理。如果测试用例之间没有依赖，可以并行执行，把多个用例的页面理解请求批量发给模型，提高吞吐。不过要注意模型接口的并发限制和速率限制。

第四，提示词精简。提示词里的示例不用太多，两三个就够。输出格式定义要精确但不要冗余。我见过有人把提示词写到几千字，其实大部分内容模型根本用不上，反而增加了 token 消耗和干扰。

第五，结果校验角色可以延迟调用。有些校验不需要每一步都做，可以在关键步骤才调用校验角色。比如一个十步的测试流程，只在第三步和最后一步做校验，中间步骤只记录不校验。这样能省不少调用。

5.5 常见问题速查表

下面这张表是我在实际项目中整理的问题速查表，覆盖了角色级拆分落地时最常遇到的几类问题，供你排查时参考。

6. 角色级拆分的扩展思路与个人体会

角色级模型拆分这套思路，落地之后你会发现它的扩展性比想象中好。最直接的扩展是增加新角色。比如你可以加一个“测试数据生成”角色，根据测试目标自动生成输入数据；或者加一个“异常恢复”角色，当测试流程卡住时，让它分析当前页面并决定如何回到正常流程。每个新角色只要输入输出定义清晰，就能无缝接入现有链路。

另一个扩展方向是角色内部的模型替换。今天用这个多模态模型做页面理解，明天出了更强的模型，直接换掉就行，其他角色不受影响。这种可替换性在模型快速迭代的当下特别有价值。我自己的做法是每个角色都保留两套模型配置，一套主力一套备用，主力效果不好时快速切换对比。

还有一个扩展思路是把角色级拆分和传统自动化测试结合。不是所有测试步骤都需要模型参与，简单的、稳定的步骤可以用传统脚本，复杂的、易变的步骤用模型。这样既能保证稳定性，又能覆盖传统脚本搞不定的场景。我通常会把登录、导航这类固定流程用脚本写死，把内容校验、动态页面操作交给模型角色。

我个人在实际操作中的体会是，角色级拆分最大的价值不是提升单点准确率，而是让整个系统变得可观测、可调试、可优化。单模型方案出问题时，你面对的是一个黑盒；角色拆分之后，每个环节的输入输出都清清楚楚，问题出在哪一目了然。这种可观测性在工程上比单纯的准确率提升更重要，因为它让你能持续改进，而不是每次出问题都从头猜。

最后分享一个小技巧：角色之间的衔接数据，尽量用结构化格式，不要用自然语言。我见过有人让页面理解角色输出一段文字描述，再让决策角色去解析这段文字，结果信息损耗严重。改成 JSON 之后，不仅准确率上去了，token 消耗也降了。这个改动看起来小，但对整体效果的影响很大。