视觉AI的下一个前沿:代码生成

stuffyokodraws 发布于 2026-05-13 阅读 74

本文探讨了视觉AI从像素生成向代码生成的最新趋势,指出代码原生生成(如SVG、HTML/CSS、3D场景脚本)比像素原生更具可编辑性和迭代优势。通过分析2D设计、UI和3D建模场景,文章解释了代码作为中间表示如何实现精确的“生成-渲染-检查-修改”闭环,从而提升生产效率。作者预测,未来视觉AI产品将围绕运行时环境(浏览器、渲染器、游戏引擎)构建,并强调测试时计算与代码迭代的结合是关键。

Image

在过去几年里,视觉 AI 的评判标准基本都取决于其像素表现。最终的图像或视频看起来越好,模型似乎就越好。

这种评判方式有其道理。扩散模型将文本提示转化为精美的图像,然后是视频,接着是越来越逼真的世界。人们直观的对比对象是 Photoshop 或相机。

但对于许多视觉相关的任务,比如平面设计、UI 设计或 3D 建模,用户所追求的最终表现形式并不局限于最终状态的像素。相反,他们寻找的是那些可以根据反馈和新想法不断迭代的产物。设计师需要的不仅仅是一个样机;他们需要图层、组件和交接规范。动画师需要的不仅仅是一段视频;他们需要时间曲线、关键帧和可编辑的动态效果。3D 艺术家需要的不仅仅是一张渲染图;他们需要几何体、材质、光照、相机和场景结构。

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

视觉生成的两大技术栈

思考视觉生成主要有两种方式。

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

第二种是代码原生生成。这类系统生成一种表现形式,然后由其他引擎执行或渲染。模型不直接产生最终像素;它产生生成像素的程序。

这个程序可以是 SVG 文件、HTML/CSS 布局、React 组件、Lottie JSON 文件、Blender 脚本、USD 场景图、着色器或游戏引擎场景。最终输出的视觉呈现仍然是像素,但数据来源是一个结构化的表现形式。

这种区别之所以重要,是因为生产工作流程非常关注生成之后发生的事。生成的图像作为输出是有用的,但生成的视觉程序作为产物更有价值——它可以被编辑、重用、改进和版本控制。它可以被集成到软件栈的其他部分,并根据约束条件进行验证。它可以在不同条件下重复渲染,或者在设计人员、工程师和 Agent 之间交接。

我认为这个重大转变已经正在进行中:对于一部分视觉问题,我们将学会将视觉生成任务重新定义为编码任务,并通过解决一个定义明确且可验证的编码问题来获得高效的改进。

代码是视觉问题的良好基板

理解视觉代码生成价值的最简单方式是看看初稿之后发生了什么。

假设一个模型生成了一个 Logo。如果输出是光栅图像,并且有一条曲线错了,用户必须对其进行遮罩、修复、重新生成或手动重绘。而如果输出是 SVG,用户则可以编辑路径、基本形状、渐变、描边或文本元素。这正是设计师在 Quiver设计 Logo 的方式。

Sean Smith

@seansmithbuilds

· 5月13日 我一直想说说使用 @QuiverAI 的体验。几周前,我需要为 Brukas 应用的 Alpha 版本快速制作一个图标/Logo。使用 Quiver 的 Arrow 1.0 模型,配合非常简单的提示,我得到了字母 B。有了 B,我又得到了完整的单词。我在 Figma 中做了一些细化,当然我本可以做得更好……

Image

Image

Image

Image

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

Image

来自 Paper 的截图(所有视觉元素均由代码表示)这也是为什么视觉代码生成在测试时计算方面尤其值得关注。在像素原生生成中,更多的推理通常意味着采样更多输出:生成二十张图像,挑选最好的一张,也许再试一次。这很有用,但每次尝试基本上都是一次新的碰运气。模型可以对反馈做出响应,但反馈通常是全局性的且不精确。

从技术上讲,扩散模型也可以从测试时计算中受益。例如,《扩散模型通过经典搜索实现推理时缩放》 表明,推理时的搜索可以在规划、强化学习和图像生成方面改进扩散模型的输出。但这里的循环是不同的。在扩散模型中,系统通常是在潜在轨迹或完成的样本中进行搜索。一个奖励函数可以告诉模型一个输出比另一个更好,但它无法将反馈清晰地映射到具体的源代码级编辑上。

代码原生生成创建了一个更精确的循环:

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

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

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

在上述例子之下,是这个技术栈:

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

Image

