企业官网建设流程全解析

仓库数字化转型聊了很多年，真正落到“能看、能算、能调度”的层面，大多数项目的瓶颈不在算法，而在三维场景的生成速度。传统做法是建模师按CAD图纸手动搭一个仓库模型，动辄两三周，等模型出来，业务需求又变了。我一直在琢磨怎么把这条链路压缩到以小时为单位，直到把 Antigravity 和 Blender MCP 串起来，才找到一条真正可行的路径。

简单解释一下这套组合：Antigravity 是一个能承载复杂任务编排的 Agent 运行平台，Blender MCP 则是一个把 Blender 的建模、改模、渲染能力暴露成 MCP 协议接口的桥梁。把两者打通之后，你不再需要手动在 Blender 里拉箱子、摆货架、调材质，而是用自然语言描述“我想要一个 10 排货架、5 层横梁、双深位库位的仓库”，Agent 就会自动调起 Blender 完成建模，并且把模型对象按业务语义命名。这篇文章是上篇，重点讲环境搭建、建模思路、MCP 参数调用和我在实操中踩过的坑，目标是让你能在半天之内跑通“从自然语言到仓储三维结构”的基础链路。

1. 为什么是 Antigravity + Blender MCP：选型逻辑

1.1 传统数字孪生项目的真实痛点

我做过的仓储数字孪生项目，流程基本是这样：业务方提出需求，建模团队开始建库房外观、货架、托盘、AGV 路径等模型，与此同时开发团队搭 Three.js 或 Unity 场景，等模型导出后再手动调坐标、调比例、绑定数据。

这个流程有三个问题。

第一，建模周期太长。一个中等规模的仓库，货架区、收货区、发货区、充电区、办公区全算上，精细建模至少一到两周。如果业务方中途调整库区规划，建模团队得返工，时间成本直接翻倍。

第二，模型与数据是断开的。传统建模流程交付的是“长得像”的三维模型，但模型里的每一个货架、每一个库位并没有结构化的 ID，后续想要实现“点击货架查看库存”这种基础交互，开发人员要自己重新给模型对象赋予业务属性，等于在模型之上再包一层数据映射。

第三，调参效率低。AGV 数量变了、巷道宽度变了、货架排数变了，每次都要重新建模或者手动改场景，完全没有“参数驱动”的概念。

1.2 Antigravity 与 Blender MCP 各自解决了什么问题

Antigravity 的出现，解决的是“任务编排”的问题。它不是一个单纯的聊天机器人，而是一个能承载复杂任务流的 Agent 运行环境。你可以把整个数字孪生搭建过程拆解为多个步骤，比如“生成仓库框架”、“生成货架阵列”、“标注库位编码”、“设置材质和灯光”、“导出场景数据”，每个步骤交给 Agent 去执行，再通过上下文传递结果。

Blender MCP 解决的是“让 AI 能真正操作 Blender”的问题。MCP 全称是 Model Context Protocol，它定义了一套标准化的工具调用协议。Blender MCP 插件装上之后，Blender 就变成了一个可以被外部程序控制的 MCP 服务端。Agent 可以通过协议调用 Blender 内部的 API，完成创建物体、移动物体、修改材质、渲染输出等操作。

把两者组合起来，等于你有了一位懂仓储备件业务、又能直接操作 Blender 的虚拟建模师。这也是我在实际体验中觉得最有价值的地方：模型不再是“画”出来的，而是“算”出来的。

1.3 适用场景与技能准备

这套方案适合三类人：一是做智慧仓储数字孪生的项目经理或技术负责人，想快速产出 Demo 进行方案验证；二是三维可视化开发工程师，想提升建模效率；三是物流规划工程师，希望通过参数化建模快速评估不同仓库布局方案。

技能要求方面，你需要对 Blender 的基本界面和操作有一定了解，不需要是建模高手，但至少要知道什么是物体模式、什么是编辑模式。Python 基础入门水平就够，因为 Blender MCP 本身已经把大部分操作封装好了。Antigravity 侧主要是任务配置和提示词编写，不需要写复杂的代码。

