把一张项目报表截图交给系统，问它“这一列为什么和上一版对不上”，事情就比描述图片内容难得多。截图里有合并单元格、脚注、颜色标记，还有被折叠的列。人靠上下文能猜出关系，机器要先决定从哪里读、按什么顺序读。多模态模型被寄予的期待，正落在这类杂乱的日常材料上。
流畅不等于可核对
多模态模型并不是把图像识别和文本生成简单拼在一起。它要在同一条推理链里处理版式、文字、符号和语气，再把它们映射成可回答的语言。表格尤其能暴露问题：数字被读对了，单位和表头却可能错位；一句话总结看似合理，却悄悄改变了条件。演示里常见的“流畅”，到了业务流里往往变成“难以核对”。
工程上常见的做法，是先用版面分析或 OCR 把图像转成结构化文本，再交给语言模型；端到端的多模态路线则试图减少中间步骤，让模型直接看图作答。前者链路长、维护成本不低，但每一步都能留下痕迹；后者交互自然，出错时却不容易定位，是看错了单元格，还是推理时把条件丢了。选择哪条路线，取决于业务能否接受可解释性上的折中，而不是单看演示效果。
看不见的边界
视觉幻觉是另一个容易被低估的细节。模型可能“读”出一个并不存在的数字，或者把图例颜色和文字说明强行对应。若输出只是一段草稿，人工复核还能兜住；若输出直接进入审批或对外发布，风险就不是语气问题。对多模态模型而言，能承认“这里看不清”比强行补全更值得设计。产品层面可以用结构化输出、置信提示和原文定位来约束，但这些手段需要和流程一起落地，单靠提示词很难稳定。
评估也不该只盯着最终答案。对表格类任务，至少要看字段是否对齐、单位是否保留、引用能否回到原图；对文档问答，则要看答案是否越过了原文边界。人工抽检仍然重要，但抽检标准要写到可执行的程度，否则不同人会给同一份输出不同结论。
我倾向于把这类系统看成一种新的输入层，而不是万能接口。它让系统第一次能比较自然地接触截图、白板和扫描件，但把“看见”变成“可负责的结果”，还需要数据治理、界面设计和人工复核共同完成。短期内，它适合做检索、归纳和初稿；涉及责任归属的判断，仍要留在人的手里。把边界写进流程，才算真正开始使用它。