1. 从一堆炫酷 Demo 到工程落地中间隔了什么过去一年多我陆陆续续接触了不少“AI CAD”方向的项目有做图纸识别的有做参数化生成的也有做自然语言驱动建模的。朋友圈里隔三差五就能刷到某个团队放出的演示视频对着聊天框说一句“帮我画一个法兰盘”几秒钟后屏幕上就出现了一个带孔的三维模型弹幕一片“牛逼”。但如果你真的在制造业、建筑设计院或者工程公司待过就会知道这些视频和真正能跑在生产环境里的系统之间差着十万八千里。我自己踩过这个坑。两年前接手一个内部项目目标是把历史积累的 DWG 图纸批量解析成结构化数据再基于这些数据做智能检索和辅助设计。当时团队里有人提议直接上大模型说“现在 AI 这么强喂几张图进去不就完了”。结果我们花了三个月换了三套方案最后发现最难的压根不是模型本身而是图纸格式的解析、图层语义的还原、以及工程语境下对“正确”的定义。Demo 能跑通是因为它只处理了最干净的那几张图工程走不通是因为真实场景里的图纸脏得超出想象。这篇文章我想把这段时间的观察和实操经验完整梳理一遍。核心围绕几个问题为什么 AI 和 CAD 的结合这么难DXF、DWG 这些格式到底卡在哪里FreeCAD、OpenCascade 这类开源工具在链路里扮演什么角色以及如果你现在想做一个真正能用的 AI CAD 工具应该从哪个环节切入。适合正在做相关产品、或者准备入坑这个方向的工程师和产品经理参考也适合对 CAD 二次开发感兴趣但还没找到切入点的朋友。2. 图纸格式这道坎比模型能力更致命2.1 DWG 和 DXF 的本质差异决定了你的技术路线很多人一开始会把 DWG 和 DXF 当成一回事觉得无非是两种后缀名。实际上这两个格式的差异直接决定了你整个技术栈的选型。DWG 是 AutoCAD 的原生二进制格式结构封闭官方文档极少想要解析基本只能依赖 Autodesk 自家的 RealDWG 库或者 ODAOpen Design Alliance的 Teigha。而 DXF 是 Autodesk 推出的交换格式有公开的组码规范文本和二进制两种形式都有理论上你可以自己写解析器。我最初选的是 DXF 路线理由很简单有文档、有开源库、不依赖商业组件。但实际跑下来发现DXF 的坑一点不比 DWG 少。首先是版本问题R12、R14、2000、2004、2007、2010、2013、2018每个版本的组码定义都有细微差别有些实体类型在新版本里被废弃了有些属性是后来才加的。你写一个解析器如果不做版本适配遇到老图纸直接崩。其次是 DXF 里大量使用扩展数据XDATA和代理实体Proxy Entity这些是第三方软件写入的私有数据没有公开规范解析出来就是一堆二进制块。后来我们转向了 ODA 的方案用 Teigha 的 .NET 或 C 接口来读 DWG。好处是兼容性好Autodesk 能打开的它基本都能打开。代价是授权费用不低而且 API 学习曲线陡峭。如果你的项目预算有限或者只是想做个原型验证我建议先用 FreeCAD 的 Python 接口配合 ezdxf 库来跑通流程等验证完业务逻辑再考虑换重型方案。格式解析难度开源方案商业方案适用场景DXF中等ezdxf、dxfgrabberODA Teigha原型验证、轻量工具DWG高LibreCAD部分、FreeCAD依赖 ODARealDWG、ODA生产环境、全兼容需求STEP/IGES中等OpenCascade、pythonocc多种三维模型交换PDF图纸高pdfplumber仅文本多种OCR方案归档图纸数字化2.2 图层和块参照图纸语义还原的真正难点解析出线段、圆弧、文字这些几何实体只是第一步真正难的是还原图纸的“语义”。在工程图纸里不同的图层代表不同的专业墙体、门窗、标注、轴线、设备、管道每个设计院有自己的图层命名规范有的用中文有的用拼音缩写有的用数字编码。你拿到一张图如果不理解图层含义解析出来的就是一堆没有意义的线条。块参照Block Reference是另一个大坑。CAD 里的块可以嵌套一个块里可以引用另一个块嵌套层数可能很深。而且块有属性Attribute这些属性可能是文字、可能是数字、可能是带格式的字段。我们当时处理一个设备图纸块嵌套了七层最里层的属性文字被外层块旋转了 90 度解析出来坐标全是错的。后来写了一个递归展开加坐标变换的模块才把这个问题解决。实操建议在做图层语义映射之前先统计一下你手头图纸的图层命名分布。如果超过 60% 的图层名是规范化的可以考虑用规则引擎做映射如果命名混乱那就需要引入人工标注或者聚类算法来辅助分类。2.3 从 DWG 到 OpenCascade几何内核的转换损耗有些场景需要把二维图纸转成三维模型这就涉及到几何内核的转换。OpenCascade 是开源领域最成熟的几何内核FreeCAD 就是基于它构建的。但 DWG 里的二维实体转到 OpenCascade 的 TopoDS_Shape 时会有精度损失和拓扑错误。比如两条本该相交的线段因为浮点精度问题没有真正相交导致后续的布尔运算失败。我们当时的做法是在转换前先做一轮几何清理合并重合点、修复微小间隙、删除零长度线段。OpenCascade 提供了 ShapeFix 工具包可以自动修复一部分问题但不能全指望它。有些图纸的精度问题非常隐蔽需要你自己写检测逻辑。比如我们遇到过一个案例图纸里有一条线段的端点坐标是 (100.0000001, 200.0000002)而相邻线段的端点是 (100.0, 200.0)差了 0.0000001肉眼完全看不出来但布尔运算就是过不去。3. 大模型在 CAD 场景里到底能干什么3.1 自然语言转参数看起来很美边界很窄现在很多 AI CAD 的 Demo 都在展示“说一句话生成模型”比如“画一个直径 100 毫米、厚度 10 毫米的法兰盘带 6 个直径 12 毫米的孔”。这个场景在演示里很惊艳但实际落地时你会发现它的适用范围非常窄。首先用户的需求描述往往是不完整的他可能只说“画个法兰盘”但不说具体参数。其次工程语境下的约束条件极其复杂材料、公差、表面处理、装配关系这些都不是一句话能说清楚的。我试过用大模型做参数提取输入是一段设计说明文字输出是结构化的参数表。在测试集上准确率能到 85% 左右但剩下 15% 的错误里有一半是致命错误比如把“M12 螺纹孔”理解成“直径 12 的圆孔”把“倒角 2x45°”理解成“边长 2 的三角形”。这些错误在 Demo 里看不出来但在工程里就是废品。我的判断是自然语言转参数这个方向短期内更适合做“辅助输入”而不是“自动生成”。也就是说让 AI 生成一个初稿然后由工程师确认和修改而不是直接输出最终结果。3.2 图纸理解OCR 加几何推理的组合拳相比生成AI 在图纸理解方面的落地可能性更大。一张 CAD 图纸里包含了几何信息、文字标注、尺寸公差、技术要求这些信息如果能够自动提取并结构化对后续的检索、复用、审核都有巨大价值。我们的做法是分两步走先用 OCR 提取图纸里的文字信息包括标注文字、标题栏、技术要求然后用几何推理引擎把文字和几何实体关联起来。比如一个尺寸标注“100±0.05”OCR 识别出文字后需要找到它对应的两条尺寸界线才能确定这个尺寸标注的是哪一段距离。这个关联过程需要结合空间位置、图层信息、标注样式来综合判断。这里有个经验不要指望 OCR 能 100% 准确。工程图纸里的字体五花八门有宋体、仿宋、黑体还有手写体。有些图纸扫描质量差文字模糊。我们的做法是OCR 结果只作为候选最终由几何推理来验证。比如 OCR 识别出一个数字“100”但几何测量出来是“99.8”那就需要人工复核。这种“AI 初筛 规则校验 人工兜底”的模式在实际项目里比纯 AI 方案靠谱得多。3.3 代码生成让 AI 写 CAD 脚本的可行性还有一个方向是用大模型生成 CAD 脚本比如 AutoLISP、Python 脚本或者 FreeCAD 的宏。用户描述需求AI 生成代码代码在 CAD 里执行。这个思路在理论上很优雅因为脚本是确定性的执行结果可复现。我实测过用 GPT-4 生成 FreeCAD Python 脚本让它画一个简单的齿轮。结果它生成的代码能跑但齿轮的齿形参数是错的模数和齿数搞反了。后来我调整了提示词把 FreeCAD 的 API 文档和几个示例脚本一起喂进去准确率明显提升。这说明大模型在代码生成方面是有潜力的但前提是你要给它足够的上下文和约束。关键技巧在提示词里明确指定 API 版本和函数签名并提供 2-3 个正确示例。不要指望模型自己“猜”对你的环境。4. 一条能跑通的工程链路应该长什么样4.1 数据层从图纸入库到结构化存储一条完整的 AI CAD 工程链路数据层是地基。我的建议是不管后续用什么 AI 方案先把图纸的解析和结构化做扎实。具体来说需要完成以下几件事第一图纸格式统一。如果手头有 DWG、DXF、PDF 多种格式先统一转成 DXF 或 STEP减少后续处理的复杂度。第二几何实体提取。把线段、圆弧、多段线、文字、标注、块参照全部解析出来存成结构化的 JSON 或数据库表。第三图层语义映射。建立图层名到业务含义的映射表比如“WALL”对应墙体“DOOR”对应门。第四元数据抽取。从标题栏提取图号、名称、材料、比例、设计者等信息。这一步做完你就有了一个“图纸数据库”后续的检索、分析、AI 应用都建立在这个基础之上。我见过太多项目跳过这一步直接上大模型结果模型再强也架不住输入是一堆乱码。4.2 推理层规则引擎和 AI 模型的分工数据层之上是推理层。我的经验是规则引擎和 AI 模型不是替代关系而是互补关系。规则引擎擅长处理确定性的、有明确逻辑的判断比如“如果图层名包含‘标注’则跳过几何分析”AI 模型擅长处理模糊的、需要语义理解的判断比如“这段文字描述的是材料还是工艺”。具体分工可以这样设计规则引擎负责预处理和过滤把明显无关的实体排除掉AI 模型负责核心的语义理解和分类最后再用规则引擎做后校验把 AI 输出的结果和几何约束做一致性检查。这种“规则-AI-规则”的三明治结构在实际项目里比纯 AI 或纯规则都稳定。4.3 应用层检索、审核、辅助设计三个落地方向链路跑通之后应用层可以做的事情就多了。我按落地难度从低到高排个序图纸检索是最容易落地的。基于结构化数据你可以做全文检索、相似图纸推荐、按参数筛选。我们当时做了一个“找相似图纸”的功能输入一张图纸系统返回历史上最相似的 10 张设计师反馈很有用。图纸审核难度中等。基于规则引擎可以自动检查图纸里的常见错误比如标注缺失、图层错误、尺寸矛盾。AI 模型可以用来检查技术要求描述是否规范、材料选择是否合理。辅助设计难度最高。这需要 AI 理解设计意图并生成符合工程约束的方案。目前我还没看到真正能落地的案例大多停留在实验室阶段。5. 那些 Demo 不会告诉你的坑5.1 图纸脏数据的七种典型形态真实工程环境里的图纸脏数据的花样比你想象的多。我整理了几种最常见的重复实体同一条线段被画了两遍坐标完全一样但属于不同图层。零长度线段起点和终点坐标相同肉眼看不见但解析时会报错。未闭合多段线本该闭合的轮廓起点和终点差了 0.001 毫米。文字乱码老图纸用的字体在新系统里找不到显示成问号或方框。块参照循环引用A 块引用 B 块B 块又引用 A 块递归展开时死循环。坐标偏移图纸的基点不在原点所有坐标都偏了一个大数。图层冻结有些实体在冻结图层里解析时容易被忽略。处理这些问题没有一劳永逸的方案。我的做法是写一个“图纸体检”工具在解析前先跑一遍把问题列出来能自动修的就修不能修的就标记出来让人工处理。5.2 精度问题浮点数在 CAD 里的隐形杀手CAD 里的坐标都是浮点数浮点数比较是编程里的经典坑。在 CAD 场景下这个问题尤其严重因为图纸的精度要求很高但浮点运算的误差会累积。我的经验是在 CAD 相关的代码里永远不要用比较两个浮点数。要用一个容差tolerance比如 1e-6 毫米。OpenCascade 里默认的容差是 1e-7但实际项目里可能需要调整。另外在做布尔运算之前一定要先做几何清理把距离小于容差的点合并把角度接近 0 或 180 度的线段处理掉。有个反直觉的点精度不是越高越好。容差设得太小会导致本该合并的点没合并布尔运算失败容差设得太大会把本该分开的实体合并在一起结果错误。需要根据你的图纸精度等级来调整。5.3 性能瓶颈当图纸大到几十兆小图纸跑得飞快大图纸直接卡死这是 CAD 处理的常见问题。一张几十兆的 DWG 图纸可能包含几十万个实体解析、存储、渲染每一步都是挑战。我们当时的优化策略是分三层第一层是解析优化用流式解析代替一次性加载边读边处理减少内存占用。第二层是存储优化用空间索引比如 R-tree来加速查询不要每次都全表扫描。第三层是计算优化把耗时的几何运算放到后台线程或者分布式任务队列里前端只做展示。还有一个容易被忽略的点DXF 文件里的实体顺序会影响解析速度。如果实体是按空间位置有序排列的解析时可以提前终止如果是乱序的就得全部读完。有些 CAD 软件导出的 DXF 是乱序的这时候可以考虑先做一次排序预处理。6. 工具选型的实战对比FreeCAD、OpenCascade 和商业方案6.1 FreeCAD 作为原型验证平台的优势和局限FreeCAD 是我最常用的原型验证工具原因有三开源免费、Python 接口友好、社区活跃。你可以用几行 Python 代码就完成一个 CAD 文件的读取和几何分析非常适合快速验证想法。但 FreeCAD 的局限也很明显。首先是性能处理大图纸时明显吃力。其次是稳定性某些复杂实体的操作会崩溃。第三是文档虽然社区文档不少但版本更新快很多教程已经过时了。我建议把 FreeCAD 定位为“原型工具”验证完业务逻辑后核心模块用 OpenCascade 的 C 接口重写。6.2 OpenCascade 的学习曲线和关键 APIOpenCascade 是工业级的几何内核功能强大但学习曲线陡峭。我刚开始用的时候光是把一个 STEP 文件读进来显示出来就花了两天时间。关键是要理解它的数据结构TopoDS_Shape 是顶层抽象下面分 TopoDS_Solid、TopoDS_Shell、TopoDS_Face、TopoDS_Wire、TopoDS_Edge、TopoDS_Vertex。每个层级有自己的属性和操作方法。几个高频 API 值得重点掌握BRep_Builder用于构建拓扑结构BRepTools用于读写文件BRepAlgoAPI用于布尔运算BRepExtrema用于距离计算。另外ShapeFix_Shape和ShapeAnalysis这两个工具包在修复脏几何时非常有用。6.3 商业方案值不值得上成本与收益的权衡商业方案比如 ODA 的 Teigha、Autodesk 的 RealDWG的优势是兼容性好、技术支持到位、文档齐全。劣势是授权费用高而且通常按年收费。如果你的项目是内部工具预算有限我建议先用开源方案跑通等业务价值验证清楚了再考虑商业方案。如果是面向外部客户的产品商业方案的稳定性和法律合规性更有保障。方案授权成本兼容性技术支持适用阶段FreeCAD ezdxf免费中等社区原型验证OpenCascade免费中等社区商业核心模块开发ODA Teigha较高高商业生产环境RealDWG高最高商业全兼容需求7. 如果现在让我重新做这个项目7.1 从最小可用闭环开始别一上来就搞大模型如果让我重新做一遍我会把节奏放慢先做一个最小可用闭环。具体来说第一步只做图纸解析和结构化存储不做任何 AI。把这一步做扎实确保能稳定处理 80% 的图纸。第二步加规则引擎做图纸检索和简单审核。第三步才引入 AI 模型做语义理解和辅助生成。这样做的好处是每一步都有明确的交付物风险可控。我见过太多项目一上来就搞大模型结果数据层没做好模型效果上不去最后项目烂尾。7.2 数据质量比模型能力更值得投入在 AI CAD 这个领域数据质量的重要性远高于模型能力。一张干净的、结构化的图纸数据用简单的规则引擎就能做出很好的效果一张脏的、混乱的图纸数据再强的模型也救不回来。我的建议是把 60% 的精力花在数据清洗和结构化上30% 花在规则引擎和业务逻辑上10% 花在 AI 模型上。这个比例可能和很多人的直觉相反但实际项目里就是这么回事。7.3 工程化落地的三个关键指标最后分享三个我用来判断项目是否真正落地的指标第一覆盖率。你的系统能处理多少比例的图纸如果低于 80%说明数据层还有问题。第二准确率。你的系统输出的结果有多少是工程师直接采纳的如果低于 70%说明推理层还需要优化。第三使用率。你的目标用户里有多少人每周至少用一次如果低于 30%说明产品价值还没被验证。这三个指标比任何 Demo 视频都更能说明问题。Demo 可以只展示最好的那 10%但工程落地必须面对剩下的 90%。我在实际项目里最大的体会是AI CAD 这个方向技术不是瓶颈耐心才是。愿意花时间把数据层做扎实、把边界条件处理干净的团队最后都跑出来了急着上模型、追热点的团队大多卡在了半路上。如果你正在做类似的事情不妨先停下来看看你的图纸数据是不是真的准备好了。