企业官网建设流程全解析

各位建模师和脚本控应该都有类似的体验：Blender 功能确实强，但入门门槛不低，很多基础操作重复枯燥，尤其是一些“低模 + 参数化”的模型，明明几句话就能描述清楚，却要在界面上点半天。最近越来越多人在讨论一个方向——能不能让 LLM 直接帮我们在 Blender 里建模？所谓 LLM 辅助 3D 建模，本质就是让大语言模型理解你的自然语言描述，生成对应的 Blender Python 脚本或几何节点配置，再交给 Blender 执行，从而把“人写代码”变成“AI 写代码、人审核”。本文会从可行性边界、环境准备、核心原理、完整插件实战、常见报错排查到工程化建议，完整拆解这条落地方案。

文章面向两类读者：一类是会用 Blender 但不太会写 Python 的建模用户，另一类是熟悉 Python / bpy 但想了解怎么把 LLM 接进工作流的开发者。读完你至少能搭出一个“在 Blender 面板里输入一句话，点击按钮生成模型”的可用工具，并知道哪些建模任务适合交给 LLM，哪些必须自己手动完成。

1. LLM 辅助 Blender 建模是什么，解决什么问题

1.1 为什么“LLM + Blender”值得关注

Blender 本身是一个开源且功能完整的 3D 创作套件，覆盖建模、雕刻、材质、动画、渲染、合成等完整管线。它的可编程能力非常强，所有界面操作几乎都能通过bpy这个 Python 模块完成。这一点非常重要，意味着“建模”这件事可以完全代码化。

大语言模型（Large Language Model，LLM）擅长的事情恰恰是“理解自然语言”和“生成代码”。当用户输入一段“生成一张圆形木桌，桌面半径 0.6 米，厚度 0.05 米，四条圆柱腿”的描述时，LLM 可以将其翻译成一段可执行的bpy脚本，Blender 运行这段脚本后就能直接生成对应模型。

所以，LLM 辅助 3D 建模要解决的核心问题不是“替代建模师”，而是把“从想法到基础模型”这一段重复、机械、容易出错的路径缩短。对于概念草图、游戏低模、场景摆件、批量生成地形、快速验证比例这类任务，LLM 的表现已经具备实用价值。

1.2 LLM 辅助建模的三种常见路径

目前社区和工程中比较常见的实现方式有三种。

第一种是“文本生成 bpy 脚本，手动粘贴运行”。用户把需求发给 LLM，拿到脚本后粘贴到 Blender 的 Scripting 工作区执行。这种方案最轻量，不涉及插件开发，也不需要额外写调用代码，适合一次性探索和临时任务。

第二种是“在 Blender 内做插件，自动调用 LLM API”。在 Blender 中注册一个面板，用户输入自然语言描述，点击按钮后插件请求 LLM 服务，拿到返回的 Python 代码后自动在 Blender 中执行。这种方案的自动化程度最高，也是本文实战部分要重点搭建的方案。

第三种是“LLM 生成几何节点配置”。Blender 的 Geometry Nodes 是一种节点化建模方案，用户可以通过节点图生成参数化模型。LLM 可以生成创建节点组的 Python 代码，也可以帮你把已有节点组的参数调整到目标值。这种路径更适合程序化建模，但 API 在不同 Blender 版本之间差异较大，需要额外注意版本兼容问题。

1.3 可行性边界：LLM 能做什么，不能做什么

讨论“靠不靠谱”之前，先明确边界。

LLM 能胜任的任务包括：创建基础几何体（立方体、圆柱、球体、平面）；设置材质和颜色；添加修改器（倒角、细分、阵列、镜像）；生成参数化建筑体块；批量摆放物体；创建基础动画关键帧；写简单的 Blender 插件框架。

LLM 目前做不好的事情包括：生成精细高模；处理需要严格拓扑规划的复杂曲面；理解“这个模型看起来不协调”这类需要视觉反馈的修改；在生成过程中实时感知 Blender 视口的渲染结果。它只能根据文本描述生成静态代码，不能“边看边改”。所以，LLM 更准确的定位是“建模加速器”，而不是“自动建模师”。

2. 环境准备与工具选型

2.1 Blender 版本与 Python 环境

