1. 项目概述：从屏幕截图到结构化元素的桥梁

在构建一个能真正“看懂”并操作图形用户界面的智能体时，最大的挑战是什么？不是让它理解复杂的自然语言指令，而是让它能像人类一样，一眼看懂屏幕上密密麻麻的图标、按钮、文本框和菜单。这就是GUI智能体的“视觉瓶颈”。过去，我们依赖操作系统提供的辅助功能API来获取界面元素信息，但这就像戴着一副有盲区的眼镜——很多自定义控件、游戏界面或者远程桌面上的元素根本无法被识别。纯视觉方案因此成为必然选择，但直接从一张复杂的屏幕截图中，精准地分割出每一个可交互或不可交互的元素，并理解它们的含义，其难度不亚于让机器在熙熙攘攘的街头准确识别每一个行人的动作和意图。

微软开源的 OmniParser ，正是为了解决这个核心难题而生。它不是一个简单的图标识别工具，而是一套 面向纯视觉GUI智能体的综合性屏幕解析方法 。简单来说，它能把一张任意的用户界面截图（无论是Windows桌面、网页浏览器还是某个专业软件），自动解析成一个结构化的、易于理解的元素列表。这个列表不仅包含每个元素的边界框坐标，还会告诉你它是不是可点击的按钮、一个输入框、还是一个仅用于展示的图标，甚至能为图标生成功能描述文本。这套解析结果，能极大增强像GPT-4V这类多模态大模型生成准确操作指令的能力，让“点击右上角的红色关闭按钮”这样的指令，能精确地“落地”到屏幕上对应的像素区域。

我花了些时间深入研究了OmniParser V2的代码和论文，并动手部署测试。我发现，它巧妙地将目标检测与图像描述两大任务结合，其设计思路非常值得从事AI智能体、RPA（机器人流程自动化）或任何需要自动化界面操作领域的开发者关注。无论你是想为自己的项目添加一个“眼睛”，还是希望研究前沿的视觉-语言交互技术，OmniParser都提供了一个强大且开源的起点。接下来，我将拆解它的核心原理、手把手带你完成部署与使用，并分享在实际应用中的一些关键心得和避坑指南。

2. 核心设计思路与技术架构拆解

OmniParser的卓越性能并非偶然，其背后是一套深思熟虑的、将复杂问题模块化解决的架构。理解这个架构，是有效使用和后续定制它的关键。

2.1 双模型协作的解析流水线

OmniParser的核心是一个两阶段的流水线，这模仿了人类观察屏幕时的认知过程：先“看到”所有东西，再“理解”关键部分。

第一阶段：交互区域检测 (Interactive Region Detection) 这个阶段由 Icon Detect 模型 负责。你可以把它想象成一个经过特殊训练的“目标检测器”。但与普通的物体检测（如检测猫、狗）不同，它专门学习检测图形用户界面中的各类元素。其输入是一张屏幕截图，输出则是一系列边界框（Bounding Box）以及对应的类别标签。在V2版本中，这个模型的检测能力得到了显著增强，能够识别出更细粒度、更小的图标，并且新增了一个至关重要的属性预测： 可交互性（Interactability） 。这意味着模型不仅能框出一个元素，还能判断它是否可以被点击、拖动或输入。这是实现可靠自动化操作的基础，因为智能体需要区分装饰性图片和功能按钮。

第二阶段：图标功能描述 (Icon Functional Captioning) 检测出区域后，智能体还需要知道这个按钮是干什么的。“一个红色的圆形图标”和“一个表示‘关闭’的红色圆形图标”所包含的信息量天差地别。这就是 Icon Caption 模型 的任务。OmniParser V2提供了两个可选的描述模型：基于 BLIP-2 和基于 Florence-2 的版本。它们接收被检测出的图标区域图像作为输入，生成一段简短的、描述其功能的文本，例如“搜索图标”、“最小化按钮”、“音量调节滑块”。这一步为后续的大语言模型（LLM）提供了丰富的语义上下文，使得LLM能更准确地理解用户指令并规划操作。

这种“检测+描述”的分离设计具有很大优势：它允许两个模型独立优化和更新。例如，可以更换更强大的描述模型来提升文本生成质量，而无需重新训练检测模型。

2.2 为何选择YOLO作为检测基础？

