基于Qwen2.5-VL与OpenClaw的智能UI自动化测试实践

1. 项目概述当视觉大模型遇上UI自动化测试最近在折腾一个挺有意思的项目把阿里新出的Qwen2.5-VL-7B视觉语言模型塞进了OpenClaw这个自动化测试框架里专门用来做UI验证。这活儿听起来有点跨界但实际跑起来你会发现它正在悄悄改变我们做自动化测试的玩法。传统的UI自动化测试无论是用Selenium、Playwright还是Appium核心逻辑都是基于代码定位元素然后执行点击、输入等操作。这套流程很成熟但维护成本高得吓人——页面UI一改XPath、CSS Selector这些定位符可能就全废了测试脚本就得跟着大改。OpenClaw的出现提供了一种“所见即所得”的新思路。它本质上是一个基于AI的自动化代理能通过屏幕截图“看到”界面然后理解用户的自然语言指令去执行操作。比如你告诉它“点击登录按钮”它不需要知道按钮的ID是#login-btn它只需要在截图里找到长得像“登录按钮”的东西然后点下去。这大大降低了对页面结构的依赖。而Qwen2.5-VL-7B作为一个多模态大模型它的强项正是理解图像和文本。把它作为OpenClaw的“大脑”负责解析屏幕截图并生成操作指令理论上能让自动化测试变得更智能、更健壮尤其适合应对频繁变动的UI和需要复杂视觉判断的场景。这个组合适合谁呢首先是测试开发工程师和自动化测试爱好者你们肯定受够了维护脆弱的元素定位脚本。其次是前端开发可以在自测环节快速验证页面功能而不用写一堆测试代码。甚至对产品经理来说用自然语言描述一个测试流程让AI自动跑一遍看看效果也不是不可能。它的核心价值就是试图用“视觉理解”和“自然语言交互”这两把钥匙去打开UI自动化测试“高维护成本”和“低智能程度”这两把锁。2. 核心思路与技术选型解析2.1 为什么是OpenClaw Qwen2.5-VL-7B选择这个组合背后是一套完整的逻辑推演。首先看OpenClaw它不是一个从零开始的轮子而是站在巨人肩膀上的产物。它底层集成了Playwright用于Web和Appium用于移动端这样的成熟驱动来处理最底层的页面控制和设备交互。它的创新点在于中间层一个AI智能体框架。这个框架的工作流是截取当前屏幕 - 将截图和用户指令如“找到商品列表的第一个商品并点击”一起送给大模型 - 接收大模型返回的结构化操作指令如{“action”: “click”, “coordinates”: [x, y]}- 通过底层驱动执行。这样一来测试脚本的编写就从“代码定位”变成了“自然语言描述”这是质的飞跃。那么为什么选择Qwen2.5-VL-7B作为这个“大脑”这里有几个关键的考量点性能与效率的平衡7B参数的模型在消费级显卡如RTX 4060 16G上已经可以流畅地进行本地部署和推理响应速度能满足自动化测试的交互需求。相比动辄70B、千亿参数的大模型它的部署和运行成本要友好得多。强大的视觉理解能力Qwen2.5-VL在多项视觉问答VQA和图表理解基准测试中表现突出。对于UI测试来说这意味着它能较好地识别按钮、输入框、图标、文本内容以及它们之间的布局关系这是准确生成操作指令的基础。优秀的指令跟随能力这个版本的模型在遵循复杂、多步骤指令方面做了优化。我们的测试指令往往不是单一的“点击”而是“在搜索框输入‘手机’然后在结果页筛选出价格低于2000的商品”这需要模型有很强的逻辑分解和上下文理解能力。可控的输出格式通过精心设计的提示词Prompt我们可以引导模型输出严格遵循我们预定JSON格式的操作指令这对于与OpenClaw执行引擎的无缝对接至关重要。注意这里有一个常见的误区就是认为模型越大效果越好。对于自动化测试这种对响应延迟有一定要求的场景盲目追求超大模型可能会导致单步操作耗时过长整个测试用例跑下来时间不可接受。7B模型在精度和速度之间取得了很好的平衡。2.2 整体架构与数据流设计整个系统的运行可以看作一个清晰的闭环流水线。我画了一个简单的数据流图来帮助理解用户自然语言指令 (例如“登录系统”) | v [OpenClaw 客户端] --(指令 当前屏幕截图)-- [Qwen2.5-VL-7B 模型服务] | | | v | 模型解析生成结构化动作 | (例如: {“action”: “click”, “target”: “用户名输入框”}) | | v | [OpenClaw 执行引擎] --(结构化动作指令)------------- | v [底层驱动 (Playwright/Appium)] 执行点击、输入等操作 | v 页面状态更新进入下一循环指令输入测试用例以自然语言脚本的形式存在。例如一个测试用例可能就是一个文本文件里面写着“打开浏览器访问‘https://example.com’在用户名框输入‘admin’在密码框输入‘123456’点击登录按钮验证页面是否跳转到仪表盘。”视觉感知与决策OpenClaw控制浏览器或App到达初始页面后截取全屏或指定区域的图像。这张截图和当前步骤的指令如“在用户名框输入‘admin’”被一起发送给Qwen2.5-VL-7B模型。模型需要完成a) 视觉定位在图中找到“用户名输入框”b) 意图理解知道要对它执行“输入”操作c) 参数填充输入的内容是“admin”。动作执行模型将理解的结果以JSON格式返回例如{“action”: “type”, “bbox”: [x1, y1, x2, y2], “text”: “admin”}。OpenClaw的执行引擎接收到这个JSON后会通过Playwright的API在对应的坐标区域执行输入文本的操作。状态验证与循环操作执行后页面状态发生变化。系统可以再次截图结合下一步指令如“在密码框输入…”进行下一轮循环。对于验证步骤如“验证页面是否跳转到仪表盘”模型可以分析新截图判断是否存在“仪表盘”相关的关键视觉元素如特定的标题、图表并返回验证结果True/False。这个架构的核心优势在于解耦。测试逻辑自然语言脚本、视觉理解大模型、底层操作驱动三者分离。未来如果有了更强大的视觉模型我们可以直接替换Qwen2.5-VL-7B而无需重写测试脚本或执行引擎。3. 环境部署与核心配置实战3.1 OpenClaw的本地化部署OpenClaw的安装并不复杂但需要清晰的步骤。官方推荐使用Python虚拟环境这是避免依赖冲突的好习惯。以下是在Ubuntu 20.04/22.04或WSL2环境下的标准步骤# 1. 创建并激活虚拟环境 python -m venv openclaw_env source openclaw_env/bin/activate # Windows: openclaw_env\Scripts\activate # 2. 安装OpenClaw核心包 pip install openclaw # 3. 安装Playwright浏览器驱动OpenClaw的Web能力依赖它 playwright install chromium # 建议安装chromium稳定性好对于Windows用户步骤基本一致只需注意激活虚拟环境的命令不同。安装完成后可以通过一个简单命令测试OpenClaw基础功能是否正常openclaw --help。如果能看到一列命令说明恭喜你第一步成功了。实操心得在Linux服务器上部署时Playwright可能需要额外的系统依赖。如果运行playwright install报错通常它会给出缺少库的提示比如libatk-bridge2.0、libxkbcommon等。根据提示用apt-get install安装即可。这一步是很多新手部署失败的主要原因。3.2 Qwen2.5-VL-7B模型的本地服务化让OpenClaw能调用Qwen2.5-VL-7B我们需要让模型以一个API服务的形式运行起来。这里我强烈推荐使用Ollama这个工具。它就像大模型的Docker能极大地简化模型的拉取、管理和服务化。# 1. 安装Ollama (以Linux为例) curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取Qwen2.5-VL-7B模型 (注意模型名可能为 qwen2.5-vl:7b 或类似) ollama pull qwen2.5-vl:7b # 3. 以API模式运行模型 ollama run qwen2.5-vl:7b默认情况下Ollama会在http://localhost:11434提供一个兼容OpenAI API格式的接口。这意味着OpenClaw可以直接像调用ChatGPT一样调用它。但是直接使用默认参数可能效果不佳。我们需要为UI测试这个特定任务创建一个自定义模型Modelfile来优化它的表现# 保存为 Modelfaw.qwen-vl-test FROM qwen2.5-vl:7b # 设置较低的temperature让输出更确定、更可控减少随机性 PARAMETER temperature 0.1 # 使用JSON格式输出这是与OpenClaw对接的关键 PARAMETER format json # 添加系统提示词引导模型专注于UI理解和操作 SYSTEM 你是一个专业的UI自动化测试助手。你的任务是根据用户提供的屏幕截图和文本指令分析界面并生成下一步的操作命令。 请严格按照以下JSON格式输出且只输出这个JSON对象不要有任何其他解释 { thought: 你的思考过程简要分析截图内容和指令意图, action: 操作类型只能是以下之一click, double_click, right_click, type, scroll, hover, drag, wait, verify, target_description: 对操作目标的文字描述例如蓝色的登录按钮, coordinates: {x: 整数, y: 整数}, // 操作的中心点坐标可选对于click等操作需要 text: 需要输入的文本仅当action为type时需要, confidence: 0.95 // 你对此次判断的置信度0-1之间 } 如果指令是验证页面状态如“验证登录成功”则action为“verify”并在thought中说明验证依据。 现在请开始你的工作。 使用这个Modelfile创建并运行一个定制化的模型实例ollama create qwen-vl-tester -f ./Modelfile.qwen-vl-test ollama run qwen-vl-tester3.3 OpenClaw与模型服务的对接配置OpenClaw需要通过配置文件知道去哪里找我们的“AI大脑”。在OpenClaw的工作目录下通常需要创建一个配置文件如config.yaml或通过环境变量设置。# config.yaml 示例 model: provider: openai # Ollama兼容OpenAI API api_base: http://localhost:11434/v1 # Ollama的API地址 model: qwen-vl-tester # 我们自定义的模型名 api_key: ollama # Ollama不需要真key但有些框架要求非空可随意填写 automation: platform: web # 或 mobile browser: chromium # 浏览器类型 headless: false # 调试时设为false可以看到浏览器操作正式运行可设为true viewport: {width: 1920, height: 1080} default_timeout: 30000 # 操作超时时间毫秒 logging: level: INFO save_screenshots: true # 非常重要保存每次模型决策前后的截图用于调试和分析最关键的一步是告诉OpenClaw使用我们配置的模型。这通常在启动OpenClaw或编写测试技能Skill时完成。4. 测试技能Skill开发与提示词工程4.1 编写你的第一个自然语言测试技能在OpenClaw中一个具体的测试任务被封装成一个“Skill”。我们可以用YAML来定义一个最简单的登录测试Skill。# skills/user_login.yaml name: user_login_test description: 测试用户登录功能 steps: - instruction: 打开浏览器访问登录页 https://demo.testfire.net/login.jsp action: navigate # 这是OpenClaw内置的基础动作无需模型介入 parameters: url: https://demo.testfire.net/login.jsp - instruction: 在用户名输入框中输入 admin # 不指定actionOpenClaw会将instruction和当前截图发给模型决策 - instruction: 在密码输入框中输入 demo - instruction: 点击登录按钮 - instruction: 验证是否成功跳转到主页并看到 Welcome 字样 action: verify # verify动作会触发模型进行视觉验证并判断测试步骤成功与否运行这个Skill很简单openclaw run skill skills/user_login.yaml。OpenClaw会依次执行每一步。对于没有指定action的步骤它会自动截图联合instruction发送给配置的Qwen2.5-VL模型等待模型返回具体的操作指令后再执行。4.2 核心针对UI测试的提示词优化技巧模型的性能极度依赖提示词Prompt。我们之前在Modelfile里写的SYSTEM提示词是全局的但有时我们需要为特定步骤提供更精确的引导。OpenClaw允许在Skill步骤中附加prompt_override。技巧一明确输出格式和行动范围这是最重要的。必须用最清晰、无歧义的语言规定模型输出的格式。我们在系统提示词中已经做了但可以强化。例如在需要点击的步骤可以附加- instruction: 点击‘忘记密码’这个链接 prompt_override: | 请专注于在截图底部区域寻找带有“忘记密码”或“Forgot Password”字样的文本链接。输出必须严格遵循指定的JSON格式且action必须是click。技巧二提供上下文和排除干扰当界面元素复杂时告诉模型“不要关注什么”和“重点关注什么”同样重要。- instruction: 在商品列表中选择第一个商品 prompt_override: | 截图上方是导航栏下方是页脚请忽略。请聚焦于页面中间的主体内容区域寻找呈现为网格或列表排列的商品卡片。‘第一个商品’指的是视觉上最靠左上方的那张商品卡片。找到后点击该卡片的图片或标题区域。技巧三分步引导复杂操作对于拖拽、滑动等复杂操作在指令中分解步骤。- instruction: 将进度条滑块从当前位置拖动到80%的位置 prompt_override: | 1. 首先在截图中定位水平进度条组件找到上面的圆形或方形滑块。 2. 计算进度条的总长度。假设滑块最左端是0%最右端是100%。 3. 估算从滑块当前位置移动到代表80%位置的点需要向右水平移动的距离。 4. 输出action为drag并提供滑块的初始坐标和拖放目标坐标。技巧四验证步骤的提示词设计验证Verify是测试的关键。提示词要引导模型进行“视觉断言”。- instruction: 验证登录成功页面显示用户头像和‘我的账户’菜单 prompt_override: | 请分析当前截图判断是否同时满足以下两个条件 1. 页面右上角或显眼位置存在一个圆形或方形的头像图标。 2. 页面中存在包含‘我的账户’、‘My Account’或类似含义的文字的菜单项。 如果两个条件都满足则验证通过输出中action为verifyconfidence设为高0.9。如果任一条件不满足则验证失败confidence设为低。避坑指南提示词中的指令要避免使用模糊代词。比如“点击它”模型可能不清楚“它”指代什么。一定要用明确的名词如“点击‘提交’按钮”。另外对于中文UI指令用中文描述效果通常更好对于国际化的应用中英文混合或使用英文关键词可能更可靠。5. 实战演练一个完整的电商流程测试案例让我们用一个更复杂的电商场景来串联所有知识。目标是测试一个电商网站的核心流程搜索商品、加入购物车、进入结算页。5.1 测试技能设计我们创建一个名为e2e_shopping_flow.yaml的技能文件。name: e2e_shopping_flow description: 端到端电商购物流程测试搜索、加购、进入结算 parameters: base_url: https://magento.softwaretestingboard.com # 一个公开的测试电商站 search_keyword: jacket product_to_select: Proteus Fitness Jackshirt # 假设我们想找这个具体商品 steps: - instruction: 打开浏览器访问电商网站首页 action: navigate parameters: url: {{base_url}} - instruction: 在页面顶部的搜索框中输入关键词 ‘{{search_keyword}}’然后按回车键进行搜索 prompt_override: | 寻找页面顶部通常在导航栏附近的文本输入框其旁边或有放大镜图标或有‘Search’字样。执行‘type’动作输入文本后模拟按下键盘回车键。注意回车键动作可能需要特殊处理如果模型不支持可拆分为两个步骤1.输入文本2.点击搜索按钮。 - instruction: 在搜索结果列表中找到名为 ‘{{product_to_select}}’ 的商品并点击进入其详情页 prompt_override: | 仔细浏览搜索结果网格或列表比对每个商品项下的标题文字找到完全匹配‘{{product_to_select}}’的那一个。点击该商品的标题或主图片。 - instruction: 在商品详情页找到并点击 ‘Add to Cart’ (加入购物车) 按钮 # 依赖模型识别按钮文字 - instruction: 等待购物车侧边栏或顶部通知出现确认商品已添加成功 action: wait parameters: ms: 2000 # 硬性等待2秒让UI有反应时间。更好的做法是让模型验证这里演示混合策略。 - instruction: 点击页面右上角的购物车图标进入购物车页面 prompt_override: | 定位页面右上角或固定顶部栏的购物车图标通常是一个小车形状的图标。点击它。 - instruction: 在购物车页面找到并点击 ‘Proceed to Checkout’ (前往结算) 按钮 prompt_override: | 在购物车页面内寻找一个突出的、通常是绿色的按钮上面写着‘Proceed to Checkout’或类似文字。点击它。 - instruction: 验证页面是否成功跳转到结算流程的第一步例如看到 ‘Shipping Address’ (配送地址) 的标题 action: verify prompt_override: | 检查当前页面是否包含‘Shipping Address’、‘Checkout’、‘结算’或类似的核心标题。同时页面应该包含表单输入区域。如果存在这些元素则验证通过。5.2 执行、监控与结果解析运行这个技能openclaw run skill skills/e2e_shopping_flow.yaml。在非headless模式下你可以亲眼看到浏览器被自动操控完成一系列操作。如何监控和调试日志OpenClaw会输出详细的INFO级别日志显示每一步发送给模型的指令、接收到的响应以及执行的操作。截图我们在配置中开启了save_screenshots: true。这会在本地生成一个目录保存每一步模型决策前即发送给模型的截图和决策后的屏幕状态。这是最宝贵的调试工具。当某个步骤失败时去查看对应的截图你就能知道模型当时“看到”了什么它为什么做出了错误的决策。模型输出日志中会记录模型返回的完整JSON。检查thought字段可以了解模型的“思考过程”检查confidence字段可以评估模型对当前步骤的把握程度。低置信度如0.7的步骤是潜在的风险点。结果解析如果所有步骤绿色通过恭喜测试成功。如果某一步失败OpenClaw通常会停止可配置为继续。你需要分析失败原因模型识别错误截图里目标元素清晰但模型找错了位置或理解了错误指令。这需要优化提示词或考虑在技能中增加更精确的prompt_override。页面状态未就绪模型执行点击时按钮可能还未加载出来或处于不可点击状态。这需要在操作前增加wait动作或者实现更智能的等待如下文会讲的“重试与稳定性处理”。底层操作失败模型指令正确但Playwright执行点击时元素已失效。这可能是因为页面是动态渲染的需要更精确的等待策略。6. 高级技巧提升测试稳定性和可维护性纯靠模型“盲操”是不够的我们需要结合传统自动化测试的智慧来打造健壮的测试流程。6.1 混合定位策略AI视觉 代码辅助完全依赖视觉模型在极端情况下如元素被遮挡、动态内容闪烁可能不稳定。我们可以设计一个混合策略优先使用视觉AI如果失败或置信度低则回退到传统的CSS Selector或XPath。这需要扩展OpenClaw的技能逻辑。我们可以通过编写更复杂的技能步骤处理器或者利用OpenClaw的插件机制来实现。思路如下# 伪代码逻辑需要在自定义Skill Handler中实现 - instruction: 点击‘立即购买’按钮 strategy: hybrid fallback_selectors: [button.purchase-btn:visible, //button[contains(text(), 立即购买)]] # 首先让模型尝试视觉定位和点击confidence 0.8才执行 # 如果模型置信度低于0.8或执行后未达到预期效果如下一步验证失败则启用fallback_selectors用Playwright原生方式定位并点击。6.2 实现智能等待与重试机制网络延迟、前端渲染都会导致元素出现时机不确定。我们不能只靠固定的sleep。基于视觉的等待在关键操作前插入一个“等待特定元素出现”的步骤但这个等待是由模型来判断的。- instruction: 等待页面加载完成直到主内容区域的商品列表出现 action: wait_for_vision parameters: timeout: 10000 # 最多等10秒 check_interval: 1000 # 每秒检查一次 success_criteria: 截图中存在多个排列整齐的、包含图片和文字的商品卡片区域这需要自定义一个wait_for_vision的动作其内部会循环截图、调用模型判断“成功条件”是否满足。操作后验证与重试执行一个点击操作后不一定成功。可以紧接着加一个轻量级的验证步骤。- instruction: 点击登录按钮 - instruction: 验证登录按钮是否消失或页面URL是否变化 action: verify parameters: max_retries: 2 # 如果验证失败重试前面的点击操作最多2次6.3 测试数据管理与参数化为了提高技能的可复用性必须将测试数据如用户名、商品名、URL从操作逻辑中分离出来。我们在之前的案例中已经使用了{{parameter}}的语法。我们可以创建一个外部的数据文件如JSON或YAML来管理多组测试数据。# config/test_data.yaml flows: - name: flow_guest_checkout base_url: https://demo-store.com search_keyword: T-shirt expected_product: Basic Cotton T-Shirt - name: flow_user_purchase base_url: https://demo-store.com search_keyword: jeans expected_product: Slim Fit Jeans username: testusermail.com password: Pass123!然后在运行技能时通过命令行参数或配置文件指定使用哪一组数据openclaw run skill skills/shopping.yaml --data config/test_data.yaml --flow flow_guest_checkout。7. 常见问题排查与效能优化实录在实际应用中你会遇到各种各样的问题。下面是我踩过坑后总结的一些典型问题及其解决方案。7.1 模型相关问题问题1模型响应慢导致测试执行时间过长。排查检查Ollama服务运行状态ollama list查看GPU资源占用nvidia-smi。如果GPU内存不足模型可能会部分或全部运行在CPU上速度极慢。解决量化模型使用Ollama拉取量化版本的模型如qwen2.5-vl:7b-q4_K_M能在几乎不损失精度的情况下大幅减少内存占用和提升推理速度。调整参数在Modelfile中降低num_ctx上下文长度和num_predict最大预测令牌数。对于UI测试我们不需要很长的文本生成。升级硬件如果条件允许使用显存更大的显卡。问题2模型“看”不到或“误解”了界面元素。排查查看保存的失败步骤截图。是不是截图范围不对元素是否太小、模糊或被遮挡检查模型的thought输出看它的分析是否合理。解决优化截图确保OpenClaw截取的是正确的视口或区域。对于单页应用SPA可能需要滚动后再截图。可以配置OpenClaw在关键步骤前自动滚动到特定位置。增强提示词在指令中提供更精确的空间位置描述如“页面右上角的用户头像”、“表格第一行的删除图标”。图像预处理进阶如果UI对比度低或元素密集可以在将截图发送给模型前进行简单的图像处理如提高对比度、边缘检测等有时能提升模型识别率。问题3模型输出格式不符合要求导致OpenClaw解析失败。排查查看OpenClaw日志中模型返回的原始内容。是不是包含了多余的Markdown代码块标记或解释性文字解决强化系统提示词在SYSTEM提示词中反复强调“只输出JSON不要有任何其他文本”。使用Ollama的format参数如我们之前在Modelfile中设置的PARAMETER format json能强制模型以JSON格式输出。后处理在OpenClaw端写一个简单的解析器尝试从模型返回的文本中提取合法的JSON对象。7.2 OpenClaw与执行环境问题问题4Playwright操作失败如点击无效、输入不成功。排查首先确认模型返回的坐标coordinates是否合理在屏幕范围内。然后查看Playwright执行时的错误日志。解决坐标校正模型返回的坐标可能是基于截图分辨率的而Playwright操作是基于实际浏览器视口的。需要确保坐标系转换正确。OpenClaw通常会自动处理但需检查配置中的viewport是否与实际匹配。操作替代对于输入框如果type动作不生效可以尝试先click聚焦再type。对于下拉选择可能需要组合click和键盘事件。等待元素可交互在模型指令执行前通过配置增加一个短暂的固定等待或使用Playwright的page.waitForSelector配合混合策略等待元素处于可交互状态。问题5测试在CI/CD流水线中不稳定Headless模式。排查Headless模式下一些CSS样式、字体渲染或动画可能与有头模式略有差异可能影响模型识别。解决使用headless: ‘new’模式Playwright的新无头模式更接近真实浏览器。统一环境确保CI环境与本地开发环境的浏览器版本、视口大小完全一致。提高容错率降低验证步骤的置信度阈值增加重试次数并设置合理的超时时间。7.3 效能与成本优化问题6每次操作都调用模型API调用次数多成本/延迟高。解决缓存策略对于相对稳定的页面如登录页相同的指令如“输入用户名”可能会被多次执行。可以缓存“截图-指令-操作”的映射关系。当再次遇到高度相似的截图和相同指令时直接使用缓存的操作无需调用模型。这需要实现一个简单的图像特征比对模块。操作合并将连续的、简单的操作合并为一个指令发给模型。例如将“输入用户名”、“输入密码”、“点击登录”合并为“完成登录表单填写并提交”。这需要模型有更强的多步骤理解能力但能显著减少调用次数。使用更轻量的模型进行简单判断对于“元素是否存在”这类简单验证可以训练或使用一个专门的小型图像分类模型比调用7B的大模型要快得多、便宜得多。将Qwen2.5-VL-7B与OpenClaw结合确实为UI自动化测试打开了一扇新的大门。它最大的魅力在于让测试脚本的编写和维护变得更符合直觉。我个人在几个项目中实践下来的体会是它特别适合用于冒烟测试、探索性测试的自动化辅助、以及对UI变化容忍度较高的回归测试场景。对于追求绝对稳定、毫秒级响应的核心流程测试目前的纯视觉方案可能还需要与传统方法结合形成混合框架。另外提示词工程的质量直接决定了测试的成败这部分需要投入精力去积累和打磨形成一个针对自己产品UI的“提示词库”。最后记得妥善管理测试过程中产生的大量截图和日志它们不仅是调试的依据更是未来迭代优化模型和提示词的宝贵数据资产。