企业官网建设流程全解析

前阵子做智慧仓储项目，我一直在找一个能让AI直接操作3D软件的方案。起因很实际：仓储数字孪生场景里，货架、库位、AGV路径这些模型如果全手动在Blender里搭，光阵列复制和层级整理就能耗掉一整天；但如果只让AI帮你写建模脚本，它又“看不见”Blender里到底有什么。后来我把 Antigravity 和 Blender MCP 串起来，发现AI真的能从对话里直接生成和修改仓储3D模型，整个建模效率翻了不止一倍。这篇文章就把我实测跑通的链路完整拆开，讲讲怎么从零搭出一个智慧仓储数字孪生场景，包括MCP配置、建模实操、导出渲染和排坑经验。适合正在做数字孪生、想用AI提升3D建模效率、或者对MCP协议感兴趣的开发者，这篇是上半部分，先重点解决“AI怎么把模型建出来”这件事。

1. 项目背景与整体设计思路

1.1 这个项目到底在解决什么问题

智慧仓储数字孪生，说白了就是把一个真实仓库的物理空间和业务数据，映射到一套可交互的3D场景里。管理者在网页上看到的不是一个平面表格，而是能直观看到哪个货架堆满了、哪个库位空着、AGV当前跑到哪个通道的立体视图。我接过不少这类需求，客户问的第一句话通常是“能不能让我一眼看清楚仓库现在的状态”，而不是要一份漂亮的二维图表。

传统仓储管理系统的问题在于数据和空间脱节：WMS里能查到某个SKU的库存数量，但很难立刻定位到它在仓库的哪个物理位置；视频监控能看到现场画面，可一旦货架遮挡就失去全局视角。数字孪生就是把这两者拼起来——先建一个跟真实仓库比例一致的3D模型，再把库存、设备状态、任务进度这些实时数据挂到对应模型上。比如某个库位有货，模型里对应的长方体亮成绿色；AGV正在移动，模型里的小车就沿着预设路径走。用户不需要懂数据库，也不用看监控回放，一眼就能判断当前仓储运转是否正常。

这个项目的难点不在3D建模本身——Blender里建个仓库模型并不难，难点在于三个层面：第一，模型结构要足够规整，方便后期跟业务数据做一一映射；第二，场景要可复用，换一个仓库尺寸就能批量调整；第三，也是最核心的，建模过程能不能由AI驱动，让非专业建模人员也能通过对话生成和修改场景。Antigravity + Blender MCP 这套组合，就是冲着第三个难点去的。

1.2 为什么是“Antigravity + Blender MCP”这套组合

先说结论：这套组合的价值，在于把“AI理解需求”和“AI操作工具”这两件事打通了。Antigravity 是一个AI开发环境，内置了Agent能力，能让模型自主拆解任务并执行；Blender MCP 则是一个跑在Blender内部的MCP服务端，接受外部指令操作3D场景。两者连起来之后，你可以直接用自然语言对AI说“在仓库东北角加一排货架”，AI会转化成Blender能执行的Python命令，真正把模型创建出来。

我之前也试过其他方案。最传统的是自己写Blender Python脚本，好处是可控，但每次改布局都要改代码，AI完全帮不上忙。也试过让AI生成脚本、我手动粘贴到Blender里执行，步骤繁琐不说，AI对Blender内部状态的感知几乎是零——它不知道现在场景里已经有了哪些物体，生成的脚本很可能重复建模。还有用Unity做数字孪生的路线，但Unity在Web端的部署重量较大，对智慧仓储这种以数据可视化为核心的场景来说，Three.js这类轻量渲染方案反而更合适。

MCP（Model Context Protocol）在其中扮演的角色，很像给AI装了一个“USB接口”。没有这个协议，AI和Blender之间是断开的，AI只能凭经验猜你场景里有什么；有了MCP，AI可以直接调用Blender暴露出来的能力——查询场景、创建物体、修改属性、执行脚本，每一步都有真实反馈。这也是我选择 Antigravity 的原因：它对MCP的原生支持比较完善，配置起来顺滑，Agent在执行多步任务时也够稳定。整体技术栈是：Antigravity（AI大脑）+ Blender MCP（3D操作执行器）+ Blender（建模环境）+ Three.js（Web端渲染）。