Blender 内置了完整的 Python 解释器，bpy模块只有在 Blender 运行时才可用，这一点和普通 Python 包完全不同。你不能在系统终端里直接import bpy，必须通过 Blender 自己的 Python 环境来执行脚本。

建议使用 Blender 3.6 及以上版本，4.x 系列也可以。不同版本的bpyAPI 有一些差异，尤其是几何节点相关接口，在 3.x 和 4.x 之间变化明显。为了避免兼容性问题，本文核心案例只使用相对稳定的 API，如创建对象、设置位置、添加材质、注册 Panel / Operator 等。

操作系统方面，Windows、macOS、Linux 都可以，但要注意 macOS 通过 GUI 启动 Blender 时，进程环境变量可能与终端不完全一致。如果你用os.environ读取 API Key，可能会读不到，建议优先使用本地配置文件。

2.2 LLM API 的接入选择

LLM 服务商很多，接口格式大同小异。无论你使用哪家服务，核心请求基本都是向一个 Chat Completion 接口发送system和user消息，然后从返回结果中取文本内容。

在选择 LLM 服务时，需要考虑三个因素。

第一是代码生成能力。建模场景需要模型具备较强的代码生成能力，尤其是 Python 代码和 Blender API 知识。通用对话模型也能用，但建议优先选择代码能力更强的模型。

第二是响应速度。如果 API 响应太久，Blender 界面会一直卡在请求状态，体验很差。可以在请求时设置超时时间，也可以考虑使用本地模型。

第三是安全与隐私。如果建模数据涉及项目资产、角色设计稿或内部规范，不建议直接发送到公有云 API。此时可以在本机部署 Ollama 等本地推理框架，把请求地址改为http://localhost:11434/v1/chat/completions，模型使用本地代码模型。这种方式的好处是数据不出本机，但推理速度受显卡性能影响。

2.3 安全边界说明

把 LLM 生成的代码直接放进 Blender 执行，本质上是“让 AI 在你的 Blender 环境里运行任意 Python 代码”。这存在一定的操作风险，比如模型连续执行时误删场景对象、引入不存在的模块、调用危险的文件操作等。因此，在练习和项目落地时都要建立安全习惯：最重要的一条是执行 LLM 返回代码前先备份.blend文件；在生产环境中，建议对生成的代码做关键词过滤，并限制执行命名空间，本文实战部分会给出具体做法。

3. 核心原理：bpy、代码生成与执行链路

3.1 Blender Python API 基础

理解后续代码前，先掌握三个最常用的bpy入口。

bpy.context表示当前上下文，比如当前选中的物体、当前场景、当前视图区域。典型用法是bpy.context.active_object获取当前活动物体。

bpy.data表示 Blender 当前文件中的数据，包括网格、材质、集合、灯光等。例如bpy.data.objects是所有场景对象的集合。

bpy.ops表示操作符调用，相当于把用户在界面上的操作翻译成代码。例如bpy.ops.mesh.primitive_cube_add(size=2)会在场景中创建一个尺寸为 2 的立方体。

一个最基础的 bpy 脚本示例：

import bpy # 清空场景中的默认立方体 bpy.ops.object.select_all(action='SELECT') bpy.ops.object.delete(use_global=False) # 创建一个圆柱体 bpy.ops.mesh.primitive_cylinder_add( radius=0.6, depth=0.05, location=(0, 0, 0) )

这段代码执行后，Blender 场景中会出现一个半径 0.6、高度 0.05 的扁圆柱。理解bpy.ops的参数，是后续判断 LLM 生成代码质量的基础。

3.2 LLM 生成代码的基本链路

LLM 辅助建模的完整链路可以拆成四步。

第一步，用户输入需求文本，比如“创建一个木桌”。第二步，插件把需求文本和一段 System Prompt 一起发送给 LLM 接口。System Prompt 的作用是约束模型行为，让它只输出 Python 代码，不输出解释文字。第三步，LLM 返回一段文本，插件解析出代码部分。第四步，插件在 Blender 中执行这段代码，生成 3D 模型。

为什么推荐使用 System Prompt 而不是完全依赖用户描述？因为 LLM 的输出随机性很强，如果没有强约束，它可能会返回一大段 Markdown 说明，甚至包含与代码无关的内容。在提示词中明确“你只输出 Python 代码，不要包含任何解释”能大幅提高执行成功率。

