1. 开篇为什么会聊起这家“幕后玩家”做CAD/CAE/PLM相关开发的朋友多半都听说过Tech Soft 3D这家公司但又未必能说出它具体做了什么。它旗下的HOOPS系列产品常年藏在大家熟悉的CAD软件后面组成了许多高端应用的图形内核和文件交互底座。你可能每天在某个三维设计工具里点开一个几十种格式的模型操作顺畅得像原生功能背后往往就是HOOPS在打底。这半年我陆续看了Tech Soft 3D在AI方向的一些公开动态尤其是近期围绕HOOPS AI展开的布局觉得这是个值得聊透的话题。CAD软件乘上AI这趟车现阶段其实鱼龙混杂。有的产品只是给命令栏加了个“智能推荐”有的把大模型塞进界面就当AI了。真正从数据底层、从三维图形引擎这个层面去思考I与CAD结合方式的公司数量并不算多。Tech Soft 3D恰好是其中最特殊一家——它不卖CAD软件却给大量CAD软件提供核心组件。所以它怎么看AI往哪个方向走推出的HOOPS AI到底解决什么问题很大程度上代表了CAD行业基础设施层面对AI的真实态度。这篇文章我想从三个层面展开先说说Tech Soft 3D在CAD生态里的实际位置和它做AI的底牌再拆解AI时代CAD开发遇到的真实需求变化最后重点梳理HOOPS AI的能力边界、落地思路和集成时避坑的经验。给正在做CAD二次开发、准备上AI能力的技术决策者和开发者一个参考。我尽量不去空谈趋势多讲一些能落地的判断。2. Tech Soft 3D在CAD生态里的“隐形基建”角色2.1 它到底解决了什么陈年难题搞过CAD数据交换的人都知道三维CAD格式的数量多到离谱。光是主流的就有几十种还有各种版本变体。CATIA、NX、Creo、SolidWorks、Inventor、Parasolid、ACIS、STEP、IGES、JT每一种的底层数据结构、精度单位、装配关系表达都不一样。A软件里一个简单的孔特征导到B软件里可能就变成不带参数的面片。这种问题是CAD领域存在了几十年的老毛病。Tech Soft 3D的HOOPS Exchange干的就是这件事把各种格式的CAD文件读进来统一转换成一套内存里的数据结构。装配树、PMI注释、几何拓扑、BOM属性都能以相对一致的形式暴露给开发商。再加上HOOPS Visualize负责高性能渲染HOOPS Communicator负责Web端三维展示HOOPS Publish负责输出PDF和HTML文档这四个组件几乎覆盖了一个CAD应用从“读文件”到“显示”“发布文档”的完整链路。很多市面上的知名软件查看器也好、完整设计工具也好底层其实是搭了一组HOOPS积木上去的。这也是把它叫做“隐形基建”的原因。它不直接面对终端设计师但终端设计师每天用的工具很可能就在调用HOOPS的代码。对做二次开发的朋友来说与其自己花两三年去啃格式解析和图形渲染不如直接租用这些成熟模块。这个商业模式不性感但极其稳当——只要全球还有人在开发新的CAD应用就需要有人持续维护格式兼容和图形性能。2.2 为什么说做AI它有天然底牌现在很多CAD厂商做AI本质上是在自家封闭的数据库和用户界面上做改进。但Tech Soft 3D不一样它处在中间层天然拥有“跨格式、跨平台”的数据视野。HOOPS Exchange每年跟着各大CAD软件升级格式版本积累了非常完整的格式兼容经验。这意味着如果要做AI数据理解和语义抽取它有现成的结构化数据管道。举一个我接触过的场景。某家做工业设备运维系统的公司平台上要接入客户发来的各种三维模型。以前的做法是收到什么格式就转换成中性格式。客户发CATIA就转STEP发SolidWorks也转STEP但转完之后装配关系、自定义属性经常丢。后来他们评估过HOOPS Exchange的方案看中的不只是格式转换能力而是转换过程中能把BOM属性、PMI、视图信息一并抽出来。有了这些结构化数据后面做AI语义检索才谈得上有数据可用。这个例子揭示了Tech Soft 3D做HOOPS AI的核心逻辑AI不是替代CAD内核而是把CAD内核里那些“人类一眼能看懂但机器很难理解”的信息变成大模型能处理的语义层。理解这一点后面再看它的产品方向就不会发懵。2.3 阻力和边界也不能忽视当然底层SDK厂商做AI方案也有自己的天花板。比如它不掌握具体CAD应用里的业务数据不像SolidWorks那样知道用户设计完零件之后还要做仿真还是出加工单。所以它的AI能力做“通用理解”比较强做“垂直业务”就要靠集成商往上叠。另外商业模式的平衡也很微妙——它服务的是开发者不是终端用户AI功能设计得太“端”反而不好卖。3. AI时代CAD开发的真实需求变化3.1 从图标点按到自然语言交互CAD软件这些年最大的交互瓶颈是什么我用自己用软件的体感来说是菜单层级太深。一个功能你可能知道存在但就是找不到入口。刚入行的工程师尤其明显很多命令藏在二级三级菜单里效率被严重拖累。AI时代大家最期待的一件事就是能不能对着软件说一句人话它自己去找到那个功能、完成那个操作。自然语言交互在CAD里比在办公软件里难不只一个量级。因为工程设计语言充满歧义。你说“把这个孔移到那边”“这个孔”是哪个孔“那边”是哪个面、哪个坐标如果系统没有结合三维场景的语义理解能力这句话就无从执行。这也是HOOPS AI这类方案瞄准的切入点——它擅长把三维场景里的对象、属性、约束转化成语境让模型理解的是“当前屏幕里这个零件”而不是“一段普通的自然语言”。3.2 数据检索与知识管理成为刚需很多企业攒了几十年的CAD图纸和三维模型散落在不同的产品数据管理系统里。以前找东西靠文件名、编号、分类目录。但文件名经常不规范分类目录也更新不及时。AI能力的介入让“用语义找模型”成为可能。你可以问“之前那个带散热筋的铝合金外壳还有吗”系统通过语义解析把“散热筋”“铝合金”“外壳”几个概念映射到模型属性和几何特征上再通过向量检索把最接近的几个模型排出来。这块需求在制造业里不是伪需求。我们接触过不少中大型制造企业图纸量大到已经有专职管理员在维护分类了但检索效率依然感人。问题是多数CAD厂商做的AI检索只覆盖自家格式。Tech Soft 3D做这个方向则是想办法从统一数据层出发覆盖几十种格式。把HOOPS Exchange解析出来的属性、几何标签、PMI信息一起灌进向量库检索的覆盖面就完全不一样了。3.3 生成式设计、自动化脚本与智能检查再往下挖一层是AI辅助生成和自动检查。比如根据过去的零件库风格自动建议新的结构方案或者自动检查模型中哪些孔距不满足工艺规范。这类能力需要有规则引擎、几何算法和大模型三者配合。HOOPS本身有着丰富的几何查询和测量接口可以作为这套体系的“手和脚”而AI负责“大脑”。目前行业里真正能跑通“AI出结论-几何引擎执行验证-反馈结果”闭环的团队很少缺的就是中间这一层连接。4. HOOPS AI的能力拆解与产品方向4.1 语义层让大模型能看懂三维数据从公开信息和技术交流中透露的方向判断HOOPS AI并不是一个单一的“聊天机器人”而更像是一整套把AI和HOOPS数据能力结合的系统。最核心的一块是语义层。它负责将HOOPS Exchange解析出来的装配树、零件属性、PMI、几何包围盒等结构化信息转换成语义化的对象模型。说得直白一点就是给大模型配一个“对三维世界的接口”。这个接口做得好不好直接决定了后面AI功能的天花板。如果只是把零件名字和属性丢给大模型那跟普通的文档检索没什么区别。真正有价值的是把几何关系也纳入进来。比如“离这个面最近的那根管道是什么”这种涉及空间关系的问题必须让模型能理解三维坐标和拓扑关系才有解。HOOPS多年来积累的模型拓扑数据能力给这种语义层提供了别的厂商不容易复制的数据基础。4.2 交互层语音、文本与三维场景的融合交互层方面HOOPS AI的方案看起来更倾向支持多模态输入。文本输入是基础语音输入在XR场景和车间场景里价值更大。想象一个工程师戴着AR眼镜站在设备旁边需要查看某个管路对应的零件信息直接开口问比低头翻手机高效得多。语音指令被识别之后转换成对HOOPS场景图的操作请求比如高亮某个零件、隐藏某些组件、生成剖面视图。这类演示在一些行业活动上出现过实际落地的主要难点还是语音识别的工程术语准确率而不是三维渲染本身。4.3 工具链集成从API到低代码配置对开发者来说更关心的可能是HOOPS AI以什么形态提供。从目前看到的方向推测它会以云服务和本地化部署结合的方式提供。基础API覆盖语义查询、场景操作指令解析、属性提取等常用能力。同时会有一些针对特定场景的预置模块比如面向装配审核的“自动生成审核清单”、面向售后的“故障零件定位辅助”。这种“通用能力场景预置”的组合针对性很强——通用大模型解决方案遍地都是CAD领域要的是开箱即用的垂直能力。4.4 私有化部署与数据安全制造业对数据安全的敏感度接触过的人都有体会。很多企业的三维模型就是核心资产不可能把数据传到第三方公有云上做大模型推理。所以HOOPS AI如果要在企业市场站住脚私有化部署能力是必须项。比较合理的预期是它会支持主流的私有化大模型框架把语义理解这块放到企业内部。HOOPS本身的渲染和数据转换都在端侧或私有服务器跑了很多年这个基因是一致的。5. 实战视角如何评估并接入这类AI能力5.1 先别急着接API把你的数据底座盘清楚我给准备吃螃蟹的团队一个建议上HOOPS AI之前先检查自己的数据管理现状。AI模型再强喂进去的是乱数据出来的结论也没法看。需要结构化的是三类信息格式统一程度、属性完整度、几何特征的语义标注水平。格式统一程度取决于你前端是否已经用HOOPS Exchange这类工具做解析入库。属性完整度指的是模型里有没有规范的Part Number、材料、版本等字段。几何语义标注则是更进阶的一件事——比如模型里有没有“安装孔”“散热面”这种带工程含义的标签没有的话AI能识别到的几何语义就很浅。这三类数据基础越好后面AI效果的上限越高。我们见过一些企业数据源乱七八糟文件名、属性、格式全都不统一这时候直接上AI检索大概率是灾难。先用传统手段做一轮数据治理反而比盲目追AI靠谱。5.2 语义映射与提示词工程要提前做好接入HOOPS AI时语义映射指的是把企业管理里习惯的叫法映射到系统可识别的属性或对象上。比如你们内部管“机壳”叫“罩子”那在语义层里就要做好这个词条的同义映射否则用户问“罩子有哪些尺寸”时系统匹配不到任何数据。这块工作的工程量经常被低估。一套完整的工程语义库至少包含产品类别、特征名称、材料术语、加工方式、检测要求等维度。HOOPS AI可以提供底层的语义理解引擎但企业独有的黑话和缩写一定得自己维护。建议是从MVP阶段就建立词条维护机制每遇到一个AI理解不了的业务词就补一条映射迭代半年后效果会有质变。另外提示词工程在这里跟搞聊天机器人完全是两码事。HOOPS AI场景里提示词模板要结合三维场景的实时上下文来写。比如“帮我筛出当前装配里所有未标注材质的零件”这个请求被翻译成代码大概三步遍历装配节点、检查材质属性、筛选空值高亮。AI需要输出的不是一段话而是一系列结构化的操作指令。模板设计就要引导模型往“输出操作序列”的方向走而不是让它长篇大论解释。5.3 验证闭环用可回滚的方式做功能开关实施AI功能最怕什么最怕AI出错直接影响设计数据。设计软件不是聊天工具一个错误的自动修改可能要了设计师半天的命。稳妥的接入策略是让AI只输出“建议的操作”而不是直接执行。用户在界面上看到AI给出的方案、高亮候选对象经过人工确认后再真正去改动数据。这样既保留了AI的效率价值又把风险控制在确认环节。HOOPS的组件体系其实很适合做这种“建议-确认-执行”的闭环。可视化层负责把候选对象高亮出来数据层负责记录变更前状态AI层负责生成建议界面层用确认按钮衔接。整个过程可以做到不破坏原模型。我强烈建议团队在上线初期所有AI功能默认带确认步骤等数据运行稳定、用户信任度建立起来再针对低风险操作开放自动执行。6. 落地场景与决策对照6.1 最可能先跑起来的三个场景第一个场景是智能模型检索与重用。企业历史模型库大用自然语言就能查到想要的零件或装配这件事我能确认是有刚需的。HOOPS Exchange做了格式解析和属性提取后HOOPS AI做语义检索是比较顺的落地路径。收益也明显研发部门找人找图的时间省一大截。第二个场景是自动生成BOM和工艺辅助信息。以前出一份准确的BOM要人工核对装配树和零件属性慢且容易漏。AI理解装配结构之后自动整理部件清单、标注采购状态再通过HOOPS Publish输出结构化文档流程简化很多。这里考验的是属性数据的准确度早期设计不规范的企业做起来会有点吃力。第三个场景是售后和培训环节的模型问答。客户拿到的产品说明书只能写通用内容配上AI交互之后客户可以直接对模型提问“这个指示灯报警是什么意思”“怎么拆下滤芯”系统结合三维模型生成图文指引。这块如果配合AR设备体验会更强当然也意味着更多开发投入。6.2 选型对照自研、HOOPS AI还是混合路线不少团队会在“自己接大模型做”和“用HOOPS AI”之间犹豫。我给一个比较务实的决策框架如果你的CAD应用已经有稳定的文件解析和渲染能力只是想加一个问答助手那自研大模型调用成本最低如果你面对的是多格式输入、需要深度理解三维结构、希望生成的结果能驱动渲染和操作那HOOPS AI的价值就体现出来了如果你的业务垂直到某个特定行业比如模具设计标准审查那大概率还要在HOOPS AI的基础之上继续叠业务规则。自研路线最大的隐性成本不在模型调用而在数据准备和场景联动那一层。很多团队都低估了把CAD数据结构化、再映射给大模型的工程量。这正好是HOOPS沉淀了二十多年的东西。所以从总拥有成本角度算一个成熟SDK厂商的AI中间层往往比从零自研更划算。6.3 团队组织结构也需要相应调整接这类AI能力还有一个容易忽略的点团队里得有人既懂CAD数据结构又懂AI应用开发还得有产品经理能把工程需求翻译成AI需求。这种复合角色很难招更多要靠内部培养。比较务实的做法是让现有CAD开发骨干去补AI知识业务部门出人做语义定义再由算法工程师实现模型调用和微调。三条线配合项目才推得动。7. 避坑经验与常见问题解答7.1 大模型的“幻觉”在工程场景更危险CAD领域使用大模型最怕的不是答非所问而是看起来非常专业的数据错误。比如AI回答“这个零件的材料是Q235”但实际模型属性里根本没写材料AI是根据外观“猜”的。这在设计评审里是绝对不能接受的。现阶段处理办法是让AI在给出结论时标注信息来源信息来自模型属性的才直接显示信息是推断的要明确加“根据经验推断”提示。语义层设计必须把这个逻辑固化下来不能指望模型自己判断。7.2 格式版本升级会悄悄影响AI效果用了HOOPS Exchange的老手都清楚CAD格式一升级解析结果偶尔会有些微小变化。这些变化平时可能不影响显示但对AI来说可能就是属性名、单位、层级结构的差异。所以AI语义层的映射规则必须定期跟着SDK版本走。最怕的是上游换了CAD版本下游AI突然检索不到数据排查很久才发现是解析逻辑变了。7.3 同义词与多语言问题尽早规划工程行业的称呼五花八门“沉头孔”有人叫“埋头孔”“法兰”有人叫“凸缘”英文还有美式英式差异。语义层如果不提前做好同义词表用户就会发现换一种叫法就搜不到东西。这个坑我们踩过一次之后学乖了现在新接一个客户第一件事就是收集他们的词汇表哪怕先收一百个词也好比发现问题再补救强得多。7.4 性能与成本要放在一起考虑AI语义查询通常比传统SQL查询慢三维场景里的实时AI交互如果要求毫秒级响应单靠通用大模型不太行。务实的架构是极热数据用规则和向量缓存兜住复杂问题才走大模型推理。很多方案在演示环境看着流畅一到生产环境就卡顿多半是没做这种分层处理。算力成本也一样每次语义查询都调大模型接口账单会很可观。8. 一些个人的判断和收尾把Tech Soft 3D、HOOPS AI放在整个CAD行业AI化进程里看它的角色很像一座桥。一端连着几十种存在了几十年的CAD格式另一端连着正在快速进化的大模型能力。真正想明白这一点就会理解它为什么做AI的思路跟CAD应用厂商不一样——它不需要改变设计师的工作习惯而是让每一个使用HOOPS组件的应用都能低成本地获得AI能力。我个人的体会是CAD领域做AI最难的从来不是模型本身而是把模型嵌入到一套对精度、安全、可靠性要求极高的工程环境里。HOOPS AI作不完美但至少它选择了一条从数据底层向上做的务实路径。对广大做CAD应用开发的团队而言现在最值得做的不是观望而是拿自己的真实数据和几个核心场景去验证一下这条路到底能跑多远。等基础模型和数据管道磨合顺了后面每一个新场景的前进速度都会快很多。