大语言模型驱动3D建模：自动化实践指南

一、背景：开源三维软件与AI能力的结合

近几年，开源三维创作软件的使用门槛持续降低，社区插件和脚本生态也日渐成熟。大多数三维软件都提供Python或类似的脚本接口，允许程序以代码方式创建对象、修改属性、批量处理资产。这类接口原本服务于技术美术和自动化流水线，如今也成为大语言模型与三维场景之间的天然桥梁。

把模型能力接入三维软件，核心问题并不在于“能不能生成内容”，而在于“能否把模糊的自然语言需求，稳定地转换为软件可以执行、结果可以验证的操作”。一句“做一个带圆角的木质桌子”，背后涉及几何体创建、尺寸单位、材质参数、层级关系等多个决策。直接让模型输出一段任意代码并执行，风险高、可复现性差，也难以排查错误。

因此，工程上更合理的做法是：让模型只负责理解意图并输出受约束的结构化指令，由程序层负责校验、执行和回传状态。

二、系统架构：四层职责划分

一个可落地的系统通常分为四层：

1. 意图理解层：接收用户的自然语言描述，结合当前场景信息，提取目标、约束和优先级。
2. 指令生成层：调用大语言模型，输出符合预定义协议的JSON指令序列。
3. 执行层：在三维软件内部运行，逐条校验指令并调用脚本接口完成操作。
4. 反馈层：采集场景摘要、对象列表或渲染截图，回传给模型用于下一轮迭代。

示意如下：

用户需求 → 意图理解 → 指令生成（JSON） → 校验与白名单过滤 → 脚本执行 → 场景状态回传
                 ↑                                                    │
                 └──────────────────── 迭代修正 ←───────────────────────┘

分层的价值在于每一层都有明确的输入、输出和失败模式。例如，校验失败时可以直接拒绝指令并要求模型重新生成，而不必让错误一路传到三维软件内部。

三、环境准备

在动手之前，建议确认以下事项：

• 软件版本：不同版本的脚本接口在函数名和参数上可能存在差异，应固定版本并在文档中记录。
• 解释器一致性：三维软件内置的Python解释器版本可能与系统Python不同，第三方依赖需要安装到对应环境中。
• 密钥管理：模型服务的访问密钥应通过环境变量或密钥管理服务注入，不写入代码或日志。
• 工作目录：所有自动化操作都应在副本文件上进行，原始工程文件保持只读。

本文示例中的脚本接口统一以 scene_api 表示，实际开发时需替换为你所用软件版本提供的真实接口。

四、指令协议设计

协议设计决定系统的可控性。建议使用固定的动作集合，每个动作只允许预定义的参数类型和取值范围。

ALLOWED_ACTIONS = {
    "create_primitive": {
        "shape": {"cube", "sphere", "cylinder", "plane"},
        "size": float,
        "location": (float, float, float),
    },
    "move_object": {
        "name": str,
        "location": (float, float, float),
    },
    "set_material_color": {
        "name": str,
        "rgba": (float, float, float, float),
    },
    "delete_object": {
        "name": str,
    },
}
DESTRUCTIVE_ACTIONS = {"delete_object"}

协议中有两点需要注意。第一，动作数量应保持有限，每新增一个动作都意味着新的风险面。第二，删除类动作单独标记，后续流程会对其强制确认。

模型输出示例：

{
  "actions": [
    {"action": "create_primitive", "shape": "cube", "size": 2.0, "location": [0, 0, 1]},
    {"action": "set_material_color", "name": "Cube", "rgba": [0.6, 0.4, 0.2, 1.0]}
  ]
}

五、校验与执行

模型输出不可信，必须先校验再执行。校验函数需要检查动作是否在白名单内、参数类型和范围是否合法、对象名称是否存在。

from typing import Any
def validate_action(action: dict[str, Any], scene_objects: set[str]) -> tuple[bool, str]:
    name = action.get("action")
    if name not in ALLOWED_ACTIONS:
        return False, f"未知动作: {name}"
    schema = ALLOWED_ACTIONS[name]
    for key, expected in schema.items():
        if key not in action:
            return False, f"缺少参数: {key}"
    if name == "create_primitive":
        if action["shape"] not in schema["shape"] or action["size"] <= 0:
            return False, "形状或尺寸不合法"
    if name in {"move_object", "set_material_color", "delete_object"}:
        if action["name"] not in scene_objects:
            return False, f"对象不存在: {action['name']}"
    return True, "ok"
