企业官网建设流程全解析

先说一个结论：把 Antigravity 当成一个“会自己拆任务、会调用工具”的 AI 代理，把 Blender MCP 当成“Blender 的远程控制口”，两者接起来之后，我可以用自然语言让 AI 在 Blender 里直接搭建一整套智慧仓储数字孪生场景——从地面、墙体和货架，到 AGV 路径、输送线和数据锚点，都能自动生成，而且生成的是可编辑、可导出、可对接数据的三维资产。这篇是（上）篇，重点讲清楚工具链的搭建思路和从零建模的实操流程。适合正在做数字孪生、智慧仓储可视化，或者想尝试“AI + 3D 自动建模”这条路线的人参考。就算你之前没碰过 Blender，只要按着步骤走，也能在半天内跑通这套链路。

1. 为什么是 Antigravity + Blender MCP 这个组合

1.1 Antigravity 在整条链路里的角色

第一次看到 Antigravity 的人，很容易把它理解成“一个比较聪明的浏览器”。确实，它的交互界面是浏览器形态，但它真正的价值在于：它能像人一样规划任务、操作页面、调用外部能力，最后把结果交给你。放在我们这个场景里，它扮演的是“项目负责人 + 建模操作员”的角色——你告诉它想要一个什么样的仓储场景，它负责把这句话拆解成几十个具体动作，然后逐个执行。

这里有一个关键认知：Antigravity 本身并不会建模，它也不需要在 Blender 里打开界面去点工具。它通过 MCP 协议连接 Blender，相当于拿到了 Blender 的“遥控器”。你在对话里说“在坐标 (10, 0, 0) 放一个货架”，它就转而调用 Blender 的接口，真正在三维场景里把货架创建出来。这种“大脑负责思考，工具负责动手”的分工，是我后来用顺手了才体会到妙处的。

1.2 Blender MCP 把“说话”变成“建模动作”

MCP 的全称是 Model Context Protocol，一个模型上下文协议，它解决的问题很简单：让 AI 应用能和外部工具互通。你可以把它类比成 USB 标准——电脑插 U 盘、插键盘、插摄像头，靠的都是同一个接口规范，谁也不用为谁单独设计线缆。MCP 就是软件世界的“USB”，Antigravity 是主机，Blender MCP 是外设。

Blender MCP 的具体形态是一个运行在 Blender 内部的插件。插件启用后，Blender 会开放一个本地服务端口，向外暴露一系列工具接口，比如创建物体、创建网格、设置材质、执行 Python 代码等等。AI 代理拿到这些接口清单后，就知道自己“能对 Blender 做什么”。真正动手时，它会生成对应的操作指令，通过 WebSocket 发到 Blender 内部执行，并把执行结果（包括报错信息）带回来。

这套机制最大的好处是：不需要给 AI 装任何 Blender 插件，也不需要让它理解 Blender 的完整 API。它只需要学会使用 MCP 暴露出来的那十几个工具，剩下的复杂操作可以通过“执行 Python 代码”这个万能接口完成。这也是为什么我说这组合是“中间路线”——比纯手工建模快，比纯代码门槛低。

1.3 数字孪生场景对建模流程的三个硬要求

做智慧仓储数字孪生，和做普通三维动画场景，需求差别很大。普通场景追求“好看”，数字孪生场景追求“可算、可对、可改”。具体来说有三个硬要求：

第一，可参数化。仓储布局经常要调整，货架数量、层数、通道宽度随时可能变。如果每个模型都是手工摆出来的，改一处就得重新来一遍。所以从一开始，货架、输送线、AGV 路线这些元素就应该用参数驱动。

第二，可对接数据。数字孪生不是静态模型，每个货位要对应库存数据，每台 AGV 要对应实时位置，每条输送线要对应运行状态。这就要求模型里的每个对象都有明确标识，将来才能绑定数据。

第三，可导出。场景最终不一定只留在 Blender 里，常见的做法是导出成 glTF 或 FBX，丢到 Three.js 前端、Unity 或者自研引擎里去跑。所以建模过程必须坚持米制单位和合理命名，否则导出到别的环境就是一团乱麻。

手工建模满足不了这些要求，尤其是“改参数出第二版”这个需求。而用 Antigravity 驱动的 Blender MCP，恰好能把建模过程变成一串可复用的对话指令——换一组参数，就是一版新场景。

2. 环境准备与工具链搭建

2.1 装好 Blender 与 Blender MCP 服务端

先从 Blender 说起。版本方面，我建议用 3.6 LTS 或 4.x 系列，太老的版本对 Python API 的支持不完善，MCP 插件执行代码时容易踩到接口变更的坑。下载安装后，打开 Blender，进入“编辑 → 偏好设置 → 插件”，点击“安装”，选择你下载的 blender-mcp 插件压缩包。启用后，插件会在 Blender 内部启动一个本地 MCP 服务端。

