用聊天编辑一个 3D 房间：AI 平面图编辑器是怎么运作的
「对话式编辑」听起来像是在一个 3D 工具之上加了一层界面便利——打几个字， 而不用在菜单里点来点去。但底层实际发生的事情比这具体得多， 理解它，既能解释一次对话编辑能可靠做到什么，也能解释它在哪些地方依然需要人。
从一张扁平上传图到可编辑场景图
起点是一张 2D 平面图图片——线条、尺寸、门的开合方向， 一个 3D 工具没法直接对它做任何操作。一个视觉语言模型读取这张图片 并提取结构：墙体位置、开口、房间边界。这套结构会被搭建成实际的 3D 几何结构——具有真实高度和厚度、位置与尺寸都正确的墙体—— 再由真实目录把家具摆进去。结果是一张场景图：墙体、家具、材质 作为各自独立、可寻址的对象，而不是一个被压平的模型。 这也正是聊天面板开始变得有用的地方——从这一步开始， 接下来发生的一切，都是要求模型针对一个它已经能够读取的场景来描述改动。
「已经能够读取」这一点比听起来更重要。一句「把沙发挪近窗户」的对话请求， 之所以能被解析成一个具体动作，正是因为模型面对的是一个结构化场景—— 一个具体的沙发对象，一个具体的窗户位置，两者都可寻址。 同样一句话打在一块没有场景背景的空白画布上，不会有任何可执行的意义； 正是场景图，把自然语言变成了确定性引擎真正可以执行的东西。
一次对话编辑在底层究竟改动了什么
不是每一个请求都触碰同一层。材质与家具位置类请求—— 「把主题墙调深一点」「把沙发挪近窗户」——是场景编辑： 它们改变的是哪个对象占据某个位置，或者某个表面引用哪种材质， 完全不触碰底层的墙体或房间几何结构。结构性请求—— 「在最长的墙上加一扇门」「把最小的房间放宽半米」——则确实会改变几何结构： 一个新的开口会被切出来，一面墙会被移动，而这面墙下游的一切 （相邻房间边界、受影响的家具占地）都会针对新布局重新验证。
在这两种情况下，模型的工作都是同一件事：把一句自然语言请求， 翻译成对场景图的一次具体、结构化改动——而不是把房间从头重新生成。 正是这个区别，让一次对话编辑保持快速，也让请求没有触碰到的一切 完全保持原样。这也是为什么一个界定清晰的请求会产出一次小而快的编辑， 而一个含糊的请求要么被拒绝，要么产出一个远比预期更大的结构性改动—— 模型并不是在猜测改动范围，它是在场景图允许的范围内，尽可能字面地翻译这个请求。
保持编辑有效的护栏机制
一次不受约束的编辑很容易产出一个无效的房间——一面墙被移到另一面墙里面， 一扇门被加在一面墙太短、承载不了门洞的地方，家具被推进一块 已经无法通行的空间。验证初次搭建时使用的同一套检查， 适用于每一次编辑：对照空间网格做碰撞检查、墙体与开口约束、 围绕门与通道的净空规则。任何会违反其中一项的编辑都会被拒绝， 而不是被悄悄套用——这些护栏不是一个独立的审核步骤， 而是搭建流程本来就在运行的同一套验证逻辑，在提议的改动被接受之前再运行一次。
这种复用，对一致性的意义不亚于对安全性的意义。如果编辑用的是一套 比初次搭建更宽松的规则来检查，房间就可能逐渐漂移到一个连搭建流程本身 都不可能一开始就产出的状态——一系列微小违规慢慢累积起来， 而没有哪一次编辑单独看起来是「有问题的」。让每一次编辑都经过 搭建所用的同一套验证，能让房间始终处于一个系统可以随时为之担保的状态， 而不只是它最初被搭建出来时的那个状态。
人在哪里依然需要介入
对话式编辑能可靠地处理界定清晰、范围明确的请求。对于界定不清的请求， 它的处理方式是要求澄清，而不是靠猜——一个真正含糊的指示 （比如没有任何具体细节的「让它感觉更高端一点」）， 或者一个和模型自己解决不了的物理约束相冲突的请求， 依然需要一个人来澄清真正想要的是什么，或者直接通过手动工具完成这项修改。 聊天层是一条快速通道，适用于那些具体到足以被翻译成场景编辑的请求， 而不是要取代那些真正需要人类判断力和意图的决定。实际呈现出来的模式， 是一种分工：聊天面板处理一次审阅周期里真正大量产生的、 小而具体、界定明确的改动，而人依然留在流程里， 负责那些真正需要品味或者模型不具备的上下文的、数量更少的决定。
立即开始
想了解这一切所建立在的更早阶段——最初的上传是怎么变成可编辑几何结构的—— 可以参考 如何将 2D 平面图转化为 3D 房间。 想了解这里模型的角色，和其他 AI 驱动的 3D 生成方式相比有什么不同，可以参考 AI 3D 生成模型：究竟是什么在生成 3D 房间。 想全面了解 Flur 在编辑层之外还搭建了什么，可以参考 什么是 Flur？