1. 为什么“AI CAD”的 Demo 看起来都很美1.1 从一张 DXF 说起Demo 的起点往往被精心挑选如果你最近半年刷过技术社区大概率见过这样的演示上传一张二维图纸AI 在几秒内识别出墙线、标注、门窗然后自动生成三维模型或者自动完成图层归类。视频节奏很快配乐很燃评论区一片“CAD 要被颠覆了”。但我自己真正把这类流程往工程项目里搬的时候第一反应是这张用来演示的 DXF是谁画的这个问题很关键。绝大多数 Demo 用的图纸是团队自己用脚本生成的、或者从公开数据集里挑出来的“干净图纸”。图层命名规范、线型统一、没有外部参照、没有多重引用、没有炸开的块、没有跨图幅拼接、没有历史遗留的“放射状乱线”。而真实工程里的 DWG往往是五六个专业来回改了十几版、图层名从“A-WALL”到“墙-最终-改-真的最终”都有的东西。Demo 和工程之间的第一道鸿沟不是算法能力而是输入数据的脏乱程度。我做过一个粗略统计在一个中等规模的建筑机电项目里随机抽 100 张 DWG能直接被程序无异常读取并解析出完整实体结构的通常不到 30 张。剩下的要么有损坏的块引用要么有循环嵌套的外部参照要么图层被锁定冻结导致解析出来是空的。Demo 阶段没人会告诉你这些因为 Demo 的图纸是“选出来的”而工程图纸是“长出来的”。1.2 演示环境与生产环境的三个硬差距把 Demo 跑通和把工程跑通中间隔着三样东西我习惯叫它们“三堵墙”。第一堵是数据规模墙。Demo 通常处理单张图纸几百 KB 到几 MB。工程里一个专业一次要处理几百上千张总量几十 GB还要保证图纸之间的坐标系统一、图幅拼接正确。单张能跑不代表批量能跑批量能跑不代表结果能对齐。第二堵是格式兼容墙。热词里出现的 DXF、DWG、EXB 转换、DWG 转 SHP、Pro/E 导入 DXF 改比例本质上都是格式问题。DXF 是文本交换格式相对好解析DWG 是二进制私有格式版本从 R12 到 2018 差异巨大EXB 是国产 CAD 的格式转换工具质量参差不齐。Demo 往往只支持一种格式的一个版本工程里则是“什么格式都有”。第三堵是精度与语义墙。Demo 识别出“这里有一条线”就算成功工程里要的是“这是一段 200mm 厚的剪力墙标高从 -0.05 到 3.15属于轴网 B-C 之间”。从几何到语义中间需要大量领域规则而规则是跟着项目、跟着规范、跟着设计院习惯走的不是一套模型能通吃的。提示判断一个 AICAD 方案能不能落地先别问它模型多大先问它“给我一批没整理过的历史图纸你能读出多少张”。这个问题的答案基本决定了它是 Demo 还是产品。1.3 谁适合看这篇给正在踩坑的工程侧和算法侧这篇内容主要写给两类人。一类是工程侧的技术负责人手里有一堆图纸想用 AI 提效但试了几个方案发现“演示很惊艳落地就翻车”另一类是算法侧的同学模型训得不错但一接触真实 CAD 数据就发现预处理比训练还难。如果你正好在这两个位置上下面这些内容应该能帮你少走几个月弯路。我不会给你一个“万能框架”因为这东西目前不存在。我会把我在 DWG 解析、DXF 处理、FreeCAD 二次开发、OpenCascade 几何内核这条链路上踩过的坑按“为什么走不通”和“怎么绕过去”两条线讲清楚。核心观点先放这儿AICAD 落地难八成不是 AI 的问题是 CAD 数据工程的问题。2. 拆开看CAD 数据到底难在哪里2.1 DWG 与 DXF一个私有二进制一个“看似开放”的文本先说格式。很多人以为 DXF 是开放的就好处理实际上 DXF 分 ASCII 和二进制两种ASCII 版本虽然能读但结构极其啰嗦。一个简单的圆在 DXF 里可能是这样的0 CIRCLE 5 2F 100 AcDbEntity 8 0 100 AcDbCircle 10 100.0 20 50.0 30 0.0 40 25.0这还只是一个圆。一张真实图纸里实体数量动辄几十万组码group code层层嵌套块引用INSERT里套块属性ATTRIB跟着走还有扩展数据XDATA挂在实体上。用 Python 的 ezdxf 能读但读全、读对、读快是三件不同的事。我试过用 ezdxf 批量读 500 张中等复杂度 DXF单张平均 8 秒内存峰值能到 2GB遇到嵌套块深的直接爆栈。DWG 更麻烦。它是 Autodesk 的私有二进制格式官方 SDK 有授权和平台限制开源方案里 LibreDWG 覆盖不全ODAOpen Design Alliance的 Teigha/Drawings SDK 相对靠谱但要商业授权。热词里那个“【cpython土木4】dwg图纸读取到opencascade”其实点到了要害从 DWG 到几何内核中间需要一层可靠的转换而这层转换的稳定性直接决定后面 AI 能不能用。我的实际做法通常是能用 DXF 就用 DXF必须处理 DWG 时先用可靠的转换工具批量转成 DXF注意版本选 R2013 或 R2018太老的 R12 会丢实体属性再进解析流程。转换这一步不要省省下来的时间后面会以十倍的调试成本还回来。2.2 图层、块、外部参照工程图纸的“历史包袱”真实图纸最劝退算法的地方不是几何复杂而是组织方式混乱。我见过一个项目同一个“门”的图块在三个专业里分别叫“门”“DOOR”“M-门”图层分别是“A-DOOR”“门”“0”。AI 模型如果按名字学直接懵如果按几何学又因为缩放比例不同而误判。外部参照XREF是另一个大坑。图纸 A 引用了图纸 BB 又引用了 CC 里还有多重引用。你单独打开 A看到的可能只是几个框。要拿到完整几何必须递归解析所有引用还要处理路径失效、循环引用、绑定与未绑定的区别。热词里“cad多重引用插入解除工具”能火说明这是普遍痛点。程序化处理时我一般会先做一次“引用展开”把所有 XREF 绑定并炸开到当前图纸再进解析。这一步会显著增大文件体积但换来的是结构确定性。块BLOCK的处理也有讲究。块定义和块引用是分开的同一个块定义可以被引用几百次每次有不同的插入点、缩放、旋转。解析时如果只读块定义会漏掉实例位置如果每个实例都展开数据量会爆炸。我的经验是先统计块引用的分布对高频块做“定义级”语义标注对低频块做“实例级”几何展开这样在精度和性能之间取平衡。2.3 从几何到语义AI 真正该发力的地方很多人把 AICAD 理解成“让模型看图”其实模型看图那部分图像识别反而是最成熟的。真正难的是把几何实体映射到工程语义。一条线可能是墙、可能是轴线、可能是标注引线、可能是填充边界。判断依据不只是几何还有图层、线型、颜色、所在图幅、相邻实体、甚至图纸名称和目录结构。我做过一个实验用纯几何特征长度、角度、位置做墙线分类准确率大概 70%加上图层和线型特征能到 88%再加上“同一图层内实体的一致性约束”和“墙线必须闭合或与柱相交”这类规则能到 95% 以上。这说明什么AI 不是替代规则而是和规则配合。纯端到端的模型在 Demo 里好看在工程里往往不如“规则打底 模型纠偏”的混合方案稳。热词里“逆冲断层 cad 线型”这种专业地质线型就是典型例子。这种线型在通用模型里根本没见过但工程上必须识别。解决办法不是重新训练一个大模型而是让系统支持“线型到语义”的可配置映射项目上自己维护一套规则库。这也是为什么我一直认为AICAD 的落地形态大概率是“平台 可配置规则 轻量模型”而不是一个黑盒大模型。3. 落地链路从图纸到可用数据的完整实操3.1 第一步批量格式归一化与健康检查不管后面用什么 AI第一步永远是把输入统一成可控格式。我的标准流程是这样的收集所有 DWG、DXF、EXB 文件按扩展名分组。DWG 用可靠转换工具批量转 DXF版本统一到 R2018兼容性和属性保留较好。EXB 用对应转换器转 DWG 再转 DXF转换后必须抽检因为 EXB 转换丢实体的情况不少。对每个 DXF 做健康检查能否打开、实体总数、图层数、块引用数、XREF 数、是否有损坏记录。健康检查我一般写成一个 Python 脚本用 ezdxf 的 recover 模式读读不出来的单独放“问题清单”。这一步看起来笨但能避免后面 80% 的“莫名其妙报错”。实测下来一个 500 张图纸的项目健康检查能筛出 30 到 50 张需要人工处理的提前处理掉后面批量跑就顺了。import ezdxf from pathlib import Path def health_check(dxf_path): try: doc ezdxf.readfile(dxf_path) msp doc.modelspace() return { file: dxf_path.name, status: ok, entities: len(msp), layers: len(doc.layers), blocks: len(doc.blocks), } except Exception as e: return {file: dxf_path.name, status: error, msg: str(e)} for p in Path(drawings).glob(*.dxf): print(health_check(p))注意ezdxf 的 recover 模块能救回一部分损坏文件但救回来的实体可能缺属性。救回的文件要标记来源后续语义处理时降低置信度。3.2 第二步几何解析与 OpenCascade 的角色格式统一后下一步是把 DXF 实体转成几何内核能理解的拓扑结构。这里 OpenCascadeOCCT是绕不开的。热词里“dwg图纸读取到 opencascade”说的就是这条链路DXF 实体 → 几何曲线/曲面 → OCCT 拓扑TopoDS_Shape→ 可做布尔运算、求交、偏置的模型。为什么非要走 OCCT因为工程上很多操作不是“看图”而是“算”。比如判断两个房间是否连通、计算墙体体积、检查管线碰撞这些都需要真正的几何运算而不是像素级识别。OCCT 提供了 BRep 表示和一套成熟的几何算法是开源里最靠谱的选择。从 DXF 到 OCCT 的转换我的做法是LINE、ARC、CIRCLE、LWPOLYLINE 这些基本实体直接映射到对应的 Geom 曲线SPLINE 用控制点构造HATCH 先提取边界再构造面INSERT 递归展开后按变换矩阵作用到子实体。这一步的难点在容差。DXF 里的坐标是浮点数但工程上“两条线是否相交”需要容差判断。容差设太小本该闭合的墙线判成断开设太大相邻但不该连的线被误连。我的经验值是 1e-3 到 1e-2 毫米量级具体看项目精度要求最好做成可配置。3.3 第三步语义标注与规则引擎的配合几何有了接下来是语义。这一步我强烈建议不要一上来就上大模型而是先搭一个规则引擎把能确定的先确定下来。规则引擎的输入是实体 上下文输出是语义标签 置信度。规则可以写成配置比如规则名条件输出语义置信度墙线规则图层含 WALL 且线宽 0.2墙0.9轴线规则线型为 CENTER 且贯穿图幅轴线0.85标注规则实体类型为 DIMENSION标注0.95门窗规则块名含 DOOR/WINDOW门窗0.8规则跑完后剩下的“低置信度”实体才交给模型。模型的任务不是从零识别而是在规则给出的候选里做选择或纠偏。这样模型小、训练数据需求少、可解释性强。我实测过这种混合方案比纯模型方案在真实项目上准确率高 10 到 15 个百分点而且出问题时能定位到具体规则而不是“模型黑盒不解释”。热词里“python 批量对 cad 修改”也是这个思路的延伸规则引擎不仅能标注还能反向修改图纸比如统一图层名、修正线型比例、批量替换块。这些操作在工程上价值极高而且比“AI 自动设计”靠谱得多。3.4 第四步FreeCAD 作为验证与可视化平台FreeCAD 在这个链路里的角色我把它定位成验证器和可视化前端。热词里“freecad 没有齿轮工具”说明很多人拿它当通用 CAD 用但在 AICAD 场景里它的价值在于开源、可 Python 脚本化、能加载 OCCT 模型、能快速搭一个查看器。我的做法是解析和语义处理在后台跑结果导出成 OCCT 的 BREP 或 STEP然后在 FreeCAD 里加载用不同颜色显示不同语义类别人工抽检。这样工程侧的人不需要懂代码打开 FreeCAD 就能看到“AI 把哪些线认成了墙”。抽检发现的问题反馈回去改规则或补训练数据形成闭环。FreeCAD 的 Python API 也方便做批量导出比如把识别出的墙线导出成 DXF 图层、把房间导出成面、把设备导出成点。这些中间产物可以进一步喂给其他系统比如 GISDWG 转 SHP 那条链路、算量软件、或者碰撞检查工具。4. 那些 Demo 不会告诉你的坑4.1 坐标系与比例一个让所有几何都错位的隐形杀手工程图纸的坐标系问题是 Demo 里最容易被忽略、工程里最容易翻车的点。一张图纸可能用了自定义坐标系插入点偏移几十万米不同图纸之间比例不一致有的按 1:100 画有的按 1:1 画Pro/E 导入 DXF 时比例改错整个模型缩放 25.4 倍英寸毫米混淆。热词里“pr0tel 导入 dxf 文件时怎么改图纸比例”就是这个问题的典型表现。我的处理原则是所有几何在进入语义处理前必须归一化到统一坐标系和统一单位。具体做法是读图纸的 INSUNITS 和测量信息结合已知的轴网间距或标注尺寸反推比例做一次全局变换。如果图纸本身没有可靠的比例信息就标记为“比例未知”不参与需要精确尺寸的计算只做拓扑和相对位置分析。这一步没有捷径必须逐个项目配置。我一般会做一个“项目配置表”记录每个项目的坐标系原点、单位、典型比例、轴网间距解析时按项目加载。看起来麻烦但比后面发现所有尺寸都错要省事得多。4.2 性能与内存批量处理时的真实瓶颈单张图纸跑得动不代表批量跑得动。我遇到过最典型的情况是单张 DXF 解析 3 秒500 张理论上 25 分钟实际跑了 4 个小时还没完内存从 2GB 涨到 32GB 最后 OOM。原因有三个一是没有及时释放 OCCT 对象C 侧的内存 Python 的 GC 管不到二是块定义被反复解析没有缓存三是日志和中间结果全存内存。解决办法是分批处理 显式释放 磁盘缓存。每处理 50 张就强制释放一次 OCCT 对象块定义按名称缓存到磁盘中间结果写临时文件而不是内存。这样虽然单张慢一点但整体稳定不会跑到一半崩掉。实测 500 张图纸优化后 1.5 小时跑完内存峰值控制在 6GB 以内。提示OCCT 的 Python 绑定pythonocc 或 OCCT 官方绑定在对象生命周期管理上比较敏感建议封装一层上下文管理器确保 TopoDS_Shape 用完就释放。4.3 常见问题速查表现象可能原因排查方向解决思路解析出来实体为空图层冻结/锁定、XREF 未展开检查图层状态和引用解冻图层、绑定并展开 XREF几何位置整体偏移坐标系原点不同、插入点异常对比已知轴网或标注归一化坐标系反推偏移量尺寸差 25.4 倍英寸毫米单位混淆检查 INSUNITS 和导入设置统一单位重算比例块引用丢失块定义缺失或循环引用检查块表和引用链补全块定义打断循环批量处理内存暴涨OCCT 对象未释放、无缓存监控内存曲线分批处理显式释放磁盘缓存线型识别错误线型比例不对、自定义线型检查 LTSCALE 和线型定义按项目配置线型映射文字乱码字体缺失、编码问题检查文字样式和编码替换字体统一编码转换后属性丢失转换工具版本不兼容对比转换前后实体数换转换工具或版本抽检这张表是我自己项目里攒下来的基本覆盖了 80% 的常见问题。遇到新问题先往这几类里套能省不少排查时间。4.4 一个真实项目的复盘从 500 张图纸到可用数据去年我参与过一个机电管线项目目标是把 500 多张 DWG 图纸里的管线和设备提取出来做碰撞预检查。过程大致是这样的第一周格式归一化和健康检查筛出 47 张问题图纸人工修复。第二周几何解析和坐标系归一化发现三个专业用了三套坐标系统一花了两天。第三周规则引擎标注管线和设备规则改了 11 版准确率从 72% 提到 91%。第四周模型纠偏和人工抽检最终可用率 96%。剩下 4% 是图纸本身质量问题标记为“需人工确认”。整个项目最大的教训是时间不要花在调模型上要花在数据清洗和规则配置上。模型我们只用了很小的一个分类网络大部分工作靠规则和几何运算完成。如果一开始就奔着“训个大模型”去估计现在还在调参。5. 我对 AICAD 落地形态的判断5.1 不是替代 CAD而是做 CAD 的“数据层”很多人讨论 AICAD喜欢说“AI 会不会取代设计师”。我的判断是短期内 AI 在 CAD 里的角色不是替代绘图而是做 CAD 和下游系统之间的数据层。CAD 图纸是给人看的但下游的算量、仿真、GIS、运维系统需要的是结构化数据。这个“从图纸到数据”的转换目前大量靠人工AI 的价值就在这里。所以我看好的是“AI 辅助的数据提取和转换工具”而不是“AI 自动设计工具”。前者需求明确、可验证、ROI 清晰后者听起来性感但工程上责任边界模糊落地阻力大。热词里“专利相关辅助链接 ai 辅助”也说明大家真正在找的是“能帮我干具体活的 AI”而不是“能替我思考的 AI”。5.2 给工程侧的建议先修数据再谈智能如果你在工程侧想引入 AICAD我的建议顺序是先做数据标准化再做规则自动化最后才考虑模型智能化。数据标准化包括图层规范、块命名规范、坐标系规范、版本管理。这些做好了哪怕不用 AI用脚本也能提效 50% 以上。规则自动化是在标准化基础上把重复的判断和修改写成规则。模型智能化是最后一步用来处理规则覆盖不到的边缘情况。跳过前两步直接上模型结果就是“Demo 很惊艳落地就翻车”。我见过太多这样的案例根因都是数据没准备好。5.3 给算法侧的建议去工地待一周比调参一个月有用如果你在算法侧我的建议是去实际项目上待一周看看图纸是怎么画的、怎么改的、怎么传的。你会看到设计师用 F 命令热词里“cad 里面 f 命令用不了”说明这是高频操作倒角会看到图纸被反复另存为不同版本会看到有人用“放射状乱线”表示某种特殊含义。这些在数据集里永远看不到但恰恰是模型落地必须理解的。AICAD 的难点不在 AI在 CAD。谁先把 CAD 这侧搞明白谁就能做出真正能用的东西。模型可以慢慢调但对业务的理解越早建立越好。5.4 最后分享一个实用技巧用“最小可用闭环”验证方案如果你正在评估一个 AICAD 方案别一上来就全量跑。选 10 张有代表性的图纸跑通“格式转换 → 几何解析 → 语义标注 → 结果导出 → 人工验证”这个最小闭环记录每一步的耗时、准确率、失败原因。这个闭环跑通了再放大到 100 张、500 张。跑不通趁早换方案别在 Demo 上浪费时间。这个技巧帮我省过很多次“看起来能行、实际不行”的投入。10 张图纸的验证成本很低但能暴露 80% 的落地风险。真正难的不是让 Demo 跑起来而是让它在你不完美的数据上稳定地跑下去。