在项目代码中，可以看到Icon Detect模型基于YOLO架构。这是一个非常务实的选择。

  1. 速度与精度的平衡 ：YOLO系列以其“单次前向传播即可完成检测”的特性著称，在保持较高精度的同时拥有极快的推理速度。对于需要实时或近实时响应的GUI智能体应用来说，低延迟至关重要。
  2. 对小目标的检测能力 ：经过针对性训练后，YOLO能够较好地检测屏幕中那些微小的图标（如系统托盘图标、工具栏上的小按钮），而这正是GUI解析中的难点和重点。
  3. 成熟的生态 ：YOLO拥有庞大的社区和丰富的预训练模型、优化工具，降低了开发和研究门槛。

需要注意的是，由于YOLO本身的开源协议（AGPL），基于其训练的Icon Detect模型也继承了AGPL许可证。这在商业应用中需要仔细考虑合规性。而描述模型（BLIP-2, Florence-2）通常采用MIT等更宽松的协议。

2.3 OmniTool：从解析到控制的闭环

在2025年初，团队进一步推出了 OmniTool ，这展示了OmniParser的一个强大应用场景。OmniTool构建了一个完整的智能体控制闭环：

  1. 感知 ：使用OmniParser解析Windows 11虚拟机（或真实系统）的屏幕截图。
  2. 决策 ：将解析出的结构化元素（带位置、类别、可交互属性和描述文本）与用户指令一同发送给一个多模态大语言模型（如GPT-4o、DeepSeek-R1、Qwen2.5-VL等）。
  3. 执行 ：LLM根据解析结果规划出具体操作（如点击坐标[x,y]），由OmniTool将其转换为系统级的鼠标键盘事件并执行。
  4. 验证与循环 ：执行后获取新的屏幕状态，重复上述过程。

这个工具的意义在于，它提供了一个 开箱即用的实验平台 。开发者可以立即测试不同LLM与OmniParser结合的效果，无需从头搭建复杂的控制框架。它证明了纯视觉方案在复杂、真实环境下的可行性，也为收集特定领域的GUI操作轨迹数据提供了便利，这些数据可用于训练更专业的智能体。

3. 环境部署与模型配置实战

理论清晰后，动手部署是检验一切的最好方式。OmniParser的部署过程相对 straightforward，但有几个细节不注意就容易卡住。以下是我在Ubuntu 20.04和Windows 11 WSL2环境下的实战记录。

3.1 基础环境搭建

首先，严格按照官方README操作是避免后续麻烦的基础。

# 1. 克隆仓库
git clone https://github.com/microsoft/OmniParser.git
cd OmniParser

# 2. 创建并激活Conda环境（强烈推荐使用Conda管理依赖）
conda create -n omniparser python=3.12 -y
conda activate omniparser

# 3. 安装依赖
pip install -r requirements.txt

注意：Python版本 。项目明确要求Python 3.12。使用其他版本（如3.10或3.11）可能会在安装某些依赖包（特别是与PyTorch版本绑定的包）时遇到兼容性问题。我曾尝试在3.10环境下安装，虽然能成功安装 requirements.txt ，但在运行Demo时出现了与类型注解相关的运行时错误。

3.2 模型权重下载与放置

这是最关键的一步，文件结构和路径错误会导致模型加载失败。OmniParser V2的权重托管在Hugging Face上。

官方一键下载脚本 ： 项目提供了方便的脚本，但需要确保你已安装 huggingface-hub 命令行工具 ( pip install huggingface-hub )。

# 在OmniParser项目根目录下执行
for f in icon_detect/{train_args.yaml,model.pt,model.yaml} icon_caption/{config.json,generation_config.json,model.safetensors}; do
  huggingface-cli download microsoft/OmniParser-v2.0 "$f" --local-dir weights;
done

# 关键一步：重命名文件夹
mv weights/icon_caption weights/icon_caption_florence

执行后，你的 weights 目录结构应该是这样的：

OmniParser/
├── weights/
│   ├── icon_detect/
│   │   ├── model.pt          # 检测模型权重
│   │   ├── model.yaml        # 模型配置文件
│   │   └── train_args.yaml   # 训练参数
│   └── icon_caption_florence/ # 描述模型权重（Florence-2版）
│       ├── config.json
│       ├── generation_config.json
│       └── model.safetensors

