图片进管道，先分清楚：要"取字"还是"理解"

两个能力，边界要划清#

处理图片有两类完全不同的能力：

• OCR（光学字符识别）：把图里的文字提取出来。只取字，不理解意思。
• Vision（多模态理解）：理解图片内容。能看图说话、描述画面、回答关于图的问题。

一个”提取文字”的问题，用理解模型去做，又贵又容易跑偏；一个”理解图意”的问题，用纯 OCR 去做，得到一堆字却回答不了问题。

边界划分表（铁律）#

关键判断：你最终需要的是”一串文字”，还是”对图的理解”？要字 → OCR；要懂 → Vision。

一个真实的坑#

用户提交流程图图片，走 OCR 分析。结果 OCR 返回的是嵌入式图片引用而非流程图文字——数据到手却是错的。

原因：OCR 默认模式处理”图片里有图片”的场景，把内嵌图当成了引用，没把文字抽出来。切换模型版本并开启”图片内文字”选项后，才正确输出流程图文字。

这个坑的教训：工具选对只是第一步，同一类工具的配置细节也可能让它答非所问。验证时不要只看”返回了什么”，要确认返回的是你要的那一层内容。

文字模型永远别”猜图”#

还有一个更隐蔽的坑：没有视觉能力的纯文字模型，绝不能被要求”看一下这张图”。

文字模型处理图片，本质是在猜。对话上下文里有点线索它就能”脑补”出一段看似合理的描述——但那是编的。如果系统里必须有一个文字模型和图片打交道，正确的做法是：先用多模态模型把图片转成文字描述，再交给文字模型继续处理。取字走 OCR，理解走 Vision，文字模型只接文字。

结论#

图片处理的第一步不是写代码，是回答一个问题：这图要的是字，还是懂？

• 要字 → OCR（便宜、快、准）
• 要懂 → 多模态 Vision（能回答、能描述）
• 纯文字模型 → 永远不要让它直接碰图，先转文字再交接

把边界划清楚，处理图片的需求能少踩一半的坑。