#多模态 AI 对前端意味着什么

过去很多 AI 应用都是文本框驱动的：用户输入一段话，模型返回一段话，前端负责展示 Markdown、处理 Streaming、保存会话。

多模态 AI 会把这个边界打开。用户不再只输入文本，还会输入截图、照片、PDF、语音、视频片段和设计稿。AI 也不再只返回文本，可能返回标注、结构化数据、修图结果、语音、页面区域引用和可编辑草稿。

这对前端工程师很重要。因为前端本来就是多媒体、交互和状态的入口。上传、预览、拖拽、标注、裁剪、录音、播放、权限提示、进度反馈、错误恢复，这些都不是模型能力本身能自动解决的，而是产品体验能否成立的关键。

多模态不是“给 Chat 加一个上传按钮”。它意味着前端要重新设计输入、上下文、反馈和结果呈现。

#从文本输入到媒体输入

文本输入的特点是轻量、线性、易复制、易截断。图片、音频、PDF 和视频则完全不同。

它们至少带来五类新问题：

• 文件体积更大，上传、压缩、缓存和重试都更重要。
• 内容不是天然结构化的，需要 OCR、转写、帧抽取或版面解析。
• 用户需要预览和确认，否则很难知道 AI 到底看到了什么。
• 输入中可能包含隐私、证件、合同、内部系统截图等敏感信息。
• 模型成本和延迟通常显著高于纯文本。

因此，多模态前端的第一件事不是调用模型，而是建立一条稳定的媒体输入链路。

这条链路里，模型调用只是其中一环。用户感知到的体验，更多来自前后步骤是否可靠。

#多模态能力不是一个能力

“支持图片”听起来像一个功能，但它实际包含很多不同能力。

图片能力可能是：

• 识别画面里有什么。
• 回答关于图片的问题。
• 理解 UI 截图中的按钮、状态和报错。
• 抽取票据、表格、合同里的文字。
• 判断图片是否符合某个规则。
• 对图片做区域标注。
• 生成图片描述，用于检索或无障碍。
• 基于图片生成或编辑另一张图片。

这些能力的工程设计不一样。

例如，“看图回答问题”可以把图片和问题直接发给视觉模型；“发票识别”则更像文档处理，需要字段 schema、置信度、人工校对和审计记录；“UI 截图诊断”需要把截图区域和用户操作步骤关联起来；“商品图审核”需要批处理、队列和规则解释。

前端做产品设计时，不能只问“模型能不能看图”，而要问：

• 用户提交的媒体是什么来源？
• 用户希望 AI 完成的是理解、抽取、判断、生成还是编辑？
• 结果是否需要可追溯到图片区域或文档页码？
• 错误时用户能否修正输入或结果？
• 延迟能否被接受，是否需要异步任务？

#前端新增的核心职责

多模态 AI 会让前端职责从“发送消息和展示答案”扩展为“媒体工作台”。

#输入控制

前端要明确控制可接受的输入，而不是把所有文件都丢给后端。

常见控制包括：

• 文件类型：图片、PDF、音频、视频是否分开处理。
• 文件大小：单文件大小、总大小、页数、时长。
• 数量限制：一次最多几张图、几个文件。
• 分辨率限制：超大图片是否压缩，过小图片是否提示不清晰。
• 隐私提示：是否包含身份证、银行卡、合同、客户数据。
• 网络策略：弱网下是否允许后台上传和断点重试。

这些限制应该在 UI 上提前表达，不要等模型报错后再告诉用户“不能处理”。

#预览与确认

多模态输入需要预览。

对于图片，用户要看到缩略图、文件名、大小和删除按钮。对于 PDF，用户至少要看到页数和封面页。对于音频，用户要看到时长和可播放状态。对于视频，用户要知道系统会处理哪些帧或片段。

预览不是装饰，它解决的是控制感。用户需要确认：“我上传的是正确内容，AI 将会基于这些内容回答。”

#标注与局部输入

很多多模态任务不是让 AI 看完整文件，而是让 AI 看某个局部。

例如：

• 圈出截图中的报错区域。
• 选择 PDF 的第 3 到 5 页。
• 裁剪票据中的表格区域。
• 在设计稿上标记想修改的组件。
• 截取音频中的某一段。

前端需要把这些交互转成结构化输入。

type ImageRegion = {
  imageId: string;
  page?: number;
  x: number;
  y: number;
  width: number;
  height: number;
};

type MultimodalUserInput = {
  text: string;
  attachments: Array<{
    id: string;
    type: 'image' | 'pdf' | 'audio' | 'video';
    url: string;
    selectedRegions?: ImageRegion[];
  }>;
};

这个数据模型比一个 fileUrl 更有价值，因为它保留了用户意图。

#结果可追溯

纯文本回答只需要展示答案。多模态回答经常需要展示“答案来自哪里”。

例如文档问答要引用页码，OCR 抽取要标出字段来源区域，截图诊断要高亮对应按钮，图表解读要指出使用了哪段曲线或哪个坐标轴。

这会影响后端返回格式，也会影响前端组件模型。

type MultimodalAnswer = {
  text: string;
  citations: Array<{
    sourceId: string;
    sourceType: 'image' | 'pdf-page' | 'audio-segment' | 'video-frame';
    label: string;
    page?: number;
    timeRangeMs?: [number, number];
    region?: { x: number; y: number; width: number; height: number };
  }>;
};

有了这样的结构，前端才能实现点击引用后跳转到页面、播放音频片段或高亮图片区域。

#多模态交互设计的变化

多模态 AI 的交互重点不是“让用户上传”，而是让用户理解系统正在如何处理输入。

#上传状态要更细

