为什么 AI 画的界面，比 AI 写的界面好看

把“设计一个待办事项应用的主界面”这个需求，分别交给一个图片模型和一个代码模型。图片模型交回来一张 PNG：深色卡片、圆角按钮、渐变背景，好不好看当场可见。代码模型交回来一段 HTML 和 CSS，直接读文本什么都看不出来，要交给浏览器解析，等字体和资源加载完成，在某一个视口里渲染，才变成同一个界面。

这里先限定讨论范围：代码模型，指以文本生成为主、生成过程中没有持续浏览器反馈的那一类。如今的多模态代码代理已经能看到渲染截图，这恰恰是缩小差距的方向。

两份产物要公平比较，一种常见办法是先把代码渲染成截图，再和图片模型的输出并排。而一旦并排，一个规律很快出现：AI 生成的界面图片，往往比 AI 生成的界面代码好看。差距不能简单归因于模型更聪明。起作用的是三处错位：生成空间、训练信号、评价标准。

生成空间：像素是终态，代码要过渲染管线

图片模型的主流架构是扩散模型，思路是让模型学会把噪声一步步还原成图像，生成时从随机噪声出发，走出完整画面。Latent Diffusion（论文）把去噪过程从原始像素搬进潜空间——图像经编码后的低维表示，省计算，生成对象依然是完整的图。对这类模型来说，输出就是评价对象：生成结束，一张图摆在面前，构图、色彩、光影、层级全部落在具体像素上，可看、可评、可挑刺。

代码模型走的是另一条路。以 Codex（论文）为代表的自回归模型每次只预测下一个 token——token 是模型处理文本和代码的最小单位，生成时模型眼里只有 token 序列。

从 token 到像素，中间隔着整条渲染管线：浏览器先把代码解析成 DOM 树和 CSSOM 树——页面结构和样式的内部表示；再按 CSS 视觉格式化模型（W3C 规范）计算元素的位置和尺寸；绘制、叠加字体和图片资源、结合视口参数，最终才产生屏幕上的像素。页面往往还不是静态的：脚本执行、交互状态、数据请求失败，都会改写最终画面。

视觉后果不仅延迟，而且非局部。一个未闭合的标签、一个写错的属性值，出错时不报警，渲染时爆发，波及的往往不是出错的那一行，而是整个布局流。改一个 CSS 属性，牵动的是一大片区域的重排。

图片模型输出的就是终态；代码模型输出的是远期支票，能不能兑现，要等浏览器把整条管线走完。

训练信号：代码仓库里没有“好看”

图片模型的训练数据就是图片。构图、色彩、光影、层级、留白这些视觉关系直接由像素承载，协调与否都如实落在数据里，模型不需要额外标注就能学习。当然，这指的是视觉信息对模型直接可见，训练图片本身并不天然都好看。

代码模型吃的是公开代码仓库。仓库里有源码，运气好有测试，但通常没有对应截图，更不会有“这段代码的设计意图”“这个界面的视觉偏好评分”——这类成对且带偏好反馈的数据相对稀缺。模型见过海量 div 和 span，却几乎没见过它们渲染出来长什么样。

这留下一个“审美联合分布”的缺口：界面好不好看，是字体、间距、颜色、布局共同决定的，每一项单独正确都无济于事——字体选对了间距乱，颜色和谐布局歪，整体依然不成立。

数据缺口之外，还有评价信号的问题。代码模型的训练奖励通常优先语法和功能：生成的代码能否编译、测试能否通过，才是被奖励的方向。审美不在奖励函数里，至多是这条链路的远端副作用。

要补数据缺口，需要专门构造“代码—截图”对齐数据。WebSight（论文）就是这样的数据集：研究者程序化生成 HTML 页面，用浏览器渲染成截图，得到 HTML 与截图的配对，用于训练从截图生成 HTML 的模型。

这种数据需要专门造，恰恰说明“界面截图对应的代码长什么样”这个映射，在自然存在的公开数据里是稀缺的。

评价标准：图片有打分器，代码没有

静态界面图片的责任很轻。它只对一个理想视口、一个理想状态负责：响应式布局、真实文案溢出、交互反馈、加载态、错误态、无障碍、后续维护，通通可以合法不管——一张图不会因为在小屏上崩坏而担责。

代码不行。代码必须能运行，测试必须能通过，要在各种视口和设备上成立。评价一个代码界面，比评价一张界面图像多出整整一个维度。

图片一侧，反馈回路已经比较成形。CLIP（论文）把文本和图像映射进同一个向量空间，提供的是文本—图像对齐的判断；ImageReward（论文）则更进一步，用人类偏好数据训练出图像奖励模型，直接评估生成图像与人类偏好的吻合程度。

不过，只有把这类偏好反馈接入训练流程的图片系统，才真正获得“好不好看”的直接信号。

常规代码训练阶段通常没有图片侧那样直接、成熟的人类视觉偏好信号。模型在训练中得到的反馈是能否编译、测试能否通过，最多加上代码风格启发式，而这一切离“好不好看”隔着整整一条渲染管线。盯着这些信号优化，模型学到的就是“能跑就行”。

让浏览器当裁判

三处错位指向同一个补救方向：把浏览器请进生成回路。

评价对象从 token 序列改为渲染后的像素和结构，评价环境必须是真实浏览器——渲染结果依赖字体、资源、视口和运行状态，换一个环境，同一段代码会呈现不同的画面。

具体做法是：生成代码，交给真实浏览器渲染，对截图做视觉评价，同时对 DOM 结构、布局稳定性做结构评价，定位问题，修改，再渲染。这样审美从远端副作用变成直接优化目标，响应式、可用性这些必答题也不会在评分里缺席。

截图只覆盖一个视口，所以结构评价要兜底：内容有没有溢出，元素有没有重叠，语义结构是否清晰。

这个方向已有对应工作，但都只补上反馈闭环的部分环节。Design2Code（论文）是一个评测基准：给定网页截图，让多模态模型生成 HTML/CSS，用自动指标并辅以人类评估，比较截图输入后生成代码的渲染还原，以渲染结果评价生成结果。

WebSight 则是数据侧的工作。两者一个管评测、一个管训练数据，各自接上了“渲染结果”这一环，但“生成—渲染—评价—反馈”的完整迭代回路还谈不上成熟。

这里还有一个陷阱：模型可能学会画网页，而不是写网页。比如用绝对定位把每个元素钉死在固定坐标，截图上完美还原，代价是布局不随内容流动，文案一长就互相重叠，换一个视口就崩溃。

所以浏览器当裁判不能只看视觉一项，视觉、功能、响应式、工程质量必须一起进评分。这一整组义务，恰好是图片模型从来不用背的。

差距缩小，义务不消失

把浏览器完整请进训练回路，让代码模型直接对着渲染反馈迭代，UI 代码和 UI 图片之间仍有一道不会消失的差距：图片模型只要打赢一张图，代码模型要打赢的是一个会运行、会响应用户、要在不同设备与运行状态下保持体面的系统。

状态、设备、维护都带来额外义务。这些义务是可运行产品的定义，而生成式图片的评估从来不需要为它们负责。

差距在缩小。开头提到的多模态代码代理能看到渲染截图，视觉反馈不再缺席，这正是“让浏览器当裁判”的方向。

但裁判只能评判已经运行起来的东西。AI 画的界面比 AI 写的界面好看，是结构性的结果：两种模型被各自的生成空间、训练信号和评价标准推向不同方向。让界面在真实产品里长期成立的那最后一段路，仍然要靠代码和测试走完。