多模态代码智能综述：从视觉输入到可执行、可验证的代码系统

导读

过去几年，大语言模型推动了自然语言到代码生成的发展：用户用文字描述需求，模型生成函数、脚本、项目补丁或工具调用代码。但真实编程需求并不总是以文字出现。很多时候，意图藏在截图、网页设计稿、图表、论文页面、矢量图、三维模型、视频和交互状态里。此时，模型不仅要写出语法正确的代码，还要理解布局、几何、数据语义、可编辑结构、用户交互和执行后的领域约束。

综述论文《Beyond NL2Code: A Structured Survey of Multimodal Code Intelligence》系统梳理了这一新兴方向：多模态代码智能。它研究模型如何在视觉输入或视觉输出约束下生成、编辑、细化、执行或推理代码。论文把代码的角色从“文本程序”扩展为渲染制品、可编辑符号结构、科学表示、中间推理轨迹，以及可执行策略或工具接口。 这篇综述覆盖 282 篇相关论文，时间重点是 2022 至 2026 年，并按照四大领域组织：图形用户界面、科学可视化、结构化图形，以及前沿任务与框架。更重要的是，它提出一个贯穿全篇的判断：视觉相似度只是最低层的证据。可靠的多模态代码系统必须通过渲染、执行、交互、回放和多信号验证证明自己真的正确。 论文：Beyond NL2Code: A Structured Survey of Multimodal Code Intelligence作者：Xuanle Zhao、Qiushi Sun、Jingyu Xiao、Xuexin Liu、Haoyue Yang 等机构：美团、香港大学、香港中文大学、中国科学院自动化所、南京大学、哈尔滨工业大学、阿德莱德大学、慕尼黑大学、伦敦玛丽女王大学等项目：https://github.com/xjywhu/Awesome-Multimodal-LLM-for-Code论文地址：https://arxiv.org/abs/2606.15932

1 Introduction / 引言

研究背景

代码是人类意图与可执行计算之间的正式接口。传统自然语言到代码生成关注文本规格说明到程序的映射，而多模态代码智能关心更广的情况：任务意图由视觉对象表达，代码执行后又生成或改变视觉对象。 例如，前端开发需要从网页截图或设计稿生成可交互页面；数据分析需要从自然语言或图表图像生成绘图代码；文档解析需要把 PDF 页面恢复成 Markdown、HTML 或 LaTeX；矢量图和 CAD 需要把视觉形状转换为可编辑程序；智能体还可能根据屏幕状态生成工具调用、修复代码或执行物理策略。 论文指出，视觉输入具有高带宽，能够一次性承载空间层级、结构约束和样式细节。若把这些信息强行压缩成文字，往往会丢失布局、几何、关系和状态变化。因此，多模态代码智能不是普通代码生成的“加图版本”，而是要求模型把视觉感知连接到可执行程序，并在执行后接受检验。

综述方法

作者采用分阶段综述流程：从 arXiv 和人工智能、计算语言学、软件工程等主要会议收集候选论文，筛选与视觉输入、视觉输出或视觉状态相关的代码生成、编辑、验证、执行和推理工作，再按领域、任务形式、代码角色和评估信号进行人工标注。论文使用截至 2026 年 1 月的文献快照，并维护动态更新项目仓库。

2 Task Formulation / 任务形式化

从文本代码到视觉代码

传统自然语言到代码可以写成 C = LLM(T)：模型根据文本描述生成程序。多模态代码合成则加入视觉上下文，形式上变成 C = MLLM(I, T)，其中 I 可以是截图、图表、文档页、设计状态、视频帧或渲染参考。 论文把多模态代码任务分为三类基础合成任务。第一是直接生成：从视觉输入和文字提示生成能渲染目标制品的代码。第二是指令驱动编辑：根据文本或视觉标注修改现有视觉内容或源代码。第三是参考驱动细化：给定有缺陷的代码草稿和视觉参考，通过多轮修复生成更正确的代码。

代码的五种角色

多模态代码智能中的代码并不总是最终产物。论文强调五种角色：作为渲染制品的源程序，作为可编辑符号结构，作为科学表示，作为中间推理轨迹，以及作为可执行策略或工具接口。 这一区分很重要。网页代码需要通过浏览器渲染和交互验证；SVG 代码需要保持可编辑对象结构；科学图表代码要保留数据语义；视觉问答中的工具代码可能只是中间推理；机器人控制脚本则直接改变环境状态。不同角色对应不同评价证据，不能用一个视觉相似度指标统一裁判。