纯文本发送通常只有 sending 和 failed。媒体输入至少需要这些状态：

• waiting：等待上传。
• validating：校验格式、大小、页数。
• preprocessing：压缩、转码、抽帧。
• uploading：上传中。
• uploaded：上传完成。
• analyzing：AI 正在解析。
• ready：可进入对话上下文。
• failed：失败，带可理解原因。

一个简化状态模型可以这样写：

type AttachmentStatus =
  | 'waiting'
  | 'validating'
  | 'preprocessing'
  | 'uploading'
  | 'uploaded'
  | 'analyzing'
  | 'ready'
  | 'failed';

type Attachment = {
  id: string;
  name: string;
  mimeType: string;
  size: number;
  status: AttachmentStatus;
  previewUrl?: string;
  error?: string;
};

状态越清楚，用户越不容易把慢、失败、不可用混成一种挫败感。

#进度反馈要分阶段

多模态任务耗时更长。如果只展示一个 loading，用户不知道是在上传慢、解析慢，还是模型生成慢。

更好的方式是分阶段展示：

• 正在压缩图片。
• 正在上传 2/5 个文件。
• 正在识别第 4/20 页。
• 正在生成回答。
• 正在整理引用来源。

这些文案不需要很花哨，但要真实反映系统阶段。

#允许用户修正

多模态 AI 的错误经常来自输入质量，而不是模型本身。例如图片太糊、PDF 扫描歪斜、截图没有包含完整报错、音频背景噪声过大。

前端应该允许用户修正：

• 重新上传更清晰的图片。
• 裁剪关键区域。
• 删除无关文件。
• 手动修正 OCR 字段。
• 编辑语音转写结果后再发送。
• 选择文档页码范围。

这类交互比“重新生成”更重要，因为它改变了输入条件。

#工程架构上的变化

多模态 AI 应用通常需要从同步接口走向“同步 + 异步任务”的混合架构。

简单图片问答可以同步返回，但大 PDF、长音频和视频处理很难在一次请求里完成。前端需要支持任务状态轮询或服务端事件推送。

这个架构的好处是把媒体处理从聊天请求中拆出来。用户可以先上传和解析附件，再发起对话；失败也可以定位到具体附件。

#数据模型要区分原始媒体和解析结果

很多系统会犯一个错误：上传文件后只保存一个 URL，然后每次对话都重新解析。

更好的方式是区分：

• 原始文件：用户上传的真实媒体。
• 派生文件：缩略图、压缩图、音频转码、视频帧。
• 解析结果：OCR 文本、布局块、语音转写、图片描述。
• 引用映射：文本片段和原始媒体区域之间的关系。
• 使用记录：哪次 run 使用了哪些附件和解析版本。

一个简化模型如下：

type MediaAsset = {
  id: string;
  ownerId: string;
  type: 'image' | 'pdf' | 'audio' | 'video';
  originalUrl: string;
  createdAt: string;
};

type MediaAnalysis = {
  id: string;
  assetId: string;
  version: string;
  status: 'processing' | 'ready' | 'failed';
  text?: string;
  blocks?: Array<{
    id: string;
    content: string;
    page?: number;
    region?: { x: number; y: number; width: number; height: number };
  }>;
};

这样做的价值是可复用、可追踪、可缓存。用户同一份 PDF 追问多次，不应该每次都重新 OCR。

#成本与延迟会变成产品约束

多模态模型通常更贵、更慢。前端不能假设“上传越多越好”。

常见策略包括：

• 上传前压缩图片，但保留足够清晰度。
• 大 PDF 先让用户选择页码范围。
• 视频先抽关键帧，而不是完整视频直接进模型。
• 音频先转写，再把转写文本进入后续 LLM 链路。
• 对重复附件复用解析结果。
• 对低风险任务先用便宜模型预处理，再把难例交给强模型。

这些策略都需要前端配合。比如页码选择、清晰度提示、附件复用、任务进度、成本提示，都发生在界面上。

#常见坑

#把多模态当作文件上传功能

文件上传只是入口。真正的多模态工程包括预处理、解析、上下文组装、结果映射和错误恢复。

如果只做上传，很快会遇到“上传成功但 AI 不知道怎么用”的问题。

#不展示 AI 实际看到了什么

用户上传了一张复杂截图，模型回答错了。到底是模型理解错了，还是截图太小，还是系统压缩过度，还是只传了缩略图？

如果前端不展示解析状态、预览图、页码范围和引用来源，问题就很难定位。

#忽略隐私和权限

截图、合同、票据、病历、客户资料都可能进入多模态输入。前端要在上传前提示风险，后端要做权限校验、生命周期管理和访问审计。

不要把附件 URL 当作普通静态资源长期公开。

#一次性把所有内容塞给模型

多模态输入很容易膨胀。多张高清图、几十页 PDF、长音频转写都会带来成本和上下文压力。

工程上应该先解析、筛选、切分和检索，再把必要部分交给模型。

#只考虑成功路径

多模态失败非常常见：文件损坏、格式不支持、上传中断、OCR 失败、音频无声、PDF 加密、图片过糊、视频过长。

每一种失败都应该有用户能理解的提示和下一步动作。

#小结

多模态 AI 对前端的意义，不是让聊天框支持更多文件类型，而是让前端成为媒体输入、用户意图和 AI 能力之间的工程边界。

前端工程师需要关注文件状态、预览确认、局部标注、异步任务、引用映射、隐私权限、成本延迟和错误恢复。模型可以理解图片、音频和文档，但产品能不能稳定可用，取决于这些工程细节是否被认真设计。

进入多模态阶段后，一个好的前端不只是把数据发出去，而是帮助用户把复杂世界整理成 AI 可以可靠处理的上下文。