a16z：视觉AI的未来不是图片，而是代码

原文标题：The Next Frontier of Visual AI Is Code
原文作者：@stuffyokodraws，a16z
编译：Peggy

编者按：过去几年，视觉 AI 的竞争几乎都围绕一个问题展开：谁生成的图片更真实，谁生成的视频更流畅。扩散模型把文本提示词变成图像、视频和逼真场景，也让外界习惯于用「像不像」「美不美」来评判模型能力。

但这篇来自 a16z 的文章指出，视觉 AI 的下一阶段，可能并不只是生成更漂亮的像素，而是生成像素背后的代码制品（code artifact，可继续编辑、测试和交付的结构化文件）。

这一区别看似技术，实则决定了 AI 能否真正进入生产工作流。设计师需要的不只是一张 UI 截图，而是 HTML/CSS、React 组件、图层和可交付文件；动画师需要的不只是一段视频，而是关键帧、时间曲线和可修改的运动参数；3D 艺术家需要的不只是一张渲染图，而是几何结构、材质、灯光、相机和场景层级。

因此，文章将视觉生成分为两条路径：像素原生生成（直接生成图片或视频）适合真实感、氛围和探索；代码原生生成（生成 SVG、Lottie、Blender 脚本、USD 场景等）则更适合编辑、迭代和生产。后者真正重要的地方在于，它可以形成「代码 → 渲染 → 检查 → 修改」的闭环。模型不再只是一次次重新抽样，而是在调试一个可验证的视觉程序。

这也是为什么作者尤其看好 3D。因为一张椅子的渲染图并不是椅子，只是椅子的图片。真正可用于游戏、模拟器或 3D 工具的资产，必须具备稳定的几何结构、部件层级、材质和功能约束：门要能打开，抽屉要能滑动，轮子要能转动。换句话说，未来视觉 AI 的价值，不在于「看起来像」，而在于「能不能被继续使用」。

这篇文章提供了一个很好的判断框架：第一波视觉 AI 解决的是生成问题，下一波要解决的是生产问题。当视觉 AI 从最终输出走向源代码，真正被改变的就不只是设计工具，而是整个视觉内容生产链条。

以下为原文：

过去几年，视觉 AI 大多是按「像素」来评判的。最终生成的图像或视频看起来越好，模型似乎就越强。

这并不奇怪。扩散模型先是把文本提示词变成精美图片，随后扩展到视频，再到越来越逼真的世界。人们自然会把它和 Photoshop 或相机放在一起比较。

但对于许多视觉相关任务来说，比如平面设计、UI 设计或 3D 建模，用户真正需要的最终表示，并不只是最终呈现出来的像素。他们需要的是一种可以根据反馈和新想法不断迭代的制品。设计师不只是需要一张 mockup（设计稿），还需要图层、组件和交付文件；动画师不只是需要一段视频，还需要时间曲线、关键帧和可编辑的运动轨迹；3D 艺术家不只是需要一张渲染图，还需要几何结构、材质、灯光、相机和场景结构。

今天最有意思的视觉 AI 工具，已经不再试图直接生成最终输出。它们开始生成最终输出背后的源代码。这一变化正在释放可编辑性、迭代能力和反馈循环，而这些是像素原生模型难以匹敌的。

视觉生成的两套技术栈

我们可以用两种主要方式来理解视觉生成。

第一种是像素原生生成。这类系统通常直接生成图像或视频，往往是在潜空间中完成。它们擅长纹理、氛围、光照和真实感。如果目标是生成一段电影感镜头、一组漂亮的 moodboard（情绪板），或一张照片级真实图像，扩散模型仍然是主流方法。

第二种是代码原生生成。这类系统生成的是一种表示形式，再由另一个引擎执行或渲染。模型并不直接生成最终像素，而是生成一段能够生成像素的程序。

这段程序可以是一个 SVG 文件、一套 HTML/CSS 布局、一个 React 组件、一个 Lottie JSON 文件、一段 Blender 脚本、一个 USD 场景图、一个 shader（着色器），或者一个游戏引擎场景。最终的视觉输出依然是像素，但真正的「事实来源」是一套结构化表示。

这个区别很重要，因为生产工作流非常关心「生成之后会发生什么」。一张生成图片可以作为输出使用，但一个生成出来的视觉程序，则可以作为制品使用：它能被编辑、复用、改进、版本管理；它可以被整合进软件技术栈，并根据约束进行验证；它可以在不同条件下反复渲染，也可以在设计师、工程师和 Agent 之间交接。

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

代码是解决视觉问题的好载体

理解视觉代码生成价值的最简单方式，是看第一版草稿之后会发生什么。

假设一个模型生成了一个 logo。如果输出是一张栅格图像，而其中一条曲线不对，用户就必须遮罩、局部重绘、重新生成，或者手动重画。但如果输出是 SVG，用户就可以直接编辑路径、基础图形、渐变、描边或文本元素。这已经是设计师在 Quiver 上设计 logo 的方式。

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

这也是为什么视觉代码生成尤其适合 test-time compute（测试时计算）。在像素原生生成中，增加推理计算通常意味着采样更多输出：生成 20 张图，挑出最好的一张，也许再试一次。这当然有用，但每次尝试本质上更像是重新掷骰子。模型可以响应反馈，但这种反馈通常是整体性的，也不够精确。

从技术上说，扩散模型也可以从 test-time compute 中受益。例如，《Inference-time Scaling of Diffusion Models through Classical Search》表明，推理阶段的搜索可以改善扩散模型在规划、强化学习和图像生成中的表现。但这里的循环机制不同。在扩散模型中，系统通常是在潜在轨迹或最终样本之间搜索。奖励信号可以告诉模型某个输出比另一个更好，但它无法把反馈清晰地映射到某个源代码级别的具体修改上。