这里有个细节容易忽略：Blender MCP 本身并不是一个独立进程，它是跟着 Blender 走的。也就是说，Blender 必须保持打开状态，MCP 服务才会在线。很多人第一步就卡在这里——Blender 没开，自然连接不上。另外，建议打开“窗口 → 切换系统控制台”，把 Blender 的控制台面板显示出来，MCP 服务启动时的端口信息、后续收到的每条指令，都会打印在这个面板里。这个面板就是你的调试窗口。

启用插件后，默认情况下服务端会监听在本机的某个端口上。你可以先在浏览器或者命令行工具里访问一下本地地址，确认服务确实响应了，再做下一步。要是端口被其他程序占用导致启动失败，控制台里会直接报错，换成空闲端口即可。

2.2 在 Antigravity 里挂上 MCP 连接

接下来把 Antigravity 和 Blender MCP 连起来。打开 Antigravity 的设置界面，找到 MCP 连接相关的配置项（不同版本入口位置可能略有差异，一般在设置或扩展管理里）。这里需要填写两个东西：一是本地 MCP 服务的地址，一般长这样：ws://127.0.0.1:端口号/mcp；二是认证 token，如果服务端开启了鉴权的话。

关于 token 必须单独说一句：不要在公开帖子里复制别人贴出来的 token 字符串来用。原因有两个——其一，服务端校验的是“谁持有有效 token”，别人分享的 token 指向的是别人的服务实例，你拿来也用不了；其二，把 token 公开在网络上是实打实的安全隐患，别人可以拿它连接你的服务。正确做法是自己在本地服务端生成、自己保管。网上教程里出现的 token 截图，一律当作无效信息处理。

填完地址和 token 之后，保存配置，Antigravity 会去握手连接。连接成功的话，它会拿到 Blender MCP 暴露出来的工具清单，你可以在工具列表里看到类似“创建物体”“执行代码”这样的条目。到这一步，链路就通了。

2.3 验证链路是否打通（打通测试三步走）

配置完成后别急着建大场景，先做三轮小测试，确保链条的每一环都正常。第一轮，创建基础物体：在对话里让 AI“在原点创建一个立方体”。去 Blender 里看视图，如果出现了默认立方体，说明基本的指令传递和执行没问题。

第二轮，设置材质与变换：让 AI“把刚才的立方体改成红色，并移动到 (2, 0, 0)”。这轮测试的是参数传递是否正确，颜色、坐标这类数值有没有被正确解析。

第三轮，执行自定义代码：让 AI“用 Python 代码创建一个半径为 1 的圆环网格”。这轮测试的是 MCP 的代码执行接口是否可用，这是后面所有高级操作的基础，也是 Antigravity 出现 update 报错、403 之类问题后最先要回查的环节。

三轮测试全部通过后，建议在笔记里记录下当前用的 Blender 版本、MCP 插件版本和 Antigravity 版本。别嫌麻烦，后面遇到任何诡异报错，第一件事就是核对这三个版本是否和你记录的一致。版本不匹配造成的兼容性问题，比配置错误更隐蔽。

3. 从零搭建智慧仓储场景

3.1 先别急着建模：布局规划与坐标系

很多人的习惯是拿到需求就开干，让 AI 生成一堆物体，堆在一起才发现比例不对、坐标混乱。我的习惯是先在对话里把“场地规则”定下来，再开始建模。

数字孪生场景我强烈建议采用 1:1 米制比例，也就是 Blender 里的 1 个单位等于真实世界的 1 米。这样做的原因是：后续数据对接时，你不需要做任何换算，IoT 设备上报的坐标直接就能映射到模型上。千万别用什么“一格代表一厘米”的自定义比例，当时爽，后面痛。

接着确认坐标系约定。我习惯把仓库的西南角设为世界坐标原点，东西方向是 X 轴，南北方向是 Y 轴，Z 轴向上。这样背后的好处是：所有货架的坐标都落在正象限里，AGV 路线的控制点也都是正坐标，任何时刻都不会出现负坐标导致的对齐错乱。

以我常用的样例仓库为例：长 40 米、宽 30 米，中间设一条 4 米宽的纵向主巷道，两侧排布货架区。第一步，让 AI 在 Blender 里创建 40×30 米的平面作为场地地面，贴一个简单的地面材质。这个平面就是后续所有物体的“基准面”，货架底座、AGV 路线、输送线的高度都从它往上算。

3.2 用自然语言把基础结构“说”出来

场地就绪后，就可以开始用自然语言下达建模指令了。这里想强调一个我踩过很多次坑才总结出来的原则：一次对话只提一批需求，别啰嗦。

