上个月在推进一个设备管理数字化项目时车间设备科长指着电脑屏幕问我“设计那边有三维模型我们能不能直接装个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软件安装轻量CAD看图器网页端三维展示平台安装部署按席位安装、配置复杂需安装客户端、仍需维护浏览器打开即用无需安装硬件要求高需独立显卡和大内存中等低普通办公机、平板可跑数据安全源文件落地终端风险高部分格式需转换仍有本地缓存轻量化模型权限控制隔离源头版本更新各终端文件版本难统一依赖手动同步服务器统一更新终端永远最新培训成本高界面复杂中看图操作简单极低会浏览网页就会用与业务系统集成差文件散落差好可嵌入工单、ERP、培训系统这张表做完之后答案已经很明显安装本地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功能强但格式封闭在浏览器里解析支持弱且授权链路不清晰。表格对比更直观格式保留材质保留模型树体积效率浏览器生态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 常见问题对照表现象根因解决方案模型整体缩小尺寸不对转换时单位识别错误强制指定源单位与输出单位加入自动检测模型在浏览器里躺倒CAD坐标系与glTF不一致服务端做轴系重映射前端不处理坐标变换部分曲面缺失、破面原始CAD数据存在瑕疵转换前做非流形边检查和法线修复加载到一半浏览器崩溃单文件过大、内存占用高按装配树拆分、Draco压缩、LOD分级车间老旧浏览器白屏WebGL2不支持降级到WebGL1路径限制纹理和使用特效低配平板拖动卡顿GPU性能不足增加性能模式关闭抗锯齿和后处理模型更新后旧数据仍在缓存策略不当文件命名加入版本号强制刷新静态资源6. 从试验到生产部署架构与数据安全的边界6.1 部署架构转换服务、静态资源、对象存储分离网页端展示平台从开发到生产部署架构必须分成三块转换服务、静态资源服务和对象存储。转换服务运行在服务器端监听PLM/PDM系统的模型发布事件。每当设计部门发布新版模型转换服务自动拉取原始文件执行单位检测、几何修复、格式转换、压缩优化最后输出glb并写入对象存储。转换是异步任务用消息队列串起来避免大模型转换时阻塞其他服务。静态资源服务负责承载前端页面和按需加载的glb文件采用Nginx或同类Web服务器开启gzip和缓存。对象存储负责存放所有版本模型文件设计成按版本号管理方便回滚和历史追溯。三块分离的好处是转换出问题不影响线上访问模型文件可以弹性扩容静态资源可以做CDN或者内网加速。6.2 权限分级与数据防泄露工业三维模型属于企业核心数据权限模型必须清晰。我们按角色分了三级访客只能看外观和基本信息无法测量和剖切工程师可以查看结构树、属性、进行测量和剖切管理员可以管理模型版本和标注内容。防泄露方面网页端天然比本地CAD文件安全得多但还有几个细节值得做。第一模型文件路径不应该暴露原始地址访问时必须通过带签名的临时链接。第二对glb文件内容做混淆或加密配合前端解钥脚本读取增加下载后直接使用的门槛。第三动态水印在渲染画面固定位置显示当前登录用户名截图外传时能追溯到人。第四流式按需加载避免一次性把完整模型数据推给终端从技术上减少整包被抓包的可能。这套组合下来车间用户能看到模型、能正常工作但拿不到源文件也拿不到路径数据安全边界是可控的。6.3 和现有系统的集成从“模型仓库”变成“业务入口”网页端展示平台如果只做一个独立网站价值会大打折扣。真正让它好用的是集成和设备台账系统打通点击设备编号直接跳转到三维视图和工单系统打通维修工单关联的部件自动在模型里高亮和培训系统打通课程页面嵌入三维讲解链接。我们在实施时给每个模型构件定义了一套统一编码和企业的物料编码体系对应。这样不管是ERP、工单还是档案系统只要能传递编码就能在三维平台里定位到具体构件。不要试图让业务系统都“看懂”三维模型只要让它们“指向”模型就够了。这个思路大幅降低了集成难度。6.4 实施后的实测收益最后分享一组我们上线前后的对比数据。以前车间要看一个部件结构先找设计要截图来回沟通平均耗时约半天现在直接在工位电脑打开浏览器搜索部件名三维高亮显示整个过程不超过2分钟。以前新员工培训讲设备结构用二维图纸加口头描述通常需要两到三次现场拆装才能建立完整认知现在配合三维爆炸图和问答助手半天就能过一遍。以前售后在外面干活遇到结构问题只能打电话回去问设计现在带着平板打开网页端就能查结构和备件信息。这些收益不是靠某一个功能实现的而是“网页端AI系统集成”组合出来的整体效果。单独的轻量化模型只是一个好看的模型加上检索、问答、标注和业务联动之后它才真正变成能参与工作的工具。如果现在有人再问我“要不要再装一套CAD”我会说如果只是让人看模型别装了把钱省下来把模型发布到一个所有同事都能用一个浏览器打开的网页端平台上去。但我也会补一句别把这事儿想得太复杂先从一台设备、一个车间、一个最常见的看模型场景开始跑跑顺了再逐步加AI功能。技术方案不是越复杂越好而是越贴合真实工作流越好。