企业官网建设流程全解析

上个月在推进一个设备管理数字化项目时，车间设备科长指着电脑屏幕问我：“设计那边有三维模型，我们能不能直接装个CAD软件来看？”我回答得很干脆：不建议装。后来我们做成了一套跑在浏览器里的工业三维模型展示平台，配合AI做了自动轻量化、语义检索和问答式交互。这个选择背后，其实是一笔很实在的账：大多数需要看三维模型的人，根本不需要设计软件的功能，他们只需要一个稳定、快速、能查、能看的窗口。这篇文章就把我这次选型、搭建和落地的完整过程拆开讲一遍，包括为什么坚持网页端、技术底座怎么搭、AI到底在哪几个环节真正起了作用，以及踩过的坑。

1. 需求还原：工业三维展示真正要解决的是什么

1.1 先分清“做模型的人”和“看模型的人”

工业三维模型在大多数企业里的现状是：设计部门用专业CAD软件建模，模型躺在设计师的电脑里或PLM/PDM系统里。但真正高频需要看模型的，往往是车间装配工、售后工程师、客户、采购、甚至投标方案讲解人员。这些人没有兴趣也没有必要学会操作一套完整的三维CAD软件，他们要的只是“把这个设备转起来看结构、点一下查某个零件、剖开来看看内部”。

这就是需求还原的第一步：把用户分成“生产者”和“消费者”。设计部门是模型生产者，他们需要完整的建模、装配、出图能力；其余角色是模型消费者，他们需要的是低成本、低门槛的查看、检索和沟通能力。让每个消费者都装一套CAD软件，本质上是用高射炮打蚊子。

我这次遇到的项目就是典型：某装备制造企业有一台大型压机的完整三维模型，设计部只有少数几人能熟练打开原始装配文件，而车间、售后、培训三个部门都在追问“能不能让我们也看看模型”。当时的第一反应确实是“再装一套CAD”，但认真算完账之后，我否掉了这个方案。

1.2 网页端要解决的三个核心诉求

在需求调研阶段，我们把所有“看模型”的需求收敛成了三类：看、查、用。

“看”指的是直观查看：总装结构、部件位置、爆炸顺序、剖切内部。车间装配工看装配顺序，售后工程师看拆解路径，客户看整体外观，本质上都是“看”。

“查”指的是精准定位：输入零件号定位到模型树的某个节点，在总装图上高亮显示；点击某个部件，弹出物料编码、材质、供应商等信息。这个动作在CAD软件里需要会操作设计树和属性面板，而网页端通过搜索框和点击交互就能完成。

“用”指的是把模型嵌入业务动作：现场维修时对照模型拆装、培训时用三维爆炸图讲解原理、投标时用网页链接演示产品。这些场景不是在“设计”，而是在“消费模型”。

这三个诉求都不要求用户掌握建模能力，却都对加载速度、操作流畅度、信息可得性提出了要求。网页端的优势恰恰在于：不用安装、随时打开、权限可控、可以和现有业务系统无缝衔接。

1.3 明确边界：我们做的是“数字化样机消费端”，不是新设计系统

强调一个容易犯的认知错误：网页端三维展示平台不是用来替代CAD设计的，它是设计数据的“衍生消费端”。

设计源头仍在专业CAD软件里，模型更新从PLM/PDM系统同步过来，网页端做的是轻量化转换、结构化处理和交互展示。这样做的最大好处是职责清晰：设计部门继续管源头数据，数字化转型或IT部门管展示平台，业务部门只管用。边界清晰了，才不会出现“网页端能不能改模型”“能不能另存为工程图”这类需求蔓延。

这个边界也决定了技术选型的方向：不需要完整CAD内核，不需要高精度布尔运算，需要的是高效渲染、流畅交互、稳定加载和与业务系统的集成能力。所以从一开始，网页端就是对的答案。

2. 为什么不装一套CAD：本地展示方案的六笔隐形账

2.1 许可、硬件、培训：看得见的成本

CAD软件的授权模式通常是按席位买的，价格不便宜，且往往有期限。给车间放一台CAD终端，意味着设计部门多占一个授权名额，两拨人互相抢许可，最后谁都别扭。这是第一笔账。

第二笔账是硬件。大型装配体在CAD软件里打开，对显卡、内存、CPU的要求不低。我见过不少企业的办公电脑还是集成显卡，强行打开几百兆的装配体，转一下视角要等十几秒，风扇狂转，最后用户干脆放弃使用。要让它流畅，就得配图形工作站，一台的成本足够搭起整套网页端方案的基础设施。