def execute_actions(actions: list[dict], scene_objects: set[str], confirm_fn) -> list[str]:
    logs = []
    for act in actions:
        ok, reason = validate_action(act, scene_objects)
        if not ok:
            logs.append(f"拒绝: {reason}")
            continue
        if act["action"] in DESTRUCTIVE_ACTIONS and not confirm_fn(act):
            logs.append(f"用户未确认，跳过: {act}")
            continue
        # 实际调用示例（接口名称需替换为真实版本的API）
        if act["action"] == "create_primitive":
            scene_api.create_primitive(act["shape"], act["size"], act["location"])
            scene_objects.add(f"{act['shape'].capitalize()}")
        elif act["action"] == "move_object":
            scene_api.set_location(act["name"], act["location"])
        elif act["action"] == "set_material_color":
            scene_api.set_color(act["name"], act["rgba"])
        elif act["action"] == "delete_object":
            scene_api.remove(act["name"])
            scene_objects.discard(act["name"])
        logs.append(f"执行成功: {act['action']}")
    return logs

这段代码体现了三个原则：未知指令直接拒绝；删除动作需要人工确认；每条操作都留下日志，便于回溯。

六、调用模型并闭环迭代

调用模型时，提示词中应包含三类信息：协议定义、当前场景摘要和用户需求。场景摘要不必传完整几何数据，只需对象名称、类型、位置和层级关系即可。

def build_prompt(user_request: str, scene_summary: str) -> str:
    return (
        "你是三维场景指令生成器。只能输出符合协议的JSON，"
        "不得输出任何解释性文字。\n"
        f"当前场景：\n{scene_summary}\n"
        f"用户需求：\n{user_request}\n"
    )

闭环迭代的关键在于反馈。每轮执行结束后，系统把执行日志和更新后的场景摘要再次送入模型，让其判断是否还需要补充操作。设置最大迭代轮数（例如3到5轮），可以防止模型陷入无效循环。

七、安全与可控性

自动化控制三维软件时，安全问题容易被忽视，主要包括以下几点：

• 输入即数据：场景中的对象名、文件描述或注释可能包含类似指令的文字，应作为普通数据处理，不得直接拼入“系统指令”。
• 最小权限：脚本运行环境只开放必要接口，禁止执行任意系统命令或读写工程目录之外的文件。
• 可撤销性：执行前自动保存一份版本快照，出现异常时可以回滚到快照。
• 审计日志：记录每次请求的用户、时间、指令内容和执行结果，日志存放在独立的日志服务中，便于追溯。
• 资源限制：对单次任务的对象数量、面数和渲染时长设置上限，防止生成过程占满计算资源。

如果系统需要部署在云端，资产文件可以放在对象存储中，任务排队交给消息队列，批量渲染交给容器平台调度，并由监控告警覆盖失败任务。这些都是通用的基础设施类目，选型时应依据团队已有技术栈决定。

八、常见问题与优化思路

1. 单位与尺度不一致。 模型常混用米、厘米和任意单位。解决办法是在提示词中明确统一单位，并在校验层对尺寸参数做范围检查。

2. 对象命名冲突。 脚本接口创建对象时可能自动重命名，导致后续操作找不到目标。建议执行层返回实际对象名，并由系统维护名称映射表。

3. 需求歧义。 用户说“换个颜色”时，模型可能不知道指的是哪个对象。系统应设计澄清机制：模型输出 ask_user 类型的响应，由前端展示选项，而不是强行猜测。

4. 响应延迟。 模型调用通常是整个流程中耗时最长的部分。可以把场景摘要缓存、对简单指令使用规则解析直接处理，只在复杂需求时调用模型。

5. 结果质量不稳定。 模型生成的造型和比例往往需要人工微调。更务实的定位是让它完成批量、重复、结构明确的工作，美术判断和最终审校仍由人完成。

九、适用场景与边界

这一方案较适合以下场景：批量生成基础几何体、按规则调整大量对象属性、教学环境中的交互式建模练习、快速验证场景原型。

它的边界也很清楚。模型对空间关系的理解有限，复杂有机造型、精细拓扑和风格化表现仍然依赖专业美术。协议越严格，系统越安全，但能力范围也越窄。团队应根据任务风险和收益，逐步扩展动作集合，而不是一次开放全部权限。

十、落地建议

1. 先从只读查询类功能开始，例如场景统计和对象检查，验证链路稳定性。
2. 再开放低风险的创建与属性修改动作，并保留完整的撤销能力。
3. 最后评估删除、导出和批量替换等高风险功能，配合人工确认和审计。
4. 每次迭代都用固定的测试场景集回归，记录模型输出的通过率，用数据判断改进是否有效。

按照以上步骤，团队可以在可控范围内把大语言模型的理解能力接入三维创作流程，让它承担重复性和结构化的工作，同时保留人对质量和风险的最终判断。