3 Graphical User Interface / 图形用户界面

网页应用

网页到代码是最成熟的多模态代码场景，因为 HTML、CSS、JavaScript、浏览器和自动化测试形成了天然闭环。模型可以从截图、草图或录屏生成 React、HTML 或其他前端代码；代码可以被浏览器渲染，再通过截图相似度、DOM 结构、用户动作和功能测试进行检查。 早期基准多关注静态页面重建，如 WebSight、Web2Code、Design2Code、WebCode2M 等。近期基准开始转向动态交互，例如 Interaction2Code、MRWeb、Web-Bench、WebGen-Bench 和 IWR-Bench。这一转变很关键：一个页面可以在固定视口下看起来正确，却没有事件处理、状态更新、路由逻辑或可维护组件结构。 方法上，网页生成从单模型监督微调逐渐走向模块化和智能体化。部分系统把任务拆成视觉定位、布局规划、代码生成、审查和执行反馈；另一些系统引入视觉批评器、浏览器回放或计算机使用智能体来验证功能。论文提醒，视觉分数、任务完成率和代码结构检查应分开报告，否则容易把“看起来像”误当成“能用”。

移动应用

移动应用比网页更难标准化。原生应用需要平台构建系统、设备或模拟器执行和交互工具链，公开源代码也不如网页容易获得。因此，当前移动端研究更多使用设计工具状态、UI 层级、模拟器检查或模型评价作为代理信号。 APPUI、CANVAS、UICrit 等工作代表不同评价路径：有的从静态设计稿恢复界面，有的评估设计工具中的操作，有的用批评数据衡量移动界面质量。总体趋势是从单页视觉重建走向可执行、可编辑、可交互的应用生成。

4 Scientific Visualization / 科学可视化

统计图表

科学可视化的核心不是画得像，而是数据、编码和分析意图是否正确。图表把数据操作、坐标轴、图例、比例尺、颜色和布局压缩到视觉形式中。一个生成图表可以视觉上合理，却使用错误数值、错误聚合、错误编码或不恰当的比较。 图表任务可分为两类：自然语言到图表，以及图表到代码。前者要判断生成代码是否满足分析意图，后者要恢复参考图中的数据和可视编码。VisEval、PlotCraft、ChartX、ChartMimic、Plot2Code、Chart2Code53 等工作分别从执行有效性、真实图像、层级复杂度和多轮细化角度推动评估。

结构化文档

结构化文档任务包括 PDF 到 Markdown、表格到 HTML/LaTeX、公式到 LaTeX。它不同于普通 OCR，因为目标不仅是文字识别，还要保留阅读顺序、版面结构、表格网格、跨单元格关系、公式语法和可编译性。 OmniDocBench、olmOCR-Bench、READoc、PubTabNet、FinTabNet、Table2LaTeX-RL、UniMER-Test 等基准分别检验全文结构、表格标记和公式生成。论文强调，文本相似度无法保证可执行正确性；文档类代码目标需要通过重新渲染、编译或结构比较来验证。

学术展示与科学演示

学术展示把论文或研究内容变成幻灯片、海报或演示视频。它要求模型选择证据、组织叙事、控制版式，而不只是复刻文档。科学演示则更进一步：生成的代码要解释分子、数学定理、教育概念或交互实验，必须符合领域机制和教学意图。

5 Structured Graphics / 结构化图形

矢量图

SVG、图标和插画生成的难点在于视觉对象必须同时可渲染和可编辑。一个像素图相似的 SVG 可能只有一串不可理解的 path，缺少对象层级、复用组件和可修改结构。未来系统需要支持参数化、分组、约束和动画，而不是只追求静态外观。

图表与工程图

图表类任务包括流程图、UML、工作流和硬件结构图。它们不仅有视觉布局，还有节点、边、关系、方向和语义约束。错误可能出现在关系类型、边连接、图语法或布局歧义中。CAD 则要求模型恢复可执行、可编辑的几何程序，满足约束、装配和可制造性。 论文指出，结构化图形评估不能只看图像相似度。SVG 要检查语义对象和可编辑性；图表要检查图结构；CAD 要检查实体有效性、参数约束和后续修改能力。

