1. 为什么“AI CAD”的Demo看起来很美1.1 一个典型Demo的诞生过程先说说我见过最多的那类演示。打开一个网页上传一张户型图或者机械零件的照片点一下“生成CAD”几秒钟后屏幕上出现一堆线条看起来像模像样。再点一下“导出DXF”下载一个文件用CAD软件打开——确实有东西虽然尺寸不对、图层混乱、线条断开但外行看热闹觉得“AI已经能画图了”。这种Demo的技术栈通常很直接用视觉模型做图像识别提取边缘和轮廓然后把像素坐标映射到CAD坐标系最后用ezdxf或者dxfgrabber这类Python库写出DXF文件。整个流程跑通只需要几百行代码一个周末就能做出来。问题在于这个流程和真正的工程设计之间隔着一道巨大的鸿沟。我试过用类似的方法处理一张简单的法兰盘图纸。AI识别出来的圆孔位置偏差了2-3毫米对于演示来说无所谓但对于要上机床加工的零件来说这个误差直接导致报废。Demo展示的是“能生成线条”工程需要的是“能生成正确的、可制造的、符合标准的几何体”。这两者之间的差距就是本文要拆解的核心。1.2 工程场景的真实需求是什么在制造业、建筑业、电子设计这些领域CAD图纸不是一张画而是一份工程契约。它包含了几何信息、尺寸公差、材料标注、工艺要求、装配关系甚至还有版本管理和审批流程。一张图纸从设计到投产要经过校对、审核、批准多个环节每个环节都有明确的规范。我接触过的机械设计团队他们对AI辅助的期待其实很具体能不能自动标注尺寸能不能检查干涉能不能根据装配关系自动生成爆炸图能不能把二维图纸自动转成三维模型这些需求背后有一个共同点——AI需要理解工程语义而不仅仅是识别像素。举个例子一张图纸上画了两条平行线间距标注为50毫米。人类工程师看到这个知道这是一个槽宽需要根据配合件的尺寸来确定公差等级。AI看到这个如果只做图像识别它只知道“这里有两根线距离是某个像素值”。要让它理解“这是一个配合尺寸需要查公差表”就需要把工程知识注入到模型里。这就是Demo和工程之间的第一道坎。1.3 为什么“能跑通”不等于“能用”很多团队在立项的时候目标定的是“做一个AI生成CAD的Demo”。这个目标本身没问题但问题在于Demo的验收标准太低了。只要生成的DXF文件能被CAD软件打开就算成功。至于里面的线条是否闭合、图层是否规范、尺寸是否准确、标注是否完整这些都不在Demo的考核范围内。我见过一个项目团队花了三个月做出了一个“AI自动生成建筑平面图”的原型。演示的时候输入一段文字描述“三室两厅一厨一卫”输出一张平面图。看起来很棒。但实际拿去给设计师用的时候问题全暴露了墙体厚度不对、门窗位置不合理、承重墙和隔墙没有区分、尺寸标注缺失、图层命名混乱。设计师说了一句话让我印象很深“这个东西生成的图我改它的时间比我自己画还长。”这就是核心矛盾Demo追求的是“从0到1”的惊艳感工程追求的是“从60到90”的可靠性。AI在Demo里做的是“无中生有”在工程里需要做的是“锦上添花”或者“提效减负”。两者的评价体系完全不同。2. 拆解AI与CAD结合的核心技术难点2.1 数据格式的坑DXF和DWG远比你想象的复杂很多人以为DXF就是一个文本格式的图纸文件读进来就是一堆线段和圆弧。实际上DXFDrawing Exchange Format是Autodesk在1982年推出的交换格式经过四十多年的迭代包含了大量的实体类型、属性字段和扩展数据。我统计过一个中等复杂度的机械零件DXF文件里面可能包含LINE、ARC、CIRCLE、POLYLINE、LWPOLYLINE、SPLINE、ELLIPSE、INSERT、BLOCK、ATTRIB、DIMENSION、HATCH、TEXT、MTEXT等二十多种实体类型。更麻烦的是DXF有ASCII和二进制两种格式还有不同的版本号R12、R13、R14、2000、2004、2007、2010、2013、2018。不同版本之间的实体定义有差异有些旧版本不支持新实体。我遇到过一个问题用某个开源库读取一个R12版本的DXF文件里面的POLYLINE实体被解析成了LINE的集合丢失了多段线的拓扑关系。这个bug在Demo里看不出来因为线条位置是对的但在工程里就是致命的——后续的偏移、修剪、倒角操作全部失效。DWG格式就更封闭了。它是Autodesk的专有格式没有公开的完整规范。开源库如LibreDWG、ODAOpen Design Alliance的Teigha库可以读取但兼容性参差不齐。我试过用LibreDWG读取一个包含动态块的DWG文件结果动态块的参数丢失了块引用变成了静态的。对于需要参数化设计的场景这个损失是不可接受的。实操心得如果你的项目需要处理DWG文件优先考虑用ODA的SDK或者商业库。开源方案在简单场景下能用但遇到复杂图纸尤其是包含自定义实体、动态块、外部参照的时坑会非常多。DXF相对开放但也要注意版本兼容性建议统一转成R2018或R2013格式再处理。2.2 几何理解的鸿沟从像素到参数化特征AI模型尤其是视觉模型处理CAD图纸时输入通常是栅格图像。模型看到的是像素矩阵输出的是分割掩码或者关键点。但CAD的核心是参数化几何——一条线由起点、终点、图层、线型、颜色定义一个圆由圆心、半径、图层定义一个尺寸标注由测量点、标注类型、公差值定义。从像素到参数化特征中间需要经过“矢量化”和“语义化”两个步骤。矢量化是把栅格图像转成矢量线条这个技术相对成熟OpenCV的findContours、HoughLinesP都能做。但语义化就难了——你需要判断哪些线条是轮廓、哪些是中心线、哪些是尺寸线、哪些是剖面线。这些判断依赖工程知识不是单纯的图像处理能解决的。我做过一个实验拿一张标准的机械零件图纸用OpenCV提取所有线段然后让一个工程师标注每条线段的语义。结果发现即使是同一个零件不同工程师的标注也有差异。比如一条线有人标为“轮廓线”有人标为“过渡线”有人标为“辅助线”。这说明语义标注本身就有模糊性让AI去学习这种模糊性难度可想而知。更麻烦的是CAD图纸里的几何元素往往不是孤立的。一个孔的位置由中心线决定中心线又由基准面决定基准面又由装配关系决定。这种约束网络是工程图纸的灵魂但AI模型很难从像素中直接恢复出来。Demo里生成的线条是“散装”的没有约束关系改一个尺寸其他相关尺寸不会联动更新。这在工程里就是不可用的。2.3 工程语义的缺失AI不懂“公差”和“基准”公差是机械设计的核心概念之一。一个尺寸标注为“50±0.05”意味着加工出来的零件尺寸必须在49.95到50.05之间。这个公差值不是随便定的它取决于配合性质、加工能力、成本控制。AI如果只做图像识别它能看到“50”和“±0.05”这两个文本但它不理解这个公差背后的工程含义。我见过一个AI辅助标注的项目模型能自动识别图纸上的尺寸线然后生成标注。但生成的标注全部是“50”这种基本尺寸没有公差、没有基准、没有形位公差。工程师拿到之后需要手动补全所有公差信息。这个工作量比重新标注还大因为工程师需要先理解设计意图再查公差表最后逐个填写。基准Datum是另一个AI难以理解的概念。在工程图纸中基准是测量和加工的参考通常用带字母的方框标注。一个位置公差“◎0.1 A B C”表示这个特征相对于基准A、B、C的位置度公差是0.1毫米。AI要理解这个需要知道A、B、C分别对应哪个面或哪条轴线还需要知道位置度的计算方法。这些知识在CAD软件里是内置的但AI模型里没有。注意事项如果你的AI项目涉及尺寸标注或公差不要试图让模型“学会”公差表。公差表是标准化的、确定性的知识用规则引擎或者查表的方式实现更可靠。AI应该负责识别“这里需要标注”然后调用规则引擎生成具体的公差值。把确定性的工作交给代码把不确定性的工作交给AI这个分工原则很重要。2.4 从FreeCAD看开源CAD的AI集成困境FreeCAD是一个优秀的开源参数化CAD软件支持Python脚本扩展。理论上你可以用Python调用FreeCAD的API实现AI辅助设计。我试过用FreeCAD的Part模块和Draft模块做自动化建模确实能跑通。但问题在于FreeCAD的API文档不够完善很多功能需要看源码才能理解。而且FreeCAD的几何内核是OpenCASCADE这个内核功能强大但学习曲线陡峭。我尝试用FreeCAD做一个“AI生成齿轮”的功能。思路是用户输入模数、齿数、压力角AI生成齿轮的渐开线轮廓然后拉伸成三维实体。结果发现FreeCAD没有内置的齿轮工具需要手动计算渐开线点然后用B样条曲线拟合。这个计算过程涉及渐开线方程、基圆、齿顶圆、齿根圆参数一多就容易出错。而且FreeCAD的布尔运算在复杂齿轮上经常失败需要调整容差。这个经历让我意识到开源CAD软件在AI集成方面有一个天然劣势几何内核的稳定性和API的易用性不如商业软件。商业软件如SolidWorks、CATIA、NX都有成熟的二次开发接口文档齐全技术支持到位。开源软件虽然免费但隐性成本很高。如果你的项目需要快速落地选择商业软件的API可能更划算。3. 落地路径的实操探索3.1 从“辅助”而不是“替代”开始我见过太多项目一上来就想做“AI自动设计”结果做了一年还在Demo阶段。更务实的路径是先做辅助工具解决工程师的某个具体痛点。比如自动识别图纸中的文字并提取到Excel自动检查图纸中的尺寸标注是否遗漏自动将二维图纸中的轮廓提取出来生成简单的三维拉伸体自动对比两个版本的图纸高亮差异部分这些功能的技术难度远低于“自动设计”但实用价值很高。我认识一个团队他们做了一个“AI图纸比对”工具专门用于工程变更管理。工程师上传新旧两版图纸工具自动标出所有差异包括尺寸变化、标注增减、图层修改。这个工具的技术核心是DXF解析和几何比对AI只用在文字识别上。但它在实际项目中非常受欢迎因为工程变更管理是刚需而且人工比对容易出错。实操心得辅助工具的成功标准是“帮工程师省时间”。如果你的工具能让工程师每天少加班半小时他们就会用。如果你的工具需要工程师花半小时学习怎么用他们就不会用。所以辅助工具的设计原则是零学习成本、无缝集成到现有工作流、结果可验证。3.2 数据管道的搭建从DWG到可训练数据AI模型需要数据但CAD图纸的数据不是现成的。你需要搭建一个数据管道把DWG/DXF文件转成模型能吃的格式。这个管道通常包括格式转换用ODA或LibreDWG把DWG转成DXF统一版本。实体解析用ezdxf解析DXF提取所有实体及其属性。几何规范化把不同坐标系、不同单位的图纸统一到标准坐标系和单位。语义标注人工或半自动地标注实体的语义轮廓、中心线、尺寸线等。特征提取把几何实体转成特征向量用于模型训练。这个管道里最耗时的是第4步。我做过一个统计一张中等复杂度的机械图纸人工标注语义需要30-60分钟。如果要标注1000张图纸就是500-1000小时的工作量。这个成本很多团队承受不起。我的建议是先用规则做半自动标注再用AI做主动学习。规则可以覆盖80%的常见情况比如“图层名为‘轮廓’的实体标为轮廓线”“颜色为红色的实体标为中心线”。剩下的20%用主动学习让模型挑出它最不确定的样本人工标注这些样本然后重新训练。这样可以把标注成本降低到原来的三分之一。3.3 模型选型为什么通用大模型不够用我试过用GPT-4V和Claude 3来理解CAD图纸。结果发现这些通用大模型在“看图说话”方面很强能描述图纸的大致内容但在“精确几何”方面很弱。比如你问它“这个圆的直径是多少”它可能会说“大约50毫米”但实际标注是“Φ48”。你问它“这两条线是否平行”它可能会说“看起来平行”但实际有0.5度的夹角。通用大模型的问题在于它们的训练数据主要是自然图像和文本CAD图纸在训练集中占比极低。而且CAD图纸的“语言”是几何和工程符号不是自然语言。模型没有学过这些符号的语法自然无法准确理解。更靠谱的方案是用通用大模型做高层理解用专用模型做低层几何处理。比如用GPT-4V识别图纸的类型机械、建筑、电气、提取标题栏信息、理解设计意图用专门的几何模型如基于PointNet或GNN的模型处理线条、圆弧、尺寸标注的精确识别。两者结合各司其职。我试过一个组合方案先用OpenCV做边缘检测和直线拟合得到精确的几何参数然后把几何参数和原始图像一起送给GPT-4V让它判断这些几何元素的关系哪些是轮廓、哪些是中心线。这个方案的效果比纯用GPT-4V好很多因为几何参数是精确的大模型只需要做语义判断。3.4 一个可复现的最小可行方案如果你现在想动手做一个AICAD的落地项目我建议从下面这个最小可行方案开始目标自动从二维机械图纸中提取所有圆孔的位置和直径生成一个CSV表格。技术栈Python 3.10ezdxf解析DXF文件OpenCV图像预处理如果只有PDF或图片PaddleOCR识别尺寸标注文字pandas生成CSV步骤用ezdxf读取DXF文件遍历所有CIRCLE和ARC实体。对于每个圆提取圆心坐标和半径。用ezdxf的query功能找到与圆关联的DIMENSION实体提取标注文字。如果标注文字是“Φ50”则直径为50如果是“R25”则半径为25。把结果写入CSV包含圆心X、圆心Y、直径、所在图层。这个方案的技术难度不高但实用价值很高。我把它给一个做机加工的朋友用他说以前手动抄孔位要花半小时现在几秒钟就搞定了。虽然只解决了“抄数”这一个环节但已经帮他省了不少时间。常见问题有些图纸的圆是用LWPOLYLINE画的比如用多段线拟合的圆不是标准的CIRCLE实体。这时候需要判断多段线是否闭合、是否近似圆形。我的做法是计算多段线的外接矩形如果长宽比接近1且顶点数大于16就认为是圆。这个方法不是100%准确但能覆盖大部分情况。4. 常见问题与排查技巧实录4.1 DXF读取时的坐标系混乱问题DXF文件里的坐标系有世界坐标系WCS和用户坐标系UCS之分。很多图纸在绘制时使用了UCS但保存时没有正确转换。用ezdxf读取时默认返回的是WCS坐标但有些实体的坐标是UCS下的。如果不做转换提取出来的坐标就是错的。排查方法检查DXF文件的$UCSORG和$UCSXDIR变量。如果这些变量不是默认值说明图纸使用了UCS。ezdxf提供了ucs模块可以用ucs.transform()方法做转换。我踩过一次坑一个建筑图纸的UCS原点在建筑角点而不是世界原点导致提取出来的所有坐标都偏移了。后来加了UCS转换才解决。4.2 文字识别中的字体和编码问题CAD图纸里的文字可能使用SHX字体AutoCAD专用字体或TrueType字体。SHX字体是矢量字体OCR识别难度大。而且DXF文件里的文字编码可能是GBK、UTF-8、ANSI等如果编码判断错误提取出来的就是乱码。我的做法是先用ezdxf的doc.header[$DWGCODEPAGE]获取代码页然后用对应的编码解码。如果代码页是ANSI_936简体中文就用gbk解码。如果还是乱码就尝试utf-8和latin-1。对于SHX字体如果OCR识别率低可以考虑用CAD软件把文字炸开成线条然后做形状匹配。这个方法比较重但准确率高。4.3 几何比对中的容差设置做图纸比对时两条线是否“相同”取决于容差。容差设得太小微小的绘制误差会导致误判容差设得太大真正的差异会被忽略。我试过用0.001毫米的容差结果发现同一张图纸在不同软件里保存后线条端点会偏移0.0001毫米导致比对失败。后来把容差调到0.01毫米误判率大幅下降。对于角度容差一般设为0.1度。对于半径容差设为0.01毫米。这些值不是固定的需要根据图纸的精度要求调整。我的经验是先统计一批“相同”图纸的几何差异分布然后取95%分位数作为容差。这样既能覆盖正常的绘制误差又能捕捉真正的设计变更。4.4 性能优化大图纸的处理策略一张大型建筑图纸可能有几十万个实体用ezdxf全部加载到内存会占用几个GB。我的优化策略是用ezdxf的iterdxf方法流式读取不要一次性加载。只提取需要的实体类型忽略HATCH、SPLINE等复杂实体。用空间索引如R-tree加速几何查询。对于比对任务先用包围盒做粗筛只对包围盒重叠的实体做精确比对。我处理过一张包含50万个实体的总图用流式读取加空间索引内存占用控制在500MB以内处理时间从原来的20分钟降到2分钟。4.5 常见问题速查表问题现象可能原因排查方法解决方案提取的坐标全部偏移UCS未转换检查$UCSORG变量用ucs.transform()转换文字显示为乱码编码判断错误检查$DWGCODEPAGE用对应编码解码圆孔识别遗漏圆用多段线绘制检查实体类型增加多段线圆检测逻辑比对结果误报多容差设置过小统计几何差异分布调整容差到95%分位数处理速度慢一次性加载所有实体检查内存占用改用流式读取布尔运算失败几何容差冲突检查实体间距调整容差或简化几何标注文字提取不全标注是块引用检查INSERT实体遍历块定义提取属性图层信息丢失DXF版本不兼容检查版本号统一转成R2018格式最后分享一个小技巧如果你需要批量处理DWG文件但又不想装AutoCAD可以用ODA的File Converter工具。它支持命令行调用能把DWG批量转成DXF速度比LibreDWG快很多而且兼容性更好。这个工具是免费的注册ODA账号就能下载。我用它处理过上千个DWG文件转换成功率在99%以上。唯一需要注意的是它不支持动态块的参数保留如果你的图纸大量使用动态块转换后需要手动检查。