1. 为什么“AI + CAD”的Demo看起来很美

1.1 一个被反复验证的错觉

过去两年，我参与过三个和AI辅助CAD相关的项目，有内部的效率工具，也有对外的产品原型。几乎每一次，团队都会在头两周做出一个让人兴奋的Demo：上传一张DWG图纸，AI自动识别出墙线、标注、图层，甚至能根据自然语言描述生成一段简单的二维轮廓。演示给业务方看的时候，反馈基本都是“这个方向对”“赶紧落地”。

然后，真正的工程化开始了，进度条就卡住了。

这不是个别现象。我在几个技术社区里和做类似事情的人聊过，大家的共识非常一致：AI和CAD结合，Demo阶段的门槛远比想象中低，但工程化的门槛远比想象中高。低在哪里？低在你可以用Python的ezdxf库读一个DXF文件，调一个大模型API，把图层名和实体类型丢进去，让它输出一段结构化描述，再画几张图，就是一个能跑通的Demo。高在哪里？高在真实的设计流程里，图纸不是孤立的文件，它背后有图层规范、有块引用、有外部参照、有版本迭代、有协同需求，还有一堆历史遗留的“脏数据”。

1.2 核心矛盾：AI的模糊性和CAD的精确性

这个矛盾的根源，我认为是AI的模糊推理和CAD的精确表达之间存在天然的对立。

CAD的本质是什么？是精确的几何定义。一条线段的起点坐标是(100.0, 200.0)，终点是(300.0, 200.0)，图层是“WALL”，线型是“CONTINUOUS”，线宽是0.3mm。这些数据不允许有歧义。而AI大模型擅长的是什么？是概率生成。你问它“这张图里有多少个房间”，它可能回答“大约5个”，但CAD工程师需要的是“5个，分别是A、B、C、D、E，每个房间的闭合多段线句柄是……”。

我见过一个典型的翻车案例：团队用视觉模型去识别图纸中的门窗数量，Demo阶段准确率能到85%，大家觉得不错。但到了实际项目里，设计师发现AI把一些装饰性的弧线也识别成了门，把图例里的符号也算进了数量。85%的准确率在演示时是亮点，在工程里就是灾难——因为设计师需要花更多时间去核对和修正，还不如自己数。

1.3 谁在真正推动这件事

目前在这个方向上投入的，大致有三类人。

第一类是CAD软件厂商，比如Autodesk、达索、西门子这些。他们的优势是掌握底层格式和API，能做深度集成，但劣势是船大难掉头，AI功能往往作为附加模块存在，迭代速度慢。第二类是AI创业公司，他们擅长模型和交互，但对CAD的行业know-how理解不够，做出来的东西经常“看起来能用，实际用起来别扭”。第三类是一线工程师自己，用Python、FreeCAD、LibreCAD这些开源工具攒工具链，解决自己工作流里的具体问题。这类人做出来的东西往往最接地气，但受限于个人精力，很难产品化。

我自己的定位属于第三类。下面要聊的，都是从这个视角出发的实操经验。

2. 拆解CAD数据的真实复杂度

2.1 DWG和DXF：不只是文件格式的区别

很多人刚开始做的时候，会觉得DWG和DXF差不多，反正都能读。但实际处理起来，差别很大。

DWG是AutoCAD的原生二进制格式，结构封闭，官方没有公开完整的格式规范。你能找到的解析库，要么是逆向工程出来的，要么是调用AutoCAD的COM接口。前者不稳定，后者依赖AutoCAD环境。DXF是交换格式，有公开的文档，文本结构，解析起来相对友好。但问题是，很多设计院交付的图纸是DWG，而且版本很杂，从R14到2018都有。

我试过用ezdxf读DWG，结论是：不靠谱。ezdxf官方文档明确说了它主要处理DXF，对DWG的支持是通过odafc这样的外部转换器实现的。也就是说，你得先装一个ODA File Converter，把DWG转成DXF，再用ezdxf读。这个链路在Demo里没问题，在工程里就多了一个依赖和故障点。

注意：如果你的场景必须处理DWG，优先考虑用ODA（Open Design Alliance）的SDK，或者直接调用AutoCAD的ActiveX接口。前者需要商业授权，后者需要目标机器装AutoCAD。没有银弹。

2.2 图层、块、外部参照：三个容易被忽略的坑

图层是CAD里最基础的组织方式，但也是最容易被AI忽略的语义来源。一个训练有素的CAD团队，图层命名是有规范的：WALL、DOOR、WINDOW、DIM、TEXT。但现实是，我见过图层名叫“0”“图层1”“新建图层”的图纸，也见过把所有东西都画在“0”层上的。AI如果只依赖几何信息，不结合图层语义，准确率会大打折扣。

块（Block）是另一个坑。CAD里的门窗、家具、设备经常以块的形式存在。一个块定义可能被引用几十次，每次引用有不同的缩放和旋转。AI如果只看到炸开后的线段和圆弧，就丢失了“这是一个门”的语义。但如果你不炸开块，很多几何算法又没法直接处理。我的做法是：先提取块引用的元数据（块名、插入点、缩放、旋转），再决定是否炸开。块名往往包含关键信息，比如“DOOR_900”就比一堆线段有用得多。