实操心得：网络问题与手动下载 。使用 huggingface-cli 在国内网络环境下可能速度缓慢或中断。如果遇到问题，可以直接访问 Hugging Face Model Hub ，手动下载上述列出的6个文件，并按照完全相同的目录结构放置。 model.safetensors 文件可能较大（约几个GB），请耐心下载。 务必执行 mv 重命名命令 ，因为代码中默认会寻找 icon_caption_florence 这个文件夹名。

3.3 运行Gradio演示界面

验证安装是否成功的最快方法是启动Gradio Web Demo。

python gradio_demo.py

如果一切顺利，终端会输出一个本地URL（通常是 http://127.0.0.1:7860 ）。在浏览器中打开它，你将看到一个简洁的上传界面。

演示步骤 ：

  1. 点击“上传图像”或拖拽一张你的桌面截图、软件界面图到上传区。
  2. 点击“提交”按钮。
  3. 等待几秒至十几秒（取决于你的GPU性能），结果会显示在右侧。
    • 解析结果 ：以JSON格式展示所有检测到的元素，包含 bbox （坐标）、 label （类别，如 button ）、 interactable （布尔值）、 caption （描述文本）等字段。
    • 可视化图像 ：在原图上用不同颜色的框画出检测区域，并标注类别和可交互性。

注意事项：首次运行的延迟 。第一次运行 gradio_demo.py 时，系统需要加载模型到内存（GPU或CPU），这个过程可能会比较慢，持续一两分钟是正常的，请耐心等待控制台输出，不要误认为程序卡死。后续对同一张图片或新图片的解析会快很多。

4. 深入代码：核心API使用与自定义解析

对于开发者而言，通过Demo界面使用只是第一步。更常见的需求是将OmniParser集成到自己的Python项目中。让我们深入 demo.ipynb Jupyter笔记本和源码，看看如何以编程方式调用。

4.1 初始化解析器引擎

核心的解析逻辑封装在 OmniParser 类中（通常定义在 engine.py 或类似文件中）。初始化时需要指定模型路径。

import sys
sys.path.append('.') # 确保可以导入项目模块
from omniparser.engine import OmniParser
import cv2

# 初始化解析器
# 模型根路径默认为 './weights'，如果你的权重放在别处，需要指定
parser = OmniParser(model_root='./weights')

# 加载一张图片
image_path = "your_screenshot.png"
image = cv2.imread(image_path)
# OpenCV默认读取为BGR格式，需要转换为RGB
image_rgb = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)

# 执行解析
results = parser.parse(image_rgb)

results 变量是一个字典列表，每个字典代表一个检测到的界面元素。一个典型的结果对象如下：

{
  'bbox': [x1, y1, x2, y2],  # 左上角和右下角坐标
  'label': 'icon',            # 元素类别，如 'button', 'input', 'icon', 'text'
  'interactable': True,       # 是否可交互
  'confidence': 0.95,         # 检测置信度
  'caption': 'settings gear icon'  # 功能描述（如果调用了描述模型）
}

4.2 关键参数解析与调优

parse 方法通常支持一些参数，用于控制解析的粒度、速度和输出内容。

# 更精细化的调用示例
results = parser.parse(
    image_rgb,
    detect_threshold=0.25,      # 检测置信度阈值，低于此值的框将被过滤
    caption_threshold=0.5,       # 触发描述生成的置信度阈值
    enable_caption=True,         # 是否启用图标描述功能
    caption_model='florence',    # 选择描述模型：'florence' 或 'blip2'
    return_image=True           # 是否返回带标注框的可视化图像
)

# 如果 return_image=True，results 会是一个元组 (detections, annotated_image)
detections, annotated_img = results
  • detect_threshold ：这是控制检测“灵敏度”的关键。如果界面元素很多很密集，适当提高阈值（如0.3）可以减少误检和重叠框；如果有些小图标检测不到，可以适当降低阈值（如0.2），但可能会引入更多噪声。
  • enable_caption 与 caption_model ：生成描述会显著增加推理时间（尤其是第一次加载描述模型时）。如果您的应用场景只需要元素位置和类别，可以关闭此功能以提升速度。 florence 模型通常比 blip2 更准更快，是V2的默认推荐。
  • return_image ：这个功能对于调试和可视化非常有用。你可以用 matplotlib 或 cv2.imwrite 保存或显示 annotated_img ，直观地检查解析效果。

