HDSL：结构化3D场景生成语言，让LLM精准构建可编辑的3D世界

1. 从“一句话”到“一个世界”：为什么我们需要HDSL这样的结构化3D场景生成语言

最近在折腾一个智能家居的3D可视化项目，想把家里的布局、家具摆放都数字化，方便后续做智能联动和空间规划。一开始，我天真地以为这事儿很简单：找个3D建模软件，或者用Unity、Blender的脚本，让大语言模型（LLM）写点代码不就搞定了？结果现实给我上了一课。我让LLM生成一个“温馨的客厅，中间有沙发，对面是电视柜，旁边有绿植”，它确实能给我一段代码，可能是Three.js的，也可能是Unity C#的。但问题来了：这段代码生成的沙发，尺寸是随机的，可能塞不进我预留的位置；电视柜和沙发的位置关系是“对面”，但具体距离多少？朝向如何？绿植的品种、花盆样式更是五花八门。更头疼的是，我想微调一下，比如“把沙发换成L型的，颜色改成深灰色”，LLM要么生成一段全新的、与之前场景毫无关联的代码，要么干脆理解错，把整个客厅布局都改了。

这其实就是当前用LLM直接生成3D内容的核心痛点：缺乏结构化的、可编程的语义约束。LLM擅长理解和生成自然语言，但自然语言是模糊的、非结构化的。当它面对3D场景这种高度结构化、参数化、且各元素间存在复杂空间与逻辑关系的领域时，直接输出代码就像让一个文学家用汇编语言写操作系统——方向对了，但工具和表达方式错位得厉害。

这就是HDSL（Hierarchical Domain-Specific Language，分层领域特定语言）出现的背景。它不是一个具体的软件或SDK，而是一种设计思想和方法论，旨在为特定领域（这里是3D室内场景）创建一套专用的、结构化的描述语言。简单说，HDSL就是给LLM和3D世界之间架起的一座“标准化桥梁”。LLM不再需要直接编写复杂的图形API代码，而是用HDSL这种更接近自然语言逻辑、但又具备严格结构的“高级指令”来描述场景。一个后端系统（或代理，Agent）再将这些HDSL指令编译、解释成底层的3D引擎代码或资产调用。

为什么非得是“分层”的？想象一下描述一个家：你会先说“这是一个两室一厅的公寓”（顶层，场景级）；然后说“客厅里有一套沙发、一个茶几、一台电视”（房间级，容器）；接着描述“沙发是三人位、布艺、深灰色、长2.1米”（物体级，属性）；最后可能还会说“茶几在沙发正前方0.5米处”（关系级，约束）。这种从宏观到微观、从容器到内容、从物体到属性的层次结构，正是人类组织复杂空间信息的自然方式。HDSL将这种层次结构形式化、代码化，使得场景描述既易于人类（和LLM）理解，又便于机器精确执行和后续编辑。

2. HDSL的核心设计哲学：像搭积木一样构建和编辑3D场景

理解了HDSL的动机，我们再来拆解它的核心设计。一个好的HDSL，尤其是用于3D室内场景的，我认为必须解决以下几个关键问题，这也是我踩过坑后总结的经验。

2.1 语义的精确性与可计算性

自然语言说“一个大沙发”，HDSL必须能将其映射为具体的、可计算的参数。这需要预先定义好一个丰富的本体（Ontology）库。这个库不仅仅是物体名称的列表（如“沙发”、“桌子”），而是一个包含分类、属性、参数范围、默认值甚至行为逻辑的知识图谱。

例如，在HDSL的本体库中，“沙发”可能是一个父类，其下可以有“双人沙发”、“三人沙发”、“L型沙发”、“沙发床”等子类。每个子类都定义了一系列属性：

• 几何属性：长、宽、高、座位深度、扶手高度。这些不是随意值，而是有合理范围（如三人沙发长度通常在1.8m-2.4m之间）。
• 材质属性：表面材质类型（布艺、皮质、木质框架）、颜色（支持RGB或材质贴图URI）、纹理。
• 功能属性：是否可展开成床、是否有储物功能。
• 连接点（Anchor Points）：定义物体上可用于对齐或放置其他物体的关键点，如“沙发靠背顶部中心”、“沙发坐垫前缘中心”、“左侧扶手末端”。这对于后续的局部编辑至关重要。

