代码即房间：通过智能体代码合成从俯视图生成 3D 房间

用 MLLM 智能体分阶段生成 Blender 代码，从俯视图重建可执行 3D 房间。

前置知识

多模态大语言模型 (MLLM)

能同时处理图像与文本的视觉-语言模型，可执行跨模态推理、视觉问答、代码生成等任务。本文中 Gemini-3 Flash、GPT-5.5 等都属此类，充当智能体的视觉中枢。

整个 Code-as-Room 框架以 MLLM 为决策核心，需要理解它在布局评判、代码生成中的角色及上下文限制。

Blender 脚本化建模 (bpy API)

Blender 的 Python API 通过代码创建几何体、材质、灯光和相机，输出可执行 .py 脚本即可重建完整 3D 场景，是 "代码即 3D 资产" 的代表范式。

论文以 Blender 代码作为 3D 房间的最终表示，读者需要了解 bpy 的基本图元、材质、渲染管线。

智能体系统 (Agentic System) 与反馈循环

由 LLM 担任决策者，调用工具、执行动作、观察结果并迭代修正的工作模式，常采用 render-critique-revise 等多阶段闭环。Code-as-Room 把这一模式系统化为 10 个阶段的执行流水线。

本文核心创新在于结构化执行支架 (structured execution harness) 与跨阶段记忆，没接触过智能体读者难以理解其动机。

场景图 (Scene Graph) 与空间关系推理

以节点表示物体、边表示物体间空间/层级关系的图结构，可编码共现、支持、对称等约束。论文 Stage 2 把俯视图解析为带父子与相邻关系的图，作为后续布局的骨架。

场景图是 Code-as-Room 把图像转译成代码的中间表示，决定后续几何生成的拓扑正确性。

研究动机

传统 3D 房间建模依赖 ProceduralTHOR 等规则系统或手工摆放，扩展性差且无法直接从可视化输入得到可控结果。基于 MLLM 的文本驱动方法（如 Holodeck、LAYOUTVLM）受限于语言无法精确表达物体数量、位置、朝向等空间信息，生成的房间与设计意图常有偏差。当把视角条件改为俯视图（top-down view）进行整体房间生成时，现有智能体范式又会陷入两类典型失败：一是 VIGA 这类分析-合成循环代码智能体在俯视图输入下无法恢复精细空间布局，二是智能体上下文长度有限，长流水线中极易遗忘早期输出，导致对象遗漏、重叠和边界错误。这些问题在单张图像生成完整 3D 房间的设置下被进一步放大，因为模型必须同时推断房间结构、空间布局、几何造型与外观。

本文的目标是论文提出 Code-as-Room (CaR)，用基于 MLLM 的智能体加结构化执行支架，把单张俯视图转换为可在 Blender 中直接执行、可渲染可编辑的 3D 房间代码。框架要在保证空间布局与原图对齐的同时，让跨阶段信息不丢失、对小件与材质细节也给予足够处理，并构建专属评测基准，从视觉理解、空间推理、代码生成与场景质量四个维度比较不同 VLM 基座与现有智能体基线。目标是把 "图像→3D 房间" 这条链路由不可控的一次性生成，转为稳定、可迭代、可评测的多阶段工程化流水线，使三主流 VLM 在该任务上都获得稳定提升。

与已有工作不同的是，本文切入角度有三：第一，把图像而不是文本作为全局空间先验，让房间结构与家具布局直接由俯视图驱动，绕开文本对空间信息的精度损失；第二，把"图像到 3D"拆解成十个阶段的执行流水线，配合 render-critique-revise 视觉反馈与跨阶段记忆模块，从根本上抑制上下文遗忘与无限循环；第三，把 3D 房间表示为可执行 Blender 代码而非 JSON 场景描述或单物体神经辐射场，从而获得可编辑、可复用、一次性建模整体房间的能力，并通过专属基准验证该范式相对直接生成与 VIGA 的优越性。

核心方法

