当AI学会"看图写代码"：一场关于视觉理解与程序生成的深度探索

这项由美团、香港大学、香港中文大学、中国科学院自动化研究所、南京大学、哈尔滨工业大学、澳大利亚阿德莱德大学机器学习研究所、慕尼黑路德维希马克西米利安大学、中国科学技术大学以及伦敦玛丽女王大学等多所机构联合完成的研究，以综述论文形式发表于2026年，论文编号为arXiv:2606.15932，感兴趣的读者可通过该编号查询完整原文。

**代码生成的"视觉缺口"**

平时我们跟AI说"帮我写一段排序代码"，AI可以轻松完成。但假如你把一张网页截图放到AI面前，说"帮我把这个页面变成代码"，或者把一张折线图放过去，说"帮我把这张图复现出来"——AI能做到吗？这就是这篇论文关注的核心问题。

过去几年，大语言模型（可以把它理解为非常强大的文字处理引擎）在"看文字写代码"这件事上已经做得相当不错了。程序员描述需求，AI生成代码，这套流程已经被整合到了无数开发工具中。然而现实世界里，人们表达意图的方式远不止用文字——更多时候，我们会拿一张设计稿、一张数据图、一份手绘草图来说"我想要这样的效果"。这种从视觉到代码的跨越，就像是把一幅画翻译成乐谱，既要保留视觉的"样子"，又要还原其背后的"逻辑"。

这篇综述论文把这个新兴领域命名为"多模态代码智能"，并系统梳理了从2022年到2026年初的相关研究，覆盖282篇论文，横跨四个主要方向。下面，我们就顺着这篇研究的脉络，一起探索这个既新鲜又复杂的领域。

---

一、从文字到图像：代码生成的新挑战

传统的代码生成，就像是根据一份菜谱来做菜——菜谱用文字写清楚了步骤，厨师照着做就行。但现实中，很多时候你手里只有一盘成品菜的照片，没有任何文字说明，你得自己"反推"出这道菜怎么做。这就是多模态代码生成的本质难点。

研究团队将这类任务归结为三种基本形式。第一种叫"多模态直接生成"：给模型一张图（比如网页截图、图表、设计稿），让它直接生成对应的代码。第二种叫"指令驱动代码编辑"：给模型一张现有的图和一条指令（比如"把这个按钮换成红色"），让它修改代码实现视觉上的变化。第三种叫"基于参考的代码精化"：给模型一份"草稿代码"和一张目标图，让它把草稿改到和目标一致。

在这三种基本形式之外，研究团队还归纳了两种更高级的代码使用方式。一种叫"程序化工具调用"——代码不是最终产物，而是一个中间推理步骤，用来调用外部工具（比如图像识别、数学计算），最后得出答案。另一种叫"可执行策略"——代码是一个动作脚本，驱动机器人或软件在环境中执行任务。

这个分类框架是整篇综述的骨架，所有后续内容都可以在这个框架下找到归宿。

---

二、图形界面代码生成：让截图变成能跑的程序

考虑这样一个场景：你是一名创业公司的设计师，画好了一张网页设计稿，但公司没有足够的前端工程师。如果AI能直接把你的设计稿变成可以运行的网页代码，那得省多少时间？这正是"图形界面代码生成"这个方向在解决的问题。

研究团队把这个方向分成了网页端和移动端两大块，发现二者面临的挑战截然不同。

网页端的情况相对乐观，因为浏览器是一个非常理想的"验证环境"——生成的代码可以直接在浏览器里运行，看看渲染出来的页面是否和目标图一致，还可以模拟用户点击、表单填写等交互行为来检验功能是否正确。早期研究主要关注"外观相似度"，用像素级比较来判断生成的页面像不像原图。WebSight和Web2Code等数据集在合成数据上建立了基础方法。Design2Code则走向真实网站数据，让模型学会处理真实世界中复杂的页面结构。

然而随着研究深入，一个重要的问题浮出水面：一个页面看起来像，和这个页面真的能用，是两码事。比如，一个表单看起来和原图一模一样，但当用户点击提交按钮时什么也不发生——这样的代码在视觉评分上可能很高，但对用户来说毫无用处。IWR-Bench的研究发现，在他们的测试集上，模型的视觉相似度得分可以达到64%，但交互功能正确率只有24%——这个巨大的鸿沟说明，我们长期以来只盯着"好不好看"，忽略了"能不能用"。

于是，Interaction2Code、WebGen-Bench等更新的基准测试开始引入"交互成功率"这样的指标，要求模型生成的页面不仅要好看，还要能响应用户操作。一些新方法（比如Coder-CUA）甚至引入了一个"电脑使用智能体"来自动模拟用户行为，检验页面功能是否完整。

