香港中文大学联合多校团队研发：让AI像搭积木一样造房间，还能让机器人真正"动"起来

这项由香港中文大学、上海交通大学、上海人工智能实验室、微软研究院和牛津大学联合完成的研究，以预印本形式发布于2026年5月19日，论文编号为arXiv:2605.19587，感兴趣的读者可通过该编号在arXiv平台查阅完整论文。

**房间里的那些"哑巴"家具**

如果你曾经玩过《模拟人生》或者任何一款家居设计软件，你大概有过这样的体验：你可以把沙发、桌子、床摆得井井有条，但这些家具只是图片而已——抽屉打不开，柜门推不动，椅子也没法真的坐。这种"只能看不能动"的状态，正是目前大多数AI房间生成系统面临的根本困境。

研究人员做到了一件事：用自然语言描述一个房间，比如"青少年卧室，有一张带床头板的单人床、一个带多个抽屉的木衣柜，以及桌上的台灯"，然后让系统自动生成一个完整的三维房间场景——不只是好看的图像，而是每一件家具都像真实家具一样有内部结构、有关节、有运动范围，甚至可以让机械臂真的去拉开抽屉或推开柜门。

这套系统叫做**SceneCode**，它的核心创意是把"生成房间"这件事从"画一张图"变成了"写一段可执行的程序"。

---

**一、为什么之前的方案总是差那么一口气**

在SceneCode出现之前，AI生成室内场景的方式大体上分成几种路子。一种是"图书馆选书式"：从一个已有的3D模型库里挑选合适的家具，然后摆放到房间里。这就像你在宜家只能买他们架子上有的款式，如果你想要一个带三个抽屉加一扇玻璃门的特定酒柜，那只能凑合用最接近的那款。另一种是"AI画图式"：用图像生成技术直接输出一团三角面片组成的三维模型，看起来像家具，但本质上是一块实心的数字泥巴，没有内部结构，没有可以活动的部件，更无从谈起让机器人去操作。

还有一种混合方式：用图书馆里的模型处理需要活动的家具，用AI图像生成处理其他家具。这条路看起来聪明，但问题同样明显——活动家具的种类和样式被图书馆的库存限制死了，而AI生成的那部分又是"实心泥巴"，两套体系拼在一起，最终得到的场景既不够灵活，也不够完整。

SceneCode的研究团队认为，这些方案的共同问题在于它们把家具当成了"终点"——拿到一个模型就结束了。真正需要的，是把家具当成"程序"来对待，让每一件家具都有可以读取、修改、重新执行的代码根基。

---

**二、用"乐高说明书"理解SceneCode的核心思路**

SceneCode的核心比喻，用"乐高积木说明书"来理解最为直观。

普通AI生成家具，就像是直接给你一张家具的照片或者雕塑——你能看到它长什么样，但没有办法知道它是由哪些零件组成的，也没办法换掉其中一个零件或者让某个部分动起来。而SceneCode生成家具的方式，是写一份精确的"乐高积木说明书"——这份说明书告诉你：主体框架用什么形状的积木，前面板用什么尺寸，抽屉的滑轨从哪里开始到哪里结束，铰链的转动范围是多少度，木头部分是什么颜色，金属把手用什么材质。

这份说明书本身就是一段Blender Python程序——Blender是一款专业的3D建模软件，Python则是一种常用的编程语言。程序写好之后，系统在"无头模式"（可以理解为后台静默运行）下执行这段程序，就自动搭出了一件完整的三维家具，而且每个零件都是独立可操作的。

有了这份说明书，后续想改动就变得极其自然：想把四个抽屉改成两个？修改说明书里对应的参数重新执行就行。想把木质把手换成金属的？改一行材质代码即可。这种灵活性是任何"直接给你一个模型"的方案都无法提供的。

---

**三、从一句话到一整个可互动房间，具体怎么做到的**

SceneCode把整个房间生成任务分成了两个层面，两者像总指挥和施工队一样配合运作。

**总指挥：房间规划层**

当你输入一段描述文字，比如那段关于青少年卧室的描述，系统首先会进行整体规划。这个规划过程由一套叫做"规划—设计—批评"的循环驱动：规划阶段决定下一步要放什么家具，设计阶段调用工具实际创建或调整家具，批评阶段则从渲染好的场景图像出发，结合场景状态信息和几何一致性检查，评估中间成果是否合理。