外部参照（Xref）更麻烦。一张总图可能引用了十几个外部文件，每个文件又有自己的图层和块。AI处理的时候，如果只读主文件，就会丢失大量信息。但把所有Xref都绑定进来，文件体积又会爆炸。我的经验是：在预处理阶段就把Xref绑定并清理，生成一个“扁平化”的中间文件，后续所有AI处理都基于这个中间文件。这样虽然损失了部分结构信息，但保证了处理的完整性。

2.3 几何精度与容差：AI不懂“差不多”

CAD里的几何计算是有容差的。两条线是否相交，取决于你设定的容差是1e-6还是1e-3。AI模型输出的坐标往往是浮点数，精度不确定。我遇到过AI生成的轮廓，端点坐标差了0.001mm，人眼看不出，但CAD的闭合多段线判定就失败了。

解决办法是在AI输出之后加一层几何规整化：把所有坐标按容差吸附到网格，强制闭合多段线的首尾点一致，清理重复顶点。这一步看起来简单，但不做的话，后续的布尔运算、面积计算都会出问题。

3. 从Demo到工程：四个必须跨过的坎

3.1 数据预处理的工程量被严重低估

我做过一个统计：在一个AI辅助审图的项目里，数据预处理占了总工作量的60%以上。这个比例在Demo阶段是感知不到的，因为Demo用的都是“干净”的样本。但真实图纸的脏数据五花八门：

• 重复实体：同一条线画了两遍，坐标完全一样
• 零长度线段：起点和终点重合
• 微小线段：长度小于0.1mm，可能是绘图时的误操作
• 未闭合的多段线：本该闭合的轮廓差了零点几毫米
• 文字乱码：字体缺失导致显示为问号
• 图层状态混乱：冻结、锁定、关闭的图层混在一起

这些问题的处理，没有统一的方案，只能根据具体场景写规则。我的建议是：在项目初期就建立一个“脏数据样本库”，每遇到一种新问题就加进去，逐步完善预处理流水线。这个库的价值，比AI模型本身还大。

3.2 模型选型：不是越大越好

很多团队一上来就想用大模型，觉得参数越多效果越好。但在CAD场景里，通用大模型往往不如小模型+规则。

举个例子：识别图纸中的文字。通用OCR模型对印刷体效果不错，但CAD图纸里的文字有旋转、有镜像、有特殊字体（比如hz-s这种工程字体），还有大量被线条穿过的情况。我试过几个主流OCR，直接跑准确率不到70%。后来换了一个专门针对工程图纸微调过的小模型，加上基于图层和文字高度的过滤规则，准确率到了92%。

再比如：判断两条线是否构成墙体。大模型可能会根据上下文“猜”，但一个简单的规则——两条平行线，间距在200mm到400mm之间，图层名包含WALL，且中间没有其他实体——就能达到很高的准确率。规则的好处是可解释、可调试、可复现。

我的观点是：在CAD这个领域，AI应该做它擅长的模糊识别和语义理解，精确的几何判断交给规则和算法。两者结合，比纯AI或纯规则都好。

3.3 交互设计：AI不能替设计师做决定

我见过一些产品，试图让AI全自动完成图纸处理，设计师只需要点“确认”。这个思路在Demo里很酷，在工程里很危险。

CAD设计的本质是责任。一张图纸盖了章，设计师是要负责的。AI如果自动改了一条线，出了问题谁负责？所以，AI的定位应该是“副驾驶”，而不是“自动驾驶”。它应该做的是：提出建议、标注可疑点、提供备选方案，最终决定权在设计师手里。

具体到交互上，我的做法是：AI处理完的结果，用高亮、批注、图层隔离的方式呈现，设计师可以逐条接受或拒绝。接受的操作要记录到操作日志里，方便追溯。这个设计看起来增加了操作步骤，但实际上降低了设计师的心理负担，反而提高了采纳率。

3.4 性能与稳定性：别让设计师等

CAD图纸动辄几十兆，实体数量几万到几十万。AI模型推理需要时间，如果每次操作都要等十几秒，设计师就会放弃使用。

我的优化经验是：

• 分层处理：先处理当前视图范围内的实体，后台异步处理全图
• 缓存中间结果：预处理后的几何数据、AI推理结果都缓存起来，避免重复计算
• 增量更新：图纸修改后，只重新处理变化的区域
• 降级策略：AI服务不可用时，自动切换到规则引擎，保证基本功能可用

这些优化在Demo里都不需要，但在工程里是必须的。我见过一个项目，功能做得很好，但因为每次操作要等8秒，最后没人用。

4. 一个可复现的最小工程化方案

4.1 技术栈选择与理由

基于我自己的实践，推荐一套最小可用的技术栈：

