企业官网建设流程全解析

最近在 Windows 上折腾 AI 自动化的时候，我一直在想一个问题：大模型的能力已经很强了，但为什么实际用起来总觉得“差一步”？

你可能会遇到和我一样的场景：想用豆包帮忙理解一张截图，就得先打开网页版、上传图片、输入提示词，再把结果复制回来；想用 DeepSeek 做深度推理，又要切到另一个网页或写一段临时脚本；想把这些能力集成到日常桌面操作里，更是要写一堆胶水代码，处理 API Key、接口格式和异常重试。

更关键的是，模型 API 越来越多，文本、视觉、推理各有各的长处，但大多数人的使用方式还停留在“打开网页 → 复制粘贴”的阶段。这种用法不是不行，只是太低效。真正值得做的，是把这些模型能力变成“可调用的原子能力”，再通过一个统一入口把它们组织起来，形成一条能自动完成复杂任务的处理链路。

这篇文章要讲的，就是一套在 Windows 上可用、且可以复用的组合方案：Quicker + 豆包 API + DeepSeek Harness。

我的判断很明确：这三个工具放在一起，不是简单的功能堆砌，而是构成了一条完整的 AI 应用开发链路。Quicker 负责解决“怎么触发”的问题，豆包 API 负责解决“怎么理解”的问题，DeepSeek Harness 负责解决“怎么编排与调度”的问题。三者组合起来，你可以在桌面环境里实现截图识别、图文理解、内容总结、多步推理等典型的多模态应用场景。

读完这篇文章，你会得到一套可以直接照做的方案，包括环境准备、API 调用代码、Harness 编排配置、Quicker 动作接入方式，以及实际运行中最容易踩的坑和排查思路。

1. 这篇文章真正要解决的问题

先说清楚：为什么要关注这个组合？

如果你只是偶尔用一次 AI，网页版完全够用。但当你的工作流开始频繁依赖模型能力时，网页版的效率瓶颈会非常明显。

举一个具体场景。假设你要批量处理一批产品截图：识别图片中的文字、提取关键信息、生成结构化摘要。用网页版做，一张图至少需要几十秒的人工操作；用代码做，你要写请求脚本、处理鉴权、做重试，还要应付不同模型 API 的格式差异。

这套组合解决的核心痛点，是把“模型能力”变成“桌面自动化能力”，让普通人也能用很低的上手成本，搭建自己的 AI 工作流。

具体拆解下来，它解决了三类问题：

第一，统一入口问题。Quicker 可以把手动操作变成快捷键、轮盘菜单或右键动作，省去打开网页的时间。

第二，多模型协同问题。豆包在中文理解、视觉内容识别上表现扎实，DeepSeek 在复杂推理上有自己的优势。Harness 层可以把两者编排成一条流水线。

第三，接口复用问题。API 调用一旦封装好，以后任何场景都可以直接复用，不用每个需求都从零开始写请求代码。

什么样的读者最适合读这篇文章？

• 日常在 Windows 上办公，希望用 AI 提升效率的信息工作者；
• 正在做 AI 应用集成，需要聚合多个模型 API 的开发者；
• 刚接触 API 调用，想找一个完整案例入门的新手。

需要提前说明的是：本文不会教你脱离官方规范和合规边界去调用任何服务，所有操作都建立在官方 API 和合理授权的基础上。涉及生产环境部署时，务必先在小范围测试。

2. 三个核心概念：Quicker、豆包 API 与 DeepSeek Harness

在进入实操之前，先花一点篇幅把这三个概念讲清楚。因为在实际使用中，我发现很多人对它们的理解是模糊的，甚至会混淆它们的职责边界。

2.1 Quicker：桌面效率的“触发器”

Quicker 是一款 Windows 效率工具，核心价值是让你用最短的路径触发一个操作序列。

它的工作方式可以这样理解传统的软件操作是“人去找功能”，而 Quicker 是“功能来找人”。你可以把一系列操作打包成一个动作，比如“截图 → 调用 API → 把结果写入文件”，然后通过鼠标轮盘、快捷键、右键菜单甚至文本指令触发。