编码模型是产物的作者和编辑者。它编写 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 本身就是一个可编辑的动画格式。一旦运动被表示为形状、图层、时间和动画参数,反馈就可以映射到源代码级的编辑。如果对象移动得太慢,就调整时间参数。如果路径错误,就编辑矢量。如果变形不对,就更新形状序列。

这个技术栈对应于编码 Agent 可以运行以改进输出质量的测试时计算循环:在每一次代码 → 渲染 → 检查 → 修订的循环中,模型不仅仅是在生成另一个样本;它正在利用渲染器作为反馈来改进底层的产物。它可以更改 CSS 规则、调整 SVG 路径、修复动画时间或更新 3D 约束,然后再次渲染并持续改进。

这正是让循环有机会收敛的原因。在像素原生生成中,每次重试通常会产生一个新的输出。在代码原生生成中,每次重试可以改进源代码产物本身。模型不仅仅是采样更多的图像或视频;它是在一个闭环、可渲染的环境中调试一个视觉程序。

市场地图:围绕运行时切入

视觉代码生成市场正开始围绕着产物被渲染或执行的运行时进行组织。在代码原生的视觉生成中,模型生成的是一个符号产物,它将在某个地方被执行:在浏览器中、SVG 渲染器中、Lottie 播放器中、Blender 中、游戏引擎中或模拟器中。

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

Image

目前最明显的应用是在 2D 设计领域,尤其是 UI 和平面设计。但视觉代码生成的范围比设计工具更广。它出现在任何视觉产物具有底层表示、并且可以被生成、渲染、检查和优化的地方。

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

虽然产品设计和 2D 设计是今天最明显的用例,但 3D 产物可能最能从将其一致性问题重新定义为编码问题中受益。

一个 2D 设计如果看起来正确,有时就是有用的。但一个 3D 资产不行。一把椅子的渲染图并不是椅子本身。它是一把椅子的图片。要使资产在游戏、模拟或 3D 编辑工具中有用,产物需要具有一致的底Layer3D 表示,包括正确的几何体、材质、部件层级和场景上下文。

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

对于许多资产来说,视觉一致性只是基准。对象还需要正确的部件语义和功能约束:门应该能打开,铰链应该能旋转,抽屉应该能滑动,轮子应该能转动。换句话说,输出必须不仅仅是一个看起来合理的形状。它必须表现得像它所代表的东西。

这就是像 VIGA 和 Articraft3D 这样的项目在此领域脱颖而出的原因,我们预计今年将看到更多商业和开源的相关工作。VIGA 使用 Blender 作为渲染和反馈环境,将视觉重建变成一个代码-渲染-检查循环;VIGA 并不仅仅是在循环中暴露原始的 Blender。它给 Agent 提供了用于观察和修改的语义工具,以及对先前尝试的记忆,以便它能从更好的视角进行检查、诊断问题所在并进行有针对性的编辑。Articraft3D 更直接地针对资产结构:它将关节式 3D 生成定义为编写程序来定义部件、几何体、关节和测试。

Image

VIGA 生成的示例 3D 场景重建

未来影响和未解决的问题

如果视觉代码生成行得通,胜出的产品将不仅仅是生成更漂亮的输出。它们将拥有整个循环:生成产物,渲染它,检查哪里出了问题,然后修订源代码。

这有几个影响。首先,渲染器变成了反馈环境。浏览器、SVG 渲染器、Lottie 播放器、Blender、游戏引擎和模拟器将成为 Agent 测试和改进其工作的地方,就像今天编码 Agent 利用沙箱和虚拟机一样。

其次,迭代上下文的质量变得比以往任何时候都更重要。要让 Agent 进入视觉代码领域的“Ralph 循环”,中间表示必须足够精确以指导下一步。模型不仅需要知道什么东西看起来不对,还需要知道要更改源代码的哪一部分以及为什么。结构、渲染或反馈中的微小错误可能会在迭代中迅速累积。

第三,未来很可能是混合的。像素原生模型仍然最适合生成逼真度、纹理和探索性内容。代码原生系统更适合结构、迭代和生产。最有用的工作流程将结合两者。

仍然存在一些开放性问题。每个领域哪种表示会胜出?我们是需要重造引擎和渲染器,而不是使用上一代已有的东西?视觉品味有多少可以被约束、测试和反馈循环所捕捉?

尽管如此,方向已经清晰:视觉 AI 正从输出转向代码产物。第一波浪潮让生成图像变得更容易。下一波浪潮将让生成可编辑、可测试、可发布和可改进的视觉产物变得更容易。

  • 原文链接: x.com/stuffyokodraws/sta...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论