多模态 AI 实战：用 Claude 4.7 和 Gemini 3 搭建图文理解 Pipeline

2026 年的多模态不再是”能看图”

如果你对多模态 AI 的印象还停留在 2024 年——上传一张图，模型说”这是一只猫”——那你错过了太多进展。

2026 年 5 月的多模态 AI 已经能做到：Claude 4.7 可以读一份 30 页的扫描合同，提取出所有关键条款并标注风险点，OCR 准确率超过 96%；Gemini 3 可以看完一个 45 分钟的产品评审会议录像，输出结构化的会议纪要，包括每个参与者的发言要点和 action items；GPT-5.5 可以看一张系统架构图和对应的代码库截图，告诉你架构图和实际代码有哪三处不一致。

多模态的价值不再是”理解图片内容”，而是”跨模态关联推理”。 今天我要用三个真实场景的代码实现来展示这一点。

场景一：发票 OCR + 结构化提取

这是最常见的多模态应用场景——拍一张发票照片，自动提取出所有字段，返回结构化 JSON。

import Anthropic from "@anthropic-ai/sdk";
import { readFileSync } from "fs";

interface InvoiceData {
  invoiceNumber: string;
  date: string;
  vendor: string;
  items: Array<{ name: string; quantity: number; unitPrice: number }>;
  subtotal: number;
  tax: number;
  total: number;
}

async function extractInvoice(imagePath: string): Promise<InvoiceData> {
  const client = new Anthropic();
  const imageBuffer = readFileSync(imagePath);
  const base64Image = imageBuffer.toString("base64");
  const mediaType = imagePath.endsWith(".png") ? "image/png" : "image/jpeg";

  const response = await client.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 1024,
    messages: [
      {
        role: "user",
        content: [
          {
            type: "image",
            source: { type: "base64", media_type: mediaType, data: base64Image },
          },
          {
            type: "text",
            text: `Extract all information from this invoice image.
Return a JSON object with this exact structure:
{
  "invoiceNumber": "string",
  "date": "YYYY-MM-DD",
  "vendor": "string",
  "items": [{"name": "string", "quantity": number, "unitPrice": number}],
  "subtotal": number,
  "tax": number,
  "total": number
}
Return ONLY the JSON, no other text.`,
          },
        ],
      },
    ],
  });

  const textBlock = response.content.find((b) => b.type === "text");
  return JSON.parse(textBlock?.text ?? "{}");
}

几个工程要点：

1. 模型选择：用 Sonnet 不用 Opus。 OCR + 结构化提取是模式匹配任务，不需要深度推理。Sonnet 的视觉能力足够，成本是 Opus 的 1/5。

2. 图片预处理很重要。 在实际项目中，我在调用 API 之前会做两步预处理：(a) 把图片分辨率调整到 1500px 以内（太大浪费 token，太小丢细节）；(b) 增强对比度（拍照发票经常光线不均匀）。

3. 用 JSON mode 而非自由文本。 明确告诉模型 “Return ONLY the JSON”，并给出完整的结构定义。如果需要更严格的约束，可以用 tool_use 模式让模型直接调用一个接受 InvoiceData schema 的函数。

准确率数据

我用 200 张真实发票（中英文混合、打印 + 手写、不同模板）测试了 Claude 4.7 Sonnet 的 OCR 准确率：

手写部分仍然是短板，但打印内容的准确率已经超过了大多数传统 OCR 引擎。

场景二：技术架构图理解 + PlantUML 生成

这个场景更有意思——上传一张系统架构图（白板拍照或 draw.io 导出），让模型理解组件关系，然后生成可编辑的 PlantUML 代码。

import Anthropic from "@anthropic-ai/sdk";
import { readFileSync } from "fs";

async function architectureDiagramToPlantUML(imagePath: string): Promise<string> {
  const client = new Anthropic();
  const imageBuffer = readFileSync(imagePath);
  const base64Image = imageBuffer.toString("base64");

  const response = await client.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 2048,
    messages: [
      {
        role: "user",
        content: [
          {
            type: "image",
            source: {
              type: "base64",
              media_type: "image/png",
              data: base64Image,
            },
          },
          {
            type: "text",
            text: `Analyze this system architecture diagram. Identify all components, 
their relationships (data flow, API calls, dependencies), and any labels or annotations.

Then generate PlantUML code that accurately represents this architecture.

Requirements:
1. Use @startuml/@enduml blocks
2. Use appropriate PlantUML components (rectangle, database, queue, cloud, etc.)
3. Label all connections with their protocol/type (HTTP, gRPC, WebSocket, etc.)
4. Group related components using packages or namespaces
5. Preserve the original layout direction (left-to-right or top-to-bottom)

Return ONLY the PlantUML code.`,
          },
        ],
      },
    ],
  });

  const textBlock = response.content.find((b) => b.type === "text");
  return textBlock?.text ?? "";
}

