企业官网建设流程全解析

1. 先搞清楚：我们这一期到底要搭个什么

最近在做一个3D智慧仓储数字孪生的项目，我一个很深的感受是：大多数人对“数字孪生”的理解还停留在“用三维软件画个好看的仓库模型”这个层面。但真做起来，你会发现模型只是地基，关键在数据和坐标。仓库里的货架、货物、通道、AGV运行路径，每一样东西除了要长得像，还必须能被程序读取、被业务系统驱动、被前端页面实时渲染。这件事的工程量，远远超过“建个模”。

所以这次我换了思路：不自己一格格去建模，而是把建模工作交给“Antigravity + Blender MCP”这套AI协作流程。简单说，我只需要用自然语言描述需求，Antigravity负责编排任务、调用MCP服务，Blender MCP在三维软件里执行AI生成的指令，最终得到一个“能跑数据的仓库场景”。这一期是“上篇”，先解决最核心的问题：怎么用这套组合把仓库场景搭起来，并把业务数据挂到三维物体上，让模型从“能看”变成“能用”。

这套工作流特别适合谁？第一类是正在做智慧园区、智慧物流、工业数字孪生项目的人，你们大概率还在用传统方式手动建模，可以看看AI协作能省多少时间；第二类是前端工程师，想把three.js或者Unity的场景数据接回来，这篇文章会讲清楚模型坐标和数据的导出链路；第三类是刚接触数字孪生、想低成本验证概念的同学，这套方案几乎零门槛，一台能跑Blender的电脑就够了。

2. 拆开看：数字孪生、Blender MCP、Antigravity各自扮演什么角色

2.1 数字孪生的三层架构：不止是“像”

我在实际项目里习惯把数字孪生拆成三层来看。最底层是数据层，包括库存数据、设备状态、传感器数据、点位坐标，这些是“孪生”的灵魂；中间层是模型层，也就是Blender里面建的货架、货物、AGV、摄像头等三维对象；最上层是交互层，也就是前端页面、大屏或者VR终端，用来把数据和模型叠加展示给使用者。

很多人做孪生项目容易犯一个错误：先把模型建得很漂亮，然后才去考虑数据怎么接，结果要么模型结构没法对应数据字段，要么坐标系统对不上，最后只能返工。正确的顺序应该是先确认“哪些物体有数据、数据长什么样”，再倒推模型结构。比如仓库里的一个货位，它需要包含货位编号、所属货架、层数、当前库存、容量上限，那么建模的时候就要给这个货位对象挂上这些属性字段，而不是只建一个立方体。

2.2 Blender MCP到底做了什么

MCP全称是Model Context Protocol，模型上下文协议。它解决的问题很直接：AI模型没法直接操作你电脑上的软件，MCP就是那座桥。浏览器里有Chrome DevTools MCP、自动化测试可以用Playwright MCP，而Blender MCP则是专门用来连接AI和Blender的。

Blender MCP的服务端运行在本地的Blender里，通常是作为一个插件启动。AI客户端连接上这个服务端之后，就能通过预定义的工具类型指令来操作Blender，比如创建物体、修改材质、摆坐标、批量生成。对我来说最常用的是让它直接执行Python代码，因为Blender本身就是全Python驱动的，有了MCP，AI就可以绕开“只能给我看代码、不能自己跑代码”的尴尬局面。

这带来的体验变化是质的：以前你说“帮我建一个20米乘20米的仓库地面，再放四排五层货架”，AI只能给你一段代码，你得自己复制进Blender的Scripting窗口执行；现在你用Antigravity这类Agent工具连上Blender MCP，它直接就在Blender里把场景建好了。省去的不是一点点时间，而是整个“人在中间传话”的环节。

2.3 Antigravity在项目里的定位：AI编排中枢

Antigravity这类Agent开发环境，在我看来就是承担“裁判和调度员”的角色。AI编程工具本身已经很常见，但单个对话窗口的能力是有上限的，尤其在项目链路长、工具多的时候，你需要一个能自主拆解步骤、按顺序调用不同MCP服务、处理中间错误的执行体。Antigravity把这种能力产品化了：你给它一个目标，它自己去规划，去执行，遇到问题还能读报错并调整方案。

在“Antigravity + Blender MCP”这个组合里，Antigravity负责这么几件事。第一，理解你的中文需求，拆解成“建地面、建货架、批量放货物、挂数据”这样的子任务；第二，按顺序调用Blender MCP的工具，把生成的Blender Python脚本送进去执行；第三，维护整个会话上下文，比如你中途说“货架往左边挪两米”，它能知道指的是哪排货架，而不是当新需求处理。