2. 环境搭建：从零到 Blender MCP 可被调用

2.1 安装 Blender 与 MCP 插件

第一步是装 Blender。我建议直接装 LTS 版本的 Blender 3.6 LTS 或者 Blender 4.2 LTS，这两个版本比较稳定。版本选择别太激进，因为 MCP 插件的兼容性需要时间跟上新版 Blender。

安装完成后下载 Blender MCP 插件源码。拿到的是一个 Python 编写的插件，安装方式跟普通 Blender 插件一致：打开 Blender，进入编辑（Edit）→ 偏好设置（Preferences）→ 插件（Add-ons），点击“安装”按钮，选择插件压缩包，然后启用。启用的标志是在插件列表里能看到 Blender MCP 的条目，并且在右侧 N 面板或者侧边栏出现了 MCP 相关的 UI 界面。

注意：插件的安装路径和 Blender 版本要匹配，不同 Blender 版本的 Python 环境不同，如果你的插件报了“module not found”之类的错误，大概率是版本不兼容。另外，插件安装拿到的是开源社区维护的版本，建议关注仓库的更新状态，最好用最近的 release。

2.2 Antigravity 侧的任务配置

装好 Blender MCP 之后，接下来配置 Antigravity。

Antigravity 的注册和基础配置我这里就不赘述了。进去之后，核心是创建一个新的 Agent 或者项目，然后在工具配置里添加 MCP 服务器。引用的方式很直接：打开 Antigravity 的工具配置页面，选择添加服务器，填入 Blender MCP 的本地连接地址。

如果一切正常，Antigravity 会发现 Blender MCP 暴露出来的工具列表，包括“创建物体”、“移动物体”、“旋转物体”、“修改材质”、“设置场景”、“导入文件”等。这一步是整条链路的命门：如果工具列表没出现，后面所有操作都无从谈起。

2.3 首次调用：让 Blender 动起来

配置完成后，先做一个最简单的冒烟测试。在 Antigravity 对话框里输入：

”请确认 Blender 当前场景的空物体数量。“

如果 Antigravity 成功调用 MCP 工具并且返回了数字，说明链路已经通了。我当时第一次跑通的时候，看到 Blender 右下角的状态栏里出现了脚本执行的提示，那种“AI 正在替你操作软件”的感觉确实很奇妙。

接下来再试一个更复杂的操作，输入：

”在场景中创建一个立方体，边长为 2 米，命名为 UnitTestCube，位置在原点。“

然后去 Blender 里看，会看到从无到有出现了这么一个模型。这一步的意义在于验证 MCP 工具不仅能读场景信息，还能执行写操作。读写都正常，你就有资格进行下一步的实际建模了。

3. 仓储数字孪生的建模思路：先骨架后血肉

3.1 坐标系统与比例尺，建模前必须想清楚的事

在让 Agent 生成货架之前，有一个比建模本身更重要的问题需要先定下来：坐标系统和比例尺。

仓储数字孪生有一个特点——它最终要跟真实业务数据对接，比如库位坐标、AGV 路径、传感器位置。如果模型里一个单位对应现实中的 1 米，那你需要知道每个货架的真实尺寸；如果你只是做概念演示，那可以用 1 单位 = 1 米 的直观比例。

我建议统一采用“1 Blender 单位 = 1 米”的比例，并且把仓库的原点定在仓库大门的中心位置。这样后续接入 WMS 或者第三方物流系统时，从系统里读到的坐标就能直接映射到 Blender 场景中。

3.2 用提示词生成仓库框架

不需要先手动建模，直接让 Antigravity 来。

第一次实际生成时，我的提示词是这样写的：

”请创建一个参数化仓库模型。仓库长 80 米，宽 50 米，高 12 米。地面使用灰色材质，屋顶使用白色材质。创建四周墙壁，其中正门位于 Z 轴正方向，墙高 12 米。请把仓库主体命名为 Warehouse_Main。“

Antigravity 会把这个需求解析为一系列 Blender MCP 调用。我看实际执行结果是：地面出来了，四面墙立起来了，屋顶也盖上了，而且每个物体都有独立命名。整个过程大概几十秒，比我手动建模快了不止一个数量级。