一个完整的请求伪代码如下：

import json import urllib.request def call_llm(prompt, api_key, base_url, model): headers = { "Content-Type": "application/json", "Authorization": f"Bearer {api_key}" } payload = { "model": model, "messages": [ {"role": "system", "content": "你是一名Blender Python专家，只输出可执行的bpy代码，不要输出解释。"}, {"role": "user", "content": prompt} ], "temperature": 0.2, "max_tokens": 4000 } req = urllib.request.Request( base_url, data=json.dumps(payload).encode("utf-8"), headers=headers, method="POST" ) with urllib.request.urlopen(req, timeout=180) as resp: result = json.loads(resp.read().decode("utf-8")) return result["choices"][0]["message"]["content"].strip()

这里使用urllib.request而不是requests，是因为 Blender 内置 Python 不一定安装了第三方requests库，而urllib是标准库，稳定性更高。当然，如果你的 Blender Python 环境里已经安装了requests，也可以用后者，代码可读性更好。

3.3 为什么选择“生成脚本再执行”而不是“直接操作场景”

有一些开发者会问，能不能让 LLM 直接操作 Blender 里的场景数据，比如让模型返回结构化 JSON，再由插件解析后创建物体。这种方案确实存在，而且更可控，但它要求复杂的 JSON Schema 设计和大量解析代码，灵活性也较低。

相比之下，“生成脚本再执行”的优势是：模型可以直接利用bpy.ops和bpy.data的完整能力，不需要中间层转换；Blender 中几乎所有操作都能通过 Python 表达，LLM 生成的代码覆盖范围最广；实现一个最小可用版本只需要几十行代码。

缺点也很明显：生成代码可能包含语法错误、运行时错误，或者调用不存在的 API。因此，需要在执行前做基础检查，执行时隔离命名空间，执行后收集错误并反馈，必要时可以设计“LLM 自纠错”循环，把报错信息重新发送给模型，让它修正代码。

4. 实战案例：在 Blender 中接入 LLM 完成建模

这一节我们实现一个可用的 Blender 插件。插件功能是在 3D 视图右侧面板中提供一个文本输入框和一个“生成模型”按钮，用户输入自然语言模型描述后，插件调用 LLM API，拿到 Python 代码并执行。

4.1 创建项目结构与准备

不需要复杂的目录结构，一个单文件插件就足够。在本地新建llm_modeling_assistant.py文件，文件编码保存为 UTF-8。插件的bl_info字典用于 Blender 识别插件信息。

文件路径：

llm_modeling_assistant.py

4.2 编写 LLM 调用模块

LLM 调用模块负责组装请求、发送 HTTP 请求、解析返回内容。这里把 API Key 和接口地址放在文件顶部配置区，便于修改。需要特别说明的是，这里的LLM_API_KEY在实际使用时不要硬编码在脚本中，建议改成读取环境变量或本地配置文件，后面最佳实践会详细讲。

bl_info = { "name": "LLM Modeling Assistant", "author": "Your Name", "version": (0, 1, 0), "blender": (4, 0, 0), "category": "3D View", } import bpy import json import os import traceback import urllib.request # ========== 配置区 ========== # 建议优先使用环境变量，不要硬编码 LLM_API_KEY = os.environ.get("LLM_API_KEY", "your-api-key") LLM_BASE_URL = os.environ.get("LLM_BASE_URL", "https://api.openai.com/v1/chat/completions") LLM_MODEL = os.environ.get("LLM_MODEL", "gpt-4o-mini") LLM_TIMEOUT = 180 # =========================== SYSTEM_PROMPT = """你是一名Blender Python专家。 用户会给出3D建模需求，你需要返回一段可直接在Blender中运行的bpy Python代码。 要求： 1. 只输出Python代码，不要输出任何解释、Markdown标记或代码块标记。 2. 代码必须使用bpy模块，不依赖外部Python包。 3. 生成对象前，先删除场景中已存在的同名对象。 4. 新生成的对象统一放入名为"Generated"的Collection中，如果不存在则创建。 5. 使用bpy.ops操作前，先确保处于OBJECT模式。 6. 代码要简洁，不要使用类定义，不要定义多余函数。 7. 设置材质或颜色时，使用bpy.data.materials.new()创建，并赋值给对象。 """ def call_llm(prompt, api_key=LLM_API_KEY, base_url=LLM_BASE_URL, model=LLM_MODEL): headers = { "Content-Type": "application/json", "Authorization": f"Bearer {api_key}" } payload = { "model": model, "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": prompt} ], "temperature": 0.2, "max_tokens": 4000 } req = urllib.request.Request( base_url, data=json.dumps(payload).encode("utf-8"), headers=headers, method="POST" ) try: with urllib.request.urlopen(req, timeout=LLM_TIMEOUT) as resp: result = json.loads(resp.read().decode("utf-8")) return result["choices"][0]["message"]["content"].strip() except Exception as e: error_detail = traceback.format_exc() print(error_detail) raise RuntimeError(f"LLM API 调用失败: {e}")