4.3 处理解析结果与坐标系统

获取到结果后，如何利用这些数据？

# 示例：找出所有可交互的按钮
interactive_buttons = []
for det in detections:
    if det['label'] == 'button' and det['interactable']:
        interactive_buttons.append(det)
        print(f"找到按钮: {det.get('caption', 'N/A')}， 坐标: {det['bbox']}")

# 示例：计算某个元素的中心点坐标（常用于模拟点击）
def get_center(bbox):
    x1, y1, x2, y2 = bbox
    center_x = (x1 + x2) // 2
    center_y = (y1 + y2) // 2
    return center_x, center_y

for btn in interactive_buttons[:3]: # 取前三个示例
    center = get_center(btn['bbox'])
    print(f"按钮中心点: {center}")

# 示例：将坐标转换为相对比例（适用于不同分辨率适配）
height, width = image_rgb.shape[:2]
for det in detections:
    x1, y1, x2, y2 = det['bbox']
    # 转换为相对坐标 (0~1)
    rel_x1, rel_y1 = x1 / width, y1 / height
    rel_x2, rel_y2 = x2 / width, y2 / height
    # 相对坐标在不同分辨率的同一界面布局上更具鲁棒性

重要提示：坐标系统 。OmniParser输出的坐标是 基于输入图像像素的绝对坐标 。如果你的应用需要在不同分辨率或缩放比例的屏幕上执行操作，直接使用这些坐标可能会点错位置。一个常见的做法是： 将解析坐标转换为相对于屏幕宽高的比例坐标 。在执行操作时，再根据当前屏幕的实际分辨率，将比例坐标转换回绝对坐标。这是构建健壮的跨分辨率GUI自动化智能体的关键技巧。

5. 性能优化与生产环境考量

将OmniParser从实验Demo推向实际生产环境，会面临性能、稳定性和资源方面的挑战。以下是一些基于经验的优化思路。

5.1 推理速度优化

GUI智能体对实时性要求很高，用户无法忍受一个点击指令要等上好几秒。优化推理速度是首要任务。

  1. 硬件选择与模型量化 ：

    • GPU是必须的 ：在CPU上运行检测和描述模型会非常慢（单张图可能需数十秒）。至少使用具有足够显存的NVIDIA GPU。
    • 模型量化 ：可以考虑使用PyTorch的量化工具（如 torch.quantization ）对 icon_detect 模型进行INT8量化。这能在几乎不损失精度的情况下，显著提升推理速度并降低显存占用。不过，这需要对项目代码和模型加载部分进行一些修改。

  2. 缓存与批处理 ：

    • 模型预热 ：在服务启动时，先用一张小图或空白图跑一次完整的 parse 流程，让所有模型完成加载和初始化，避免第一次用户请求的冷启动延迟。
    • 批处理推理 ：如果您的场景需要连续解析多张相似界面（如监控一个流程），可以尝试修改代码，支持将多张图片组成一个batch进行检测，这能更充分地利用GPU的并行计算能力。YOLO模型通常支持批处理。

  3. 选择性调用 ：

    • 如果界面变化不大，可以考虑 增量解析 。例如，只对屏幕中发生变化的部分区域重新运行检测，而不是全图检测。
    • 仅在需要时才启用 enable_caption 。对于已知的、稳定的界面（如软件主工具栏），其图标功能是固定的，可以预先建立“坐标-功能”的映射表，无需每次调用描述模型。

5.2 处理复杂与动态界面