为什么这个场景价值高？

在实际工程中，架构图的维护是一个永恒的痛点——Confluence 上的架构图和实际系统总是对不上。用这个 pipeline，团队可以：

1. 白板上画架构设计 → 拍照 → 自动生成 PlantUML → 存入代码仓库
2. 系统架构变更后 → 截图新状态 → 和旧的 PlantUML 对比 → 自动标注差异

我在团队内部用了两个月，架构文档的更新频率从”季度”变成了”每次架构变更后”。原因很简单：以前更新架构图需要打开 draw.io 手动改半小时，现在截个图跑一下脚本就完事了。

场景三：视频会议摘要

这个场景用 Gemini 3，因为它支持原生视频输入——不需要你自己抽帧。

import { GoogleGenerativeAI } from "@google/generative-ai";
import { readFileSync } from "fs";

interface MeetingSummary {
  title: string;
  duration: string;
  participants: string[];
  keyDecisions: string[];
  actionItems: Array<{
    owner: string;
    task: string;
    deadline: string;
  }>;
  openQuestions: string[];
}

async function summarizeMeeting(videoPath: string): Promise<MeetingSummary> {
  const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
  const model = genAI.getGenerativeModel({ model: "gemini-3-pro" });

  const videoBuffer = readFileSync(videoPath);
  const base64Video = videoBuffer.toString("base64");

  const result = await model.generateContent([
    {
      inlineData: {
        mimeType: "video/mp4",
        data: base64Video,
      },
    },
    {
      text: `You are a meeting analyst. Watch this meeting recording and produce a structured summary.

Return a JSON object:
{
  "title": "meeting topic",
  "duration": "estimated duration",
  "participants": ["name1", "name2"],
  "keyDecisions": ["decision 1", "decision 2"],
  "actionItems": [
    {"owner": "name", "task": "description", "deadline": "date or 'TBD'"}
  ],
  "openQuestions": ["question 1"]
}

Focus on:
- Who made what decisions
- Specific action items with clear owners
- Unresolved questions that need follow-up
Return ONLY the JSON.`,
    },
  ]);

  const text = result.response.text();
  return JSON.parse(text);
}

Gemini 3 视频理解的能力边界：

注意事项：视频文件大小。 一个 30 分钟的 720p 会议录像约 500MB，直接上传 API 不现实。实际操作中我会先用 ffmpeg 做预处理：

# 降低分辨率 + 压缩 → 约 50MB
ffmpeg -i meeting.mp4 -vf "scale=640:-1" -b:v 500k -an meeting_compressed.mp4

去掉音轨（-an）是因为 Gemini 3 的视频理解主要基于视觉帧，纯音频内容还是用 Whisper → LLM 的 pipeline 更准确。

2026 多模态基准对比

数据来源：MMMU-Pro、DocVQA、ChartBench、VideoMME 等公开基准 + 我的内部测试集。

选型指南：什么场景用谁

生产注意事项

图片大小和 token 消耗。 这是最常被忽视的成本因素。一张 2000x2000 的图片在 Claude 中消耗约 6400 tokens——如果你每天处理 10000 张图片，光图片 token 就要 $192/天（Sonnet 价格）。解决方案：在调用 API 前把图片缩放到刚好够用的分辨率（大多数 OCR 场景 1200px 宽就足够）。

隐私合规。 如果图片包含 PII（个人身份信息），比如身份证、护照、医疗记录，要确保你的 API 调用符合相关法规。Anthropic 和 Google 都有 data processing addendum，但你需要主动签署。另外，考虑在发送前对敏感区域做模糊处理（如果那部分信息不是提取目标）。

批量处理的并发控制。 多模态 API 调用通常比纯文本调用慢 2-3 倍（图片编码 + 视觉处理）。批量处理时设置合理的并发上限（建议 5-10 个并行请求），避免触发 rate limit 后大面积重试。

// 批量处理时的并发控制
async function processImagesWithConcurrency(
  imagePaths: string[],
  maxConcurrent: number = 5
): Promise<InvoiceData[]> {
  const results: InvoiceData[] = [];
  for (let i = 0; i < imagePaths.length; i += maxConcurrent) {
    const batch = imagePaths.slice(i, i + maxConcurrent);
    const batchResults = await Promise.all(
      batch.map((path) => extractInvoice(path))
    );
    results.push(...batchResults);
  }
  return results;
}