6 Frontier Tasks and Frameworks / 前沿任务与框架

程序化视觉操作

程序化视觉操作把代码作为中间推理工具。模型可以生成裁剪、检测、分割、OCR、几何计算或图像变换代码，然后根据执行结果回答问题或继续推理。这类方法的优势是把视觉推理过程显式化，缺点是工具调用是否真正因果地支持答案仍需验证。

视频与具身控制

视频代码生成把运动、场景或教学过程变成可执行脚本，挑战在于时间一致性、事件顺序和动作动态。具身控制则把代码作为高层策略，让模型根据视觉观察生成环境动作。这里的正确性不是一张图是否好看，而是状态轨迹是否按预期演化。

视觉接地编程与统一模型

视觉接地编程要求模型用截图、错误日志、界面状态或仓库上下文修复代码。统一多模态代码生成则试图把网页、文档、图表、SVG、工具调用和软件开发任务纳入同一接口。论文提醒，任务覆盖更广不等于真正学会可迁移能力。统一模型必须证明布局推理、符号关系、交互理解等技能能够跨任务迁移。

7 Future Directions / 未来方向

多信号验证

论文最重要的未来方向是多信号验证。视觉相似度、代码相似度、偏好评分、智能体回放和工具轨迹都只能观察部分正确性。可靠评价应形成诊断画像：视觉是否相似、数据是否正确、结构是否有效、代码是否可执行、对象是否可编辑、交互是否通过、失败能否归因。

多状态验证

许多任务应该被评估为执行 episode，而不是孤立渲染。网页要测试点击、路由、响应式布局和状态更新；视频要测试同步和事件顺序；具身控制要测试接触、遮挡、控制限制和恢复。未来基准应定义初始状态、生成代码或动作、中间观察、预期状态转移、验证器输出和恢复案例。

跨任务迁移

统一模型需要证明能力迁移，而不只是支持更多输入格式。一个更好的协议应比较源域增强、同规模控制和目标域表现，并报告正迁移与负迁移。例如，图表训练是否改善图结构理解，文档结构学习是否帮助视觉接地编程，交互监督是否提升制品修复。

可验证智能体轨迹

多模态代码智能体需要过程级证据。每一步应记录使用了哪块视觉证据、改了哪段代码、预期改善哪个验证器、回放结果如何，以及证据不足时如何回退。这样的日志能支持回放、视觉消融、反事实输入、权限控制和人工审查。

8 Limitations / 局限

论文的范围受公开论文、基准和仓库限制。闭源系统、私有评测集和快速更新的 arXiv 工作可能缺失。由于许多论文自建数据集和指标，综述也可能更偏向基准提出类工作，而低估没有公开制品的真实部署系统。 跨方法比较仍然困难，因为不同基准观察的是不同正确性切片。作者因此没有给出统一排行榜，而是强调领域内比较、共性失败模式、数据泄漏、基准饱和和评审器敏感性等可靠性风险。跨任务迁移部分更多是研究议程，当前评价还很少隔离因果迁移。

9 Broader Impact / 更广泛影响

多模态代码智能可以降低视觉编程门槛，让用户通过截图、草图、图表、视频或自然语言表达意图，并获得可执行代码。它也能帮助专家把视觉反馈转为可检查、可编辑和可复用的程序制品。 风险在于视觉可信感可能掩盖严重错误：错误图表数据、丢失文档结构、无效科学机制、损坏交互、不安全代码或危险物理动作。智能体系统还可能操作浏览器、文件、接口、设计工具、专有仓库或机器人，因此必须配合来源追踪、权限范围、执行日志、领域验证器、高风险人工复核和回滚机制。

10 Conclusion / 结论

这篇综述把多模态代码智能组织为一个从视觉证据到可执行程序的研究领域。它覆盖图形用户界面、科学可视化、结构化图形和前沿智能体框架，并指出代码在这些任务中不只是输出文本，而是渲染、编辑、推理、执行和交互的中介。 核心结论非常明确：未来进展不能只看生成代码是否视觉上相似，而要看代码在渲染、执行、交互和回放后暴露出什么证据。真正可靠的系统应当是可执行、可验证、可编辑，并且能够证明其行为受视觉证据约束的系统。 论文地址：https://arxiv.org/abs/2606.15932