视觉 AI 的下一个前沿：代码驱动

过去几年，视觉 AI 的评价标准几乎完全取决于像素质量。最终图像或视频看起来越好，模型似乎就越强大。

这在当时是合理的。扩散模型将文本提示转化为精美的图像，然后是视频，接着是越来越逼真的世界。人们自然会将其与 Photoshop 或相机进行比较。

但对于许多与视觉相关的任务——比如平面设计、UI 设计或 3D 建模——用户最终追求的并不仅仅是最终的像素状态。相反，他们需要的是能够根据反馈和新想法不断迭代的“工件”。设计师需要的不仅仅是效果图，而是图层、组件和交接清单；动画师需要的不仅仅是视频，而是时间曲线、关键帧和可编辑的运动轨迹；3D 艺术家需要的不仅仅是一张渲染图，而是几何体、材质、灯光、相机和场景结构。

如今最有趣的视觉 AI 工具已经不再试图直接生成最终输出。相反，它们正在生成输出背后的“源代码”。这一转变解锁了像素原生模型无法企及的：可编辑性、迭代能力和反馈循环。

视觉生成的两大技术栈

关于视觉生成，主要有两种思路。

第一种是 像素原生生成。这些系统直接在潜空间中生成图像或视频。它们在纹理、氛围、光照和真实感方面表现出色。如果目标是生成一个电影级镜头、一张漂亮的情绪板或一个照片级真实的图像，扩散模型仍然是主流方法。

第二种是 代码原生生成。这些系统生成一种“表示”，然后由另一个引擎执行或渲染。模型并不直接产生最终像素，而是产生生成像素的程序。

这个程序可能是一个 SVG 文件、一个 HTML/CSS 布局、一个 React 组件、一个 Lottie JSON 文件、一个 Blender 脚本、一个 USD 场景图、一个着色器，或者一个游戏引擎场景。最终的视觉输出仍然是像素，但数据的“真相源”是一个结构化的表示。

这种区别之所以重要，是因为生产工作流非常关注“生成之后”会发生什么。 生成的图像作为一个输出是有用的，但生成的视觉程序作为一个工件更有价值——它可以被编辑、重用、改进和版本控制。它可以被集成到整个软件栈中，并受到约束条件的验证。它可以在不同条件下反复渲染，也可以在设计师、工程师和 Agent 之间交接。

我认为重大的转变已经发生：对于一部分视觉问题，我们将学会把视觉生成任务重新定义为编码任务，并通过解决一个定义明确、可验证的编码问题来获得高效的改进。

代码是处理视觉问题的良好基础

理解视觉代码生成价值的最简单方法是看看“初稿产生之后”会发生什么。

假设一个模型生成了一个 Logo。如果输出是光栅图像，而某条曲线出错了，用户就必须进行遮罩、修补、重新生成或手动重绘。但如果输出是 SVG，用户就可以直接编辑路径、基本图形、渐变、描边或文本元素。这正是设计师在 Quiver 上设计 Logo 的方式。

在 UI 设计领域，如果输出是一张截图，那它基本上只是灵感参考。但如果输出是 HTML/CSS 或 React，设计师就可以检查 DOM、替换真实组件、测试响应式状态、检查可访问性，并将其接入应用程序。

来自 Paper 的截图（所有视觉元素均由代码表示）

这也是为什么视觉代码生成对测试时计算（test-time compute）特别有吸引力。 在像素原生生成中，更多的推理通常意味着采样更多的输出：生成二十张图像，选出最好的一张，可能再试一次。这很有用，但每次尝试基本上都是重新掷骰子。模型可以对反馈做出响应，但反馈通常是全局性的且不精确。

从技术上讲，扩散模型也可以从测试时计算中获益。例如，论文 Inference-time Scaling of Diffusion Models through Classical Search 表明，在推理时进行搜索可以提高扩散模型在规划、强化学习和图像生成方面的输出质量。但这里的循环是不同的。在扩散模型中，系统通常是在潜轨迹或完成的样本中进行搜索。奖励函数可以告诉模型某个输出优于另一个，但它无法将反馈清晰地映射到特定的源代码级编辑上。

代码原生生成创造了一个更精确的循环：

代码 → 渲染 → 检查 → 修改。

模型生成工件，渲染它，观察哪里出了问题，然后修补源代码。如果间距不对，就修改 CSS；如果 Logo 曲线偏离，就编辑 SVG 路径；如果动画感觉太慢，就调整时间参数。关键在于，每一次迭代都在改进底层的工件，而不仅仅是渲染出的输出。这就是为什么视觉代码生成能够直接从生成更多 Token 和测试时计算中获益。模型是在一个闭环、可验证的环境中调试视觉程序，而不仅仅是采样更多图像。

基于代码的视觉生成技术栈

上面这些例子背后，是这样一个技术栈：

编码模型 + 符号表示 + 渲染器或引擎

编码模型是工件的编写者和编辑者。它编写 HTML、SVG、Lottie JSON、Blender 脚本、USD 场景或定制的 3D 资产程序。

