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优先考虑用ODAOpen 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 技术栈选择与理由基于我自己的实践推荐一套最小可用的技术栈环节工具理由文件解析ezdxf ODA Converter开源、文档全DXF处理足够DWG通过ODA转换几何处理shapelynumpy成熟的几何运算库容差控制灵活AI推理本地小模型如YOLO微调 大模型API小模型做识别大模型做语义理解和交互交互界面FreeCAD插件 或 独立PyQt应用FreeCAD开源可扩展PyQt灵活数据存储SQLite 文件缓存轻量适合单机工具这套栈的好处是全部可以本地部署不依赖外部服务适合对数据安全有要求的场景。缺点是AI能力受限于本地模型但可以通过API补充。4.2 预处理流水线的搭建预处理的目标是把任意来源的CAD文件转换成干净、结构化、AI友好的中间格式。我的一般流程是格式转换DWG → DXF用ODA Converter统一到DXF R2018清理删除重复实体、零长度线段、微小线段图层规整根据图层名映射到标准分类墙体、门窗、标注、文字、其他块处理提取块引用元数据选择性炸开几何规整坐标吸附、多段线闭合、清理重复顶点导出中间格式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也可以用PyQtmatplotlib做一个独立的查看器但工作量会大一些。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. 一些个人体会做AICAD这个方向最大的感受是不要被Demo的顺利迷惑也不要被工程的困难吓退。Demo顺利是因为你只看到了冰山一角工程困难是因为你看到了水面下的全部。但一旦跨过那些坎做出来的东西是真的能帮到设计师的。我自己的项目里有一个功能是自动识别图纸中的房间并计算面积。Demo阶段准确率85%工程化之后通过图层过滤、几何规整、人工确认三个环节最终准确率到了99%以上设计师从原来手动描房间边界要花半小时变成现在5分钟核对。这个价值是实实在在的。另一个体会是CAD领域的AI规则和模型同样重要。纯规则太死板纯模型太飘。两者结合规则做精确判断模型做模糊识别才是可行的路径。最后分享一个小技巧如果你刚开始做先从DXF入手别碰DWG。DXF的文档齐全Python库成熟能让你快速验证想法。等DXF跑通了再考虑用ODA Converter处理DWG。这样能省掉很多前期踩坑的时间。
AI+CAD工程化实战：从Demo到落地的四个关键坎
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优先考虑用ODAOpen 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 技术栈选择与理由基于我自己的实践推荐一套最小可用的技术栈环节工具理由文件解析ezdxf ODA Converter开源、文档全DXF处理足够DWG通过ODA转换几何处理shapelynumpy成熟的几何运算库容差控制灵活AI推理本地小模型如YOLO微调 大模型API小模型做识别大模型做语义理解和交互交互界面FreeCAD插件 或 独立PyQt应用FreeCAD开源可扩展PyQt灵活数据存储SQLite 文件缓存轻量适合单机工具这套栈的好处是全部可以本地部署不依赖外部服务适合对数据安全有要求的场景。缺点是AI能力受限于本地模型但可以通过API补充。4.2 预处理流水线的搭建预处理的目标是把任意来源的CAD文件转换成干净、结构化、AI友好的中间格式。我的一般流程是格式转换DWG → DXF用ODA Converter统一到DXF R2018清理删除重复实体、零长度线段、微小线段图层规整根据图层名映射到标准分类墙体、门窗、标注、文字、其他块处理提取块引用元数据选择性炸开几何规整坐标吸附、多段线闭合、清理重复顶点导出中间格式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也可以用PyQtmatplotlib做一个独立的查看器但工作量会大一些。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. 一些个人体会做AICAD这个方向最大的感受是不要被Demo的顺利迷惑也不要被工程的困难吓退。Demo顺利是因为你只看到了冰山一角工程困难是因为你看到了水面下的全部。但一旦跨过那些坎做出来的东西是真的能帮到设计师的。我自己的项目里有一个功能是自动识别图纸中的房间并计算面积。Demo阶段准确率85%工程化之后通过图层过滤、几何规整、人工确认三个环节最终准确率到了99%以上设计师从原来手动描房间边界要花半小时变成现在5分钟核对。这个价值是实实在在的。另一个体会是CAD领域的AI规则和模型同样重要。纯规则太死板纯模型太飘。两者结合规则做精确判断模型做模糊识别才是可行的路径。最后分享一个小技巧如果你刚开始做先从DXF入手别碰DWG。DXF的文档齐全Python库成熟能让你快速验证想法。等DXF跑通了再考虑用ODA Converter处理DWG。这样能省掉很多前期踩坑的时间。