需要重点说明的是，我用的是“参数化”这个关键词，目的是让 Agent 理解这个模型是参数驱动的，后续改尺寸时可以基于参数调整，而不是重新建模。在提示词里加上“仓库长 80 米，宽 50 米”这些具体的尺寸描述，Agent 生成的对象才能带上正确的几何尺寸。

3.3 货架阵列：让 Agent 理解“排、列、层”的语义

仓库框架只是壳，货架才是内容物。货架的建模逻辑可以总结成一个核心公式：货架 = 排 × 列 × 层 × 深度。

以下是我实际使用的提示词：

”在 Warehouse_Main 内部创建货架。货架布局为：10 排货架，每排货架有 20 个库位列，每列货架高度方向上分为 5 层，单双面均为双深位。货架尺寸：长 2.8 米，宽 1.2 米，高 5 米。货架与货架之间的主通道宽度为 3.5 米，货架之间的消防通道宽度为 1.8 米。请根据以上参数自动排列货架，并将每个货架单体命名为 Rack_R_C_L_Layer_L。“

执行完成后，Antigravity 会让 Blender MCP 启动一个脚本循环，在场景里用基准参数生成货架单元，然后按排、列的偏移量复制。关键在于 MCP 插件能否正确处理嵌套循环里的变量——如果提示词里指定了 n 个参数，则循环次数就对应到这个 n 个参数并逐一复用。

这套逻辑跑下来，物料编码是删不掉的：Robot 调度在场景里看到的不再是一个个无差异的立方体，而是带有坐标的货架实体（Rack_R_C_L_Layer_L 就是第几排的第几列的第几层，能直接能让路径规划识别出哪个库位在哪里）。

我在实操中发现，如果让 Agent“裸生成”所有货架，它可能只生成一个货架然后复制粘贴，容易产生重名或者坐标偏移的错误。所以建议在提示词中明确说明“请先生成单个货架单元，再基于该单元进行阵列复制”，这样减少出错的概率。

3.4 材质与颜色：用视觉表达逻辑

建模的下一步是赋予材质和颜色。我在这个环节遵循一个原则：用颜色表达业务状态，而不是单纯追求美观。

比如，货架本体用灰蓝色，代表正常存储区；待检区的地面用黄色，代表需要人工介入；AGV 通道用深灰色，代表机器人行驶区域；货架上的空库位用浅绿色，占用库位用橙色，这可以直观展示仓储空间的使用状态。

Antigravity 执行材质修改时，会调用 Blender MCP 的材质接口。我建议在提示词里给出明确色值，例如：

”将货架金属部分设置为金属质感材质，漫射色 RGB 值为 (0.2, 0.25, 0.3)，粗糙度为 0.4；将库位底板设置为白色哑光材质，RGB (0.9, 0.9, 0.88)。“

为什么不直接说“灰色”？因为“灰色”在 Blender 里可能有十几种实现方式，最终渲染效果差别很大。直接给出 RGB 值，渲染结果可控，这也是我在跟设计团队协作时总结出来的一个经验：让 Agent 做视觉调整时，数值比形容词靠谱。

4. 让 Antigravity 真正驱动 Blender 的关键环节

4.1 MCP 工具调用的底层逻辑

表面上看，你只是在聊天框里输入了一句话，Blender 里就长出了一个货架。但背后经历了一个完整链路：Antigravity 解析用户提示词 → 规划需要调用的工具序列 → 通过 MCP 协议向 Blender 发起请求 → Blender MCP 插件执行 Python 命令 → 返回执行结果给 Antigravity → Antigravity 判断是否需要继续调用。

MCP 的关键设计在于标准化了“工具发现”和“工具调用”。工具发现是指 MCP 服务器启动时，会告诉客户端自己支持哪些操作。工具调用是指客户端按照统一的 JSON 格式发起请求，服务端执行后返回结构化的结果。这种设计的好处是，Antigravity 不需要内置 Blender 的专用代码，插件也不需要理解 Antigravity 的任务调度逻辑，两者之间保持松耦合。

