1. 项目整体设计与思路拆解1.1 为什么选择 Antigravity Blender MCP 这个组合先说一下这个项目的背景。数字孪生Digital Twin这个概念在仓储物流、工厂自动化领域已经喊了很多年但从 0 到 1 落地一个能让业务方看得见、摸得着的 3D 智慧仓储场景一直是个不太轻松的事。传统的做法通常分两条路要么用 Unity、Unreal 这类重型引擎从建模、骨骼、材质一路做到光照烘焙、动画蓝图工程量大得吓人要么用 Three.js / WebGL 直接在浏览器里从零搭场景代码量可观而且没有 DCCDigital Content Creation工具帮助的话要手动去写几何体坐标、材质参数完全是体力活。这个项目我选择的是 Antigravity 作为 AI 智能体Agent驱动核心Blender 作为 3D 资产生产工具通过 MCPModel Context Protocol模型上下文协议把它们串起来。Antigravity 是目前个人项目里最能打的 AI 编程代理之一它不仅仅是“帮你写代码”还能像一个有判断力的工程师一样去规划任务、操作文件系统、调用外部工具、执行终端命令、按需安装依赖甚至自己去查找报错日志并修复问题。而 Blender 是开源领域最完整的 3D 建模套件它本身自带了一个基于 Python 的 API——bpy几乎所有通过 UI 能做的操作用 Python 脚本也都能做这就给了 AI 一个非常好的“操作面”。中间搭桥的 MCP 是近两年 AI 工具链里的一个关键协议。它相当于给 AI 智能体开了一堆“标准化的可插拔接口”让智能体不再局限于买卖 Tokens 的对话窗口而是可以实时调用外部工具、读取数据、操作软件。在这个项目里MCP Server 运行在 Blender 侧由一个插件即 Blender MCP提供它监听本地 WebSocket 端口接收 Antigravity 发来的指令再转成 bpy 调用。这个方案的优势在于AI 不需要理解 Blender 内部的复杂 API只需要按协议发送结构化的建模指令就行。数据的流向非常清晰——Antigravity 做规划决策Blender MCP 做命令执行Blender 负责产出最终模型最后再通过导出流程把模型转成前端可用的 JSON 资源。1.2 数字孪生仓储场景到底要建什么在实际动手之前我先把“智慧仓储数字孪生”拆解成了几个明确的需求模块这样后面跟 AI 沟通才不会跑偏。第一空间还原。仓库是一个有真实尺寸的物理空间不是随便搭个长方体就行。这个场景里我以 50 米长、30 米宽、9 米高的单层立体库为例用 1:1 的真实比例建模。货架区分为 5 排主货架每排货架 12 列、6 层单元尺寸按标准托盘位 1.2 米 x 1 米 x 1.5 米设计这样整个模型导入到前端 Three.js 里坐标、尺度都能和传送设备、AGV 的实时数据准确对应。第二设备模型。光有货架不算智慧仓储还需要考虑堆垛机、AGV 小车、输送线、提升机这些自动化设备。这部分我用的是可参数化建模的思路——货架的长宽高、层数、列数都做成变量设备模型做成可复用组件这样如果仓库尺寸变了只需要改参数重新生成不需要从头再建一遍。第三信息映射。数字孪生不只是一个好看的空壳它要把业务数据比如库存量、库位利用率、AGV 位置、任务状态实时映射到 3D 模型上。这部分的实现方式是Blender 里为每个货架单元、每台 AGV 建立独立命名的空对象Empty作为锚点前端加载模型后通过对象名和业务主键进行关联再在 Web 端用数据驱动的方式去更新颜色、位置、旋转角。建模阶段就把命名规范定下来后面做数据对接能省掉大量麻烦。第四形变与物流动线。仓储场景里最核心的逼真度指标是 AGV 和堆垛机的运行轨迹。这部分我采用几何节点Geometry Nodes加点位数据驱动的方式把轨迹线做成可编辑的路径曲线路径上按固定距离放置标注点再由前端在每一帧插值计算 AGV 的位置和朝向。前期模型里留好这些路径锚点后面 Web 端接入实时定位数据就顺畅了。选型的关键判断在于默认的搜索引擎式开发没法快速生成可交互的 3D 内容而 Antigravity Blender MCP 的组合本质上是在“能用自然语言驱动建模软件”和“能自动规划复杂任务”这两件事之间做了一个高速衔接。整个方案比传统方式节约了我大概三分之二的前期时间而且模型质量稳定不会出现手工一个个搭方块时漏掉细节的低级错误。2. 环境准备与工作区搭建2.1 软件版本与插件安装这个项目对软件版本还是有点要求的特别是 Blender MCP 插件依赖某些 bpy 接口版本太老会直接报错。我使用的组合是Blender 4.2 LTS Antigravity 最新稳定版 Python 3.11Antigravity 自带但最好独立装一个因为后续要用来运行数据处理脚本。Blender 4.2 的几何节点系统比 3.x 版本完善很多MCP 插件的兼容性也最好。Blender MCP 插件的安装方式和普通插件一样先到 Blender 的“编辑 偏好设置 插件”面板点击“从磁盘安装”选择 zip 包安装完成后在插件列表里找到 “Blender MCP Server” 并勾选启用。注意启用后右侧面板N 键侧栏会多出一个 MCP 标签页里面会显示 WebSocket 服务器的监听地址和端口默认通常是ws://127.0.0.1:8080这个地址后面要填到 Antigravity 的 MCP 配置里。有几个细节很容易踩坑插件启用后如果端口被占用Blender 不会弹报错只是在侧栏面板显示“failed to start server”。这时候用lsof -i :8080Mac/Linux或netstat -ano | findstr :8080Windows查一下什么在占用端口直接把冲突进程结束或改端口。我之前碰到过本机 Docker 占用 8080 口的情况改到 8765 就清爽了。在 Windows 上运行 Blender MCP必须保证安装 Python 的时候勾选了“Add to PATH”否则插件里有些子进程调用可能找不到 Python 解释器导致回传结果异常。MCP 服务端和 Antigravity 需要在同一台机器上因为它是走本地 WebSocket 通信的如果你想跨机器访问需要额外做安全转发我不建议你在实际项目里那么搞风险大于收益。2.2 Antigravity 中的 MCP 配置与鉴权Antigravity 的 MCP 配置入口在它的设置面板里新版界面下路径是Settings AI Providers MCP Servers。配置本质上就是一个 JSON告诉 Antigravity 有哪些外部工具可以调用、怎么连、用哪种鉴权方式。对于 Blender MCP一个标准的配置块长这样{ mcpServers: { blender: { type: ws, url: ws://127.0.0.1:8080, auth: { type: none } } } }如果你在公网或跨网络环境下想用一些托管 MCP 资源比如某些公网 MCP 市场提供的大模型工具集那就要在 Antigravity 里把鉴权字段换成Bearer Token或者OAuth流程。我在测试时接入过公网 MCP 网关使用 token 时需要在 JSON 里这么写{ mcpServers: { public_mcp: { type: ws, url: wss://your-mcp-gateway.example.com/mcp, auth: { type: bearer, token: your-token-here } } } }提示wss://是 WebSocket Secure 协议和ws://的区别堪比https和http。本地调试用ws://就行如果在私有云或者跨集群部署强烈建议用wss://并开启鉴权避免未授权的机器直接向你的 3D 建模服务发指令。配置完了以后在 Antigravity 的对话窗口里直接输入“列出当前可用的 MCP 工具”如果能列出类似create_cube、set_material、import_gltf这类工具名就说明 MCP 链路已经通了。首次连通时如果遇到超时多半是因为 Blender MCP 插件的侧栏面板里没有点“Start Server”。2.3 工作区目录与数据约定搭建好工具链后我强烈建议把项目目录结构也一并规范好。数字孪生工程后期会涉及模型文件、纹理贴图、数据快照、前端工程、日志等多类文件如果所有东西堆在一个目录里Antigravity 在自动规划任务时很容易搞混路径。我这边采用的结构如下warehouse_digital_twin/ ├── blender/ # 所有 .blend 工程文件 ├── exports/ # 导出的 glTF/JSON/资源包 ├── data/ # 业务数据快照CSV、JSON ├── assets/ # 贴图、材质、HDR ├── scripts/ # 自建 Python 数据脚本 └── frontend/ # Three.js / Web 前端工程这个结构有几个好处Antigravity 在生成文件时能快速判断该往哪个子目录写导出资源时exports目录可以被前端直接引用不需要额外做文件路由映射数据快照隔离减少了 AI 在建模时不小心改动到真实业务数据的风险。同时模型命名规范也得定死。货架用shelf_row_col_layer格式AGV 用agv_01、agv_02库位锚点用slot_x_y_z。初期建模时命名规范做得越细后期 Web 端对接数据时就越省心。我第一次做时命名比较随意结果前端对接时不得不回 Blender 逐个改名字白白浪费了大半天。3. 核心实操让智能体从零构建仓储模型3.1 结构光扫描与拉框数据的前期处理注意项目热搜词里提到的“3D 结构光相机”和“3D 点云拉框”在这个项目里它们的作用不是直接生成最终模型而是用于生成真实库位的障碍物边界、托盘位姿以及货架立柱的精确位置。真实场景中我们会用一台 3D 结构光相机放置在仓库上方的巡检轨道上对整个库区进行扫描得到带有 XYZ 坐标和反射强度信息的点云数据。点云数据的后处理需要经过几个步骤去噪 → 地面分割 → 欧式聚类 → 盒状包围框拟合。所谓“拉框”本质就是对聚类后的点云用最小体积的有向包围盒OBB去贴合获得每个库位、每个货架立柱在全局坐标系下的位置、尺寸和偏航角。这个过程的产出就是一份 CSV 或 JSON 文件里面每行是一个对象object_id, center_x, center_y, center_z, size_x, size_y, size_z, yaw。Antigravity 可以直接读这份文件来动态创建 Blender 模型。Antigravity 在这里的核心价值在于它可以自动完成“从点云数据到完整建模指令”的转换。在提示词里告诉它“读取data/shelf_layout.json为每个对象创建对应尺寸的立方体并设置正确的旋转角度”它会自己规划出循环创建对象的 Python 代码再通过 MCP 批量执行这个过程手动操作的话大概要 20 多分钟AI 跑通常不到 1 分钟就完成了。3.2 仓储模型的提示词设计与分阶段构建把任务拆成几轮对话来推进比一次性给 AI 一个超大提示词的稳定性要高得多。我分成了四个阶段每个阶段都对应一组明确的交互指令。第一阶段地面与墙体。基础提示词可以这样设计“在 Blender 中新建一个空白场景删除默认 Cube。以平面方式创建 50m x 30m 的地面厚度 0.2m使用混凝土材质。创建四面墙体高度 9m厚度 0.4m材质使用浅灰色。把场景原点设置为地面中心 (0, 0, 0)。”这里要注意Antigravity 会通过 MCP 调用create_plane、create_box、set_material这些工具完成建模。每一轮操作结束建议让 AI 返回一个简短的执行摘要内容包括创建了哪些对象、坐标范围、面数方便你确认没有偏差。第二阶段货架与库位。这一阶段是核心建议用参数化方式驱动“根据data/shelf_layout.json中记录的货架信息创建 5 排货架。每排货架包含 12 列、6 层每个库位尺寸为 1.2m x 1m x 1.5m。货架立柱使用金属材质横梁使用深蓝色材质。在每个库位中心位置创建名称为slot_row_col_layer的空物体Empty用于后续数据挂载。”参数化指令的好处是如果仓库尺寸调整只需要改 JSON 文件里的数字重跑一次提示词就能完成整个货架区的更新不用重新建模。每一层的层高我留了 0.1m 的间隙作为货架横梁结构厚度这样模型导入到 Web 端后货与货之间不会出现穿模。第三阶段设备与动线。设备建模建议用现成的基础几何体拼接。AGV 可以直接用“Box Cylinder Sphere”组合出来车体一个 1.2m x 0.8m x 0.4m 的长方体四个车轮用半径 0.15m 的圆柱体车顶部配一个激光雷达柱体半径 0.1m、高度 0.3m。这样出来的模型面数低、结构清晰前端做动画也不会卡。动线设计我用的是 Blender 的路径曲线Curve。提示词可以这样写“创建 3 条路径曲线分别命名为 route_1、route_2、route_3用于 AGV 行驶动线。曲线从仓库入口开始经过各排货架之间的主通道终点是出库口。每条路径由直线段和 90 度圆弧段组成。”把这些曲线对象保存在一个专门的集合里前端加载模型时可以直接读取曲线的控制点生成相应的行驶轨迹。这套做法的好处是路径数据直接在模型里Web 端不需要另存一套坐标表数据天然一致。第四阶段导出与前端适配。Blender 模型最终要交给 Three.js 使用最稳妥的格式是 glTF 2.0。但直接导出整个场景会让文件非常巨大所以我会按功能分组导出比如environment.gltf地面墙体、shelves.gltf货架库位、equipment.gltfAGV输送线、routes.gltf路径曲线和锚点。导出用 Antigravity 调用 MCP 里封装好的导出工具完成。在 Blender MCP 中可以自己定义一个导出函数绑定到快捷键或通过 MCP 调用核心思路如下import bpy import json def export_scene_section(collection_name: str, export_path: str): # 备份当前选中状态 selected bpy.context.selected_objects bpy.ops.object.select_all(actionDESELECT) # 仅选中目标集合内的对象 for obj in bpy.data.collections[collection_name].objects: obj.select_set(True) # 导出为 glTF 2.0 bpy.ops.export_scene.gltf( filepathexport_path, export_formatGLTF_SEPARATE, use_selectionTrue, export_yupTrue, export_applyFalse ) # 恢复选中状态 bpy.ops.object.select_all(actionDESELECT) for obj in selected: obj.select_set(True) # 通过 MCP 暴露的参数 export_scene_section(equipment, //exports/equipment.gltf)export_yupTrue这个参数容易忽略但它是 Blender 和 Three.js 之间坐标系的转换关键。Blender 默认是 Z 轴向上Three.js 默认是 Y 轴向上如果导出时不设置这个选项前端模型会躺在地上还得再写一个轴校正脚本非常麻烦。3.3 从 Blender 导出 JSON 数据的细节热搜词里特别提到了“blender如何导出json”这说明确实有不少人在这块犯过难。实际上 Blender 的导出能力可以分成两层一是静态模型资源glTF/obj/fbx二是场景结构化数据JSON。模型资源给 Web 端提供几何体和材质信息JSON 则给 Web 端提供“语义信息”比如哪个库位叫什么名字、它的世界空间坐标和尺寸是多少、库位上目前有没有绑定货物数据。我建议用一个自定义导出脚本来生成这个 JSON。它的本质是遍历场景中的所有对象把对象类型、名称、世界坐标、旋转、缩放、尺寸、自定义属性全部抽取出来再按照指定的排序规则输出。脚本核心部分长这样import bpy import json def dump_scene_metadata(): scene_data { objects: [], cameras: [], lights: [] } for obj in bpy.data.objects: entry { name: obj.name, type: obj.type, location: list(obj.matrix_world.translation), rotation: list(obj.matrix_world.to_euler()), scale: list(obj.matrix_world.scale), } # 提取自定义属性例如库位编码 for key in obj.keys(): if key not in [_RNA_UI]: entry[key] obj[key] # 如果是网格对象记录包围盒尺寸 if obj.type MESH: bbox [obj.matrix_world bpy.types.Object .bound_box[i] for i in range(8)] entry[bbox_size] [ max(v[i] for v in bbox) - min(v[i] for v in bbox) for i in range(3) ] scene_data[objects].append(entry) with open(//exports/scene_metadata.json, w) as f: json.dump(scene_data, f, indent2, defaultstr) dump_scene_metadata()导出 JSON 之后前端 Three.js 的加载逻辑就非常清晰了用GLTFLoader加载模型用fetch加载 JSON 元数据把 JSON 里每个对象的名称与加载后的 3D 对象一一对应起来后续做点选高亮、数据扇区映射就都有了基础。3.4 核验模型正确性的三个关键动作AI 建模速度快但不代表它产出就一定对。每次一轮模块建完我习惯做三件事来核验第一检查面积和体积。在 Blender 的“3D 打印工具箱”面板中可以直接看到选中物体的表面积和体积。如果地面和墙体的数值和预算差得太多十有八九是尺寸参数写错了。比如 50m x 30m x 0.2m 的地面体积算出来应该是 300 立方米左右如果 AI 给的是 0.3 立方米那肯定是参数单位错了。第二检查面数。数字孪生场景如果是给 Web 端用的必须控制总面数。纯几何体拼接的方案整个仓库控制在 20 万面以内会有很好的流畅表现如果用雕刻或细分曲面做了高精度模型动辄上百万面那前端浏览器基本扛不住。测试时我一般用 Blender 的“统计”面板查看整体三角形数量如果超出预算就让 AI 用减面修改器或者直接用更少分段的基础几何体重建。第三检查命名与坐标。用 JSON 导出工具跑一遍确认所有slot命名的空物体坐标都在货架区域范围内没有出现坐标跑到墙体外面去的异常数据。命名规范和坐标范围检查可以写成一个自动化断言脚本后续每次建模完成后自动运行。4. 常见问题与排查技巧实录4.1 Antigravity 的 403 与资格校验问题热搜词里有“antigravity 403”和“antigravity eligibility check failed”这两个问题在实际使用 Antigravity 时非常典型而且往往和项目本身的工程代码无关纯粹是账号或网络环境层面的问题。403 错误最常见的触发场景是在未受支持的地区访问 Antigravity 服务、账号没有完成初始资质验证、或者请求触发了风控策略。解决思路第一步是检查网络代理配置是否正常如果代理出口不稳定Antigravity 的服务端可能判定为异常请求。注意我这里说的网络代理指的是常规的企业内网 HTTP 代理配置不是任何违规工具。第二步是确认账号在服务商的白名单内部分 AI 编程工具开放早期是灰度测试制需要申请后才解锁完整能力。第三步是检查认证 Token 是否过期在 Antigravity 里退出重登一般能刷新。“Eligibility check failed”则通常出现在新加入的用户或切换工作区时本质上是服务端对你的账号所在组织或订阅计划做资格校验失败。处理方式进入账号设置页确认订阅状态是 active然后清除本地缓存再重新打开客户端。如果还是不行去官方帮助中心查一下最新的支持地区/订阅计划变更公告这类问题往往跟服务商调整策略相关升级订阅计划经常能直接解锁。注意如果你在本地网络里用了自建的代理转发比如企业网关来访问 Antigravity 云端 API一旦代理返回了非预期响应体客户端就会显示 403。这种情况排查时先绕过代理测试一次如果直连正常说明代理规则里需要把 Antigravity 的域名或 IP 段加入直连白名单。4.2 “Agent execution terminated due to error”的根源诊断项目运行过程中Antigravity 的 Agent 偶尔会突然终止执行并抛出这个错误。根据我多次实战总结绝大多数时候问题出在“工具调用链”上——Agent 在规划好一系列任务之后去调用 Blender MCP 时某个步骤失败了但异常没有正确处理MCP Server 直接抛出了 fatal 级别的堆栈错误Antigravity 侧就只能把整个会话终止。最常见的原因有四个Blender 中执行了视图切换或数据加载等造成主线程阻塞的操作MCP 响应超时Agent 认为工具不可用。调用的 bpy API 在当前版本中已经改名或弃用脚本执行报错后插件没有对 TypeError 做兜底。导出目录不存在gltf 导出函数写入文件失败。场景中出现了非流形几何比如立方体内部有重叠面后续布尔运算或网格检查操作异常。我的排查顺序是先看 Antigravity 的会话日志里那一段“Tool Call”的输入输出详情找到具体是哪个工具的哪一条指令触发了崩溃然后去 Blender 的 MCP 插件控制台看 Python stack trace 的尾部三行如果涉及bpy.ops操作失败多数是环境状态问题比如需要先进入正确的模式最后再回看工作区里是否有缺失目录或文件。如果错误信息指向“某个对象为空”那基本可以判断是数据源问题——AI 在建模循环里读取 JSON 文件时某一条记录的字段缺失或格式不符导致它生成了一个无效对象。建议在 JSON 解析工具调用前加一个数据校验步骤比如用 Pydantic 或简单的assert检查字段完整性和类型。4.3 MCP 连接超时与端口冲突数字孪生项目要反复重启 Blender、刷新 MCP 插件配置连接超时在前期几乎每天都遇到。症状通常是Antigravity 对话里已经能看到工具列表但真正执行建模指令时等很久没有反应最终报MCP timeout。背后原因大概率是Blender 在加载大场景时UI 主线程被占用MCP Server 发送的回执消息没能及时被处理。针对这个问题有两个层面的解法。第一层是插件层面给 MCP Server 加一个独立的线程池让工具调用不在 Blender 主线程里同步阻塞。修改 MCP 插件源码时注意把需要调用 bpy API 的逻辑放进bpy.app.timer回调中排队而不是直接在 WebSocket 消息处理函数里面执行。否则你不仅会看到超时甚至可能在拖拽视图时出现 Blender 崩溃。第二层是使用层面养成“操作完一轮后保存文件再继续”的习惯。.blend文件可以随时保存保存过程极快但如果你在依赖 Blender 线程的前提下长时间不保存一旦崩溃整个建模进度就全丢了。我在项目里让 Antigravity 每完成一个阶段的建模任务就主动执行一次bpy.ops.wm.save_mainfile()这个习惯救了我好多次。4.4 更新出错与插件版本的回退策略搜热词里有一条“antigravity 更新出错”这类问题在快速迭代的 AI 工具上很常见。我的建议是正式项目进行到关键节点时不要立刻升级到最新版本。先用一个专门的环境跑通你要用的功能确认没有问题后再切到正式环境升级。如果升级后出现问题最快的还原方式是使用官方提供的版本回退渠道或者直接重新安装上一个稳定版本。对于 Blender 侧的插件我每次更新之前会把blender_mcp.zip做一次异名备份把旧版本插件目录手动复制出来存放好。更新后如果发现和新版本的 Antigravity 存在兼容问题只需要在偏好设置里卸载新插件再从备份目录手动安装旧版就行。一次回退操作不到三分钟相比找人远程协助排查兼容性问题这个时间成本几乎可以忽略。还有一个值得注意的点Blender MCP 插件更新后有时会默认重置端口号你在 Antigravity 里配置的 URL 是旧的自然就连接不上了。更新后第一件事就是检查侧栏的端口显示是否和原来一致不一致的话改回 8080 就好。5. 从建模到前端可视化的衔接经验5.1 用锚点对象承载业务数据前端加载 3D 模型后最大的需求是“点击某个货架格子能看到库存信息”。如果不做任何处理前端只能在渲染层面拿到一个几何体但不知道该几何体对应业务库位编码。解决办法就是在建模阶段用空物体Empty作为锚点绑定到真实库位的位置上。空物体不渲染任何几何体但它有名字、有坐标、有层级关系完全可以把库位编码、库位类型、最大载重这些属性塞进自定义字段Custom Properties里。在前端 Three.js 里加载模型后按名称查找这些空物体然后给它们创建透明的点击区域比如一个小立方体这样点击命中时就可以通过userData拿到库位编码再去请求对应的业务数据。我设计锚点命名时用了slot_row_col_layer的格式比如slot_03_07_02表示第 3 排第 7 列第 2 层。这个命名规范在 Blender 和前端代码里完全统一后续写查询逻辑时只需要解析字符串就能获得三维索引非常省事。5.2 数据驱动的物资着色逻辑数字孪生最直观的效果是用颜色表达库位状态。比如“蓝色 空库位、绿色 有库存且正常、黄色 库存量低于安全线、红色 超储或异常”。这个效果在 Blender 里建模时不处理而是把材质赋值逻辑完全交给前端。具体做法是为每个库位锚点创建对应的透明选区立方体在导出时把透明度设为 0.001基本不可见但可拾取。前端拿到业务数据后在每一帧或数据更新事件里切换选区立方体的材质颜色。这样避免了为每种状态预建不同颜色的模型大大减少了模型体积而且切换颜色是运行时行为数据的实时性更好。不要直接把颜色材质设置为“发光的自发光材质”因为这样在浏览器里看起来过度刺眼而且无法体现场景光照。应该用MeshStandardMaterial配合场景里的若干动态光源让颜色显示既清晰又不失真。5.3 大模型导出与纹理路径问题模型导入到 Three.js 后出现“贴图全部丢失”是非常常见的问题。根因基本在于 glTF 导出时纹理贴图使用绝对路径而且贴图文件没有和.gltf放在同一个目录下。解决办法非常简单导出的目标目录结构要固定比如exports/ ├── environment/ │ ├── environment.gltf │ ├── environment.bin │ └── textures/ │ ├── concrete.jpg │ └── metal.jpg然后在 Blender 导出面板上把贴图格式设置为“Automatic”确保每个纹理都嵌入导出的textures子目录。前端加载的时候GLTFLoader会依据 glTF 文件内部引用的相对路径自动加载纹理不需要额外手写路径映射。如果你是在 Antigravity 中通过 MCP 让 AI 导出建议在提示词里明确要求“导出后检查 textures 目录是否存在且贴图数量与材质数量一致”。这个检查可以让 AI 自动完成省去手动核对时间。5.4 压缩模型面数与加载优化智慧仓储数字孪生场景频繁涉及 AGV 动画、视角旋转、多客户端同时打开前端性能非常关键。建模阶段控制面数是第一步但仅仅这样还不够。我在实操中的流程是先从 Blender 导出高保真模型然后用 gltfpack 做一个压缩这个工具可以在保持视觉差异可忽略的前提下把 glTF 文件体积压缩 50%~70%大幅缩短前端启动加载时间。命令很简单gltfpack -i shelves.gltf -o shelves.packed.gltf -cc参数解释-cc是启用量化压缩-i和-o分别是输入输出文件。跑完之后对比一下文件大小和可视化效果如果压缩过头出现了明显的棱角可以调整-tc纹理压缩等级和几何量化参数。另外Blender 的“Decimate 减面修改器”也可以对高精模型做近无损减面我一般把表面面积误差控制在 1% 以内这样视觉上看不出差别但面数能降低一个量级。比如一个有 5 万面的货架减到 2 万面后端到端流畅度会有肉眼可见的提升。6. 操作中积累的经验与扩展方向这套工作流跑顺之后收益是很明显的。我测下来的感受是一个包含 5 排货架、60 个库位、3 台 AGV、2 条输送线和完整动线路径的仓库模型从零开始用 Antigravity 加 Blender MCP 构建耗时差不多 40 分钟到 1 小时而过去纯手动操作的话熟练的建模师至少需要一整天而且还不算反复修改调整的时间。最关键的是用 AI 驱动建模时所有操作步骤都有日志和代码可回溯不会出现“当初这个模型怎么建的现在完全想不起来”的情况。实际做的时候建好模型之后不要急着直接交付强烈建议做一次碰撞检测和物理检查。比如 AGV 高度是否超过了货架底部横梁的净空高度通道宽度是否满足双向避让所需的最小转弯半径。这些检查虽然也可以在 Web 端做但在 Blender 里直接检查更直观、更快。打开“物理”属性面板为 AGV 模型粗略添加碰撞体然后沿路径曲线拖动它看有没有和货架发生穿透。Antigravity 也能协助做这项工作只需要在提示词里要求“逐个检查路径曲线段的半径是否大于 AGV 最小转弯半径”它会自动计算并给出报告。后面我们还可以继续把这个方案往几个方向扩展。目前 Antigravity 驱动的建模还是以规则几何体为主对于更复杂的异形设备可以用 Photogrammetry摄影测量先扫描真实设备生成高精网格再在 Blender 中做自动减面和重拓扑这也是数字孪生项目里常见的“实模一致”路线。数据层面目前是静态 JSON 快照驱动后续可以直接接入一个 WebSocket 数据总线让 AGV 的实时位姿、库位占用状态直接驱动前端三维场景的状态更新这样整个仓储数字孪生系统就从“可视”进入了“可管”的阶段。最后分享一个我踩过的小坑在 Blender MCP 自动建模的过程中如果场景里开了 N 多修改器Modifier比如镜像、倒角、细分AI 有时会因为修改器依赖顺序的问题导出异常模型。建议每个建模阶段结束后让 Antigravity 自动把所有修改器“应用Apply”一次再进入下一阶段。以前这个坑让我吃过亏模型在 Blender 里看起来完美一导入到 Three.js 就结构全错后来把这步加到提示词里就再也没出过这种问题。