移动端的情况则麻烦得多。手机应用是编译过的二进制程序，没有统一的运行环境，也没有可以爬取的源代码。因此，移动端的研究只能退而求其次，用设计稿截图、UI层级信息等"代理信号"来替代真实的运行测试。APPUI用设计稿图片配代码的方式建立数据集，CANVAS则关注在Figma这类设计工具里的操作。UICrit提供了专业设计师对界面的批注，帮助模型理解"什么样的界面是好的"。这些都是有价值的探索，但研究团队也坦率地指出，这些信号都只能验证部分正确性，离真正的"运行测试"还有相当大的距离。

---

三、科学可视化代码生成：让图表说出它的"数据真相"

图表是科学交流的核心工具。一张折线图、一份统计表格、一页公式，背后都藏着数据和逻辑。如果AI能从图表"反推"出生成这张图的代码，那意味着它不仅看懂了图表的外观，还理解了图表背后的数据语义。

这个方向被研究团队细分为四个子领域：统计图表、结构化文档、学术演示文稿和科学演示。

统计图表的生成存在一个有趣的不对称性。从文字描述生成图表（比如"画一张2020到2024年销售数据的折线图"），和从图表逆向恢复代码，是两个完全不同的任务。前者是一个"欠定问题"——同一个描述可以对应无数种合理的可视化方案；后者是一个"约束重建问题"——目标图只有一个，代码必须精确还原它的数据、视觉编码方式和绘图逻辑。

研究团队发现，现有的评估方式存在一个根本性的缺陷：视觉相似度高并不等于数据正确。一张图看起来和原图几乎一样，但可能用了错误的数值，或者把X轴和Y轴搞反了，或者把两组数据的含义混淆了。这就像是临摹一幅画，临摹者可以让颜色和线条都很像，但他并不理解这幅画画的是什么。ChartMimic、ChartEdit等基准测试开始要求模型不仅重现视觉效果，还要通过"数据提取"来验证数值准确性。MSRL和ChartMaster则引入了基于渲染反馈的强化学习——简单说就是让模型"试画"，然后看渲染结果是否正确来调整参数。

结构化文档的挑战更为综合。把一页PDF文档转换成Markdown、HTML或者LaTeX格式，听起来像是简单的格式转换，实际上需要同时处理段落文字、表格结构、数学公式和页面布局四种完全不同的"语法体系"。OmniDocBench和olmOCR-Bench是这个领域的重要基准，前者关注PDF页面的整体结构还原，后者提供了1400多份各类PDF文档的测试集。在方法上，早期的流水线方法（先检测版面，再分区域识别）正在被端到端的视觉语言模型取代，后者可以一次性处理整页内容，效果更稳健。

学术演示文稿（PPT和海报）的生成面临的是一个"压缩+设计"的双重挑战。把一篇20页的论文变成20张幻灯片，不仅要选择最重要的内容，还要让每一页看起来美观、逻辑清晰。PPTAgent、AutoPresent等方法采用了不同的技术路径：有的把幻灯片当作可编辑的对象树来操作，有的用API调用的方式让AI专注于内容规划而把排版交给专业工具，有的引入"审稿人"模块来检查布局是否合理。海报生成的挑战更大，因为要把大量信息塞进一张画布，还得保证不同区块之间视觉上和谐统一。

科学演示（比如化学结构动画、数学定理可视化）是整个科学可视化方向里最"高危"的子领域。为什么说高危？因为一个分子结构图可以画得很好看，但违反化学键规则；一个数学定理动画可以很流畅，但实际上演示的是错误的推理过程。视觉上的合理性完全无法替代领域知识的正确性。TheoremExplainAgent尝试用Manim（一个数学动画库）生成定理解释视频，EduVisAgent则通过多智能体协作生成互动教学网页。这些工作都意识到，验证生成结果的正确性需要领域专家参与，或者引入领域特定的验证工具（比如化学键验证器）。

---

四、结构化图形代码生成：让程序理解"形状背后的逻辑"

如果说图表是数据的语言，那么结构化图形就是设计和工程的语言。这个方向包含三个截然不同的子领域：可缩放矢量图（SVG）、流程图/架构图，以及计算机辅助设计（CAD）。

SVG是一种用代码描述图形的格式，每一条线、每一个圆、每一个颜色都是代码里的一个命令。生成SVG的难点在于，模型必须在"视觉好看"和"代码结构合理"之间取得平衡——一张用SVG写出来的图标，不仅要渲染正确，还要方便人类设计师后续编辑修改。StarVector通过大规模SVG数据集训练模型，实现了图像到SVG的直接转换。Chat2SVG结合了大语言模型的语义理解和扩散模型的几何优化，试图同时满足语义和视觉两方面需求。RLRF则引入了基于渲染的强化学习，让模型通过"画出来看效果"的反馈来优化SVG路径参数。

