最近在折腾智慧仓储的数字孪生项目试了一圈工具链最后锁定在 Antigravity Blender MCP 这个组合上。先说结论这套方案特别适合做“程序化生成 AI 辅助建模”的仓储场景尤其是不想从零手撸 Three.js、又想快速产出质感不错的三维原型的场景。这篇先讲环境搭建、工具链打通、把仓储里最常见的货架、托盘、堆垛机用 AI 对话的方式建模到 Blender 里顺便聊聊数字孪生场景在实操中会踩到的坑。整理过程比较啰嗦几乎是全程真实记录希望能给同样在做前端数字孪生、3D 场景可视化或者智慧园区、智慧仓储方向的朋友一点参考。先说清楚这套东西各自是什么。Antigravity 是现在比较火的云端 AI 代理开发环境它能直接操作云容器、跑命令、装依赖、启动服务相当于给 agent 配了一台真正的 Linux 机器。Blender MCP 则是把 Blender 的 Python API 暴露给 AI 智能体的桥梁让大模型能通过 MCP 协议直接调用 Blender 的命令比如建网格、加材质、摆相机、渲染。两者合在一起就能实现在浏览器里指挥 agentagent 再去指挥 Blender最终生成一个能渲染、能导出、能被 Web 端用的 3D 仓储场景。为什么这个组合值得写因为我试过三条路。第一条是纯 Three.js 手写场景搭建速度和视觉质量很难兼顾一个货架参数调半天真实光照还得自己调 HDR。第二条是用传统建模软件手动搭Blender 熟练工做一个带纹理的仓库也要一晚上。第三条就是现在这套Antigravity 里的 agent 去查文档、写 Python 脚本、调 MCP 工具它能把“我想要一个双深货架8 排 6 层带托盘位”转化成可以执行的建模指令。真正的价值不在于省掉手工拖动鼠标那一步而是把建模过程变成了“可对话、可参数化、可一键重来”的工程流程。1. 内容整体设计与思路拆解1.1 数字孪生仓储场景的核心需求拆解做智慧仓储数字孪生本质上是把物理世界的仓库在数字世界里复刻一份然后让这份数字副本能对接真实数据比如库位占用、设备状态、任务队列。这个核心目标决定了我们建模的时候不能像做效果图一样自由发挥必须带着“数据可映射、位置可对齐、结构可分层”的思想去搭场景。我在动手前拆了一下需求仓储场景至少要包含这样几类对象货架系统是最核心的因为绝大多数业务数据都挂在库位上托盘和货物是第二层它们承载库存数量、批次、状态这些信息搬运设备是第三层也就是堆垛机、AGV、输送线它们反映运行状态和任务执行过程然后才是建筑结构、地面标识、灯光、安全设施这些辅助元素。传统做法是一个一个手动建效率低而且后续如果卖家的规划变了——比如货架从 6 排改成 10 排、层高从 1.6 米调到 2.2 米——就得回到建模软件里重新调整等于推翻重来。使用 Blender 的 Python 脚本生成就完全不一样把货架的长宽高、排数、层数、货位尺寸都定义成变量一键就能重生成。而 Blender MCP 的加入把这一步里的“定义变量、写循环、批量实例化”这些操作通通交给了 AI agent 来处理人只需要说需求和看产物。1.2 为什么选 Antigravity Blender MCP 这个组合选择这套组合不是图新鲜而是它把传统建模流程里的几个痛点一次性解决了。第一个痛点是环境不一致。以前本地装 Blender、装插件、配 Python 环境每个人的机器情况都不一样光是把 MCP 服务跑通就够折腾老半天。Antigravity 提供的是云端容器环境是标准的 LinuxBlender 装好后直接在一个干净环境里跑代理还能自己去解决依赖问题省掉了大量环境适配的苦工。第二个痛点是“人机语言”的翻译成本。直接学 Blender Python API 的曲线比较陡特别是 bpy 的 API命名风格非常工程化查文档都很费劲。MCP 协议把 Blender 的能力封装成了一个个工具比如“新建盒子”“添加材质”“设置相机”大模型用自然语言理解和调用这些工具相当于在一张项目图之上又叠了一层“操作语义层”。我不用再记 add_mesh_box 的完整参数签只要说“建一个长 2 米、宽 1 米、高 0.15 米的托盘”agent 自己会去匹配工具和参数。第三个痛点是要快速迭代。数字孪生项目需求变得非常快客户今天说换个货架布局明天说加两台 AGV后天又说场景里要显示温湿度传感器。用 MCP 方案这些修改基本就是一轮对话的事agent 生成新的 Python 脚本执行结果直接出现在 Blender 里。从 0 到 1 的建模速度快从 1 到 N 的迭代速度更快这对做项目交付的人来说太重要了。1.3 方案的适用边界和三个需要注意的问题任何方案都有适用边界先说清楚哪些场景适合用它。最适合的是批量化和参数化程度高的场景比如仓储库房、园区楼宇、机房布局、停车位规划对象形状规整、大量重复。这些对象用程序生成比手工建模省事得多AI agent 写循环脚本的能力又天然匹配这类任务。更适合做前期的空间验证和方案汇报快速出一个带光影、可交互、能导出的白模或简模让非技术背景的客户也能直观看到效果。不太适合的则是高精度工业孪生。比如要还原一台复杂设备的内部结构和细小零件或者做流体力学、动力学仿真级别的场景Blender MCP agent 的组合就力不从心了那种需求还是得回到 CAD 数据转换和专业仿真工具。另外有三个问题必须提前意识到。第一Antigravity 的 agent 在 Blender 上执行复杂操作时可能会出现“脚本逻辑对了但实际效果不对”的情况尤其是涉及选择模式、活动对象这类 Blender 状态相关问题时需要有一定的排查能力不能完全做甩手掌柜。第二MCP 工具调用是同步阻塞式的一次生成几十个货架还带着布尔运算的时候耗时比较长有时候会产生超时。第三Blender 的 Eevee 和 Cycles 渲染器在 MCP 代理里调用输出图片的分辨率、采样数都要提前约定否则 AI 会按默认低参数出图产物质感不够。这些都是实操中会反复遇到的细节后面会展开讲。2. 环境准备与工具链搭建Antigravity 容器、Blender 与 MCP 配置2.1 Antigravity 项目初始化与容器环境确认在 Antigravity 的 Web IDE 中创建项目后第一步不是急着写代码而是先确认云端容器是什么配置。我一般先跑一条系统信息命令看 CPU、内存、磁盘如果机器太弱后头 Blender 渲染会非常煎熬。创建 Blender 项目时Antigravity 预制模板里已经放好了 Python 环境和 Node 环境这两样是必须的其他都可以后续再装。容器环境确认完第二步是装 Blender。注意不要用 apt 直接装虽然 apt 装起来快但版本往往比较旧MCP 插件和较新版本的 Blender 兼容性更好。我建议在 Blender 官方镜像源下 tar.xz 包解压到 /opt 目录然后把可执行文件软链到 /usr/local/bin这样全局可以直接执行 blender。装完之后要跑一下 blender --version顺手记录下大版本号后面装 MCP 插件时要用。然后是安装 Blender MCP。这个项目在 GitHub 上能找到有清晰的安装说明。它包含两部分一部分是 Blender 插件端需要复制到 Blender 的 addons 目录并手动在 Blender 的偏好设置里开启 Networking 功能另一部分是 MCP 服务端可以把它配成 Antigravity 的 MCP server 配置让 agent 能连接和调用。我遇到过最坑的一件事是 MCP server 的配置格式。各个平台对 MCP 配置的写法略有差异。在 Antigravity 里配置 MCP server 时需要填 command 和 argscommand 一般是指向虚拟环境里的 Python 解释器路径args 里带启动脚本的路径。这里有一个很容易错的点虚拟环境路径和启动脚本路径必须是绝对路径。如果 Antigravity 的容器偶尔换了工作目录相对路径就会报各种“找不到模块”或者“连接拒绝”的错误。我第一次配的时候agent 始终连不上 MCP server排查了半天其实原因很简单就是路径写成了相对路径。2.2 Blender 端插件监听与安全鉴权设置Blender 端受 MCP 控制的机制是启动后开启一个本地 WebSocket 服务端。MCP server 通过向这个服务端发 WebSocket 请求来驱动 Blender 执行命令。开启服务的入口在 Blender 的“偏好设置 - 插件 - Blender MCP”勾选启用后侧边会出现一个 N 键面板里面有“连接”和“断开”按钮同时能看到当前的地址和端口。默认情况下监听的是 127.0.0.1 的某个端口。就我个人经验不要乱改它除非容器端口映射需要特殊处理。这里要特别提醒两个安全问题。第一Blender MCP 默认情况下没有鉴权也就是说任何能连到这个端口的人都能直接驱动你的 Blender 执行任意 Python 命令比如删除全部对象、修改文件、执行系统命令都可以做到。如果是本地使用问题不大但在云容器里一定要确保端口不暴露到公网或者接一层反向代理只允许 MCP server 访问。第二Antigravity 的 agent 运行容器里和 Blender 进程在同一个网络空间正常情况下连通性没有问题但是容器重启、网络模式变化会让地址失效需要检查并清理残留端口。启动 Blender 并处于后台等待连接状态时有个细节容易踩坑。在云容器里没有图形桌面直接输入 blender 命令会报错因为它默认去找显示器。处理的办法是加 -b 参数也就是 background mode然后再指定 Python 脚本路径或者直接进入监听状态。我用的是类似 blender -b -P 某个脚本.py 这样的方式脚本内部会加载 MCP 插件并启动网络服务。实际跑通后Blender 就以“无头模式”挂在容器里等着 MCP server 的调用。这也是这套方案能在云 IDE 里跑通的关键。2.3 MCP Server 与 Antigravity Agent 的连接配置细节把 MCP server 接入 Antigravity本质是在代理设置里声明一个外部工具服务。配置格式类似 JSON核心字段有名称、命令、参数、环境变量。在 Antigravity 的项目配置文件里可以增加一段 mcpServers 定义把刚才装好的 MCP server 启动命令填进去。配置完成后可以在 Antigravity 的 MCP 管理面板看到该 server 的状态如果显示在线说明 agent 已经能够发现并调用里面的 tools。Blender MCP 向外暴露的工具包括但不限于创建基础物体Cube、Plane、Cylinder、修改物体属性位置、旋转、缩放、添加材质与颜色、创建灯光与相机、执行渲染、导入导出文件等。我在第一次集成测试时出现了 403 错误agent 调用工具时被拒绝。仔细排查后发现是因为 MCP server 的模式配置和 Antigravity 的默认调用方式不匹配。解决方式是检查 server 配置里的 transport 类型确保是 streamable-http 或 stdio 中的正确那一个同时要确认服务端日志中记录的 connection 来源 IP以及是否被本地防火墙规则拦截。这里也提一句网上有些文章提到的“反代”思路主要是用于服务间通信路径优化但如果是单纯为了连 MCP server完全没有必要弄反代容器内直接用即可加上反代反而容易弄出连接识别问题。3. 核心实操用 AI 对话在 Blender 里搭建智慧仓储场景3.1 先搭骨架仓库地面、立柱、墙体与坐标对齐在进入具体的建模操作之前我要先统一一下坐标系的规范。数字孪生场景后面的数据对接、相机漫游路径、AGV 路线全部依赖空间坐标。所以我给 agent 定了三条铁律地面用 X-Y 平面Z 轴永远向上库位坐标以米为单位。对话的第一步是让 agent 建一个长 90 米、宽 60 米的仓库地面。这里 agent 内部会执行类似“创建平面、切换到编辑模式、缩放至指定尺寸”的组合操作。通过 MCP 工具它先调用创建平面的工具然后把平面的 scale 改成 [45, 30, 1]因为 Blender 里新建平面是 2 米乘 2 米要得到 90 米乘 60 米缩放系数就需要是 45 和 30。等地面完成下一步是生成立柱网格。我让 agent 以 6 米为间距生成一排、以 8 米为间距生成另一排位置从坐标零点开始铺满地面。如果想让 AI 用循环去批量复制 Cube 并 attach 到指定坐标它通过 MCP 工具会按步骤执行。这个过程中建议一起给地面添加一个简单的灰色材质因为纯白地面在渲染时反光过强会干扰对场景明暗的判断。材质这块让 agent 去做即可视觉上也能看出变化。3.2 核心逻辑货架、托盘、堆垛机的程序化建模场景骨架搭好后开始用 AI 对话生成仓储场景的核心对象。我给 agent 提需求的方式是双深货架双排背靠背布局8 排、6 层每层两个库位。下面是它内部执行逻辑的分析。作为一个合格的 agent它会先折叠这个需求将货架的尺寸拆成变量。比如每排货架长 10 米、宽 1.2 米、高 6 米层高 1 米每层有左右两个库位。数据计算上双深货架的本质是两个背靠背的货架共享同一个立柱库位面向两侧通道。然后 agent 会调用三次循环第一次循环生成 8 排货架主体每排之间留出 3.2 米宽的通道方便后续 AGV 模型移动第二次循环在每层生成横梁和层板如果层板数量多到一定程度需要优化面数把实例化方式从“独立生成”改成“集合实例”这一步很关键否则场景面数会爆炸第三次循环生成库位标识也就是每个库位上那个小方盒子后续对接库存数据时直接在数据层修改这个盒子的颜色或文字标签即可。我特意让 agent 给每个库位对象命名时加上编码规则比如 R1-S02-L01表示第 1 排货架第 2 层左 1 库位。这个命名规则后面对接 Web 端数据时非常有用一个编码可以对应一条数据库记录这也是数字孪生项目建模区别于传统 3D 建模的核心模型上的每个对象都应该带着业务语义。托盘和货物模型就简单多了。托盘用标准尺寸 1.2 米乘 1 米加上四向叉入口的凹槽让它看起来有仓储设备的辨识度而不是一个面无表情的方块。货物的话一般用不同颜色的长方体代表不同 SKU比如蓝色箱子代表电子产品、黄色箱子代表日用品。我在和 agent 对话时直接说“放两三种颜色的箱子”它就会去生成几个有颜色变化的 Box 并落到托盘上。堆垛机是场景中最有技术含量的一台设备。它由三部分组成水平行走的地轨、垂直升降的立柱、可以伸缩的货叉。我让 agent 分别建这三个部分然后添加父子级关系使货叉作为立柱的子对象、立柱作为地轨的子对象。这样后续如果要做动画只需要移动父级子级就会跟着动。这也是数字孪生设备动画的标准做法。3.3 视觉增强与相机漫游灯光、材质与镜头布置场景里对象多了以后默认的灰色材质会很闷。我一般会让 agent 统一做两件事第一把地面换成低饱和度的环氧地坪材质这种材质特点是有微弱反射和高光但不像镜面那样锐利第二把货架的铁架部分调成灰蓝色横梁位置调成深灰色托盘统一为木色。这些颜色微调都是对着 MCP 工具的“创建材质”和“赋材质”接口完成的agent 通过对话理解我的描述后执行。灯光建议用三点布光法的简化版。首先在仓库顶部生成一排线性灯带模拟真实仓库的长条灯然后在仓库两端各补一盏暖色补光灯减少阴影的死黑区域如果想出图效果再高级一点可以加一个日光灯角度调整到能在地面拉出长阴影。日光灯会让场景立刻有立体感尤其适合汇报展示用的渲染图。相机漫游方面我让 agent 建了两个相机一个放在仓库入口的斜上方作为全局总览视角另一个放在货架通道里高度约 1.6 米作为模拟巡检视角。后一个视角在 Blender 里可以直接用来输出动画关键帧也可以导出到 Web 端后在 Three.js 里做浏览。这里有个操作习惯建议把 Blender 的单位设置改为米制因为 Blender 默认单位是米但很多时候从外部导入的数据是毫米制的不统一会导致数字孪生的坐标整个错位视觉上可能看不出来但一对接数据就全乱了。3.4 从对话到 Blender 场景一次完整的工作流记录这里记录一次真实的操作流程大家可以参考整个交互节奏。我在 Antigravity 的对话框里输入了这样一段需求“创建一个仓储场景需要双深货架 8 组每组 6 层双排背靠背层高 1 米托盘按每个库位 1 个放置堆垛机 1 台放在第一排通道地面是环氧地坪效果先出一张从入口斜上方看的渲染图。”这段需求本身已经把关键约束写清楚了agent 的解析负担就小很多过程也更稳定。agent 接收到需求后没有一次性生成整个场景而是分步执行先创建地面再生成货架框架再实例化托盘再放堆垛机最后打灯光和相机。每个步骤之间它会调用一次 Blender MCP 的接口实时反馈当前场景中的对象数量。我在面板里看到对象数从 20 涨到 90 再到 260整个过程大概两三分钟。出渲染图的时候出了点小插曲。刚开始 agent 用 Eevee 渲染器跑出来的图噪点很大锐度偏低。我让它切成 Cycles 渲染器并把采样数提到 128出来的效果立刻好了一个档次。代价是渲染时间变长了几倍但好在只是单帧静态图整体可接受。渲染完成后 agent 把图片写到容器的工作目录我直接在线预览就能看到效果这一轮对话的产物直接可以作为方案初稿发给客户。4. 实操过程复盘与关键环节的“为什么”4.1 为什么用实例化而不是独立网格做仓储场景时面数控制是最初级的门槛。如果 8 排货架全部用独立网格每个货架包含立柱、横梁、层板再乘以双面和细节面数会轻松突破百万级别。Blender 在视口里还可以承受但导出到 Three.js 后浏览器直接卡成 PPT。解决方案是 MCP 工具里生成集合实例Collection Instance。它的原理和代码里的“引用”很像多个对象共享同一份几何数据只是位置矩阵不同。也就是说同一排货架的 6 层CPU 只需要维护一份网格数据显示时复制变换关系即可。我在对话里特意吩咐“货架主体用实例化库位标识用独立小立方体”这样兼顾了性能和后续做高亮交互的需求。这也是为什么我的场景里对象数很多但 Blender 依然流畅的关键。给不同基础的朋友通俗解释一下好比你复印一百份文件如果每一份都重新排版打印既费墨又费时如果用复印机连续打印底稿只有一份出的纸张不计其数但排版只需要做一次。这里的“底稿”就是 instance 的原始网格“纸张”就是场景里的实例副本。4.2 坐标系与单位数字孪生对接的关键数字孪生项目里最忌讳的就是各自为政。仓库的 CAD 图纸数据是毫米制前端 Three.js 默认是米制Blender 默认也是米制如果不加约定模型导出去不是大十倍就是小十倍。我一般以一个统一的“场景中心坐标”为锚点把所有建筑和设备都相对这个锚点摆放。锚点位置一般是仓库大门的正中心或者地图的某个角点。另外就是坐标轴方向。Blender 的 Z 轴向上这不稀奇但很多 CAD 图纸的 Y 轴朝向是北向。如果从图纸导入的数据没有做旋转变换直接放进来整个仓库的朝向就跟地图对不上了。如果你规划后续要在前端叠加真实地图或 GPS 轨迹这个问题会非常致命。所以和 agent 对话建场景时我总会先确认一句“所有对象先围绕坐标原点摆正大门朝向 Y 轴正方向”这个约定在后续导出 glTF 时能省不少事。还有一个细节是 Blender 的旋转顺序。Blender 默认是 XYZ 欧拉角你让 agent 微调某个设备角度时它可能只用一句“旋转 3 度”带过不指定旋转轴。这种不确定性在数字孪生里挺危险的——设备朝向差三度在 100 米外的坐标误差可能到几十厘米前端叠加线框时直接飘了。所以我在 prompt 里会强调涉及旋转操作时必须指定轴与角度给出精确的欧拉值。4.3 Agent 编码习惯的塑造在一次对话中把规范讲透跟 agent 协作这种事想一次到位就必须把自己的项目管理习惯“翻译”给 agent。这里讲两点我自己的习惯。第一对象命名要体系化。比如货架统一使用 R 前缀、库位统一使用 L 前缀、AGV 统一使用 V 前缀。如果 agent 自己自由命名它可能会生成一堆 Cube.001、Cube.002 这种名字一旦场景复杂了根本没法维护。所以我会在开头对话中明确给它一个命名规范。第二材质和集合的层级。我让 agent 把相同材质的对象合并到同一个集合下场景根集合再按功能分类建筑结构、存储设备、搬运设备、传感设备。这样在 Blender 大纲里看层级会非常清爽后续导出 glTF 时前端也能按层级去遍历和操作。Blender MCP 是支持对集合做增删改的agent 通过工具可以帮我们维护层级前提是你的 prompt 里把分层思想说清楚。5. 常见问题与排查技巧实录5.1 MCP 连接失败与工具调用超时这类问题是使用 Antigravity Blender MCP 的时候最常遇到的。连接失败一般表现为agent 说“无法连接到 MCP server”或者“工具调用未响应”。我先讲一个自己排查过的典型案例。有一次打开 Antigravity 的 MCP 面板发现 server 状态是“在线”但 agent 一调用工具就超时。进入容器看日志发现 Blender 进程还在但它监听的那个 wss 端口根本没有被 MCP server 正确转发。原因是容器重启过一次Blender 的启动脚本没有做到开机自启MCP server 启动后和 Blender 之间没有建立连接。排查步骤可以固定成这么几个顺序先确认 Blender 进程在跑且监听端口存在然后用 MCP server 的日志看 URL 是否匹配最后看 Antigravity agent 调用的是哪个工具名对照 MCP server 暴露的 tools 列表有没有这个工具名。如果工具名匹配很大概率是版本不一致。版本不一致的问题很隐蔽。Blender 端插件升级后工具列表可能会变但 Antigravity 的 agent 还按旧工具名调用就会报 method not found。这种时候不用慌在 MCP 管理面板里刷新一下工具列表就好。5.2 Blender 无头模式与渲染器参数导致的质量异常云容器里跑 Blender最怕“出图黑屏”或者“等待十几分钟没反应”。我遇到过一次agent 执行渲染命令后提示“渲染完成”但我打开图片发现是全黑的类型。排查后发现是相机没有对准场景或者灯光强度太低。原理上讲Cycles 渲染器如果没有光源所有像素都会是纯黑而 Eevee 则可能显示为灰色扁平网格。这个问题的解决方式是让 agent 在渲染前多做一步校验检查场景中有没有灯光对象相机朝向是否指向 bounding box 的中心。这一步放在 prompt 里描述比手动去改省事得多。另外如果渲染太慢可以把采样数调低到 64、关掉景深先出低保真预览图确认构图最后再开 256 采样出最终图效率能翻倍。5.3 导出 glTF 后前端显示错位与材质丢失Blender 里看着很好导出 glTF 再放到 Three.js 里就发现位置错乱或者材质全糊了。这是数字孪生项目里很典型的问题。材质丢失的根因通常是使用了 Blender 特有的 Shader Node 组合比如 Principled BSDF 节点嵌套复杂glTF 导出器不认这种非标准结构。解决办法是让 agent 在建模阶段就使用 glTF 兼容材质比如只调 Base Color、Metallic、Roughness不要加入复杂的 Mix Shader。简单朴素的 PBR 材质在导出后表现非常稳定。位置错位则多是旋转和缩放未应用导致的。在 Blender 里复制对象后如果直接旋转、缩放而不应用变换blender 内部数据里对象的 scale 是浮点矩阵。导出时还带着这个矩阵在 Three.js 里可能会叠加出奇怪的偏移。让 agent 在所有对象生成完、位置摆定后批量执行一次“应用变换”操作把 scale、rotation、location 固化到网格数据上这个问题就迎刃而解。5.4 参数化修改后的反向调整与版本回退AI 建模的另一个问题是“重生成后会失去之前的微调成果”。有一次我发现某个货架间距该调大一点让 agent 改了参数重生成结果它把整个货架阵列重新排了一次之前手动调整的一台堆垛机位置又回到默认值了。处理方式是把微调信息也补进 prompt 里或者更聪明一点让 agent 分模块生成。比如货架坐标单独一个脚本堆垛机模型单独一个脚本设备位置单独一个脚本。每次只让 agent 改“货架间距”这个变量其他的脚本不重跑就不会把设备位置带跑偏。这个“分模块建模”的习惯可以说是整个实操里对生产力影响最大的一条经验。6. 后续扩展方向与个人经验总结6.1 从静态场景到动态数据映射静态场景搭建完成只是第一步数字孪生价值的一半在于数据层的打通。现在场景里每个库位有明确的命名编码接下来要做的是把这些编码和数据库里的库位记录挂上钩。在 Web 端可以导入 Three.js 加载场景里的对象按名称匹配数据库字段给库位绑定状态属性、库存数量、最近操作时间等。业务系统里某个库位状态变化前端就能对应改变模型颜色比如绿色变成红色这就实现了“数据驱动的数字孪生”。Antigravity 的 agent 在这个阶段也可以发挥用途——它可以帮你生成前后端数据联调的代码。如果你的云开发环境已经配置了数据库和 API可以直接让 agent 读取数据表结构然后自动生成对接脚本。这相当于既做了建模又顺手把数据开发的一部分做了项目进度会快很多。6.2 Web 端漫游与 VR 眼镜扩展的想象空间场景导出后Web 端漫游是客户最容易理解的展示形式。Three.js 加载 glTF 模型加一个 OrbitControls客户就能自己在网页里旋转、缩放、点选库位。如果后续要做 VR 眼镜的 3D 电影式体验这个场景也可以导出为适用于 VR 浏览的格式在支持 WebXR 的浏览器里直接用 VR 设备漫游仓库。这个方向的扩展不需要重做模型把相机类型从透视相机切换为 VR 相机加上手柄交互的射线检测就能基本实现仓储巡检的沉浸式体验。大家如果对 WebXR 仓库漫游有兴趣可以留言告诉我后续我争取把这一部分单独写一篇。6.3 我对这套工具链的个人体会从实际项目出发来看这套方案最大的意义是让“会提需求的人”也能做 3D 场景因为建模从“手艺活”变成了“对话活”。当然这不是说 Blender 不再需要学了恰恰相反如果你懂一点 Blender 的基础概念比如对象模式、编辑模式、材质节点、渲染器的区别你在和 agent 对话时会非常占优势。你越能把模糊的视觉想象转化成具体的参数需求agent 交付的成果就越接近你要的效果。还有一点想说的是用这套工具链真别急着一次生成完美场景。我比较轻松的节奏是“小步快跑”先出白模确认布局和比例再上材质再调灯光最后考虑渲染出图。每轮只解决一层问题步骤清晰出现问题了也好定位而不是让 agent 一次性生成一个庞大的复杂场景结果哪里错都很难查。最后分享一个小技巧在 Antigravity 的对话里建立一个固定的开场白模板每次启动新项目时先粘贴这段话里面写好坐标约定、命名规则、材质规范、渲染设置。每次建模前让 agent“默读一遍模板再开工”这样它产出的背景风格和编码习惯会稳定非常多。这也是我从这套工作流里获得的最核心的一招。这个系列后面还有下篇我计划写点云拉框标注和 Blender 场景在目标检测数据生成里的应用——比如用程序化生成的仓库场景快速批量产出视觉数据辅助训练识别模型。那是另一个有意思的方向回头整理好了再分享出来。