当然，Antigravity本身是一个通用Agent平台，不是只服务于Blender。所以一个典型的做法是把Blender MCP作为MCP Server配置进Antigravity里面，让它能同时拿到多个工具能力。如果你的环境里还配了浏览器MCP、文件系统MCP、数据库MCP，那它就能干更多事，比如读取库存CSV、调业务API、最后驱动Blender建模。这也是为什么我选择Agent平台而不是单纯在聊天对话框里写代码的根本原因：只有Agent化，跨工具协作才能真正自动跑起来。

3. 环境准备与MCP连接，一次说清

3.1 软件安装清单

动手之前先把环境备齐。我用的配置是Windows 11主力机加一张中端独显，Blender版本用的4.1以上，Python环境通过uv管理，MCP插件直接从Git仓库拉取。Blender本身建议直接从官网下载长期支持版，不要用发行版的精简包里带的旧版本，因为MCP插件往往依赖新版Python API。

Antigravity这边，你需要一个能登录的账号，它本质上是云端算力加本地Agent调度。首次使用会检查资格和权限，建议把账号权限、区域配置、API密钥这些提前确认好，不然很容易在启动任务时卡在权限校验。连接Blender MCP时一般会用WebSocket形式的服务地址，也就是以wss://开头的MCP端点，注意这个地址里通常会带token参数，token就是你连接服务的身份凭证，泄露了等于别人能控制你的Blender会话，要保管好。

3.2 配置Blender MCP Server，尽量一次通过

Blender MCP的部署流程，我拆成三步。第一步，把MCP服务端代码克隆到本地，用uv工具安装依赖，这是目前最不容易踩坑的Python包管理方式；第二步，在Blender里安装配套插件，然后在插件面板开启MCP服务，它会监听一个本地端口，等待外部连接；第三步，在Antigravity的MCP配置里加入这个服务，把地址类型、端口、token填对，保存后测试连通性。

一个容易搞混的地方：MCP的连接协议有stdin、SSE、WebSocket几种，Blender MCP这类针对GUI软件的服务大多走的是WebSocket，因为它需要持续双向通信，AI端随时要把Python代码送进去执行，Blender端也会往回传执行结果。配置示例大概是这样的：

{ "mcpServers": { "blender-mcp": { "command": "uv", "args": ["run", "blender-mcp"] } } }

如果你的Antigravity环境只支持WebSocket地址，那就直接填MCP服务端页面显示的那个wss://地址。验证是否连通有个土办法：先给AI发一条最简单的指令，让它打印Blender场景里的物体列表，如果返回了物体名字，就说明链路已经通了。我每次换新环境都会用这个“最小测试”保底，能省掉后面一大半排查时间。

注意：MCP服务端和Blender插件必须是同一个版本仓库里的东西，混搭版本经常出现“服务端连上了但工具调用没反应”的诡异问题。

4. 实操：用自然语言建一个智慧仓库场景

4.1 先生成一个能跑的地基

整个仓库场景从地面开始。我会先给Antigravity一个空间尺寸定义，而不是让它瞎猜。数字孪生最忌讳的就是模型比例不一致，后面导出到前端、对接点云或导航数据时会全面错位。

我实际下的第一条指令是这样：“在Blender中创建一个长20米、宽15米的仓库地面，用平面网格生成，坐标为原点居中。再在四周生成高度4米的墙体，墙体厚度0.2米，留出南侧一个5米宽的出入口。”几秒钟后Blender里就会出现一个标准的矩形空间，地面是网格物体，墙体是挤出的立方体。之后我不需要再操心坐标系，因为Blender的正交视图和系统原点已经基于这个框架定义好了。

这条指令的背后，Blender MCP实际上是让AI生成了这样一段核心Python代码并通过工具执行：

import bpy # 清理默认场景 bpy.ops.object.select_all(action='SELECT') bpy.ops.object.delete() # 创建地面 bpy.ops.mesh.primitive_grid_add(size=20, x_subdivisions=10, y_subdivisions=10) floor = bpy.context.active_object floor.name = "Warehouse_Floor" floor.location = (0, 0, 0) # 创建墙体 bpy.ops.mesh.primitive_cube_add(size=1) wall = bpy.context.active_object wall.scale = (20, 0.2, 4) wall.location = (0, -9.9, 2) wall.name = "Wall_North"

需要说明的是，AI生成的代码不一定会这么规整，但它能读懂“长20米宽15米墙体高4米”的空间语义，转换成对应数值。这里有一个我反复踩坑后总结的原则：给AI的空间尺寸必须具体，否则AI会默认生成一个Blender里常见的2米见方小场景，最后你在里面压根放不下货架。