这个规划层把房间里的家具分成四个批次依次处理：先是大型家具（床、衣柜、沙发），再是墙面挂件（画框、镜子、时钟），然后是天花板悬挂物（吊灯），最后是可操作的小物件（书本、碗、手机）。这种顺序不是随机的，而是模拟了真实装修的逻辑——总得先放大件再放小件，否则容易出现碰撞和遮挡问题。

规划层最终输出的不是家具本身，而是一份"采购单"，学术上叫做AssetRequest。这份采购单写明了每件家具的类别、文字描述、目标尺寸、风格要求、在房间里的位置，以及它和其他家具或建筑结构之间的关系（比如"放在床右边"或"靠墙摆放"）。

**施工队：代码驱动的家具生成层**

拿到采购单之后，施工队开始具体建造每一件家具，这个过程分成环环相扣的几步。

第一步是路由分配，也就是判断这件家具应该用哪种"施工方案"来建造。系统内置了六种不同的方案：墙面艺术品方案专门处理画框海报之类的薄片挂件；静态家具方案负责床、沙发这类没有活动部件的大件；简单可操作物品方案处理碗、盘子这类形状简单的物件；结构化可操作物品方案负责杯子、手机这类有多个可见部件但不需要活动关节的物品；关节物品方案则专门负责那些有活动部件的家具，比如带门的柜子、带抽屉的桌子；还有一个固定模板方案专门处理地毯这类薄薄的覆盖物，直接套用模板而不需要AI去自由发挥。

第二步是生成"物体蓝图"，学术上叫ObjectPlan。系统会根据采购单的文字描述先生成一张参考图片，然后结合参考图片和采购单，制定出这件家具的详细零件清单：每个零件叫什么、用什么几何形状（方块、圆柱、球体、环形还是曲线）、放在物体本地坐标系的哪个位置、用什么材质、有没有对称关系，以及最关键的——这个零件会不会活动。

第三步是蓝图验证。自由生成的蓝图可能有各种问题：把椅子腿漏掉了，把抽屉面板画得比柜体还宽，或者把活动部件和固定部件合并在一起了。系统会用一套规则检查加上AI辅助修订的流程来纠正这些问题，确保蓝图在进入代码生成环节之前就已经合理可靠。

第四步是按零件分别生成Blender Python代码并组装。每个零件各有一段独立的程序，程序执行后生成那个零件的三维网格和材质，然后一段组装脚本把所有零件拼在一起，同时保证每个零件仍然是独立命名的Blender对象，活动部件和固定部件不会被合并成一块"实心泥巴"。

第五步是执行验证和修复循环。每段零件程序在Blender后台真正运行，如果运行出错，系统会把错误信息和出问题的代码一起送回AI，让它修改，最多允许修改三次。程序成功运行后，再让一个批评AI看渲染出来的图像，判断这件家具的外观、结构和材质是否符合要求，不满意就触发整体精化，最多精化两轮。这套"运行—报错—修复—渲染—批评—精化"的闭环，大幅降低了最终入库家具的错误率。

---

**四、让家具"活"起来：关节和物理仿真的加入**

生成好看的3D家具只是完成了一半的工作。对于需要活动的家具，SceneCode还要完成一个关键步骤：把视觉模型翻译成物理仿真系统能够读懂的格式。

具体来说，对于被标记为"可活动"的零件，系统会让一个AI辅助的关节编译器来分析这些零件，然后为每个可活动部件生成一份关节描述：它的父部件是哪个（比如抽屉的父部件是柜体）、关节类型是转动式（铰链，就像门）还是滑动式（棱柱关节，就像抽屉）、转动或滑动的轴在哪个方向、运动范围的下限和上限是多少。

除了关节信息，每个零件还会被赋予物理属性：质量（根据物件的语义类别和尺寸估算）、惯性张量（决定物体在受力时如何旋转）、以及简化的碰撞几何体（用于碰撞检测，不需要像视觉模型那样精细）。

最终，整件家具会被导出为SDF格式——这是Gazebo等物理仿真平台通用的描述格式。有了这个文件，机械臂可以真正地去操作这件家具：推开柜门会感受到铰链的阻力，拉出抽屉会受到滑轨范围的限制。

---

**五、把所有家具串成一个可追踪、可局部修改的完整房间**

生成了所有家具之后，SceneCode还需要把它们正确地摆进房间，并建立一套完整的"场景状态档案"。