2. MCP 协议与 Blender MCP 配置

2.1 MCP协议是怎么把AI和Blender连起来的

MCP全称是 Model Context Protocol，模型上下文协议。把它理解成一个标准化接口：AI（客户端的角色）想要使用某个工具的能力，不用自己去适配每种工具的私有API，而是按照MCP定义的统一方式发起请求；工具这边通过实现一个MCP Server，把自己能力暴露成标准化的“工具”（Tool），供AI调用。

具体到Blender MCP，这个插件在Blender内部启动了一个本地MCP服务，并在服务里注册了一系列工具：获取场景结构、创建物体、修改物体属性、运行Python代码等。当你在Antigravity里跟AI说“帮我建一个仓库地面”，Antigravity里的Agent会推断出需要调用Blender MCP的某个工具，然后通过网络请求把参数发给Blender，插件收到后在Blender里真正执行对应操作，再把结果返回给AI。整个过程用户是感知不到的，你只看到AI回复了“已创建地面”，但背后其实是标准的MCP工具调用链路在运转。

为什么非得要这个协议？我自己的理解是：没有MCP的时候，AI和工具的交互方式是“文本猜测”。AI写一段Python代码，你复制到Blender里跑，报错了再贴给AI看，来回来去效率极低。有了MCP，AI对工具的调用变成“结构化API调用”，工具给AI的反馈也是结构化的场景数据，这让AI的下一步决策有了依据——它知道场景里已经有3个货架，就不会重复创建。类比一下，前者是你给朋友发微信描述菜谱，后者是做菜机器人直接读取电子秤和灶台的数据。

2.2 Blender MCP插件安装与服务端启动

安装Blender MCP插件的过程不难，但有几个细节容易踩坑，我按自己的实操顺序整理一下。第一步，从插件仓库下载最新版本的zip压缩包，注意不要解压，Blender安装插件认的就是zip。第二步，打开Blender，菜单栏进入“编辑→偏好设置→插件”，点击右上角的“安装”按钮，选择那个zip文件，然后在插件列表里找到Blender MCP并勾选启用。

启用后，Blender的侧边栏（按N键可以呼出）会多出一个MCP面板，里面有几个关键按钮。其中最核心的是“Start MCP Server”，点击后插件会在本地启动一个WebSocket服务，默认监听地址是 ws://127.0.0.1:9876。端口号可以在面板里改，但我的建议是尽量保持默认，因为后面在Antigravity里配置时只要写对一次，后续都用同一套。

启动成功后会看到状态提示，表示服务已经运行。这里最常犯的错误是：项目还没保存就启动服务，或者整个Blender进程被其他操作阻塞，导致服务端口占用。如果出现“address already in use”，可以用命令行检查端口占用，但大多数情况下重启Blender再点一次启动就能解决。另一个建议是：建模过程中让Blender保持前置运行，不要最小化到任务栏挂起，有些系统在后台会降低Blender的线程优先级，影响MCP响应速度。

2.3 Antigravity中添加MCP Server的完整步骤

Antigravity这边，需要把刚才启动的Blender MCP服务注册进去。打开Antigravity的设置面板，找到MCP Servers相关的配置入口——不同版本入口名称略有差异，桌面版一般在Settings里的MCP标签页，浏览器扩展版则需要先在扩展设置中启用“MCP连接”开关，然后回到主界面刷新。

添加一个New Server，连接类型选WebSocket（也有的版本叫URL/SSE），地址填 ws://127.0.0.1:9876，直接默认参数保存。保存后先做一次Connection Test，正常情况下几秒钟内会返回成功。如果测试失败，稳妥的排查顺序是：确认Blender里MCP服务已经启动、确认端口号一致、确认Antigravity有权访问本地网络。

连接成功之后，我建议先做一个小验证：在Antigravity的对话界面里给AI发一条指令：“请读取当前Blender场景，列出所有物体名称和类型。”如果配置正常，AI会调用Blender MCP的查询工具，返回类似“场景为空，没有物体”的结果。看到这个反馈就说明整条链路已经通了，接下来就可以开始进入真正的建模环节。顺便说一句，配置阶段如果遇到HTTP 403之类的鉴权错误，大概率是Antigravity的API Key权限没有配置好或者已过期，和MCP Server本身关系不大，要分开排查。

