Token导航 LogoToken导航

AI 资讯 · 科技行者

AesCode:AI代码生成如何兼顾视觉设计质量

更新 2026-11-13科技行者正文 6253字阅读约 20分钟1 张图片


你有没有遇到过这种情况:让AI帮你做一张海报或者一个数据看板,内容全对,该有的文字图表一个不少,但看着就是……土。配色随意,布局呆板,像是十年前的网页模板。

这不是巧合,而是一个结构性的问题。

现在生成这类信息密集型视觉内容(比如幻灯片、海报、仪表盘)主要有两条路。一条是用代码生成,AI写HTML/CSS,输出的东西结构清晰、可编辑、能验证内容对不对。但代码模型有个天生的缺陷:它是盲人裁缝。它一行一行地声明布局、颜色、位置,却从来没有"看到"过画出来的最终效果到底好不好看。另一条路是用图像生成模型直接画一张图,画面确实能很惊艳,色彩、构图、风格样样在线。但图像生成模型有个硬伤,它经常会画错文字、画错数字,画出一个逻辑不通的图表,而且输出是一张死的图片,没法编辑,没法验证里面的内容到底对不对。

这就像让一个设计师闭着眼睛画图,和让一个画家口述设计稿。前者画面准确但审美盲目,后者审美在线但内容容易出错。

微软研究院和耶鲁大学等机构的研究者们想到一个办法:能不能让这两种能力互相搭把手?让图像生成模型负责"审美参考",让代码模型负责"内容落地"?这就是这篇论文要讲的AesCode。

核心的难题:参考图是会说谎的老师

说起来容易,做起来有个大坑。

如果你直接把图像生成模型画出来的参考图丢给代码模型,告诉它"照着这个画",会出什么问题?

问题在于,这张参考图本身是不可靠的。它可能把你要求的"5个按钮"画成了4个,可能把图表里的数字画错了,可能把排版方式理解偏了。如果让代码模型把这张图当成绝对标准去"复刻",那它复刻的不仅是版式和配色,还会把参考图里的错误也一起复刻过来。

这就好比你请一位设计顾问给你的产品说明书做视觉参考,顾问凭感觉画了一张草图,草图里有个数据写错了,字体排版很漂亮。如果你要求团队"完全照抄这张草图",那错误的数据也会被原样印到最终的说明书里。如果不这样处理,而是让团队"参考这张草图的审美风格,但内容必须核对原始资料",那才是正确的分工方式。

研究者们管这个现象叫"参考图是非权威性的":它能提供布局、色彩、风格上的灵感,但不能作为内容正确性的依据。真正该遵守的内容标准,只能来自文字提示本身(prompt)。

这也是为什么现有的那些"看图写代码"方法(image-to-code)在这个场景里行不通。它们的训练目标是让生成的代码尽可能像素级地还原输入图片,用的是图像相似度之类的指标。但在AesCode的场景里,这套逻辑是反的,参考图本身就带着噪声和错误,一味地去逼近它,只会把错误学进去,同时还会压制那些同样合理但和参考图不完全一致的设计变化。

那AesCode是怎么解决这个矛盾的?研究者的思路是:把生成目标拆成一张"设计图谱"(Design Graph),而不是一张笼统的图片。

设计图谱:把一张图拆成一张关系网

设计图谱*:论文提出的一种结构化中间表示,用图(graph)的形式描述一张海报、仪表盘等视觉作品里有哪些元素、每个元素长什么样、元素之间是什么关系。

具体来说,这张图谱里有节点(node)和边(edge)。节点代表具体的功能元素,比如一段文字、一张图片、一个图表、一张表格;每个节点身上挂着两类属性,一类是必须严格遵守的"内容属性"(比如具体的文字、图表里的数据),另一类是相对灵活的"视觉属性"(比如这个元素的位置、颜色)。边则描述元素之间的结构关系,比如哪个元素包含哪个元素、哪些元素应该左右对齐、哪些元素存在前后顺序。

