企业官网建设流程全解析

1. 为什么我要用 Blender MCP 来做仓储数字孪生

先说结论：如果你打算用 Three.js 从零手搓一个智慧仓储的数字孪生场景，大概率会在"建模"这一步就把耐心耗光。货架、叉车、托盘、AGV、传送带、堆垛机，这些东西在 Three.js 里用 BoxGeometry 拼出来，看着就像幼儿园积木，完全没有工业现场那种"重资产"的质感。而 Blender 恰好能补上这块短板——它免费、建模能力强、材质系统成熟，还能通过 MCP 协议把模型数据直接喂给前端。

我这次做的项目，目标很明确：搭一个 3D 智慧仓储数字孪生场景，包含货架区、分拣区、AGV 通道、堆垛机、传送带，并且要能实时反映库存状态、设备运行状态、告警信息。技术栈定的是 Vue 3 + Three.js + TypeScript，模型来源用 Blender 制作，中间通过 Blender MCP 打通"建模—导出—前端加载"这条链路。

这里要先解释一下MCP是什么。MCP 全称 Model Context Protocol，直白点说，它是一套让不同工具之间"对话"的协议。Blender MCP 的作用，就是让 Blender 这个建模软件，能够被外部的程序（比如一个 Agent、一个脚本、甚至一个前端工程）以标准化的方式调用和读取数据。你可以把它理解成"Blender 对外开的一个标准接口"，而不是每次都要手动导出 glTF、再手动拖进项目里。

为什么不用 Unity 做数字孪生？热词里也出现了"unity数字孪生"，这确实是一条成熟路线。但 Unity 的部署成本高，Web 端要跑 WebGL 构建包，体积大、加载慢，而且和 Vue 3 的集成不如 Three.js 自然。对于一个"前端数字孪生网站"来说，Three.js + WebGL 是更轻的选择。Blender 负责"重"的部分（建模、材质、动画烘焙），Three.js 负责"轻"的部分（渲染、交互、数据绑定），这个分工是我实测下来最舒服的。

至于标题里的Antigravity，它在这个项目里扮演的是"调度者"的角色——负责协调 Blender MCP 的调用、管理模型资产的版本、驱动整个数字孪生场景的构建流程。你可以把它当成一个 Agent 层，它不直接画模型，但它决定"什么时候调 Blender、调哪个模型、导出成什么格式、放到前端哪个位置"。这种分层思路，是后面所有实操的基础。

提示：数字孪生不是"把 3D 模型放到网页上"就完事了。真正的数字孪生，模型只是壳，数据才是魂。所以从第一天起，就要想清楚"哪些数据要绑到哪个模型上"。

2. 数字孪生三层架构在仓储场景里到底怎么落地

2.1 三层架构不是概念，是分工

热词里有"数字孪生三层架构"，很多人背得出"物理层、数据层、应用层"，但一到落地就懵。我按仓储场景给你翻译一遍：

这个分法的价值在于：每一层只关心自己的事。物理层不管数据从哪来，数据层不管模型长什么样，应用层只负责把前两层"粘"在一起。我见过太多项目把这三层揉成一坨，结果改一个货架颜色都要动数据接口，维护成本爆炸。

2.2 物理层的建模边界：哪些该在 Blender 做，哪些该在 Three.js 做

这是最容易踩坑的地方。我的原则是：

• 静态、复杂、需要精细材质的：放 Blender。比如货架的钢结构、堆垛机的机械臂、传送带的滚筒。
• 动态、简单、需要频繁改参数的：放 Three.js。比如库位的高亮方块、AGV 的路径线、告警的闪烁光圈。
• 需要大量复制的：放 Blender 做一份，Three.js 里用 InstancedMesh 复制。比如托盘，一个仓库几千个，不可能每个都单独建模。

我一开始犯的错，是把所有东西都塞进 Blender，结果导出的 glTF 有 80 多 MB，浏览器加载直接卡死。后来把托盘、库位指示器这些"标准化重复件"挪到 Three.js 里用代码生成，模型体积降到 12 MB，加载时间从 15 秒降到 2 秒出头。

2.3 数据层怎么和模型"对上号"

数字孪生最核心的一步，是让每个模型节点都有一个"身份证"。我的做法是：在 Blender 里给每个需要绑数据的对象命名，命名规则是类型_区域_编号，比如shelf_A_001、agv_01、conveyor_B_03。导出 glTF 后，Three.js 加载时通过getObjectByName就能精确找到对应节点。