3. 仓储场景建模实操

3.1 建模前的场景规划与数据准备

很多实操翻车的案例，问题都出在“没规划就动手”。我强烈建议在打开Blender之前，先用一张纸或者一个表格把仓储的基本参数定下来。比如我这次做的原型，仓库尺寸取40米长、20米宽、8米高，这是一个相对标准的中型仓库比例。货架区放在仓库中部，占22米长、10米宽，两侧留出AGV通道，通道宽度设计成2.4米，这个值参考了常见AGV的最小转弯半径。

货架的参数也要提前定：每排货架长10米，包含8组货位，每组货位宽1.2米、深0.8米、层高1.2米，总共做3层。这些参数不是乱填的，它们直接决定了你后面用阵列复制时的偏移量。我的习惯是建一张参数表，把空间尺寸、货架数量、通道宽度、坐标原点全部列清楚，然后才开始建模。这样做的最大好处是：AI辅助建模具的时候，你可以把这些参数直接丢给AI，让它用循环和阵列算法生成场景，而不是一个物体一个物体地手动摆放。

坐标系也要事先约定好。Blender里默认Z轴向上，我把仓库的长边对齐X轴，短边对齐Y轴，原点放在仓库的西南角。这个约定很重要，因为后期如果要把模型导出到Three.js或者对接点云数据，坐标系的统一能省掉大量回调工作。

3.2 用Blender搭建仓储基础结构

先把仓库的框架搭起来。我习惯从地面开始：Shift+A添加一个平面（Plane），然后在右侧属性面板里把尺寸改成40x20米，为了让地面有质感，给材质指定一个浅灰色。墙壁可以用立方体拉长，但临时原型阶段我通常只建一面短墙做视觉边界，省得渲染性能浪费。

地面之后是货架。这里要提醒：不要一个个手动建货架，必须用阵列修改器（Array Modifier）。我的方法是先创建一组货架单元——两根立柱加三块层板，组成一个三层货架单体，然后选中这个单体，添加Array Modifier，将Count设为8，并设置Relative Offset沿X轴偏移1.2米。这样一组8个货位的长货架就生成了。再把这一整排复制到另一边，居中排成5排，排距按参数表设为2.4米。

托盘和货物也用小立方体代替：托盘是0.9x0.6x0.15米的扁立方体，货物根据货位状态决定要不要放。初始阶段我随机放了一些货物，目的是测试渲染效果，后续在数据联动阶段会用实时数据覆盖这些静态内容。这里有个关键操作容易被忽略——所有用于后期数据绑定的物体，都要按命名规范改名，比如货位命名“Shelf_A_Slot_01”，AGV命名“AGV_01”，这样后面通过JSON或WebSocket更新状态时，才能准确找到对应模型。改完名记得按Ctrl+A应用缩放和旋转，把变换归一到本地坐标，这一步对后期导出模型极为重要，否则可能出现模型位置偏移或缩放异常。

3.3 通过MCP让AI辅助批量建模的实战

手动搭好第一组结构之后，就该上AI了。Blender MCP的价值在批量生成和结构调整上体现得最明显，分享一个我实测比较高效率的提示词写法：

“在当前Blender场景中，请获取场景结构。然后以现有货架为基础，在X=30米的位置再创建一排货架，要求：共8组货位、每组3层，货位深度0.8米，高度1.2米，与X=30米的距离控制在2.4米。创建完成后，把新货架的库位命名为Shelf_E_01到Shelf_E_08，并返回创建的物体列表。”

AI拿到这个指令后，会先调用MCP获取场景当前结构，确认已有货架的尺寸和坐标系，然后生成一段Python脚本，通过execute_code工具在Blender里执行。实际执行结果里，AI通常会创建一个空物体作为组父级，然后把8组货架作为子物体挂在下面，方便整体挪动。如果你发现AI生成的层级很乱，可以在提示词里加一句“所有新物体必须归入一个名为Shelf_E的空物体下”，AI基本都会照做。

