有人把一张现场照片丢给模型，问“这里有什么问题”。模型把画面里的标签、线缆颜色、端子的排列一五一十描述了一遍，语气笃定。答案对不对先放一边，真正麻烦的是：看描述的人没法照着它去动手。他需要的是“第几排、第几个”，而不是一段读起来很顺的话。
这种落差在多模态模型的落地里反复出现。它擅长把像素翻译成语言，而下游系统接住的往往是字段、坐标、状态码。从一句通顺的描述走到一个可执行的结果，中间隔着的常常不是模型能力，而是接口设计和容错机制。
描述是开放的，判断是收敛的
模型可以列出画面里所有可能相关的元素，而现场要的是收敛：合格或不合格，是或不是。这个收敛动作需要有人先把标准写清楚——什么算看清了，什么算看不清，看不清的时候又该怎么办。这些定义不在模型里，在流程里。
另一个难点是错误的表现形式。文字任务里的幻觉是编造事实，容易被抓住；多模态模型的幻觉更隐蔽，它会给出一个和画面细节略有偏差的读数，句子依然流畅，语法依然正确，只有把原图放大对照才发现不对。流畅本身就是一层伪装，读的人越信任文字，越容易跳过核对。
被压缩掉的细节
从技术路径看，多数多模态模型会先把图像切成小块，编码成向量，再投影到语言模型能读的空间里。这条路径效率高，代价则落在分辨率上。一张扫描件被压成几百个视觉 token 之后，最先消失的是小字号、手写批注和密集的表格线。
所以不少工程问题并不在“模型够不够聪明”，而在“信息进入模型之前还剩多少”。切图、局部放大、提高输入分辨率，都是笨办法；可在细节已经丢失的情况下，换一个参数更多的模型也补不回来。判断一个方案是否可行，多看几眼预处理，通常比多看几眼介绍有用。
输出得能用，不只是像话
接口层面，约束输出结构是常见做法：要求模型返回固定字段，附带对自身确定程度的说明，并允许它回答“无法判断”。这条“允许拒绝”很关键。一个总被要求给出答案的模型，会在模糊处编一个最像的答案，而且编得很像。
评测是另一处容易被低估的成本。文本任务可以拿标准答案比对，视觉任务的光标注就贵得多，同一张图不同的人给出的框都可能对不上。没有相对稳定的评测集，团队很难分清一次改动是改进还是噪声，只能凭印象拍板。
我的看法偏保守：多模态模型眼下站得稳的位置，是读、摘、初筛——把截图里的信息转成可检索的文本，把长文档里的表格挑出来，把成堆的照片按内容归类。端到端的自动决策，还是留给错误代价可控、并且有明确兜底流程的场景。
反过来，也不必因为不够准就搁置。把模型放在人前面当第一道筛子，人只看它标出来的部分，这个分工在很多流程里已经能省下时间。前提是团队清楚它会在哪里出错，并且出错的时候有人接得住。