代码原生生成创造了一种更精确的循环：代码 → 渲染 → 检查 → 修改。

模型生成制品，将其渲染出来，观察哪里出了问题，然后修补源文件。如果间距不对，就修改 CSS；如果 logo 曲线有偏差，就编辑 SVG 路径；如果动画节奏太慢，就调整时间参数。关键在于，每一次迭代改善的都是底层制品，而不只是渲染后的输出。这也是为什么视觉代码生成天然能够受益于更多 token 生成和 test-time compute。模型是在一个闭环、可验证的环境中调试视觉程序，而不只是采样更多图片。

以代码为核心的视觉生成技术栈

上述例子背后，是这样一套技术栈：编码模型 + 符号表示 + 渲染器或引擎。

编码模型是制品的作者和编辑者。它负责编写 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 可以用来提升输出质量的 test-time compute 循环：在每一次「代码 → 渲染 → 检查 → 修改」的循环中，模型并不是又生成了一个新样本，而是在利用渲染器提供的反馈，改善底层制品。它可以修改 CSS 规则、调整 SVG 路径、修正动画时间，或更新 3D 约束，然后再次渲染，并继续改进。

这让循环具备了收敛的可能。在像素原生生成中，每次重试往往都会产生一个新的输出。而在代码原生生成中，每次重试都可以改善源制品本身。模型不只是采样更多图像或视频，而是在一个闭环、可渲染的环境中调试视觉程序。

市场地图：围绕运行时形成切入口

视觉代码生成市场正在围绕「运行时」组织起来，也就是制品被渲染或执行的地方。在代码原生视觉生成中，模型生成的是一种符号制品，而这个制品会在某个环境里被执行：浏览器、SVG 渲染器、Lottie 播放器、Blender、游戏引擎或模拟器。

每一种运行时都会形成不同的切入口，因为每一种运行时都有自己的源表示、反馈循环和生产工作流。

今天最明显的应用是在 2D 设计领域，尤其是 UI 设计和平面设计。但视觉代码生成并不局限于设计工具。只要视觉制品背后存在一种可以被生成、渲染、检查和优化的底层表示，它就可能出现。

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

虽然产品设计和 2D 设计是今天最直观的用例，但 3D 制品可能最能受益于这种「把一致性问题重新定义为编码问题」的方式。

一个 2D 设计有时只要看起来正确，就已经有用。但 3D 资产不行。一张椅子的渲染图并不是椅子，它只是椅子的图片。若要让这个资产在游戏、模拟器或 3D 编辑工具中真正可用，它必须拥有一致的底层 3D 表示，包括正确的几何结构、材质、部件层级和场景上下文。

这就是为什么 3D 天然适合视觉代码生成。它的价值不只是生成一个从某个角度看起来像 3D 的东西，而是生成一个在不同视角、编辑和交互中都能成立的一致 3D 结构。这需要一个迭代循环：提出对象，渲染它，检查几何结构和部件是否合理，然后修改底层表示。但这个循环只有在 Agent 拥有正确工具和上下文时才有效。只是不断运行 Blender，直到某个东西看起来更好，并不够。Agent 需要能够切换相机视角、查询场景状态、隔离对象、与目标进行比较、记住之前的尝试，并把视觉差异转化为源文件级别的修改。正是这些能力，让 test-time compute 有机会走向收敛。

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

这正是 VIGA 和 Articraft3D 这类项目引人注目的地方。我们预计今年还会看到更多相关工作出现，包括商业化项目和开源项目。VIGA 使用 Blender 作为渲染和反馈环境，把视觉重建转化为「代码—渲染—检查」的循环；但 VIGA 并不是简单地把原始 Blender 暴露给 Agent 循环。它为 Agent 提供了用于观察和修改的语义工具，并保留对过往尝试的记忆，使其能够从更好的视角检查对象、诊断问题，并进行有针对性的修改。Articraft3D 则更直接地处理资产结构：它把有关节的 3D 生成定义为编写程序，这些程序负责定义部件、几何结构、关节和测试。

未来影响与未解问题

如果视觉代码生成真的成立，最终胜出的产品不会只是生成更漂亮的输出。它们会掌握整个循环：生成制品、渲染制品、检查哪里出了问题，并修改源文件。

这会带来几个影响。

首先，渲染器会成为反馈环境。浏览器、SVG 渲染器、Lottie 播放器、Blender、游戏引擎和模拟器，将成为 Agent 测试并改进作品的环境，就像今天编码 Agent 正在利用沙盒和虚拟机一样。

其次，迭代上下文的质量会变得比以往更加重要。要让 Agent 进入视觉代码版本的「Ralph loop」，中间表示必须足够精确，能够指导下一步操作。模型需要知道的不只是「某个东西看起来不对」，还要知道应该修改源文件中的哪一部分，以及为什么要这样改。结构、渲染或反馈中的小错误，可能在多轮迭代中迅速累积。

第三，未来很可能是混合式的。像素原生模型仍然最擅长真实感、纹理和探索；代码原生系统则更适合结构、迭代和生产。最有用的工作流将会把二者结合起来。

当然，还有很多开放问题。每个领域最终会采用哪一种表示方式？我们是否需要重新打造引擎和渲染器，而不是继续使用上一代工具？视觉品味在多大程度上能够被约束、测试和反馈循环捕捉？

但方向已经很清楚：视觉 AI 正在从输出走向代码制品。第一波浪潮让生成图像变得更容易；下一波浪潮将让生成那些可编辑、可测试、可交付、可改进的视觉制品变得更容易。

[原文链接]