基于视觉定位的跨平台GUI自动化测试：原理、实践与混合策略

1. 项目概述当GUI自动化测试遇上“纯视觉”革命在软件测试领域GUI图形用户界面自动化测试一直是个让人又爱又恨的“瓷器活”。爱的是它能解放人力实现7x24小时不间断的回归测试恨的是它极度脆弱一个按钮位置偏移几个像素、一个控件ID的变更甚至是一个字体颜色的调整都可能导致精心编写的测试脚本“全军覆没”。传统的自动化测试框架无论是基于Web的Selenium、Playwright还是基于移动端的Appium其核心逻辑都严重依赖于对UI底层结构的解析——HTML的DOM树、移动端的Accessibility Tree无障碍树简称A11y。这种“后台依赖”模式就像蒙着眼睛在迷宫里摸索一旦迷宫的结构图DOM/A11y变了或者干脆不给你看了比如某些桌面客户端、游戏界面测试脚本立刻就会迷失方向。这就是“GROUNDCUA”这个项目标题背后所指向的核心痛点与革新方向。GROUNDCUA我理解其核心是“Grounding CUA”即“基于视觉定位的跨平台用户界面自动化”。它代表的是一种全新的GUI自动化范式抛弃对底层代码和结构的依赖让AI像人一样纯粹通过“看”屏幕来理解和操作界面。这不仅仅是技术路径的切换更是思维模式的颠覆。它要解决的正是传统自动化测试中那些最顽固的兼容性、稳定性和跨平台难题。如果你是一名被频繁的UI变更搞得焦头烂额的测试工程师或是一个希望构建更健壮RPA机器人流程自动化流程的开发者那么基于视觉定位的方案很可能就是你一直在寻找的“银弹”。2. 核心思路拆解为什么“看见”比“知道”更重要要理解GROUNDCUA这类方案的价值我们必须先看清传统方案的“阿喀琉斯之踵”。2.1 传统GUI自动化的三大“原罪”强耦合性测试脚本与UI元素的定位器如XPath、CSS Selector、resource-id深度绑定。前端开发修改一个div的class你的脚本就可能失效。这种耦合使得测试维护成本极高往往与开发进度形成对抗。平台局限性Selenium玩不转桌面应用Appium对纯原生或游戏界面束手无策。每个平台都需要一套特定的工具和驱动技术栈碎片化严重。信息不完整与动态性挑战A11y树或DOM树并非总能100%反映视觉状态。一些自定义绘制的控件、基于Canvas的复杂应用如在线设计工具、或动态加载的内容其底层结构信息可能是缺失、滞后或不准确的。2.2 视觉定位方案的破局逻辑视觉定位方案的核心思想是模拟人类用户的交互方式。人类操作软件时不需要知道一个按钮在代码里叫btn_submit还是#submit-button我们只关心“屏幕上那个绿色的、写着‘提交’的方块在哪里”。GROUNDCUA方案将这个过程拆解为两个核心阶段这与当前前沿研究如Aria-UI的思路高度一致视觉感知与理解Seeing模型接收整个屏幕或指定区域的截图作为输入。它需要理解这张图像里包含哪些可交互的视觉元素按钮、输入框、图标、文本等并理解它们的语义这是个搜索框、那是个关闭按钮。指令对齐与定位Grounding当接收到一个自然语言指令如“点击登录按钮”模型需要将这个指令与第一步中识别出的视觉元素进行“对齐”Grounding并计算出该元素在屏幕坐标系中的精确位置通常是归一化的坐标如(x, y)。这个过程完全绕开了底层框架和平台API实现了跨平台统一。无论是Windows桌面应用、macOS软件、Android/iOS App、Web浏览器还是运行在虚拟机里的系统只要你能截取到屏幕图像理论上就可以进行自动化操作。这为解决上述三大“原罪”提供了根本性的可能。2.3 技术选型背后的考量为什么是现在视觉定位并非新概念早期的图像识别工具如SikuliX就做过尝试。但直到最近几年它才真正具备实用价值这得益于几个关键技术的成熟大规模多模态模型LMM的崛起像GPT-4V、Qwen-VL、Aria这类模型具备了前所未有的视觉-语言联合理解能力。它们不仅能识别物体更能理解界面元素的功能和关系比如知道一个红色感叹号图标通常代表“错误”或“警告”。高精度目标检测与分割YOLO、SAM等模型能以前所未有的精度和速度定位图像中的元素边界为点击、拖拽等操作提供像素级坐标。海量高质量训练数据互联网上存在海量的GUI截图结合自动化技术如Aria-UI论文中提到的数据生成pipeline可以合成出用于训练“视觉定位”任务的巨量指令-坐标对数据。因此GROUNDCUA方案的技术栈选择必然围绕“大模型视觉”展开。它可能是一个端到端的LMM直接输入截图和指令输出坐标也可能是一个组合系统先用目标检测模型找出所有潜在元素再用一个轻量级模型对指令和元素进行匹配。注意纯视觉方案并非万能。它也有其挑战例如计算开销相对较大需要实时截图和模型推理、对屏幕分辨率变化和视觉干扰如弹窗、动画更敏感、以及无法获取非视觉属性如某个输入框是否被禁用。一个健壮的工业级方案可能会采用“视觉为主元数据为辅”的混合策略。3. 核心细节解析与实操要点构建或应用一个GROUNDCUA系统需要深入理解其核心组件和工作流程。下面我们以一个假设的、基于开源模型搭建的视觉自动化测试框架为例拆解其关键细节。3.1 系统核心组件剖析一个典型的视觉GUI自动化系统通常包含以下模块屏幕捕获模块负责以一定频率如每秒1-10帧或响应事件的方式捕获屏幕图像。这需要处理多显示器、高DPI缩放、特定窗口抓取等问题。工具上跨平台可选pyautogui、mssWindows专用有Pillowctypes调用BitBlt macOS有pyobjc Linux有pyscreenshot或maim。视觉理解与定位模块核心这是系统的“大脑”。它接收截图和自然语言指令输出目标元素的坐标。实现方式有两种主流路径端到端LMM路径直接使用类似Aria-UI的专用模型。输入是(截图 指令)输出是归一化坐标[x, y]。优点是简单直接模型已内化了元素检测和指令对齐的能力。缺点是对算力要求高模型体积大。两阶段Pipeline路径阶段一元素检测。使用目标检测模型如YOLOv8 专精于检测按钮、输入框、图标等GUI元素类别或分割模型如SAM 获取像素级掩膜先找出屏幕上所有可能的交互元素并为每个元素生成一个视觉特征向量和边界框。阶段二指令-元素匹配。将自然语言指令编码成文本特征向量然后与所有检测到的元素的视觉特征进行相似度计算如余弦相似度找出最匹配的元素并返回其边界框的中心点作为点击坐标。这种方式更模块化便于调试和优化。动作执行模块根据定位模块输出的坐标模拟人类输入。包括鼠标移动、点击左键、右键、双击、拖拽、滚动以及键盘输入。pyautogui、pynput是Python中常用的跨平台库。任务规划与状态管理模块高级对于复杂的多步骤任务如“登录邮箱找到最新邮件下载附件”需要一个上层规划器可以是另一个LLM如GPT-4o或基于规则的引擎来将高级指令分解为一系列原子操作“定位用户名输入框 - 输入文本 - 定位密码输入框 - ...。同时系统需要维护操作历史文本或图文作为后续步骤的上下文输入以处理动态变化的界面。3.2 实操中的关键参数与配置即使使用现成的模型要让它稳定工作也需要关注一系列参数截图区域与频率全屏截图最通用但处理数据量大。可以智能截取活动窗口区域以提升效率。对于动态加载的网页需要设置合理的等待时间和截图频率确保操作前界面已稳定。图像预处理送入模型前的截图可能需要调整大小如缩放到模型训练时的标准尺寸如336x336、448x448、归一化像素值除以255、以及转换为模型要求的通道格式RGB。坐标转换与后处理模型输出的通常是归一化坐标如[0-1000]范围。需要将其转换回当前屏幕分辨率下的实际像素坐标。公式很简单实际X 输出X / 1000 * 屏幕宽度。此外对于模糊匹配或模型置信度不高的情况可能需要加入后处理逻辑比如在预测坐标周围小范围内进行模板匹配二次确认。容错与重试机制视觉识别不可能100%准确。必须设计重试逻辑。例如首次定位失败后可以等待0.5秒再截一张图重试或者尝试用不同的指令表述“点击登录”、“点登录按钮”、“按下登录”进行重试。# 一个简化的坐标转换与点击示例 import pyautogui def execute_click(normalized_coords, screen_width, screen_height): 将归一化坐标转换为实际坐标并执行点击。 normalized_coords: 模型输出的 [x, y]范围 0-1000。 actual_x int(normalized_coords[0] / 1000.0 * screen_width) actual_y int(normalized_coords[1] / 1000.0 * screen_width) # 注意很多模型训练时宽高使用相同归一化基准也可能是除以1000*屏幕高度需根据模型定义调整。 # 加入微小随机偏移模拟人类操作的不精确性避免被检测为机器人 actual_x random.randint(-2, 2) actual_y random.randint(-2, 2) pyautogui.moveTo(actual_x, actual_y, duration0.2) # 带移动动画更自然 pyautogui.click()4. 从零搭建一个简易视觉自动化测试脚本我们不必一开始就追求Aria-UI那样的重型模型。可以先用现有的开源模型和工具搭建一个原型系统验证视觉自动化测试的可行性。这里我们选择两阶段Pipeline路径因为它更轻量、可控适合快速上手。4.1 环境准备与依赖安装首先创建一个干净的Python环境推荐3.9并安装必要的库。# 创建虚拟环境可选 python -m venv venv_groundcua source venv_groundcua/bin/activate # Linux/macOS # venv_groundcua\Scripts\activate # Windows # 安装核心依赖 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 根据你的CUDA情况选择版本 pip install ultralytics # 用于YOLOv8目标检测 pip install transformers pillow # 用于文本编码和图像处理 pip install sentence-transformers # 用于计算文本-图像特征相似度 pip install pyautogui mss opencv-python # 用于屏幕捕获和动作执行4.2 第一阶段基于YOLOv8的GUI元素检测我们需要一个能识别常见GUI元素按钮、输入框、复选框等的模型。幸运的是已经有社区训练好的专用模型。下载或训练YOLO模型我们可以从Roboflow Universe或Hugging Face Hub寻找公开的“GUI Element Detection”数据集和预训练模型。例如keremberke/yolov8n-gui-element-detection是一个不错的起点。编写检测脚本使用YOLOv8的Python API进行推理非常简单。from ultralytics import YOLO import cv2 from PIL import ImageGrab import numpy as np class GUIElementDetector: def __init__(self, model_pathkeremberke/yolov8n-gui-element-detection): # 加载模型可以是本地路径或Hugging Face模型ID self.model YOLO(model_path) self.class_names self.model.names # 获取类别名称如{0: button, 1: input, ...} def detect(self, screenshot): 对截图进行GUI元素检测。 screenshot: PIL.Image 或 numpy数组 (RGB格式)。 返回: list of dicts, 每个dict包含 bbox(xyxy), confidence, class_id, class_name # 将PIL图像转换为numpy数组如果尚未转换 if isinstance(screenshot, Image.Image): img_np np.array(screenshot) else: img_np screenshot # 运行推理 results self.model(img_np, verboseFalse)[0] # 取第一个也是唯一一个结果 detected_elements [] for box in results.boxes: xyxy box.xyxy.cpu().numpy()[0].tolist() # 边界框 [x1, y1, x2, y2] conf box.conf.cpu().numpy()[0] # 置信度 cls_id int(box.cls.cpu().numpy()[0]) # 类别ID cls_name self.class_names[cls_id] detected_elements.append({ bbox: xyxy, confidence: conf, class_id: cls_id, class_name: cls_name, center: ((xyxy[0] xyxy[2]) / 2, (xyxy[1] xyxy[3]) / 2) # 计算中心点 }) return detected_elements # 使用示例 detector GUIElementDetector() # 截取屏幕 screenshot ImageGrab.grab() elements detector.detect(screenshot) print(f检测到 {len(elements)} 个GUI元素) for elem in elements[:3]: # 打印前三个 print(f - {elem[class_name]} (置信度: {elem[confidence]:.2f}) 位于 {elem[bbox]})4.3 第二阶段指令-元素匹配与定位检测出元素后我们需要将自然语言指令与它们匹配。这里的关键是将文本指令和视觉元素映射到同一个向量空间进行比较。一个简单有效的方法是使用CLIPContrastive Language-Image Pre-training模型或其变体。但CLIP是为通用图像设计的。对于GUI我们可以用一个取巧的办法用文本描述元素然后进行文本-文本匹配。为检测到的元素生成文本描述我们可以根据元素的类别、位置、大小等属性合成一个简短的描述。更高级的做法是用一个小的视觉描述模型VLM来生成。文本编码与相似度计算使用sentence-transformers库中的预训练模型如all-MiniLM-L6-v2将指令和我们生成的元素描述都编码成向量然后计算余弦相似度。from sentence_transformers import SentenceTransformer, util import numpy as np class InstructionGrounder: def __init__(self, text_model_nameall-MiniLM-L6-v2): self.text_model SentenceTransformer(text_model_name) def generate_element_description(self, element, screenshot_width, screenshot_height): 为检测到的GUI元素生成一个简短的文本描述。这是一个简单规则版。 cls_name element[class_name] bbox element[bbox] center_x, center_y element[center] # 简单的位置描述左上、右上、左下、右下、中间 pos_x 左侧 if center_x screenshot_width * 0.33 else (右侧 if center_x screenshot_width * 0.66 else 中间) pos_y 顶部 if center_y screenshot_height * 0.33 else (底部 if center_y screenshot_height * 0.66 else 中部) # 组合描述 description f一个位于屏幕{pos_y}{pos_x}区域的{cls_name} return description def ground_instruction(self, instruction, detected_elements, screenshot_size): 将指令与检测到的元素进行匹配。 instruction: 字符串如“点击登录按钮”。 detected_elements: GUIElementDetector输出的列表。 screenshot_size: (width, height) 返回: 匹配度最高的元素及其相似度分数。 if not detected_elements: return None, 0.0 # 1. 为每个元素生成描述 element_descriptions [] for elem in detected_elements: desc self.generate_element_description(elem, screenshot_size[0], screenshot_size[1]) element_descriptions.append(desc) # 2. 编码指令和所有描述 instruction_embedding self.text_model.encode(instruction, convert_to_tensorTrue) desc_embeddings self.text_model.encode(element_descriptions, convert_to_tensorTrue) # 3. 计算相似度 cos_scores util.cos_sim(instruction_embedding, desc_embeddings)[0] cos_scores cos_scores.cpu().numpy() # 4. 找到最匹配的元素 best_idx np.argmax(cos_scores) best_score cos_scores[best_idx] best_element detected_elements[best_idx] return best_element, best_score # 使用示例 grounder InstructionGrounder() instruction 点击登录按钮 best_elem, score grounder.ground_instruction(instruction, elements, screenshot.size) if best_elem and score 0.5: # 设置一个相似度阈值 print(f指令 {instruction} 匹配到元素: {best_elem[class_name]}, 相似度: {score:.3f}, 中心点: {best_elem[center]}) else: print(未找到匹配度高的元素。)4.4 整合与执行完成一次自动化点击将屏幕捕获、检测、匹配、执行串联起来就完成了一个最简单的视觉自动化流程。import time from PIL import ImageGrab import pyautogui class SimpleVisualAutomator: def __init__(self): self.detector GUIElementDetector() self.grounder InstructionGrounder() self.screen_size pyautogui.size() def run_instruction(self, instruction, max_retries3, confidence_threshold0.6): 执行一条自然语言指令。 for attempt in range(max_retries): print(f尝试第 {attempt 1} 次...) # 1. 截屏 screenshot ImageGrab.grab() # 2. 检测元素 elements self.detector.detect(screenshot) if not elements: print(未检测到任何GUI元素。) time.sleep(0.5) continue # 3. 匹配指令 best_elem, score self.grounder.ground_instruction(instruction, elements, self.screen_size) if best_elem and score confidence_threshold: # 4. 执行点击 center_x, center_y best_elem[center] # 转换为全局屏幕坐标假设截图是全屏 pyautogui.moveTo(center_x, center_y, duration0.3) pyautogui.click() print(f成功执行指令: {instruction} (点击了 {best_elem[class_name]})) return True else: print(f匹配失败或置信度过低 ({score:.3f})。等待后重试...) time.sleep(1) print(f指令 {instruction} 执行失败已达最大重试次数。) return False # 主程序 if __name__ __main__: automator SimpleVisualAutomator() # 假设我们要自动化一个登录操作 automator.run_instruction(点击用户名输入框) time.sleep(0.5) pyautogui.write(test_user) automator.run_instruction(点击密码输入框) time.sleep(0.5) pyautogui.write(password123) automator.run_instruction(点击登录按钮)这个简易原型虽然功能有限但它清晰地展示了GROUNDCUA方案的核心工作流。你可以通过使用更强大的元素检测模型、更精细的元素描述生成方法例如结合OCR识别元素上的文字、以及引入上下文历史来提升其准确性和鲁棒性。5. 常见问题、挑战与优化策略实录在实际项目中应用视觉定位方案你会遇到一系列在理想Demo中不会出现的问题。下面是我在探索过程中踩过的坑和总结的应对策略。5.1 识别准确率不足问题表现模型找不到目标元素或匹配到错误元素。排查与解决检查截图质量确保截图清晰、完整没有因屏幕缩放如Windows 125%导致的模糊。高DPI屏幕需要特别注意。优化元素描述我们之前的简单描述“一个位于屏幕底部中间区域的按钮”信息量太低。必须加入OCR识别到的文本内容。例如检测到一个按钮同时用pytesseract或easyocr识别其上的文字为“登录”那么描述就变成“一个写着‘登录’二字的按钮”。这能极大提升匹配精度。引入视觉特征纯文本匹配有局限。应该使用真正的多模态模型如CLIP来编码元素的图像块从截图中根据bbox裁剪出来与指令的文本嵌入进行匹配。这能捕捉颜色、形状、图标等纯文本无法描述的特征。调整置信度阈值根据场景调整confidence_threshold。在稳定环境中可以调高如0.8以减少误操作在动态或复杂界面中可以调低如0.4但需配合更严格的后处理如二次确认。数据增强与模型微调如果是在特定类型的应用如公司内部ERP系统上使用可以收集该系统的截图和操作指令对开源的检测模型或匹配模型进行微调fine-tuning让它更熟悉你的界面风格。5.2 处理动态界面与等待问题表现脚本执行太快界面还没加载出来就开始查找导致失败。排查与解决显式等待在关键操作如点击一个会触发页面跳转的按钮后加入固定的time.sleep(2)。这是最简单但不优雅的方法。智能等待实现一个wait_for_element函数。它循环截屏、检测直到目标元素出现或消失或者达到超时时间。这更接近Selenium的WebDriverWait思想。视觉状态感知除了等待元素出现还可以等待界面达到某种“稳定状态”。例如连续几次截屏检测到的元素列表不再发生剧烈变化或者某个特定的加载动画图标消失。def wait_for_element(self, instruction, timeout10, interval0.5): 等待直到指令匹配到某个元素 start_time time.time() while time.time() - start_time timeout: screenshot ImageGrab.grab() elements self.detector.detect(screenshot) best_elem, score self.grounder.ground_instruction(instruction, elements, self.screen_size) if best_elem and score self.confidence_threshold: return best_elem time.sleep(interval) raise TimeoutError(f在 {timeout} 秒内未找到元素: {instruction})5.3 跨分辨率与跨平台适配问题表现在1080p屏幕上训练的脚本在4K屏幕上完全失效。排查与解决坐标归一化是核心我们的系统内部必须始终使用归一化坐标如0-1000范围。所有检测出的bbox中心点、以及最终要执行的坐标都先转换为归一化坐标存储和传递在执行前再根据当前屏幕分辨率转换回物理坐标。这保证了脚本与屏幕分辨率解耦。模型的多尺度训练用于元素检测的YOLO模型如果在训练时使用了多尺度数据增强其本身对尺度变化就有一定的鲁棒性。但最好能收集或合成不同分辨率下的界面数据来微调模型。UI缩放感知操作系统级的UI缩放如Windows的150%会改变渲染尺寸。我们的屏幕捕获模块需要获取的是实际物理像素而不是逻辑像素。pyautogui.size()返回的是物理像素通常是对的。但某些截图库可能需要特殊处理。5.4 性能与实时性考量问题表现整个流程截屏-检测-匹配耗时过长1秒无法用于需要快速响应的交互。排查与解决模型轻量化使用更小的模型如YOLOv8nnano或YOLOv8ssmall。对于匹配模型可以使用更小的sentence transformer。推理引擎优化使用ONNX Runtime、TensorRT或OpenVINO等推理框架对模型进行加速。对于YOLOUltralytics本身就支持导出为ONNX并利用ONNX Runtime推理。区域截屏与缓存不要每次都全屏截图。如果知道目标元素大概在屏幕的某个区域如下方的导航栏可以只截取那一部分。对于静态界面部分可以缓存其检测结果避免重复推理。异步流水线将截屏、检测、匹配、执行放在不同的线程中形成流水线并行处理提升整体吞吐量。5.5 复杂交互的支持问题表现目前只实现了点击。如何实现拖拽、滚动、长按、文本输入解决方案拖拽需要定位两个元素起点和终点或一个元素和一个坐标偏移。指令可以是“将文件A拖到文件夹B”。实现时先定位起点元素按下鼠标然后移动鼠标到终点位置或元素再释放。滚动需要识别滚动条或可滚动区域。指令可以是“向下滚动列表”。实现时可以定位到滚动条区域然后模拟鼠标滚轮事件或拖拽滚动条滑块。文本输入定位到输入框后使用pyautogui.write()或pyperclip复制粘贴。对于复杂格式需要处理。高级指令如“双击”、“右键点击”、“悬停”都可以通过组合基本动作和pyautogui的API实现。关键在于如何从自然语言指令中解析出这些操作类型这可能需要更复杂的指令解析器或使用LLM进行分解。6. 进阶方向与混合策略探讨纯粹的视觉方案在理想情况下很美但在复杂的工业场景中混合策略Hybrid Approach往往是最务实、最稳健的选择。6.1 视觉为主元数据为辅当视觉定位置信度不高时可以尝试回退到传统方法。例如在测试Web应用时优先使用视觉定位点击“提交”按钮。如果连续失败则启动一个Selenium驱动通过DOM查询来获取该按钮的坐标通过getBoundingClientRect然后让pyautogui去点击这个坐标。 这种方式结合了两者的优点视觉的跨平台性和传统方法的精确性。你需要维护两套定位逻辑但稳定性会大大提升。6.2 引入LLM进行任务规划与异常处理对于“从收件箱下载最新的PDF附件并重命名为报告.pdf”这样的复杂任务单纯的“定位-执行”循环不够用。可以引入一个LLM如GPT-4o的API或本地部署的Llama 3作为规划器Planner和协调器Orchestrator。规划器将高级指令分解为原子操作序列[“激活邮箱应用” “定位收件箱标签” “点击” “定位最新邮件” “点击” “定位附件区域” “定位PDF附件图标” “右键点击” “定位‘另存为’选项” “点击” “定位文件名输入框” “点击” “输入‘报告.pdf’” “定位保存按钮” “点击”]。协调器监督每个原子操作的执行结果。如果“定位收件箱标签”失败它可以尝试重新表述指令“找到写着‘Inbox’的侧边栏项目”或者触发异常处理流程如记录错误、发送通知、尝试备用流程。6.3 构建自适应的视觉测试资产库传统的自动化测试需要维护庞大的locators定位器库。在视觉方案中我们可以维护一个“视觉特征库”或“参考截图库”。录制模式在脚本开发或第一次成功执行时系统不仅记录操作步骤还保存下成功定位到的元素的视觉特征如经过编码的特征向量和上下文截图。回放模式再次执行时优先使用存储的视觉特征在当前界面进行匹配。这类似于“图像模板匹配”但比简单的像素匹配更鲁棒因为它基于深度学习特征对光照、微小形变不敏感。自动更新当匹配失败时可以提示用户确认或自动捕获新的特征进行更新实现测试资产的半自动维护。GROUNDCUA所代表的视觉定位自动化正在打破GUI测试的“黑盒”让我们能够以更接近用户真实体验的方式进行验证。这条路虽然仍有不少挑战需要攻克例如对计算资源的要求、对复杂动态界面的处理、以及对模糊指令的理解等但其展现出的跨平台潜力和对变化的强韧性已经为自动化测试乃至更广泛的RPA领域描绘出了一个激动人心的未来。从我个人的实践来看初期投入会高于传统方案但长期来看在维护成本和适应变化能力上带来的收益是显著的。对于面临多平台、高迭代速度产品的团队现在开始关注并尝试这一技术无疑是一个具有前瞻性的选择。