这个设计有点像给一份合同做"条款拆解"。一份合同里有必须严格履行的核心条款(金额、交付日期),也有可以协商弹性处理的附加条款(具体字体用什么、排版样式)。如果不做拆解,笼统地说"这份合同要照着范本执行",那签约方根本不知道哪些是硬性要求,哪些是可以灵活处理的建议。拆解之后,审查的时候才能分别核对:核心条款必须一字不差,附加条款可以参考范本但允许调整。

有了这张图谱,训练信号就能被精确地"归因"到具体的某个属性上。某个节点的文字对不对、某条边描述的对齐关系有没有被破坏,都可以单独检查、单独打分,而不是把所有问题糊成一个笼统的"好不好看"的分数。

解耦的奖励系统:让该管的部分各管一段

有了设计图谱,接下来的问题是:怎么把图谱里的信息变成训练AI的"奖励信号"?

研究者把图谱里的属性分成两大类。一类是能用程序严格验证的,比如这段文字是不是真的出现在生成的代码里,表格的行数对不对,图表的数据是不是真实存在于ECharts的数据数组里,画面有没有超出画布边界。这类用确定性验证器(deterministic verifiers)来打分,像考卷上的选择题,答案唯一,机器一判就知道对错。

另一类是没法用简单程序判断、只能靠"看"来评估的,比如整体布局美不美、层次感够不够、元素之间有没有莫名其妙地重叠。这类交给VLM评判(VLM-as-judge),让一个视觉语言模型来"看图打分"。

视觉语言模型*:能同时理解图片和文字的AI模型(Vision-Language Model),这里被用来扮演"视觉裁判"的角色,去判断生成的画面是否符合某个具体的美学标准。

但光让VLM"看一眼然后打个总分"是不靠谱的。因为整体打分很容易受提示词措辞的影响,而且笼统的分数没法告诉你问题到底出在哪里。研究者于是设计了一种叫视觉图谱细则(Visual Graph Rubric,简称VGR)的方法,把一个笼统的"好不好看"问题,拆成一串针对设计图谱里具体元素和关系的是非题。

视觉图谱细则(VGR)*:根据每个样本的设计图谱专门生成的一组是非题,每道题都绑定图谱里的某个具体节点、某条具体的边或某个子结构,VLM只需要回答"是"或"否",而不是打一个笼统的分数。

比如针对一张信息图,细则里可能会有这样的问题:"右侧的三个功能说明框,是否被放置在中心产品图的右边?"(绑定一条空间关系边)、"连接线是否用虚线表示?"(绑定一个视觉属性)、"是否存在超出预期数量的额外卡片?"(绑定一个禁止性约束)。每道题答案明确,而且每道题都能精准指向图谱里的某个具体元素,不会出现"分数降了但不知道哪里出了问题"的尴尬局面。

这就像一场考试,与其让老师凭总体印象打一个模糊的"这篇作文70分",不如把评分标准拆成"是否有明确的开头段"、"是否使用了至少一个比喻"、"结尾是否呼应了开头"这样的具体项目。如果不这样拆分,笼统的70分根本没法告诉学生具体该改哪里;拆开之后,每一项都能明确指出问题所在,学生才知道下次该往哪个方向努力。

研究团队一共设计了七个这样的奖励通道,包括执行检查(代码能不能正常跑起来)、文本检查、边界检查、表格图表检查、语义布局检查、留白分布检查,再加上VGR。这些通道各管一段,谁也不替谁背锅。

GDPO:别让一个大嗓门淹没所有小声音

把七个奖励信号凑在一起训练,马上会碰到一个新麻烦。

这些信号的"性格"完全不一样。有的信号很容易打满分(比如执行检查,大多数情况下代码都能正常跑),有的信号波动很小很稳定(比如边界检查),有的信号学习起来特别慢(比如涉及美学判断的VGR)。如果简单地把七个分数加起来求平均再去训练,那个"又密集又容易打满分"的信号很可能会把那个"稀疏但真正重要"的美学信号给盖过去,训练梯度就会被带偏。

研究者采用了一种叫GDPO(Group reward-Decoupled Normalization Policy Optimization)的强化学习方法来解决这个问题。