Quicker 本身不提供 AI 能力，它的定位是“调度中枢”。但它真正厉害的地方在于，可以运行命令行、PowerShell 和 Python 脚本。这意味着，你可以在一个动作里完成“截图 → 调用 Python 脚本 → 脚本请求模型 API → 返回结果 → 写入剪贴板”的完整链路。

对 AI 应用来说，Quicker 的价值在于它把“调用模型”这个技术动作，变成了“按一下快捷键”的日常操作。

2.2 豆包 API：中文友好的多模态理解入口

豆包是字节跳动旗下的大模型产品，普通用户用到的是网页版和 App，开发者用的则是豆包 API。

豆包 API 背后接入的是字节跳动的大模型服务，支持文本对话和视觉理解等多模态能力。多模态理解意味着你不仅可以把文字发给模型，还可以把图片发过去，让模型识别图像内容、提取文字信息、描述画面。

豆包 API 对中文语境的支持比较友好，在做中文内容理解、提炼、改写等任务时会有不错的表现。同时，它提供 OpenAI 兼容的接口格式，这意味着如果你曾经用过 OpenAI SDK，迁移成本很低，只需要修改 API Key 和 Base URL，大部分请求逻辑可以复用。

需要特别提醒的是，豆包 API 的模型 ID 和接口域名会随平台策略调整，具体参数以你在火山方舟控制台开通时看到的信息为准。本文示例中会用占位符和通用接口格式来演示，避免写死无效信息。

2.3 DeepSeek Harness：模型编排的“控制台”

Harness 这个词在软件工程里通常指“测试环境”或“运行容器”，在 AI 工具链里，它的含义更接近“封装与编排层”。通俗地说，DeepSeek Harness 的作用是把底层大模型 API 包装成更容易管理、更容易组合的模块。

你可以把它理解成一个“智能调度员”：它在模型 API 之上加了一层统一管理，负责处理 API Key 配置、请求格式转换、调用重试、多模型路由等繁琐工作。通过 Harness，你可以定义好一个任务流程：第一步用哪个模型，第二步把结果传给哪个模型，第三步输出什么格式。

这里想澄清一个常见误区：Harness 不是替代模型，而是“包裹”模型。它本身不产生智能，它是让智能能力更容易被工程化地调用。

从输入材料来看，DeepSeek Harness 的相关项目可能存在不同的发行形式和安装方式，本文不逐一推断具体命令，而是从通用的配置和编排思路出发，演示这类工具应该怎么用。如果你实际安装的是某个具体开源项目，以该项目官方仓库的说明为准。

2.4 三者之间的职责如何划分

用一个比方来总结：

• Quicker 是肢体，负责接收你的指令并动作；
• 豆包 API 是眼睛，负责看懂图片和文字；
• DeepSeek 是大脑，负责深度推理；
• DeepSeek Harness 是神经中枢，负责把信息传递到正确的部位。

这四层合在一起，才能形成一条完整的多模态处理链路。

3. 环境准备与前置条件

在开始写代码之前，需要先把环境准备好。本节列出的是通用前置条件，不绑定具体版本，因为不同项目的版本要求可能随时变化。更稳妥的做法是，以你安装的工具和官方文档为准。

3.1 硬件与操作系统

• 操作系统：Windows 10 或 Windows 11（64 位）。
• 内存：建议 8GB 以上。虽然调 API 不是本地推理，但你要运行 Quicker、浏览器、代码编辑器等工具。
• 网络：需要能正常访问模型 API 服务。如果你的项目环境中需要配置代理，请确保代理配置符合合规要求且工作正常。

3.2 软件依赖

3.3 确认 API 服务状态

在开始之前，先确认两件事：

第一，你的豆包 API 账号已经开通了视觉理解模型的访问权限。有些账号可能默认只有文本模型的权限，视觉模型需要单独申请。如果没开通权限，调用图片接口时会收到权限错误。

第二，确认 API Key 是有效的，并且不要泄露给任何人。建议在环境变量中配置，而不是直接写进代码。

3.4 初始化项目目录

建议创建一个独立的项目目录，用来存放所有脚本和配置。这样做的好处是，后续你在 Quicker 里引用脚本时，路径是清晰稳定的。

mkdir ai-workflow cd ai-workflow python -m venv venv

激活虚拟环境：

# Windows PowerShell .\venv\Scripts\Activate.ps1 # Windows CMD venv\Scripts\activate.bat

