用户询问DeepSeek近期是否支持多模态功能

背景

在当前的 AI 应用生态中，用户对于大语言模型（LLM）的使用场景正从单一的文本交互向更复杂的混合工作流演进。LINUX DO 社区中的 AI 板块近期出现了一则关于 Deepseek 模型能力的讨论。该讨论源于一名开发者在使用 OpenCode 平台搭配 Deepseek 的 Go 套餐时产生的实际痛点。尽管该套餐在性价比和日常文本任务处理上表现优异，但缺乏多模态（Multimodal）支持成为了阻碍其全面融入自动化工作流的关键瓶颈。

核心内容

该讨论的核心围绕 Deepseek 是否即将或已经支持多模态功能展开。

发帖者详细描述了其使用体验：

1. 优势：使用 OpenCode 平台的 Go 套餐调用 Deepseek 模型进行日常小任务处理时，体验非常流畅（“蹬 flash 真是爽”），且资源充足（“根本用不完”），足以应对大多数常规需求。
2. 痛点：Deepseek 当前版本不支持多模态输入。当用户向模型发送图片时，模型无法直接解析图像内容，而是会反问用户图片中具体是什么。
3. 工作流受阻：为了解决这一问题，用户不得不临时切换至其他支持多模态的模型。这种中断不仅打断了操作的连贯性，还对整体工作流的效率造成了负面影响。
4. 核心诉求：基于上述体验，发帖者向社区询问 Deepseek 近期是否有支持多模态的消息或计划，暗示社区内存在对该功能更新的强烈期待。

关键要点

• 现有优势：Deepseek 在 OpenCode Go 套餐下的文本处理能力稳定、性价比高，适合处理日常轻量级任务。
• 功能缺失：当前 Deepseek 模型不支持图像理解（多模态输入），无法直接解析图片内容。
• 操作摩擦：由于缺乏多模态支持，用户需要在不同模型间手动切换，导致工作流中断，降低了自动化效率。
• 社区关注点：用户高度关注 Deepseek 多模态能力的更新进度，视其为提升工作流完整性的关键因素。

意义与影响

这一讨论反映了当前 AI 开发者社区对模型能力边界的敏感度和实际需求：

1. 多模态成为标配预期：随着 AI 应用的深入，单一文本交互已无法满足复杂场景需求。多模态能力（尤其是图像理解）正逐渐从“加分项”变为“必选项”。
2. 工作流连贯性至关重要：对于依赖 AI 进行自动化处理的用户而言，模型间的切换成本（Context Switching）是效率杀手。支持多模态的单一模型能够显著简化工作流，减少人工干预。
3. 市场竞争压力：Deepseek 作为高性价比的代表，其功能更新节奏直接影响用户留存。若在多模态领域滞后，可能会促使部分用户转向其他已支持多模态的竞品模型，即使后者的成本较高。
4. 产品迭代方向信号：社区对 Deepseek 多模态功能的迫切询问，向开发者释放了明确的市场信号：尽快推出多模态支持将是提升用户体验和市场竞争力的关键举措。