← 参考列表

The Next Frontier of Visual AI Is Code

a16z · 2026.6.2 · 阅读原文 →
背景

a16z 发布了一篇研判视觉 AI 下一波趋势的文章，核心论点：视觉 AI 的前沿不再是如何生成更好看的像素，而是生成可编辑的代码表示。

文章区分了两条技术路线：像素原生（pixel-native）——以扩散模型为代表，直接在像素空间中生成图像或视频；代码原生（code-native）——模型输出的不是像素，而是一段描述图像结构的程序（SVG、HTML/CSS、React 组件、Blender 脚本、Lottie JSON 等），再由渲染引擎将程序画成画面。

两者的根本区别不在于画得好看与否，而在于生成的是一个无法拆解的成品（像素），还是可拆解、可编辑、可迭代的源文件（代码）。代码原生的优势在于：用户想修改一处，只需改源码中的一行参数并重新渲染，而非用补绘或重画的方式推倒重来。

文章指出，生产环境真正关心的是生成之后发生的事情——资产是否可分发、可版本管理、可交接给工程师继续修改。像素只能作为"输出"，代码则能作为"工件"进入后续工作流。

关键引述
The most interesting visual AI tools today have stopped trying to generate the final output. Instead, they're generating the source code behind it. This change is unlocking editability, iteration, and a feedback loop that pixel-native models can't match.
—— 全文核心命题：从"生成成品"到"生成源码"，打开的是可编辑、可迭代的闭环
For a subset of visual problems, we will learn to reframe the visual generation task to a coding task, and get highly efficient improvements from solving a well-defined and validatable coding problem.
—— 将视觉问题重新定义为编程问题，从"抽奖式重试"转变为"精确溯源修复"
The model is debugging a visual program in a closed-loop, verifiable environment; not just sampling more images.
—— 代码原生模型的行为类比是调试而非渲染：在可验证环境中修正源程序
In pixel-native generation, each retry often produces a new output. In code-native generation, each retry can improve the source artifact itself.
—— 像素原生每次重试是"重新抽奖"；代码原生每次重试是在同一个工件上累积进步
A 3D asset cannot just look right. For the asset to be useful in a game, simulation or 3D editing tool, the artifact needs the consistent underlying 3D representation with the right geometry, materials, part hierarchy and scene context.
—— 3D 是代码原生的最佳应用场景：一个"看起来像"的 3D 图片毫无意义，必须"物理上成立"
核心机制：四步闭环

文章提出的视觉代码生成栈由三个组件和四个步骤构成：

三组件：编码模型 + 符号表示 + 渲染/执行引擎。编码模型是作者和编辑者，输出 SVG/HTML/Lottie JSON/Blender 脚本/USD 场景文件；符号表示是事实源，包含 DOM 节点、布局规则、矢量形状、关键帧、材质、关节约束等；渲染引擎（浏览器、SVG 渲染器、Lottie 播放器、Blender、游戏引擎）将符号表示转为可检查的像素。

四步闭环：Code → Render → Inspect → Revise。模型写出代码 → 渲染引擎画出画面 → 模型检查画面发现椅子腿悬空或间距错误 → 定位到源码中的对应行进行修改 → 重新渲染验证。

这个循环的精髓在于：每一步都不是重新生成，而是在调试一个可执行的视觉程序。每一个错误都可以回溯到符号表示中的具体参数——CSS 规则、SVG 路径、动画 timing、3D 约束——并精确修正。文章称之为"测试时计算可以收敛的路径"，区别于扩散模型的重试式搜索。

为什么 3D 是代码原生的终极场景

文章认为，2D 设计错了还能看——一张 Logo 位图纵有缺陷，大致感觉对了就能用。但 3D 资产没有"大致成立"的空间：一把椅子必须有四条腿接地、门必须有铰链能旋转、抽屉必须有滑轨能拉出。如果椅子腿穿到地板下面，整个资产就是废品。

这意味着 3D 对 Code → Render → Inspect → Revise 循环有着最强的硬需求——它不是锦上添花的编辑能力，而是生存前提。

文章提到两个代表项目：VIGA（为 AI 提供语义化的 Blender 操作工具——切换视角、查询场景状态、隔离对象——让 AI 在 Blender 里反复生成-渲染-检查-修正，直到 3D 物体成立）和 Articraft3D（更进一步，让 AI 写出定义了零件层级、几何体、关节和测试的程序，输出的是有功能约束的 3D 资产而非单张渲染图）。

这篇文章真正想说的是：当 3D 建模从手工建模变成 AI 可自动调试的编程问题，整个 3D 资产供应链的效率就有数量级的提升空间。

深层分析：为什么 a16z 这个时候提出这个叙事

结合 a16z 同期发布的多篇"全球使命"系列文章，这篇文章不应被孤立地理解为技术趋势分析。它更核心的功能是投资 thesis 信号。

市场地图：按渲染运行时切分

文章提出应用层正在按渲染运行时自然分化，每个运行时创造不同的"楔子"——因为它有自己独特的符号表示、反馈循环和生产工作流：

赢家不是"生成得最好看的模型"，而是能把模型、符号表示、渲染引擎串成一个闭环迭代系统的公司。

与上下文 Lab 的关系

Code → Render → Inspect → Revise 闭环本质上是一个结构化的上下文累积过程。每次渲染的错误转变为下一次代码修改的信号；每次修正的结果携带前一次尝试的信息。Agent 需要跨渲染轮次记住相机视角、物体状态、历史修正记录——这正是 Context Graph 试图解决的持久化、可追溯的上下文管理问题。

具体而言，VIGA 论文中提到的"给 agent 提供语义观察工具和跨尝试的记忆模块"描述了这样一种需求：Agent 需要将视觉检查结果转化为源码编辑指令，这中间涉及隐式上下文的显式化（"这条椅子腿看起来不对"→"position.y 需要 +0.3"）——与上下文 Lab 关注的结构化 context 有方向性交集。

更宏观的层面：文章揭示的趋势是AI 的输出从"消费品"变成"中间件"——代码作为 Agent 与渲染引擎之间的接口层。这种"Agent → 结构化中间件 → 执行环境"的架构模式不仅适用于视觉领域，也适用于更广泛的 Agent 工作流——Context Layer 在这个架构中的位置正是连接 Agent 决策与执行环境的上下文基础设施。

阅读原文 →