流程图和架构图的生成本质上是一个逻辑推理问题而不是视觉问题。一张流程图可能看起来很正确，但如果某个分支条件搞反了，或者某个节点之间的箭头方向错了，整个图表达的意思就完全不同了。Flow2Code建立了流程图到代码的多语言测试集，StarFlow关注从草图到结构化JSON工作流的转换。OmniDiagram提出了一个统一框架，用"生成式视觉追问"作为奖励信号——简单说就是让另一个模型来"审查"生成的图，看看它和原始逻辑是否一致。

CAD是这三个子领域里技术门槛最高的。CAD代码不仅要生成一个在视觉上看起来像目标模型的三维形状，还要保留设计的"参数化历史"——比如这个零件的某个孔是先打了一个圆，再挤压出来的，这个构建顺序必须在代码里正确反映，否则当工程师后来修改设计参数时，整个模型就会"崩掉"。DeepCAD开创了用序列化命令表示CAD历史的研究范式，后续的CAD-Llama、ReCAD等工作在此基础上引入了语言模型，让自然语言描述也可以驱动CAD生成。CAD-Judge提出了"以编译器为裁判"的思路——用CAD软件的编译器来判断生成的代码是否合法，而不是依赖昂贵的视觉语言模型评分。

---

五、前沿任务：当代码成为"看世界"的工具

前面三个方向里，代码是最终产物——生成一个网页、一张图表、一个零件。但研究团队还关注了另一类完全不同的场景：代码不是终点，而是过程中的一个工具，用来帮助AI更好地理解和处理视觉信息。

程序化视觉操作是其中最有趣的一个方向。基本思路是：当AI面对一道视觉推理题时，与其靠"直觉"直接作答，不如先写一段代码，用代码来裁剪图像、检测物体、测量距离、标注区域，把"解题过程"变成可以观察和验证的一系列操作步骤。VisProg把自然语言问题翻译成视觉处理程序，ViperGPT用Python脚本调用视觉API来回答问题，Visual Sketchpad让模型先画辅助草图再作答。更近的工作如Visual-ARFT和Pixel Reasoner则通过强化学习来奖励那些"真正有用"的视觉操作步骤，而不仅仅奖励最终答案是否正确。

视频代码生成分为两个方向：从代码生成视频，以及从视频中提取代码。前者的典型场景是用Python脚本生成教学动画，Code2Video尝试通过编程脚本生成教育视频，TheoremExplainAgent专注于用Manim生成数学定理可视化。后者的典型场景是从机器人操作视频中自动提取可执行的操作策略脚本，RoboPro用大规模视频数据训练策略生成模型，减少了昂贵的机器人轨迹数据采集需求。这两个方向都面临同一个核心挑战：代码描述的是离散的步骤和关键帧，而视频呈现的是连续流动的时间，两者之间的"断层"很难完全填平。

具身控制是把代码生成推向物理世界的方向。当一个机器人需要"去厨房拿一瓶水"时，它需要把这个高级目标分解成一系列具体的动作指令：先导航到厨房，判断水瓶的位置，规划抓取轨迹，控制机械臂……Code as Policies和ProgPrompt展示了用程序化结构来表达机器人任务的优势——代码的层次结构、API调用和条件逻辑让机器人行为更加透明和可解释。然而，代码天然是离散和符号化的，而机器人操控需要处理连续的力反馈、物体接触动态和传感器噪声，这道鸿沟在技术上至今没有完美的解决方案。

视觉基础编程研究的是当代码生成任务的关键线索藏在图像里时，模型能否真正利用这些视觉信息。HumanEval-V专门设计了253个"纯靠文字无法解答"的编程题，图像是解题的关键。SWE-bench MM收集了617个需要借助网页截图来定位和修复Bug的真实软件工程问题。GUIRepair让模型生成"复现脚本"来触发Bug，然后在修复后截图验证，形成一个视觉驱动的调试闭环。这个方向最根本的挑战在于：怎么证明模型真的用到了图像信息，而不是靠猜测或文字描述走了捷径？

统一多模态代码生成是一个更宏观的研究方向，探索能否用一个通用模型来处理前面所有类型的视觉代码任务。JanusCoder、VisCodex、VisCoder2等工作尝试通过数据混合训练来打通不同任务之间的边界。研究团队对此保持审慎态度：一个能接受更多任务格式的模型，并不等于一个真正理解了视觉代码底层规律的模型。真正的"统一"应该体现在跨任务迁移能力上——比如在图表任务上学到的排版理解，能不能帮助解决流程图任务——而不仅仅是把更多数据塞进一个模型。