这套栈的好处是全部可以本地部署，不依赖外部服务，适合对数据安全有要求的场景。缺点是AI能力受限于本地模型，但可以通过API补充。

4.2 预处理流水线的搭建

预处理的目标是：把任意来源的CAD文件，转换成干净、结构化、AI友好的中间格式。

我的一般流程是：

1. 格式转换：DWG → DXF（用ODA Converter），统一到DXF R2018
2. 清理：删除重复实体、零长度线段、微小线段
3. 图层规整：根据图层名映射到标准分类（墙体、门窗、标注、文字、其他）
4. 块处理：提取块引用元数据，选择性炸开
5. 几何规整：坐标吸附、多段线闭合、清理重复顶点
6. 导出中间格式：JSON + GeoJSON，包含几何和语义信息

这个流水线我用Python实现，核心代码大概300行。关键是要可配置，不同项目对清理的力度要求不同。

4.3 AI推理层的设计

AI推理层我分成两个模块：

识别模块：用微调过的小模型做实体分类。输入是几何特征（坐标、长度、角度、图层），输出是类别标签。这个模块的准确率取决于训练数据，我一般会准备500到1000个标注样本，覆盖常见实体类型。

理解模块：用大模型做语义理解。比如设计师说“把客厅的墙加厚到200”，大模型负责解析意图，输出结构化的操作指令（目标图层、操作类型、参数），然后由规则引擎执行。这个模块的关键是提示词工程，要把CAD的领域知识写进系统提示里。

提示：大模型的输出一定要做校验。我遇到过模型输出“把墙厚改为-200”的情况，如果不校验，执行后图纸就乱了。

4.4 交互层的实现要点

交互层我推荐用FreeCAD做原型，因为它是开源的，Python API完善，社区活跃。具体做法是：

• 写一个FreeCAD工作台（Workbench），把AI功能集成进去
• 用PySide做界面，保持和FreeCAD原生风格一致
• AI处理结果用Coin3D的高亮节点显示
• 操作日志用SQLite存储，支持撤销和追溯

如果不想依赖FreeCAD，也可以用PyQt+matplotlib做一个独立的查看器，但工作量会大一些。

5. 常见问题与排查技巧实录

5.1 文件打不开或报错

问题：cad打开报vcruntime140 1.dll缺失。

排查：这是Windows运行库缺失，不是CAD文件的问题。安装最新的Visual C++ Redistributable即可。如果是用Python脚本处理，确保Python环境也装了对应的运行库。

问题：librecad打开dwg失败。

排查：LibreCAD原生只支持DXF，打开DWG需要额外的转换器。建议先用ODA Converter转成DXF，再用LibreCAD打开。

5.2 几何处理中的典型错误

问题：多段线闭合判定失败。

排查：检查首尾点坐标是否完全一致。如果不一致，用shapely的snap函数按容差吸附。容差一般设为图纸最小单位的1/10，比如图纸精度是0.1mm，容差就设0.01mm。

问题：布尔运算结果异常。

排查：大概率是存在自相交或重复顶点。先用shapely的is_valid检查，无效的话用buffer(0)修复。

5.3 AI推理的稳定性问题

问题：同一张图，两次识别结果不一致。

排查：检查模型是否设置了随机种子。如果用的是大模型API，温度参数设为0。如果是本地模型，固定torch.manual_seed。

问题：AI把图例识别成了实际实体。

排查：在预处理阶段就把图例区域裁剪掉，或者根据图层名过滤。图例通常在固定图层（如“LEGEND”），加一条规则就能解决。

5.4 性能瓶颈的定位

问题：处理大图纸时内存溢出。

排查：用memory_profiler定位内存热点。常见原因是把所有实体一次性加载到内存。改成流式处理，或者按图层分批处理。

问题：AI推理速度慢。

排查：如果是本地模型，检查是否用了GPU。如果是API，检查网络延迟。我的经验是，把AI推理放在异步任务里，不阻塞主线程，用户体验会好很多。

6. 一些个人体会

做AI+CAD这个方向，最大的感受是：不要被Demo的顺利迷惑，也不要被工程的困难吓退。Demo顺利是因为你只看到了冰山一角，工程困难是因为你看到了水面下的全部。但一旦跨过那些坎，做出来的东西是真的能帮到设计师的。

我自己的项目里，有一个功能是自动识别图纸中的房间并计算面积。Demo阶段准确率85%，工程化之后，通过图层过滤、几何规整、人工确认三个环节，最终准确率到了99%以上，设计师从原来手动描房间边界要花半小时，变成现在5分钟核对。这个价值是实实在在的。

另一个体会是：CAD领域的AI，规则和模型同样重要。纯规则太死板，纯模型太飘。两者结合，规则做精确判断，模型做模糊识别，才是可行的路径。

最后分享一个小技巧：如果你刚开始做，先从DXF入手，别碰DWG。DXF的文档齐全，Python库成熟，能让你快速验证想法。等DXF跑通了，再考虑用ODA Converter处理DWG。这样能省掉很多前期踩坑的时间。