用MCP辅助建模时有一个使用心得：尽量用增量式指令，不要一次提太多需求。比如把“建地面、建货架、放AGV、加灯光”拆成四条指令逐条执行，每执行完一条就让AI报一下结果，这样出问题能第一时间定位。实测下来，增量式操作成功率比一次性大指令高很多，而且后续想回溯调整也更方便。另外，AI生成物体后我一般会在Blender里手动检查一遍透视图，确认没有物体交叠或者悬空，毕竟AI对物理碰撞没有概念。

4. 模型导出与Web端渲染管道

4.1 导出格式选型：glTF 还是 JSON

仓储模型建完之后，下一步是把模型搬到浏览器里。常见的做法有两条路线，我分别讲一下各自的适用场景。

第一条路线是用glTF/GLB格式。这是3D格式里最适合Web场景的，Blender原生支持导出，Three.js加载起来也方便。优点是模型自带材质、纹理、层级结构，渲染效果跟Blender里比较接近，适合结构复杂、需要精细展示的模型。操作路径是：选中要导出的所有物体，菜单栏File→Export→glTF 2.0，导出时勾选“应用修改器”和“+Y Up”（这一步会帮你处理Blender和Three.js的坐标轴差异）。我个人最推荐这条路线，因为智慧仓储场景里货架、AGV、货物这些模型有不少细节，glTF能完整保留。

第二条路线是把场景导出成自定义JSON，只包含物体名称、类型、位置、旋转、缩放、尺寸等核心属性，然后在Three.js里用这些数据程序化重建模型。好处是文件体积极小，数据结构天然适合绑定实时业务数据，坏处是丢失材质细节和复杂层级。我通常在两种情况下选JSON：一是模型结构简单（就是方块组合），二是我需要把建模和业务数据做深绑定的场景。实际项目里我经常两条路混用：整个仓库用glTF展示，但每个货位的状态标记物（比如绿色/红色指示块）用JSON数据动态生成。

# Blender中导出自定义JSON的参考脚本 import bpy, json objects_data = [] for obj in bpy.context.scene.objects: if obj.type == 'MESH' and obj.name.startswith('Shelf'): objects_data.append({ "name": obj.name, "location": [round(v, 3) for v in obj.location], "rotation_euler": [round(v, 3) for v in obj.rotation_euler], "scale": [round(v, 3) for v in obj.scale], "dimensions": [round(v, 3) for v in obj.dimensions] }) with open('/tmp/warehouse.json', 'w', encoding='utf-8') as f: json.dump(objects_data, f, ensure_ascii=False, indent=2)

4.2 Three.js加载与场景搭建

Three.js这边的核心任务，是把导出的模型放进来并做成可交互的视角。如果你选了glTF路线，用一个GLTFLoader就够了，十几行代码就能把整个仓库加载到场景里。需要单独设置的是相机和轨道控制器：相机初始位置放在仓库入口的斜上方，这样用户进入页面第一眼就能看到全局；轨道控制器（OrbitControls）开启缩放和平移，让用户能自由下钻到某个货架查看细节。灯光用一盏环境光加一盏方向光，模拟仓库顶部的照明效果。

// 加载glTF模型 import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'; const loader = new GLTFLoader(); loader.load('/models/warehouse.glb', (gltf) => { scene.add(gltf.scene); });

如果选了JSON路线，就需要自己写程序化生成逻辑。核心做法是遍历JSON里每条物体数据，根据类型创建对应的几何体，再按照数据结构里的位置、旋转、缩放设置transform。好处是可以直接在JS里给每个物体加上自定义属性（比如货位的状态字段），后续更新状态时不用去遍历模型树，直接在维护好的映射表里操作就行。我通常会建一个slotMap对象：把JSON里的物体名作为key，存对应mesh的引用和初始状态，这样后面数据联动时，根据货位编号直接查表更新即可。

给一个比较实际的建议：不管用哪种加载方式，都要把模型加载和场景初始化拆成两个函数。initScene负责创建渲染器、相机、灯光和地面网格；loadModel负责加载仓储模型。这样后面你若想换不同仓库的模型，只需要调用loadModel传入新的模型地址，不用动整个初始化逻辑。智慧仓储项目经常要换场景，这个拆分能省不少调试时间。