---

六、评估的困境：为什么"看起来对"还不够

贯穿整篇综述的一个核心主题，是对现有评估方法的深度反思。研究团队总结了当前领域里五类常见的评估代理及其局限性。

视觉相似度指标（比如SSIM、CLIP分数）是最常用的评估手段，但它只能检验外观，无法判断数据是否正确、结构是否可编辑、交互是否可用。文本/代码相似度指标（比如BLEU、TEDS）关注的是代码字符层面的匹配，但一个语法完全不同的代码可以生成完全相同的输出，反之亦然。偏好评分依赖人类评审员或另一个AI模型的判断，这种方式容易受提示词影响，难以重现，也很难定位到具体错误。智能体回放（让AI自动模拟用户操作来检验功能）是一个更强的信号，但受限于智能体自身的能力上限，且很难独立控制评估过程。过程奖励（奖励工具调用是否合理、中间步骤是否正确）比只看最终答案更细致，但一个看起来合理的操作步骤不一定真的起到了关键作用。

基于这些观察，研究团队提出了四个值得重点探索的未来方向。

第一个方向是"多信号验证"——对同一个生成结果，同时用视觉相似度、数据准确性、代码可执行性、结构可编辑性等多个维度来评估，而不是靠单一指标打分。这就像医生给病人做体检，不能只量体重，还要查血压、血糖、肝功能等多项指标。

第二个方向是"多状态验证"——不只测试单一输出状态，而是把生成的代码放入一个执行环境，测试它在不同用户操作、不同数据输入下的行为是否都正确。这就像测试一辆汽车，不只看停在展厅里好不好看，还要在各种路况下实际开一开。

第三个方向是"跨任务迁移测试"——专门设计测试集来检验统一模型学到的能力是否真的在任务间迁移，而不只是在训练过的任务上表现好。

第四个方向是"可验证智能体轨迹"——对于那些通过多步骤推理和工具调用来生成代码的智能体系统，要求它们记录详细的操作日志，每一步操作都能被回放和审查，确保每个视觉操作确实作用于了关键信息，而不是"表演"给评估者看。

---

归根结底，这篇综述揭示了一个关键洞见：代码不只是文字，代码是人类表达意图、控制计算机和物理世界的工具。当这个工具需要处理视觉世界时，正确性的标准就不再只是"语法对不对"，而是扩展到了"渲染出来的样子对不对、数据是否精确、交互是否可用、逻辑是否合理、物理上是否可行"——一整个证据链。

这个领域还很年轻，从时间线图上可以看到，2024年第一季度只有17篇相关论文，到2025年第二季度已经飙升到了44篇。每一篇新论文都在试图解决这个证据链上的某一个缺口。对于普通用户来说，这意味着不远的将来，你或许真的可以把一张设计稿、一份手绘草图或者一张数据图丢给AI，然后得到一段不仅好看而且真的能用的代码——而AI给你的那段代码，它自己也"知道"为什么要这样写。

对于有兴趣深入了解这个领域的读者，完整论文可通过arXiv:2606.15932查阅，其中包含282篇相关论文的详细分类和分析，以及配套的GitHub资源库，持续更新最新研究成果。

---

Q&A

Q1：多模态代码智能和普通代码生成有什么区别？

A：普通代码生成是"你用文字说需求，AI写代码"。多模态代码智能则是"你给AI看一张图（比如网页截图、图表、设计稿），AI把这张图变成能运行的代码"。关键区别在于输入是图像而不是文字，AI需要先理解图像里的视觉信息，再把这些信息转化为代码逻辑。

Q2：视觉相似度评分高的代码为什么还是可能有问题？

A：视觉相似度只能判断"好不好看"，无法验证功能是否正常。一个网页页面可以和参考图看起来一模一样，但按钮点击没有反应、表单提交会报错、路由跳转会失败。一张图表可以外观完全相同，但背后的数值是错的。就像一辆玩具汽车和真实汽车外形一模一样，但你没法真的开它上路。

Q3：当前多模态代码生成领域最大的技术瓶颈是什么？

A：最大的瓶颈是"评估"。现有的评估方式大多只检验视觉外观，没有同时验证数据准确性、代码可执行性、交互功能和结构可编辑性。这导致模型优化方向偏差——训练出来的模型擅长"让结果看起来对"，但不一定"真正做对了"。这篇综述呼吁建立多信号验证体系，从多个维度同时检验生成结果的正确性。