然后安装 OpenAI Python SDK，因为豆包 API 兼容 OpenAI 接口格式：

pip install openai python-dotenv

这里解释一下为什么使用 python-dotenv：API Key 不应该硬编码在代码里，用.env文件统一管理密钥，既安全又方便切换不同环境。

4. 核心流程拆解：一条多模态流水线的设计思路

在写代码之前，先想清楚整体流程。很多人的做法是一上来就写请求代码，但等跑通了才发现流程设计不合理，又要返工。

我推荐的流水线设计是四步：

1. 采集：通过 Quicker 完成截图或选择文件，获取图片和文字输入。
2. 理解：调用豆包视觉模型，对图片进行识别，提取关键信息。
3. 推理：将豆包输出的结构化信息交给 DeepSeek，进行更深入的分析、总结或改写。
4. 输出：把最终结果写入剪贴板、文件或发送到指定应用。

这个流程设计的核心思想是“各司其职”：视觉理解交给更擅长图像处理的模型，深度推理交给更擅长逻辑分析的模型，中间用 Harness 做数据流转。

这是一个很自然的架构选择。如果你只看表面，很容易误以为用一个模型就能完成所有事情。但在实际项目中，不同模型在不同任务上的表现差异是真实存在的。视觉识别和逻辑推理属于不同的能力维度，组合使用往往比“一个模型打天下”效果更好，成本也更容易控制。

4.1 为什么把豆包放在理解层？

从实践角度来看，豆包 API 在多模态理解上的接入比较简单，且对中文场景友好。图片识别、OCR、内容描述这些任务，它可以直接完成。把这一层放在流水线最前面，是因为后续所有推理都依赖于这一步产出的结构化文本。

4.2 为什么用 DeepSeek 做推理层？

DeepSeek 的优势在于复杂推理和逻辑分析。拿到豆包识别出的文本之后，让 DeepSeek 帮你做数据分析、优劣对比、方案生成，效果会比较理想。

4.3 为什么 Harness 放在中间？

Harness 的核心价值在于解耦。没有 Harness 时，你需要在业务代码里分别处理豆包和 DeepSeek 的 API 格式、错误码、重试策略。有了 Harness，这些逻辑被抽象到一个配置层，业务代码只关心“输入什么、得到什么”，而不用管底层是哪个模型。

5. 完整示例与代码实现

下面进入代码实现。为了让路径更清晰，我们先把一个场景跑通：桌面截图 → 豆包识别图中菜品和食材 → DeepSeek 生成家常菜谱 → 结果写入剪贴板和文件。

这个场景很典型，因为它涵盖了图片输入、文本理解、逻辑推理、结果输出四个环节，且每一步都是可替换的。你能跑通它，就能在此基础上改造出属于你自己的多模态工作流。

5.1 配置环境变量

在项目目录下创建.env文件：

DOUBAO_API_KEY=your_doubao_api_key_here DOUBAO_BASE_URL=https://your-doubao-endpoint.example.com/v1 DOUBAO_VISION_MODEL=doubao-vision-model-id DEEPSEEK_API_KEY=your_deepseek_api_key_here DEEPSEEK_BASE_URL=https://api.deepseek.com/v1 DEEPSEEK_MODEL=deepseek-chat-model-id

注意，这里的 Base URL 和模型 ID 是占位符，请替换成你在控制台实际看到的值。因为不同平台的接入地址不同，写死一个无效地址反而会误导读者。

5.2 第一步：调用豆包视觉模型理解图片

创建step1_understanding.py：

# 文件路径：ai-workflow/step1_understanding.py import os import base64 from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI( api_key=os.getenv("DOUBAO_API_KEY"), base_url=os.getenv("DOUBAO_BASE_URL"), ) def encode_image_to_base64(image_path: str) -> str: """读取本地图片并转为 Base64 字符串""" with open(image_path, "rb") as f: return base64.b64encode(f.read()).decode("utf-8") def understand_image(image_path: str, prompt: str) -> str: """调用豆包视觉模型，识别图片内容""" base64_image = encode_image_to_base64(image_path) response = client.chat.completions.create( model=os.getenv("DOUBAO_VISION_MODEL"), messages=[ { "role": "user", "content": [ {"type": "text", "text": prompt}, { "type": "image_url", "image_url": { "url": f"data:image/png;base64,{base64_image}" }, }, ], } ], max_tokens=1024, ) return response.choices[0].message.content if __name__ == "__main__": result = understand_image( image_path="screenshot.png", prompt="请识别这张图片中的所有内容，并用中文逐项列出。", ) print(result)