4.2 让货架和货物批量“长”出来

场景框架建好后，重点就来了：用AI批量生成货架和货物。仓储场景里货架数量动辄几十上百，手动摆放根本不现实。Antigravity的高效之处在于它能理解“批量”这个概念，并且自动用循环去生成，而不是真的一个个加。

我的指令是：“在仓库内部生成6排货架，每排长8米，货架高2.4米，分5层，每层再分4个货位格，背靠背摆放，两组之间留出1.2米通道。”执行后，AI会用循环加嵌套的方式在Blender里创建大量立方体，并把每个立方体按“哪排、哪层、哪个格子”进行命名，比如Rack_01_Level_3_Slot_2。

这一步是整期项目里最考验MCP稳定性的环节，因为批量生成意味着几十上百次物体创建操作，如果连接稍微不稳定，半路就会断掉。我的做法是让它先生成两排验证，确认模型尺寸和通道宽度没问题后，再让它“按照相同规则生成剩下四排”。这种小步快跑的方式看起来多花了点时间，实际上反而省了反复返工的麻烦。

货物建模也同理。比如输入：“在货架每个格子内生成一个尺寸0.8×0.9×0.6米的货物箱，货物箱与格子的间距保持在0.05米。不同层高用不同颜色区分，底层蓝色、中层绿色、顶层橙色。”AI会按层循环生成货物箱，并自动设置材质颜色。这样出来的场景既有视觉区分度，又便于后期按层做数据处理。

4.3 挂上业务数据，模型才算数字孪生

三维物体建得再像，没有数据就不是数字孪生。这一步要做的是给每个物体添加自定义属性。Blender物体可以通过Python直接写自定义属性，这些属性会随工程文件保存，导出时也能通过脚本读取。

我在生成货架和货物后，会继续让AI“为所有货物箱添加custom property，键名是sku、quantity、storage_date，其中sku和数据里CSV文件的sku字段对应”。假如你有真实的库存Excel或CSV文件，可以让AI读取文件再反写属性。这种做法的好处是：三维场景的每个货物箱都对应一条真实业务记录，前端点击模型时可以直接展示“这个箱子是什么商品、有多少件、什么时候入库”。

给物体挂属性的代码大致是这个模式：

import bpy obj = bpy.data.objects["Box_SKU_10086"] obj["sku"] = "SKU-10086" obj["quantity"] = 120 obj["storage_date"] = "2025-06-18"

这一步跑通之后，模型的“样子”和“数据”就绑定了。后面不管是做前端可视化、做库存热力图、还是对接WMS系统，都有了最基础的数据底座。

5. 把“孪生”变成“可用”：坐标拉框与前端数据链路

5.1 拉框到底在拉什么：AABB和OBB的区别

做智慧仓储绕不开“拉框”这个词。尤其你接触过3D点云、3D结构光相机、AGV导航雷达数据的话，拉框其实就是给场景中某个区域或物体定义一个矩形边界范围。在三维空间里，拉框一般有两种：AABB，轴向对齐包围盒，也就是不管物体怎么摆，框的每条边都平行于坐标轴；OBB，有向包围盒，框跟着物体的旋转方向走。

建模阶段我们用AABB就够了，因为货架货物大多数都是横平竖直摆放的。但如果是后续对接3D雷达点云数据，比如一辆AGV要通过通道，它的导航系统会基于点云实时生成障碍物框，这种框往往是任意姿态的，就要用OBB去表达。我在项目里是把Blender建模出来的货物位置导出成坐标列表，后期让AI把列表转换成前端导航可读的障碍物数据，这个过程也属于“拉框”的一部分，只是对象从图像变成了坐标数据。

数字孪生项目的演进路线通常就是这样：先用Blender MCP批量建立静态模型，再通过点云或者结构光相机实时数据来更新货物状态。前者管“长什么样”，后者管“现在什么样”。如果你的仓库里装了3D视觉传感器，建议从一开始就在Blender里把相机位置也建出来，并且给相机挂上视角参数，这样点云数据映射到三维场景时会有对应关系。

5.2 导出可被前端读取的JSON场景

三维场景最终要给前端用，所以必须导出一个前端能轻松解析的格式。Blender自带的导出格式很多，FBX、OBJ、GLB都行，但对我来说信息最完整的还是自定义的JSON格式，因为可以同时包含几何信息、坐标和业务属性。前端拿到这个JSON，用three.js就能还原场景。

我在Blender Scripting窗口写了一个导出脚本，通过MCP让AI执行，跑完直接生成一个warehouse.json文件。脚本核心结构如下：