这里需要解释几个要点。

SYSTEM_PROMPT非常关键。它对 LLM 做了六条约束，每条约束都在减少失败概率。比如第 1 条要求不输出 Markdown，否则执行时会把```python这种标记当成代码报错；第 3 条要求删除同名对象，避免重复点击按钮时场景里出现多个重名物体；第 4 条要求统一放入Generated集合，方便管理生成结果。

4.3 编写模型生成与执行模块

接下来定义两个 Operator。第一个 Operator 负责调用 LLM 并执行生成的代码，第二个 Operator 负责把示例描述填充到输入框中（可选），但为了聚焦，只实现第一个。

注意执行方式。这里使用exec(code_text, exec_namespace)，并且传给命名空间的只有bpy模块。这样做的好处是限制了生成代码可以访问的全局变量，降低误操作风险。但也要提醒，exec本身就是高危操作，生产环境必须配合代码审查。

class LLM_OT_GenerateModel(bpy.types.Operator): bl_idname = "llm.generate_model" bl_label = "根据描述生成模型" bl_options = {'REGISTER', 'UNDO'} def execute(self, context): user_prompt = context.scene.llm_prompt_text.strip() if not user_prompt: self.report({'ERROR'}, "请输入模型描述") return {'CANCELLED'} try: code_text = call_llm(user_prompt) except Exception as e: self.report({'ERROR'}, str(e)) return {'CANCELLED'} # 打印生成代码，方便在系统控制台检查 print("=== LLM 生成的代码 ===") print(code_text) print("=== 代码结束 ===") success, msg = self.execute_code(code_text) if success: self.report({'INFO'}, msg) else: self.report({'ERROR'}, f"执行失败: {msg[-300:]}") return {'FINISHED'} def execute_code(self, code_text): # 简单安全检查：阻止明显危险的文件操作 dangerous_keywords = [ "os.system", "subprocess", "shutil.rmtree", "pathlib.Path.unlink", "open(", "write_text" ] for keyword in dangerous_keywords: if keyword in code_text: return False, f"检测到危险代码片段: {keyword}" # 用独立命名空间执行，只暴露 bpy exec_namespace = {"bpy": bpy} try: exec(code_text, exec_namespace) return True, "模型生成成功" except Exception as e: error_msg = traceback.format_exc() print(error_msg) return False, str(e)

这段代码里有两个用心之处。第一是dangerous_keywords基础过滤，虽然不能完全防止恶意代码，但能阻止大部分误操作，比如 LLM 偶然生成open()文件写入这类行为。第二是使用独立命名空间，避免生成代码把bpy全局命名空间里的变量覆盖掉。

4.4 组装面板和属性

面板部分比较简单，在 3D 视图右侧的 N 面板中新增一个LLM分类页签。属性llm_prompt_text需要注册到bpy.types.Scene上，这样每个 Scene 都可以保存一份输入内容。

class LLM_PT_MainPanel(bpy.types.Panel): bl_label = "LLM 建模助手" bl_idname = "LLM_PT_MainPanel" bl_space_type = 'VIEW_3D' bl_region_type = 'UI' bl_category = "LLM" def draw(self, context): layout = self.layout layout.label(text="描述你想要的模型") layout.prop(context.scene, "llm_prompt_text", text="") layout.operator("llm.generate_model", text="生成模型", icon='MESH_CUBE') def register_properties(): bpy.types.Scene.llm_prompt_text = bpy.props.StringProperty( name="模型描述", description="用自然语言描述你要创建的3D模型", default="生成一个圆桌，桌面半径0.6米，厚度0.05米，4条圆柱腿，腿高0.75米，腿半径0.03米，使用木头材质" ) def unregister_properties(): del bpy.types.Scene.llm_prompt_text def register(): register_properties() bpy.utils.register_class(LLM_OT_GenerateModel) bpy.utils.register_class(LLM_PT_MainPanel) def unregister(): bpy.utils.unregister_class(LLM_PT_MainPanel) bpy.utils.unregister_class(LLM_OT_GenerateModel) unregister_properties() if __name__ == "__main__": register()

默认的字符串描述是一个“圆桌”需求，比较适合初次测试。你可以改成任何自己需要的描述，比如“生成一个带抽屉的方形木桌”“生成一个三层书架”“生成一个路灯模型”。

4.5 运行与验证

在 Blender 中安装运行插件有两种方式。

第一种是临时运行：打开 Blender，切换到Scripting工作区，用文本编辑器打开llm_modeling_assistant.py，点击Run Script按钮。这时插件会被注册，面板出现在 3D 视图右侧。

第二种是正式安装：打开Edit > Preferences > Add-ons，点击Install...，选择llm_modeling_assistant.py，在插件列表中找到3D View: LLM Modeling Assistant并勾选启用。

启用后，找到 3D 视图右侧的N面板，切换到LLM分类，你会看到一个输入框和“生成模型”按钮。

测试时，直接点击按钮，观察 3D 视图。如果一切正常，场景中会出现一个圆桌模型，并自动放入Generated集合。生成结果如下所示：

Generated Collection └── Table_Top（圆柱体，桌面） └── Leg_1（圆柱体，桌腿） └── Leg_2（圆柱体，桌腿） └── Leg_3（圆柱体，桌腿） └── Leg_4（圆柱体，桌腿） └── Table_Material（木头材质）

此时默认描述对应的模型是圆桌，材质名可能是Table_Material或类似名称。如果你在系统控制台开启Window > Toggle System Console，还能看到 LLM 返回的原始代码，方便排查问题。

5. 进阶：几何节点生成与参数化模型

5.1 LLM 生成几何节点配置的思路

除了直接生成网格对象，LLM 也可以帮助创建几何节点程序化模型。Blender 的 Geometry Nodes 是一种非破坏性建模方式，节点图本质上也是可以通过 Python API 构造的数据结构。

要让 LLM 生成几何节点图，你需要把需求描述得足够具体，并在 System Prompt 中补充几何节点的相关约束，比如“请使用 GeometryNodeTree 创建节点组”“不要使用 bpy.ops 创建网格”“节点连接请使用 node_group.links.new()”。

一个简单的示例需求：

创建一个植物生长模拟器几何节点组： 1. 输入一个平面网格。 2. 使用Distribute Points on Faces节点在面上分布点。 3. 每个点实例化一个圆柱作为主干。 4. 添加一个参数控制主干高度。 5. 将节点组应用到选中的平面物体上。

LLM 有可能会生成下面的代码，这里展示一个核心片段，不是完整可运行脚本：

import bpy obj = bpy.context.active_object if obj is None: raise RuntimeError("请先选中一个平面物体") mod = obj.modifiers.new(name="LLM_Plant", type='NODES') node_group = bpy.data.node_groups.new(name="LLM_Plant_Group", type='GeometryNodeTree') mod.node_group = node_group # 创建输入节点和输出节点 input_node = node_group.nodes.new("NodeGroupInput") output_node = node_group.nodes.new("NodeGroupOutput") # 创建分布节点和实例化节点 distribute = node_group.nodes.new("GeometryNodeDistributePointsOnFaces") instance = node_group.nodes.new("GeometryNodeInstanceOnPoints") cylinder = node_group.nodes.new("GeometryNodeMeshCylinder")

需要特别提醒的是，几何节点的 Python API 在不同 Blender 版本之间差异非常大。上面这段代码在 Blender 3.6 和 4.1 中，某些节点类名可能不同。因此，如果要用这条路，建议在提示词里明确标注你的 Blender 版本，并做好“生成后手动微调”的心理准备。

5.2 通过自然语言调整已有模型参数

另一个实用场景是“参数微调”。例如你已经有一个人物模型，希望把它的手臂长度增加 10%，或者把某个材质颜色改成深蓝色。这类需求如果用传统方式，需要找到对应的骨骼或材质节点，操作比较繁琐。

LLM 可以帮你做这件事，前提是你把场景对象命名规范做好。比如手臂骨骼命名为arm_L、arm_R，材质命名为skin_material，LLM 就能根据名称准确生成修改代码。

示例需求：

在Blender中，将名为"arm_L"和"arm_R"的两根骨骼的bone.length都设置为原来的1.1倍。

这个场景更推荐的做法是：把场景结构说明、对象命名规范、常见修改操作模板一起放入知识库，通过 RAG（检索增强生成）让 LLM 在回答前先检索团队内部的建模规范。这样生成的代码会更符合项目约定，减少手动修正成本。

6. 常见问题与排查思路

在实际使用 LLM 辅助建模时，大概率会遇到下面几类问题。这里整理成表格，方便你按图索骥。

这里重点展开几个高频问题。

第一个是bpy模块导入失败。很多人会把 LLM 生成的脚本直接丢到系统终端里的 Python 运行，然后发现import bpy报错。记住：bpy只在 Blender 启动后的 Python 环境里存在，Blender 的命令行执行方式是：

blender --python generate_model_script.py

第二个是 API 返回的代码无法执行。有时候 LLM 会返回带 Markdown 代码块的内容，或者包含解释文字。最简单的处理方式是把执行逻辑改成：先判断代码里是否包含"""或```，有则剥离；如果还是不行，就把报错信息发回给 LLM，让它重新生成。