符号表示是数据的真相源。这是使工件可编辑的关键。一个 UI 拥有 DOM 节点、布局规则和组件。一个 Lottie 动画拥有图层、矢量形状、时间曲线、关键帧和运动参数。一个 3D 资产拥有几何体、材质、关节、约束条件和层级结构。

渲染器或引擎将这些结构转化为像素。浏览器渲染 HTML/CSS，SVG 渲染器渲染矢量，Lottie 播放器渲染运动，Blender 或游戏引擎渲染 3D 场景，模拟器则验证一个带关节的资产是否能实际移动或交互。

OmniLottie 是一个很好的例子，能说明为什么符号表示很重要。Lottie 是一种轻量级的、基于 JSON 的动画格式，它将运动表示为可编辑的矢量形状、图层、关键帧和时间参数，而不是扁平视频。OmniLottie 提出将原始的 Lottie JSON 转换为更利于模型处理的命令序列，从而使模型能够更可靠地生成和编辑 Lottie 动画。这篇论文的主要目的不是构建一个完整的 Agent 循环。它的关键举措是让 Lottie 对模型更友好：它将原始的 Lottie JSON 转换为一个紧凑的命令和参数序列，便于模型生成。这之所以重要，是因为 Lottie 本身已经是一种可编辑的动画格式。一旦运动被表示为形状、图层、时间和动画参数，反馈就可以映射到源代码级的编辑上。如果物体移动太慢，就调整时间参数；如果路径错误，就编辑矢量；如果变形不对，就更新形状序列。

0:21

这个技术栈与编码 Agent 可以用来提高输出质量的测试时计算循环相对应：在每个“代码 → 渲染 → 检查 → 修改”的循环中，模型不仅仅是生成另一个样本；它利用渲染器的反馈来改进底层的工件。它可以更改 CSS 规则、调整 SVG 路径、修复动画时间或更新 3D 约束，然后再次渲染并持续改进。

这是循环得以收敛的关键。 在像素原生生成中，每次重试通常都会产生一个新的输出。而在代码原生生成中，每次重试都可以改进源代码工件本身。模型不再仅仅是采样更多的图像或视频；它是在一个闭环、可渲染的环境中调试一个视觉程序。

市场图谱：围绕运行时的切入点

视觉代码生成市场已经开始围绕工件被渲染或执行的运行时环境进行组织。在代码原生视觉生成中，模型会产生一个符号工件，该工件会在某处被执行：在浏览器、SVG 渲染器、Lottie 播放器、Blender、游戏引擎或模拟器中。

每个运行时都创造了不同的切入点，因为每个运行时都有自己的源代码表示、反馈循环和生产工作流。

目前最明显的应用场景在 2D 设计领域，尤其是 UI 和图形设计。但视觉代码生成的范围远不止设计工具。它出现在任何视觉工件具有底层表示的地方，这些表示可以被生成、渲染、检查和优化。

为什么 3D 是下一个重要的前沿

虽然产品设计和 2D 设计是当前最明显的用例，但 3D 工件可能从“将一致性问题重新定义为编码问题”中获益最大。

一个 2D 设计有时只要看起来正确就能派上用场。但一个 3D 资产不行。一张椅子的渲染图并不是一把椅子。它只是一张椅子的图片。要使资产在游戏、模拟或 3D 编辑工具中有用，工件需要拥有一致的底层 3D 表示，包括正确的几何体、材质、零件层次结构和场景上下文。

这就是为什么 3D 天然适合视觉代码生成。其价值不仅仅是从一个角度生成看起来像 3D 的东西，而是生成一个在多个视角、编辑和交互中保持一致性的 3D 结构。这需要一个迭代循环：提出物体、渲染它、检查几何体和零件是否合理、然后修改底层表示。但只有当 Agent 拥有正确的工具和上下文时，这个循环才能有效工作——仅仅不断运行 Blender 直到东西看起来更好是远远不够的。Agent 需要能够改变相机视角、查询场景状态、隔离物体、与目标进行对比、记住之前的尝试，并将视觉上的差异转化为源代码级的编辑。这正是测试时计算能够收敛的路径。

对于许多资产来说，视觉一致性只是基础。物体还需要正确的零件语义和功能约束：门应该能打开，铰链应该能旋转，抽屉应该能滑动，轮子应该能转动。换句话说，输出必须不仅仅是形状合理。它必须像它所代表的事物那样“表现”。

这就是为什么像 VIGA 和 Articraft3D 这样的项目在这个领域显得尤为突出，我们预计今年会有更多这方面的商业和开源工作出现。VIGA 使用 Blender 作为渲染和反馈环境，将视觉重建变成了一个“代码-渲染-检查”的循环；VIGA 并不仅仅是在循环中暴露出原始的 Blender。它赋予 Agent 用于观察和修改的语义工具，以及对先前尝试的记忆能力，这样它就能从更好的视角进行检查，诊断问题所在，并进行有针对性的编辑。Articraft3D 则更直接地针对资产结构：它将关节式 3D 生成定义为编写程序，这些程序定义了零件、几何体、关节和测试。