反例是：“创建仓库的四面墙，再加一个大门，然后放 20 组货架，每组 3 层，还要一圈 AGV 路径。”这种笼统指令下去，AI 确实会执行，但它会自作主张地决定墙体厚度、货架间距、路径半径这些细节，结果大概率和你心里想的不一样。

正例是分步来。第一批：创建四面墙体，高度 6 米，墙体厚度 0.2 米，在 X 轴负方向一侧留出一个 5 米宽的大门位置。第二批：在巷道两侧按对称布局创建货架区。第三批：创建 AGV 路径曲线。每批之间，我都切到 Blender 视图里确认一下，有问题当场修正，再进入下一批。

为什么必须分步？因为 MCP 一次只能执行一个动作。虽然 AI 有规划和拆解能力，但拆解得越清晰，生成结果越可控。你把它当成一个理解力很强的实习生，把任务拆成“先做什么、再做什么、每步做到什么标准”，它就不会自由发挥。

分步执行的另一个好处是可回溯。哪一步出的问题，就在哪一步对话里修正，不会把错误一路带到底。

3.3 货架、AGV、输送线的参数化建模

基础结构完成后，进入核心环节：仓储三大件的建模。先说货架。货架在仓储数字孪生里出现频率最高，数量大、结构重复，是最适合参数化的对象。我不会让 AI 一个货架一个货架地去建，而是让它在指定位置创建一个货架单元（比如一组立柱加三层隔板），然后给这个单元加上阵列修改器，指定阵列的数量和间距。这样一排货架就出来了，而且参数可调——想改成 4 层货架，改一个参数就行，不用重建。

这里给一段示意代码，方便理解原理。实际使用中我通常直接让 AI 执行类似逻辑，而不用手敲：

import bpy # 创建货架单元：一个底座 + 三层隔板 bpy.ops.mesh.primitive_cube_add(size=1, location=(0, 0, 0.5)) base = bpy.context.active_object base.scale = (1.2, 0.8, 0.1) for i in range(3): bpy.ops.mesh.primitive_cube_add(size=1, location=(0, 0, 1.2 + i * 0.8)) shelf = bpy.context.active_object shelf.scale = (1.2, 0.8, 0.05) # 给单元加阵列修改器，沿 X 轴阵列 8 组 bpy.ops.object.select_all(action='DESELECT') base.select_set(True) mod = base.modifiers.new(name="ShelfArray", type='ARRAY') mod.count = 8 mod.relative_offset_displace[0] = 1.2

这段代码的思路是“单元 + 阵列”，仓库里任何重复度高的结构都适用。货架命名可以按RACK_A01这样的规则来，A01 代表 A 区第 1 组。每个隔层也可以自定义属性记录它的容量和编号，为后面数据对接做准备。

接下来是 AGV。AGV 本身可以用一个扁平的盒子或者胶囊体表示，真正重要的是它的行驶路径。我用 Bezier 曲线来画路径，把曲线控制点安排在货架之间的巷道中线上。为什么用曲线而不是直线段？因为 AGV 转弯需要平滑过渡，Bezier 曲线天然自带平滑性，也方便后续导入到 Unity 或者前端之后做轨迹回放。

输送线的建模思路和货架类似：创建一段输送线单元（长的扁立方体），阵列后加上一条循环动画，让物体沿输送线方向循环移动。这个动画在 Blender 里看着是示意效果，导出到数字孪生平台之后，再通过数据驱动替换成真实的运行状态。到这个阶段，整个场景的“骨架”就已经立起来了。

3.4 为数字孪生预留数据锚点

很多人建完模型就急着导出，结果到了前端才发现：模型是有了，但不知道该往模型的哪个位置绑定数据。这个问题必须在建模阶段就解决，解决方案是“数据锚点”。

具体做法是，在关键位置放置空物体（Empty），这些空物体本身不渲染，只提供一个坐标位置。我在每个货架区、每台 AGV 的停靠点、每条输送线的首尾段、大门口、充电桩位置，都放了空物体，并按功能命名，比如Anchor_Camera_01、Anchor_Charger_A、Anchor_Sensor_Dock。将来摄像头实时画面要叠加到三维场景里，直接锚定到Anchor_Camera_01的位置，不用再去翻模型找坐标。

另一个更实用的习惯是给物体添加自定义属性。Blender 支持在物体属性面板里加自定义字段，我在货架物体上加了storage_id、capacity、status这几个字段，在 AGV 上加了vehicle_id和battery_level字段。这些字段现在只是占位符，但等真正对接数据库和 IoT 数据时，前端可以直接读取这些属性做绑定。

命名规范也要提前定。我的一套规则是：货架用RACK_区域_组号_层号_货位号，AGV 用AGV_编号，锚点用Anchor_类型_编号。这套规则看起来不起眼，但在数据对接环节能省下大量时间——前端拿到模型后，靠着名字就能把数据挂到对应物体上，而不是靠人力一个个去对坐标。