整体思路是 "以图像为骨架，以代码为肌理"：给定单张俯视图 $I$，用一个拥有结构化执行支架的 MLLM 智能体 $A$ 把它映射为可执行的 Blender 脚本 $C = A(I)$。直觉上，人类设计师依据平面图建模时会先勾画分区、再摆大件家具、再补墙饰和小物、最后上材质与灯光，Code-as-Room 把这条工作流编码为十个阶段，并在每一步都允许 VLM 进行视觉评判与修订。技术上把任务粗分为两阶段：粗阶段先用 Stage 1-2 做语义分区与场景图，得到结构化场景状态 $D_{CU}$；Stage 3-4 生成可渲染的布局代理代码 $C_{\text{layout}}$，通过 render-critique-revise 闭环把 Layout IoU 等空间指标调到收敛。细阶段用 Stage 5 做布局对齐的物体描述 $D_{FU}$，Stage 6 用程序化几何 + Asset 检索替换代理，Stage 7-10 顺序完成 PBR 材质、纹理贴图、灯光与位置的后校正。整个流水线由跨阶段记忆模块 $M$ 串接，所有阶段按记忆视图读写，避免 prompt 噪声。

和已有方法相比的核心差异在于把"长链路智能体"转化为"结构化执行支架"：VIGA 等代码智能体使用粗粒度的 generate-then-loop，缺乏显式阶段分工与持久记忆，因此对俯视图整体房间生成既易空间错位又会陷入死循环；文本驱动方法则完全没有图像条件。本文的关键创新正是 (a) 跨阶段记忆 $M_s = M_{s-1} \oplus e_s$ 用类型化 artifact 把每阶段输出固化，使下游阶段只读写预定视图，既消除上下文遗忘，又把 prompt 控制在大致稳定长度；(b) 把 render-critique-revise 循环具体化为 Stage 3-4 中的布局校验，先 sanitize 批评意见避免擅自改墙窗等架构元素，再用最大迭代 $T_{\max}=5$ 避免无限制修订；(c) 物体级代码生成 Stage 6 把每个代理拆为局部坐标系下的语义部件 $P_i = \{\pi_{i,j}\}_{j=1}^{K_i}$，并以程序化几何 + 资产检索混合策略处理小件，从而在不依赖"先有 3D 资产才能放"的前提下完整生成房间级场景。

方法步骤详情

方法分十个阶段串联：Stage 1 用 VLM 输出 schema 约束的空间语义描述 $D_1$；Stage 2 将其解析为带父子与空间边的场景图 $G$。Stage 3 初始化 $C^{(0)}=\text{Generate}(I,D_1,G)$，进入 Render、Critique、Sanitize、Revise 闭环，最多 $T_{\max}=5$ 次后冻结为 $C_{\text{major layout}}$；Stage 4 追加墙挂件与显著性小件，得完整 $C_{\text{layout}}$。Stage 5 由 VLM 输出颜色、材质、功能的细粒度描述 $D_{FU}$。Stage 6 用语义部件 $P_i=\Phi_{\text{geo}}(o_i,d_i)$ 替换代理几何，小件以 $\arg\max_{b\in B}\text{match}$ 在资产库检索替换。Stage 7-10 在不动布局几何的前提下，加 PBR 材质、扩散纹理 + UV、灯光与渲染参数，并以局部搜索校正边界碰撞，得最终代码 $C=\text{PostHoc}(C_{\text{raw}})$。

技术新颖性

技术新颖性体现在三方面：(1) 跨阶段类型化记忆 $M$ 的形式化定义为长链路智能体设计提供了一种可推广的"读写视图"机制，避免传统 prompt 拼接导致的信息丢失。论文中消融显示去掉记忆后 Layout IoU 从 $73.2\%$ 跌至 $58.0\%$，Obj. Recall 从 $55.5\%$ 降至 $48.2\%$，验证了其关键性。(2) 把 render-critique-revise 闭环约束在 Stage 3-4 的布局级而非全代码级，并对批评做 schema-level sanitize，既利用视觉反馈提升布局（Layout IoU 从 $64.0\%$ 升到 $66.2\%$），又防止自反式修改带来的过校正（迭代 10 次时旋转精度反而从 $75.4\%$ 降至 $72.6\%$）。(3) 把 3D 房间直接表示为 Blender 代码，相对于 JSON 场景图或 NeRF 提供可编辑、可复用、可执行的精细结构，并且通过部件级 PBR、纹理生成模型与资产检索混合策略，把代码生成与 3D 资产生态连接，使 VLM 在不擅长复杂几何时仍能借助已有资产填补细节。

