1. 为什么“AI CAD”的 Demo 看起来无所不能一进工程就趴窝过去两年我陆陆续续参与了几个把 AI 往 CAD 工作流里塞的项目从最开始的“用大模型读图纸、自动生成标注”到后来的“自然语言驱动参数化建模”再到“批量识别 DWG 里的图层和线型做合规检查”。几乎每一个项目都经历过同一个剧本第一周做出一个惊艳的 Demo第二周信心满满地拿去给一线工程师看第三周开始被各种“这个图它读不了”“这个尺寸它算错了”“这个图层它认反了”按在地上摩擦最后要么砍需求要么退回人工兜底。这个现象太普遍了普遍到我觉得有必要把踩过的坑系统性地写一写。标题里说的“Demo 满天飞工程却走不通”不是唱衰而是一个真实存在的断层。Demo 面对的是“一张干净、标准、理想化的图纸”工程面对的是“十年积累下来的、图层命名混乱、块嵌套七八层、线型自定义、外部参照丢失、单位不统一”的真实文件。这两者之间的差距不是模型能力差一点而是整个数据链路、工程约束、验证机制全都不在一个维度上。这篇文章适合三类人看一是正在或准备把 AI 能力接入 CAD 流程的开发者二是被各种“AI 自动出图”方案轰炸过、想搞清楚到底能不能落地的一线工程师三是做技术选型、需要判断一个 AICAD 方案靠不靠谱的负责人。我会围绕AI、CAD、DXF、DWG、FreeCAD这几个核心关键词把“为什么走不通”拆成可操作的层面给出我实际验证过的思路和避坑经验。全文不吹不黑只讲我亲手试过、亲眼见过的东西。2. 先搞清楚 CAD 数据的真实形态别拿 Demo 的理想数据骗自己2.1 DWG 和 DXF 到底差在哪为什么选错格式直接决定项目生死很多人做 AICAD 的第一步就栽在格式上。Demo 阶段大家习惯用 DXF因为它是文本格式解析库多Python 里ezdxf几行代码就能读出来看起来特别美好。但一到工程现场甲方给你的十有八九是 DWG而且是各种版本、各种来源的 DWG。DWG 是 Autodesk 的私有二进制格式官方没有公开完整规范。你能找到的开源解析方案要么依赖 ODAOpen Design Alliance的库要么用一些逆向出来的读取器稳定性和覆盖度都参差不齐。DXF 虽然是交换格式但它分 ASCII 和二进制两种而且不同版本R12、R2000、R2004、R2007、R2010、R2013、R2018的实体支持差异很大。我见过一个项目Demo 用 R12 的 DXF 跑得飞起结果现场给的是 R2018 的 DWG里面用了大量动态块和自定义对象解析出来直接丢了一半信息。这里有个很实际的判断逻辑如果你的 AI 能力只需要读几何线段、圆弧、多段线、文字那 DXF 够用优先让上游导出 DXF。但如果你的能力依赖图层语义、块属性、标注样式、外部参照那必须直面 DWG而且要接受“解析不完整”这个现实在设计方案时就留好降级路径。格式可读性信息完整度工程现场常见度建议用途DXF (ASCII)高库多中动态块/自定义对象易丢中多用于交换Demo、几何提取DXF (二进制)中中低不推荐作为主链路DWG低依赖商业库高极高正式工程链路FreeCAD 原生高高但非 CAD 通用低参数化建模、验证2.2 图层、块、外部参照AI 最容易误读的三座大山我做过一个“自动识别图纸内容并分类”的实验用大模型去读 DXF 里提取出来的文字和图层名。结果发现同一个“墙体”概念在不同项目里可能叫WALL、Q-墙体、A-WALL、墙、WALL-200、0对很多人画图全在 0 层。你让模型去猜它猜对的概率在 Demo 里很高因为 Demo 数据是你自己整理的。但工程里图层命名是历史遗留问题没有统一标准。块Block更麻烦。一个图块可能嵌套了五层每层有自己的缩放和旋转块属性里还藏着关键信息。AI 如果只读最外层的几何拿到的坐标和实际位置对不上。外部参照Xref则是另一个坑图纸本身不包含被参照的内容你解析出来的是一堆“占位符”真正的几何在另一个文件里。Demo 里没人用 Xref工程里 Xref 是常态。实操心得在解析阶段就把“图层名归一化”和“块展开”做成独立模块不要指望 AI 模型去理解这些。规则能解决的不要交给模型。模型应该用在“规则解决不了”的地方比如模糊语义匹配、异常检测。2.3 单位、比例、坐标系一个没对齐后面全白算CAD 图纸里的单位是个隐形杀手。有的图按毫米画有的按米画有的图框是 1:100 但模型空间是 1:1。你从 DXF 里读出来的坐标是“图形单位”不是“现实尺寸”。如果 AI 要做尺寸校验、面积计算、碰撞检测单位不统一直接导致结果错得离谱。我遇到过一个案例AI 判断两根管线间距不足报警了。工程师一看说“这俩差着 300 毫米呢”。问题出在一根线在模型空间按毫米画另一根在布局空间按米画AI 把两个坐标直接相减得出了“间距 0.3”的结论然后按毫米理解成 0.3 毫米。这种错误在 Demo 里永远不会出现因为 Demo 数据是你自己按统一单位造的。坐标系还涉及 UCS 和 WCS 的区别。很多图纸在绘制时旋转过 UCS你读出来的坐标是 WCS 下的但工程师标注的尺寸是基于 UCS 的。AI 如果不做转换算出来的角度和距离全是错的。3. 把 AI 塞进 CAD 流程到底哪些环节真的能提效3.1 从“读图”到“懂图”语义理解的边界在哪里AI 在 CAD 里最容易做出效果的是“读图”这一步也就是把图形信息转成结构化数据。比如用 OCR 或视觉模型识别图纸里的文字标注用几何算法提取线段和圆弧用分类模型判断图元类型。这些在 Demo 里效果都不错因为输入相对干净。但“懂图”是另一回事。懂图意味着理解设计意图这条线为什么画在这里这个尺寸为什么这么标这个图层为什么用这个颜色。这需要领域知识而领域知识在图纸里往往是隐式的。比如建筑图里一根虚线可能代表梁的投影也可能代表吊顶边界还可能代表隐藏的管线。你让 AI 去判断它需要上下文而上下文可能分散在图纸说明、图层规范、甚至项目文档里。我的经验是把 AI 的能力边界划在“提取和初筛”上不要让它做“最终判断”。AI 可以告诉你“这里有 200 个文字标注其中 15 个可能不符合命名规范”但最终确认必须由规则或人来兜底。Demo 喜欢展示“AI 全自动完成”工程需要的是“AI 辅助 人工确认”的闭环。3.2 参数化建模与自然语言驱动FreeCAD 为什么是个好试验田FreeCAD 在这波 AICAD 探索里被频繁提到不是没有原因。它是开源的Python API 完善参数化建模的底层逻辑清晰非常适合做“自然语言生成模型”的实验。你可以用大模型把“画一个长 5 米、宽 3 米、高 2.8 米的房间”转成 FreeCAD 的脚本然后执行生成几何。但这里有个关键限制FreeCAD 的建模逻辑是“特征树”每一步操作都依赖前一步的结果。大模型生成的脚本如果顺序错了、参数引用错了整个模型就崩了。Demo 里你生成一个简单盒子没问题工程里你要生成一个有几十个特征、依赖关系复杂的装配体模型出错率会指数级上升。我试过一个折中方案不让 AI 直接生成完整脚本而是让它生成“参数和约束”然后由预置的模板脚本去执行。比如 AI 只负责输出“长度5000宽度3000高度2800墙体厚度200”模板脚本负责调用 FreeCAD API 建模。这样 AI 的输出空间被压缩出错概率大幅降低而且模板脚本可以复用、可以测试、可以版本管理。3.3 批量处理与合规检查AI 真正能落地的场景如果说有一个场景是 AICAD 目前最接近工程落地的我认为是“批量合规检查”。比如检查图纸里有没有违反图层规范的图元有没有未闭合的多段线有没有标注缺失有没有线型用错。这些任务的特点是规则明确、重复性高、人工做很枯燥、AI 做初筛很合适。我参与过一个项目用规则引擎 轻量模型对上千张 DWG 做批量检查。规则引擎负责硬性检查图层名、线型、颜色模型负责软性检查文字语义、图元分类。最终输出一份问题清单工程师只需要复核清单不需要从头看图。这个方案的效果是检查效率提升了大概 3 到 4 倍但前提是我们花了大量时间把规则梳理清楚并且接受了“模型会有误报”这个事实。注意批量处理最怕的是“静默失败”。一张图解析出错如果程序不报错、不记录你根本不知道漏了多少。一定要在流程里加日志和校验点每处理一张图都记录状态失败的单独拎出来人工处理。4. 工程走不通的五个真实卡点与破解思路4.1 卡点一数据脏且脏得没有规律工程图纸的“脏”是全方位的图层乱、块嵌套深、文字是炸开的、线型是自定义的、标注是手动改过的。你没法用一套规则覆盖所有情况因为每个项目、每个设计院、甚至每个绘图员都有自己的习惯。破解思路是“分层处理”。第一层用最宽松的规则做粗筛把明显无关的图元过滤掉第二层用模型做分类和语义提取第三层用人工确认关键结果。不要试图一步到位Demo 的一步到位是假象工程的分层兜底才是现实。4.2 卡点二AI 的输出不可验证错了也不知道大模型有个特性它输出错误答案时语气和输出正确答案时一样自信。在 CAD 场景里这意味着 AI 告诉你“这条线长度是 5000”你如果不手动量一下根本不知道它是不是在胡说。Demo 里没人验证工程里必须验证。我的做法是所有 AI 输出的关键数值都要有一个“可验证的锚点”。比如 AI 说某段距离是 5000那就用几何算法独立算一遍两者对比不一致就标记出来。几何算法是确定性的模型是概率性的用确定性去校验概率性是目前最务实的方案。4.3 卡点三CAD 软件生态封闭集成成本极高AutoCAD、MicroStation、Allegro、EPlan 这些软件各有各的格式和 API你想把 AI 能力嵌进去要么用它们的二次开发接口要么走文件交换。二次开发接口学习成本高、版本兼容性差、授权费用贵文件交换则面临格式转换的信息丢失问题。FreeCAD 和 LibreCAD 这类开源工具在这里反而有优势因为它们的格式和 API 是开放的适合做原型验证。但工程现场不会因为你用 FreeCAD 就改用 FreeCAD最终还是要回到 DWG 生态。所以我的建议是用开源工具做能力验证用文件交换做工程集成接受转换损耗在转换前后加校验。4.4 卡点四工程师不信任黑盒AI 必须可解释一线工程师对 AI 的态度用一句话概括就是“你先证明你靠谱我再考虑用你”。Demo 展示的是“AI 自动完成了”工程师关心的是“它为什么这么做”“它什么时候会出错”“出错了我怎么改”。如果你的 AI 是个黑盒工程师不会把关键任务交给它。可解释性在 CAD 场景里尤其重要因为图纸是要负责的。我的做法是AI 的每一个输出都附带“依据”。比如“判断这条线是墙体因为它在 WALL 图层且线宽为 0.3”把依据展示出来工程师可以快速判断对错也可以基于依据去调整规则。4.5 卡点五项目周期和 AI 迭代周期不匹配AI 模型的迭代是以周甚至天为单位的CAD 工程项目是以月甚至年为单位的。你在项目中期换一个模型版本可能之前调好的提示词、阈值、后处理逻辑全要重来。这种不匹配导致很多 AICAD 项目在 Demo 之后无法持续维护。破解思路是“解耦”。把 AI 能力封装成独立的服务输入输出接口固定模型版本可以独立升级。CAD 流程只依赖接口不依赖具体模型。这样模型迭代不会影响工程流程工程流程的变更也不会影响模型。5. 一套可复现的 AICAD 最小验证流程5.1 环境准备与工具选型如果你想自己动手验证我建议从下面这套组合开始成本低、可控性强Python 3.10主语言生态最全。ezdxf读写 DXF文档清晰社区活跃。FreeCAD做参数化建模验证Python API 直接调用。OpenCASCADE通过 pythonocc 或 FreeCAD 内置做几何运算和拓扑检查。一个本地可跑的大模型用于语义提取和分类避免依赖外部服务。安装 FreeCAD 的 Python 环境时要注意版本匹配FreeCAD 内置的 Python 版本可能和你系统的 Python 不一致。我一般直接用 FreeCAD 自带的 Python 解释器跑脚本省去环境冲突的麻烦。5.2 从 DWG 到结构化数据的关键步骤第一步是格式转换。如果拿到的是 DWG先用 ODA File Converter 或同类工具转成 DXF。转换时注意选择版本建议用 R2013 或 R2018兼容性较好。转换后一定要做一次完整性校验对比转换前后的实体数量差异过大说明转换丢了东西。第二步是解析 DXF。用 ezdxf 读取时重点提取这几类信息图层列表、图元类型和坐标、文字内容、块定义和块引用、标注样式。解析完先做统计看看图层有多少、图元有多少、块有多少心里有个数。第三步是归一化。把图层名统一大小写、去掉前后空格、按规则映射到标准分类。把块展开成基本图元记录展开后的坐标变换。把单位统一到毫米所有坐标乘以对应的比例因子。第四步才是 AI 介入。把归一化后的文字和图层信息喂给模型做分类和语义提取。模型的输出要结构化比如 JSON 格式方便后续程序处理。5.3 用 FreeCAD 做参数化验证的实操记录我拿一个简单的房间模型做过验证。流程是用户输入“画一个 5 米乘 3 米的房间墙厚 200高 2800”大模型输出参数 JSONFreeCAD 脚本读取 JSON 并建模。脚本的核心逻辑是先创建草图画矩形约束尺寸然后拉伸成墙再开洞。每一步都加了异常捕获如果某一步失败记录失败原因并回滚。实测下来简单模型成功率很高但一旦参数之间有冲突比如墙厚大于房间宽度的一半模型就会报错。这时候 AI 是不知道的需要脚本把错误信息返回给用户让用户调整参数。这个验证让我确认了一件事AI 负责“翻译需求”脚本负责“执行建模”两者之间用结构化参数解耦是目前最稳的方案。5.4 验证结果的评估标准怎么判断一个 AICAD 方案是否值得继续投入我一般看三个指标解析完整度能正确读取的图元占比低于 90% 就要警惕。语义准确率AI 分类和提取的准确率抽样人工核对低于 85% 就要优化。人工兜底成本AI 处理完后人工需要花多少时间复核和修正。如果比纯人工还慢方案就没有价值。这三个指标在 Demo 阶段往往被忽略因为 Demo 数据太干净了。一定要用真实项目的数据去测哪怕只有十张图也比一百张理想图有参考价值。6. 常见问题与排查技巧实录6.1 解析类问题速查问题现象可能原因排查方法解决思路DXF 读出来图元数量对不上版本不兼容或转换丢数据对比转换前后实体统计换转换工具或换 DXF 版本块的位置全错块嵌套变换未正确应用检查块引用的插入点和缩放递归展开块并累乘变换矩阵文字乱码编码或字体缺失检查 DXF 的编码声明指定编码读取或提取原始字节坐标数值异常大或小单位不统一检查 $INSUNITS 变量统一换算到毫米外部参照内容缺失Xref 未绑定检查是否有 XREF 实体让上游绑定 Xref 或单独提供参照文件6.2 模型输出类问题速查问题现象可能原因排查方法解决思路AI 分类结果不稳定提示词不够明确同一输入多次运行对比固定提示词降低温度参数数值提取错误模型幻觉用几何算法交叉验证关键数值必须程序校验输出格式不固定模型自由发挥检查输出是否符合 schema用结构化输出约束模型处理速度慢模型太大或调用频繁统计单张图处理耗时批处理 缓存 小模型初筛6.3 我踩过的三个印象最深的坑第一个坑是“以为 DXF 是标准”。我早期做一个批量检查工具只支持 DXF结果现场一半的图是 DWG而且转出来的 DXF 丢了很多块信息。后来我学乖了任何方案都先问清楚数据来源和格式再决定技术路线。第二个坑是“让模型做算术”。我试过让大模型直接从图纸文字里提取尺寸并计算面积结果它算错了好几次。后来改成模型只负责提取文字计算交给 Python准确率立刻上去了。模型擅长语义不擅长精确计算这个边界要划清楚。第三个坑是“忽略日志”。早期跑批量任务程序不报错但结果不对查了半天才发现是某几张图的图层名有特殊字符导致解析异常但被静默跳过了。后来我在每个环节都加了日志和校验点问题定位时间从半天缩短到几分钟。实操心得在 AICAD 项目里最值钱的不是模型而是“数据清洗 规则引擎 校验机制”这套基础设施。模型可以换基础设施换起来成本极高。先把基础设施搭好再考虑模型选型。7. 我对这个方向的一些真实判断AICAD 不是伪命题但它目前被过度包装了。Demo 满天飞是因为做 Demo 的成本很低拿几张干净图纸、调一个模型、录个视频就能展示。工程走不通是因为工程要面对的是真实数据的复杂性、验证的严格性、集成的封闭性这些都不是靠一个更强的模型能解决的。我个人的判断是短期内AI 在 CAD 里最有价值的场景是“辅助提取”和“批量初筛”而不是“全自动设计”。把 AI 放在流程的中间环节前面用规则做清洗后面用人工做确认这个组合目前最稳。FreeCAD 这类开源工具会继续扮演试验田的角色但工程落地还是要回到 DWG 生态接受格式转换的损耗在损耗可控的前提下做能力集成。如果你正在做类似的项目我的建议是先用真实数据跑一遍最小验证别急着上模型先把数据链路打通。数据链路通了模型的效果会自然显现数据链路不通再强的模型也是空中楼阁。这个顺序搞反了就是 Demo 和工程之间那道跨不过去的坎。