4. 实操中踩过的坑与排查技巧

4.1 MCP 连接不上、超时怎么办

这条链路最容易出的问题就是连接。我整理了一个排查顺序，按这个顺序走，基本能定位九成以上的问题：

技术细节上，最常踩的坑是协议前缀搞错。Blender MCP 走的是 WebSocket 协议，地址前缀应该是ws://，而不是http://。如果填成 http，Antigravity 会不停地握手超时，报错信息还很抽象。另外一个容易忽略的点是：本地服务默认只监听了127.0.0.1，如果你为了调试把它改成了监听所有网卡，就要特别注意安全——本地开发场景没有正当理由不要暴露到局域网或公网。

4.2 模型比例失控、位置偏移

第二个高频问题，是生成出来的模型比例完全不对。有一次我让 AI 创建一个“3 米高的货架”，结果它创建了一个 30 米高的庞然大物，整个场景瞬间被塞满。排查后发现，问题出在我没在上下文中声明“单位约定”，AI 默认跑到了 Blender 的某个默认比例里去了。

解决办法是在整个对话的早期就固定单位：明确告诉它“当前场景 1 个 Blender 单位等于 1 米，所有尺寸都按米为单位输入”。这句话要放在第一批指令里，并且最好在后面的每轮关键指令里重复强调，防止 AI 在长对话中“忘记”约定。

位置偏移的问题则往往出在目标原点。Blender 里每个物体都有自己的原点，当 AI 执行阵列或者复制操作时，如果物体原点和它的几何中心不重合，阵列结果就会歪掉。一个有效的兜底方案是：每个物体创建后，强制让 AI 执行“设置原点到几何中心”的操作，把原点校准一次。这步操作看着多余，但在复制、阵列、导出环节能避免大量对不齐的问题。

4.3 AI 执行的代码报错、对象错乱

第三类问题集中在 AI 生成的 Python 代码上。Blender 的 Python API 版本差异很大，从 3.x 到 4.x，很多接口的调用方式变了。AI 训练数据里包含大量旧版本代码，执行到新版本的 Blender 里就可能报错。面对这种情况，我的经验是不要急着骂 AI，而是让它自己读报错信息，然后修正重试。MCP 的优势在于，报错信息会原样传回给 AI，它能看到 Blender 抛出的异常，具备自我修复的基础。

对象错乱的问题也有一个常见来源：选择集残留。Blender 是基于“当前选中对象”执行操作的，如果上一轮操作选中了物体 A，这一轮想让 AI 修改物体 B，AI 又没有显式取消选中，就可能改错对象。我的习惯是要求 AI 在每段操作代码开头先执行一次“取消全选”，再精准选择目标对象。这个习惯养成之后，错乱问题基本绝迹。

最后补充一个工作习惯：每完成一批建模，就截图确认一次，并让 AI 用一句话说明它刚刚做了什么。这个“对话留痕”的习惯，对长对话尤其重要，因为一旦后续出了问题，你可以顺着截图和说明快速定位是哪一步偏离了预期。

5. 这波操作给我的真实体会

用了这条链路大半年，我最深的感受是：它的价值不在于“自动建模”这四个字，而在于把建模过程变成了一串可复用的指令序列。以前我建一个仓储场景，从规划到完成大概要两三天，其中大量时间花在重复性操作上——复制货架、摆放位置、调整尺寸。现在这些工作变成了对话里的几十轮指令，存下来就是一套“场景生成模板”。下个项目来了，改改参数，重新跑一遍，一个新场景就出来了。这种可复用性，才是比“省时间”更值钱的东西。

在实际操作中还有一个心得：别把 Antigravity 当成无所不能的工具，它更像一个执行力很强但需要明确约束的伙伴。你对它越清晰，交付越稳定；你给它发散指令，它就给你发散结果。所以我现在每逢复杂任务，都会先写一个“项目约束说明”放在对话开头，把单位、坐标系、命名规范、分步节奏全部固定下来，然后才进入正式建模。

下一步我打算做两件事，也是（下）篇准备展开的内容：一是把生成的场景导出成 glTF 格式，接进 Three.js 前端，让网页端能实时浏览仓储场景；二是把货架、AGV 的自定义属性和实际的 IoT 数据对接起来，让模型真正“活”起来——货架状态、AGV 位置、输送线运行都由真实数据驱动。到那时候，这套 Blender 里的静态场景才能真正称得上数字孪生体。如果你也在这条链路上折腾，建议先把（上）篇的这套基础流程跑通，后面数据联调环节，你会感谢当初认真做的命名规范和那些不起眼的空物体锚点。