真实世界的GUI千变万化，OmniParser可能在某些场景下表现不佳。

  1. 透明、重叠与不规则控件 ：一些现代UI使用半透明效果、控件重叠或非矩形设计。这会给检测框的回归带来困难。如果遇到此类问题，可以尝试：

    • 在调用 parse 前，对图像进行简单的预处理，如提高对比度、进行边缘检测，有时能增强模型对控件边界的感知。
    • 收集一些目标应用的特有界面截图，对OmniParser的检测模型进行 微调（Fine-tuning） 。这是提升在特定领域性能最有效的方法。项目提供了训练参数文件（ train_args.yaml ），可以作为微调的起点。

  2. 动态内容与频繁刷新 ：对于游戏、视频播放器等界面元素快速变化的场景，高频率的全屏解析开销巨大。可以考虑：

    • 使用 区域关注策略 。结合先验知识或简单的模板匹配，只对可能发生交互的区域（如对话框弹出位置、任务栏）进行高频率解析，其他静态区域降低解析频率。
    • 利用 时序信息 。前后两帧的界面通常具有高度相似性，可以利用光流或简单的差分法检测变化区域，只解析变化部分。

5.3 与下游LLM的集成策略

OmniParser的输出如何更好地服务于LLM决策？

  1. 信息过滤与结构化 ：直接给LLM扔过去几十个甚至上百个检测框的原始JSON数据，可能会使其困惑。更好的做法是进行预处理：

    • 按区域分组 ：将屏幕上相邻的、同类的元素进行聚类（如将所有工具栏按钮归为一组）。
    • 重要性排序 ：根据元素的大小、位置（如屏幕中央通常更重要）、可交互性等属性，对元素进行排序，将最重要的元素信息放在前面提供给LLM。
    • 简化描述 ：对于 caption 字段，如果生成文本过长或冗余，可以进行摘要或提取关键词。

  2. 设计高效的提示词（Prompt） ：给LLM的指令需要精心设计。例如：

    “你是一个GUI操作助手。以下是当前屏幕的解析结果，包含元素的坐标、类型、是否可交互及其描述。用户指令是：‘打开文件菜单’。请从以下元素中，选择最可能匹配‘文件菜单’的那个，并输出其边界框的中心坐标。解析结果：[此处放置过滤和排序后的结构化数据]”

  3. 建立反馈循环 ：当LLM基于解析结果做出了错误决策（如点击了错误的按钮），可以将这个“错误轨迹”（截图、解析结果、LLM决策、实际结果）记录下来。这些数据可以用于：

    • 分析是OmniParser解析错了，还是LLM理解错了。
    • 作为新的训练数据，进一步微调OmniParser的检测或描述模型，使其在易出错场景表现更好。

6. 常见问题排查与实战技巧

在实际部署和测试中，我遇到了一些典型问题，以下是它们的解决方案和预防措施。

6.1 模型加载失败与路径错误

  • 问题 ：运行Demo或脚本时，出现 FileNotFoundError 或 KeyError: ‘model’ ，提示找不到模型文件。
  • 排查 ：
    1. 首先检查 weights 目录结构是否与 3.2 节中描述的完全一致。特别是 icon_caption_florence 文件夹的名字是否正确。
    2. 检查模型文件是否完整下载。 model.safetensors 文件通常很大（数GB），网络中断可能导致文件不完整。可以尝试重新下载。
    3. 在代码中打印或检查 model_root 的路径。使用绝对路径比相对路径更可靠。
  • 解决 ： 
    import os
# 打印当前工作目录和模型路径
print("Current Working Directory:", os.getcwd())
print("Model root path:", os.path.abspath('./weights'))
# 确保路径存在
assert os.path.exists('./weights/icon_detect/model.pt'), "检测模型权重未找到！"

6.2 依赖冲突与版本问题

  • 问题 ：在安装 requirements.txt 或运行代码时，出现 ImportError 或 AttributeError ，提示某个模块不存在或版本不兼容。
  • 排查 ：这通常是由于PyTorch、CUDA版本或一些视觉库（如opencv-python, Pillow）的版本冲突引起的。
  • 解决 ：
    1. 严格使用Conda环境 ：这是隔离依赖的最佳实践。
    2. 查看官方要求 ：仔细阅读 requirements.txt ，注意其中可能包含的版本限定符（如 torch==2.1.0 ）。
    3. 适配你的CUDA版本 ：如果 requirements.txt 中的PyTorch版本与你的CUDA驱动不兼容，需要手动安装匹配的版本。例如： 
      # 先卸载已有的torch
pip uninstall torch torchvision torchaudio
# 去PyTorch官网 (https://pytorch.org/get-started/locally/) 查找对应你CUDA版本的安装命令
# 例如，对于CUDA 11.8
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118
    4. 然后再次运行 pip install -r requirements.txt ，使用 --no-deps 选项可能有助于避免冲突： pip install -r requirements.txt --no-deps ，但需手动确保核心依赖已安装。

