1. 从一堆"跑得通"的Demo说起
过去一年多，我陆陆续续接触了十几个号称"AI + CAD"的项目，有创业团队做的，有设计院内部孵化的，也有大厂研究院拿出来秀肌肉的。演示环节几乎都长一个样：上传一张图纸，模型几秒钟之内把墙体、门窗、标注识别得七七八八，然后自动生成一份结构化数据，或者干脆直接输出一份改好的DXF。台下掌声雷动，投资人点头，领导满意。
然后到了真实工程环境，故事就变了。
图纸一换，识别率从90%掉到40%；图层命名稍微不规范，整个解析流程直接崩；DWG里嵌套的外部参照一多，程序跑十分钟还没出结果；更别提那些扫描件转出来的PDF、手绘草图、以及各种历史遗留的R12格式文件。我见过最夸张的一个案例，团队在Demo里用的是自己精心挑选的20张"干净"图纸，上线后面对一个真实项目的3000张图纸，准确率惨不忍睹，最后项目不了了之。
这不是个别现象，这是当前AI + CAD落地的一个普遍困境。Demo满天飞，工程走不通，这句话我越想越觉得精准。问题不在于AI不行，也不在于CAD太复杂，而在于两者之间的那道鸿沟——工程化的鸿沟——被绝大多数团队严重低估了。
这篇内容我想认真聊聊这件事。不是唱衰，也不是吹捧，而是把我自己踩过的坑、见过的失败、以及少数跑通的案例，掰开揉碎讲清楚。如果你正在做AI + CAD相关的产品、项目或者研究，或者你是一个想用AI提效的CAD工程师，这篇应该能帮你少走不少弯路。核心关键词就几个：AI、CAD、DXF、DWG、FreeCAD，围绕这几个词展开，但重点不在工具本身，而在"为什么工程走不通"这件事上。
2. 图纸格式这道坎，比想象中高得多
2.1 DWG不是"一种格式"，而是一个格式家族
很多人对DWG的理解停留在"CAD图纸文件"这个层面，觉得读DWG就跟读PDF差不多。这个认知偏差是很多项目翻车的起点。
DWG是Autodesk的私有格式，从R1到R2018，中间经历了无数次内部结构变更。R12、R13、R14、2000、2004、2007、2010、2013、2018，每一个版本的二进制结构都不一样。更麻烦的是，Autodesk从来没有完整公开过DWG的规范，第三方库（比如ODA的Teigha，现在叫ODA Drawings SDK）虽然能读，但兼容性始终是个玄学问题。我实测过，同一个文件用不同版本的ODA库打开，实体数量能差出百分之几，某些自定义对象直接丢失。
DXF相对好一些，毕竟是公开的交换格式。但DXF也分ASCII和二进制两种，版本同样一大堆。而且DXF有个致命问题：它本质上是一个"尽力而为"的交换格式，从DWG转DXF的过程中，信息丢失是常态。图层状态、动态块、约束、自定义对象、代理实体，转一圈回来可能就面目全非了。
提示：如果你的AI管线依赖DXF作为中间格式，务必在转换环节做一次完整性校验，对比实体数量、图层列表、块引用关系。我见过太多团队直接拿转换后的DXF喂给模型，结果模型学到的是一份"残缺"的数据分布。
2.2 真实图纸的"脏"程度超出算法工程师的想象
做算法的人习惯在干净数据集上工作，但真实工程图纸的混乱程度，我可以用几个真实例子来说明：
- 图层命名毫无规范。同一个设计院，不同项目组，甚至同一个项目组不同人画的图，图层名从"WALL"到"墙"到"0"到"图层1"到"$%#@墙体"，什么都有。
- 块（Block）嵌套深度惊人。一个门窗块可能嵌套了五层，每层还有不同的缩放和旋转，炸开之后实体数量爆炸。
- 标注和图形混在一起。尺寸线、引线、文字、填充，全部堆在同一个图层，没有语义区分。
- 外部参照（Xref）满天飞。主图里引用了十几个外部文件，有些路径还是绝对路径，换台机器就找不到。
- 历史遗留的"垃圾"实体。零长度的线、重复的圆、看不见的图层上的东西，清理都清理不干净。
这些"脏"数据，在Demo里被精心过滤掉了，在工程里却是常态。你的模型在干净数据上训练，到了真实环境就是"水土不服"。
2.3 FreeCAD和开源方案的真实定位
说到开源CAD，FreeCAD是绕不开的。它的优势很明显：开源、可编程（Python API）、支持多种格式导入导出。但我要泼一盆冷水：FreeCAD目前不适合作为生产级DWG处理的主力工具。
原因有几个。第一，FreeCAD对DWG的支持依赖外部转换器（比如ODA File Converter或者LibreDWG），本身并不原生解析DWG。第二，它的几何内核是OpenCASCADE，处理大型图纸时性能瓶颈明显。第三，导入DWG后的实体结构，和AutoCAD里的原始结构往往对不上，做精确的语义分析很吃力。
那FreeCAD适合干什么？我的经验是：适合做原型验证、适合做轻量级的参数化建模、适合做教学和二次开发学习。如果你要做一个AI + CAD的产品，FreeCAD可以作为一个参考实现或者辅助工具，但别指望它扛起整个DWG解析的重担。
真正做工程级DWG处理，目前比较靠谱的路线是：ODA Drawings SDK（商业授权，但稳定）、AutoCAD的ObjectARX（需要AutoCAD环境）、或者基于开源库自己啃格式（成本极高，不推荐）。DXF处理则可以用ezdxf（Python）这类成熟库，但同样要注意版本兼容和实体覆盖度。
3. AI模型在CAD场景里的"水土不服"
3.1 视觉模型看图纸，和看自然图像是两回事
很多团队的第一反应是：图纸不就是图像吗？用目标检测、语义分割那套不就行了？
我一开始也这么想，后来发现完全不是一回事。CAD图纸有几个特性，直接让通用视觉模型失效：
第一，图纸是矢量语义的，不是像素语义的。一条线在像素层面就是几个像素宽的黑线，但在CAD语义里，它可能是一段墙、一根管道、一条轴线、或者一个标注的延伸线。光看像素，模型根本分不清。你可能会说，那就多训练数据呗。问题是，同样的像素图案，在不同图纸里语义完全不同，这个歧义靠数据量是解决不了的。
第二，图纸的尺度变化极大。一张总平面图可能覆盖几平方公里，一张节点详图可能只有几厘米。同一个模型要同时处理这两种尺度，对感受野和分辨率的要求是矛盾的。
第三，图纸的信息密度极高。自然图像里，物体之间有大量冗余背景。图纸里，每一根线、每一个文字都可能是关键信息，没有"背景"这个概念。模型很容易被密集的线条干扰。
我见过一个团队，用YOLO做图纸符号检测，在自建数据集上mAP到了0.9，上线后面对真实图纸，mAP掉到0.3。原因就是真实图纸的符号样式、比例、旋转角度、遮挡情况，远比训练集复杂。
3.2 大模型读图纸，卡在"结构化"这一步
这两年大模型火了，很多人想用多模态大模型直接读图纸。思路是：把图纸转成图片，喂给GPT-4V或者类似模型，让它输出结构化信息。
这个思路在Demo里效果惊艳，但工程上问题很多。
首先是精度问题。大模型对图纸里的精确数值、坐标、尺寸，识别能力很有限。它可能告诉你"这里有一堵墙"，但墙的起点坐标、厚度、高度，它给不出来，或者给出来是错的。而CAD工程恰恰是精确到毫米的领域，差一点都不行。
其次是一致性问题。同一张图纸，你问两次，大模型可能给出两个不同的答案。这在工程场景里是不可接受的。
第三是成本问题。一张A0图纸转成高分辨率图片，token消耗巨大。一个真实项目几千张图纸，用大模型逐张处理，成本根本扛不住。
那大模型在CAD场景里就没用了吗？也不是。我的经验是，大模型适合做辅助理解和交互，比如：根据自然语言描述生成CAD操作脚本、解释图纸里的设计意图、做图纸问答。但让它直接做精确的图纸解析，目前还不现实。
3.3 真正跑通的方案，往往是"传统 + AI"的混合体
我见过少数跑通的案例，它们的共同特点是：不迷信AI，该用传统方法的地方就用传统方法。
比如图纸解析这个环节，成熟的方案往往是：
- 先用规则和几何算法做预处理：图层过滤、实体分类、拓扑关系提取。
- 再用AI做规则搞不定的部分：比如模糊的符号识别、手写标注识别、异常检测。
- 最后用规则做后处理和校验：确保输出的结构化数据符合工程规范。
这个"规则-AI-规则"的三明治结构，比纯AI方案稳定得多。原因很简单：CAD本身就是一个高度规则化的领域，规则能解决的问题，没必要用AI。AI的价值在于处理规则覆盖不到的"长尾"情况。
我认识一个做电气图纸识别的团队，他们的方案就是：先用规则提取所有线段和文字，然后用一个轻量级的分类模型判断每个符号的类型，最后用规则做连接关系推理。整个方案没有用任何大模型，但准确率和稳定性都远超那些"端到端"的AI方案。
4. 工程化的坑：从"能跑"到"能用"的距离
4.1 数据管线的健壮性，决定了项目的生死
Demo阶段，数据是手工准备的，格式是统一的，路径是写死的。工程阶段，数据是源源不断的，格式是五花八门的，路径是动态的。这个转变，会暴露出一大堆问题。
我列几个最常见的：
| 问题类型 | Demo表现 | 工程表现 | 应对策略 |
|---|---|---|---|
| 文件格式 | 统一DWG | DWG/DXF/PDF/图片混合 | 建立格式识别和转换管线，每种格式单独处理 |
| 文件版本 | 单一版本 | R12到2018都有 | 用ODA等库做版本兼容，或统一转换到中间格式 |
| 文件损坏 | 不存在 | 偶尔出现 | 加异常捕获和降级处理，损坏文件单独记录 |
| 路径问题 | 本地路径 | 网络路径、相对路径、中文路径 | 统一路径处理，避免硬编码 |
| 并发处理 | 单文件 | 批量并发 | 加队列和限流，避免内存爆炸 |
这些看起来都是"工程细节"，但恰恰是这些细节，决定了项目能不能上线。我见过一个团队，算法做得很好，但因为没处理好中文路径，上线后一半文件读不进来，排查了两天才发现是编码问题。
4.2 性能：CAD处理的性能瓶颈往往不在算法
很多人以为AI + CAD的性能瓶颈在模型推理，其实不然。我实测下来，大部分时间花在了文件IO和格式转换上。
一个典型的DWG文件，几十兆到几百兆不等。用ODA库打开，可能要几秒到几十秒。如果要做格式转换，时间更长。模型推理反而可能只占百分之十几的时间。
这意味着什么？意味着你优化模型推理，收益有限。真正要优化的是：
- 缓存机制：解析过的文件，把中间结果缓存起来，避免重复解析。
- 并行处理：文件级别的并行，而不是实体级别的并行。
- 增量处理：只处理变化的文件，而不是每次全量处理。
- 预处理流水线：把耗时的转换步骤提前做，和推理步骤解耦。
我见过一个项目，通过引入文件级并行和中间结果缓存，整体处理速度提升了将近十倍。算法一行没改。
4.3 准确率的"最后一公里"，是最难啃的
从80%准确率到95%，可能比从0到80%还难。因为剩下的20%是长尾，是各种奇葩情况，是"每个项目都不一样"的部分。
这个时候，纯靠模型迭代已经不够了。需要的是：
第一，建立反馈闭环。让用户能方便地标注错误、修正结果，这些反馈数据回流到训练集。没有反馈闭环的系统，准确率会停滞。
第二，做分层处理。高置信度的结果自动通过，低置信度的结果转人工审核。这样既保证了整体准确率，又控制了人工成本。
第三，接受"不完美"。工程场景里，100%准确率是不现实的。关键是让用户知道哪些地方可能有问题，并提供便捷的修正手段。一个能标注"这里我不确定"的系统，比一个假装什么都懂的系统有用得多。
提示：在设计AI + CAD产品时，一定要把"人工修正"作为一等公民来设计，而不是事后补丁。用户修正的过程，既是数据回流的过程，也是建立信任的过程。
5. 那些跑通的团队，做对了什么
5.1 场景收窄：不做"通用CAD AI"，做"某个细分场景的AI"
跑通的团队，几乎没有一个做"通用"方案的。他们都很聪明地把场景收窄到了极致。
比如，有的团队只做建筑平面图的墙体识别，别的什么都不做。有的团队只做电气原理图的符号识别和连线检查。有的团队只做机械图纸的尺寸标注提取。
场景一收窄，问题就变得可解了。因为你可以针对这个场景，定制数据、定制规则、定制模型、定制评估标准。通用方案面对的是无限的长尾，细分方案面对的是有限的问题集。
我认识一个团队，专做暖通图纸的风管识别。他们的数据全部来自暖通领域，模型是针对风管符号专门设计的，规则是针对暖通制图规范写的。结果就是，在这个细分场景里，他们的准确率能做到95%以上，而通用方案可能只有60%。
5.2 人机协同：不追求全自动，追求"人机配合的效率最大化"
另一个共同点是，他们都不追求"全自动"。他们追求的是"人机协同"。
什么意思？就是AI做它擅长的部分（比如批量识别、初步分类、异常检测），人做他擅长的部分（比如判断、决策、修正）。整个流程的设计目标，不是"取代人"，而是"让人做得更快"。
这个思路的转变很关键。追求全自动，你会陷入无止境的准确率优化，而且永远达不到100%。追求人机协同，你只需要让AI把人的工作量降低到原来的几分之一，价值就出来了。
比如，原来一个工程师一天能审10张图，现在AI先过一遍，标出可疑的地方，工程师只需要重点看这些地方，一天能审50张。这个提升，已经足够支撑一个商业产品了。
5.3 工程思维优先：算法是手段，不是目的
最后一点，也是我觉得最重要的一点：跑通的团队，都是工程思维优先的。
他们不会为了用某个酷炫的模型而用模型。他们会先问：这个问题，用规则能不能解决？用传统算法能不能解决？如果都能，那就用最简单的方案。只有当简单方案搞不定的时候，才上AI。
他们也不会追求"技术领先"。他们追求的是"稳定、可靠、可维护"。一个用了三年还在稳定运行的规则系统，比一个每个月都要重新训练的模型系统，在工程上价值大得多。
这种工程思维，在AI热潮里显得有点"保守"，但恰恰是这种保守，让他们的项目活了下来。
6. 给正在做AI + CAD的人几条实在建议
6.1 先把数据管线做扎实，再谈模型
如果你现在正在启动一个AI + CAD项目，我的第一条建议是：花至少一半的精力在数据管线上。
具体来说：
- 搞清楚你的数据来源，有多少种格式、多少个版本、多少种"脏"法。
- 建立一套健壮的格式转换和预处理流程，能处理异常、能记录日志、能降级。
- 建立数据质量评估机制，知道你的数据里有多少是"能用"的。
- 建立数据版本管理，确保训练和推理用的是同一套数据标准。
这些工作很枯燥，不像调模型那么有成就感，但它们决定了项目的下限。下限守不住，上限再高也没用。
6.2 评估指标要贴合工程实际，别只看mAP
算法团队喜欢用mAP、IoU这些指标，但工程场景里，这些指标往往和实际体验脱节。
我建议加入这些指标：
- 端到端准确率：从输入文件到最终输出，整个流程的正确率。
- 人工修正率：用户需要手动修改的比例。
- 处理时间：单文件平均处理时间，以及P95、P99。
- 失败率：完全无法处理的文件比例。
- 用户满意度：最终用户的直接反馈。
这些指标才能真正反映产品的好坏。一个mAP 0.95但处理一张图要5分钟的系统，和一个mAP 0.85但处理一张图只要5秒的系统，后者在工程上往往更有价值。
6.3 别忽视CAD领域知识，算法工程师需要"补课"
我见过太多算法工程师，对CAD的理解停留在"一种文件格式"的层面。他们不知道图层的作用、不知道块的意义、不知道标注的规范、不知道不同专业的制图习惯。
这导致他们设计出来的方案，往往"技术上可行，工程上可笑"。比如，把图层信息完全丢弃，只用几何信息做识别。比如，把块炸开之后再处理，丢失了块的语义。比如，不考虑图纸的打印比例，直接用像素坐标。
我的建议是：算法工程师至少要花一周时间，跟着CAD工程师画几张图，理解图纸是怎么"长"出来的。这个投入，回报极高。
6.4 从小场景切入，快速验证，逐步扩展
不要一上来就做"通用CAD AI"。找一个你熟悉的、数据容易获取的、价值明确的细分场景，先做出来，跑通，拿到反馈，再考虑扩展。
这个细分场景最好满足几个条件：
- 有明确的用户和明确的价值。
- 数据相对规范，或者你有能力获取规范数据。
- 评估标准清晰，能快速判断做得好不好。
- 场景边界清晰，不会无限膨胀。
我见过一个团队，从"钢筋图纸的编号识别"这个小场景切入，做了一年，积累了数据和口碑，然后逐步扩展到整个结构图纸的识别。这个路径，比一上来就做"通用"要稳得多。
6.5 保持耐心，这个领域没有捷径
最后一条，也是最重要的一条：保持耐心。
AI + CAD不是一个能快速爆发的领域。它涉及文件格式、几何算法、领域知识、工程规范、用户习惯，每一个都是硬骨头。想靠一个大模型、一套算法就颠覆这个领域，是不现实的。
但反过来说，这个领域的门槛高，也意味着一旦跑通，壁垒就高。那些愿意沉下心来做数据、做工程、做细节的团队，最终会建立起别人难以复制的优势。
我自己在这个领域摸索了几年，最大的体会就是：慢就是快。把基础打扎实，把场景做透，把用户服务好，增长是自然的事情。那些追求"快速起量"的，往往死得也快。
7. 关于工具选型的一点个人经验
聊了这么多理念，最后说点具体的工具选型经验，算是给实操的人一点参考。
DWG解析：如果预算允许，ODA Drawings SDK是目前最稳的选择。它的兼容性和稳定性，是开源方案比不了的。如果预算有限，可以考虑用AutoCAD的脚本接口做批量转换，把DWG转成DXF再处理，但要注意转换损失。
DXF处理：Python生态里，ezdxf是比较成熟的选择。它支持大部分DXF实体，API也比较友好。但要注意，ezdxf对某些自定义实体和代理实体的支持有限，遇到复杂图纸可能会丢东西。
几何处理：OpenCASCADE是绕不开的，功能强大但学习曲线陡峭。如果只是做2D处理，Shapely这类轻量级库可能更合适。3D处理的话，OpenCASCADE或者CGAL都是可选项。
FreeCAD：前面说过了，适合原型和学习，不适合生产级DWG处理。但它的Python API设计得不错，可以用来快速验证一些想法。
AI框架：这个没什么好说的，PyTorch是主流。但我要提醒一句：在CAD场景里，模型往往不是最关键的。一个精心设计的规则系统，可能比一个复杂的深度学习模型更有效。
大模型：如果要用，建议用在辅助环节，比如图纸问答、操作脚本生成、设计意图解释。别用它做精确的图纸解析，目前还不靠谱。
工具选型没有绝对的对错，关键是要匹配你的场景、团队能力和预算。我的建议是：先用最简单的方案跑通流程，遇到瓶颈再逐步升级工具。不要一上来就堆最复杂的工具链，那样只会让你陷入"工具调试"的泥潭，忘了真正要解决的问题。
说到底，AI + CAD这件事，技术只是其中一部分。更多的时候，考验的是你对工程的理解、对用户的理解、对细节的把控。那些Demo满天飞却走不通的项目，缺的往往不是技术，而是这份理解和耐心。