4.3 实时数据如何驱动模型状态

数字孪生和普通3D展示的本质区别，就在于“动”。模型建得再漂亮，如果数据不会驱动它变化，那只是个花架子。智慧仓储场景里，最常见的实时数据有几种：库位状态（有货/空置/锁定）、AGV位置（实时坐标）、设备状态（运行/故障/离线）、任务进度（出入库任务进行到哪一步）。

我在原型里用WebSocket连接后端数据服务，每次收到数据后按类型分发处理。比如后端推送这样一条消息：{"type":"slot_update","slot":"Shelf_A_01","status":"occupied"}，前端就根据slot字段在slotMap里找到对应的mesh，把材质颜色改成绿色（有货）或灰色（空置）。如果收到AGV位置更新，就把AGV模型的position更新到新坐标，必要时用TWEEN库做平滑移动，避免画面跳变。

// 一个简单仓储数据消息示例 {"type": "slot_update", "slot": "Shelf_A_01", "status": "occupied"} {"type": "agv_move", "agv_id": "AGV_01", "x": 12.4, "y": 8.2} {"type": "device_state", "device": "conveyor_01", "state": "running"}

这里有一个我踩过的坑：不要把实时数据直接写到每个物体上，而要维护一份“业务状态层”。也就是用一个Map结构存所有业务实体的状态，逻辑层监听数据变化并更新状态值，然后由渲染层订阅这些状态值去驱动模型。如果数据直接驱动模型，一旦业务逻辑复杂（比如库存扣减、库位分配），你会被渲染代码里塞满业务分支。把状态层和渲染层分离，后面扩展传感器数据、订单数据都会容易得多。

5. 常见问题与排查实录

5.1 MCP连接失败、403与Agent中断

我实测中遇到最多的一类问题就是MCP连不上。现象是Antigravity里提示无法连接MCP Server，或者AI一直在“重试连接”。排查顺序可以这样：先回Blender看MCP面板状态是否是运行中；然后用一个简单的命令行工具测试 ws://127.0.0.1:9876 是否可访问；最后再检查Antigravity里配置的地址是不是多打了空格或斜杠。我试过的经验是，地址里的路径千万不要写成 ws://127.0.0.1:9876/，最后多余的斜杠在部分版本里会导致握手失败。

403错误，哪怕是本机测试也会出现。它一般跟MCP本身无关，而是Antigravity调用云端模型接口时鉴权失败，常见原因是API Key过期、额度耗尽，或者登录态失效。我处理这个问题时是先确认Antigravity账号能正常发起普通对话，如果普通对话也403，那就是鉴权问题；如果只有带MCP的对话403，再看看是不是MCP Server接收了请求但回传了异常状态，被模型误判成了鉴权错误。

还有一个比较麻烦的现象：Agent执行中途直接终止，日志显示“agent execution terminated due to error”。分析下来最常见的原因是某一步MCP工具调用抛了异常，而Agent的安全机制认为这是不该继续执行的操作，于是终止整个回合。解决办法是精细化提示词，把操作拆小，避免一次调用里同时创建大量物体或执行过于复杂的Python代码。另外AI偶尔会调用不存在的工具名，属于Agent模型对工具理解偏差，给它明确的工具使用说明或者示例，成功率会明显提升。

5.2 AI生成的模型和预期不符怎么办

AI建出来的模型不符合预期，这事太常见了，不要指望一次提示词就能完美。我遇到过AI把货架建到地面以下半米的情况，原因是Blender里Cube的默认原点在几何中心，AI在计算位置时忘了把层板的厚度加上去。解决办法不是去改提示词，而是直接在对话里追加一条修正指令：“请把刚才创建的货架组整体沿Z轴上移0.5米。”AI会再次生成一段微调脚本执行，这比手动改快得多。