然后在数据层，WebSocket 推过来的每条消息都带一个targetId，前端拿到消息后，用targetId去场景里找对应模型，更新它的材质、位置或可见性。这套机制跑通之后，加一个新设备只需要：Blender 里建个模、起个规范的名字、数据层加一条映射，前端几乎不用改代码。

注意：命名规范一定要在建模阶段就定死，不要等到前端加载时再改。Blender 里改名字很轻松，但 glTF 导出后节点名会带上层级路径，改起来很麻烦。

3. Blender MCP 打通建模到前端的完整链路

3.1 Blender MCP 到底解决了什么问题

传统流程是这样的：Blender 建模 → 手动导出 glTF → 手动复制到前端 public 目录 → 手动改代码引用路径。这个流程在模型少的时候还行，一旦模型多了、要改版了，就是灾难。

Blender MCP 把这个流程自动化了。它的核心能力是：让外部程序能够以标准协议调用 Blender 的操作。具体到我的项目里，Antigravity 作为调度层，通过 MCP 向 Blender 发送指令，比如"导出 shelf_A 这个集合为 glTF"、"把材质贴图路径改成相对路径"、"生成 LOD 层级"。Blender 执行完，把结果回传给 Antigravity，Antigravity 再把资产放到前端工程的指定位置。

这里有个关键点：MCP 不是万能的，它不能替你建模。它解决的是"模型做好之后，怎么高效地流转到前端"这个问题。所以建模本身还是要在 Blender 里老老实实做，MCP 只是把后面的搬运工作自动化了。

3.2 环境准备里最容易忽略的三个细节

第一个细节：Blender 的版本要和 MCP 插件匹配。我一开始用 Blender 4.0，插件报了一堆兼容错误，换成 4.2 LTS 之后才稳定。LTS 版本的好处是 API 稳定，不会因为小版本更新导致插件失效。

第二个细节：glTF 导出要关掉"应用修改器"以外的多余选项。Blender 默认导出会带上相机、灯光、空物体，这些在 Three.js 里要么用不上，要么会干扰场景。我的导出配置是：只导出选中集合、关闭相机和灯光、开启 Draco 压缩、贴图用 WebP 格式。

第三个细节：坐标系要统一。Blender 是 Z 轴向上，Three.js 是 Y 轴向上。导出 glTF 时 Blender 会自动转换，但如果你在 Blender 里用了自定义的旋转，转换后可能会歪。我的做法是：建模时就让模型"躺平"在 XY 平面上，Z 轴朝上，导出后 Three.js 里再统一旋转一次。

# Blender 命令行导出 glTF 的示例（MCP 底层也是调这个） blender --background warehouse.blend \ --python-expr "import bpy; bpy.ops.export_scene.gltf( filepath='/output/warehouse.glb', export_format='GLB', use_selection=True, export_cameras=False, export_lights=False, export_draco_mesh_compression_enable=True )"

3.3 从 Blender 到 Three.js 的资产管线设计

我的资产管线分三步：

1. Blender 端：按区域分集合（货架区、分拣区、AGV 区），每个集合单独导出成一个 glb。这样做的好处是前端可以按需加载，不用一次性把整个仓库都拉下来。
2. Antigravity 端：接收 Blender 导出的 glb，做一次校验（检查节点命名、材质数量、三角面数），然后按规则重命名、压缩、放到前端工程的public/models目录。
3. Three.js 端：用 GLTFLoader 按区域加载，加载完成后遍历节点，建立"节点名 → 数据绑定"的映射表。

这套管线跑通之后，改一个货架模型，只需要在 Blender 里改完、触发一次 MCP 导出，前端刷新就能看到新模型，中间不需要任何手动操作。这是我做这个项目最大的效率提升点。

提示：glb 文件建议控制在单个 5 MB 以内。超过这个体积，移动端加载会明显卡顿。如果模型太大，优先考虑减面、合并材质、用 Draco 压缩。

4. Vue 3 + Three.js 场景搭建的实操细节

4.1 场景初始化：别一上来就堆功能

很多人写 Three.js 场景，习惯一上来就把相机、灯光、控制器、后处理全加上，结果代码乱成一团。我的做法是分阶段：

第一阶段，只做"能看见模型"。初始化 Scene、PerspectiveCamera、WebGLRenderer，加载一个 glb，确认模型能正常显示、比例正确。这一步不做任何交互。