第三笔账是培训。三维CAD软件界面复杂，菜单层级深，非设计人员学习成本很高。车间工人没有时间和耐心去记“草图”“约束”“特征树”这些概念，他们试两分钟觉得难，就不会再打开第二次。

三笔加起来，方案还没落地，钱已经花出去一大截。

2.2 版本、协作与更新：看不见的成本

比上面三笔更能劝退我的，是版本和协作问题。

设计部门的模型文件通常有多个软件版本，一个用旧版本软件的设计师存出的文件，新版本软件不一定兼容，反过来也一样。让车间、售后每人装一套版本对得上的CAD软件，是运维噩梦。更麻烦的是模型更新：设计改了一版，车间电脑里的旧文件怎么办？远程一台台去替换？基本做不到。最后的结果必然是：各人电脑里的模型版本不一致，现场维护时拿错了结构图，出了事都不知道责任在哪。

还有数据安全问题。把原始三维设计文件直接放到车间和售后终端上，等于把企业的核心设计资产暴露在大量非受控终端上。源文件包含完整建模特征和参数，一旦外泄，损失无法估量。而网页端展示用的轻量化模型是经过转换和剥离的，不包含原始建模特征树，风险等级完全不同。

2.3 一张表看清三种查看方式

这张表做完之后，答案已经很明显：安装本地CAD的方案，在每个维度上都没有优势。剩下的问题不是“要不要网页端”，而是“网页端具体怎么实现”。

3. 网页端三维展示的工程底座：从CAD源文件到浏览器里的轻量化模型

3.1 第一件事：把原始CAD格式换成glTF/glb

网页端不能直接打开CAD原生格式，必须做格式转换。我们最终把统一目标格式定为glTF（及其二进制形式glb），原因有三个：

一是glTF是开源的开放标准，对PBR材质、动画、多级LOD都有原生支持，在Web渲染引擎里兼容性最好。二是glb是二进制封装，文件体积比OBJ、STL等传统格式小得多。三是three.js对glTF/glb的加载支持非常成熟，生态完善，后续做交互、标注、测量都有现成方案。

相比之下，OBJ虽然通用，但不支持材质层级和模型树结构；STL只有三角面片，连颜色都没有，直接放弃；FBX功能强但格式封闭，在浏览器里解析支持弱，且授权链路不清晰。表格对比更直观：

实际推行中，建议用glb作为所有展示模型的统一格式。glTF和glb内容等价，但glb二进制体积更小、加载更快，绝大多数场景直接用glb就够了。

3.2 转换管线里必须盯住的两个参数：单位和坐标系

格式转换不是简单“另存为”，最容易出问题的有两点，第一是单位，第二是坐标系。

CAD软件里不同项目、不同设计者可能使用毫米、厘米甚至英寸建模。转换到glb时如果单位换算错误，整个模型会缩小或者放大成完全不可用的尺寸。我们第一次测试时就遇到整台压机模型缩小到原来的四十分之一，在浏览器里小得像玩具。排查后发现是转换工具默认按米处理，而源文件是毫米。

解决办法是在转换服务里强制指定输入单位和输出单位，不能依赖转换工具的自动识别。虽然glTF标准内部以米为单位，但转换时显式声明“源数据为毫米，导出时按1:0.001换算”，就可以稳定复现。

第二个坑是坐标系。CAD软件普遍使用Y轴向上或Z轴向上，而Web渲染里glTF规定Y轴向上。如果坐标系不转换，模型进入浏览器后整个装配体的朝向就是错的，看起来像被“放倒”了。处理方式是在转换环节统一做一次轴系变换，把Z轴向上转为Y轴向上，坐标系变换必须在服务端完成，不要指望前端去转。

3.3 前端渲染：为什么是Three.js加WebGL

前端渲染引擎我们选了three.js，没有选更新的WebGPU方案。原因不是WebGPU不好，而是兼容性和稳定性的问题。

工业现场有大量老旧浏览器和低配电脑，WebGL2的覆盖率已经足够高，而WebGPU虽然性能上限更强，但目前仍需要较新版本的浏览器支持。对于工厂这类“不折腾”的生产环境，稳定性优先于酷炫。three.js的上限对我们够用，渲染大型装配体、剖切、爆炸视图、热点标注都能做，社区案例多，出了问题也容易查。

