1. 项目背景与整体思路
1.1 传统智慧仓储数字孪生的建模痛点
这两年做智慧仓储项目，绕不开一个词：数字孪生。简单说，就是把物理世界里的仓库在电脑里完整还原出一套 1:1 的三维场景——货架、库位、AGV、输送线、人员动线，全部映射到数字空间，再和 WMS（仓库管理系统）的数据打通。传统的落地路径一般是：先让建模师用 Blender 或 3ds Max 手工建一套仓库场景，导出成 glTF 或 FBX，然后在 Unity、Three.js 或者自研引擎里做交互和渲染，最后再接入实时数据流。这个流程最大的痛点不在渲染，而在建模环节。
我接触过好几个项目，3D 场景的交付周期常常占到整个项目工期的一半以上。原因很现实：手工建模速度慢，而且不同建模师产出的模型命名混乱、坐标不统一、层级结构千奇百怪。数字孪生最怕的不是模型丑，而是模型和业务数据对不上——WMS 告诉你"A0101 库位有货"，结果场景里根本找不到叫 A0101 的物体，或者坐标完全错位。这意味着，建模从一开始就不能只靠美术手感，必须用规则化、数据化的方式去生成。
1.2 为什么选择 Antigravity + Blender MCP
我最近在试着走一条新的工作链路：用 Antigravity 作为 AI 编程环境，AI Agent 负责理解需求、组织指令，通过 Blender MCP 这个中间层，把指令变成 Blender 里的具体操作。试了几周之后，我可以比较负责任地说，这条路在"快速产出规则化三维场景"这件事上，比传统手工建模有明显的量级提升。
Antigravity 这类 AI IDE 的核心价值，不光是补全代码，更重要的是它的 Agent 模式可以自主执行多步任务。你要做的只是用自然语言描述需求，比如"在 Blender 里建一个 36 米乘 24 米的仓库地面，放在 y=0，命名 Floor，材质用浅灰色"，它就会自己去调用工具、执行操作、检查结果、修正错误。而 Blender MCP 是整个链路里最关键的桥梁——它把 Blender 的内部操作暴露成一个个标准工具，AI 不需要懂 Blender 的 Python API 也能驱动建模。
选这套组合还有一个现实原因：Blender 是免费开源的，本身自带 Python API 和几何节点，程序化建模能力很强，做仓储这种"规则几何体组合"非常合适。相比直接用 Three.js 写代码建模，Blender 的优势是即时可视、后续还能渲染和做动画；相比纯手工建模，它又可以完全程序化、完全可复用。Antigravity + Blender MCP 相当于把这个程序化建模过程中的"编程"环节也替代掉了。
1.3 工具链路与角色分工
把整套架构讲清楚，其实只需要三行：
- Antigravity：扮演大脑。接收你的自然语言需求，拆解任务，决定调用什么工具，处理执行结果。
- Blender MCP Server：扮演神经和手。运行在 Blender 插件里的本地服务，把 AI 发来的指令翻译成 bpy 代码并执行。
- Blender 本体：扮演工作台。创建场景、管理物体、赋予材质，所有三维资产的最终生成和呈现都在里面发生。
三者之间通过 MCP（Model Context Protocol）协议通信。MCP 定义了统一的接口：AI 可以查询有哪些工具、调用某个工具、传参数、拿结果。Blender MCP 就是这套协议在 3D 软件上的具体实现，由开源社区维护。插件安装后会在本地起一个 Socket 服务，默认监听 127.0.0.1:9876，Antigravity 通过 MCP 客户端连接这个端口，两边就接通了。
这里有个容易误解的点：MCP 不是 WebSocket 或者 RPC 那种需要你写业务逻辑的通信方案，它更像是给 AI 和软件之间定了一份"菜单 + 点餐规则"。AI 只需要知道菜单上有哪些菜、每道菜需要什么配料，至于后厨怎么炒，它不需要关心。把这一层抽象做好了，AI 就能以很低的适配成本去控制一个桌面软件。
2. 环境搭建：从零跑通 AI 与 Blender 的通信
2.1 安装 Blender MCP 插件端
先准备 Blender，我建议直接用 4.0 以上版本，Blender MCP 对较新版本的支持更完整。安装过程很常规：
- 从 GitHub 的 ahujasid/blender-mcp 仓库下载最新的插件压缩包（zip 格式）。
- 打开 Blender，进入 Edit（编辑）-> Preferences（偏好设置）-> Add-ons（插件）标签页。
- 点击右上角的 Install（安装），选择下载好的 zip 文件。
- 搜索 "mcp"，找到 Blender MCP Server 条目，勾选启用。
- 启用后，在 3D 视图的侧边栏（N 键呼出）会多出一个 MCP 面板，点击 Start Server（启动服务），面板中会显示服务端口，默认是 9876。
这步最容易被忽略的是插件加载问题。Blender MCP 插件执行代码时是在 Blender 自己的 Python 环境里运行，如果 Blender 是通过某个管理器安装的，或者你手动改过 Python 路径，插件可能加载失败。遇到这种情况，优先检查插件是否成功装进addons目录，以及侧边栏有没有出现 MCP 面板。只要面板出来了，后续基本顺畅。
还有一个实操细节：插件启动后，不要关掉 Blender 窗口。MCP 的服务是常驻进程，Blender 一旦最小化到托盘或者被系统锁定，Socket 连接通常不会断，但执行 UI 相关操作时偶尔会超过 AI 的响应超时。我习惯在生成大场景时把 Blender 窗口放到副屏，不要做任何视图缩放操作，让 AI 在后台稳定跑。
2.2 在 Antigravity 中注册 MCP 服务
Antigravity 端的配置不复杂。它支持 MCP 服务器的注册方式与主流 AI IDE 一致，一般是在项目根目录或用户配置目录下维护一个 JSON 配置文件，把blender-mcp注册为标准 MCP 服务器。常用的配置如下：
{ "mcpServers": { "blender": { "command": "uvx", "args": ["blender-mcp"] } } }这里uvx是 Python 生态里的一个工具，类似 npx 之于 Node.js，会自动下载并运行 Python 包，适合把 blender-mcp 这种带命令行入口的服务挂起来。如果你的机器上没有uvx，也可以先用pip install blender-mcp安装到当前 Python 环境，然后把 command 改成解释器路径，args 里填-m blender_mcp。不同版本的启动方式略有差异，以插件仓库 README 为准。
配置完成后，重启 Antigravity，然后在 MCP 服务器列表里应该能看到blender这个条目，确保它处于 Running 状态。这一步的关键点：Antigravity 和 Blender 之间通过 127.0.0.1:9876 这个本地端口通信，所以必须保证 Blender 端的 MCP Server 先启动，Antigravity 那边再去连接。顺序反了，连接会直接失败。我一般先打开 Blender、点击 Start Server，再进入 Antigravity 的会话。
2.3 首次连通验证的完整步骤
配置完不要急着做复杂场景，先做一次最小化连通测试：
- 确保 Blender 的 MCP 面板显示 Server Started（端口 9876）。
- 在 Antigravity 中新建对话，先把目标说清楚："请通过 Blender MCP 检查 Blender 连接状态。"
- AI 通常会先调用
check_socket_connection工具，然后返回类似 "Connected to Blender" 的结果。 - 继续要求："在 Blender 中创建一个边长为 2 米的立方体，命名为 TestCube，放在原点。"
- 观察 Blender 场景里是否出现一个立方体，并且 Outliner（大纲视图）中出现 TestCube。
这五步走完，链路就算通了。如果第 3 步就失败，问题几乎都集中在端口不一致上——Blender 插件允许自定义端口，如果你改过，Antigravity 配置里的端口也要同步改。如果第 1 步失败，那就是 Blender 侧插件没加载成功，优先回看 2.1。
我第一次连通测试时踩过一个坑：Antigravity 配置的 MCP 客户端和 Blender 插件版本不匹配，老版本 blender-mcp 只实现了部分工具，导致某些指令有响应、某些指令静默失败。所以建议 Blender 插件和 Python 包都拉最新版，两边主版本至少是同一代。测试时故意试它一两个高级工具（比如execute_code），能走通就说明工具集完整。
3. 核心原理：MCP 如何把自然语言变成 3D 操作
3.1 用生活类比理解 MCP 协议
聊原理前先打个比方。MCP 的工作方式就像去餐厅吃饭：你不会直接冲进后厨对着厨师喊"把土豆切成丝"，你会坐下看菜单，选好菜，告诉服务员"我要一盘酸辣土豆丝"。服务员把你的点单传给后厨，后厨做完端上来，你只关心菜好不好吃。在这里，AI 是顾客，Blender 是后厨，MCP 就是那份菜单加服务员。
从协议层面看，MCP 定义了几类基本操作：
tools/list：列出当前所有可用的工具，相当于浏览菜单。AI 通过它知道 Blender 能做什么。tools/call：指定工具名和参数，执行一次实际调用，相当于下单。- 资源与提示词：一些非工具的信息交换，比如读取文档、获取上下文提示，相当于餐厅里的特色菜说明。
通信格式是 JSON-RPC 2.0，也就是一段带jsonrpc、method、params字段的 JSON 对象，在 Antigravity 和 Blender 之间通过本地 Socket 传输。这种设计带来的好处是跨语言、跨平台：任何支持 JSON 的工具都能接入同一条链路，这也解释了为什么 MCP 生态一出现就在各种软件里快速普及。
从产品设计角度看，MCP 最大的价值是"去插件化"。以前想让 AI 控制 Blender，要么给 AI 装一套专用的 SDK，要么让 AI 直接生成 Python 脚本再手动执行，非常别扭。MCP 把所有软件操作抽象成统一接口，AI 层面不用关心每个软件的内部差异。
3.2 Blender MCP 的常用工具清单
Blender MCP 插件暴露出来的工具，基本覆盖了三维场景建模的日常操作。我列几个高频使用的：
| 工具名 | 作用 | 典型参数 |
|---|---|---|
| check_socket_connection | 检查 Blender 服务是否在线 | 无 |
| create_mesh | 创建基础网格物体（立方体、平面、圆柱、圆环等） | type, size, location, name |
| add_object | 添加平面、文本、空物体等 | object_type, name, location |
| modify_object | 移动、旋转、缩放对象或修改属性 | object_name, mode, transformation |
| select_object / delete_object | 选择与删除物体 | object_name |
| get_object_tree | 获取场景大纲完整层级 | 无 |
| get_object_info | 获取单个物体的属性、类型、位置、旋转 | object_name |
| add_material / set_material | 新建材质、将材质赋给物体 | material_name, color, object_name |
| execute_code | 把一段 Python 代码直接交给 Blender 执行 | code |
前几个是"具体操作型"工具，AI 使用它们时按部就班地完成建物体、移动、上色。最后一个是"万能后门"，它允许 AI 把任意 bpy 代码丢进 Blender 执行。这意味着 AI 可以写 for 循环生成整个货架阵列，可以用数学函数生成曲线，也可以直接用 bpy.data 批量操作场景数据。
这个工具集的组织逻辑很有讲究：常规操作走专用工具，保证行为可控、结果明确；复杂操作走 execute_code，把自由度交给 AI。我在使用中体会很深的一点是，不要因为有 execute_code 就用它干所有事。专用工具的好处是每一步都可追溯，AI 出错时你能从调用记录里看出是哪一步；execute_code 一旦写出 bug，可能整个场景被清空，排查成本高。
3.3 Agent 的多步迭代执行逻辑
Antigravity 的 Agent 并不是每次把工具调用当成孤立的命令来执行，它对一个任务通常会走完整的规划-调用-检查-修正循环。以"生成一排货架"为例，内部流程大概是：
- 解析用户需求：抓取关键数字，比如货架数量、尺寸、间距、命名规则。
- 规划子任务：先创建货架底座，再创建立柱，再创建横梁，最后赋材质。
- 逐个调用工具：用 create_mesh 或 execute_code 执行每一步，拿到返回结果。
- 读取反馈：如果某个工具报错，它会尝试理解错误信息，调整参数后重试。
- 完成后汇报：给你一个总结，列出创建了哪些物体、放在什么位置。
这个循环看起来不复杂，但实际效果差别很大。我发现 Antigravity 在规划阶段的"建模思维"和你给的上下文强相关。如果你只是笼统说"生成一些货架"，它可能会自由发挥尺寸；如果你把坐标系约定、尺寸规格、命名规范写清楚，它生成的代码质量会高一个档次。
还有一个重要机制：Blender MCP 的 execute_code 执行完不会自动截图给你。AI 看不到 Blender 的渲染结果，所以它判断"做没做对"主要靠工具返回的文本信息、场景对象树，以及你的文字反馈。这提醒我们，和 AI 协作建模时，最好养成"每完成一个层级就让它核对场景对象树"的习惯，让 AI 输出它认为的关键对象列表，你再用眼睛在 Blender 里确认。
4. 实操记录：半小时生成仓储数字孪生初版场景
4.1 先用文字定出场景规格
真正开干之前，最关键的一步反而跟 Blender 无关：把仓储场景的规格写清楚。数字孪生最忌讳一边建模一边改尺寸，AI 生成一堆物体后再让你全部重来。我建议在对话一开始就给 AI 一段"需求规格说明"，像这样：
- 仓库尺寸：长 36 米（x 方向），宽 24 米（y 方向），高 6 米。
- 坐标约定：仓库中心为原点，地面 y=0，x 正方向为仓库纵向，y 正方向为横向。
- 货架区：共 4 排货架，每排 6 组，每组长 3 米、宽 0.9 米、高 3 层（含地面层）。
- 库位：每个库位深 0.8 米、宽 0.6 米、层高 1 米。
- 通道：主通道宽 3 米，货架间通道宽 1.5 米。
- 命名规则：地面 Floor；货架 Rack_R{排}_G{组}；库位 Bin_R{排}_G{组}_L{层}。
- 材质规则：地面浅灰，货架立柱深蓝，库位边框黄色线框，占用库位用红色方块表示。
把这 8 条发给 Antigravity，然后再下达"按以上规格搭建初版场景"的命令。为什么这样做？因为 AI 建模的成败，90% 取决于输入规格的清晰度。坐标和命名规则尤其重要，后面你要接 WMS 数据、做动画、做交互，全靠这一套规则。
4.2 第一轮指挥：生成地面与仓库边界
第一轮我通常只要一个物体：地面。命令可以这么下：
"使用 Blender MCP，在原点创建地面平面，x 宽 36 米，y 宽 24 米，命名为 Floor，添加名为 FloorMat 的浅灰色材质（RGB 0.8）。请先把材质创建好，再赋给平面，最后检查场景对象树确认。"
AI 收到后大致会做这几件事：调用 add_material 创建材质，调用 create_mesh 或 execute_code 创建平面，再调用 set_material 赋材质。你从 Antigravity 的执行日志里能看到每个工具的参数，这是一个很好的学习机会——看 AI 怎么把"创建浅灰色材质"翻译成color=[0.8, 0.8, 0.8]这样的参数。
有个细节值得注意：Blender 默认平面是 2 米乘 2 米，如果你只告诉 AI"创建地面"而不写尺寸，它多半会给你一个默认平面，后面所有货架坐标都会算不准。所以我在命令里总是把尺寸、原点一起写清楚。地面建好之后，我通常让 AI 再创建四根细长立方体作为边界标记，方便肉眼判断仓库范围。这个用 create_mesh 就能做，AI 自己会拼接参数。
如果这轮 AI 直接把地面建歪了，先检查是不是它调用了两次 create_mesh 导致重复物体，然后用 select_object + delete_object 清理，并告诉它"只保留 Floor，删除重复项"。这种纠正动作，AI 能听懂并记住。
4.3 第二轮指挥：程序化生成货架阵列
地面搞定之后，重头戏来了：生成 4 排货架、每排 6 组。如果用 create_mesh 一个物体一个物体调，AI 会累死，你也会等疯。正确姿势是让 AI 用 execute_code 写一段 bpy 脚本，用双重循环批量生成。我会这样下指令：
"在 Floor 上生成 4 排货架，每排 6 组。货架组尺寸 3 米 x 0.9 米 x 3 层，层高 1 米。第一排货架中心线从 x=-15 开始，排距 2.5 米，组间距 3.5 米。请用 execute_code 写 Python 脚本，使用 bpy 创建货架底座、立柱和横梁，所有物体命名遵循规格，命名前缀 Rack_R{排}_G{组}。生成完成后调用 get_object_tree 汇报。"
AI 生成的代码大概是这样（我整理过）：
import bpy rows = 4 groups = 6 group_width = 3.0 group_depth = 0.9 level_height = 1.0 levels = 3 start_x = -15.0 row_gap = 2.5 group_gap = 3.5 for r in range(rows): for g in range(groups): x = start_x + g * group_gap z = r * row_gap # 创建底座 bpy.ops.mesh.primitive_cube_add(size=1, location=(x, 0.1, z)) obj = bpy.context.active_object obj.scale = (group_width, 0.1, group_depth) obj.name = f"Rack_R{r}_G{g}_Base" # 立柱和横梁部分由 AI 展开...当然实际生成时 AI 会写得更完整，包含四根立柱和每层横梁。你只需要在对话里告诉它"货架组要有底座、四根立柱、三层横梁"，它就会展开成足够多的物体。执行完，Blender 场景里立即出现一排排结构清晰的货架，这时用get_object_tree检查命名和数量，心里就有底了。
这个环节我踩过最大的坑是：AI 在 execute_code 里创建完物体后忘记清理bpy.ops的自动命名，导致生成一堆 "Cube.001"、"Cube.002"。所以我在命令里会特别强调"创建完物体后立即设置 name 属性"，比如obj.name = f"Rack_R{r}_G{g}_Base"。这一步直接决定了后续的可维护性——数字孪生场景的未来全靠命名规则。
4.4 库位线与区域标识的视觉分层
货架骨架有了，但离数字孪生还差一步：库位可视化。一个库位不只是货架上的格子，它应该是一个明确的几何体，方便后续做数据关联和状态飘色。我给库位定的视觉规则是：空闲库位用黄色线框表示（wireframe），占用库位用红色实心方块表示。这个视觉分层思路非常重要，让三维场景一眼就能看出哪些位置有货、哪些没有。
命令示例：
"在每层货架的每个库位位置，创建一个 0.8 米深、0.6 米宽的线框立方体（wireframe display），颜色设为黄色，命名 Bin_R{排}_G{组}_L{层}。线框立方体要用 execute_code 创建，然后设置 display_type 为 WIRE。"
这里说的 wireframe 不是建模意义上的线框网格，而是 Blender 物体的一种显示方式，可以在 bpy 里这样控制：
obj = bpy.context.active_object obj.display_type = 'WIRE'要让 AI 同时把材质改成黄色，还需要给物体赋一个带基础色的材质。我在命令里会明确要求"材质的 Viewport Display 颜色设为黄色"，否则有些版本的 Blender 默认材质在视图里显示为白色，看不出效果。
这个过程会很考验 AI 的耐心，因为一个 4 排 x 6 组 x 3 层的仓库，库位数量是 72 个（单深位）。如果它用 create_mesh 一个个调，早就超时了。所以我一律要求它用 execute_code 跑 for 循环，你只需要看它最后有没有正确汇报数量，以及 Blender 里线框是否整齐排布。
4.5 进阶思路：用库存数据批量生成库位状态
到这里，初版静态场景已经基本成型。再往前一步，是让场景具备"数据驱动"能力。数字孪生真正值钱的地方在于：库位状态不是美术手调的，而是从 WMS 实际数据里长出来的。
我在第二个项目里试过这样的流程：
- 从 WMS 导出当前库位表，字段至少包含：库位编码、所在排/组/层、状态（空闲/占用）、SKU 编号。
- 整理成 JSON 文件，存到本地。
- 在 Antigravity 中告诉 AI："读取当前目录的 wms_bins.json，根据每条记录的 status 字段，在对应库位坐标处生成红色立方体（占用）或不生成（空闲）。库位坐标按约定：排 r 的 x 起点、组 g 的 x 间距、层 l 的 y 高度来计算。生成后所有 Bin 数量等于 JSON 记录数。"
JSON 大概长这样：
[ { "bin_id": "R0_G0_L0", "row": 0, "group": 0, "level": 0, "status": "occupied", "sku": "SKU001" }, { "bin_id": "R0_G0_L1", "row": 0, "group": 0, "level": 1, "status": "free", "sku": "" } ]AI 读取数据后，通过 execute_code 把坐标算出来，批量生成小立方体。整个过程不需要人工桥梁，数据文件直接变成三维状态。这里有个非常有价值的副作用：因为坐标是代码算出来的，场景里的物体位置和业务数据严格对应，以后做碰撞检测、路径规划、库存盘点都有了准确的三维基础。
坐标换算其实很直接：第 r 排第 g 组货架中心线的 x 坐标是start_x + g * group_gap，z 坐标按排距累加；第 l 层的 y 高度是base_height + l * level_height。数据表里的行列号只要映射到这两个公式，AI 就能定位任何一个库位。这种"数据到几何"的一一对应关系，是数字孪生后续所有功能的地基。
当然这里说的是静态快照。动态联动，比如每隔几秒刷新库存状态、AGV 按路径移动，需要再接实时数据流，这是下篇的内容。但你要明白，先把静态数据驱动的架子搭对，后面接动态数据就只是换数据源的问题。
5. 高频问题与排查心得
5.1 连接类问题速查
我整理了一份速查表，覆盖实际遇到过的 MCP + Blender 连接问题，按出现频率排序：
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| Antigravity 提示无法连接 MCP Server | Blender 端未启动 MCP Server | 回到 Blender，点击 MCP 面板的 Start Server |
| check_socket_connection 返回 False | 端口不一致 | 确认 Blender 面板显示的端口与 Antigravity 配置一致，默认 9876 |
| 连接时通时断 | Blender 正在执行长任务阻塞 UI | 等 Blender 空闲后再发指令，不要在视图里频繁操作 |
| MCP 面板找不到 | 插件加载失败 | 检查偏好设置里的插件是否勾选，卸载重装 zip |
| execute_code 执行后无反应 | 代码有语法错误但被吞掉 | 让 AI 在 code 末尾加print("DONE")，通过返回输出定位 |
第一个问题出现频率最高，尤其是同时开了多个 Blender 实例时。MCP 默认连接 9876，两个 Blender 实例可能抢占端口，导致 AI 连到错误的实例。我的建议是单独用一个 Blender 实例专跑 MCP，别多开。
5.2 工具调用与代码执行类问题
连接通了之后，真正磨人的是执行阶段的报错。典型问题有：
- AI 调用 modify_object 时找不到对象。原因是对象名被 Blender 自动改了，比如创建了 Cube.001，AI 以为是 Cube。解决办法是让 AI 先调用
get_object_info或get_object_tree查一下准确名称，再传参数。 - execute_code 里用 bpy.ops.object.delete() 删不掉。这个 API 需要先选中对象，AI 经常会忽略。可以引导它用
bpy.data.objects.remove(obj)替代，不需要选中。 - 材质没生效。常见情况是 add_material 创建了材质但没有赋给物体，或者赋到了错误的材质槽。命令里要把"先创建材质、再选择物体、再赋材质"三步说全。
- 坐标错乱。AI 在算货架坐标时把 x 和 z 搞混。这个要靠规格说明约束，我通常在命令里附带一句"x 代表仓库纵向，z 代表横向，y 代表垂直高度"。
遇到这些报错，我的处理原则是：不要替 AI 改代码，而是把报错信息原样贴回去让它自己修。Antigravity 通常能根据 traceback 找到问题。唯一要人工介入的时机是它连续修了三四次还没进展时，你就把目标拆小，让它只处理一排货架，跑通了再放大。
5.3 建模协作的节奏控制与避坑建议
最后聊几个软性经验，可能比上面的硬问题更值钱。
第一，永远不要一次给 AI 布置一个大而全的任务，比如"生成整套仓库场景，包括货架、AGV、包围区域、动线标识"。AI 虽然能做多步任务，但会在某个环节信息过载，要么漏细节，要么生成一堆需要返工的东西。我的节奏是：地面一轮、货架一轮、库位一轮、标识一轮、数据驱动一轮，每轮之间可以开新对话段落，让上下文保持清爽。
第二，学会逼 AI 自查。很多建模错误不是 AI 不知道规则，而是它忘了检查。命令末尾加一句"完成后用 get_object_tree 列举所有 Rack_ 前缀的对象，确认数量和命名正确"，它能立刻发现遗漏。这比你去 Blender 里肉眼找快得多。
第三，坐标统一是生命线。如果你规划时用 x 作为长度、z 作为宽度，那么所有命令都要沿用这个约定。一旦中途换坐标系，AI 生成的一半物体位置全错，返工成本极高。数字孪生项目尤其如此，因为后续所有业务数据坐标映射都建立在这套约定上。
第四，仓库比较复杂的时候，比如有阁楼、站台、输送线，我建议在初始化阶段让 AI 先生成占位盒（低精度立方体表示设备区域），把整体空间关系定下来，之后再逐项替换成精细模型。这借鉴了软件工程的接口先行理念——先把布局对清楚，再填充实现。
从我实际操作的体会来说，Antigravity + Blender MCP 最适合的场景就是这种规则明确、数量大、可程序化的仓储类三维场景。它不能替代美术精细建模，但能把过去三周的工作量压缩到半天，而且产出的资产是结构化、命名规范、坐标准确的——这恰恰是数字孪生落地最需要的底座。
最后再分享一个细节：每次大场景生成前，在 Blender 里按一次 Ctrl+S 保存初始场景文件，给 AI 一个悔药。一旦 execute_code 写崩场景，你可以让 AI 重新加载这个文件，而不是在废墟上修补。我在踩过一次"整个场景被清空"的坑之后，这个习惯就再没断过。下篇我会写动态层：怎么把 WMS 实时数据接进来、库位状态定时刷新、AGV 路径动画怎么做，到时候这套静态底座才能真正活起来。
