不是“视觉让代码能力变笨”，而是通才模型在固定预算下更难优化。
目前最符合证据的结论是：多模态能力不会从逻辑或架构上必然损害 Coding；但在模型大小、训练算力、数据总量、显存与延迟都固定时，多模态模型确实更容易付出专业化成本。
如果所谓“天生缺陷”是指：无论怎么扩容、训练和路由，只要模型能够看图，其代码能力就必然更差——现有证据不支持这个命题。原生多模态模型可以保持文本能力，PaLM-E和后续受控预训练还观察到正迁移；GPT-5、Gemini等系统也同时展示强Coding和多模态能力。[P03][P06][S01]
但若比较“同样30B参数、同样训练FLOPs、同样上下文和同样部署预算”，代码专用文本模型通常更容易把容量集中到代码、数学、工具调用和长仓库推理。
真正决定 Coding 的优先变量
在多数纯文本开发任务中，影响结果的第一梯队通常是代码训练数据、推理后训练、工具调用稳定性、仓库检索、上下文管理、测试反馈和Agent脚手架；“是否具备视觉输入”往往只是第二梯队变量。厂商自己也承认，SWE-bench结果会受到提示词、工具和执行环境的显著影响，因此不能把一个分数直接解释成架构因果。[S01]
“多模态”不是一种模型，而是至少三种完全不同的工程路线。
只有先判断视觉模块是否独立、语言主干是否被改写、训练是否从零联合进行，才能推断纯文本Coding会不会受到影响。
四种“公平比较”其实会得到不同答案
- 固定总参数量多模态模型需要同时容纳视觉、语言与代码，专业模型更容易占优。
- 固定激活参数量MoE或模态路由可以只激活相关专家，通才成本可能明显下降。
- 固定训练算力视觉更“吃数据”，代码Token份额下降时，纯Coding可能退化。[P05]
- 固定推理成本有图片时视觉编码和视觉Token增加延迟；无图片时外接式模型可能接近文本路径。
多模态模型在纯 Coding 上可能吃亏的六个机制
受控对照、公开数据集、可执行测试或多模型重复结果。
技术报告、单一架构实验、厂商自报结果或仍待复现的预印本。
论坛反馈、个别部署故障和非标准内部评测，不能推导普遍因果。
对LLaVA的受控比较发现：Mistral主干在多模态指令微调后出现语言推理下降，Vicuna在多数任务反而提升；数学推理更容易下降，常识推理可能改善。也就是说，多模态不是统一的负效应，而是“任务 × 主干 × 训练配方”的交互。[P07]
无关图片会扭曲文本问答，无关文字也会干扰视觉理解。对Coding而言，旧版本截图、OCR误识别、与当前分支不一致的UI以及图中隐藏提示都可能成为额外噪声。[P10]
图片、PDF和网页截图可以携带视觉提示注入。若Coding Agent还能执行终端、Git或云端操作，视觉内容必须视为不可信外部输入，而不能直接转化为高权限动作。[S03]
这三个条件叠加时，模型既没有足够容量吸收新模态，又可能覆盖原语言能力，同时缺乏代码执行反馈将能力拉回精确符号任务。
多模态不仅可以避免损失，还可能改善某些文本推理。
其神经元级更新约束在11项语言基准上恢复了普通多模态微调造成的大部分语言损失，同时保持相近的多模态表现。它是2026年8月的新预印本，数字应等待更多复现，但说明“损失可被训练方法修复”。[P11]
结构性反例
为什么可能正迁移
- 空间与结构概念获得感知锚点位置、旋转、拓扑和对象关系不再只依赖文本共现。
- 同一概念出现更多监督视角代码、界面、流程图和文字说明可以形成互补表示。
- MoE允许模态专家化共享高层知识，同时把视觉和文本的低层计算分开，降低直接争抢。[P05]
商业系统构成“非必然”的现实反例
OpenAI在2025年公开的GPT-5系统同时报告74.9%的SWE-bench Verified、88%的Aider Polyglot和84.2%的MMMU；截至本报告日期，Google公开的Gemini 3.5 Flash-Lite同时接受文本、图像、视频、音频和PDF输入，并报告54.2%的SWE-Bench Pro。它们是厂商自报、且系统可能包含路由和专门后训练，不能证明同规模下多模态没有成本；但足以反驳“只要多模态就不可能成为强代码系统”。[S01][S02]
问“Coding强不强”之前，先问代码任务里有没有视觉信息。
| 任务类型 | 主要瓶颈 | 单模态代码模型 | 多模态模型 | 建议 |
|---|---|---|---|---|
| IDE补全、函数续写 | 低延迟、代码分布、局部上下文 | 通常更合适 | 视觉基本无贡献 | 选择代码专用、小而快的模型 |
| 算法、SQL、正则、配置 | 精确推理与执行正确性 | 同成本下常占优 | 取决于代码后训练 | 用编译和测试比较，不看“多模态”标签 |
| 大型仓库修复 | 检索、长上下文、工具和错误恢复 | 可非常强 | 无图时未必增益 | Agent脚手架比模态更重要 |
| 设计稿 / 截图转前端 | 布局、字体、颜色、视觉回归 | 需要人工转述 | 结构性优势 | 建立“生成—渲染—截图—比较”闭环 |
| 流程图 / 图表转代码 | 视觉解析 → 算法映射 → 执行 | 无法直接读取 | 必要但仍脆弱 | 结合OCR、结构化中间表示和单元测试 |
| 报错截图、桌面调试 | 界面状态与日志定位 | 依赖用户描述 | 可直接观察 | 能复制日志时仍优先原始文本 |
| 硬件 / 嵌入式开发 | 代码、接线图、仪器截图、实物状态 | 信息链断裂 | 明显优势 | 视觉结论必须与规格书和实测交叉验证 |
| 本地低显存部署 | VRAM、吞吐、运行时兼容 | 更简单经济 | 需视觉塔与额外算子 | 按需双模型或视觉模型作为“眼睛” |
图片最适合传递“只有视觉形式才存在的信息”，例如界面布局、图形关系或设备状态。可复制的代码、日志、堆栈、配置和结构化数据，应尽量直接提供原文本或文件，以减少OCR误差和视觉Token开销。
当前真正薄弱的是“视觉理解与可执行代码之间的最后一公里”。
数据还包含6,620张图片，来自10个编程竞赛网站。论文结论是当时的先进模型普遍难以解决这些题目，问题不只是OCR，而是需要把复杂视觉规格转成算法。[P12]
强调真实世界视觉编程问题，对视觉解析、数学和算法能力同时施压。适合说明“会看图 + 会写代码”不等于能完成二者的组合。[P12]
多数模型严重依赖附带文字描述，说明从像素恢复精确绘图代码仍缺少可靠的结构化中间表示。[P13]
修订版论文报告最佳模型Claude 3.5 Sonnet仅36.8% pass@1，并指出空间变换、拓扑关系和动态模式是主要难点。[P14]
在Hard子集上GPT-4o达到79.3% pass@1，而最佳开源模型为15%。流程图比复杂自然图像更结构化，也证明“视觉Coding”不是单一能力。[P15]
为什么不同基准不能横向直接排名
流程图、科学图表、几何图、UI截图和真实竞赛插图对模型提出的要求完全不同。模型可能擅长识别图中节点与箭头，却不擅长读取小字坐标轴；可能能生成能运行的前端，却无法精确复现像素；也可能理解图形，但在边界条件和测试驱动修复上失败。评价时至少应分别报告：视觉解析正确率、代码可执行率、隐藏测试通过率以及渲染结果相似度。
社区经验没有统一答案，但反复指向“实现和工作流比标签更重要”。
论坛不能证明多模态的因果效应；它的价值是暴露论文评测未覆盖的量化、缓存、模板、图像分辨率和长对话问题。
用户讨论中同时出现“数学或自然语言转SQL变差”和“实际无明显差别”的反馈。这更像模型版本、量化、Prompt和内部任务差异，而不是足以支持普遍结论的对照实验。[F01]
2026年7月的一组LocalLLaMA讨论展示了拆分式Coding工作流：文本模型负责代码推理，小型视觉模型读取截图、UI和错误状态，再把结构化描述交回主模型。它牺牲端到端统一性，换取显存与专业化效率。[F02]
Qwen3-VL曾出现第二次多模态请求后输出乱码或停止的KV Cache问题。此类故障不是模型权重本身的Coding能力，却会直接破坏真实使用体验。[F03]
llama.cpp用户报告某些版本在每轮对话重新处理过去的图片，图片越多，多轮Coding调试越慢。这说明视觉能力的成本与运行时缓存策略密切相关。[F04]
论坛中的“明显更差”和“完全一样”都应视为待验证假设。只有在相同模型家族、参数量、量化、模板、上下文、推理预算和任务集下做A/B测试，才能对自己的业务形成有效结论。
生产系统的最佳答案通常不是二选一，而是按需调用视觉。
优先代码专用文本模型。比较单位成本下的测试通过率、延迟和长仓库稳定性，不为用不到的视觉能力付费。
优先强多模态模型，或“代码模型 + 视觉检查器”。必须加入浏览器渲染、截图比较和可访问性检查，否则看图能力无法转化为可靠交付。
可采用分脑方案：主代码模型常驻，小型VLM仅在截图、PDF或设备照片出现时加载。这样通常比让完整多模态模型处理每个Token更经济。
视觉输入视为不可信数据；图中指令不能直接触发终端、凭据、Git推送或生产变更。关键动作应以文本策略、权限沙箱和人工确认约束。
建议的内部A/B评测协议
- 控制变量同家族、相近规模、同量化、同上下文、同温度、同推理预算和同工具。
- 任务分层纯文本代码、仓库修复、视觉辅助代码三组分别计分，禁止混成一个平均分。
- 至少三次运行Agent任务波动大，应报告平均值、失败类型和最差情况。
- 核心指标隐藏测试通过率、误改文件数、虚构API率、工具调用错误、总Token、墙钟时间和峰值显存。
- 视觉专属指标OCR/布局理解、结构提取、渲染相似度，以及移除图片后的性能差值。
- 决策阈值如果视觉任务少于总量约10%，通常更值得按需路由，而不是全量切换到多模态。
多模态模型没有Coding的先天智力缺陷。它面对的是更复杂的容量分配、模态干扰和运行时成本。小模型、固定算力和粗糙微调会放大这些问题；原生训练、参数隔离、模态路由、足够容量与代码专项后训练可以显著缓解。
如果任务不含视觉，选最好的代码系统，不必追求多模态标签；如果任务的真实状态存在于截图、图表、界面或物理世界中，拒绝多模态反而会形成先天的信息缺口。
论文与证据索引
强度标尺衡量“该来源对本报告核心问题的因果支持力”，不是论文整体质量。预印本、厂商自报和论坛经验均单独标注。
证据边界：本报告检索截止到2026年8月18日。论文中的模型版本和商业系统榜单会随时间变化；厂商基准用于提供反例与系统能力背景，不用于证明架构因果。论坛与GitHub问题只作为工程线索。
阅读建议：若只读五篇，优先 P06（原生多模态扩展）、P07（语言推理变化）、P10（模态干扰）、P12（真实视觉编程）和P14（复杂图形Coding）。