第三个是执行环境的安全问题。因为exec会运行任意代码，所以生产环境必须做代码审查。你可以增加“人工确认”环节，让插件先把代码输出到控制台并弹窗询问是否执行，这样至少多一层拦截。

7. 最佳实践与工程建议

7.1 提示词工程：把约束写进 System Prompt

LLM 辅助建模的核心变量是提示词。一份好的 System Prompt 应当包含四个方面：角色定义（你是 Blender Python 专家）、任务约束（只输出代码）、环境约束（哪些 API 可用）、质量要求（处理同名对象、放入指定集合）。约束越明确，生成的代码越稳定。

下面是一个更完善的 System Prompt 模板，可以按需扩展：

你是一名 Blender 3D 建模脚本专家。你的唯一任务是输出一段可执行的 Python 代码，使用 bpy 模块。 约束： 1. 只输出代码，不要解释、不要 Markdown。 2. 不得使用除 bpy、math、random 以外的第三方库。 3. 生成对象前，检查是否存在同名对象，存在则删除。 4. 所有生成对象放入名为 Generated 的 Collection。 5. 完成后不要调用视图切换、渲染、保存文件等操作。 6. 如果需求不明确，使用合理的默认参数，并在代码注释中说明默认值。

给默认参数加注释这一点很重要。当用户描述不完整时，LLM 自己拍板的参数可能不合理，但至少注释能让你知道它选了什么默认值。

