1. 从Demo到工程AICAD落地的真实鸿沟做过CAD相关工具开发的人都有一个共同感受演示视频里AI自动生成图纸、自动标注、自动改图看起来无所不能但一旦放到真实工程项目里立刻就露馅了。这不是某一个团队的问题而是整个行业目前面临的系统性困境。我从几年前开始接触CAD二次开发后来逐步把AI能力引入到图纸处理流程中踩过的坑可以说覆盖了从文件解析到工程交付的每一个环节。这篇文章不打算讲什么宏大的趋势只想把“为什么Demo满天飞、工程却走不通”这件事拆开揉碎从技术细节和工程实践两个维度把真实的原因和可能的出路讲清楚。先明确一下讨论范围。这里说的“AICAD”指的是利用AI大模型、机器学习或规则引擎对CAD图纸进行理解、生成、修改、转换或校验的一类工作。典型场景包括从DWG/DXF文件中提取结构化信息、根据自然语言描述生成参数化模型、批量修改图纸中的图层与标注、将CAD数据转换到其他格式比如GIS用的SHP、以及在设计过程中提供智能辅助。这些场景听起来都很美好但每一个从Demo走向工程的过程都会遇到几乎相同的障碍。适合谁看如果你正在做CAD相关的工具开发、正在评估AI能不能用在自己的设计流程里、或者单纯好奇为什么那些炫酷的演示到了自己手里就跑不起来那这篇内容应该能给你一些实在的参考。我不会只讲“有问题”还会讲“问题出在哪”以及“目前能怎么绕”。2. 为什么Demo看起来总是很美好2.1 Demo的天然优势受控环境下的完美表现Demo之所以好看核心原因是它在一个极度受控的环境里运行。开发者会精心挑选一个格式规范、图层清晰、没有多余嵌套的DWG文件然后用一套针对这个文件调好的参数去跑。比如展示“AI自动识别图纸中的门窗编号”Demo里用的图纸可能只有标准图层、标准块名、标准文字样式甚至连线宽都是统一的。这种情况下无论是用规则匹配还是用模型推理准确率都能轻松跑到90%以上。但真实工程图纸是什么样我见过一个项目同一套建筑图纸里门窗编号的字体就有三种图层名有中文有英文还有拼音缩写有些块被炸开过有些标注被手动改过数值。这种图纸丢给任何AI工具第一遍跑出来的结果基本没法看。Demo不会展示这些因为一旦展示观众就会问“那怎么办”而开发者往往也没有好答案。另一个关键点是Demo通常只跑一次。演示的时候开发者输入一个指令工具输出一个结果看起来流畅自然。但工程场景要求的是可重复、可批量、可回溯。你今天用同样的指令跑同一张图纸明天再跑一次结果必须一致。很多基于大模型的方案做不到这一点因为模型输出本身就有随机性温度参数稍微调一下结果就变了。工程上这是致命的。2.2 数据预处理的隐形工作量所有做过CAD数据提取的人都知道真正的工作量不在AI推理那一步而在数据预处理。一个DWG文件里包含的信息远比表面看到的复杂图层、块定义、属性、扩展数据、代理对象、自定义对象还有各种历史遗留的格式兼容问题。我试过用Python的ezdxf库读取一个中等规模的建筑图纸光是处理各种异常实体就写了上千行代码。Demo里通常直接跳过这一步或者只处理最干净的DXF。但工程里你拿到的往往是DWG而且可能是AutoCAD 2004到2024各个版本混着来。有些文件用中望CAD保存过有些用FreeCAD导出过还有些是从其他软件转换过来的里面带着一堆无法识别的代理实体。这些东西不处理干净后面的AI环节根本没法进行。更麻烦的是很多设计院或工程公司的图纸有自己内部的图层标准和命名规范但这些规范往往只存在于老员工的脑子里没有文档化。你让AI去理解一张图纸它连“这个图层为什么叫这个名字”都不知道怎么可能准确提取信息2.3 评价标准的错位Demo的评价标准通常是“看起来对”而工程的评价标准是“完全正确”。这两个标准之间的差距比大多数人想象的要大得多。举个例子AI从图纸中提取轴线编号Demo里提取出80%的轴线观众觉得“哇好厉害”。但工程上漏掉20%的轴线意味着什么意味着后面的所有计算、所有标注、所有出图都是错的。一个轴线编号错了可能导致整栋楼的定位偏移。这种评价标准的错位导致很多在Demo阶段看起来可行的方案到了工程验收阶段直接被否掉。而且工程上往往没有“部分正确”这个选项要么全对要么重来。这就对AI方案提出了极高的要求而目前的通用大模型和常规机器学习方法在CAD这种高度结构化、高度专业化的领域里很难达到工程级的准确率。3. 工程落地的四大核心障碍3.1 文件格式的深水区DWG不是你想读就能读DWG是Autodesk的私有格式虽然市面上有一些开源库能读取部分内容但完整解析DWG至今仍是一个难题。ODAOpen Design Alliance提供了一套相对完整的解决方案但它是商业产品而且价格不菲。很多团队一开始想用开源方案省钱结果发现读出来的数据缺胳膊少腿最后还是要回到ODA或者直接调用AutoCAD的COM接口。DXF虽然是公开格式但不同版本之间的差异也很大。R12的DXF和2018的DXF结构上几乎可以说是两种格式。而且DXF里有很多可选字段和扩展数据不同软件导出的DXF在细节上千差万别。我试过用同一个解析器去读AutoCAD、中望CAD和FreeCAD导出的DXF结果三者的实体数量、图层信息、甚至坐标精度都有差异。这里有一个很实际的建议如果你的项目需要处理DWG尽早评估ODA的授权成本不要在这上面浪费时间。如果只处理DXF那至少要把R12到2018各个版本的解析都测一遍确保兼容性。另外FreeCAD虽然能打开DWG和DXF但它的解析结果和AutoCAD并不完全一致用它做中间转换要特别小心。3.2 图纸语义的复杂性AI看不懂“设计意图”CAD图纸不只是几何图形它承载的是设计意图。一条线是墙还是梁一个矩形是窗户还是设备这些信息在图纸里往往是通过图层、颜色、线型、块名等间接表达的。AI模型如果只看到几何数据根本没法区分这些语义。更麻烦的是同一个几何形状在不同专业、不同项目里可能代表完全不同的东西。比如一个圆形在建筑图里可能是柱子在给排水图里可能是检查井在电气图里可能是灯具。AI模型如果没有上下文信息根本无法判断。而上下文信息往往分散在图纸的各个角落甚至在其他专业的图纸里。我试过用大模型直接读DXF的文本内容让它判断某个图层上的实体是什么。结果模型给出的答案五花八门同一个图层上的同类实体它有时候说是墙有时候说是梁。后来我改成先用规则引擎做初步分类再把分类结果喂给模型做校验准确率才勉强能用。但这也意味着纯AI方案在CAD领域基本走不通必须和传统规则方法结合。3.3 精度与一致性的硬要求工程图纸对精度的要求是毫米级的有些场景甚至是微米级。AI模型输出的坐标、尺寸、角度必须和设计意图完全一致不能有偏差。但大模型生成的内容天然带有不确定性同一个提示词跑两次结果可能就不一样。这在工程上完全不可接受。我见过一个团队尝试用AI自动标注尺寸Demo里标注得又快又好。但到了实际项目AI标注的尺寸和实际几何尺寸对不上差了0.5毫米。0.5毫米在屏幕上根本看不出来但在施工阶段就是大问题。后来他们不得不加一层校验把AI标注的结果和几何数据做比对不一致的就打回重做。这样一来效率优势就没了。一致性问题还体现在批量处理上。工程上经常需要处理成百上千张图纸AI方案必须保证每一张的处理逻辑完全一致。但大模型的输出受输入影响很大图纸稍微变一点输出就可能变很多。这种不确定性是AICAD落地最大的障碍之一。3.4 集成与工作流的现实约束就算AI方案在技术上可行把它集成到现有的设计工作流里也是一个大问题。设计院用的软件五花八门AutoCAD、中望CAD、浩辰CAD、Revit、Bentley系列每个软件都有自己的插件体系和数据格式。你的AI工具要能无缝接入这些环境才能被设计师接受。但现实是大多数AICAD的Demo都是独立运行的要么是一个网页应用要么是一个命令行工具。设计师需要导出图纸、上传、等待处理、下载、再导入这个流程本身就劝退了大部分人。而且很多设计院有严格的数据安全要求图纸不能上传到外部服务器这就把大部分云端AI方案直接排除了。本地部署的方案也有问题。大模型本地部署需要GPU而设计院的电脑通常只有集成显卡或者入门级独显。你让设计师为了用一个AI功能去升级硬件这个推广成本太高了。所以目前能在工程里落地的AICAD方案基本都是轻量级的、嵌入到现有软件里的、不需要额外硬件的。4. 从Demo到工程可行的技术路径4.1 规则引擎打底AI做增强目前最务实的方案是用规则引擎处理确定性的部分用AI处理模糊的部分。比如图纸解析、实体分类、坐标提取这些完全可以用规则搞定而且规则的结果是确定的、可重复的。AI只用在那些规则覆盖不到的地方比如自然语言指令的理解、非标准图层的推断、异常情况的处理。我自己的做法是先用规则引擎把图纸里的所有实体按图层、类型、属性做一遍结构化生成一个中间数据层。然后在这个数据层上跑AI让AI基于结构化数据做判断。这样AI的输入是干净的、确定的输出的不确定性也会大大降低。而且一旦AI出错可以回溯到规则层看看是哪一步出了问题。这种架构的另一个好处是规则部分可以持续积累。每遇到一种新的图纸格式或新的图层命名就加一条规则。时间长了规则库越来越完善AI需要处理的情况越来越少整个系统的稳定性就上来了。4.2 小模型微调而不是通用大模型通用大模型在CAD领域的表现说实话不如一个针对特定任务微调过的小模型。我试过用GPT-4级别的模型做图纸实体分类准确率大概在70%左右。后来用了几百张标注好的图纸微调了一个BERT级别的模型准确率直接上到92%。而且小模型的推理速度快、资源占用低可以本地部署完全满足设计院的数据安全要求。微调的关键是数据。CAD领域的标注数据很难搞因为需要既懂CAD又懂AI的人来标。我的做法是先用规则引擎跑一遍把高置信度的结果作为训练数据低置信度的让人工复核。这样迭代几轮就能积累出一批高质量的标注数据。虽然前期投入大但一旦模型训好后面的收益是持续的。4.3 人机协同而不是全自动工程上完全自动化的AI方案目前基本不可行。更现实的路径是人机协同AI做初步处理人做最终确认。比如AI自动提取图纸信息然后在一个界面里展示提取结果设计师可以快速核对和修改。这样既利用了AI的效率又保证了工程的准确性。我做过一个图纸信息提取的工具AI提取完后会生成一个报告标出哪些地方置信度高、哪些地方置信度低。设计师只需要重点看低置信度的部分高置信度的快速扫一眼就行。实测下来设计师的工作量减少了60%以上而且因为有人工把关准确率接近100%。这种方案虽然不够“智能”但它是能真正落地的。4.4 格式转换的中间层设计如果你的项目涉及DWG到其他格式的转换比如DWG转SHP、DXF导入Allegro、EXB转DWG这些一定要设计一个中间层。不要试图直接从源格式转到目标格式而是先把源格式解析成一种通用的中间表示再从中间表示生成目标格式。这样做的好处是每增加一种新格式只需要写一个解析器和一个生成器而不是为每对格式写一个转换器。中间层的设计也有讲究。我建议用JSON或者Protocol Buffers来定义中间格式把几何数据、图层信息、属性数据、扩展数据都包含进去。几何数据用OCCTOpen CASCADE Technology的格式来存这样后续做几何运算也方便。图层和属性用键值对存灵活且容易扩展。5. 实操中的关键细节与避坑指南5.1 DWG读取的实操要点如果你决定用ODA来读DWG有几个细节一定要注意。第一ODA的版本要和你的DWG文件版本匹配虽然ODA声称向下兼容但实测中老版本ODA读新版本DWG经常出问题。第二ODA的授权是按年收费的而且价格不低预算里一定要算进去。第三ODA的API文档虽然全但示例代码不多很多坑要自己踩。如果预算有限只能先用开源方案顶着那我的建议是只处理DXF不碰DWG。如果客户坚持要DWG那就先用FreeCAD或者LibreCAD把DWG转成DXF再处理DXF。但要注意这种转换会丢失一些信息比如代理对象和自定义对象。转换前一定要和客户确认这些信息是否可以丢失。还有一个坑是字符编码。DWG和DXF里的文字编码很复杂有ANSI、有UTF-8、有GBK还有各种代码页。我遇到过图纸里的中文图层名读出来是乱码的情况排查了半天才发现是编码问题。建议在读取文字时先检测编码再统一转成UTF-8处理。5.2 图层与块处理的常见问题图层是CAD图纸里最重要的语义信息之一但也是最混乱的。我见过一个项目同一个图层在不同图纸里有不同的含义因为设计师复制粘贴的时候没改图层名。这种情况下单纯靠图层名做判断肯定会出错。我的做法是图层名只作为参考特征之一还要结合实体的几何特征、颜色、线型、所在位置来综合判断。比如一个图层叫“WALL”里面的实体都是直线颜色是白色那大概率是墙。但如果里面出现了圆和弧那就要怀疑了可能是设计师放错了图层。块的处理更麻烦。块有嵌套块、有属性块、有动态块还有匿名块。嵌套块要递归展开属性块要提取属性值动态块要处理可见性状态。我建议在解析阶段就把所有块展开成基本实体同时保留块的层级关系和属性信息。这样后续处理会简单很多。5.3 AI模型选型与调参经验如果你要用大模型做CAD相关的任务我的经验是不要直接用通用模型一定要做提示词工程。CAD领域的术语和表达方式很特殊通用模型经常理解错。比如“标注”这个词在CAD里特指尺寸标注但通用模型可能理解成文字注释。提示词里要把这些术语的定义写清楚最好给几个例子。温度参数要调低建议在0.1到0.3之间。CAD任务需要的是确定性不是创造性。温度高了模型就会“发挥”输出一些看起来合理但实际错误的内容。我试过温度0.7的时候模型把轴线编号从“1、2、3”改成了“A、B、C”理由是“这样更符合建筑制图规范”。这种“自作聪明”在工程上是灾难。如果任务涉及几何计算不要让模型直接算而是让模型生成计算代码然后执行代码得到结果。比如让模型生成一段Python代码来计算两个点的距离而不是让模型直接说出距离。这样既利用了模型的代码生成能力又保证了计算精度。5.4 批量处理的性能优化工程上经常需要批量处理成百上千张图纸性能是一个大问题。我做过一个测试用单线程处理100张中等规模的DXF图纸每张平均耗时3秒总共5分钟。这个速度在Demo里可以接受但在工程上太慢了。设计师等5分钟才能看到结果体验很差。优化的方向有几个。第一用多进程而不是多线程因为Python的GIL会限制多线程的性能。第二把耗时的操作比如文件解析、几何计算用C或者Rust重写Python只做调度。第三如果AI推理是瓶颈考虑用ONNX Runtime或者TensorRT来加速。第四对于重复的图纸可以做缓存相同的输入直接返回缓存结果。还有一个容易被忽略的点是内存管理。处理大图纸时内存占用可能达到几个GB。如果不及时释放批量处理跑到一半就会OOM。建议每处理完一张图纸就手动触发垃圾回收并监控内存使用情况。6. 常见问题速查与排查思路6.1 文件读取类问题问题现象可能原因排查方法解决方案读取DWG时报错“不支持的版本”ODA版本与DWG版本不匹配查看DWG文件头中的版本号升级ODA或先用高版本CAD另存为低版本DXF读取后实体数量不对DXF版本差异或解析器bug用AutoCAD打开对比实体数量换用更成熟的解析库或针对不同版本做适配中文文字显示为乱码字符编码不匹配检查DXF中的$DWGCODEPAGE变量根据代码页做编码转换统一转UTF-8块参照无法展开嵌套块或动态块检查块定义中的实体类型递归展开嵌套块处理动态块的可见性状态代理实体无法识别自定义对象或第三方软件生成查看实体类型名是否以“ACAD_PROXY”开头尝试用ODA的代理实体支持或跳过并记录6.2 AI推理类问题问题现象可能原因排查方法解决方案同一输入两次输出不同模型温度参数过高检查温度设置温度调到0.1-0.3或设置随机种子模型输出格式不稳定提示词不够明确检查提示词中的格式要求在提示词中给出明确的输出格式示例专业术语理解错误通用模型缺乏领域知识测试模型对关键术语的理解在提示词中定义术语或微调领域模型几何计算结果偏差模型直接计算导致精度损失对比模型输出与精确计算值让模型生成计算代码执行代码得到结果推理速度太慢模型太大或硬件不足监控GPU/CPU使用率换用小模型或用ONNX/TensorRT加速6.3 工程集成类问题问题现象可能原因排查方法解决方案设计师不愿意用操作流程太复杂观察设计师的实际操作把工具嵌入现有软件减少操作步骤数据安全审查不通过图纸上传到外部服务器检查数据流向改为本地部署或只上传脱敏后的数据批量处理中途崩溃内存泄漏或OOM监控内存使用曲线分批处理及时释放内存加异常捕获结果无法复现依赖了外部服务或随机因素检查是否有网络调用或随机数固定随机种子缓存外部服务结果与其他插件冲突命名空间或依赖库冲突检查加载的插件列表隔离运行环境或用容器化部署7. 一些个人体会和后续方向做AICAD这几年我最大的体会是这个领域不缺想法缺的是对工程细节的敬畏。很多团队拿着互联网那套“快速迭代、容忍错误”的思路来做CAD工具结果就是Demo很漂亮工程用不了。CAD是制造业和建筑业的基础它的错误成本太高了高到没有任何一个环节能容忍“差不多就行”。另一个体会是AI在CAD领域的作用短期内更多是“辅助”而不是“替代”。它能帮设计师省掉一些重复劳动能帮工程师快速提取一些信息但最终的判断和决策还是要人来做。那些宣称“AI自动出图”的方案要么是在极窄的场景里要么是在骗投资人的钱。后续如果继续做这个方向我会重点关注几个点。一是轻量级的本地模型能在普通办公电脑上跑不需要额外硬件。二是和现有CAD软件的深度集成让设计师感觉不到AI的存在但效率确实提升了。三是建立一套CAD领域的评测标准让不同的AI方案能有一个公平的比较基准。这些事情都不容易但比做一个好看的Demo有意义得多。最后分享一个很实用的小技巧如果你在做一个CAD相关的AI工具先别急着写代码花一周时间坐在设计师旁边看他们怎么工作听他们抱怨什么。你会发现他们真正需要的往往和你最初想做的完全不是一回事。
AI+CAD从Demo到工程落地：DWG解析、图纸语义与精度一致性四大障碍及可行技术路径
1. 从Demo到工程AICAD落地的真实鸿沟做过CAD相关工具开发的人都有一个共同感受演示视频里AI自动生成图纸、自动标注、自动改图看起来无所不能但一旦放到真实工程项目里立刻就露馅了。这不是某一个团队的问题而是整个行业目前面临的系统性困境。我从几年前开始接触CAD二次开发后来逐步把AI能力引入到图纸处理流程中踩过的坑可以说覆盖了从文件解析到工程交付的每一个环节。这篇文章不打算讲什么宏大的趋势只想把“为什么Demo满天飞、工程却走不通”这件事拆开揉碎从技术细节和工程实践两个维度把真实的原因和可能的出路讲清楚。先明确一下讨论范围。这里说的“AICAD”指的是利用AI大模型、机器学习或规则引擎对CAD图纸进行理解、生成、修改、转换或校验的一类工作。典型场景包括从DWG/DXF文件中提取结构化信息、根据自然语言描述生成参数化模型、批量修改图纸中的图层与标注、将CAD数据转换到其他格式比如GIS用的SHP、以及在设计过程中提供智能辅助。这些场景听起来都很美好但每一个从Demo走向工程的过程都会遇到几乎相同的障碍。适合谁看如果你正在做CAD相关的工具开发、正在评估AI能不能用在自己的设计流程里、或者单纯好奇为什么那些炫酷的演示到了自己手里就跑不起来那这篇内容应该能给你一些实在的参考。我不会只讲“有问题”还会讲“问题出在哪”以及“目前能怎么绕”。2. 为什么Demo看起来总是很美好2.1 Demo的天然优势受控环境下的完美表现Demo之所以好看核心原因是它在一个极度受控的环境里运行。开发者会精心挑选一个格式规范、图层清晰、没有多余嵌套的DWG文件然后用一套针对这个文件调好的参数去跑。比如展示“AI自动识别图纸中的门窗编号”Demo里用的图纸可能只有标准图层、标准块名、标准文字样式甚至连线宽都是统一的。这种情况下无论是用规则匹配还是用模型推理准确率都能轻松跑到90%以上。但真实工程图纸是什么样我见过一个项目同一套建筑图纸里门窗编号的字体就有三种图层名有中文有英文还有拼音缩写有些块被炸开过有些标注被手动改过数值。这种图纸丢给任何AI工具第一遍跑出来的结果基本没法看。Demo不会展示这些因为一旦展示观众就会问“那怎么办”而开发者往往也没有好答案。另一个关键点是Demo通常只跑一次。演示的时候开发者输入一个指令工具输出一个结果看起来流畅自然。但工程场景要求的是可重复、可批量、可回溯。你今天用同样的指令跑同一张图纸明天再跑一次结果必须一致。很多基于大模型的方案做不到这一点因为模型输出本身就有随机性温度参数稍微调一下结果就变了。工程上这是致命的。2.2 数据预处理的隐形工作量所有做过CAD数据提取的人都知道真正的工作量不在AI推理那一步而在数据预处理。一个DWG文件里包含的信息远比表面看到的复杂图层、块定义、属性、扩展数据、代理对象、自定义对象还有各种历史遗留的格式兼容问题。我试过用Python的ezdxf库读取一个中等规模的建筑图纸光是处理各种异常实体就写了上千行代码。Demo里通常直接跳过这一步或者只处理最干净的DXF。但工程里你拿到的往往是DWG而且可能是AutoCAD 2004到2024各个版本混着来。有些文件用中望CAD保存过有些用FreeCAD导出过还有些是从其他软件转换过来的里面带着一堆无法识别的代理实体。这些东西不处理干净后面的AI环节根本没法进行。更麻烦的是很多设计院或工程公司的图纸有自己内部的图层标准和命名规范但这些规范往往只存在于老员工的脑子里没有文档化。你让AI去理解一张图纸它连“这个图层为什么叫这个名字”都不知道怎么可能准确提取信息2.3 评价标准的错位Demo的评价标准通常是“看起来对”而工程的评价标准是“完全正确”。这两个标准之间的差距比大多数人想象的要大得多。举个例子AI从图纸中提取轴线编号Demo里提取出80%的轴线观众觉得“哇好厉害”。但工程上漏掉20%的轴线意味着什么意味着后面的所有计算、所有标注、所有出图都是错的。一个轴线编号错了可能导致整栋楼的定位偏移。这种评价标准的错位导致很多在Demo阶段看起来可行的方案到了工程验收阶段直接被否掉。而且工程上往往没有“部分正确”这个选项要么全对要么重来。这就对AI方案提出了极高的要求而目前的通用大模型和常规机器学习方法在CAD这种高度结构化、高度专业化的领域里很难达到工程级的准确率。3. 工程落地的四大核心障碍3.1 文件格式的深水区DWG不是你想读就能读DWG是Autodesk的私有格式虽然市面上有一些开源库能读取部分内容但完整解析DWG至今仍是一个难题。ODAOpen Design Alliance提供了一套相对完整的解决方案但它是商业产品而且价格不菲。很多团队一开始想用开源方案省钱结果发现读出来的数据缺胳膊少腿最后还是要回到ODA或者直接调用AutoCAD的COM接口。DXF虽然是公开格式但不同版本之间的差异也很大。R12的DXF和2018的DXF结构上几乎可以说是两种格式。而且DXF里有很多可选字段和扩展数据不同软件导出的DXF在细节上千差万别。我试过用同一个解析器去读AutoCAD、中望CAD和FreeCAD导出的DXF结果三者的实体数量、图层信息、甚至坐标精度都有差异。这里有一个很实际的建议如果你的项目需要处理DWG尽早评估ODA的授权成本不要在这上面浪费时间。如果只处理DXF那至少要把R12到2018各个版本的解析都测一遍确保兼容性。另外FreeCAD虽然能打开DWG和DXF但它的解析结果和AutoCAD并不完全一致用它做中间转换要特别小心。3.2 图纸语义的复杂性AI看不懂“设计意图”CAD图纸不只是几何图形它承载的是设计意图。一条线是墙还是梁一个矩形是窗户还是设备这些信息在图纸里往往是通过图层、颜色、线型、块名等间接表达的。AI模型如果只看到几何数据根本没法区分这些语义。更麻烦的是同一个几何形状在不同专业、不同项目里可能代表完全不同的东西。比如一个圆形在建筑图里可能是柱子在给排水图里可能是检查井在电气图里可能是灯具。AI模型如果没有上下文信息根本无法判断。而上下文信息往往分散在图纸的各个角落甚至在其他专业的图纸里。我试过用大模型直接读DXF的文本内容让它判断某个图层上的实体是什么。结果模型给出的答案五花八门同一个图层上的同类实体它有时候说是墙有时候说是梁。后来我改成先用规则引擎做初步分类再把分类结果喂给模型做校验准确率才勉强能用。但这也意味着纯AI方案在CAD领域基本走不通必须和传统规则方法结合。3.3 精度与一致性的硬要求工程图纸对精度的要求是毫米级的有些场景甚至是微米级。AI模型输出的坐标、尺寸、角度必须和设计意图完全一致不能有偏差。但大模型生成的内容天然带有不确定性同一个提示词跑两次结果可能就不一样。这在工程上完全不可接受。我见过一个团队尝试用AI自动标注尺寸Demo里标注得又快又好。但到了实际项目AI标注的尺寸和实际几何尺寸对不上差了0.5毫米。0.5毫米在屏幕上根本看不出来但在施工阶段就是大问题。后来他们不得不加一层校验把AI标注的结果和几何数据做比对不一致的就打回重做。这样一来效率优势就没了。一致性问题还体现在批量处理上。工程上经常需要处理成百上千张图纸AI方案必须保证每一张的处理逻辑完全一致。但大模型的输出受输入影响很大图纸稍微变一点输出就可能变很多。这种不确定性是AICAD落地最大的障碍之一。3.4 集成与工作流的现实约束就算AI方案在技术上可行把它集成到现有的设计工作流里也是一个大问题。设计院用的软件五花八门AutoCAD、中望CAD、浩辰CAD、Revit、Bentley系列每个软件都有自己的插件体系和数据格式。你的AI工具要能无缝接入这些环境才能被设计师接受。但现实是大多数AICAD的Demo都是独立运行的要么是一个网页应用要么是一个命令行工具。设计师需要导出图纸、上传、等待处理、下载、再导入这个流程本身就劝退了大部分人。而且很多设计院有严格的数据安全要求图纸不能上传到外部服务器这就把大部分云端AI方案直接排除了。本地部署的方案也有问题。大模型本地部署需要GPU而设计院的电脑通常只有集成显卡或者入门级独显。你让设计师为了用一个AI功能去升级硬件这个推广成本太高了。所以目前能在工程里落地的AICAD方案基本都是轻量级的、嵌入到现有软件里的、不需要额外硬件的。4. 从Demo到工程可行的技术路径4.1 规则引擎打底AI做增强目前最务实的方案是用规则引擎处理确定性的部分用AI处理模糊的部分。比如图纸解析、实体分类、坐标提取这些完全可以用规则搞定而且规则的结果是确定的、可重复的。AI只用在那些规则覆盖不到的地方比如自然语言指令的理解、非标准图层的推断、异常情况的处理。我自己的做法是先用规则引擎把图纸里的所有实体按图层、类型、属性做一遍结构化生成一个中间数据层。然后在这个数据层上跑AI让AI基于结构化数据做判断。这样AI的输入是干净的、确定的输出的不确定性也会大大降低。而且一旦AI出错可以回溯到规则层看看是哪一步出了问题。这种架构的另一个好处是规则部分可以持续积累。每遇到一种新的图纸格式或新的图层命名就加一条规则。时间长了规则库越来越完善AI需要处理的情况越来越少整个系统的稳定性就上来了。4.2 小模型微调而不是通用大模型通用大模型在CAD领域的表现说实话不如一个针对特定任务微调过的小模型。我试过用GPT-4级别的模型做图纸实体分类准确率大概在70%左右。后来用了几百张标注好的图纸微调了一个BERT级别的模型准确率直接上到92%。而且小模型的推理速度快、资源占用低可以本地部署完全满足设计院的数据安全要求。微调的关键是数据。CAD领域的标注数据很难搞因为需要既懂CAD又懂AI的人来标。我的做法是先用规则引擎跑一遍把高置信度的结果作为训练数据低置信度的让人工复核。这样迭代几轮就能积累出一批高质量的标注数据。虽然前期投入大但一旦模型训好后面的收益是持续的。4.3 人机协同而不是全自动工程上完全自动化的AI方案目前基本不可行。更现实的路径是人机协同AI做初步处理人做最终确认。比如AI自动提取图纸信息然后在一个界面里展示提取结果设计师可以快速核对和修改。这样既利用了AI的效率又保证了工程的准确性。我做过一个图纸信息提取的工具AI提取完后会生成一个报告标出哪些地方置信度高、哪些地方置信度低。设计师只需要重点看低置信度的部分高置信度的快速扫一眼就行。实测下来设计师的工作量减少了60%以上而且因为有人工把关准确率接近100%。这种方案虽然不够“智能”但它是能真正落地的。4.4 格式转换的中间层设计如果你的项目涉及DWG到其他格式的转换比如DWG转SHP、DXF导入Allegro、EXB转DWG这些一定要设计一个中间层。不要试图直接从源格式转到目标格式而是先把源格式解析成一种通用的中间表示再从中间表示生成目标格式。这样做的好处是每增加一种新格式只需要写一个解析器和一个生成器而不是为每对格式写一个转换器。中间层的设计也有讲究。我建议用JSON或者Protocol Buffers来定义中间格式把几何数据、图层信息、属性数据、扩展数据都包含进去。几何数据用OCCTOpen CASCADE Technology的格式来存这样后续做几何运算也方便。图层和属性用键值对存灵活且容易扩展。5. 实操中的关键细节与避坑指南5.1 DWG读取的实操要点如果你决定用ODA来读DWG有几个细节一定要注意。第一ODA的版本要和你的DWG文件版本匹配虽然ODA声称向下兼容但实测中老版本ODA读新版本DWG经常出问题。第二ODA的授权是按年收费的而且价格不低预算里一定要算进去。第三ODA的API文档虽然全但示例代码不多很多坑要自己踩。如果预算有限只能先用开源方案顶着那我的建议是只处理DXF不碰DWG。如果客户坚持要DWG那就先用FreeCAD或者LibreCAD把DWG转成DXF再处理DXF。但要注意这种转换会丢失一些信息比如代理对象和自定义对象。转换前一定要和客户确认这些信息是否可以丢失。还有一个坑是字符编码。DWG和DXF里的文字编码很复杂有ANSI、有UTF-8、有GBK还有各种代码页。我遇到过图纸里的中文图层名读出来是乱码的情况排查了半天才发现是编码问题。建议在读取文字时先检测编码再统一转成UTF-8处理。5.2 图层与块处理的常见问题图层是CAD图纸里最重要的语义信息之一但也是最混乱的。我见过一个项目同一个图层在不同图纸里有不同的含义因为设计师复制粘贴的时候没改图层名。这种情况下单纯靠图层名做判断肯定会出错。我的做法是图层名只作为参考特征之一还要结合实体的几何特征、颜色、线型、所在位置来综合判断。比如一个图层叫“WALL”里面的实体都是直线颜色是白色那大概率是墙。但如果里面出现了圆和弧那就要怀疑了可能是设计师放错了图层。块的处理更麻烦。块有嵌套块、有属性块、有动态块还有匿名块。嵌套块要递归展开属性块要提取属性值动态块要处理可见性状态。我建议在解析阶段就把所有块展开成基本实体同时保留块的层级关系和属性信息。这样后续处理会简单很多。5.3 AI模型选型与调参经验如果你要用大模型做CAD相关的任务我的经验是不要直接用通用模型一定要做提示词工程。CAD领域的术语和表达方式很特殊通用模型经常理解错。比如“标注”这个词在CAD里特指尺寸标注但通用模型可能理解成文字注释。提示词里要把这些术语的定义写清楚最好给几个例子。温度参数要调低建议在0.1到0.3之间。CAD任务需要的是确定性不是创造性。温度高了模型就会“发挥”输出一些看起来合理但实际错误的内容。我试过温度0.7的时候模型把轴线编号从“1、2、3”改成了“A、B、C”理由是“这样更符合建筑制图规范”。这种“自作聪明”在工程上是灾难。如果任务涉及几何计算不要让模型直接算而是让模型生成计算代码然后执行代码得到结果。比如让模型生成一段Python代码来计算两个点的距离而不是让模型直接说出距离。这样既利用了模型的代码生成能力又保证了计算精度。5.4 批量处理的性能优化工程上经常需要批量处理成百上千张图纸性能是一个大问题。我做过一个测试用单线程处理100张中等规模的DXF图纸每张平均耗时3秒总共5分钟。这个速度在Demo里可以接受但在工程上太慢了。设计师等5分钟才能看到结果体验很差。优化的方向有几个。第一用多进程而不是多线程因为Python的GIL会限制多线程的性能。第二把耗时的操作比如文件解析、几何计算用C或者Rust重写Python只做调度。第三如果AI推理是瓶颈考虑用ONNX Runtime或者TensorRT来加速。第四对于重复的图纸可以做缓存相同的输入直接返回缓存结果。还有一个容易被忽略的点是内存管理。处理大图纸时内存占用可能达到几个GB。如果不及时释放批量处理跑到一半就会OOM。建议每处理完一张图纸就手动触发垃圾回收并监控内存使用情况。6. 常见问题速查与排查思路6.1 文件读取类问题问题现象可能原因排查方法解决方案读取DWG时报错“不支持的版本”ODA版本与DWG版本不匹配查看DWG文件头中的版本号升级ODA或先用高版本CAD另存为低版本DXF读取后实体数量不对DXF版本差异或解析器bug用AutoCAD打开对比实体数量换用更成熟的解析库或针对不同版本做适配中文文字显示为乱码字符编码不匹配检查DXF中的$DWGCODEPAGE变量根据代码页做编码转换统一转UTF-8块参照无法展开嵌套块或动态块检查块定义中的实体类型递归展开嵌套块处理动态块的可见性状态代理实体无法识别自定义对象或第三方软件生成查看实体类型名是否以“ACAD_PROXY”开头尝试用ODA的代理实体支持或跳过并记录6.2 AI推理类问题问题现象可能原因排查方法解决方案同一输入两次输出不同模型温度参数过高检查温度设置温度调到0.1-0.3或设置随机种子模型输出格式不稳定提示词不够明确检查提示词中的格式要求在提示词中给出明确的输出格式示例专业术语理解错误通用模型缺乏领域知识测试模型对关键术语的理解在提示词中定义术语或微调领域模型几何计算结果偏差模型直接计算导致精度损失对比模型输出与精确计算值让模型生成计算代码执行代码得到结果推理速度太慢模型太大或硬件不足监控GPU/CPU使用率换用小模型或用ONNX/TensorRT加速6.3 工程集成类问题问题现象可能原因排查方法解决方案设计师不愿意用操作流程太复杂观察设计师的实际操作把工具嵌入现有软件减少操作步骤数据安全审查不通过图纸上传到外部服务器检查数据流向改为本地部署或只上传脱敏后的数据批量处理中途崩溃内存泄漏或OOM监控内存使用曲线分批处理及时释放内存加异常捕获结果无法复现依赖了外部服务或随机因素检查是否有网络调用或随机数固定随机种子缓存外部服务结果与其他插件冲突命名空间或依赖库冲突检查加载的插件列表隔离运行环境或用容器化部署7. 一些个人体会和后续方向做AICAD这几年我最大的体会是这个领域不缺想法缺的是对工程细节的敬畏。很多团队拿着互联网那套“快速迭代、容忍错误”的思路来做CAD工具结果就是Demo很漂亮工程用不了。CAD是制造业和建筑业的基础它的错误成本太高了高到没有任何一个环节能容忍“差不多就行”。另一个体会是AI在CAD领域的作用短期内更多是“辅助”而不是“替代”。它能帮设计师省掉一些重复劳动能帮工程师快速提取一些信息但最终的判断和决策还是要人来做。那些宣称“AI自动出图”的方案要么是在极窄的场景里要么是在骗投资人的钱。后续如果继续做这个方向我会重点关注几个点。一是轻量级的本地模型能在普通办公电脑上跑不需要额外硬件。二是和现有CAD软件的深度集成让设计师感觉不到AI的存在但效率确实提升了。三是建立一套CAD领域的评测标准让不同的AI方案能有一个公平的比较基准。这些事情都不容易但比做一个好看的Demo有意义得多。最后分享一个很实用的小技巧如果你在做一个CAD相关的AI工具先别急着写代码花一周时间坐在设计师旁边看他们怎么工作听他们抱怨什么。你会发现他们真正需要的往往和你最初想做的完全不是一回事。
