做3D智慧仓储数字孪生这件事，我一开始没打算走“AI直接操刀建模”这条路线。直到我同时把 Antigravity 和 Blender MCP 串起来跑通，才发现以前最耗时的“拿代码生成场景、再手动导回 Blender 调整”的两段式流程，被压缩成了一段连续对话：我在 Antigravity 的对话框里说“把第二排货架间距改成 1.2 米”，Blender 视图里的模型就真的跟着动了。这个项目上篇，我会把从零跑通这套链路的过程、踩过的坑，以及仓储场景建模的核心设计思路完整记录下来。适合正在做数字孪生、智能化可视化的前端或全栈工程师，也适合想用 AI 驱动 Blender 建模的朋友参考。
先说核心结论：要跑通这条链路，真正难的不是安装某个软件，而是理解三件事如何咬合。Antigravity 是负责“思考和下达指令”的 AI IDE，Blender 是负责“产出几何资产”的建模工具，MCP 则是两者之间的标准通信协议。把这三者的关系理顺，后面所有操作都会顺理成章；理不顺，配置界面上的每一个报错都能让你怀疑人生。这篇文章就按“架构拆解 → 环境搭建 → 建模设计 → 实操演示 → 问题排查”的顺序来写，尽量把每个选择背后的为什么也讲清楚。
1. 项目整体拆解：Antigravity、Blender 与 MCP 是怎么咬合的
1.1 一句话讲清这条 3D 数字孪生管线
这条管线的本质，是让 AI 代码助手通过 MCP 协议直接“遥控” Blender 的 Python API，把数字孪生场景的搭建从“写脚本、执行脚本、回看效果”变成“自然语言指令直接驱动建模操作”。我最早接触这个概念时，也觉得无非就是调用几个接口，但实际跑起来才发现，关键在于通信链路的组织方式。
MCP（Model Context Protocol，模型上下文协议）不是硬件协议，而是一个应用层协议，它定义了 AI 模型与外部工具之间的标准化交互方式：外部工具把自己的能力暴露成一组工具调用，AI 模型在对话过程中按需调用这些工具，再读取返回结果继续决策。打个不太严谨但好理解的比方：MCP 就像给 AI 配了一个“机械臂控制台”，把 Blender 里几百个建模函数全部接成一个个按钮，AI 只需要判断什么时候按哪个按钮。
Blender MCP 插件就是这个控制台的具体实现。它通常以插件形式运行在 Blender 内部，对外开启 WebSocket 服务，同时由配套的 MCP Server 进程与 AI IDE 通信。Antigravity 这边配置好 MCP Server 地址后，agent 就能获得“执行 Python 代码、调用 Blender API、读取场景状态”等核心能力。我习惯把这条链路拆成三截来看：Antigravity 管“想”，MCP Server 管“传”，Blender 管“做”。排查问题时按截定位，会快很多。
1.2 为什么选 Antigravity + Blender MCP 这条组合
我试过传统做法：在 Blender 里手写 Python 脚本，或者用 Geometry Nodes 对场景做参数化，再用外部程序生成 JSON 数据驱动更新。这两个方案本身没问题，但放在智慧仓储数字孪生场景里，痛点很明显——仓储场景里的货架排布、巷道宽度、设备位置，往往来自业务侧不断调整的规划表或 Excel 数据，每次改需求都意味着重新写脚本、重新导数据，迭代成本高得让人不想改。
Antigravity + Blender MCP 打中的正是这个痛点。Antigravity 这类 AI IDE 原生支持 MCP 配置，agent 可以在对话中完成“分析布局数据 → 计算坐标 → 驱动 Blender 建模 → 读取场景核对 → 再调整”的完整闭环。AI 不再是一次性生成一个静态脚本，而是像一个能实时操作 Blender 的建模师，我可以随时追加指令：加一排货架、改货架高度、给不同区域换颜色。这种交互方式，比“改脚本—重启—看结果”的循环舒服太多。
另外一个现实原因：仓储数字孪生最终要交付的是 Web 端 3D 可视化，Blender 相当于“资产生产工厂”。用 MCP 控制 Blender，等于把资产生产环节也纳入 AI agent 的可控范围，后面导出 glTF/GLB 给前端用，链路就顺了。我在实际项目里感受最明显的是，当业务方拿着新的库位规划图来找我时，我不用再花半天去改 Blender 脚本，而是直接拉着 AI 把参数一换，重新生成一遍场景，省下来的时间非常可观。
1.3 要复现这套流程，需要准备什么
先列一份基础清单，后面的章节会逐项展开：
- Antigravity 桌面版客户端，更新到支持 MCP 配置的版本；
- Blender 3.6 LTS 或 4.x 版本，建议用长期支持版，插件兼容性更稳；
- Blender MCP 插件，社区有开源实现，也可以在 Blender 插件商店搜相关名称；
- 一个可用的 MCP Server 运行时，通常用 Node 或 Python 环境启动；
- 测试用的 JSON 布局数据，比如一小张仓储货架规划表。
这里有个容易忽略的点：Blender MCP 插件版本要和 Blender 主版本匹配。我在 4.1 上装过某个老版本插件，WebSocket 服务能起来，但一调用场景删除接口就报错，最后查下来是插件用了在 4.x 里被重命名的 API。所以不要贪新也不要太旧，先按插件 README 里标注的 Blender 版本安装。另外，Antigravity 和 MCP Server 的版本也在快速迭代，如果升级了主程序，旧的 MCP 配置有时需要重建，这点在后面问题排查部分我会专门讲。
2. 环境搭建实操：把 Antigravity 和 Blender MCP 跑通
2.1 安装并配置 Blender 端 MCP 插件
在 Blender 里装插件，很多人第一反应是去扩展目录 Preferences 里搜索，但 Blender MCP 这类带网络服务的插件，我建议用“Install from Disk”方式装压缩包，更可控，版本也更明确。
具体流程：先下载插件 zip 包，Blender 顶部菜单 Edit → Preferences → Add-ons → 右上角下拉箭头选择 Install from Disk，选中 zip 后启用即可。启用后，插件面板会出现在 3D 视图右侧的 N 面板或特定标签页里，主要设置项包括：Server Port（默认一般 9876）、是否允许读取当前场景对象、WebSocket 安全校验开关（本地开发可以先关掉）。
这里有一个关键细节：插件启用后，Blender 窗口不能关，而且最好保持当前是 3D Viewport 模式，部分 MCP 实现导出截图或视口信息依赖当前工作区类型。我第一次跑的时候，把 Blender 切到了 Shading 工作区，结果 AI 返回的信息里看不到视口画面，排查了一会儿才发现是工作区的问题。还有一点，Blender 后面弹出的一些 Python 运行确认框会卡住 MCP 调用，我建议在偏好设置中打开 Auto Run Python Scripts 相关的选项（本地调试环境可以这样，团队交付时再按安全要求收紧）。
2.2 在 Antigravity 里注册 MCP Server
Antigravity 的 MCP 配置入口一般在设置页的 MCP Servers / Integrations 区域。不同版本界面有差异，但套路一致：新增一个 Server，填名称、命令和参数。
- 名称：写 blender-mcp，方便对话时区分；
- 命令：填启动 MCP Server 的命令，例如 npx blender-mcp；
- 参数：对应的启动参数，如 --port 9876；
- Environment：如果需要配置 Token 等信息，在这里填。
注册完记得点连接或验证，看到绿色 Connected 状态再开始对话。如果连接不上，优先检查 MCP Server 进程是否真的起来了——可以在终端单独跑一遍同样的命令，看有没有报错输出。这里分享一个经验：Antigravity 里填的命令如果是相对路径，有时候会因为工作目录问题找不到可执行文件。我建议直接填 Node 相关工具的绝对路径，或者先用 which npx 确认路径。
很多人在这步卡住，其实是没分清两个概念：Blender MCP 的“插件服务”常驻在 Blender 内部，而“MCP Server 进程”是给 AI IDE 提供标准协议接口的进程，二者之间通过 WebSocket 通信。所以你只启动 Antigravity 里的 MCP Server，但 Blender 插件没开，AI 照样连不上 Blender——必须两边都就位。我通常把两个窗口并排放着：左边 Blender，右边是 MCP Server 的终端日志，一眼就能看出请求到底到哪一步断了。
2.3 第一次握手：让 AI 读取 Blender 当前场景
跑通验证的方法很直接：新建一个空场景，然后在 Antigravity 对话框里问 AI：“请读取当前 Blender 场景的状态，告诉我场景里有多少个对象，列出它们的名称和类型。”如果链路正常，AI 会调用场景信息相关的 MCP 工具，返回类似“场景里包含 3 个对象：Cube、Light、Camera”的结果。我这里通常会再让 AI 新建一个 Cube 来验证执行能力。
实测下来，这一步最常见的失败点是“工具调用超时”。原因多半是 MCP Server 和 Blender 之间握手慢，或者 Blender 里弹出了 Python 运行确认框。Blender 有些操作会在后台弹对话框等用户确认，而 MCP 插件进程等不到回复就超时了。解决方式是在 Blender 偏好设置里把 Auto Run Python Scripts 打开，或者尽量让 AI 执行的脚本避开需要交互确认的 API。第一次握手成功之后，后面建模操作基本就都顺了，所以这一步值得多花点时间调稳。
3. 仓储数字孪生建模的核心设计
3.1 别急着建模：先定坐标、单位与命名规范
数字孪生项目里最怕的不是 AI 不会建模，而是 AI 建的模型毫无组织——对象名乱、坐标乱、单位不对，后面导出给前端引擎时全是坑。所以我在让 AI 动手前，先建立一套建模规范，并且把这些规范写进每条建模提示词里。
单位方面，Blender 场景统一设为米（Metric），仓储尺寸本来就是米级，导出 glTF 后默认单位也是米，省去换算。坐标基准方面，以仓库一个固定点为原点，比如仓库西南角地面，所有货架、设备坐标都基于这个原点计算，这样能和业务坐标表直接对表。命名规范方面，所有对象按“类型_编号_属性”命名，例如 Rack_001_Left、AGV_003、Conveyor_Segment_02。这个习惯在 MCP 链路里尤其重要，因为 AI 要靠名字精确定位对象，名字混乱等于让 AI 瞎摸。
场景组织方面，按 Collection 分层：Layout 存地面和边界，Storage 存货架，Equipment 存设备和 AGV，Effects 存标注和特效元素。这些规范不是洁癖，而是给 AI 的工作记忆减负。Antigravity 的 agent 在同一轮对话里上下文有限，如果每次操作都要先查询“有哪些对象再判断操作哪个”，很快就乱了。我的专业做法是先画一张布局草稿，把主要对象的名称和大致坐标写进提示词里，AI 就能按图索骥，减少无效查询。
3.2 货架、堆垛机、传送带的参数化建模思路
仓储数字孪生场景里，最常见的是三类基础模型：货架、巷道设备（堆垛机/穿梭车）、输送系统（传送带）。我的经验是，不要让 AI 每次去凭空捏造几何体，而是给它一套参数化规则，让 AI 按规则生成。
货架的标准结构是“立柱 + 横梁 + 层板”。我在提示词里会给 AI 定义参数：长 L、宽 W、高 H、层数 N、每层高度 h。AI 建模时用 Cube 搭接，每层生成层板，四角生成立柱。用 MCP 执行多次创建和变换命令，循环生成一排 20 列的货架，也就是几十次工具调用，AI 完全扛得住。关键是要求 AI 把这些零件放进同一个 Collection，并且父对象是一个空物体，这样整体移动货架时，只需要移动父物体。
堆垛机可以简化为“轨道底座 + 立柱 + 升降台 + 货叉”四部分组合，重点是升降台可以后期通过修改 Z 坐标来模拟运行位置。这也体现了 MCP 实时调参的价值：数字孪生做的是能动的场景，不是静态模型，堆垛机的升降、穿梭车的移动这些动作，在建模时就要预留出可动部件的独立对象。
传送带可以做成多段拉伸的 Box，每一段独立命名，然后通过一个父空物体做整体偏移。这样前端做动画时，可以直接把各段位移映射到输送逻辑上，不需要重新拆分模型。我给 AI 的提示词里会明确要求：先创建空物体作为分组节点，再在节点下创建子零件，这样做是为了后期前端遍历场景树时能拿到清晰的层级关系，而不是一堆散落的飘浮物体。
3.3 场景组织：集合（Collection）与实例化的工程化实践
Blender 的 Collection 机制是数字孪生场景组织的关键。我的做法是：先创建一个主 Collection 叫 WarehouseScene，下面按区块建子 Collection，例如 Zone_A_Storage、Zone_B_Picking。相同型号的货架，用 Collection 实例（Instance）而非复制对象（Duplicate），尤其当货架数量上百时，实例化能大幅降低场景内存和导出体积。
这里有个细节：Blender 的 Collection 实例在导出 glTF 时，如果导出选项没有开启“实例化”，会被展开成真实副本，体积又变大了。所以导出前要检查导出面板里的相关选项。我一般建模阶段用实例，导出阶段根据前端引擎能力决定展开还是保留。Three.js 的 GLTFLoader 对实例化支持一般，所以多数情况下我会选择展开，但保留父级 Collection 层级，前端再用矩阵变换统一控制。
这也就是说，建模规范和导出策略是一体的，不要建模一时爽，到前端才发现结构没法用。我在 MCP 建模提示词阶段，会把“Collection 层级”作为硬性要求写进去，并且每次建模结束后让 AI 汇报一遍 Collection 树结构，确认没有对象散落到主场景根目录。这个习惯帮我在后面做数据驱动和动画时省了大量返工时间。
4. 实操演示：让 AI 从空场景搭出一个货架库位区
4.1 向 AI 下达建模需求：提示词怎么写
我把一轮真正跑通过的操作记录放在这里。当时的需求是：在空场景中创建一条由两排货架组成的库位区，每排 8 列，每列 6 层，货架尺寸和间距按业务给定的数值。执行的提示词模板大概是这样：
背景：当前 Blender 场景是一个空场景，单位是米。请按以下参数创建仓储货架库位区：
- 创建两个 Collection：Zone_A_Storage 和 Zone_A_Equipment；
- 在 Zone_A_Storage 下创建两排货架，第一排中心 X=0，第二排与第一排的货架正面净间距为 1.6 米；
- 单排货架参数：列数 8，层数 6，单列宽 1.2 米，单层高 0.45 米，货架总高 2.7 米，货架深度 0.6 米；
- 每列货架作为一个独立对象，命名规则 Rack_A_C01 到 Rack_A_C16；
- 创建完成后，读取场景信息，核对对象数量和 Collection 结构。
关键点是：AI 无法自己脑补业务参数，你必须把数字给全，并且把命名规则、所属 Collection 这些工程约定写清楚。越细，后面的返工越少。这不是 AI 不行，而是数字孪生本来就需要确定性输入，AI 的价值是替你把几十次建模操作做了，而不是替你定需求。这种提示词写多了以后，我自己会沉淀成模板，下次换参数直接改几个数字就能复用到别的园区。
4.2 从单排货架到多巷道：一次典型迭代调参过程
第一次执行后，我让 AI 读取场景信息，发现它创建的 16 列货架都在同一排，第二排没有建出来。原因很快定位：我在提示词里写了“第二排与第一排的货架正面净间距为 1.6 米”，但 AI 在计算时把它当成了两排中心点距离，导致第二排直接和第一排重叠了。
这个例子特别典型：AI 对“间距”的理解受自然语言歧义影响。纠正方式是写清定义：“两排货架正面之间的距离为 1.6 米，货架深度 0.6 米，因此第二排中心 X 坐标 = 第一排中心 X + 货架深度 + 1.6 + 货架深度”。我把这个计算公式写进提示词，重新执行后两排货架的位置就完全正确了。这给我的启发是：在 MCP 建模场景里，凡是涉及坐标计算的地方，都尽量给公式而不是只给语义描述。
接着我又追加了一条指令：把第二排第 8 列货架的高度从 2.7 米改成 3.15 米，因为那块区域要放高货位。AI 通过修改对应对象尺寸完成，前后只花了几秒。这种实时迭代放在传统脚本流程里，至少要改参数、跑脚本、清空重来，虽然不难，但远没有对话式调整来得顺手。连续调了几轮之后，我对 MCP 的定位也发生了变化：它不只是“自动化工具”，更像一个可以随时叫来叫去的建模助理。
4.3 材质、配色与渲染视图的整理
几何体建完之后，别忘了给场景上材质。仓储数字孪生的视觉重点不是好看，而是语义清晰：不同功能区域用不同颜色，方便前台配置和运营识别。我的习惯是：货架主体用浅灰色金属材质（Metallic 0.6，Roughness 0.4）；高位货架区、冷藏区、普通区分别用蓝、绿、黄的标识色；地面用一个大平面，切割成不同颜色的 Zone 面片，命名和 Collection 的 Zone 保持一致。
这一步用 MCP 做，本质上是让 AI 调用材质创建接口，然后逐一赋值给对应对象。我在提示词里会给一个颜色表，比如“高位货架区=#2F6FE0，普通存储区=#E0A62F”。建议不要用默认的灰蒙蒙材质，那样导出到 Web 后因为光照不同，几乎看不出层级。另外，我一般会在建模完成后要求 AI 把渲染引擎切到 Eevee 并打开材质预览，这样我能在视口里直接确认颜色是否正确，而不是等到导出前端才发现一片灰。
5. 常见问题与排查技巧实录
5.1 Antigravity 侧连接报错与恢复
我实际遇到最多的是两类：一是启动 MCP Server 时进程直接退出，二是 Antigravity 显示连接失败或超时。进程直接退出的最常见原因，是命令里用了相对路径启动脚本，而 IDE 的工作目录和终端不一致。解决办法是把启动命令里的脚本路径、Node 路径全部改成绝对路径，并注意 Windows 下路径里的反斜杠要转义或用正斜杠。
连接失败还有一种隐蔽情况：Antigravity 版本升级后，MCP 配置项的名称或导入方式变了，旧配置虽然还挂在设置里，但实际没有被加载。这时候建议把旧 Server 删掉重新添加，而不是只改字段。我有一阵子升级后一直显示连接失败，查了半天，最后是删掉配置重新添加就好了。页面提示更新出错或 403 这类情况，很多也和配置缓存、服务版本不匹配有关，清缓存、重启、重建 Server 是通用三板斧。如果还不行，就去翻日志文件里 MCP Server 的具体错误，比在界面上猜有效得多。
5.2 Blender MCP 插件端常见问题
Blender 端常见问题包括：插件启用了但端口没监听、场景读取不到对象、AI 执行删除操作时报错。“端口没监听”一般是端口被占用，或者插件启动时要求的工作区类型不对。查端口占用可以用命令行工具查看，找到占用进程后关掉或改端口。改成别的端口，记得 Antigravity 那边的 MCP Server 参数也要同步修改。
“场景读取不到对象”的情况，多半是 AI 连接的 MCP Server 对应的 Blender 实例和当前打开文件不一致。如果有多个 Blender 窗口在跑，很容易连错实例。我的习惯是只开一个 Blender，并在插件面板里确认 Server 状态显示 Running。删除操作报错，通常与插件 API 和 Blender 版本不匹配有关，优先升级插件到适配当前 Blender 大版本的版本即可，这类问题的报错日志通常会在 Blender 的系统控制台里打印出具体 Python 堆栈，直接去控制台里搜关键字最快。
5.3 MCP 指令执行异常的排查思路
如果 Antigravity 的 AI 确实调用了工具，但 Blender 里没有任何变化，我会分三路排查：第一路看 Blender 插件面板的日志，确认 WebSocket 是否收到请求；第二路看 MCP Server 进程的 stdout，确认有没有执行报错的堆栈；第三路在 Blender 里手动执行 AI 要执行的 Python 操作，验证 API 本身通不通。这三路基本能覆盖绝大多数问题。
还有一种不太容易想到的情况：Antigravity 的 agent 可能在 MCP 工具执行前，把自己的假设写进了回复里，但实际没有调用工具就直接说“已完成”。这时候场景自然是没变的。检查方法很简单：要求 AI 在回复里附上它实际调用的 MCP 工具名和参数，如果它答不上来，说明它跳过了工具调用，需要调整提示词，让它必须通过 MCP 工具操作 Blender，不要假设操作结果。
这里还要强调一个通用经验：MCP 链路里，任何一步的日志都比人脑猜更能定位问题。我每次改完配置，都会同时把 Blender 的控制台窗口和 MCP Server 终端窗口开着，两边对照看。这样一旦出问题，几分钟内基本能锁定位点。这个习惯看起来笨拙，但真的帮我省了不知道多少“看着界面发呆”的时间。
这套 Antigravity + Blender MCP 的组合，我连续用了一周多，最大的感受不是“建模变快”这么简单，而是把数字孪生场景从一次性交付物变成了可以持续对话调整的活资产。你可以在上午让 AI 按新数据重排货架，下午又让它给某个区域换标识色，整个改造成本低到可以频繁试错，这对需求还在高频变化阶段的项目特别友好。
最后再分享一个小经验：如果想把这套流程稳定跑在团队项目里，最好把建模规范沉淀成一份文档，并把这套规范和提示词模板放到项目仓库中。AI 表现不稳定的地方，往往不是算力不够，而是规则没说清。把规则说清，MCP 链路就能成为一个相当可靠的生产工具。上篇主要讲的是环境与基础建模，下篇我会继续展开场景数据驱动、动画调试，以及导出 glTF 到前端渲染引擎的完整流程。