import bpy, json scene_data = [] for obj in bpy.data.objects: if obj.type != 'MESH': continue item = { "name": obj.name, "type": obj.get("obj_type", "general"), "sku": obj.get("sku", ""), "quantity": obj.get("quantity", 0), "position": [obj.location.x, obj.location.y, obj.location.z], "dimensions": [obj.dimensions.x, obj.dimensions.y, obj.dimensions.z], "rotation": [obj.rotation_euler.x, obj.rotation_euler.y, obj.rotation_euler.z] } scene_data.append(item) with open(r"D:\projects\warehouse.json", "w", encoding="utf-8") as fp: json.dump({"objects": scene_data, "scene_name": "Warehouse_A"}, fp, ensure_ascii=False, indent=2)

这个JSON里每一条记录都能对应Blender里的一个物体，前端拿它来做搜索、渲染、点击交互都非常方便。真正的数字孪生项目，模型是静态底座，数据是动态血液，两者在这个环节第一次完成合流。

这里还要提一句，很多人问Blender能不能直接导出SketchUp格式，其实Blender没有原生SKP导出。更合理的做法是导出FBX再转换，但如果我们本来就要给前端用，建议直接走GLB或JSON，不要绕道SketchUp。三维数据交换的原则是：能用轻量格式就不要用重量级格式，能走JSON就走JSON。

6. 常见报错与排查，都是我踩过的坑

6.1 Antigravity执行到一半报错：agent execution terminated due to error

这个报错是我遇到最多的。第一次跑完整流程时，AI执行到生成货物箱的步骤直接终止，控制台只留下这么一句，没有任何细节。后来排查下来，问题出在MCP连接在批量操作时断连，导致工具调用的响应没回来，Agent判定任务执行异常就自行终止了。

解决思路分几步：第一，检查Blender MCP服务端窗口是否还开着，批量生成的耗时操作会让Blender的Python进程处于繁忙状态，这段时间如果AI发起新的工具请求，可能超时；第二，把任务拆小，不要指望一条指令生成几百个物体，拆成“每排生成”甚至“每层生成”能明显降低断连概率；第三，确认Antigravity的任务级配置里超时时间是否太短，有些默认超时只有几十秒，生成大场景是不够的。

我在项目里养成了一个习惯：凡是生成步骤，都会主动告诉AI“这个操作可能耗时较长，请等待执行结果再发起下一步”。这句话能有效阻止AI在等待期间重复调用工具，减少很多无谓的报错。

6.2 Antigravity 403和eligibility check failed

403一般是访问某接口时被拒绝。如果你是在Antigravity里调用外部的MCP端点，收到403说明身份凭证没有通过服务端校验。常见的是token过期，或者token绑定的权限范围不匹配。我的处理方法是重新生成token，确认新token对应的权限组包含当前项目需要的工具类目。

eligibility check failed是我刚开始接触时一脸懵的报错，翻译过来是“资格检查失败”。这通常和账号的可用区域、套餐类型或者角色权限绑定，不需要过度解读，直接按提示去检查账号状态即可。如果遇到这类校验问题，优先看账号控制台是否提示某个功能未开通，而不是反复重启任务。

6.3 Blender MCP连接不上的几种情况

Blender MCP看着简单，连接不上时的坑可不少。我整理成一张速查表：

还有一个非常容易被忽略的问题：Blender在后台运行时如果弹出任何模态对话框，MCP客户端发过来的操作就会一直排队等待，表现就是“连接正常但任务卡住”。解法是先确认Blender界面没有弹出保存文件或者材质编辑之类的阻塞对话框，再去排查其他原因。

7. 一些真正有用的后续扩展想法

到这一步，“上篇”的核心链路已经跑通：Antigravity编排任务，Blender MCP连接三维软件，模型和数据在Blender里完成绑定，最后导出JSON交给前端。从这个底座出发，能延伸的方向非常多。

我个人最推荐下一步做的事情，是把库存JSON放到一个本地接口服务里，前端用three.js加载GLB模型，然后再请求这个JSON做动态标签和数据面板。你会发现，当三维模型里有坐标、有sku、有quantity之后，前端做点击选中的交互几乎是白送的。另一个值得投资的方向是接入3D结构光相机或3D雷达的点云数据，把实时点云和Blender里的静态模型做配准，这样当仓库里的货物被挪动时，系统能自动识别偏差。这条链路走通以后，你的项目就不叫“三维可视化”了，那才是真正的数字孪生。

这一期先到这里，下次可以接着聊怎么把Blender里建的仓库导出成前端能快速渲染的模型格式，以及如何通过MCP把实时库存数据推送进场景里。对和我一样在搞数字孪生项目的人来说，这条路值得走下去。