每件家具生成完毕后，都会在一个叫做house_state.json的文件里注册自己的信息，包括它属于哪类物件、有哪些活动部件、关节参数是什么、在房间里的位置和朝向、放置在什么支撑面上、视觉模型文件在哪里、仿真文件在哪里。这个档案文件就像是整栋房子的"户口本"，每件家具的来龙去脉都记录得清清楚楚。

摆放家具时，系统会自动把家具缩放到采购单指定的目标尺寸，应用规划层给出的位置和朝向，然后让家具底部对齐支撑面（地板或桌面）。摆好之后，还会进行一轮一致性检查：家具有没有陷进地板里？有没有和别的家具重叠？有没有跑到房间外面去？

因为每件家具都有独立的程序和注册ID，如果你觉得某件家具不满意，只需要重新执行那件家具的程序，不需要重新生成整个房间。这种"局部可重新执行"的特性，是把家具表示为程序而非模型文件的直接好处。

---

**六、测试结果：比同类系统做得更好，优势在哪里**

研究团队用30个覆盖卧室、客厅、餐厅、厨房、浴室和地下室六类场景的文字描述来测试SceneCode，并与三个同类系统进行了对比：SceneSmith（另一个面向物理仿真的场景生成系统）、HSM（层次场景主题系统）和LayoutVLM（基于视觉语言模型的布局优化系统）。

在语义忠实度方面，也就是"生成的房间有没有包含描述里要求的那些家具、这些家具有没有正确的属性"，SceneCode在物件数量满足率和属性满足率两项上同时领先，是唯一在这两项上都排第一的系统。属性满足率的优势尤其显著，比检索式系统LayoutVLM高出约42个百分点——这正是因为SceneCode的代码在生成时就把颜色、材质、风格等属性直接写进了构建逻辑，而不是从图库里找一个"差不多像"的替代品。

在物理合理性方面，SceneCode的碰撞率（家具之间互相重叠的比例）约为11%，相比其他三个系统的18%到21%低了将近一半。家具跑出房间边界的比例也不到0.5%，同样是四个系统里最低的。导航连通性（房间里的空地是不是连成一片、不会被家具切割成孤立区域）达到了接近100%的满分。

在用户评价方面，研究团队邀请了九名参与者分成三组，每组对比SceneCode和一个特定的基准系统，评估房间是否忠实于原始文字描述。结果显示，SceneCode比LayoutVLM被评价更好的频率高出约24.6个百分点，比HSM高出约13.2个百分点，比最强的对手SceneSmith也高出约2.8个百分点。在照片写实程度方面，SceneCode略输于SceneSmith——这是意料之中的，因为SceneSmith的图像生成部分可以调用更精细的照片级纹理，而SceneCode优先保证的是结构的可操作性而非视觉的逼真度。

在单件家具质量方面，SceneCode与另一个用图像生成3D模型的系统SAM 3D Objects进行了对比。结果显示，SceneCode生成的家具平均只有约22个UV岛（UV岛可以理解为3D模型表面纹理贴图的"布片"数量，布片越少代表贴图越整洁、越容易编辑），而SAM 3D Objects平均约有96个，是SceneCode的四倍多。面数减少了约一半，顶点数也随之减少，让模型更轻量。最重要的是，SceneCode生成的模型零非流形边（非流形边是一种网格拓扑错误，会导致物理仿真引擎无法正确处理），而SAM 3D Objects仍存在这类问题。

在实际机器人操作测试中，研究团队把SceneCode生成的关节家具导入MuJoCo物理引擎，让机械臂去推柜门、拉抽屉。实验结果显示，活动部件确实保持了独立的连杆结构和可执行的关节，机械臂能够完成接触式的物理交互操作。

---

**七、代码作为家具表示带来的额外好处：可编辑性和按需生成**

除了以上在数字指标上体现出来的优势，用程序表示家具还带来了两个特别实用的附带好处。

第一个好处是参数级的可编辑性。以一棵盆栽程序为例，只需修改程序里的两个参数——叶片数量和叶面细分程度——就能得到从简洁的4片大叶到茂密的16片细叶的一系列变体，而且每个变体都有完整的UV贴图和材质信息，可以直接用于渲染和仿真。这种修改方式不需要重新生成参考图、不需要重新运行整个流程，只需改几个数字重新执行一段代码，几秒钟就能出结果。相比之下，如果你手头是一个图像生成出来的"实心泥巴"模型，想要做同样的改动，要么只能重新生成，要么只能手动用3D建模软件一点点雕刻，门槛高、时间长。