7.2 安全边界：最小权限与人工审核

把 LLM 生成的代码直接执行，本质上等于赋予 AI 当前文件的完全控制权。工程化项目中建议落实四条规则。

第一，不把 API Key 写在脚本里。可以通过环境变量注入，或使用一个独立的本地配置文件，并在.gitignore中排除它。

第二，在 exec 之前增加代码审查步骤。最简单的做法是把代码打印到 Blender 控制台，执行前弹一个确认框。再进一步，可以在后端服务中加载一个“代码安全审查”Agent，由另一个 LLM 检查这段代码是否有危险操作。

第三，在独立测试文件里验证。不要直接在正式资产文件里运行插件，先复制一份.blend文件做冒烟测试。

第四，权限最小化。如果插件只是帮助建模，那生成的代码不应该拥有文件写入权限。虽然 Python 层面很难完全隔离，但可以在代码生成提示词里明确“禁止所有文件操作、禁止网络请求”。

7.3 健壮性设计：超时、重试与自纠错

真实项目中，LLM API 并不总是稳定。建议在调用模块中增加以下机制。

第一是超时控制。urllib.request.urlopen的timeout参数设置为 180 秒或更短，避免 Blender 界面长时间无响应。

第二是重试机制。遇到网络抖动时，可以连续重试 2 到 3 次，每次间隔数秒。重试时最好使用指数退避策略，例如第 1 次等 2 秒，第 2 次等 4 秒。