第二阶段，加 OrbitControls，确认能旋转、缩放、平移。这一步要调相机的near和far，仓储场景跨度大，far设小了远处的货架会被裁掉，我一般设成 2000。

第三阶段，加灯光。仓储场景我推荐"环境光 + 平行光 + 半球光"三件套。环境光给基础亮度，平行光给方向性阴影，半球光让天空和地面的过渡更自然。不要用点光源，性能开销大，而且仓储场景不需要那么精细的光照。

第四阶段，加数据绑定和交互。这一步才是数字孪生的核心。

// 场景初始化核心代码（Vue 3 + TypeScript） import * as THREE from 'three' import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader' import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls' const scene = new THREE.Scene() scene.background = new THREE.Color(0x1a1a2e) const camera = new THREE.PerspectiveCamera(45, width / height, 0.1, 2000) camera.position.set(80, 60, 80) const renderer = new THREE.WebGLRenderer({ antialias: true }) renderer.setSize(width, height) renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)) const controls = new OrbitControls(camera, renderer.domElement) controls.enableDamping = true controls.maxPolarAngle = Math.PI / 2.2

4.2 模型加载与节点映射

加载 glb 之后，最关键的一步是建立节点映射。我的做法是遍历场景图，把所有命名符合规范的节点存进一个 Map：

const nodeMap = new Map<string, THREE.Object3D>() loader.load('/models/shelf_area.glb', (gltf) => { gltf.scene.traverse((child) => { if (child.name && /^(shelf|agv|conveyor)_/.test(child.name)) { nodeMap.set(child.name, child) } }) scene.add(gltf.scene) })

有了这个 Map，数据层推过来一条{ targetId: 'shelf_A_001', status: 'full' }，我就能直接nodeMap.get('shelf_A_001')拿到模型，改它的材质颜色。这套机制简单但极其有效，我整个项目的数据绑定都靠它。

4.3 库位高亮与告警闪烁的实现

库位高亮是数字孪生里最常用的交互。我的实现方式是：在 Three.js 里为每个库位生成一个半透明的方块，叠在货架对应位置。默认不可见，鼠标悬停或数据触发时显示。

告警闪烁用sin函数控制透明度：

function animateAlarm(mesh: THREE.Mesh, time: number) { const material = mesh.material as THREE.MeshBasicMaterial material.opacity = 0.3 + Math.abs(Math.sin(time * 3)) * 0.7 }

这里有个性能坑：如果每个告警方块都单独跑一个动画循环，几百个方块会把 CPU 吃满。我的做法是统一在一个requestAnimationFrame里遍历所有告警方块，批量更新。实测下来，500 个告警方块同时闪烁，帧率还能保持在 55 以上。

4.4 AGV 路径动画与实时位置同步

AGV 的动画分两种：一种是"演示模式"，按预设路径循环跑；一种是"实时模式"，位置由 WebSocket 推过来的坐标驱动。

演示模式用 CatmullRomCurve3 生成平滑路径，然后按时间参数取点。实时模式更简单，直接agv.position.lerp(targetPosition, 0.1)做插值，避免位置跳变。

const curve = new THREE.CatmullRomCurve3([ new THREE.Vector3(0, 0, 0), new THREE.Vector3(20, 0, 0), new THREE.Vector3(20, 0, 30), new THREE.Vector3(0, 0, 30), ]) // 演示模式 const point = curve.getPointAt((time * 0.05) % 1) agv.position.copy(point) // 实时模式 agv.position.lerp(new THREE.Vector3(data.x, 0, data.z), 0.1)

注意：实时模式下不要直接position.copy，否则 AGV 会瞬移，看起来像"闪现"。用lerp做插值，视觉上会平滑很多。

5. 踩过的坑与排查链路实录

5.1 模型加载后"消失"了：相机 near/far 的锅

第一次加载仓库模型，场景一片漆黑，我以为模型没加载成功。排查过程：

1. 打印gltf.scene.children.length，发现节点数量正常，模型确实加载了。
2. 打印模型包围盒new THREE.Box3().setFromObject(gltf.scene)，发现尺寸是 200x50x150，比我预想的大得多。
3. 检查相机far值，设的是 1000，理论上够用。但相机位置在 (80, 60, 80)，距离模型中心太近，模型大部分在视锥体外。
4. 调整相机位置到 (200, 150, 200)，模型出现了。

根因是：Blender 里建模时用的单位是米，但导出时没注意缩放，模型实际尺寸是设计尺寸的 10 倍。解决方案是在 Blender 导出时统一缩放，或者在 Three.js 加载后gltf.scene.scale.set(0.1, 0.1, 0.1)。