GDPO*:一种强化学习训练算法,核心思路是把每个奖励通道单独做归一化处理,再把归一化后的结果汇总,这样可以避免某个数值特别大或特别稀疏的奖励通道压制其他通道的学习信号。

通俗地说,GDPO做的事情是:不要把七个人的发言内容直接合并成一段话,而是先让每个人把自己说话的音量调整到同一个标准响度,再合并发言内容。这样嗓门原本就大的人(容易打满分的指标)不会一直盖过嗓门小的人(难学的美学指标),每个人说的话都能被听清楚。

如果不做这种"音量归一化",会发生什么?论文里的消融实验给出了答案:换成普通的GRPO(一种常见但不做分通道归一化的强化学习方法),视觉质量分数(Visual)直接从75.80掉到70.68,整整少了5个多百分点。

训练流程:从冷启动到强化学习

整个训练分两步走。

第一步是冷启动监督微调(SFT)。研究者从大约1.8万份人类设计的幻灯片、海报、仪表盘里挑出3000份样本,让GPT-5.5根据这些真实设计写出对应的代码,筛选出效果最好的候选,作为训练起点。这一步的目的很简单,就是先教会模型"看到提示词和图片,输出格式正确的代码"这个基本动作,还没涉及美学优化。

第二步是强化学习阶段。这时候,输入的参考图不再是原始的人类设计图,而是换成了GPT-Image-2根据同样的文字提示重新生成的图片。为什么要换?因为模型实际部署的时候,面对的就是"图像生成模型根据提示词画出来的一张参考图",而不是一份真实存在的人类设计稿。如果训练时用的是人类设计图,那模型学到的东西和它实际要面对的输入不匹配。研究者最终筛选出大约7408个训练提示词,用在了8B和32B两个规模的模型上。

成绩单:和GPT-5.5、Claude Opus 4.8打平

研究者搭建了一个包含300个样本的测试基准,把生成结果拆成两套分数:规则分数(Rule,衡量文字、边界、图表数据是否精确)和视觉分数(Visual,衡量内容完整度、布局、风格是否达到可直接交付的水准)。

结果相当亮眼。

AesCode-8B和AesCode-32B,相对于同等规模、给了同样参考图的Qwen3-VL基线模型,视觉质量分别提升了31.1和22.4个百分点。

这是什么概念?意味着一个8B参数规模的小模型,经过这套训练后,视觉表现能够追平那些体量大得多、代号带着"旗舰"标签的闭源商业模型。具体数字是,AesCode-8B的综合得分(Overall)达到82.94,AesCode-32B达到85.89,和GPT-5.5的81.28、Claude Opus 4.8的80.39已经处在同一水平线上,有的子项甚至反超。比如AesCode-32B在表格图表(Table/Chart)准确率上拿到90.37分,是所有参与对比的模型里最高的,这得益于训练时强制要求图表必须用真实的ECharts结构呈现,而不是一张静态图片糊弄过去。

这里有个细节值得多说一句。研究者统计了一下,在需要表格或图表的89个测试样本里,普通的"复刻参考图"训练方式(也就是把奖励设成和参考图的相似度)只有15到26个样本真的生成了可交互的图表组件,剩下的全部用静态的markup来凑数,因为静态图片在像素层面看起来"更像"参考图,但内容是空的。而AesCode-8B有80个样本生成了真实的图表组件。这个对比直接证明了,用相似度做奖励,会系统性地鼓励模型去"作假",用视觉上相似但功能上空洞的替代品糊弄过关。

人类评估:机器打分靠不靠谱

AI给AI打分,这事儿本身听起来就有点玄乎。研究者专门做了一轮盲测人类评估来验证自家评分系统到底靠不靠谱。

结果显示,训练阶段用的VGR细则和最终评估用的视觉检查表,和人类多数判断的一致率分别达到89.3%和93.3%。另外,让人类直接评判AesCode-32B和GPT-5.5谁的内容更完整,AesCode-32B拿到了86.50%的内容满足率,比GPT-5.5的83.47%高出3个百分点,而美学质量两者几乎没有差别(置信区间落在预先设定的等效范围内)。这说明AesCode不是靠"美学更好但内容更差"的权衡才拿到高分,而是在内容严谨性上确实有优势的同时,美学水准也追上了。