4.2 从请求到模型更新的完整链路

以“创建货架”为例，一次完整的链路是这样的。

Antigravity 端发出一个 create_object 请求，参数包括物体类型（cube）、名称（Rack_1_1_1）、位置坐标（x, y, z）、缩放比例（scale_x, scale_y, scale_z）。Blender MCP 插件收到请求后，把这个 JSON 转换成 Blender 的 Python API 调用，在场景中生成一个立方体并设置其位置、姿态和尺寸。执行完成后，插件返回一个结果，通常包含执行状态和新物体的名称。

这个链路看起来简单，但真正复杂的地方在于 Agent 的多步规划能力。比如要生成 10 排货架，Agent 不是机械地调用 10 次 create_object，它倾向于先生成一个基础货架单元，再循环复制并调整位置。MCP 的工具列表没有直接的“阵列复制”接口，但 Agent 可以利用已有的移动、复制工具组合出这个功能。

4.3 参数命名与数据校验的实战经验

我在多轮实操中发现，参数命名直接决定了后续数据接入的难度。仓库数字孪生最终要跟业务数据库对接，如果货架名称是 Cube.001、Cube.002，对接方会疯掉；如果名称是 Rack_01_Aisle_01_Level_03，对接方直接就能解析。

建议在做规划时就和 Antigravity 明确对象命名规范。有一次我生成货架后，准备把库位数据导出做库存可视化，发现所有货架只有行号没有列号，原因是提示词里只说了“10 排货架”，没有说“每排 20 个库位列”。这种信息缺失直接导致后续工作无法推进。

数据校验方面，我的做法是让 Antigravity 在完成建模后执行一次“自检”：遍历场景中所有对象，输出对象名称列表和位置坐标。这样就可以直观看到有没有命名遗漏、位置重叠等问题。

5. 我在实际搭建中踩过的坑

5.1 版本不一致导致的 MCP 调用失败

第一个坑是环境版本问题。Blender MCP 插件在 Blender 4.0 以上的支持和在 3.6 上的支持有区别，Antigravity 的 MCP 客户端对不同协议版本的支持也不完全一致。如果你遇到调用工具时长时间没有响应，或者返回“tool not found”，很大概率是版本不匹配。

我最终的稳定组合是 Blender 4.2 LTS + 最新版 Blender MCP 插件 + Antigravity 的最新客户端。这个组合我连续跑了一周没有出过大问题。如果实在无法统一版本，还有一个备选方案：在 Antigravity 里指定 MCP 服务器的启动命令和参数，确保它调用的是你安装的那个 Blender 版本。

5.2 坐标系混乱问题

第二个坑是坐标系。Blender 默认是 Z 轴向上的右手坐标系，仓储系统的坐标通常以地面为 X-Y 平面。问题出在把地理坐标转成 Blender 坐标时，需要做一次轴映射。

有一次我让 Agent 生成一条从 A 点到 B 点的 AGV 路径。A 点坐标是 (10, 20, 0)，B 点坐标是 (30, 40, 0)，Agent 生成的路径看起来正常。但当我尝试把 AGV 的路径数据导入到 Three.js 场景时，发现 Z 轴对应关系反了，整个场景旋转了 90 度。后来我在提示词里特别强调：“保持 Blender 默认坐标系统，Z 轴向上”，并且在生成数据导出时，增加了坐标轴转换环节，才算彻底解决。

5.3 Blender 崩溃与场景过重

第三个坑是场景过重。生成货架时，如果一次生成的物体数量过多（比如超过 500 个独立物体），Blender 的实时视口会出现明显卡顿，甚至崩溃。

解决办法有两个：一是使用 Collection 组织物体，把同一区域的货架放进一个集合，降低场景树的复杂度；二是在生成过程中关闭 Blender 的实时视图更新，等所有物体生成完毕后再统一刷新。Blender MCP 插件一般提供了暂停视口更新的控制选项，但需要在提示词中明确要求启用。用 Instancing 的方式复制货架也是一个好的策略，基础模型只保留一个网格数据，其余实例共享同一份几何信息，内存占用大幅下降。