第二个好处是突破了关节家具的数据库瓶颈。现有的关节家具数据库里有什么，检索式系统就只能给你什么。你想要一个带玻璃门的酒柜？数据库里刚好有，那就给你这个。但如果你想要一个核桃木外框、左侧一扇玻璃铰链门、右侧两个抽屉的特定组合，而这个组合在数据库里不存在，检索式系统只能给你一个"最接近的"替代品，凑合用。SceneCode不受这个限制，因为它不从数据库里选家具，它直接根据描述生成家具程序，然后执行程序得到家具。只要你能描述清楚，就能得到对应的家具，包括那些在任何现有数据库里都从未出现过的款式。

---

**八、这项研究的边界和未来可以去的方向**

研究团队坦诚地指出了SceneCode目前的几个局限。

运行时间和成本是最直接的问题。根据实验数据，生成一个房间场景平均耗时约7小时26分钟，最长的一次接近16小时40分钟，最短的也要2小时多。API调用成本平均每个场景约21.73美元，其中家具生成部分占约61%，房间规划的智能体部分占约39%。这对于研究验证来说是可接受的，但距离普通用户能够随时使用还有相当的距离。研究团队认为，通过并行化家具生成流程和训练专门针对3D资产构建的代码生成模型，这个问题在未来是可以大幅改善的。

视觉写实度方面，纯粹基于几何基元（方块、圆柱、球体等）构建的程序化家具，在细节纹理和材质的照片写实程度上，确实不如图像生成或从真实扫描数据中提取的模型。用户研究中SceneCode略输SceneSmith的那一分劣势，根源就在这里。研究团队建议未来可以在保持程序结构可编辑的前提下，叠加神经网络纹理合成或材质精化技术来弥补这一短板。

场景范围方面，当前系统专注于室内家居环境，这类环境有清晰的建筑先验（地板、墙、天花板）和强烈的功能约束（支撑面、可及性、导航通道）。把同样的纯代码驱动范式延伸到户外或大规模混合环境，面临地形不规则、植被有机形态、气候和光照效果复杂等一系列新挑战，需要在当前管线之上引入额外的程序化生成先验和验证策略。

---

归根结底，SceneCode做的事情可以用一句话来概括：它把"生成一件家具"这件事，从"交给你一张照片"变成了"给你一份可以随时执行和修改的建造说明书"。这个转变看起来只是换了一种存储方式，实际上带来的是一连串实质性的能力升级：家具可以被修改，活动部件可以被真正操作，机器人可以在里面学习如何开门拉抽屉，整个场景可以在不重建的前提下局部调整。

对于正在思考如何让AI生成的虚拟世界真正对机器人有用、对具身智能研究有用的人来说，这种从"画图"到"编程"的思路转变，或许比任何单一的技术指标提升都更值得关注。有兴趣深入了解的读者，可以通过arXiv编号2605.19587查阅完整论文，或访问项目主页scene-code.github.io获取更多可视化演示材料。

---

Q&A

Q1：SceneCode生成的室内场景和普通AI绘图生成的3D场景有什么本质区别？

A：普通AI图像转3D生成的是一块"实心泥巴"——看起来像家具，但没有内部结构、没有活动部件、没有可以修改的参数。SceneCode生成的是一段可执行的Blender Python程序，每个零件都是独立的，抽屉能真正滑动，柜门能真正开合，程序里的参数可以修改后重新执行得到不同款式。这个区别直接决定了生成的资产能不能用于机器人操作训练。

Q2：SceneCode生成的带抽屉柜子能直接导入游戏引擎或机器人仿真软件使用吗？

A：可以。SceneCode会把生成的关节家具导出为SDF格式，这是Gazebo、MuJoCo等主流物理仿真平台通用的文件格式。论文中已验证机械臂能在MuJoCo中真正推开SceneCode生成的柜门和拉出抽屉，关节参数（铰链轴向、运动范围、摩擦力等）都被正确保留。

Q3：SceneCode生成一个完整房间需要多长时间，普通人能用吗？

A：目前生成一个房间场景平均耗时约7个半小时，API费用约21美元，最长可能接近17小时。这个速度和成本对普通消费者来说还远不实用，目前主要面向具身智能和机器人领域的研究者。研究团队认为通过并行处理和专用代码生成模型可以大幅提速，但何时能达到普通人随时可用的程度，目前还没有明确时间表。