你满心期待地打开 DeepSeek 的聊天框把一张聊天记录截图、一张 Excel 表格截图拖进去然后输入“帮我把这页数据整理成表格并且统计出总额。”它很快回了一句话“我是一个纯文本模型目前无法直接识别图片中的内容。”这不是它变笨了而是你越过了它的能力边界。DeepSeek 在很长一段时间里都专注于文本输入输出它的核心场景是代码、文档、推理、对话不是“看图说话”。但“看图”的需求又是真实存在的票据、截图、表格、流程图、UI 草图这些信息都长在图片里不转成文字模型就处理不了。于是社区里冒出一个既实用、又有点“取巧”的方案——给 DeepSeek 安上眼睛。严格说这不是原生多模态更像是一种“伪多模态”用外部工具把图像翻译成文本再让 DeepSeek 基于文本做推理。这篇文章想把这件事讲透包括它的原理、实现路径、参数细节以及它到底适合什么场景不适合什么场景。1. 先把“伪多模态”这件事说清楚它不是模型变聪明而是流程变长了1.1 真正的多模态和“伪多模态”差在哪原生多模态模型的底层是视觉编码器加语言模型的联合训练。图像会先被编码成向量再和文本指令一起进入模型模型自己就能“看到”图片。如果 DeepSeek 原生支持识图API 请求里会直接有图像字段你不需要在外部做任何转换。伪多模态没有这层。它做的事情是先用另一个模型或工具把图片转成文本再把文本作为输入传给 DeepSeek。换句话说模型本身依然看不到图片看到图片的是前面的“翻译官”。所以“伪”字不是在贬低这个方案而是在提醒我们一个事实模型的能力边界没有变变的是整个调用链路的长度。你从“一张图片直接提问”变成了“图片 → 文本 → 提问 → 推理 → 输出”。链路长了灵活性反而高了因为你可以在中间插入 OCR、视觉描述、结构化抽取等不同环节。记住这个判断伪多模态解决的不是“让 DeepSeek 拥有视觉”而是“让 DeepSeek 拿到图片里的信息”。1.2 为什么这种方式能跑通本质是把“视觉问题”转成“文本问题”文本模型最擅长的就是处理文本。截图里的字被 OCR 提取后变成字符串UI 流程图被视觉模型转述成“这是一个登录页面包含用户名框、密码框和登录按钮”票据里的金额被识别成“人民币 12,800 元”。DeepSeek 拿到这些文本后照样能完成推理、总结、代码生成。关键在于识图任务里真正难的是“图像理解”但很多业务场景要的其实只是“图像里的信息和结构”。信息能被文本化结构能被描述清楚文本模型就能接手。举个例子。你要 DeepSeek 帮你把一张表格截图生成 Markdown 表格如果它没长眼睛这事做不了。但你先用 OCR 把表格里的每一行每一列抽成带分隔符的纯文本再把这段文本交给 DeepSeek它会处理得很好。DeepSeek 不需要看到表格的边框它只需要看到行列关系。这也是“伪多模态”能成立的底层逻辑视觉任务可以被拆成“感知”和“推理”两步。感知交给专门的视觉工具推理交给文本模型。两者各干各的再通过接口串起来。2. 三条给 DeepSeek“装眼睛”的常见路径怎么选给 DeepSeek 加上识图能力不是只有一个办法。根据你的场景、成本和精度要求通常有三条路径可以走。2.1 路径一纯 OCR适合图片里主要是文字的场景如果图片里的核心内容就是文字比如截图、文档、票据、表格那么最简单的方式是 OCR。OCR 把图片里的文字识别出来变成纯文本然后直接交给 DeepSeek。优势是成本低、速度快、实现简单。很多 OCR 引擎在本地就能跑不依赖额外的大模型也没有图像 token 费用。劣势是它只能提取文字不能理解图像里的非文字信息。比如一张界面截图里有红色按钮、布局、图标OCR 只能拿到按钮上的文字拿不到按钮的位置视觉关系。纯 OCR 适合的场景很明确文字密集、结构清晰、不需要空间关系推断。比如“把这张聊天记录总结成要点”“把这张发票的内容提取出来”。2.2 路径二视觉描述模型适合图片里没有太多文字但有信息结构如果图片本身是照片、流程图、UI 草图、产品外观文字很少纯 OCR 就失效了。这时候需要另一个“眼睛”一个支持图像输入的视觉语言模型把图片内容转述成自然语言描述。操作上你把这个视觉模型当成中间服务输入图片输出一段描述文本再把描述文本交给 DeepSeek。视觉模型负责“看”DeepSeek 负责“想”。优势是适用范围更广能处理照片、图表、界面等非纯文字信息。劣势是描述过程中可能丢失细节而且多了一层模型调用成本和耗时都会增加。选这个路径时视觉模型的描述能力很关键。描述写得越完整DeepSeek 后面的推理就越准。2.3 路径三编排框架适合想把流程固化下来长期使用第三类方式是使用编排框架、插件或客户端工具把“图片输入 → 视觉转换 → DeepSeek 推理 → 结果输出”整个流程封装起来。这也是社区里最常被提到的做法。很多第三方客户端和开源项目已经支持给 DeepSeek“挂”一个视觉 skill 或插件。这种路径的优势是体验好不需要自己写代码用户直接把图片拖进对话框框架会自动调用视觉模型生成文本再传给 DeepSeek。劣势是依赖具体项目版本变化快配置复杂而且不同项目对隐私、数据存储、密钥管理的处理方式差异很大。如果你想快速验证效果可以先试这类编排工具如果你想稳定落地到自己的业务里我更建议自己实现流程因为可控性更高。2.4 三条路径怎么选路径适合场景主要成本实现难度信息保真度纯 OCR截图、文档、票据、表格低本地可跑低文字保真非文字信息丢失视觉描述模型照片、流程图、UI 草图中额外模型调用中取决于描述模型能力可能丢细节编排框架想快速上手、固化流程视项目而定中到高依赖内部封装的视觉模块不要一上来就追求“最全”的方案。先看你的图片里到底有什么是文字多还是结构多还是视觉细节多。文字多用 OCR结构多用描述模型两者都有才考虑组合使用。3. 最小可用流程从一张图片到一段文本回复下面我给出一个最小可用的“伪多模态”流程。这里不绑定具体工具因为不同环境下的 OCR 引擎和视觉模型差异很大重点是让你理解整个链路的关键环节。3.1 前置准备先确认你有哪些基础资源开始之前你需要准备三样东西一个 DeepSeek API Key以及能正常访问 DeepSeek 开放平台的网络环境一个能把图片转成文本的工具可以是本地 OCR 库也可以是一支持图像输入的模型接口一段把整条链路串起来的小程序Python 脚本足够。如果原始材料里没有说明具体依赖版本落地前先确认你用的 OCR 库、视觉模型 SDK 和 DeepSeek SDK 之间的版本兼容关系。不要盲目升级某一边容易踩到依赖坑。3.2 第一步把图片变成文本假设你选择 OCR 路径。你先把图片读入调用 OCR 引擎得到文本。下面是一个常见写法的示意结构具体参数以你实际使用的库为准# 示例结构使用 OCR 库识别图片中的文字 from PIL import Image import your_ocr_engine # 换成你实际使用的 OCR 库 image_path ./example_table.png img Image.open(image_path) # 这里通常会有语言、格式、是否输出坐标等参数 result your_ocr_engine.recognize(img, langch, output_formattext) print(result)如果你选视觉描述模型路径这个环节就会变成调用一个支持图像输入的模型接口让它输出图片的自然语言描述。需要注意一些模型服务会把图片当作 base64 字符串传入也可能要求传入图片 URL。具体格式要提前查清楚。3.3 第二步把文本交给 DeepSeek拿到图中文本之后把它拼进系统提示词或用户消息里。为了让 DeepSeek 理解“这段文字是从图片里提取的”最好在提示词里明确告诉它。# 示例结构调用 DeepSeek API将 OCR 文本交给模型 from openai import OpenAI client OpenAI( api_key你的_key, base_urlhttps://api.deepseek.com ) ocr_text 这里替换为第一步识别出来的文本 user_message ( 下面是从一张表格截图中识别出来的原始文本可能带换行和噪声。\n 请把它整理成规范 Markdown 表格并计算最后一列的总和。\n\n f{ocr_text} ) response client.chat.completions.create( modeldeepseek-chat, # 以你的账号实际可用的模型名为准 messages[ {role: system, content: 你是信息整理助手擅长从文本中还原结构化内容。}, {role: user, content: user_message} ] ) print(response.choices[0].message.content)这里有两个容易踩的坑第一不要把 OCR 结果原封不动丢掉。OCR 输出可能带多余换行、空格、乱码但先别急着清理让 DeepSeek 做格式化反而更稳。你把噪声清理得越狠越容易误删关键信息。第二模型名不要写死。不同时间、不同账号下可用模型可能不同先用开放平台控制台里的实际模型名。3.4 第三步先做单条验证再批量第一次跑通时不要直接处理 100 张图。先用一张内容最有代表性的图片验证三个东西OCR/描述结果是否完整、DeepSeek 是否理解任务、输出格式是否符合预期。如果 OCR 结果缺字先调识别语言或清晰度而不是改 DeepSeek 的提示词如果 DeepSeek 输出格式不对修改任务描述如果链路整体没问题再考虑批量。不要一上来把目标图片当作批量任务直接跑先用一张图验证三个东西文字提取是否完整、描述是否准确、DeepSeek 输出是否符合预期。4. 关键参数与 token 预算这里决定你能否批量使用很多人第一次跑通后第二件事就是“我要一次处理几千张图片”。但在批量之前有几个参数和预算问题必须弄明白。4.1 图片压缩和 base64直接影响等待时长图片不是直接发给 DeepSeek 的它是先发给视觉模块。视觉模块接收图片时一般有两种方式传本地文件路径或者传 base64 字符串。如果你用 API 调用视觉模型大概率是传 base64。base64 会把图片体积增加约 33%。一张 2MB 的图片base64 后接近 2.7MB上传和解析都会变慢。实际上大部分识图场景根本不需要原图那么大。比如识别一张截图里的文字把图片压缩到 1280px 宽度甚至 800px 宽度通常会更快识别率也未必下降。建议在进入视觉模块之前先做一次图片预处理统一图片格式为 JPEG 或 PNG把长边压缩到 1280px 左右图片过暗、过模糊时先做基础增强如果是批量任务图片命名规范里带上业务 ID方便后面追查。4.2 OCR 和描述模型的 prompt 倾向如果是纯 OCR尽量用高识别精度的“文本模式”不要把 OCR 引擎的自动分段结果当成最终格式。你可以先让它输出带行号或坐标的原始文本方便后续对齐。如果是视觉描述模型提示词要尽量具体。比如“请描述这个界面里所有可见的按钮、输入框、文本和它们的相对位置”比“描述一下这张图”要好得多。描述越结构化DeepSeek 越容易完成任务。视觉模型描述时你还要注意一个取舍描述越详细token 越多描述越简单信息丢失越严重。我的建议是在正文内容保真和 token 消耗之间取平衡先让描述模型输出结构化要点不要输出散文。4.3 DeepSeek 上下文和成本预算DeepSeek 处理的是文本所以图片信息转成文本后会占用它的上下文空间。一张复杂截图的 OCR 结果可能 2000 到 5000 字一段完整的 UI 描述可能 800 到 1500 字。同一批任务如果一次塞太多张图很容易超过上下文窗口或者让单次请求变得很贵。从工程经验看批量任务建议采用“逐步处理”策略每张图片单独跑 OCR/描述得到该图的文本对文本做质量检查确认没有大面积识别错误把多张图的文本合并提交给 DeepSeek 时先估算总 token如果文本太长优先拆成多个子任务比如按页拆分、按业务字段拆分。下面是一张粗略的成本估算表具体价格会随平台调整而变化但思路是通用的环节一次调用的大致消耗批量时的风险OCR 识别CPU/内存占用少量存储并发过高时线程阻塞视觉描述模型图像 token 输出文本 token描述过长导致成本膨胀DeepSeek 文本推理输入文本 token 输出 token合并多图时超上下文文件存储图片 文本中间结果中间结果没有留存出问题难排查有一个很多人忽略的点中间文本最好落盘保存。OCR/描述的中间结果保存成 JSON 或文本文件DeepSeek 的输出也留一份。这样即使 DeepSeek 返回异常你也能定位是视觉模块的问题还是模型推理的问题。5. 翻车现场常见报错的排查链路伪多模态链路比普通文本调用多了一个环节所以报错位置也多了一个。下面这些现象我在实际折腾中经常遇到。5.1 报错现象模型不认图片这类报错的提示通常是“这个模型不支持图片输入”或接口层面提示 image 字段无效。出现这个报错说明你把图片直接传给了 DeepSeek 的文本接口而 DeepSeek 没有原生视觉能力。正确的处理方式是把图片内容先转成文本再传文本。不要跟模型层较劲问题出在输入阶段。5.2 报错现象OCR 识别出来了但 DeepSeek 答非所问这很可能是“文本质量”问题。OCR 识别出了文字但把表格的列和行关系弄乱了或者把换行搞丢了。DeepSeek 拿到一段没有结构信息的文本自然很难还原表格。处理方法是先检查 OCR 输出而不是反复改 DeepSeek 的提示词。你可以在传给 DeepSeek 之前把 OCR 文本先打印出来看一遍确认字段顺序、分隔符、换行都还合理。5.3 报错现象批量任务中途超时或限流批量处理时既有 OCR 引擎的资源消耗又有 DeepSeek API 的并发限制还可能有文件读取的 IO 瓶颈。报错可能表现为部分任务超时、全部任务排队很久、结果缺失。这时先确认瓶颈在哪一层只有一张图都慢看是 OCR 库本身慢还是接口网络慢多张图后变慢看是并发不够还是接口被限流单张正常、批量偶尔失败多半是并发策略需要加退避重试。5.4 稳定排查顺序无论遇到什么问题我建议按下面的链路排查先看现象是报错、卡住、无输出还是输出结果错误。再看输入图片路径是否正确、格式是否支持、文字是否清晰、OCR/描述结果是否完整。再看环境依赖版本、API Key 权限、网络连通性、磁盘空间是否充足。再看参数并发数、超时时间、最大 token、图片压缩尺寸是否合理。最后看工具边界DeepSeek 是否支持当前任务、视觉模型是否真的理解图片、中间格式转换是否丢失信息。这个顺序几乎能覆盖大部分问题。不要一上来就怀疑 DeepSeek 的推理能力大多数翻车不是因为模型笨而是因为前面喂给它的材料就错了。6. 什么时候该用伪多模态什么时候该等原生方案前面讲了原理、路径、流程、参数和排查最后必须把适用边界说清楚否则你会被这个方案“坑”在不合适的地方。6.1 适合伪多模态的场景第一类是文字型图片。聊天记录、文档截图、表格截图、票据、简历、合同扫描件。这些图片里的核心资产是文字OCR 提取后交给 DeepSeek 整理效果很好。第二类是低复杂度视觉理解。比如“这个界面上有哪些功能”“这张海报上的活动规则是什么”“这个流程图描述了什么流程”。只要视觉模型能给出准确的结构化描述DeepSeek 就能接手。第三类是流程里已经需要文本模型的地方。你本来就在用 DeepSeek 做日志分析、文档生成、代码编写只是偶尔需要处理图片。不值得为了偶尔几次识图任务专门换一个原生多模态模型外挂视觉模块更划算。6.2 不适合伪多模态的场景第一类是强空间关系任务。比如“这张照片里的人在画面的哪一侧”“两个物体距离远不远”。视觉模型转成文本时空间信息会大量丢失DeepSeek 拿到文本后只能猜。第二类是细粒度视觉差异。比如判断两张设计稿的颜色、像素级对齐、图标形状差异。这类任务对视觉编码要求极高文本化描述远远不够。第三类是敏感信息和高错误容忍成本场景。如果图片里包含大量隐私数据或者识别错误会产生严重业务后果你应该优先考虑做完整的多模态方案并做好数据脱敏和人工复核而不是图省事套一层伪多模态。6.3 我的建议伪多模态不是一个完美方案但它是一个很实际的工程取舍。它解决的本质问题是在模型能力受限的情况下如何用流程编排让文本模型完成视觉任务。它的价值不在“更快”而在“让一个原本不可用的场景变得可用”。如果你只是尝鲜用编排工具把图拖进去看效果就够了。如果你想放进真实项目至少要补上图片预处理、中间文本留存、日志、异常重试和人工抽检。先跑通再优化最后工程化这个顺序比什么都重要。等到未来 DeepSeek 或其它文本模型真正开放原生视觉能力时你也不需要推翻现在这套流程。把最前面的“视觉模块”换成原生图像输入后面的文本处理逻辑还可以继续复用。所以今天折腾这套伪多模态并不是白费功夫它是在帮你提前搭好一条可替换的前处理链路。