AI+CAD工程化落地：从Demo到交付的鸿沟与破局路径

1. 从能跑通到能交付之间隔着一条工程化的鸿沟过去一年多我参与过三个把 AI 能力往 CAD 工作流里塞的项目有做图纸信息提取的有做参数化建模辅助的也有做批量改图脚本的。三个项目有一个共同点Demo 阶段都异常顺利两周内就能录出一段看起来很唬人的演示视频但一旦进入真实工程环境进度就像撞了墙怎么推都推不动。这个现象不是个例我身边做 CAD 二次开发、做工程数字化的朋友几乎都遇到过同样的困境。标题里说的Demo 满天飞工程却走不通说的就是这件事。它不是一个技术悲观论调而是一个非常具体的工程现实AI 在 CAD 场景里的单点能力已经足够惊艳但 CAD 这个领域本身是一个高度工程化、格式封闭、精度敏感、历史包袱极重的系统AI 的概率性输出和 CAD 的确定性要求之间存在结构性矛盾。这篇文章我想把这条鸿沟拆开讲清楚——它到底卡在哪几个环节每个环节的根因是什么以及我实际试过哪些绕过去的办法。适合读这篇的人有三类一是正在做 AI CAD 方向探索的开发者二是被老板要求用 AI 改造设计流程的技术负责人三是对 CAD 数据格式和工程落地感兴趣、想少走弯路的从业者。我不会给你画大饼也不会唱衰只讲我踩过的坑和验证过的路径。2. 先搞清楚 CAD 数据的真实形态再谈 AI 能做什么2.1 DWG、DXF、EXB 不是文件格式是三套不同的世界很多人做 AI CAD 的第一反应是我把图纸读进来喂给模型不就行了。问题就出在这个读进来上。CAD 图纸的主流格式至少有三种形态每一种背后的数据模型都不一样。DWG是 AutoCAD 的原生二进制格式封闭程度最高。它内部不是简单的图形列表而是一个包含图层、块引用、属性、扩展数据、字典、句柄索引的复杂对象数据库。你用一个开源库去读 DWG读出来的往往只是几何图元图层语义、块定义关系、字段表达式这些工程信息大量丢失。DXF是交换格式分 ASCII 和二进制两种。ASCII DXF 看起来是文本好像很好解析但它有版本差异——R12、R2000、R2007、R2018 的段结构、实体类型、组码含义都有变化。我见过一个团队用只支持 R12 的解析器去读 R2018 的图纸结果样条曲线全部退化成折线尺寸标注的关联关系全丢模型拿到的输入本身就是错的。EXB是国产 CAD 的格式生态相对封闭转换工具链不完整。热词里出现的exb转dwg转换器exb转换工具恰恰说明这个环节在真实工作流里是个高频痛点。这三套世界之间的转换每一次都是有损的。而 AI 模型对输入是照单全收的——你给它错的几何它就基于错的几何给你一个自信满满的错误答案。2.2 图纸里的语义和几何是两回事这是我在项目里花了最长时间才想明白的一件事。CAD 图纸对工程师来说价值不在线条本身而在线条承载的工程语义这条线是墙还是轴线这个圆是螺栓孔还是管道截面这个标注是公差还是参考尺寸。但对 AI 来说它首先看到的是一堆坐标点、直线段、圆弧、多段线。几何是显性的语义是隐性的而且语义往往藏在图层名、块名、线型、颜色、扩展属性这些元数据里。一个真实的机械图纸图层可能有几十个命名规则还因设计院、因项目、因年代而异。我做过一个实验把同一张装配图分别用纯几何和几何 图层语义两种方式喂给模型做零件识别前者的准确率大概在六成出头后者能到八成五以上。差距全在语义上。所以 AI CAD 的第一个工程化门槛不是模型能力而是你能不能把图纸的语义完整、无损地提取出来并且结构化地交给模型。2.3 精度这件事AI 的思维方式天然不匹配CAD 是确定性系统。一条线画在 (100.000, 50.000)它就是精确的尺寸链闭合就是闭合公差带就是公差带。工程上差一点就是废品。AI 是概率性系统。它输出的是最可能的答案天然带误差。你让模型去识别一个尺寸标注是 25 还是 26它可能给你 25.3 这种既不是 25 也不是 26 的结果。你让它生成一段轮廓它可能给你一条看起来像但端点不闭合、切线不连续的曲线。这个矛盾在 Demo 里被掩盖了——Demo 只需要看起来对工程需要精确对。我见过太多演示里模型把图纸识别得漂漂亮亮一上真实产线尺寸偏差 0.5mm整条工艺链就崩了。所以工程化的关键是在 AI 的概率输出和 CAD 的确定性要求之间加一层校验和修正机制而不是指望模型自己变精确。3. 那些让 Demo 惊艳、让工程崩溃的具体环节3.1 数据入口读取环节的坑比想象中深我拿一个真实案例说。项目目标是读取一批 DWG 图纸自动提取所有孔位坐标生成加工清单。Demo 阶段用的是十几张自己画的、图层规范、块命名统一的测试图跑得很顺。上真实数据后问题一个接一个块引用嵌套真实图纸里块套块有的嵌套三四层还带镜像和旋转。简单遍历块表拿到的坐标是块定义坐标系下的不是世界坐标系下的直接算就全错。外部参照图纸里插了外部参照Xref参照文件没一起给几何直接缺失。热词里cad多重引用插入解除工具就是这个痛点的产物。字段表达式有些标注用的是字段表达式值是动态计算的静态读取拿到的是缓存值或者空值。比例问题热词里pr0tel导入dxf文件时怎么改图纸比例很典型——不同来源的图纸单位不一致有的是毫米有的是英寸有的是图纸单位不做单位归一化坐标全是错的。我最后的做法是读取环节不追求一把梭而是分三步走——先用成熟库比如 ODA 的转换能力或者 FreeCAD 的导入模块把 DWG 转成中间格式再在中间格式上做几何和语义的分离提取最后做单位、坐标系、比例的归一化。每一步都留校验点任何一步数据异常就报警绝不带着脏数据往下走。3.2 模型输入图纸不是图片别当图片喂这是另一个高频误区。很多人做 AI CAD直接把图纸导出成 PNG 或者 PDF然后当图像识别任务做。短期看效果不错长期看是死路。原因有三。第一图像化会丢精度一张 A0 图纸导出成 2000 像素宽的图一个 0.1mm 的细节可能就一两个像素模型根本分不出来。第二图像化会丢语义图层、块、属性这些信息在像素里荡然无存。第三图像化后模型输出的坐标是像素坐标要反算回图纸坐标中间又引入一次误差。我现在的做法是双通道输入几何通道用矢量数据DXF 实体、FreeCAD 的拓扑结构语义通道用结构化元数据图层、块名、属性表两条通道在模型侧做融合。图像只作为辅助用来做版面理解、区域划分这类粗粒度任务不承担精确测量。3.3 输出环节模型给的答案CAD 不认就算模型识别得准输出环节还有一道坎。模型输出的是自然语言或者 JSONCAD 要的是能直接落地的实体。中间这个转换坑非常多。举个具体的模型说在 (120, 80) 处有一个直径 10 的孔。你要把它变成 CAD 里一个真实的圆实体需要确定它在哪个图层、用什么线型、是不是块的一部分、有没有关联的标注、公差怎么标。这些模型通常不管你得自己补。更麻烦的是批量修改场景。热词里python批量对cad修改是个真实需求。模型判断这批图纸的某个尺寸要统一改但改的时候要考虑这个尺寸是不是被别的尺寸引用、改了之后尺寸链还闭不闭合、关联的标注会不会失效。模型给的是改成多少工程要的是怎么改才不出连锁问题。我的经验是输出环节必须有一层CAD 语义适配器把模型的意图翻译成符合 CAD 数据模型的操作序列并且在执行前做一次影响面分析。这层适配器是工程化的核心也是最难写的部分因为它需要对 CAD 数据模型的深刻理解不是调个 API 就完事。3.4 验证环节没有 ground truth就没有工程可信度Demo 不需要验证工程必须验证。但 CAD 场景的验证特别难因为缺少标注好的 ground truth。我试过几种验证思路。一是规则校验尺寸链闭合、图层规范、线型一致这些可以用规则自动查不依赖模型。二是交叉验证同一张图用两种不同方法提取结果比对差异大的人工复核。三是增量验证在历史项目里找已经人工确认过的图纸作为回归测试集。这里有个反直觉的结论验证环节的投入往往比模型本身还大。我那个孔位提取项目模型部分大概占了三成工作量剩下七成全花在数据清洗、格式转换、验证机制上。这也是为什么很多团队 Demo 做得快、工程推不动——他们把七成的工作量低估成了一成。4. 我实际验证过的几条可行路径4.1 用 FreeCAD 做中间层绕开格式封闭的坑FreeCAD 在这个场景里被低估了。它本身是个开源参数化 CAD但更重要的是它的数据模型开放、Python 接口完整、支持多种格式导入导出。热词里freecad出现多次说明关注度在上升。我的用法是把 FreeCAD 当成CAD 数据的中间表示层。DWG、DXF、STEP、IGES 这些格式先通过 FreeCAD 导入转成它内部的拓扑结构Shape、Solid、Face、Edge在这个结构上做几何和语义的提取再喂给 AI。好处是 FreeCAD 的拓扑结构是标准化的不用为每种源格式写一套解析逻辑。要注意的是 FreeCAD 导入 DWG 依赖外部转换器导入质量取决于转换器版本复杂图纸会有几何丢失。我的做法是导入后做一次几何完整性检查边数、面数、体积这些指标和源文件比对差异超阈值就报警。另外热词里freecad没有齿轮工具这类问题其实反映的是 FreeCAD 生态的插件化特点——核心功能精简专业功能靠插件和工作台。做 AI CAD 集成时要评估清楚哪些能力是原生的、哪些要自己补。4.2 用 OpenCascade 做几何内核把精度问题交给确定性系统这是我目前最推荐的一条路径。核心思路是AI 只负责理解和决策几何的精确操作全部交给 OpenCascade 这类确定性几何内核。具体分工是这样的AI 从图纸里识别出这里有一个孔直径大概 10位置大概在 (120, 80)这是概率性的、允许有误差的。然后由 OpenCascade 去执行在 (120, 80) 创建一个直径 10 的圆并做布尔运算这是确定性的、精确的。AI 的输出经过一层意图到操作的翻译翻译过程中做参数校验和修正最终落到几何内核上的都是精确值。热词里【cpython土木4】dwg图纸读取到opencascade说的就是这个方向。C 做几何内核的性能和精度Python 做 AI 和胶水逻辑这个组合在工程上很实用。我实测下来几何操作的精度问题基本被这个架构解决了剩下的问题集中在意图翻译这一层——也就是怎么把 AI 的模糊输出可靠地翻译成精确的几何操作。4.3 用规则引擎兜底别让 AI 独自承担关键决策我踩过最大的一个坑是让 AI 独自决定哪些尺寸需要修改。结果它把一些关联尺寸也改了导致尺寸链不闭合图纸直接废掉。后来我改成规则引擎 AI 的混合架构AI 负责识别和推荐规则引擎负责把关。规则引擎里写清楚哪些尺寸是主尺寸可以改、哪些是从尺寸跟着变、哪些是参考尺寸不能动、改了主尺寸后哪些关联要重算。AI 的推荐先过规则引擎通过才执行不通过就打回或者转人工。这个架构看起来不够 AI但工程上非常稳。我的体会是在 CAD 这种高精度、强关联的场景里AI 应该是副驾驶而不是自动驾驶。关键决策要有确定性的兜底机制AI 的价值在于降低人工工作量而不是取代人工判断。4.4 多 AI 协作处理复杂任务链单一模型处理复杂 CAD 任务往往力不从心。热词里多ai协作ai agent反映的就是这个趋势。我的实践是把 CAD 任务拆成几个子任务每个子任务用最合适的模型或方法子任务推荐方法理由版面理解、区域划分视觉模型图像任务视觉模型擅长实体识别、分类微调后的小模型领域特定小模型够用且快尺寸提取、数值识别OCR 规则校验精度要求高纯模型不可靠几何操作、布尔运算OpenCascade确定性要求必须用几何内核意图翻译、操作序列生成大语言模型需要理解上下文和工程语义这个分工不是固定的要根据具体任务调整。核心原则是让每个环节用最可靠的方法而不是让一个模型包打天下。5. 工程化落地时那些没人告诉你的经验5.1 先做数据治理再谈 AI我现在的项目第一步永远是数据治理不是模型选型。具体包括图纸格式统一、图层规范梳理、块命名标准化、单位归一化、历史图纸的版本清理。这一步做完AI 的效果往往能提升一大截因为输入干净了。很多团队跳过这一步直接上模型结果模型效果不好就以为是模型不行换模型、调参数折腾半天其实问题在数据。我的经验是数据治理的投入产出比远高于模型调优。5.2 建立人机回环别追求全自动全自动在 Demo 里很性感在工程里很危险。我现在的做法是设计人机回环AI 处理大部分不确定的、高风险的、影响面大的转人工确认。人工确认的结果又回流成训练数据模型越用越准。这个机制的关键是设计好什么时候转人工的触发条件。我的触发条件包括模型置信度低于阈值、涉及关键尺寸、影响超过 N 个实体、规则引擎校验不通过。这些条件要根据项目实际调整没有万能公式。5.3 版本兼容是个长期战争CAD 格式在演进AI 模型在演进你的代码也在演进。三者版本不匹配是工程后期最常见的故障源。我吃过亏之后现在所有项目都强制做版本矩阵管理记录每个版本组合下的测试结果升级任何一个组件前先跑回归测试。热词里cad过期cad安装激活步骤这些反映的是 CAD 软件本身的版本管理问题。做集成时要明确你的方案支持哪些 CAD 版本、哪些格式版本不支持的要提前说清楚别等上线了才发现。5.4 性能问题往往在最后才暴露Demo 用十几张图工程用几万张图。单张处理 3 秒一万张就是 8 个多小时。而且真实场景往往是批量、并发、还要实时反馈。我遇到过的性能坑包括几何内核的内存泄漏、模型推理的批处理效率、格式转换的 IO 瓶颈、并发时的资源竞争。这些在 Demo 阶段完全看不出来一上量就全冒出来。我的建议是尽早做压力测试别等到上线前才发现性能不达标。6. 关于走不通这件事我的真实看法说了这么多坑可能有人觉得 AI CAD 是不是根本走不通。我的看法恰恰相反不是走不通是走法不对。Demo 满天飞说明单点技术已经成熟了这是好事。工程走不通说明大家还在用做 Demo 的思路做工程把 AI 当成了万能钥匙忽略了 CAD 领域本身的工程复杂度。一旦把架构调整过来——AI 做理解和决策确定性系统做精确操作规则引擎做兜底人机回环做保障——很多走不通的地方其实是能走通的。我最近一个项目用这套架构做图纸信息提取准确率从最初的六成多提到了九成以上人工复核工作量降了七成。它不是全自动但它真的在工程里跑起来了每天都在产出价值。这比一个惊艳但落不了地的 Demo有意义得多。如果你正在做类似的方向我的建议是先把数据入口和验证机制做扎实再谈模型。这两块做不好模型再强也是空中楼阁。至于模型选型、参数调优这些反而是后面的事而且随着基础模型能力提升这部分会越来越简单。最后分享一个我自己的判断标准一个 AI CAD 方案能不能落地不看它 Demo 多惊艳看它出错的时候能不能被及时发现、被可靠修正、被人工接管。能回答清楚这三个问题的方案才值得往工程里推。