AI遇上CAD：从Demo到工程落地，DXF/DWG解析与校验的务实架构

1. 从一堆炫酷 Demo 到工程落地中间隔了什么过去一年多我参与过三个把 AI 能力往 CAD 流程里塞的项目从最开始的“输入一句话生成一张图纸”的演示到后来老老实实做图纸解析、批量改图、参数校验踩的坑比写过的代码还多。标题里那句“Demo 满天飞工程却走不通”几乎是我这一年最真实的体感。你在网上能看到大量让人眼前一亮的演示一句话生成三维模型、截图直接转成 DXF、AI 自动标注公差视频里丝滑得不行。但真把它放到一个需要交付、需要复用、需要跟同事协作的工程环境里十有八九会在某个环节卡死。这篇文章想聊的不是“AI 能不能画图”这种泛泛的话题而是把范围收窄到一个具体问题当 AI 遇上 CAD尤其是以 DXF、DWG 这类工程图纸格式为核心载体时为什么演示能跑通、工程却走不通以及一个务实的从业者应该怎么拆解这件事。关键词里出现的 DXF、DWG、FreeCAD、OpenCascade基本就是这条链路上绕不开的几个节点。适合谁看如果你是把 AI 往设计、制造、土木、专利辅助这些方向落地的开发者或者是被“AI 自动出图”吸引、想自己动手试一把的工程师这篇内容应该能帮你少走几个月弯路。我先把结论摆出来AI 在 CAD 场景里真正难的不是“生成”而是“理解 校验 可复现”。生成一张看起来对的图很容易难的是这张图在几何上闭合、在图层上规范、在单位上正确、在后续被别的软件打开时不炸。演示阶段大家默认忽略这些工程阶段这些恰恰是全部。下面我按自己实际趟过的顺序一层层拆。2. 为什么“一句话生成图纸”的 Demo 看着惊艳落到工程就散架2.1 演示环境天然屏蔽了 CAD 最脏的那部分任何一段 AI 生成 CAD 的演示背后都有一个被精心挑选过的输入。要么是干净的轮廓描述要么是一张线条清晰、图层规整的样例图。但真实的工程图纸是什么样我手上经手过的一批 DWG同一个项目里图层命名有中文、有拼音、有英文缩写混着来有的线画在0层有的画在自定义层标注样式被改过七八轮甚至还有从别的软件导进来、单位是英寸但没人标注的情况。演示里那种“输入一句话输出一张图”的流程第一步就假设了输入是干净的而这个假设在工程里几乎从不成立。更关键的是演示通常只验证“视觉上像不像”。你把生成的图截图发出来大家看着像那么回事就鼓掌了。但工程交付要的是几何正确性线段是否首尾相接、圆弧是否闭合、多段线是否自交、图层是否符合企业标准、单位是否统一。这些在截图里根本看不出来只有把文件丢进 CAD 里放大、做布尔运算、尝试偏移和修剪问题才会暴露。我见过一个生成结果视觉上是个完美的法兰盘结果所有圆弧的圆心都偏了 0.3 毫米肉眼完全看不出但一加工就是废件。2.2 大模型擅长“像”不擅长“精确”这里要讲清楚一个底层原因。当前主流的大模型本质是在做概率性的序列生成它输出的是一串“看起来最可能”的 token。而 CAD 图纸要求的是确定性的几何约束这条线和那条线必须平行这个圆的半径必须等于那个尺寸这个角度必须是 90 度。这两件事在数学性质上是冲突的。模型可以生成一段描述“一个直径 50 的圆”但它没法保证在 DXF 里这个圆的圆心坐标和相邻特征严格对齐因为它压根不是按几何约束在算而是按“下一个数字最可能是什么”在猜。这就解释了为什么很多 Demo 在简单形状上表现很好一旦形状复杂、约束一多就开始飘。我自己的做法是绝不让模型直接输出几何坐标而是让它输出结构化的参数或约束描述再由确定性的几何内核去生成实际图形。比如模型只负责判断“这里需要一个 M8 的螺纹孔位置在四个角”具体坐标由脚本根据板件尺寸和边距规则算出来。这样模型负责它擅长的语义理解几何内核负责它擅长的精确计算各司其职。这个思路听起来朴素但它是把 Demo 往工程推的第一步也是最关键的一步。2.3 一个真实的翻车现场说个具体的。早期我做过一个“根据文字描述生成简单零件轮廓”的原型输入“一个 100x60 的矩形板四角倒 R5 圆角中间开一个直径 20 的圆孔”。模型生成的 DXF 打开一看形状完全正确我当时还挺得意。结果同事拿去用发现这个 DXF 里所有图元都在默认图层线宽是默认值而且圆孔和矩形是两条独立图元没有做任何关联。他想改板子尺寸得手动一个个改因为没有任何参数化关系。更离谱的是文件单位是“无单位”导入到另一个软件里被默认当成英寸整个零件放大了 25.4 倍。这次翻车让我彻底明白工程要的不是一张“图”而是一个“可维护的模型”。图是给人看的模型是给流程用的。Demo 交付的是图工程交付的是模型。这个认知转变之后我后面所有的方案设计都围绕“可维护”来做而不是围绕“生成得漂亮”来做。3. DXF 与 DWGAI 落地 CAD 时最先撞上的两堵墙3.1 DXF 是文本但它不是给人读的文本很多人一听 DXF 是文本格式第一反应是“那好办直接读文本、改文本就行”。我一开始也这么想直到我打开一个真实的 DXF 文件。它确实是 ASCII但结构是一堆GROUP CODE VALUE的配对比如0后面跟SECTION2后面跟ENTITIES10、20、30分别代表 X、Y、Z 坐标。一个稍微复杂点的图纸几万个图元几十万行这种配对人眼根本没法直接读。而且 DXF 有多个版本R12、R2000、R2007、R2013 等不同版本对某些实体的编码方式还不一样比如样条曲线、椭圆弧在不同版本里的组码就有差异。所以“直接改文本”这条路在简单场景能跑稍微复杂就崩。正确的做法是用成熟的解析库把 DXF 读成内存里的对象模型操作对象再序列化回去。Python 生态里ezdxf是我用得最顺手的它能覆盖绝大多数常见实体文档也全。C 方向就是 OpenCascade 那一套配合 DXF 的读写模块。关键词里出现的“dwg 图纸读取到 opencascade”就是这个思路用 OpenCascade 做几何内核把图纸读进来变成拓扑对象再在上面做运算。这条路更重但几何能力更强适合需要做布尔、倒角、干涉检查的场景。3.2 DWG 是二进制闭源是它最大的门槛DWG 比 DXF 麻烦得多。它是二进制格式而且格式规范并不完全公开不同版本之间差异很大。这意味着你没法像 DXF 那样“读文本”必须依赖专门的库。开源世界里能比较靠谱读 DWG 的方案其实不多很多时候大家是先用某个工具把 DWG 转成 DXF再走 DXF 的流程。关键词里“dwg 转 shp”“exb 转 dwg 转换器”“librecad 打开 dwg”这些搜索本质上都是大家在找“怎么把 DWG 变成我能处理的东西”。这里有个务实的经验如果你的 AI 流程只需要读几何和图层信息优先走“DWG 转 DXF 再解析”的路线别硬啃 DWG 二进制。转换这一步会损失一些信息比如某些自定义对象、动态块的部分行为但对绝大多数几何处理任务来说够用。我自己的项目里转换环节用命令行工具批量跑转完统一进 DXF 解析管线稳定性和可维护性都比直接读 DWG 好很多。当然如果你的场景对 DWG 原生特性依赖很重那就得考虑商业库这是成本问题不是技术问题。3.3 单位、坐标系、图层三个最容易被忽略的隐形杀手我单独把这三个拎出来讲因为它们是我踩坑最多的地方而且 Demo 阶段几乎没人提。单位DXF 里有个$INSUNITS变量但大量图纸这个值是 0无单位或者干脆是错的。你按毫米算结果图纸实际是英寸所有尺寸全错。我的做法是解析时先读这个变量如果是 0 或者可疑值就根据图元坐标的数值范围做启发式判断——比如一个机械零件坐标范围在几百这个量级大概率是毫米如果只有几可能是英寸或米。这个判断不完美但比盲信变量强。坐标系图纸可能用了 UCS用户坐标系也可能有旋转和镜像。你直接读 WCS 坐标得到的可能是错的。解析时要确认实体的挤出方向和变换矩阵必要时做坐标变换。图层图层承载了语义。哪条线是轮廓、哪条是中心线、哪条是标注全靠图层区分。AI 要理解图纸第一步就是理解图层体系。但现实是图层命名五花八门我见过用图层1到图层87的也见过用颜色代替图层的。这时候就需要做图层语义映射把杂乱的图层归一到一套标准分类上这一步往往需要结合企业规范来做没有通用解。4. 把 AI 塞进 CAD 流程我实际采用的架构与取舍4.1 分层让模型只做它擅长的事经过几轮折腾我现在的架构基本固定成三层语义层大模型在这里工作负责理解自然语言需求、识别图纸里的语义信息比如判断某个区域是孔位还是槽、生成结构化的中间描述JSON 或类似格式。几何层确定性的几何内核在这里工作接收语义层的结构化描述生成精确的几何图元做布尔运算、约束求解、拓扑校验。DXF 的读写、OpenCascade 的运算都在这一层。校验层独立的规则引擎检查生成结果是否符合工程规范——图层对不对、单位对不对、有没有自交、有没有零长度线段、标注是否完整。这个分层的核心思想是把概率性的部分和确定性的部分彻底隔开。模型输出错了几何层不会跟着错因为几何层只认结构化参数几何层算错了校验层能兜住。三层之间用明确定义的接口通信任何一层出问题都能单独定位和替换。这比“让模型直接吐 DXF”要啰嗦但工程上稳得多。4.2 为什么我选 FreeCAD 做验证环境而不是纯 AutoCAD关键词里 FreeCAD 出现频率很高我自己也确实用它做了大量验证。原因很实际FreeCAD 是开源的可以脚本化Python 控制台能直接操作几何对象适合做自动化测试。我可以在 FreeCAD 里写脚本批量生成测试用例、批量校验生成结果、批量导出 DXF整个流程可以进 CI。AutoCAD 当然更强但它的自动化门槛和授权成本对个人开发者和小团队不友好。具体做法是几何层生成的对象先导出成 FreeCAD 能读的格式或者直接用 FreeCAD 的 Python API 构建在 FreeCAD 里跑一遍几何校验确认没问题再导出 DXF 交付。FreeCAD 在这里扮演的是“可信的第三方裁判”因为它的几何内核和商业软件不完全一样如果两边都能打开且几何一致说明文件本身是规范的。这个交叉验证的习惯帮我挡掉了很多“在我这儿能开、在别人那儿炸”的问题。4.3 参数化优先于直接生成前面提过我现在的原则是能参数化就参数化绝不直接生成死几何。举个例子要生成一块带孔的板我不会让模型输出一堆线段坐标而是让它输出一个参数对象板长、板宽、板厚、孔的数量、孔的直径、孔的边距规则。然后由脚本根据这些参数用几何库算出实际图元。这样做的好处是后续要改尺寸改参数就行不用重新生成而且参数本身可以被校验比如孔直径不能大于板宽错误在参数层就被拦住了。这个思路在关键词里“python 批量对 cad 修改”这个场景下特别有用。批量修改的本质就是批量改参数而不是批量改图元。你有一百张图纸要统一改某个尺寸如果图纸是参数化的改一个参数表就完事如果是死几何就得写脚本去识别、定位、替换脆弱得多。5. 图纸解析这条链路哪些环节最容易出问题5.1 从 DWG 到可处理数据的完整链路我把实际用的链路拆开讲每一步都标注容易出问题的地方DWG 转 DXF用命令行工具批量转。坑在于版本兼容老版本 DWG 转出来的 DXF 可能丢失某些实体。建议转换时指定输出为较新的 DXF 版本兼容性更好。DXF 解析用ezdxf读入。坑在于自定义实体和代理实体这些ezdxf可能读不全需要做异常捕获和日志记录把读不了的实体单独列出来人工确认。图层归一把杂乱图层映射到标准分类。坑在于映射规则需要维护新项目来了可能要加规则。我的做法是把映射规则做成配置文件不写死在代码里。几何提取把图元转成几何对象。坑在于单位换算和坐标变换前面讲过这里必须做。语义标注用 AI 或规则给几何打语义标签这是轮廓、这是孔、这是中心线。坑在于准确率AI 标注不可能 100% 对所以要有置信度机制低置信度的交给人工复核。校验与导出跑规则校验通过后导出。坑在于校验规则要覆盖企业规范这需要跟实际使用方对齐。这条链路里第 3 步和第 5 步是最需要“人”介入的也是 AI 最能帮上忙但也最容易出错的地方。我的经验是这两步一定要设计成人机协作而不是全自动。让 AI 做初筛和标注人做确认和修正修正结果再反馈回去优化规则或提示词。全自动听起来美好但在工程场景里一次错误标注可能导致整批图纸报废代价太高。5.2 一个具体的解析踩坑样条曲线和椭圆弧说个技术细节。DXF 里的样条曲线SPLINE和椭圆弧ELLIPSE在解析时特别容易出问题。样条曲线有控制点、节点向量、权重不同软件导出的参数化方式可能不同你按一种方式解析在另一种软件里可能形状就变了。椭圆弧有长轴、短轴、起始角、终止角角度定义方式也有坑。我遇到过一批图纸椭圆弧在 AutoCAD 里显示正常用ezdxf读出来再导出形状就偏了原因是角度参数的参考系不一致。解决办法是对这类复杂曲线解析后一定要做几何验证而不是盲信解析结果。具体做法是采样曲线上的若干点跟原始文件里对应位置的点做比对偏差超过阈值就报警。这个验证步骤在 Demo 里没人做但工程里必须做因为曲线偏了肉眼很难发现等到加工或仿真时才暴露就晚了。5.3 批量处理的性能与稳定性关键词里“python 批量对 cad 修改”是个高频需求。批量处理最大的挑战不是单个文件处理得多好而是一百个文件里有一个异常整个批处理不能崩。我的做法是每个文件独立处理异常单独捕获记录处理完输出一份报告成功多少、失败多少、失败原因分类。这样即使有失败也不影响其他文件而且失败原因能指导后续优化。性能上DXF 解析本身不算慢瓶颈往往在几何运算和 AI 调用。AI 调用如果每个文件都调一次大模型成本和延迟都受不了。我的优化是能规则化的先规则化只有规则搞不定的才调模型模型调用做批量和缓存相同或相似的输入复用结果。实测下来一个几百张图纸的批处理任务优化后能把 AI 调用量降到一个可接受的范围。6. 那些没人写在文档里的实操心得6.1 先做“读”再做“写”读懂了再谈生成我见过太多人一上来就想做“AI 生成图纸”结果卡在第一步。我的建议是反过来先把“AI 读懂现有图纸”做扎实。读图这件事本身就极有价值——批量提取图纸信息、自动分类归档、自动检查规范、自动生成物料清单这些都是实打实的需求而且比生成容易落地。你把读图做透了对图纸的数据结构、常见问题、企业规范都有了深入理解再去做生成成功率会高很多。我自己的项目就是从“批量读图提取信息”起步的这个阶段积累的解析能力和校验规则后来全用在了生成流程上。6.2 校验规则要跟实际使用方一起定校验层是我认为整个架构里最被低估的部分。很多人把精力全花在生成上校验随便写写。但工程场景里校验才是保证交付质量的关键。而且校验规则不能你自己拍脑袋定要跟实际用图纸的人对齐。比如图层规范设计部门有一套加工部门可能还有额外要求标注样式不同项目可能不一样。这些规则要一条条确认写成可配置的规则文件。我吃过亏自己定了一套规则生成结果自己校验通过交付后被使用方打回来因为不符合他们的图层标准。后来我学乖了规则制定阶段就拉着使用方一起过虽然前期慢但后期返工少。6.3 给 AI 的输出加“护栏”模型输出不可控是常态所以要在它外面加护栏。我的做法是定义严格的输出 schema模型必须按 schema 输出结构化数据任何不符合 schema 的输出直接拒绝并重试。schema 里对每个字段做类型和范围约束比如“孔直径”必须是正数且在一定范围内“图层名”必须来自预定义列表。这样即使模型抽风也抽不出 schema 的边界。这个护栏机制看起来简单但能挡掉大量低级错误是工程化的基本功。6.4 版本和可追溯性工程图纸是要追溯的。哪张图是谁在什么时候用什么参数生成的出了问题要能查。所以我的流程里每次生成都记录输入参数、模型版本、生成时间、校验结果存成一份元数据。这份元数据跟图纸文件一起归档。Demo 阶段没人管这个但工程阶段这是刚需。有了它出问题能快速定位是参数错了、模型变了还是校验漏了而不是两眼一抹黑重新跑一遍。7. 关于“AI CAD”这件事我现在的真实判断做了这几个项目之后我对“AI CAD”的预期比一开始理性了很多。它不是一个能一键替代设计师的东西短期内也不是。它真正能创造价值的地方是那些重复、规则明确、但量大的环节批量提取图纸信息、批量做规范检查、批量生成标准件、辅助标注和分类。这些环节人做又慢又容易错AI 做能显著提效而且错了也能通过校验兜住。至于“一句话生成复杂装配体”这种我觉得还有很长的路。不是模型不够强而是工程对正确性的要求太高而概率性生成和确定性几何之间的鸿沟需要靠架构设计去弥合不是靠换个更大的模型就能解决的。我现在的做法就是把 AI 放在它该在的位置——做语义理解和初筛把精确计算和校验交给确定性系统人做最终的确认和决策。这个分工不酷但能落地。如果你也在做类似的事我的建议是别被 Demo 迷惑先把“读”和“校验”做扎实把参数化和可追溯做进去把 AI 的输出用 schema 框住。这些基础工作做完你会发现能落地的场景比想象中多而且每一个都经得起工程的检验。反过来如果跳过这些直接冲生成大概率会停在 Demo 阶段然后感慨“AI 落地真难”。难的不是 AI是工程本身。