AI+CAD工程化落地：从Demo到生产环境的鸿沟与应对

1. 从一堆跑得通的Demo说起AICAD落地到底卡在哪过去一年多我陆陆续续接触过十几个号称AICAD的项目有做图纸智能识别的有做参数自动生成的也有做自然语言驱动建模的。几乎每一个在演示阶段都让人眼前一亮上传一张DWG几秒钟后模型结构就出来了输入一句给我画个法兰盘屏幕上真的长出了一个带螺栓孔的零件。但真正把这些东西往工程环境里搬的时候问题就来了——原本在Demo里跑得飞快的流程到了实际项目里要么精度不够要么速度慢到没法用要么干脆在某个环节直接崩掉。这个现象不是个例。我后来跟不少同行聊发现大家遇到的困境高度相似Demo满天飞工程走不通。这不是AI不行也不是CAD不行而是两者结合的那条链路里藏着太多在演示阶段被刻意忽略的细节。这篇文章我想把这条链路拆开从数据格式、几何内核、AI能力边界、工程约束几个角度聊聊为什么能跑通和能用之间隔着一道鸿沟以及我实际踩过的一些坑和总结出来的应对思路。如果你正在做AICAD相关的产品、研究或者内部工具或者你只是好奇为什么这个方向喊了这么久却迟迟没有大规模落地那这篇内容应该能给你一些参考。我会尽量少讲概念多讲实际遇到的情况和背后的原因。2. 数据格式这道坎DXF和DWG远没有看起来那么标准2.1 DXF的标准是个美好的误会很多人做AICAD的第一步就是解析DXF因为它是文本格式看起来结构清晰用Python的ezdxf库几行代码就能读出来。我一开始也是这么想的直到我拿了几十张来自不同设计院、不同软件版本导出的DXF文件做测试才发现事情没那么简单。DXF确实有官方规范但实际文件里充斥着各种方言。同样是直线有的用LINE实体有的用LWPOLYLINE有的用POLYLINE加VERTEX组合同样是文字MTEXT和TEXT的混用几乎是常态而且MTEXT里的格式控制码能把人逼疯。更麻烦的是图层命名有的设计院用墙-承重-240有的用WALL_240_LOAD还有的干脆用拼音首字母。你写一套规则去解析换一个来源就失效。我做过一个统计拿100张来自不同渠道的DXF文件用同一套解析逻辑去提取墙体信息准确率大概在60%到70%之间。剩下的30%到40%要么是图层命名对不上要么是实体类型超出预期要么是坐标系统不一致。这个准确率在Demo里演示没问题因为你可以挑一张干净的图但到了工程环境没人会给你挑图的机会。2.2 DWG的封闭性让AI无从下手DWG比DXF更麻烦。它是二进制格式而且Autodesk一直没有完全公开其内部结构。虽然有一些开源库能读DWG但支持程度参差不齐遇到复杂实体或者高版本文件就容易出问题。我试过用开源方案读一个2018版本的DWG里面包含动态块和自定义对象结果直接报错退出。这就导致一个很尴尬的局面AI模型需要结构化数据才能发挥威力但CAD世界里的数据恰恰是最不结构化的。你拿到的图纸本质上是一堆几何图元的集合没有语义没有层级没有这是一面墙或者这是一个螺栓孔的标注。AI要做的第一件事就是把这些几何图元重新组织成有意义的工程对象而这个重新组织的过程恰恰是最难自动化的。2.3 从几何到语义中间缺了一层翻译我后来想明白一件事AICAD的核心难点不在于AI模型本身有多强而在于从几何图元到工程语义之间的那层翻译。这层翻译在人类工程师脑子里是自然而然发生的——看到两条平行线加一段圆弧就知道那是一个倒角看到一组同心圆加中心线就知道那是一个孔。但要让机器理解这些需要大量的领域知识和规则。我试过用纯视觉方案把DWG渲染成图片然后用目标检测模型去识别墙体、门窗、标注。效果怎么说呢在简单图纸上还行一旦图纸密度上去或者有大量重叠图元识别率就断崖式下跌。而且视觉方案有个致命问题它只能给出大概位置没法给出精确的几何参数。工程上要的是精确到毫米的尺寸不是这里大概有个门。后来我转向了基于图元关系的方案先解析出所有几何实体然后根据它们之间的空间关系平行、垂直、共线、同心等来推断语义。这个思路更靠谱但实现起来工作量巨大而且规则很难穷举。一个墙体的判定可能涉及图层、线型、颜色、线宽、相邻关系、闭合性等十几个特征每个特征都要调阈值调完阈值还要处理例外情况。3. 几何内核为什么FreeCAD和OpenCascade不是万能药3.1 OpenCascade很强但学习曲线陡得吓人说到CAD几何内核OpenCascade简称OCC是绕不开的。它是开源的功能强大支持BRep建模、布尔运算、倒角圆角、曲面操作等等。FreeCAD就是基于OCC构建的。我一开始觉得有了OCC几何处理这块应该不用愁了。实际用起来才发现OCC的API设计对新手极不友好。它的文档零散示例代码少很多功能要靠读源码或者翻论坛才能搞明白。而且OCC的报错信息经常让人摸不着头脑一个布尔运算失败可能返回一个错误码但具体为什么失败、哪一步出了问题得自己一步步排查。我印象最深的一次是想把一个从DWG读进来的二维轮廓拉伸成三维实体。轮廓本身是闭合的看起来没问题但OCC就是报错说无法构建面。后来查了很久才发现轮廓里有一段圆弧的端点跟相邻直线的端点差了0.001毫米肉眼完全看不出来但OCC的容差判定就是过不去。这种问题在Demo里不会遇到因为Demo用的都是精心准备的干净数据但工程数据里这种微小误差遍地都是。3.2 FreeCAD的生态能用但别指望它开箱即用FreeCAD作为开源CAD平台生态确实在慢慢变好。它有Python接口可以脚本化操作这对AICAD来说是个很大的优势——你可以用Python写AI逻辑然后直接调用FreeCAD的API来建模。但FreeCAD本身有不少坑比如它的齿轮工具经常被吐槽不好用参数化建模的稳定性也一般复杂模型容易崩。我用FreeCAD做过一个批量生成标准件的工具输入规格参数自动生成对应的三维模型。简单零件没问题但一旦涉及复杂特征比如变位齿轮或者非标螺纹FreeCAD就力不从心了。而且FreeCAD的版本兼容性也是个问题不同版本之间的API有差异升级一次可能就要改一堆代码。3.3 自研内核大多数团队想都不要想有些团队会想既然开源内核有这么多限制那干脆自研一个。我的建议是除非你有十年以上的几何算法积累和一个稳定的数学团队否则不要碰这个方向。几何内核的复杂度远超大多数人的想象光是布尔运算的鲁棒性就够研究好几年。而且自研内核意味着你要自己处理所有边界情况而CAD里的边界情况是无穷无尽的。我见过一个团队花了两年时间自研了一个简易内核结果在处理复杂曲面的时候频繁崩溃最后还是切回了OCC。这个教训很深刻在几何内核这件事上不要重复造轮子除非你确定自己能造得更好。4. AI模型在CAD场景下的真实能力边界4.1 视觉识别看起来很美用起来很痛用深度学习做图纸识别是很多AICAD项目的切入点。思路很直接把DWG渲染成图片然后用目标检测或者语义分割模型去识别图元。我试过几种主流方案包括基于YOLO的检测和基于U-Net的分割效果总结下来就是在受控条件下表现不错在真实场景下勉强能用在工程精度要求下不够看。问题主要出在几个方面。第一是分辨率工程图纸的细节非常密集一张A1图纸渲染成2000x2000的图片很多小尺寸图元就糊成一团了。要提高分辨率显存和计算量就上去了推理速度直线下降。第二是重叠图元CAD图纸里图元重叠是常态视觉模型很难区分哪些是主要图元哪些是辅助线。第三是精度视觉模型给出的是像素坐标要转换成工程坐标需要标定而标定本身就会引入误差。我后来把视觉方案定位为辅助而不是主力用视觉模型做初步筛选和区域定位然后用几何方法做精确提取。这样结合下来效果比纯视觉好不少但流程也复杂了不少。4.2 大模型直接生成CAD代码方向对但路还长最近一年用大模型直接生成CAD脚本或者建模代码的思路很火。比如你输入画一个长宽高分别为100、50、30的盒子顶部中心有一个直径20的孔模型输出一段Python代码调用FreeCAD或者OCC的API来建模。这个方向我觉得是对的因为大模型擅长处理自然语言和结构化输出而CAD建模本质上就是一系列结构化操作。但实际用下来问题也很明显。首先是空间推理能力不足大模型对三维空间的理解还很浅你让它生成一个孔在盒子顶部中心它可能把孔放到侧面或者偏离中心。其次是API幻觉大模型经常会编造不存在的函数或者参数生成的代码跑不起来。第三是精度控制工程上对尺寸公差有严格要求大模型生成的代码往往忽略这些细节。我目前的用法是让大模型生成骨架代码然后我自己补全细节和校验逻辑。这样效率确实有提升但离一句话生成完整模型还有很长的路。4.3 参数化与约束求解AI暂时插不上手CAD里有一个很重要的部分叫参数化约束求解就是给几何元素之间定义约束关系平行、垂直、相切、等长等然后求解器自动调整几何形状以满足约束。这部分目前AI基本插不上手因为约束求解是一个数值优化问题需要精确的数学计算而不是概率预测。我试过用强化学习来做约束求解效果很不理想。求解空间太大奖励信号稀疏训练出来的模型要么收敛慢要么解的质量差。后来还是老老实实用传统的数值求解器AI只在前面做约束识别和推荐。5. 工程环境的真实约束为什么能用比能跑难十倍5.1 精度要求Demo可以模糊工程必须精确Demo里最常听到的一句话是差不多就行但工程里没有差不多。一个螺栓孔的位置偏了0.5毫米可能就导致装配不上一条墙线的长度差了1毫米可能就导致面积计算错误。AI模型天生带有概率性输出结果有不确定性这在工程场景里是致命的。我做过一个实验用同一个AI模型对同一张图纸做十次识别结果每次的墙体位置都有细微差异最大偏差到了2毫米。这个偏差在Demo里看不出来但在工程里是不可接受的。后来我的做法是AI只负责识别不负责定位定位交给几何算法来做确保每次结果一致。5.2 速度要求批量处理时慢一秒都是灾难Demo通常只处理一张图而且可以等。但工程环境里一个项目可能有几百张图纸而且用户希望几分钟内出结果。我算过一笔账如果单张图纸的处理时间是30秒100张就是50分钟这个时间成本大多数用户接受不了。AI模型的推理速度是瓶颈之一。一个中等规模的视觉模型在GPU上跑一张图可能要几百毫秒加上前后处理单张图纸轻松超过10秒。要提速要么换更小的模型精度下降要么加硬件成本上升要么优化流程工程量巨大。我目前的做法是把AI推理和几何处理并行化能压到单张5秒左右但离秒级还有距离。5.3 可解释性出了问题得知道为什么工程环境里用户不仅要知道结果还要知道结果是怎么来的。如果AI说这里有一面墙用户会问为什么你认为这是墙依据是什么如果AI给不出合理的解释用户就不敢用。这一点上纯AI方案很吃亏。深度学习模型是个黑盒你很难解释它为什么做出某个判断。我后来在流程里加了一层规则校验AI给出初步判断然后用几何规则去验证验证通过的才输出不通过的标记出来让人工复核。这样虽然增加了工作量但用户接受度高了很多。5.4 数据安全与私有化部署工程图纸往往涉及商业机密很多用户要求私有化部署不能把图纸上传到云端。这就意味着你不能用那些需要联网的大模型API只能用本地部署的模型。而本地部署的模型能力通常比云端模型差一截这是个硬约束。我试过在本地部署一个中等规模的开源大模型来做CAD相关的自然语言处理效果比云端模型差不少尤其是在复杂指令的理解上。后来只能把任务拆细让本地模型做简单分类和提取复杂逻辑用规则引擎来补。6. 我实际踩过的几个坑和应对思路6.1 坑一以为解析了DXF就万事大吉前面提过DXF的方言问题让我吃了不少亏。我最初的解析逻辑只考虑了标准实体结果遇到用自定义实体的图纸就直接跳过导致信息丢失。后来我加了一层未知实体收集把所有不认识的实体单独存起来分析它们的共同特征再逐步扩展解析规则。这个过程很枯燥但效果是实打实的。6.2 坑二低估了几何容差的重要性OCC的容差问题让我debug了整整一周。后来我养成了一个习惯所有从外部读入的几何数据先做一轮清洗包括合并重合点、修复微小间隙、统一坐标精度。这一步看起来简单但能避免后面大量的莫名其妙报错。6.3 坑三AI模型选型只看精度不看速度我一开始选了一个精度很高的视觉模型单张推理要2秒加上前后处理一张图纸要15秒。后来换了一个轻量模型精度降了3个百分点但速度提升了5倍。在实际使用中用户对速度的敏感度远高于对那3个百分点精度的敏感度。6.4 坑四忽略了用户的实际工作流我最初做的工具是上传图纸-等待处理-下载结果后来发现用户根本不这么用。他们希望工具能集成到现有的CAD软件里直接在绘图界面里调用。这个需求变更导致我重构了整个交互层。教训是做工具之前先搞清楚用户实际是怎么工作的。7. 如果现在让我重新做我会怎么设计这条链路7.1 分层架构AI只做它擅长的事我现在倾向于把整个链路分成三层感知层、语义层、几何层。感知层用AI做初步识别和分类语义层用规则和知识图谱做对象关系推断几何层用OCC做精确建模和校验。AI只在感知层发挥作用不参与后面的精确计算。这样既利用了AI的泛化能力又保证了工程精度。7.2 数据预处理花多少时间都值得数据预处理的重要性怎么强调都不为过。我现在会把30%到40%的开发时间花在数据清洗和标准化上包括格式统一、坐标归一、图层映射、实体修复等。这一步做扎实了后面的AI和几何处理都会顺畅很多。7.3 人机协同不要追求全自动全自动是很多AICAD项目的执念但实际工程里全自动往往意味着高风险。我现在更倾向于人机协同AI做初步处理人工做复核和修正系统记录人工修正的结果用来迭代优化AI模型。这样虽然单次处理时间长了但整体可靠性和用户信任度高了很多。7.4 从小场景切入别一上来就做通用平台我见过太多团队一上来就想做通用AICAD平台结果做了两年还在Demo阶段。我的建议是先找一个足够窄的场景比如批量提取图纸中的门窗表或者自动生成标准件三维模型把这个场景做到极致再逐步扩展。窄场景的好处是边界清晰容易验证也容易找到愿意付费的用户。8. 一些具体的工具选型和技术细节8.1 DXF解析ezdxf够用但要自己补很多逻辑Python生态里ezdxf是解析DXF最成熟的库。它支持大多数标准实体文档也比较全。但如前所述实际DXF文件里的方言需要你自己处理。我的做法是在ezdxf之上封装一层把不同来源的实体统一成内部表示这样上层逻辑就不用关心底层差异了。8.2 DWG处理能用ODA就用ODA如果预算允许ODAOpen Design Alliance的SDK是处理DWG最靠谱的方案。它支持各种版本的DWG实体覆盖全稳定性好。缺点是收费而且集成起来有一定工作量。如果预算有限可以考虑用FreeCAD的DWG导入功能但支持程度有限复杂图纸容易出问题。8.3 几何处理OCC为主FreeCAD为辅OCC负责底层的几何运算FreeCAD负责上层的建模和参数化。两者通过Python接口衔接。需要注意的是FreeCAD的Python API在不同版本间有变化建议锁定一个稳定版本不要频繁升级。8.4 AI模型本地部署优先云端为辅考虑到数据安全我倾向于本地部署开源模型。视觉任务可以用YOLO或者Detectron2自然语言任务可以用ChatGLM或者Qwen的中小规模版本。如果确实需要更强的能力可以在用户授权的前提下调用云端API但要做好数据脱敏。9. 关于这个方向的一些个人判断AICAD这个方向我觉得长期来看是有价值的但短期内不要期待颠覆。CAD是一个积累了几十年的领域里面的工程知识和经验不是AI几年就能学会的。AI能做的是把那些重复性高、规则明确的工作自动化比如图纸信息提取、标准件生成、批量修改等。这些场景虽然不性感但实实在在能省时间。另一个判断是这个方向的赢家大概率不是纯AI公司也不是纯CAD公司而是能把两者结合好的团队。纯AI公司不懂CAD的工程约束纯CAD公司不懂AI的能力边界只有两者都懂才能做出真正能用的产品。最后说一句如果你正在做这个方向不要被Demo的漂亮效果迷惑多去实际工程环境里跑一跑多跟一线工程师聊一聊你会发现很多在办公室里想不到的问题。这些问题才是真正的机会所在。