**Figure 2**: Overview of the Code-as-Room pipeline.

实验结果

41 场景基准上 CaR 在三种 VLM 上都稳定提升：Gemini3-Flash w/CaR 把 Layout IoU 从 16.8% 提到 72.0%、Execution Rate 从 57.8% 升到 100%；Gemini3.1-Pro w/CaR 在 Spatial Relation 79.8%、Rotation 93.6%、Support 94.0% 居首；GPT-5.5 w/CaR 拿到最高 Object Recall 67.5% 但 Execution 仅 73.3%。20 位专家评测 CaR w/ Gemini3.1-Pro Sim=9.0、Use=8.0、Accept=7.5 全面压倒 VIGA 的 5.5/4.5/4.0。Table 3 消融显示去记忆使 Layout IoU 由 73.2% 跌到 58.0%；反馈 0→5 次 Obj Recall 由 33.8% 升到 38.4%，10 次时 Rotation 反从 75.4% 降至 72.6%，印证 $T_{\max}=5$ 为质量-成本折中点。重渲染实验表明网格化房间可作为多视角一致的视觉增强先验。

**Table 1**: Benchmark results for code-based 3D room generation from top-down images across four metric families.

**Table 2**: Human evaluation of overall scene quality.

**Table 3**: Ablation study on different components of Code-as-Room.

**Figure 3**: Qualitative comparisons corresponding to the benchmark results in Table 1.

**Figure 4**: Representative qualitative results corresponding to the benchmarks in Table 1.

**Figure 5**: Detailed qualitative analysis and performance comparisons relative to the benchmarks in Table 1.

**Figure 6**: Comparative performance analysis of Gemini 3.1-Pro with CaR vs the VIGA framework.

**Figure 7**: Visual Enhancement Comparison: From Base 3D Scenes (left) to Realistic Re-rendering by GPT-5.5 (right).

查看结构化数据

任务	指标	本文	基线	提升
直接 VLM 生成 vs CaR Agentic Harness (Gemini3-Flash)	Object Recall / Layout IoU / Execution Rate	58.9% / 72.0% / 100%	Direct Gemini3.1-Pro 17.8% / 16.8% / 57.8%	Object Recall +41.1pp, Layout IoU +55.2pp, Execution Rate +42.2pp
CaR w/ Gemini3.1-Pro 全部空间推理指标	Spatial Relation / Rotation Acc / Support Acc	79.8% / 93.6% / 94.0%	Direct Gemini3.1-Pro 54.7% / 78.0% / 41.7%	Spatial Relation +25.1pp, Rotation +15.6pp, Support +52.3pp
CaR w/ GPT-5.5 vs Direct GPT-5.5	Layout IoU / Agent Completion / Execution Rate	66.7% / 71.1% / 73.3%	46.2% / – / 42.2%	Layout IoU +20.5pp, Execution Rate +31.1pp
Human Evaluation: CaR vs VIGA	Similarity / Usability / Acceptability (满分 10)	CaR Gemini3.1-Pro: 9.0 / 8.0 / 7.5	VIGA: 5.5 / 4.5 / 4.0	Similarity +3.5, Usability +3.5, Acceptability +3.5
Ablation: Memory 机制	Obj. Recall / Layout IoU / Rotation Acc	Full Model 55.5% / 73.2% / 93.6%	w/o Memory 48.2% / 58.0% / 88.4%	Obj. Recall +7.3pp, Layout IoU +15.2pp, Rotation +5.2pp
Ablation: Visual Feedback 迭代数	Obj. Recall / Layout IoU / Rotation Acc @ Feedback=5	Feedback×5 38.4% / 66.2% / 75.4%	Feedback×0 33.8% / 64.0% / 71.9%	Obj. Recall +4.6pp, Layout IoU +2.2pp, Rotation +3.5pp

局限与改进