更系统性的问题在于AI生成的物体命名和层级混乱。有一次它创建了10组货位，但所有物体名都是“Cube.001”“Cube.002”这种默认名，直接把后续的数据映射全打乱了。我的对策是在最开始就定好命名规则，而且在每次生成后让AI调用查询工具返回物体列表，自己肉眼检查一遍。如果命名乱了，就追加一条修正指令：“将选中物体的名字批量改成Shelf_B_01到Shelf_B_08”。MCP的价值在这里体现得很充分：AI能读回场景状态，修正指令就有依据，不需要你手动去改。

还有一个心态上的建议：不要要求AI一步到位生成完整仓储。我的方法是“先骨架，后细节”——让AI先创建货架整体框架，等框架确认无误，再补充货物、指示块、AGV路线这些细节。每步之间都让AI返回场景摘要，报一下新增了哪些物体，相当于给它一个自我检查的环节，出错的概率会大幅下降。

5.3 导出到Web端后尺寸和方向不对

仓储模型在Blender里看着没问题，一导入Three.js发现要么方向不对，要么尺寸变大好几倍。这类问题几乎都是导出设置或者坐标约定不一致导致的。Blender的默认单位是米，但Three.js里默认世界单位也是米，理论上一比一对应，可如果你在建模时缩放过物体但没有应用缩放，导出时模型尺寸就会保持原始数值。

方向问题更隐蔽。Blender是Z轴向上，Three.js默认是Y轴向上。如果走glTF导出，引擎已经帮你做了转换，你只要在导出时勾选+Y Up选项就行。但如果你是用自定义JSON导出，那就得自己写坐标映射：把Blender的(x, y, z)转成Three.js的(x, z, -y)。我对比过两种方式，还是推荐glTF，省心很多；只要货架数据状态映射是用物体名维护的，glTF的节点层级也够用。

还有一个容易忽略的点：材质颜色。Blender里你用的可能是Principled BSDF材质，颜色和粗糙度都调好了，但导出到glTF后Three.js渲染出来可能整体偏暗。这是因为Three.js默认没有处理光照映射。我在加载glTF后通常会在场景里加一个环境贴图或者加大环境光强度，让模型亮起来。

5.4 大场景渲染卡顿的优化思路

仓储数字孪生原型还好，一旦模型精度上来、物体数破千，Web端就可能卡顿。第一次卡顿我以为是Three.js性能不行，后来排查发现是模型物体数量太多导致的draw call超标。智慧仓储场景动辄几十排货架、几百个库位，每个库位由两三个mesh组成，draw call轻松破千。

优化手段按见效速度排：第一招是合并静态几何体，整个仓库的货架、地面、墙壁这类不运动的物体，用BufferGeometryUtils.mergeGeometries合并成一个mesh，draw call立刻降一个数量级。第二招是用InstancedMesh做重复物体的实例化渲染，比如几百个同尺寸的库位指示块，用实例化只需要一次draw call。第三招是控制实时更新的范围，AGV、状态灯这类需要频繁变化的物体单独保留为独立mesh，静态背景全部合并。我的实测数据是：优化前draw call约1400次，优化后降到200次左右，帧率从20帧提升到稳定60帧。

做这些优化时有几个细节：合并后物体就没有单独的“名字”了，所以必须在合并且前把所有业务映射数据导出来，存在你维护的slotMap里。另外glTF导入后的模型树层级很深，合并前先处理好遍历逻辑。如果你是用JSON程序化重建模型的，那从一开始就可以用实例化方案，天然就没有draw call压力。

最后分享一个小技巧：在Blender里建模时，可以开启统计面板查看场景多边形数量，尽量控制在十万面以内。仓储场景大部分是规则几何体，不需要太高的细分，模型面数一降，Web端渲染和加载速度都会有明显提升。实际做下来，一个中等规模的仓储场景全部优化完，GLB文件控制在5MB以内，浏览器首屏加载三秒内基本可以完成。

这套链路我用了快一个月，最大的感受是“AI建模”终于不是一个噱头了。Antigravity + Blender MCP 的价值不在于帮你省掉几次点击，而在于把建模过程变成了可对话、可批量、可追溯的操作流。以前改一个货架布局，你得手动挪物体、改数组参数；现在一句话就能让AI重新生成并排好。下半篇我会接着写前端实时联动和动态AGV路径可视化，把数字孪生的“活性”真正做出来。