5.2 材质全黑：贴图路径丢失

模型加载出来是纯黑的，没有材质。排查：

1. 检查 glb 文件，用 glTF 查看器打开，材质正常。
2. 检查 Three.js 控制台，发现一堆 404，贴图路径是绝对路径C:/Users/.../texture.png。
3. 根因是 Blender 导出时贴图用了绝对路径，glb 里记录的是本地路径，浏览器加载不到。

解决方案：Blender 导出前，把所有贴图改成"打包进 glb"（File > External Data > Pack Resources），这样贴图会内嵌到 glb 里，不依赖外部路径。

5.3 帧率骤降：Draw Call 太多

场景跑起来只有 20 帧，卡得没法看。用renderer.info一看，Draw Call 有 3000 多。排查：

1. 货架上的每个托盘都是独立 Mesh，一个货架 50 个托盘，10 个货架就是 500 个。
2. 每个托盘材质不同（颜色区分状态），无法合并。

解决方案：用 InstancedMesh。把所有托盘合并成一个 InstancedMesh，用实例颜色区分状态。Draw Call 从 3000 降到 200，帧率回到 60。

const托盘Geometry = new THREE.BoxGeometry(1, 0.2, 1) const托盘Material = new THREE.MeshStandardMaterial() const instancedMesh = new THREE.InstancedMesh(托盘Geometry, 托盘Material, 500) // 设置每个实例的位置和颜色 const matrix = new THREE.Matrix4() const color = new THREE.Color() for (let i = 0; i < 500; i++) { matrix.setPosition(positions[i]) instancedMesh.setMatrixAt(i, matrix) instancedMesh.setColorAt(i, color.set(statusColors[i])) }

5.4 内存泄漏：切换页面后场景没销毁

Vue 3 的组件销毁时，Three.js 的资源不会自动释放。我一开始没注意，来回切换几次页面，内存直接飙到 2 GB。解决方案是在onUnmounted里手动清理：

onUnmounted(() => { scene.traverse((obj) => { if (obj instanceof THREE.Mesh) { obj.geometry.dispose() if (Array.isArray(obj.material)) { obj.material.forEach((m) => m.dispose()) } else { obj.material.dispose() } } }) renderer.dispose() controls.dispose() })

这个坑很隐蔽，因为开发时不容易发现，上线后用户切几次页面就崩了。

6. 数据绑定与实时同步的工程化做法

6.1 WebSocket 消息格式设计

数字孪生的数据层，消息格式设计得好不好，直接决定前端代码乱不乱。我的格式是这样的：

{ "type": "device_status", "targetId": "agv_01", "timestamp": 1735000000000, "payload": { "status": "running", "position": { "x": 12.5, "z": 30.2 }, "battery": 78 } }

关键字段是type和targetId。type决定前端用哪个处理器，targetId决定更新哪个模型。这样前端只需要一个统一的消息分发器，不用为每种设备写一套逻辑。

6.2 Pinia 状态管理与 Three.js 的桥接

Vue 3 用 Pinia 管理状态，但 Three.js 的场景对象不在 Pinia 里。我的做法是：Pinia 只存"数据"，Three.js 场景对象存在一个独立的sceneRegistry里，两者通过targetId关联。

// Pinia store export const useWarehouseStore = defineStore('warehouse', { state: () => ({ devices: new Map<string, DeviceData>(), }), actions: { updateDevice(targetId: string, data: Partial<DeviceData>) { const existing = this.devices.get(targetId) || {} this.devices.set(targetId, { ...existing, ...data }) }, }, }) // 桥接层：监听 store 变化，更新 Three.js 场景 store.$subscribe((mutation, state) => { state.devices.forEach((data, targetId) => { const obj = sceneRegistry.get(targetId) if (obj) updateObjectVisual(obj, data) }) })

这样分层的好处是：数据逻辑和渲染逻辑解耦，测试时可以直接 mock store，不用启动 Three.js。

6.3 高频数据的节流与批处理

AGV 位置数据一秒推 10 次，如果每次都触发渲染，性能扛不住。我的做法是：WebSocket 消息进来后先存进一个缓冲区，在requestAnimationFrame里统一处理。