这段代码的逻辑很简单，但有几个关键点值得说明：

第一，图片通过 Base64 编码嵌入请求。这种方式适合单张图片的小文件，如果图片过大，就要考虑压缩或使用图片 URL。

第二，content 字段是数组结构，可以同时包含文本和图片内容。这是 OpenAI 兼容接口的视觉请求标准格式，豆包 API 支持这种结构，所以代码可复用性很高。

第三，max_tokens 限制了模型输出的最大长度。这个值需要根据你的任务复杂度调整，识别任务一般 1024 够了，如果任务复杂，可以调大。

5.3 第二步：用 DeepSeek 做深度推理

创建step2_reasoning.py：

# 文件路径：ai-workflow/step2_reasoning.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL"), ) def reason_with_deepseek(recognized_text: str) -> str: """调用 DeepSeek 模型，基于识别结果做深度推理""" response = client.chat.completions.create( model=os.getenv("DEEPSEEK_MODEL"), messages=[ { "role": "system", "content": "你是一个经验丰富的中文助手。请基于用户提供的识别结果进行推理和总结，输出条理清晰、可直接使用的内容。", }, { "role": "user", "content": f"以下是从图片中识别出的内容：\n{recognized_text}\n\n请根据这些内容生成一份完整的家常菜谱，包括步骤和注意事项。", }, ], temperature=0.7, ) return response.choices[0].message.content if __name__ == "__main__": recognized = "西红柿、鸡蛋、葱花、食用油、盐、糖" print(reason_with_deepseek(recognized))

这一步的要点是 system prompt 的设计。很多人在调用推理模型时只给用户消息，不给系统指令，导致输出结构松散。在这里，我给模型设定了角色和输出要求，结果会更可控。

temperature 参数控制随机性，0.7 是一个比较平衡的值，既能保证多样性，又不会太发散。如果你希望结果更稳定，可以调到 0.2 到 0.3。

5.4 第三步：用 Harness 配置编排流水线

如果每次都要手动串联两个 Python 脚本，显然还不够优雅。更合理的方式是，用一个 Harness 配置文件把流程声明出来。

创建harness_config.yaml：

# 文件路径：ai-workflow/harness_config.yaml version: 1.0 workflow: name: image_to_recipe description: 截图识别 → 食谱生成 steps: - id: understand type: call_model provider: doubao model: ${DOUBAO_VISION_MODEL} input: image prompt: 请识别这张图片中的所有内容，并用中文逐项列出。 - id: reason type: call_model provider: deepseek model: ${DEEPSEEK_MODEL} input: ${understand.output} prompt: 请根据识别结果生成一份完整的家常菜谱。 output: type: write_file path: ./recipe_result.md

这个配置文件的思路是“声明式流水线”：每一步只写“我是谁、我调谁、我的输入来自哪里”，具体的 API 调用逻辑由 Harness 层自动处理。这样做的好处是，后续如果想换模型、调参数，只需要改配置，不用改代码。

在实际使用中，Harness 工具可能会用具体字段名，比如把type叫action，把input叫source，但核心设计思路是一致的：把流程从代码中抽象出来。

5.5 第四步：用 Quicker 触发整个流水线

到这里，代码已经跑通了。但每次在命令行里运行 Python 脚本，仍然不够“桌面化”。现在用 Quicker 把这个流程变成一键触发。

在 Quicker 中创建一个新动作，类型选择“运行 PowerShell 命令”或“执行命令行”。核心命令如下：