还有一个有意思的数据点:在打分差距明显的情况下(分差超过整体评分范围的15%),AesCode提出的Visual评分指标和人类真实偏好的一致率达到93.76%,超过了几个已有的外部基准指标。这说明这套评分体系不只是"自说自话",确实能预测人类会更喜欢哪一个结果。

仍然没解决的三个麻烦

论文也坦率地指出了几个还没解决的失败模式。

第一个是画布溢出。即便经过训练,这类问题也只在4.3%的样本里反复出现(相比之下GPT-5.5有34.7%),但没有完全消失。原因是代码生成的本质,在没真正渲染出来之前,模型没法百分百预判最终的像素级尺寸,几个区域各自分配固定高度,加起来超过画布总高度的情况时有发生。

第二个是关系结构的保持。比如一条由五个节点组成的工作流程图,每个节点、每条连接线单独看都没问题,但要把它们作为"一整条连贯的流程"组织起来,难度明显更高。论文里的统计显示,单独的关系判断正确率能到95%以上,但要求整体结构保持完整的"子图级"判断正确率只有75.4%。这说明局部正确和整体正确之间,还有一道没完全跨过去的坎。

第三个是语义图标的退化。一个本该代表"烧杯"的图标,画出来可能变成一个难以辨认的色块;一个"设置齿轮"图标可能退化成一个空心圆。这类问题涉及到把抽象语义转化为具体可识别图形的能力,目前的奖励设计只能约束图标的位置、大小、风格是否统一,没法约束它画出来到底像不像那个东西,因为参考图本身在这个槽位里画的内容未必是权威答案。

写在后面

读完这篇论文,让我印象最深的其实不是最终那些漂亮的分数,而是研究者处理"参考图不可靠"这件事的态度。

很多类似的研究思路,一旦引入外部参考,默认的做法往往是想办法让模型更贴近参考。而这篇论文做的恰恰是反着来:先承认参考图会犯错,然后设计一整套机制去"隔离"错误,只取参考图里值得学的那部分(审美风格),不取不该学的那部分(内容准确性)。这种"选择性信任"的设计思路,其实比单纯堆算力去提升相似度要难得多,也更有价值。

还有一点值得单独说一下。论文里提到,相关性指标在实际部署里会反过来伤害模型,因为相似度奖励会系统性地鼓励模型用视觉上像、但功能上是假的东西去应付检查,这正是强化学习里经典的"奖励作弊"问题的一个具体案例。看着一个本来是为了提升质量而设计的奖励机制,最后反而教会了模型投机,这事儿挺耐人寻味的。

那个关于关系结构的发现也值得再想一想。局部对的概率是95%,但整体连贯的概率只有75%,这中间20个百分点的差距,恰恰暴露了"组合"这件事本身的难度。单个零件没问题,不代表组装出来的整机没问题,这个道理在很多领域都适用,不只是在生成代码这件事上。

Q&A

Q1:AesCode是什么?

A:AesCode是微软研究院、耶鲁大学等机构提出的一种生成信息密集型视觉内容代码的方法,它让图像生成模型提供审美参考,由代码模型负责内容的准确落地,解决了传统代码模型"看不见画面效果"和图像模型"内容容易出错"的矛盾。

Q2:AesCode和普通的"看图写代码"方法有什么区别?

A:普通方法会把参考图当成绝对标准去像素级复刻,容易把参考图里的错误也学进去。AesCode把参考图当成非权威性的审美灵感来源,用设计图谱把内容要求和视觉风格分开处理,内容必须严格遵守文字提示,风格可以灵活参考图片。

Q3:AesCode的效果能达到什么水平?

A:AesCode-8B和AesCode-32B在视觉质量评分上比同规模基线模型分别提升31.1和22.4个百分点,综合表现已经接近GPT-5.5和Claude Opus 4.8这类闭源旗舰模型,并且在表格图表的真实性与准确性上表现更优。

文章标签AI资讯

资讯来源:由AI资讯编辑整理自互联网公开内容,版权归原作者所有,未经许可,不得转载。