当LLM说“放一个L型沙发”时，它实际调用的是HDSL中Furniture.Sofa.LShaped这个类，并可能附带一些属性覆盖，如{“material”: “fabric”， “color”: “#333333”}。HDSL解析器收到指令后，会从资产库中找到一个符合该类和属性的3D模型实例，或者根据参数程序化生成一个基础模型。

实操心得：本体库的构建是基石。在个人或小团队项目中，不要试图一开始就构建一个完美的、覆盖所有家具的本体库。应该采用“最小可行产品（MVP）”思路，先定义你项目中最核心的10-20类物体，把它们的必需属性（尺寸、关键锚点）定义清楚。后续再随着需求扩展。可以使用JSON Schema或Protobuf来定义这个结构，便于序列化和校验。

2.2 空间关系的形式化表达

“电视在沙发对面”、“茶几在沙发前面”、“画挂在墙上”。这些日常描述在3D空间中需要被转化为精确的数学关系。HDSL需要提供一套丰富的空间关系运算符。

• 绝对定位：at(x, y, z)，rotate(yaw, pitch, roll)。用于精确放置物体，但不够灵活。
• 相对定位（核心）：这是实现“局部化编辑”的关键。例如：
  • place(table).inFrontOf(sofa, distance=0.5)：将桌子放置在沙发前方0.5米处。“前方”需要根据沙发的局部坐标系来判定。
  • attach(painting).to(wall).align(“center”, “top”, offsetZ=1.6)：将画挂到墙上，水平居中，顶部对齐，离地1.6米。
  • arrange(chair1, chair2, chair3, chair4).around(table).facing(table)：将四把椅子围绕桌子摆放，并全部朝向桌子。
• 约束条件：fitsIn(room)（物体必须完全在房间边界内）、faces(window)（物体朝向窗户）、avoidCollisionWith(allOtherObjects)（避免与其他所有物体碰撞）。

这些关系在HDSL中通常被表达为一种声明式的约束。系统（或求解器）的任务是找到满足所有约束的物体位置和旋转。这比直接指定坐标要强大得多，因为它保持了场景的“语义灵活性”。当移动沙发时，系统能自动根据“茶几在沙发前0.5米”这个约束，重新计算茶几的位置。

2.3 分层结构与继承机制

HDSL的“分层”不仅体现在场景-房间-物体的容器关系上，也体现在属性的继承和覆盖上。这能极大减少指令的冗余。

假设我定义了一个客厅场景模板：

{ “sceneType”: “LivingRoom”, “defaults”: { “wallColor”: “#FFFFFF”, “floorMaterial”: “wood_parquet”, “lighting”: “warm” }, “regions”: [ { “id”: “seatingArea”, “type”: “Region”, “defaults”: { “function”: “relax” } } ] }

然后，我在这个模板下添加一个沙发：

{ “add”: { “type”: “Furniture.Sofa.ThreeSeater”, “id”: “mainSofa”, “region”: “seatingArea”, “overrides”: { “material”: “leather” } } }

这个沙发会自动继承seatingArea的function: relax属性，以及场景级的lighting: warm光照环境。同时，我用overrides单独指定了它的材质为皮革，覆盖了可能存在的默认值。

这种机制让LLM的指令可以非常简洁：“在客厅的休息区，放一个皮质三人沙发”。HDSL解析器能根据上下文（当前在编辑LivingRoom场景的seatingArea区域）自动补全所有继承来的信息。

3. LLM Agent如何与HDSL协同工作：从自然语言到结构化指令的翻译官

LLM在这里扮演的角色不是“3D程序员”，而是“需求分析师”和“HDSL代码生成器”。一个典型的LLM Agent与HDSL协同的工作流如下，这也是我在项目中尝试实现的架构：

3.1 指令解析与意图识别

用户输入：“我想重新布置一下书房，把书桌放在窗边，要一个带书架的大书桌，椅子要人体工学椅，颜色整体偏原木风。”

LLM Agent的工作：

1. 场景定位：识别出目标场景是“书房”（对应HDSL中的Scene.Study类型或一个已存在的sceneId）。
2. 操作识别：识别出这是一个“重新布置”操作，可能意味着清除原有布局或在其基础上修改。核心动作是“添加”（书桌、椅子）和“移动”（书桌到窗边）。
3. 物体与属性抽取：
   • 物体1：书桌。属性：带书架（暗示类型是Desk.WithBookshelf）、大（尺寸属性，可能需要从本体库中匹配或指定size: large）、原木风（材质颜色，如material: wood, color: #DEB887）。
   • 物体2：椅子。属性：人体工学椅（类型Chair.Ergonomic）、原木风（可能指扶手或框架材质）。
4. 空间关系抽取：“书桌放在窗边” -> 空间关系place(desk).beside(window)或place(desk).facing(window)，需要进一步明确。“窗边”是一个模糊区域，可能需要将其解析为“靠近命名为‘window1’的墙体模型”。

3.2 HDSL指令生成

基于以上分析，LLM Agent需要调用其“HDSL编写”能力。它内部应该有一个HDSL语法模板和上下文（当前场景的状态）。它生成的可能不是最终可执行的代码，而是一种中间表示（IR），例如：

{ “action”: “modifyScene”, “sceneId”: “my_study”, “steps”: [ { “type”: “clearRegion”, “region”: “center” // 假设原来书桌在房间中心区域 }, { “type”: “addObject”, “object”: { “class”: “Furniture.Desk.WithBookshelf”, “id”: “new_desk_1”, “properties”: { “size”: “large”, “primaryMaterial”: {“type”: “wood”， “color”: “#DEB887”} } }, “constraints”: [ {“type”: “proximity”， “to”: “window_wall”， “maxDistance”: 1.0}, {“type”: “alignment”， “with”: “window_wall”， “face”: “towards”} ] }, { “type”: “addObject”, “object”: { “class”: “Furniture.Chair.Ergonomic”, “id”: “new_chair_1”, “properties”: { “frameMaterial”: {“type”: “wood”， “color”: “#DEB887”} } }, “constraints”: [ {“type”: “relativePlacement”， “to”: “new_desk_1”， “relation”: “inFrontOf”， “distance”: {“min”: 0.4， “max”: 0.5}}, {“type”: “alignment”， “with”: “new_desk_1”， “face”: “towards”} ] } ] }

注意事项：LLM的幻觉与约束。LLM可能会生成HDSL中不存在的物体类（如“带鱼缸的书桌”）或无效的属性值。因此，在Agent生成HDSL后，必须有一个验证阶段。这个验证器需要对照HDSL的本体库和模式（Schema）检查指令的有效性。对于无效部分，可以反馈给LLM进行修正，或者由系统提供默认备选方案。

3.3 场景更新与冲突解决

HDSL指令被提交给一个场景管理引擎。这个引擎负责：

1. 解释指令：将HDSL的声明式约束转化为具体的3D引擎操作（实例化模型、设置变换矩阵）。
2. 解决约束：上述指令中，书桌要“靠近窗墙”且“朝向窗墙”，椅子要“在书桌前0.4-0.5米”且“朝向书桌”。引擎可能需要调用一个简单的约束求解器，为这些物体计算出一组合适的位置和旋转。如果无解（比如要求的大书桌在窗边放不下），则需要将错误（如“空间不足”）反馈给用户或LLM Agent。
3. 更新场景图：将新添加或修改的物体加入到场景的层次化数据结构中，并建立父子或引用关系。
4. 触发渲染：通知3D渲染引擎更新画面。

4. “局部化编辑”的实现：HDSL如何让修改变得精准而简单

“局部化编辑”是HDSL结合LLM后最亮眼的功能之一，也是区别于传统“推倒重来”式生成的关键。它指的是用户或Agent可以对已生成场景的某个特定部分进行修改，而不会影响其他无关部分。这依赖于HDSL对场景的显式、结构化表示。

4.1 基于唯一标识符（ID）的精准引用

在HDSL生成的场景中，每一个物体、灯光、区域都应该有一个唯一的id。当需要编辑时，指令直接针对这个id。

例如，初始场景中有一个id为“sofa_001”的沙发。用户后续指令：“把那个灰色的沙发换成蓝色的。”

• 没有HDSL：LLM需要重新理解整个场景，识别出“灰色的沙发”是哪一个，然后重新生成整个客厅的代码，风险极高。
• 有HDSL：LLM Agent可以将指令转化为：updateObject(id: “sofa_001”， properties: {color: “blue”})。引擎只修改sofa_001的颜色属性，场景中其他物体纹丝不动。

4.2 利用层次结构进行范围限定

编辑指令可以限定在某个层次范围内。比如：“把客厅里所有椅子的材质都换成胡桃木。” 对应的HDSL指令可能是：

{ “action”: “batchUpdate”, “scope”: { “sceneId”: “living_room”, “filter”: {“class”: “Furniture.Chair.*”} }, “update”: { “primaryMaterial”: {“type”: “wood”， “name”: “walnut”} } }

这个scope指定了操作范围是“living_room”场景下，所有类名匹配Furniture.Chair.*的物体。引擎会遍历场景图，找到所有符合条件的椅子进行批量更新，而不会影响到卧室的椅子或客厅的桌子。

4.3 保持关联约束的“智能”更新

这是局部化编辑更高级的形式。假设初始场景有约束：“茶几在沙发正前方0.5米”。当我们用指令moveObject(id: “sofa_001”， newPosition: [x, y, z])移动沙发时，一个“笨”的系统只会移动沙发，茶几留在原地，约束被破坏。

一个集成了HDSL的智能引擎应该能做到：

1. 执行移动沙发的指令。
2. 检测到与“sofa_001”相关的空间约束（如“coffee_table_001”的位置依赖于它）。
3. 自动重新求解这些约束，计算出“coffee_table_001”的新位置，并更新它。
4. 如果重新求解失败（例如新位置导致茶几穿墙），则向用户报告约束冲突，而不是静默破坏场景逻辑。

这就实现了“牵一发而动全身”的智能联动，保持了场景的内在一致性。要实现这个，需要在HDSL中显式地定义和存储这些约束关系，而不仅仅是生成最终位置。

5. 实战构想：搭建一个简易的HDSL驱动3D场景编辑器原型

理论说了这么多，我们来构想一个最小化的实战项目，看看如何将HDSL的思想落地。这个原型将包含以下几个核心模块：

5.1 定义HDSL模式（Schema）

首先，我们需要用JSON Schema来定义我们的HDSL语言结构。这是最核心的“合约”。

schema/scene.schema.json(片段):

{ “$schema”: “http://json-schema.org/draft-07/schema#”, “title”: “室内场景描述”, “type”: “object”, “properties”: { “meta”: {“$ref”: “#/definitions/Meta”}, “settings”: {“$ref”: “#/definitions/SceneSettings”}, “rooms”: { “type”: “array”, “items”: {“$ref”: “#/definitions/Room”} } }, “definitions”: { “Meta”: { “type”: “object”, “properties”: { “version”: {“type”: “string”}, “generator”: {“type”: “string”} } }, “SceneSettings”: { “type”: “object”, “properties”: { “units”: {“type”: “string”， “enum”: [“meters”， “centimeters”]}, “upAxis”: {“type”: “string”， “enum”: [“Y”， “Z”]， “default”: “Y”} } }, “Room”: { “type”: “object”, “properties”: { “id”: {“type”: “string”}, “type”: {“type”: “string”， “enum”: [“LivingRoom”， “Bedroom”， “Study”， “Kitchen”]}, “bounds”: {“$ref”: “#/definitions/BoundingBox”}, “objects”: { “type”: “array”, “items”: {“$ref”: “#/definitions/SceneObject”} } }, “required”: [“id”， “type”， “bounds”] }, “SceneObject”: { “type”: “object”, “properties”: { “id”: {“type”: “string”}, “class”: {“type”: “string”}, // 如 “Furniture.Sofa.ThreeSeater” “assetId”: {“type”: “string”}, // 对应3D模型库中的ID “position”: {“$ref”: “#/definitions/Vector3”}, “rotation”: {“$ref”: “#/definitions/Euler”}, “scale”: {“$ref”: “#/definitions/Vector3”}, “properties”: {“type”: “object”} // 扩展属性，如 {“color”: “#FF0000”， “material”: “fabric”} }, “required”: [“id”， “class”] }, “BoundingBox”: { … }, “Vector3”: { … }, “Euler”: { … } } }

5.2 构建本体（Ontology）库

这是一个将class字符串映射到具体参数和资产的知识库。可以用一个JSON文件或数据库来管理。

ontology/furniture.json:

{ “Furniture”: { “Sofa”: { “ThreeSeater”: { “displayName”: “三人沙发”, “defaultDimensions”: {“length”: 2.1， “width”: 0.9， “height”: 0.85}, “assetVariants”: [“sofa_modern_01”， “sofa_classic_02”], “anchorPoints”: { “frontCenter”: {“localOffset”: [0, 0, -0.45]}, “seatCenter”: {“localOffset”: [0, 0.4, 0]} }, “editableProperties”: { “material”: {“type”: “string”， “options”: [“fabric”， “leather”]}, “color”: {“type”: “color”} } }, “LShaped”: { … } }, “Desk”: { … } } }

5.3 实现LLM Agent指令转换器

这里我们需要为LLM（例如通过OpenAI API调用GPT-4）设计一个有效的提示词（Prompt），让它学会将自然语言转换为我们的HDSL JSON。

System Prompt:

你是一个专业的室内场景HDSL（分层领域特定语言）生成器。你的任务是将用户的自然语言描述，转换为结构化的HDSL JSON指令。 HDSL Schema概要： - 场景(Scene)包含多个房间(Room)。 - 房间有id、类型（如LivingRoom）和边界(bounds)。 - 房间内包含对象(SceneObject)。对象有id、类(class)、位置(position)、旋转(rotation)、属性(properties)等。 - 类(class)的格式为“类别.子类.具体类型”，例如“Furniture.Sofa.ThreeSeater”。 可用物体类参考（来自本体库）： - Furniture.Sofa.ThreeSeater (三人沙发) - Furniture.Sofa.LShaped (L型沙发) - Furniture.Table.Coffee (茶几) - Furniture.Desk.WithBookshelf (带书架书桌) - Furniture.Chair.Ergonomic (人体工学椅) - Lighting.Ceiling.Pendant (吊灯) - Decor.Plant.Ficus (盆栽榕树) 空间关系关键词： - inFrontOf (在前方)， behind (在后方)， leftOf (在左侧)， rightOf (在右侧) - beside/nextTo (在旁边) - facing (朝向) - onTopOf (在上面) - attachedTo (附着于) 请根据用户请求，生成一个合法的HDSL JSON对象，描述要执行的操作（如addObject, updateObject, batchUpdate）。只输出JSON，不要额外解释。

User Input:“在客厅中央放一个L型沙发，前面放一个茶几，旁边放一盆绿植。”

LLM Output (理想情况下):

{ “action”: “addObjects”, “targetRoom”: “living_room”, “objects”: [ { “id”: “sofa_1”, “class”: “Furniture.Sofa.LShaped”, “position”: {“x”: 0， “y”: 0， “z”: 0}, “rotation”: {“y”: 0}, “properties”: {} }, { “id”: “table_1”, “class”: “Furniture.Table.Coffee”, “constraints”: [ {“type”: “relative”， “to”: “sofa_1”， “relation”: “inFrontOf”， “distance”: 0.5} ] }, { “id”: “plant_1”, “class”: “Decor.Plant.Ficus”, “constraints”: [ {“type”: “relative”， “to”: “sofa_1”， “relation”: “rightOf”， “distance”: 0.3} ] } ] }

在实际中，LLM的输出可能需要一个后处理模块来校验和修正，比如确保id唯一、补充默认位置等。

5.4 开发场景引擎与约束求解器

这是最复杂的部分，但原型可以简化。我们可以用Three.js作为3D渲染引擎。

1. 场景状态管理：维护一个内存中的场景图，其数据结构与HDSL Schema对应。
2. 指令解释器：解析HDSL JSON指令。对于addObject，根据class从本体库找到assetId，加载对应的3D模型（GLTF）。对于有constraints的对象，先不设置绝对位置，将其加入“待求解队列”。
3. 简易约束求解：实现一个简单的求解器。对于“relative”约束，根据参考物体的位置、旋转和指定的关系（如inFrontOf）、距离，计算目标物体的目标位置。这个求解器可以按顺序处理队列，也可以迭代几次以达到近似解。
4. 冲突检测与处理：在放置物体后，进行简单的AABB（轴对齐包围盒）碰撞检测。如果发生碰撞，可以尝试微调位置，或者将冲突信息记录并反馈。
5. 局部更新：当收到updateObject指令时，根据id找到场景图中的对应物体，更新其材质、颜色或变换属性，并触发Three.js场景更新。

5.5 实现编辑与回退功能

为了支持局部化编辑，引擎需要记录完整的HDSL指令历史。每次修改（无论是LLM生成还是用户直接操作）都对应一条HDSL指令。这允许我们：

• 撤销/重做：简单地回退或重放指令历史。
• 持久化：将当前的HDSL指令序列保存为文件，即可完整保存场景状态，文件体积远小于保存整个3D场景的二进制数据。
• 指令补丁：后续的编辑指令可以基于最新的场景状态进行计算，实现真正的增量更新。

6. 挑战、局限与未来展望

在实际尝试将HDSL思想应用于项目后，我深刻体会到几个绕不开的挑战，这也是未来值得深入的方向。

6.1 本体库的构建与维护成本

一个实用的系统需要庞大且高质量的本体库。这不仅仅是3D模型资产，更是对每个物体类别的语义、属性、参数、行为逻辑的精确描述。构建这样的库工作量巨大，且需要领域专家（如室内设计师）参与。可能的解决方案是：

• 社区共建：建立开放的本体库标准，鼓励社区贡献。
• 从数据中学习：利用大量的3D场景数据集（如3D-FRONT、ScanNet）进行自动化或半自动化的本体提取。
• LLM辅助标注：用LLM来分析和总结现有3D模型的元数据，生成初步的本体描述。

6.2 复杂空间约束的求解

“把餐桌放在厨房和客厅之间的开放区域，周围放六把椅子，椅子要方便进出且不挡路。”这样的指令包含了复杂的空间、功能和语义约束。当前的简易求解器可能无法处理。需要引入更强大的几何约束求解器（CSP）甚至物理模拟，来找到符合人体工学、动线合理的布局。这涉及到计算几何和优化算法，复杂度很高。

6.3 LLM的可靠性问题

LLM在理解复杂空间关系和生成精确HDSL时仍会出错。它可能混淆“左边”和“右边”（基于观察者视角还是物体自身视角？），也可能生成不合逻辑的约束组合。因此，人机协同的编辑界面至关重要。系统应该将LLM生成的HDSL指令以可视化的方式呈现（例如，高亮即将被修改的物体，用线框预览新物体的位置），让用户进行最终确认或微调。同时，系统需要提供强大的错误反馈和指令修正机制。

6.4 从静态场景到动态交互

目前的HDSL主要描述静态场景。未来的方向是扩展其语义，以支持动态行为和交互。例如，描述“这是一扇可以打开的门”、“这是一个可以调节亮度的灯”、“当人走近时，电视自动打开”。这需要将HDSL与行为树、状态机或事件系统相结合，定义物体之间的交互逻辑，从而生成真正“活”的、可交互的3D场景。

尽管有这些挑战，HDSL与LLM Agent结合的方向，为3D内容创作提供了革命性的思路。它降低了专业3D工具的使用门槛，让创意更直接地转化为可视化的成果。对于室内设计、游戏关卡原型设计、虚拟展厅搭建等领域，这种技术能极大提升构思和迭代的效率。从我个人的实践来看，即使从一个非常简陋的原型开始，沿着这个思路去构建工具，也能深刻感受到结构化描述语言带来的清晰度和可控性，这远比直接让LLM“黑盒”式生成代码要可靠和实用得多。