# Quicker 动作中的 PowerShell 脚本片段 # 变量 $imagePath 由 Quicker 的截图动作提供 $env:DOUBAO_API_KEY = "your_doubao_api_key" $env:DOUBAO_BASE_URL = "https://your-doubao-endpoint.example.com/v1" $env:DOUBAO_VISION_MODEL = "doubao-vision-model-id" $env:DEEPSEEK_API_KEY = "your_deepseek_api_key" $env:DEEPSEEK_BASE_URL = "https://api.deepseek.com/v1" $env:DEEPSEEK_MODEL = "deepseek-chat-model-id" # 调用 Python 步骤 1：图片理解 $recognized = python C:\ai-workflow\step1_understanding.py --image $imagePath # 调用 Python 步骤 2：深度推理（将第一步结果写入临时文件，再传给第二步） $recognized | Out-File -FilePath C:\ai-workflow\tmp_recognized.txt -Encoding utf8 python C:\ai-workflow\step2_reasoning.py --input C:\ai-workflow\tmp_recognized.txt

这段脚本的逻辑是：先把 Quicker 截图得到的图片路径传给第一个 Python 脚本，然后把它输出识别结果作为第二个脚本的输入，最终生成菜谱文件。

从工程角度来说，更推荐的办法是在第一步脚本中直接把识别结果写入标准输出或临时文件，第二步再读取。因为 API 调用是异步的，直接把一个脚本的输出作为另一个脚本的输入，需要处理参数传递和编码问题，容易出错。

在实际项目中，你不需要像我这样在 Quicker 中配置 API Key。更好的做法是让 Python 脚本从.env文件读取密钥，Quicker 只管传图片路径和触发脚本，这样密钥不会散落在一堆动作配置里。

6. 运行结果与效果验证

代码写完，怎么判断它真的跑通了？本节给出验证路径。

6.1 第一层验证：直接运行 Python 脚本

在项目目录下，先确认有一张测试图片screenshot.png，然后运行：

python step1_understanding.py

预期输出是模型对图片内容的文本描述。例如，如果图片里是一盘西红柿炒鸡蛋，模型可能会输出：

图片中有一盘西红柿炒鸡蛋，主要食材包括西红柿、鸡蛋、葱花，菜品颜色红黄相间，看起来是刚做好的家常菜。

如果这一步成功，说明你的豆包 API 配置、图片编码、请求格式都正确。

6.2 第二层验证：验证推理层

把识别文本复制到第二步脚本里运行：

python step2_reasoning.py

预期输出是一份结构完整的菜谱。成功标准是：

• 内容与识别结果相关；
• 步骤清晰；
• 没有明显的事实错误。

6.3 第三层验证：Quicker 动作触发

在 Quicker 里触发动作后，检查是否生成了recipe_result.md文件。打开文件，确认内容完整。

如果运行失败，第一步应该看哪里？按以下顺序排查：

1. 看 Python 脚本的控制台输出，是网络错误还是参数错误；
2. 看 API 返回的状态码，是 401、529 还是 404；
3. 看原始请求是否到达了正确的接口地址。

6.4 运行预期效果

从实践角度看，跑通这套流程后，你的桌面操作路径会变成：

• 截图 → 按快捷键 → 得到一份菜谱文件。

整个过程从原来的“打开网页 → 上传 → 复制 → 整理”缩短到几秒钟。这就是多模态自动化带来的效率提升。

7. 常见问题与排查思路

在实际使用中，最烦人的不是写代码，而是遇到莫名其妙的报错。这里整理几个高频问题。

重点说一下 529 错误。这个错误很典型：它表示模型服务端过载，是服务端的问题，通常是暂时性的。看到这个错误不要慌，也不要立刻改代码。更合理的做法是在客户端做重试，比如第一次失败后等 2 秒再试，再失败等 4 秒，最多重试 3 次。这就是指数退避重试策略，是生产环境的通用做法。

简化的重试代码如下：

import time from openai import OpenAI client = OpenAI(api_key=..., base_url=...) def call_with_retry(max_retries: int = 3): for attempt in range(max_retries): try: response = client.chat.completions.create( model="your-model-id", messages=[{"role": "user", "content": "你好"}], ) return response.choices[0].message.content except Exception as exc: if "529" in str(exc) and attempt < max_retries - 1: wait_time = 2 ** attempt print(f"服务过载，{wait_time} 秒后重试...") time.sleep(wait_time) else: raise exc

还有一个小坑想提醒你：不要把 Quicker 的截图动作和命令行动作混在一起。截图动作需要单独绑定快捷键或轮盘，命令行动作负责执行脚本。把它们拆成两个动作，调试起来会清晰很多。