第三是错误自纠错。当 LLM 生成的代码执行失败时，把报错信息拼接到原提示词中，再发送给 LLM，要求它“根据报错信息修正代码”。这个循环可以执行 1 到 2 次，能明显提高最终成功率。示例代码如下：

def generate_with_retry(user_prompt, max_retry=2): code_text = call_llm(user_prompt) for attempt in range(max_retry): success, msg = execute_code(code_text) if success: return code_text, "" # 把错误信息发回给模型 fix_prompt = ( f"你之前生成的Blender脚本执行报错。\n" f"原始需求：{user_prompt}\n" f"生成的代码：\n{code_text}\n" f"错误信息：\n{msg}\n" f"请输出修正后的完整代码，只输出代码。" ) code_text = call_llm(fix_prompt) return code_text, "多次尝试后仍然失败"

这种自纠错机制在实践中很有用，因为大多数 bpy 脚本报错都是小问题，比如对象名拼写错误、模式没有切换、参数类型不对，LLM 看到报错信息后通常能直接修复。

7.4 命名规范与场景管理

LLM 根据自然语言生成代码时，对场景对象的命名往往比较随意。但在实际项目中，后续可能需要继续操作这些模型，如果对象名是Circle.001、Cylinder.005，维护成本会很高。

建议在 System Prompt 中明确命名规则，例如：

• 新增网格统一前缀Gen_，例如Gen_Table_Top、Gen_Leg_01。
• 材质统一前缀Mat_，例如Mat_Wood_Oak。
• 生成结果统一放入Generated集合。
• 如果模型包含多个部件，按照模型名_部件名的格式命名。

这样可以保证后续无论是人工还是 LLM，都能基于名字操作具体物体。

7.5 从“单次生成”到“对话式微调”

一次性生成往往难以达到满意效果。更实用的交互模式是“多轮对话”：第一轮用户描述需求，LLM 生成模型；用户检查后发现问题，发给 LLM“把桌面改大一点”“桌腿改成方形”等反馈；LLM 针对已有模型生成修改脚本。

实现起来也很简单，只需要维护一个对话历史列表，每次调用接口时把之前的user和assistant消息一起发送。这样 LLM 能记住之前的生成代码和模型结构，微调效果会比每次从零生成好很多。

如果要把这个能力做到产品级，建议在 Blender 插件之外单独搭建一个后端服务，负责管理对话上下文、用户资产、模型缓存和审批流程。前端 Blender 插件只负责收集输入和展示结果，这样职责更清晰，也更容易做安全控制和审计。

8. 总结与下一步学习建议

从可行性上看，LLM 辅助 Blender 3D 建模并不是噱头，它已经在“自然语言转基础模型”“参数化建模”“脚本自动生成”这几个场景里表现出了实用价值。本文从原理到实战，带大家搭建了一个最小可用的 Blender 插件：在面板中输入描述，点击按钮，LLM 返回 bpy 代码，插件隔离执行并生成模型。同时也梳理了常见的报错和安全问题。

如果想把这条路走深，建议按以下顺序继续学习：先掌握 Blender Python API 的核心对象类型，尤其是bpy.data和bpy.ops的常用接口；然后熟悉几何节点的 Python 构造方式，尝试用 LLM 生成程序化纹理和建筑体块；再往后可以研究 RAG 知识库，把团队建模规范、材质库清单、命名规范全部灌入知识库，让 LLM 生成的代码更贴合项目要求。

最后想强调一点：LLM 辅助建模的意义不是取代建模师，而是把最琐碎、最重复的那部分工作自动化。真正高质量的模型，仍然需要人的审美、拓扑规划和视觉判断。建议从你手头最常见的重复建模任务开始试，比如批量生成道具、快速搭建场景白模、自动设置材质，把 LLM 当成一个“随叫随到、能理解你说人话”的脚本助手，逐步积累一套适合自己项目风格的提示词模板和代码执行规范。

如果你在接入过程中遇到其他奇怪的报错，欢迎在评论区贴出错误信息和控制台日志，大家一起排查。实践是最好的学习方式，先跑通一个小案例，再慢慢扩展功能。