1. 从一堆炫酷演示到工程现场的真实落差过去一年多我参与过三个把 AI 往 CAD 流程里塞的项目从最开始的“让大模型读图纸自动生成修改建议”到后来“用视觉模型识别 DWG 里的图元再回写”再到最近一个“AI 辅助生成参数化模型”的尝试。每一次立项的时候团队都很兴奋Demo 录出来也确实好看上传一张图纸几秒钟后模型圈出几个区域旁边弹出文字说明再点一下按钮DXF 就导出到本地了。会议室里掌声不断领导点头项目进入下一阶段。然后真正的问题来了。当这套东西要交给一线设计人员、要接入他们每天用的 CAD 环境、要处理他们手里那些积累了十几年的图纸时几乎每一个环节都开始出问题。图纸打不开、图层对不上、坐标偏移、字体缺失、块引用炸开、标注错位、导出 DXF 之后下游软件读不了……Demo 里那些“智能”的部分反而成了最不重要的东西真正卡住工程落地的是那些看起来最枯燥、最没有技术含量的“脏活”。这篇文章想聊的就是这件事为什么 AI 和 CAD 结合的方向看起来那么诱人Demo 可以满天飞但真正走到工程里却处处走不通。我会从图纸格式的底层差异、AI 模型在工程语境下的能力边界、工具链集成的现实约束、以及实际落地时那些没人愿意写进 PPT 的细节这几个角度展开。如果你正在做类似的事情或者准备入这个坑希望这些经验能帮你少走一些弯路。关键词里出现的 DXF、DWG、FreeCAD、OpenCascade 这些词基本覆盖了这条路上你会遇到的核心技术节点。我会尽量把每个环节讲透包括为什么某些看起来简单的操作在工程里会变得极其复杂。2. DWG 和 DXF 不是“一种东西的两种格式”2.1 为什么“读个图纸”这件事本身就很难很多人第一次接触 CAD 数据交换的时候会默认 DWG 和 DXF 是同一种东西的不同后缀就像 .doc 和 .docx 的关系。这个理解偏差是后面所有问题的根源。DWG 是 AutoCAD 的原生二进制格式它的结构是私有的、版本化的、并且随着 AutoCAD 版本迭代不断变化。从 R14 到 2000、2004、2007、2010、2013、2018每一个大版本的文件结构都有差异。你用一个库去读 R14 的 DWG 可能没问题但遇到 2018 的 DWG 就可能直接报错。更麻烦的是DWG 里可以嵌入自定义对象、代理对象、扩展数据这些东西在不同版本之间的兼容性非常脆弱。DXF 则是 Autodesk 为了数据交换设计的文本格式理论上更开放、更容易解析。但 DXF 本身也分版本而且不同软件导出的 DXF 在细节上差异巨大。比如 Allegro 导出的 DXF 可能只有顶层信息Protel 导入 DXF 时图纸比例会乱这些在热词里都能看到真实用户在搜的问题。我实际遇到过一个典型案例客户给了一批图纸后缀是 .dwg但用 AutoCAD 打开正常用 LibreCAD 打开就报错用 FreeCAD 导入则丢失了所有标注。后来排查发现这批图纸是用某个国产 CAD 软件保存的虽然扩展名是 .dwg但内部结构并不完全符合 AutoCAD 的标准。这种“伪 DWG”在工程现场非常常见。2.2 解析库的选择决定了你后面能走多远如果你要在程序里读 CAD 图纸绕不开几个选择直接用 Autodesk 的 RealDWG需要授权费用不低、用 ODAOpen Design Alliance的 Teigha/Drawings SDK、用开源的 libdxfrw 或 LibreCAD 的解析模块、或者走 OpenCascade 这条路。OpenCascade 本身不是专门做 DWG/DXF 的它是一个几何建模内核擅长的是 BRep、STEP、IGES 这类格式。热词里有一条“【cpython土木4】dwg图纸读取到opencascade”这其实反映了很多人的思路先把 DWG 转成 DXF再用 OpenCascade 读 DXF 里的几何信息。但这里有个关键问题——OpenCascade 读 DXF 的能力有限它主要关注几何实体对图层、标注、块引用、文字样式这些工程语义信息支持很弱。我自己的经验是如果你的目标只是提取几何轮廓做后续计算OpenCascade 够用但如果你要保留图纸的完整工程语义比如图层结构、标注关联、块定义那必须用专门的 DWG/DXF 解析库。ODA 的 SDK 在这方面最完整但授权费用对小团队来说是个门槛。libdxfrw 免费但对新版本 DXF 的支持有限遇到复杂图纸容易丢数据。这里给一个实际的选型对照表是我在几个项目里踩坑之后总结的方案优势劣势适用场景ODA Drawings SDK格式支持最全语义保留完整商业授权费用高企业级产品需要完整读写RealDWG与 AutoCAD 兼容性最好授权贵绑定 Autodesk 生态深度集成 AutoCAD 的场景libdxfrw开源免费轻量新版本支持弱复杂图纸易丢数据简单几何提取内部工具OpenCascade几何处理能力强CAD 语义支持弱需先转格式几何计算、模型重建FreeCAD 解析模块开源可定制性能一般依赖 Python 环境原型验证小批量处理选型的时候不要只看“能不能读”要看“读完之能保留多少信息”。很多项目死在第二步读进来了但图层没了、标注散了、块引用变成了一堆散线后面 AI 再聪明也没法在垃圾数据上做出正确判断。2.3 坐标系统和单位最容易被忽略的致命细节图纸里的坐标从来不是简单的 x、y、z。CAD 图纸可能使用世界坐标系WCS或用户坐标系UCS可能有不同的插入基点可能经过多次平移旋转缩放。更麻烦的是单位——有的图纸单位是毫米有的是英寸有的干脆没有单位定义。我见过一个项目AI 模型识别出图纸里某个区域的尺寸标注是“100”然后自动生成了一个“100 毫米”的零件。结果实际图纸单位是英寸做出来的东西小了 25 倍。这种错误在 Demo 里永远不会出现因为 Demo 用的都是精心挑选的、格式规范的图纸。但工程现场拿到的图纸可能来自十几个不同的设计院、不同的年代、不同的软件单位混乱是常态。处理这个问题没有捷径必须在解析阶段就建立一套单位推断和坐标归一化的逻辑。我的做法是先读图纸的头部信息看有没有单位定义如果没有就看标注的数值范围和常见工程尺寸做推断再不行就让用户手动确认。这个过程很土但比事后返工便宜得多。3. AI 模型在 CAD 语境下的能力边界3.1 视觉识别图纸和识别自然图片是两回事现在很多团队的第一反应是用视觉大模型去“看”图纸识别里面的图元、标注、符号。这个思路在 Demo 阶段往往效果不错因为演示用的图纸通常清晰、规范、图元简单。但工程图纸的复杂度完全不是一个量级。一张典型的机械装配图可能包含几百个零件、上千条线段、几十个图层、大量的块引用和标注。视觉模型在这种密度下会出现严重的漏检和误检。更关键的是CAD 图纸是矢量数据本身就包含了精确的几何信息用像素级的视觉模型去识别等于把精确数据降维成图像再猜回来信息损失巨大。我试过用视觉模型识别图纸里的焊缝符号在简单图纸上准确率能到 80% 以上但换到复杂装配图就掉到 40% 以下。后来改成直接从 DXF 里解析块引用和属性文字准确率直接到 95% 以上。这个对比说明了一个核心问题在 CAD 场景里能读结构化数据就不要用视觉模型。视觉模型应该用在那些确实没有结构化数据的地方比如扫描版的老图纸、手绘草图。3.2 大模型“理解”图纸的幻觉问题让大模型读图纸内容然后生成修改建议这个方向听起来很美好。但实际用下来最大的问题是幻觉。模型会“看到”图纸里不存在的东西或者对图纸内容做出错误推断。比如你问模型“这张图纸里的轴承型号是什么”它可能会根据图纸里某个标注的文字片段编出一个看起来合理但实际不存在的型号。在聊天场景里这种幻觉可能只是让人哭笑不得但在工程场景里一个错误的型号可能导致采购错误、装配失败、甚至安全事故。我现在的做法是大模型只做“解释”和“建议”不做“决策”。所有从图纸里提取的关键信息必须经过结构化解析验证不能直接采信模型的输出。模型可以帮你把一段复杂的标注文字翻译成通俗解释可以帮你总结图纸的技术要求但具体到尺寸、型号、材料这些硬信息必须回到原始数据去核对。3.3 从“能聊”到“能干活”之间的鸿沟热词里有很多关于 AI 聊天、AI Agent 的内容这说明大家很自然地把对话式 AI 的能力往 CAD 场景里迁移。但 CAD 操作和聊天有一个本质区别聊天允许模糊CAD 不允许。你说“帮我把这个图改一下”人可以理解你的意图但 AI 需要知道改哪里、改成什么、用什么命令、在哪个图层、是否影响关联标注。这些信息在自然语言里往往是缺失的需要大量的上下文和领域知识来补全。我见过一个团队做了一个“用自然语言操作 CAD”的 Demo演示的时候说“把这个圆放大一点”然后圆确实变大了。但实际用的时候用户说“把这个孔改大”AI 就懵了——哪个孔改多大是直径还是半径改了之后关联的标注要不要更新阵列里的其他孔要不要跟着改这些问题的本质是CAD 操作是一个精确的、有状态的、有依赖关系的流程而自然语言是模糊的、无状态的、缺乏依赖描述的。要弥合这个鸿沟需要的不只是一个更强的模型而是一整套领域特定的交互设计和状态管理机制。4. 工具链集成那些 Demo 里不会出现的脏活4.1 文件格式转换的连环坑在实际工程里你很少能直接在原始格式上操作。更多时候流程是这样的客户给 DWG你需要转 DXF 给解析库解析完生成中间数据可能要转成 STEP 给几何内核处理完再转回 DXF最后转成 DWG 交付。每一次转换都可能丢信息、改坐标、变图层。热词里有一条“exb 转 dwg 转换器”还有“dwg 转 shp”这些真实需求背后都是格式转换的痛苦。EXB 是 CAXA 的格式SHP 是 GIS 格式这些转换在工程里很常见但每一个转换环节都需要验证和补偿。我的经验是每增加一次格式转换就要增加一轮验证。验证的内容包括图层是否保留、坐标是否偏移、标注是否关联、块引用是否完整、文字样式是否丢失。这些验证很枯燥但不做的话问题会在最后交付的时候集中爆发。4.2 字体和线型小问题引发大故障CAD 图纸里的字体和线型是另一个容易被忽略的坑。图纸里用了某个特殊字体你的环境里没有打开就显示乱码或者问号。线型文件缺失虚线变实线虚线变实线在机械图里可能意味着完全不同的含义。热词里“cad 出现放射状乱线”这个问题很多时候就是线型或显示驱动的问题。还有“cad 里面 f 命令用不了”这种看起来是软件故障的问题实际可能是插件冲突或者配置损坏。在 AI 处理流程里字体和线型问题会更隐蔽。因为 AI 通常不关心显示效果它关心的是数据。但如果字体缺失导致文字解析错误AI 拿到的就是错误的数据。我现在的做法是在解析阶段就把字体和线型信息单独提取出来建立映射表遇到缺失的字体就用标准字体替代同时记录替换日志方便后续追溯。4.3 版本兼容性一个永远绕不开的话题AutoCAD 每年一个版本每个版本的文件格式都有细微变化。你的解析库可能支持到 2018但客户用的是 2024 保存的图纸。ODA 的 SDK 更新相对及时但开源库往往滞后。更麻烦的是有些软件保存的 DWG 虽然扩展名一样但内部结构有差异。比如“cad admint.dll”这个热词反映的是某些 CAD 软件在加载特定 DLL 时出现的问题这类问题在纯 AutoCAD 环境里不会出现但在多软件混用的工程现场很常见。我的建议是在项目初期就建立一个“图纸样本库”收集各种来源、各种版本、各种软件的图纸作为回归测试的基础。每次更新解析逻辑都跑一遍样本库看有没有新的失败案例。这个做法很笨但能帮你提前发现大部分兼容性问题。5. 工程落地的现实约束人、流程、环境5.1 设计人员不会为了 AI 改变工作习惯这是我在项目里体会最深的一点。你可以做出一个很智能的 AI 工具但如果它要求设计人员改变现有的工作流程大概率推不动。设计人员用 CAD 已经用了十几年快捷键、命令、图层规范、打印样式都是肌肉记忆。你让他为了用你的 AI 功能先导出 DXF、再上传、再等结果、再下载、再导入这个流程在 Demo 里演示没问题在实际工作里没人会坚持用。真正能落地的方案必须是嵌入现有流程的。比如做成 CAD 的插件在原有界面里增加一个按钮或者做成后台服务设计人员保存图纸的时候自动触发处理。任何需要额外步骤的方案都要慎重评估用户的接受度。5.2 数据安全和图纸保密工程图纸往往涉及商业机密很多设计院和企业对图纸外传有严格限制。如果你的 AI 方案需要把图纸上传到云端处理很多客户会直接拒绝。这不是技术问题是合规和信任问题。我现在的做法是优先考虑本地化部署。模型可以小一点速度可以慢一点但数据不出本地。如果必须用云端能力也要做数据脱敏把敏感信息项目名称、客户信息、具体尺寸替换掉之后再处理。5.3 错误成本的不对称性在互联网产品里一个功能有 5% 的错误率可能可以接受因为用户可以快速修正。但在工程领域一个错误的图纸可能导致巨大的返工成本甚至是安全事故。这种错误成本的不对称性决定了 AI 在 CAD 场景里的容错空间非常小。这意味着你不能只追求“大部分情况正确”你必须设计一套机制来处理“少数情况错误”。比如AI 的输出必须经过人工确认才能生效关键操作要有回滚机制系统要能标记出低置信度的结果提醒用户重点检查。6. 几条实际走通过的路子6.1 从“辅助”而不是“自动”开始我参与过的最成功的项目定位都是“辅助”而不是“自动”。AI 不直接修改图纸而是给出建议、标记问题、提供参考。设计人员仍然是决策者AI 只是帮他更快地发现问题。比如一个图纸检查工具AI 自动扫描图纸找出可能的问题标注缺失、图层错误、线型不一致、尺寸矛盾。然后生成一份检查报告设计人员逐条确认。这个工具没有“自动修复”功能但设计人员用得很顺手因为它确实帮他们省了时间又没有引入风险。6.2 把 AI 用在“非精确”环节CAD 流程里有很多环节其实不需要精确的几何计算比如图纸分类、相似图纸检索、技术要求文本理解、设计规范问答。这些环节 AI 可以发挥很大作用而且错误成本相对较低。我做过一个“相似图纸检索”的功能用图纸的图层结构、块引用、标注特征做向量化然后做相似度匹配。设计人员要画一个新零件的时候可以先搜一下有没有类似的旧图纸可以参考。这个功能不涉及精确修改但实际使用频率很高。6.3 建立“人在回路”的反馈机制AI 的输出不可能 100% 正确关键是建立一个反馈闭环。用户在使用过程中标记错误、修正结果这些反馈数据可以用来持续优化模型和规则。我在项目里做了一个简单的反馈按钮用户觉得 AI 的建议不对可以点一下“不准确”然后选择原因。这些数据积累起来之后能很清楚地看到模型在哪些场景下容易出错后续优化就有了方向。7. 一些具体的实操建议如果你正在或者准备做 AI CAD 的项目下面这些建议可能对你有用。第一先把图纸解析这一关过掉。不要急着上 AI先确保你能稳定、完整地读取目标图纸的几何和语义信息。这一步做不好后面全是空中楼阁。第二建立图纸样本库。收集至少 50 张不同来源、不同版本、不同复杂度的图纸作为开发和测试的基础。每次改动都跑一遍确保没有回归。第三明确 AI 的边界。哪些环节用 AI哪些环节用规则哪些环节必须人工。不要试图用 AI 解决所有问题工程场景里规则引擎往往比模型更可靠。第四优先本地化部署。如果客户对数据安全有要求云端方案基本没戏。本地化部署虽然麻烦但能打开更多客户的门。第五从辅助功能切入。不要一上来就做自动修改先做检查、建议、检索这类低风险功能建立信任之后再逐步深入。第六重视格式转换的验证。每一次格式转换都要有验证环节确保关键信息没有丢失。这个工作很枯燥但能避免后面的大坑。第七设计好错误处理机制。AI 一定会出错关键是出错之后怎么办。要有回滚、有确认、有日志让用户能放心使用。8. 关于工具选型的一点个人体会最后聊几句工具选型。FreeCAD 在开源 CAD 里算是比较活跃的它的 Python API 对于做原型验证很方便。但 FreeCAD 的 DWG/DXF 支持依赖外部库实际使用中会遇到各种兼容性问题。如果你的项目需要处理大量真实工程图纸FreeCAD 可能不是最终方案但作为原型工具是合格的。OpenCascade 在几何处理上很强但它的学习曲线陡峭文档也不算友好。如果你的团队没有几何内核的经验上手会比较痛苦。建议先从简单的几何操作开始逐步深入。商业 SDK 虽然贵但在格式支持和稳定性上确实有优势。如果项目预算允许而且对兼容性要求高ODA 的 SDK 是值得考虑的。省下来的调试时间往往比授权费用更值钱。至于 AI 模型本身我的建议是不要迷信“更大更强”。在 CAD 场景里一个针对特定任务微调的小模型往往比通用大模型更实用。关键是数据质量和任务定义而不是模型参数量。这条路不好走但走通了价值很大。希望这些经验能帮你少踩几个坑。