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和开源方案的真实定位说到开源CADFreeCAD是绕不开的。它的优势很明显开源、可编程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处理则可以用ezdxfPython这类成熟库但同样要注意版本兼容和实体覆盖度。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表现工程表现应对策略文件格式统一DWGDWG/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满天飞却走不通的项目缺的往往不是技术而是这份理解和耐心。 
长河君 · 2026/9/30 18:38:26 · 阅读 1.2k AI+CAD工程化落地：从Demo到生产环境的鸿沟与破局
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和开源方案的真实定位说到开源CADFreeCAD是绕不开的。它的优势很明显开源、可编程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处理则可以用ezdxfPython这类成熟库但同样要注意版本兼容和实体覆盖度。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表现工程表现应对策略文件格式统一DWGDWG/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满天飞却走不通的项目缺的往往不是技术而是这份理解和耐心。