const buffer: DeviceMessage[] = [] ws.onmessage = (event) => { buffer.push(JSON.parse(event.data)) } function renderLoop() { // 批量处理缓冲区 while (buffer.length > 0) { const msg = buffer.shift()! handleMessage(msg) } renderer.render(scene, camera) requestAnimationFrame(renderLoop) }

这样无论数据推多快，渲染频率始终和屏幕刷新率一致，不会因为数据量大而卡顿。

7. 一些让场景"更像真的"的细节技巧

7.1 地面反射与阴影

仓储场景的地面如果是纯色，会显得很假。我加了一个简单的反射效果：用MeshStandardMaterial设置roughness: 0.3、metalness: 0.1，再配一个环境贴图，地面就会有轻微的反光。阴影用平行光的castShadow，配合PCFSoftShadowMap，边缘会柔和很多。

7.2 雾效营造纵深感

热词里有"three.js雨雪雾怎么实现"，雾效在仓储场景里特别有用。仓库跨度大，远处的货架如果清晰可见，会显得场景很小。加一层雾：

scene.fog = new THREE.Fog(0x1a1a2e, 100, 500)

近处清晰，远处渐隐，纵深感立刻就出来了。注意雾的颜色要和背景色一致，否则会有明显的"边界"。

7.3 相机动画与视角切换

数字孪生场景通常需要几个预设视角：全景、货架区、分拣区、AGV 通道。我用 GSAP 做相机过渡：

gsap.to(camera.position, { x: targetPos.x, y: targetPos.y, z: targetPos.z, duration: 1.5, ease: 'power2.inOut', onUpdate: () => camera.lookAt(targetLookAt), })

比直接camera.position.copy体验好太多，切换视角时有一种"飞过去"的感觉。

7.4 性能监控与自适应降级

上线前我加了一个简单的性能监控：每秒统计一次帧率，如果连续 3 秒低于 30 帧，就自动关闭阴影和雾效，降低pixelRatio。这套降级机制让场景在低端设备上也能跑起来，虽然画质差一点，但至少不卡。

let frameCount = 0 let lastTime = performance.now() function checkPerformance() { frameCount++ const now = performance.now() if (now - lastTime >= 1000) { const fps = frameCount frameCount = 0 lastTime = now if (fps < 30) degradeQuality() } }

8. 关于 Antigravity 在整条链路里的角色定位

回到标题里的 Antigravity。在这个项目里，它不是建模工具，也不是渲染引擎，而是"流程调度者"。具体来说，它做了三件事：

第一，管理模型资产的版本。每次 Blender 导出新模型，Antigravity 会记录版本号、导出时间、三角面数、文件大小，方便回溯。有一次我改货架模型改坏了，直接回滚到上一个版本，省了半小时重做。

第二，协调 MCP 调用。Blender MCP 的调用不是随便触发的，需要按顺序：先检查 Blender 是否运行、再检查当前打开的文件是否正确、然后执行导出、最后校验导出结果。Antigravity 把这些步骤串起来，我只需要点一个按钮。

第三，驱动前端资产更新。模型导出后，Antigravity 会对比新旧文件的 hash，如果变了就通知前端重新加载。开发阶段这个功能特别省事，改完模型不用手动刷新，前端自动热更新。

这套流程跑顺之后，我的工作流变成了：Blender 里改模型 → 点一下"同步" → 前端自动更新。中间不需要导出、复制、改路径这些琐碎操作。这是我做这个项目最大的效率提升，也是我推荐用 MCP 而不是手动导出的核心原因。

提示：Antigravity 这类调度工具的价值，在项目初期不明显，但一旦模型数量超过 20 个、改版超过 5 次，它的价值就体现出来了。建议从项目一开始就搭好这套流程，不要等到后期再补。

9. 后续可以继续深挖的方向

这个项目目前跑通了"建模—导出—加载—数据绑定"的主链路，但还有几个方向值得继续做：

一是LOD（多细节层次）。现在所有模型都是全精度加载，远处的小货架其实不需要那么精细。下一步我打算在 Blender 里生成 2-3 个精度层级，Three.js 里根据相机距离动态切换。

二是路径规划可视化。现在 AGV 路径是预设的，下一步想接入真实的路径规划算法，把规划结果实时渲染成 3D 路径线。

三是历史回放。把设备状态数据存到时序数据库，支持按时间轴回放，这对故障排查和运营分析很有价值。

四是移动端适配。现在场景是给大屏做的，移动端操作体验一般。下一步要针对触屏优化相机控制和交互方式。

这些方向我还在陆续做，等跑通了再单独写一篇。数字孪生这个领域，模型只是起点，数据才是深水区，越往后做越觉得有意思。