论文 Limitations 明确指出三点限制：(1) 当前框架仅针对 top-down view 设计，没有覆盖任意视角输入；(2) 程序化几何无法忠实还原形状复杂、几何细节丰富的真实物体，仍需借助资产检索，跨模态对齐有限制；(3) 重渲染阶段（用 GPT-5.5 增强 Blender 输出为真实感图像）受限于当下视频生成模型，对超过 5 秒的相机轨迹，时间一致性仍不足。我们自己的观察还补充两点：智能体对 Scene Graph 中父子/相邻关系正确性高度依赖，在俯视图遮挡严重的小房间中容易生成共面重叠（Self Overlap 指标 Gemini3-flash w/CaR 仍有 2.57%）；另外 Benchmark 41 个场景规模偏小，且 Stage 6 依赖的资产库 $B$ 未在文中公开名称，迁移到新领域时建议补齐自建库，否则 Execution Rate 在小众房型上会下降（GPT-5.5 w/CaR 已跌到 73.3%）。

独立分析的弱点

四点可着手的弱点：(1) Stage 2 的场景图仍依赖 VLM 在已有节点上补全属性与正向边、无显式几何先验，俯视图严重压缩时易出现"沙发与床头柜共面"错误，可引入 GroundingDINO 等 open-vocabulary 检测器先初始化节点。(2) render-critique 反馈循环只覆盖 Stage 3-4，没有下推到 Stage 6 后的物体级几何与材质层，建议把 VIGA 已验证的对象级反馈拓展到 Stage 7-9，并对每阶段输出加 Schema 校验。(3) 资产检索只用语义标签 + 描述 + 占位尺寸打分，未引入 3D 形状先验，存在同标签几何歧义，可改为先 text-to-3D 生成候选再 render-and-match 二次筛选。(4) CaR 强依赖 Blender bpy 生态，对无 Blender 的下游任务 (Web GPU / 移动端) 不友好，建议把最终代码转译为 Three.js / glTF 描述扩展适配面。

未来方向

作者在结论中提出下一步用视频生成模型作为神经渲染器把 Blender 输出转为 4D 可视化，可在多视角一致性上突破当前 5 秒瓶颈。基于成果可延伸的方向还包括：(a) 把跨阶段记忆 $M$ 与外部知识图谱 (Wikidata / ConceptNet) 连接，让 VLM 在对象 profiling 时能检索真实品牌家具的几何先验，缩小程序化几何与资产库的差距；(b) 把同一执行支架拓展到动态场景与机器人模拟，把 Stage 6 的几何直接传给 Isaac Sim / Habitat 进行具身训练，从而把 "图像→3D 房间" 升级为 "图像→可交互仿真资产"；(c) 引入显式物理仿真与碰撞推导，结合 Constraint-Satisfaction 把当前 Stage 10 的局部搜索替换为可微优化，进一步提升物体支撑关系 (Support Acc) 接近 100%；(d) 在更大多模态基座（Gemini4、Claude Opus 5 等）上重新跑基准，验证 harness 在更强 VLM 上的边际收益是否饱和。

复现评估

项目页 code-as-room.github.io/2026 公开了论文、demo 与部分 Stage 提示词、示例 Blender 代码，但完整 10 阶段 prompt 模板、bpy 函数封装与 Stage 6 资产库 $B$ 尚未以 monorepo 形式开源；41 场景标注经 Gemini 3.1 + 反向 code refinement 流水线完成，作者承认存在跨模型偏差未独立发布。运行所需算力取决于基座：Gemini3 Flash/Pro、GPT-5.5 走云端 API，单房间全 10 阶段约 8-12 分钟；本地重跑 Stage 9 纹理需扩散模型算力。整体复现难度评 "中高"：图像→场景图、布局反馈、几何替换三段 Schema 清晰但要自己拼出 bpy 模板；建议优先复用 Objaverse / ABO 作为资产库；自评与第三方复现因 VLM 评分差异会出现系统性偏差（如 Human Accept 7.5 vs VLM Quality 8.20）。

代码即房间：通过智能体代码合成从俯视图生成 3D 房间 Code-as-Room: Generating 3D Rooms from Top-Down View Images via Agentic Code Synthesis