核心渲染代码非常简洁，下面是加载一个glb模型并加上轨道控制器的基本骨架：

import * as THREE from 'three'; import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'; import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js'; const scene = new THREE.Scene(); const camera = new THREE.PerspectiveCamera(45, window.innerWidth / window.innerHeight, 0.1, 1000); const renderer = new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); document.body.appendChild(renderer.domElement); const loader = new GLTFLoader(); loader.load('/models/press-machine.glb', (gltf) => { scene.add(gltf.scene); // 自动聚焦到模型包围盒中心 const box = new THREE.Box3().setFromObject(gltf.scene); const center = box.getCenter(new THREE.Vector3()); camera.lookAt(center); }); scene.add(new THREE.AmbientLight(0xffffff, 0.6)); const dirLight = new THREE.DirectionalLight(0xffffff, 0.8); dirLight.position.set(10, 20, 10); scene.add(dirLight); const controls = new OrbitControls(camera, renderer.domElement); controls.enableDamping = true; function animate() { requestAnimationFrame(animate); controls.update(); renderer.render(scene, camera); } animate();

实际项目中还要加环境贴图、阴影、剖切面、热点标记等功能，但核心思路就是这样的。工程上的复杂度不在于three.js本身，而在于模型文件怎么准备好、怎么加载得快。

3.4 大模型加载三板斧：压缩、LOD、按需加载

工业设备模型动辄一个装配体几百万甚至上千万三角面片，直接加载必卡，需要三招配合。

第一招是几何压缩。glTF标准支持Draco压缩，对网格几何数据的压缩率非常可观。用开源的gltfpack工具或者转换服务内置的Draco编码器，可以把几何体体积压缩到原来的三分之一甚至更低，代价是加载时需要解压时间，但整体收益远大于损耗。

第二招是LOD，即多级细节层次。同一模型准备粗、中、细三个精度版本，视角远的时候显示粗糙版本，靠近时再切换精细版本。对于大型设备，LOD能显著降低实时渲染的三角面片数量，帧率提升非常明显。gltfpack也支持自动生成LOD链条，不需要手动做三份模型。

第三招是按需加载。不一次加载整个总装模型，而是先加载总装外壳，当用户点击某个子系统时再动态加载该子系统的精模。实现上可以按装配树拆分为多个glb文件，前端维护一个加载队列，用懒加载策略控制请求顺序。这一招对超大装配体尤其有效，首屏加载时间可以缩短一个数量级。

4. AI在这套架构里到底干了什么：不是噱头，是三个能落地的场景

4.1 自动轻量化：不是简单减面，要保住关键特征

模型轻量化是网页端展示的第一步，也是AI发挥价值最大的一步。传统减面算法一刀切，容易把螺栓孔、圆角、安装法兰等小特征抹平，模型变得“失真”。我们接入AI辅助的自适应简化后，算法会先分析局部曲率和法向变化，识别出特征密集区和平面区，在平面区大幅度减面，在特征密集区保留更多三角面片。

举一个实测数据：一台大型压机的装配体，原始模型导出后三角面片总数约2880万，用自适应简化压到860万，整体视觉检查几乎看不出差别，但文件体积下降了约70%。如果换成无脑减面，到1200万时就出现了明显棱角和细节丢失。这说明AI在这一步不是花架子，而是让“轻量化”和“保真度”这对矛盾同时成立的关键。

需要提醒的是，无论AI怎么简化，轻量化模型都不应用于精密测量和CAE仿真分析。它有几何展示和空间认知价值，但不代表原始设计精度。我们会在平台上注明“展示模型，非设计依据”，避免误导。

4.2 自然语言找部件：语义检索怎么落地的

以前查零件的方式是：在模型树里一层层展开，靠人眼找编号。面对一个包含上千个子系统的总装图，这是体力活。我们在网页端接入语义检索后，用户可以直接输入“3号泵的进油口”“左侧安全阀”“液压站主阀块”这类自然语言描述，系统会返回最匹配的构件并在三维场景中高亮显示。

实现原理不复杂：先把装配树节点、部件名称、物料描述、技术参数做成结构化的元数据库，再给这些文本建向量索引。用户搜索时，自然语言查询被向量化，与元数据库做相似度匹配，返回top-k结果。这一步的价值在于：把“关注三维形态”和“关注文字信息”打通了，哪怕记不住准确零件号，也能靠习惯说法的描述找到模型。

实测中，语义检索的准确率大约在85%左右，剩下的靠“相近零件同时高亮，用户二次点选”补足。没有做成完全黑盒的智能，而是把AI结果和人工确认结合起来，这样既高效又可靠。

4.3 圈一个部件，问它的故障和备件：问答式助手

第二个AI落地点是问答式助手。我们把设备维修手册、常见故障记录、BOM物料清单整理成知识库，接入检索增强生成，做成了一个“在三维场景里圈选部件就能问问题”的入口。

维修人员选中某个部件，右下角弹出对话窗口，可以问：“这个阀的常见故障有哪些？”“密封圈型号是多少？”“更换需要哪些工具？”系统基于知识库内容回答，并标注信息来源章节。过去这些信息分散在几百页的PDF和Excel表格里，现在直接以部件为锚点组织起来，现场操作效率提升明显。

这里必须强调一个底线：AI回答的内容必须限定在已收录的知识库范围内，不能自由发挥。我们的做法是所有回答在界面上标注“参考文档来源”，对于知识库中没有覆盖的问题，明确回答“暂未收录”，而不是试图编造一个答案。设备维修不是闲聊，错误答案会造成现场事故，这个边界不能妥协。

4.4 自动标注热点：把装配树变成可点击的导览

第三个落地点是自动生成三维热点标注。以前在三维模型上做热点，需要人工记住每个部件的空间位置，逐个点击设定标注点，一个总装图几十个热点能折腾大半天。现在AI根据装配树的层级和部件包围盒，自动计算每个子部件的视觉中心坐标，批量生成热点候选，人工只需要在界面上确认和调整标签文案，十分钟就能完成原先数小时的工作。

这套机制还被用到了爆炸图导览上。AI根据装配关系自动生成爆炸顺序的初始猜测，人工修正后保存为动画，新员工培训时直接播放，比自己对着二维图纸想象拆卸步骤直观太多。这个功能上线后，培训部门的反馈是最好的，以往新员工理解一台设备结构要两三天，现在跟三维爆炸图走一遍，加上问答助手随时查，基本半天就能建立起空间认知。

5. 落地过程中最容易被绊倒的几个地方：实测与复盘

5.1 单位、坐标系、破面：转换阶段的三座山

第一座山是单位，前面已经详细讲过，再补充一个教训：不要相信“一键转换”工具自动识别单位。不同工具对STEP/IGES文件的单位处理逻辑不一致，有的默认读取文件内单位，有的默认毫米，有的默认英寸。最稳妥的做法是在转换服务的配置文件里固定单位策略，每次转换前自动检测，检测不了就显式指定。我们为此写了一个单位检测模块，根据模型的包围盒尺寸和历史数据对比，异常时直接报警。

第二座山是坐标系。解决方法是服务端做坐标轴重映射，在导出glb前置节点做旋转变换，保证进入前端的模型Z轴向上结构正确。如果这一步遗漏，在浏览器里看到“躺倒”的模型，所有交互都会错位。

第三座山是破面。大装配体转换时经常出现个别面片法线翻转、部分曲面缺失，后来定位主要是原始CAD数据里存在修复瑕疵的几何体。我们的处理方式是准备一套自动几何修复流程：检查非流形边、统一法线方向、删除零面积面片，再进入导出环节。这个流程对STEP来源的数据尤其重要，能减少九成以上的显示异常。

5.2 首屏性能：从1.2GB到80MB的实测路径

我们第一次把完整压机模型转成glb时，文件体积是1.2GB，直接扔给前端，浏览器加载到一半就崩溃了。后来逐步优化，路径很清楚：

第一步，按装配树拆分。整机拆成顶梁、底座、液压系统、电气柜四个子装配，每个子装配单独导出glb。第二步，每个子装配做Draco压缩，体积下降约60%。第三步，生成LOD粗模，首屏只加载粗模和当前视点的子装配精模。第四步，纹理压缩，把8K大纹理统一缩到2K，关闭不必要的发光贴图。

走完这四步，首屏实际加载量降到80MB左右，在办公网络环境下进入可交互状态大约8秒，后续子装配按需加载，基本无感知。如果一开始就按这个方案设计，能少走很多弯路。我的经验是：性能目标是上线前就要定的，不能等模型污染了再做清理。

5.3 浏览器和终端设备：兼容性是最容易被忽视的

开发阶段我们都在开发机上跑，Chrome最新版，独立显卡，流畅得毫无感觉。一部署到车间就露馅了：部分办公电脑上的浏览器版本较旧，WebGL2支持不稳定；还有一批平板设备，GPU性能有限，大模型转起来掉帧严重。

解决方案分三层：第一层在检测到WebGL2不可用时自动降级到WebGL1渲染路径；第二层限制最大纹理尺寸，关闭抗锯齿和后期特效，换取低端设备的基础可用性；第三层增加“性能模式”手动开关，低端设备默认开启简化渲染。这些都是纯前端工作，但必须在项目计划里预留时间。我建议在部署前，把目标用户的真实终端清单收集一遍，在上面逐台跑测试页，再谈上线。

5.4 常见问题对照表

6. 从试验到生产：部署架构与数据安全的边界

6.1 部署架构：转换服务、静态资源、对象存储分离

网页端展示平台从开发到生产，部署架构必须分成三块：转换服务、静态资源服务和对象存储。

转换服务运行在服务器端，监听PLM/PDM系统的模型发布事件。每当设计部门发布新版模型，转换服务自动拉取原始文件，执行单位检测、几何修复、格式转换、压缩优化，最后输出glb并写入对象存储。转换是异步任务，用消息队列串起来，避免大模型转换时阻塞其他服务。

静态资源服务负责承载前端页面和按需加载的glb文件，采用Nginx或同类Web服务器，开启gzip和缓存。对象存储负责存放所有版本模型文件，设计成按版本号管理，方便回滚和历史追溯。三块分离的好处是：转换出问题不影响线上访问，模型文件可以弹性扩容，静态资源可以做CDN或者内网加速。

6.2 权限分级与数据防泄露

工业三维模型属于企业核心数据，权限模型必须清晰。我们按角色分了三级：访客只能看外观和基本信息，无法测量和剖切；工程师可以查看结构树、属性、进行测量和剖切；管理员可以管理模型版本和标注内容。

防泄露方面，网页端天然比本地CAD文件安全得多，但还有几个细节值得做。第一，模型文件路径不应该暴露原始地址，访问时必须通过带签名的临时链接。第二，对glb文件内容做混淆或加密，配合前端解钥脚本读取，增加下载后直接使用的门槛。第三，动态水印：在渲染画面固定位置显示当前登录用户名，截图外传时能追溯到人。第四，流式按需加载，避免一次性把完整模型数据推给终端，从技术上减少整包被抓包的可能。

这套组合下来，车间用户能看到模型、能正常工作，但拿不到源文件，也拿不到路径，数据安全边界是可控的。

6.3 和现有系统的集成：从“模型仓库”变成“业务入口”

网页端展示平台如果只做一个独立网站，价值会大打折扣。真正让它好用的是集成：和设备台账系统打通，点击设备编号直接跳转到三维视图；和工单系统打通，维修工单关联的部件自动在模型里高亮；和培训系统打通，课程页面嵌入三维讲解链接。

我们在实施时给每个模型构件定义了一套统一编码，和企业的物料编码体系对应。这样不管是ERP、工单还是档案系统，只要能传递编码，就能在三维平台里定位到具体构件。不要试图让业务系统都“看懂”三维模型，只要让它们“指向”模型就够了。这个思路大幅降低了集成难度。

6.4 实施后的实测收益

最后分享一组我们上线前后的对比数据。以前车间要看一个部件结构，先找设计要截图，来回沟通平均耗时约半天；现在直接在工位电脑打开浏览器，搜索部件名，三维高亮显示，整个过程不超过2分钟。以前新员工培训讲设备结构，用二维图纸加口头描述，通常需要两到三次现场拆装才能建立完整认知；现在配合三维爆炸图和问答助手，半天就能过一遍。以前售后在外面干活，遇到结构问题只能打电话回去问设计；现在带着平板，打开网页端就能查结构和备件信息。

这些收益不是靠某一个功能实现的，而是“网页端+AI+系统集成”组合出来的整体效果。单独的轻量化模型只是一个好看的模型，加上检索、问答、标注和业务联动之后，它才真正变成能参与工作的工具。

如果现在有人再问我“要不要再装一套CAD”，我会说：如果只是让人看模型，别装了，把钱省下来，把模型发布到一个所有同事都能用一个浏览器打开的网页端平台上去。但我也会补一句：别把这事儿想得太复杂，先从一台设备、一个车间、一个最常见的看模型场景开始跑，跑顺了再逐步加AI功能。技术方案不是越复杂越好，而是越贴合真实工作流越好。