AesCode:让AI写代码兼顾审美,微软研究院等提出设计图谱方案
你有没有遇到过这种情况:让AI帮你做一张海报或者一个数据看板,内容全对,该有的文字图表一个不少,但看着就是……土。配色随意,布局呆板,像是十年前的网页模板。这不是巧合,而是一个结构性的问题。现在生成这类信息密集型视觉内容(比如幻灯片、海报、仪表盘)主要有两条路。一条是用代码生成,AI写HTML/CSS,输出的东...
让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,前者拿到86.50%的内容满足率,后者为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这类闭源旗舰模型,在表格图表的真实性与准确性上表现更优。