6.3 推理结果不理想（漏检、误检、描述不准）

  • 问题 ：模型对某些界面元素检测不到，或者把背景纹理误检为按钮，或者生成的描述文本不准确。
  • 排查与解决 ：
    1. 调整置信度阈值 ：这是最直接的调优旋钮。尝试降低 detect_threshold 以召回更多目标（但增加误检），或提高它以提升精度（但可能漏检小目标）。
    2. 检查输入图像质量 ：确保输入给模型的图像清晰、分辨率适中。过于模糊或压缩严重的图片会影响性能。可以尝试对图像进行适度的锐化或超分辨率处理。
    3. 领域差异 ：OmniParser是在一个大规模的GUI截图数据集上训练的，但如果你的目标应用界面风格非常独特（如某些工业软件、复古游戏），其泛化能力可能不足。
      • 数据收集 ：收集一批目标界面的截图。
      • 标注 ：使用标注工具（如LabelImg, CVAT）手动标注出其中的界面元素（框和类别）。
      • 微调 ：利用项目提供的训练配置，在你的数据上对检测模型进行微调。即使只有几十张高质量的标注图像，也能带来显著改进。
    4. 描述模型选择 ：如果 florence 模型描述不准，可以尝试切换回 blip2 模型（需要下载对应的V1.5权重并放置正确），看是否有改善。不同模型在不同类型的图标上可能各有优劣。

6.4 内存不足（CUDA Out of Memory）

  • 问题 ：在解析大分辨率图片或批量处理时，出现GPU显存不足的错误。
  • 解决 ：
    1. 降低输入图像分辨率 ：在将图片送入模型前，先将其缩放到一个固定尺寸（如1920x1080）。保持宽高比进行缩放，并在周围填充灰边，以避免变形。 
      import cv2
def resize_with_padding(img, target_size=(1920, 1080)):
    old_h, old_w = img.shape[:2]
    target_w, target_h = target_size
    scale = min(target_w / old_w, target_h / old_h)
    new_w, new_h = int(old_w * scale), int(old_h * scale)
    resized = cv2.resize(img, (new_w, new_h))
    # 创建目标尺寸的画布并填充中性色
    canvas = np.full((target_h, target_w, 3), 128, dtype=np.uint8)
    # 将缩放后的图像置于画布中央
    x_offset = (target_w - new_w) // 2
    y_offset = (target_h - new_h) // 2
    canvas[y_offset:y_offset+new_h, x_offset:x_offset+new_w] = resized
    return canvas
    2. 关闭描述模型 ：描述模型（特别是大型视觉语言模型）会消耗大量显存。如果任务不需要，务必设置 enable_caption=False 。
    3. 使用CPU模式 ：作为最后的手段，可以将模型加载到CPU上运行（修改代码中模型加载的device参数）。速度会慢很多，但不会占用显存。

OmniParser为纯视觉GUI智能体打开了一扇大门，它将杂乱的像素阵列转化为了机器可以理解的结构化语义。从技术上看，其“检测+描述”的流水线设计清晰有效；从实践上看，它提供了从快速演示到生产集成的完整路径。最大的挑战和机遇，在于如何根据具体的应用场景对其进行优化和适配——可能是阈值的微调，可能是模型的微调，也可能是与下游LLM协同策略的设计。这个领域正在快速发展，OmniParser V2在Screen Spot Pro基准上取得的39.5%的成绩已经证明了其领先性，而随着OmniTool等工具的出现，构建实用化的GUI智能体正在从研究课题逐步走向工程现实。我个人的体会是，成功的关键不在于等待一个完美的通用解析器，而在于深入理解你的特定任务，并利用好OmniParser这样强大的基础工具，围绕它构建起包含预处理、后处理、错误处理和领域适应的完整解决方案。

Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

用 Trace Skills 生成产品原型：从概念到可交互 Demo 的实战经验

avatar 龙虾开发者社区
cover

OpenClaw 本地部署教程｜Windows 可视化安装与上手指南

avatar 龙虾开发者社区
cover

写了那么多 AI 测试 Skills，为什么还是不好用？

avatar 龙虾开发者社区