5.4 权限与隔离问题

还有一个经常被忽略的细节：Antigravity 的 Agent 执行任务时，不会主动确认操作是否会影响场景中已有的对象，所以你在调试时如果想保留现有场景，但又不想用新操作破坏它，务必在提示词中写上“保留当前场景中的 XXX 对象”或者“将新对象放入新建集合，命名规则为 XXX”。否则，你可能一句话把辛辛苦苦建好的模型全部删掉。我印象里最惨的一次，意图是修改其中一个货架的高度，结果整个仓库的货架都被重新构建了一遍，之前调好的材质全丢了。从那之后，我写提示词的第一句永远是操作范围限定。

6. 三个值得推荐的进阶用法

6.1 用参数化模板沉淀建模方案

跑通第一遍之后，我建议把常用的建模流程沉淀成参数化模板。比如把一个仓库建模拆成“框架生成”、“库区划分”、“货架生成”、“设备摆放”、“材质应用”五个步骤，每一步都写成固定的提示词模板，只动态传入尺寸参数。这样一来，下次做新项目时，不需要从零开始写提示词，改参数就能出模型。

我的模板中有一个关键的改进：增加中间校验提示——“每完成一个步骤，暂停并输出该步骤生成的对象数量，确认无误后继续下一步。”这个设计能有效防止一个复杂任务执行到最后发现前面某个参数错了，所有步骤推倒重来。

6.2 场景数据导出与外部系统对接

数字孪生不能只停留在 Blender 里，模型最终要放到 Web 端或者游戏引擎里展示。我目前用到的导出链路是：Antigravity 通过 MCP 调用 Blender 的导出工具，把场景导出为 glTF 格式，同时导出包含对象名称、位置、尺寸的 JSON 元数据文件。在前端加载时，解析 glTF 模型构建三维场景，然后把 JSON 元数据绑定到模型对象上，这样点击某个货架时就能显示对应的库位编码。

这套数据的意义在于：前端场景和后端业务系统共用同一套坐标语义，仓储管理系统里查到的某个 SKU 库存和前端看到的某排货架上的某个位置是可以对应起来的。这也就是数字孪生“能用于运营管理”的基本前提。

6.3 用 AI 做场景审查

Antigravity 的另一个用法是做场景一致性审核。比如，你可以让它遍历整个仓库场景，统计“货架对象的总数量”并和预期数量做比对，找出位置重叠的货架，识别出命名不符合规范的物体。

我实际用过一次：让 Antigravity 检查 10 排 20 列 5 层的货架是否全部生成成功。它通过遍历场景对象，发现第 7 排第 13 列缺失，原因是生成任务执行到一半被中断。这种审查如果完全靠人眼在一堆物件里排查，耗时极久，AI 几秒钟就能定位到问题。

7. 上篇的收尾与下篇的展望

读到这里的你应该已经能够独立完成“Antigravity + Blender MCP”环境搭建，并用自然语言生成一个带有货架、通道、库位标识的仓储三维基础模型。这条链路的意义在于：它把数字孪生项目中成本最高、周期最长的物理建模环节，从“人手建模”变成了“参数化生成 + AI 驱动”。我在实际项目中感受到的差距是跨层级的，以前三天出一个库区雏形，现在一小时就能出全局场景，而且模型是结构化的、命名的、可对接数据的。

下篇我会重点讲述数据联动：包括如何把 WMS 的库存数据实时同步到 Blender 场景中的货架上，如何用颜色和标签表达库存状态变化，以及如何让 Antigravity 根据业务数据自动调整仓库布局。这些内容更加偏重数据工程和业务逻辑的结合，也会涉及更多实际业务中的性能优化策略。

最后留一句经验：这套组合工具的学习曲线并不陡，真正的瓶颈在于你能否把业务需求拆解成清晰、可执行的参数和规范。提示词写不好，工具再强也白搭。如果你已经开始折腾，或者正打算从零搭建智慧仓储数字孪生，欢迎随时交流你在环境搭建中遇到的问题，尤其是那些报错信息，往往是最有价值的学习素材。