8. 最佳实践与工程建议

技术方案能跑通只是第一步。如果要在实际项目中使用，推荐遵守下面几条工程建议。

8.1 密钥管理：永远不要硬编码

这是最重要的一条。API Key 是敏感凭证，写死在代码里或 Quicker 动作里，一旦项目被分享或上传到公开仓库，密钥就会泄露。

正确做法：

• 使用.env文件管理密钥；
• .env文件加入.gitignore；
• 在 CI/CD 或生产环境中使用环境变量注入。

8.2 设计一个统一封装层

不要在每个脚本里都创建 OpenAI Client。建议写一个统一的模型调用封装模块：

# 文件路径：ai-workflow/llm_client.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() def get_client(provider: str) -> OpenAI: """根据 provider 名称返回对应客户端""" if provider == "doubao": return OpenAI( api_key=os.getenv("DOUBAO_API_KEY"), base_url=os.getenv("DOUBAO_BASE_URL"), ) if provider == "deepseek": return OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url=os.getenv("DEEPSEEK_BASE_URL"), ) raise ValueError(f"Unknown provider: {provider}")

这样做的价值是，所有调用方只依赖一个封装函数，后续增加模型只需修改封装层，不用改业务代码。

8.3 图片预处理

多模态识别最大的开销往往不是 API 费用，而是图片体积。超大图片会导致请求时间长、费用升高，甚至超时。

建议：

• 截图后先压缩到合适分辨率，比如宽度 1280 像素；
• 控制体积在 1MB 以内；
• 优先使用 Base64 内嵌，但如果图片在公网有稳定 URL，可以直接传 URL。

8.4 日志与可观测性

AI 应用最容易出现的问题就是“这次行，下次不行”。因为模型输出具有随机性，请求也可能因为服务端波动而失败。

推荐在 Python 脚本中加入日志记录：

import logging logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", filename="workflow.log", ) logging.info("开始调用豆包视觉模型")

记录关键信息：

• 请求时间；
• 使用哪个模型；
• 输入图片大小；
• 输出结果长度；
• 耗时。

这些日志能帮你在问题出现时快速定位。

8.5 关注成本

模型 API 是按 token 或按次计费的。多模态请求的费用通常比纯文本高，因为图片部分占据了大量输入 token。

成本控制建议：

• 先小图测试，再处理大图；
• 识别任务限制 max_tokens；
• 重复性任务加入缓存，比如对相同图片不做二次识别。

8.6 尊重服务条款与合规边界

这是一条底线。调用任何 API 都必须在官方服务条款允许的范围内，不能绕过鉴权、突破访问限制、批量抓取。生产环境中如果涉及用户数据，需要确认数据脱敏和合规要求。

9. 总结与后续学习方向

到这里，整条链路已经讲完了。如果你想快速回顾，这套方案的核心是四句话：

• Quicker 负责把 AI 能力变成桌面操作入口；
• 豆包 API 负责视觉理解和中文内容理解；
• DeepSeek 负责深度推理和内容生成；
• DeepSeek Harness 负责把多模型编排成一条流水线。

这篇文章真正想传递的不是某个具体 API 的调用代码，而是一种思路：在 AI 时代，工具组合的价值远远大于单个工具。不要把自己锁在网页版的交互里，更不要被“写代码很难”吓退。一次封装，无限复用，这才是把 AI 变成生产力的正确方式。

如果接下来你想继续深入，建议按这个顺序推进：

1. 把豆包 API 的文本对话能力接入到日常写作场景；
2. 用 Harness 配置文件把视觉理解和推理流程沉淀成模板；
3. 在 Quicker 中设计一套你自己的动作面板，把常用 AI 场景全部入口化；
4. 了解模型服务的计费体系，建立成本意识。

这套方案也能继续扩展。比如，你可以在 Harness 配置中增加 OCR 步骤、语音识别步骤，或者把输出接入到指定文件夹、邮件、聊天工具。核心链路不变，能力模块可以越加越多，这才是这个组合最大的想象力所在。

建议收藏备用。等你跑通第一个截图识别动作之后，再回来看这篇文章，你会发现自己对“多模态”三个字的理解已经不一样了。