港中大联合多校研发AI模块化房间构建与机器人动态交互技术

近期，一项由香港中文大学、上海交通大学、上海人工智能实验室、微软研究院及牛津大学联合完成的研究成果，以预印本形式发布于arXiv平台。该研究突破性地提出了一种全新方案，旨在让AI生成的虚拟房间不再停留于“视觉观赏”层面，而是具备真实的可交互性与物理合理性。

无论是体验过《模拟人生》等模拟游戏，还是使用过家居设计软件的用户，大多都有这样的感受：你可以自由摆放沙发、床铺和桌子，但它们本质上仍是静态的“图片”——抽屉无法拉开，柜门不能推动，椅子也不能真正坐上去。这种“只能看、不能动”的局限性，正是当前多数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岛（可理解为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生成的虚拟世界真正对机器人有用、对具身智能研究有价值的人们而言，这种从“绘图”到“编程”的思维范式转变，或许比任何单一技术指标的提升都更值得关注。

常见问题解答

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

A：普通AI图像转3D生成的是一个“实心雕塑”——外观像家具，但缺乏内部结构、活动部件和可修改参数。SceneCode生成的是一段可执行的Blender Python程序，每个部件独立，抽屉能真实滑动，柜门能真实开合，程序中的参数修改后可重新执行得到不同款式。这一区别直接决定了生成的资产能否用于机器人操作训练。

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

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

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

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