AI 和 CAD 这两个词放在一起这几年被聊得太多了。打开任何一个技术社区搜AI 生成 CAD 图纸你能刷到一堆让人血脉偾张的演示视频输入一段自然语言描述几秒钟之后一张看起来像模像样的机械零件图或者建筑平面图就出现在屏幕上。评论区一片传统工程师要失业了CAD 要被颠覆了。但如果你真的在工程设计一线待过或者亲手试着把这些 Demo 往实际项目里塞过就会知道一个很尴尬的事实这些演示离能用之间隔着的不是一层窗户纸而是一整条鸿沟。我自己在过去一年多的时间里断断续续折腾过好几个 AI 辅助 CAD 的方向从最粗暴的让大模型直接吐 DXF 代码到用 Python 脚本批量处理 DWG 图纸再到研究 FreeCAD 这类开源工具能不能接进 AI 的工作流。踩的坑比做出来的东西多得多。这篇就把我这一路的观察和实操经验摊开来讲聊聊为什么 AI 加 CAD 这件事Demo 满天飞工程却走不通以及如果真想做路应该怎么走。1. 先搞清楚 CAD 世界里图纸到底是什么东西很多人对 CAD 的想象停留在一个很表面的层面图纸嘛不就是一张画着线条的图。这个认知偏差是后面所有AI 生成 CADDemo 翻车的根源。在 AI 圈子里大家习惯把图像当成像素矩阵把文本当成 token 序列然后指望模型学会这个分布之后就能生成新东西。但 CAD 图纸根本不是像素也不是自由曲线它是一套带语义的、参数化的、有严格拓扑约束的几何数据结构。1.1 图纸不是画是一份几何契约你打开一个 DWG 文件看到的那些线每一条都不是随便画的。一条直线段背后至少有这些信息起点坐标、终点坐标、图层归属、线型、线宽、颜色、是否被锁定、是否属于某个块引用。一个圆背后是圆心、半径、所在平面法向量。更复杂的是这些图元之间还存在约束关系——两条线可能平行、垂直、相切一个尺寸标注可能绑定到某两个特征点上改了其中一个另一个必须跟着变。这就是参数化 CAD 的核心图纸是一份几何契约任何一处改动都要满足所有约束。AI 模型如果只是画出一堆看起来像零件的线条它完全没有理解这份契约。它不知道哪条线是基准哪个尺寸是驱动尺寸哪个是参考尺寸。结果就是你拿到的图看着挺像但一改尺寸整个图就散架或者根本没法在 CAD 里做后续的编辑操作。我见过最典型的翻车场景有人用图像生成模型画了一张齿轮的图导入 CAD 之后发现齿廓根本不是渐开线只是一堆近似曲线拿去加工直接报废。1.2 DXF 和 DWGAI 最容易栽跟头的两个格式热词里频繁出现 DXF、DWG这俩是 CAD 数据交换里绕不开的格式。DWG 是 AutoCAD 的原生格式二进制、封闭、版本众多官方 SDK 要授权。DXF 是它的文本交换格式理论上谁都能读写但实际用起来坑极多。我最早的想法很天真让大模型直接输出 DXF 文本不就行了DXF 是 ASCII 的模型能生成文本那生成 DXF 顺理成章。真动手才发现DXF 的结构远比想象中啰嗦。一个最简单的、只包含一条直线的 DXF 文件也要有 HEADER 段、TABLES 段、BLOCKS 段、ENTITIES 段、EOF 结尾每个段里还有一堆组码group code和值成对出现。模型生成的 DXF 经常出现的问题包括组码和值错位、段顺序不对、缺少必需的 TABLES 定义、图层引用了一个不存在的图层名。这些错误在文本层面看不出来一导入 CAD 就报错或者显示空白。更麻烦的是 DWG。DWG 是二进制格式模型根本没法直接生成。市面上能读写 DWG 的库比如 ODA 的 Teigha、或者一些商业 SDK要么收费要么授权复杂。开源方案里LibreCAD 能打开 DWG 但支持有限FreeCAD 通过第三方库读 DWG 也经常出问题。所以现实中的 AI CAD 工作流往往是AI 生成中间格式再想办法转成 DWG而这个转换环节本身就是重灾区。1.3 为什么看起来对和工程可用差这么远这里有个特别值得说的认知陷阱。AI 领域评价一个生成结果好不好常用的是像不像比如图像生成的 FID 分数、文本生成的困惑度。但工程领域评价一张图纸好不好用的是完全不同的标准能不能加工、能不能装配、尺寸链是否闭合、公差是否合理、是否符合制图标准。一张图纸哪怕线条画得再漂亮只要有一个尺寸标错或者少标了一个关键尺寸它在工程上就是废的。而 AI 模型恰恰最容易在这些语义正确性上出错。它可能把直径符号 φ 漏掉可能把公差带代号写错可能把粗糙度符号放错位置。这些错误在缩略图上看不出来但到了车间就是真金白银的损失。这就是为什么很多 AI CAD Demo 只敢展示生成了一张图不敢展示这张图拿去加工会怎样。2. 那些 Demo 到底是怎么骗过你的理解了 CAD 数据的本质再回头看那些满天飞的 Demo就能看出门道了。大部分演示之所以惊艳是因为它们在你看不见的地方做了大量手脚把最难的部分绕过去了。2.1 演示里的生成往往只是检索和拼贴我拆过不少公开的 AI CAD 演示。相当一部分所谓的生成底层其实是检索加拼贴。做法是预先准备一个零件库每个零件都有对应的文本描述和 CAD 文件。用户输入描述模型做的是语义匹配找到最接近的零件然后把它渲染出来。整个过程没有任何真正的几何生成只是找了一张最像的图给你看。这种方案在演示里效果极好因为零件库是精心挑选的覆盖了演示会用到的所有输入。但一旦用户输入一个库里没有的零件或者要求改一个尺寸系统立刻露馅。我试过一个开源的文本生成 CAD项目输入一个带四个安装孔的矩形法兰它给出的结果确实是个法兰但四个孔的位置完全是随机的孔间距也不符合任何标准。因为它的训练数据里法兰就是长这样它学的是法兰大概长什么样而不是法兰的孔应该按什么规则排布。2.2 参数化模板伪装成 AI 生成另一类更隐蔽的做法是用参数化模板冒充 AI 生成。开发者预先写好一堆 CAD 脚本模板每个模板接受几个参数。用户输入自然语言模型的任务只是从这句话里抽取参数然后填进模板。比如生成一个 M8 的螺栓模型抽出M8模板里早就写好了 M8 螺栓的所有几何直接实例化。这种方案比检索拼贴高级一点因为它确实能生成新东西——换个参数就是新零件。但它的能力边界完全由模板库决定。模板库里没有的零件类型它一个都生成不了。而且模板的粒度很粗一个法兰模板可能只支持圆形法兰遇到方形法兰就歇菜。演示的时候专挑模板覆盖的输入看起来无所不能实际一用就发现能干的活非常有限。2.3 把渲染图当成可编辑模型来展示最坑的一种是把渲染图当成可编辑模型来展示。AI 生成一张看起来很像工程图的图片然后截个图给你看你以为是 CAD 模型其实背后根本没有几何数据就是一张 PNG。这种在视频演示里特别有迷惑性因为观众看不到文件属性也看不到图层结构。我有个朋友就上过这个当。他看到一个AI 一键生成建筑平面图的工具兴冲冲地拿一个真实项目去试结果生成的东西根本没法导入 CAD导出的所谓DXF打开一看全是碎线段墙不是墙门不是门连图层都没分。他后来跟我说那一刻他才明白演示视频里那些流畅的编辑操作全是后期剪出来的。提示判断一个 AI CAD 工具是不是真货最直接的办法是看它导出的文件能不能在标准 CAD 软件里正常打开、能不能选中单个图元、能不能修改尺寸后图形跟着变。这三条过不了基本就是演示级产品。3. 真正动手做的时候卡点都在哪前面说的是别人怎么骗你这一节说说你自己动手会卡在哪。我从最简单的脚本开始一路试到比较复杂的 AI 工作流把遇到的主要卡点按难度排一下。3.1 读取和解析DWG 这道坎就劝退一半人做 AI CAD第一步永远是把图纸读进来变成程序能处理的数据。这一步在 DWG 上就极其痛苦。热词里有人问dwg 图纸读取到 opencascade有人问autocad dwg 获取线段 c#说明这是普遍痛点。我试过的路径有这么几条。第一条是用 AutoCAD 官方的 COM 接口或者 .NET API前提是你装了 AutoCAD而且只能在 Windows 上跑批量处理的时候性能很差还容易被弹窗打断。第二条是用 ODA 的 Teigha SDK功能全但授权费用不低个人开发者基本用不起。第三条是走开源路线用 LibreDWG 或者 ezdxf 这类库。LibreDWG 能读一部分 DWG但格式覆盖不全遇到复杂图纸经常解析失败。ezdxf 只处理 DXFDWG 得先转成 DXF。我最后常用的组合是先用 ODA File Converter免费工具把 DWG 批量转成 DXF再用 ezdxf 在 Python 里解析。这个方案能覆盖大部分场景但转换过程会丢一些信息比如某些自定义对象、动态块的参数。而且 ODA File Converter 是命令行工具批量处理要写脚本调度转换失败的图纸还得单独处理。3.2 几何理解从图元到这是什么东西把 DXF 读进来之后你拿到的是一堆 LINE、CIRCLE、ARC、LWPOLYLINE、INSERT 之类的图元。但 AI 要做的下一步是理解这些图元组成了一个什么零件。这一步叫几何语义理解是 AI CAD 里最难的部分之一。举个具体例子。一张图纸里有一堆线段人一眼能看出这是个矩形框但程序看到的是四条独立的 LINE。你得写逻辑去判断这四条线首尾相连吗它们构成闭合环吗这个环是矩形还是别的形状如果图纸里有几百个这样的环哪些是零件轮廓哪些是辅助线哪些是标注引线这些问题没有标准答案全靠规则和启发式。我试过用图神经网络来做这件事把图元当节点把图元之间的连接关系当边让模型学习哪些图元属于同一个零件。效果嘛在简单图纸上还行一到复杂装配图就崩。因为装配图里图元之间的空间关系太复杂而且很多关系是隐含的比如两个零件通过尺寸标注关联但几何上并不相连。3.3 生成环节模型输出的东西 CAD 不认假设你前面都搞定了现在要让 AI 生成新的几何。这里最大的坑是模型输出的格式和 CAD 要求的格式对不上。大模型擅长生成文本但 CAD 要的是精确的数值几何。模型生成的坐标经常是大概在这个位置比如它说在 (100, 50) 附近画一个圆但 CAD 要的是精确的 (100.000, 50.000)。模型还可能生成自相矛盾的几何比如一条线的起点是 (0,0)终点是 (100,100)但另一条线声称和它平行起点却是 (0,10)终点是 (100,90)——斜率都不一样怎么可能平行。我试过让模型生成 Python 代码用 ezdxf 来画图而不是直接生成 DXF。这个思路好一些因为代码是结构化的模型生成代码的准确率比生成 DXF 高。但模型生成的代码经常有 bug比如引用了不存在的变量、坐标算错、循环写错。你得跑一遍、看报错、让模型改来回好几轮才能跑通。而且模型对 CAD 的几何约束理解很浅它不知道这两个圆应该同心除非你在 prompt 里明确说。3.4 校验环节谁来保证生成的图是对的这是最容易被忽略、但工程上最致命的一环。Demo 里生成完就结束了但真实工程里生成完只是开始后面还有校验。一张图纸要检查的东西太多了尺寸是否标全、尺寸链是否闭合、公差是否合理、是否符合企业制图规范、有没有和已有零件干涉。这些校验目前基本靠人工AI 能帮上的忙很有限。我试过写规则引擎来做自动校验比如检查每个尺寸标注是否绑定到了有效的图元、检查闭合轮廓是否真的闭合。规则能覆盖一部分常见错误但工程图纸的对错很多时候是经验判断写不成规则。比如一个孔的间距标准上可能允许一个范围具体取多少要看装配需求这种判断 AI 做不了。4. 如果真要做务实的路径长什么样吐槽了这么多不是说 AI CAD 没戏。恰恰相反我觉得这个方向有真价值只是要放弃让 AI 端到端生成图纸这种不切实际的幻想走一条更务实的路。4.1 把 AI 定位成助手而不是设计师最关键的认知转变AI 在 CAD 工作流里的角色应该是助手不是设计师。它不负责从零画出正确的图纸它负责帮你处理那些重复、繁琐、有规律可循的环节。具体来说AI 能干的活包括批量修改图纸里的某个属性比如把所有某型号的标注统一改掉、从图纸里提取信息生成物料清单、根据规则检查图纸里的常见错误、把一种格式的图纸批量转成另一种格式、根据已有图纸生成相似的变体。这些活的特点是有明确的输入输出、有可验证的正确性标准、不需要创造性设计。AI 在这些场景里能实实在在提效而且出错了好发现、好回滚。我自己最常用的一个场景是批量图纸处理。以前改一批图纸的标题栏信息得一张张打开改几十张图能耗掉一下午。现在写个 Python 脚本用 ezdxf 读进来批量改属性再存回去几分钟搞定。这里面 AI 的作用是帮我写脚本、处理各种格式的边界情况而不是替我做设计决策。4.2 用脚本和规则打底AI 做胶水一个我验证过比较靠谱的架构是底层用确定性的脚本和规则AI 只在需要理解自然语言或者处理模糊输入的时候介入。比如一个根据需求生成标准件的系统底层是一个参数化的标准件库每个标准件都有严格的几何定义和参数表。用户输入我要一个 M10 的内六角螺栓长度 50AI 的任务只是把这句话解析成结构化参数{type: hex_bolt, size: M10, length: 50}然后调用标准件库生成。几何的正确性由标准件库保证AI 只负责语言理解这一层。这样即使 AI 解析错了错误也是可控的、可发现的不会生成一张几何上就错的图。这个架构的好处是责任清晰。AI 出错的地方是语言理解这个错误容易发现也容易修。几何生成由确定性代码负责只要代码写对了几何就是对的。比起让 AI 端到端生成这种分工的可靠性高一个数量级。4.3 FreeCAD 这类开源工具在 AI 工作流里的位置热词里 FreeCAD 出现好几次我专门说一下。FreeCAD 是开源 CAD 里比较成熟的一个它有 Python 接口可以脚本化操作这对 AI 工作流很友好。你可以用 Python 脚本驱动 FreeCAD 建模然后把 AI 接在前面做参数解析或者接在后面做结果检查。但 FreeCAD 也有它的局限。它的 DWG 支持依赖外部库经常出问题它的 API 文档不算完善很多功能得看源码它的稳定性在复杂模型上一般。我一般把 FreeCAD 用在轻量级的参数化建模场景比如生成一些简单的标准件、做一些几何计算。复杂的装配和出图还是得靠商业 CAD。用 FreeCAD 做 AI 工作流的一个实际例子我写过一个脚本用 FreeCAD 的 Python API 生成一系列不同规格的法兰盘参数从 Excel 读AI 负责把自然语言需求转成 Excel 里的参数行。整个流程跑通之后生成一百个法兰盘变体只要几分钟而且每个都是参数化模型改参数就能更新。4.4 数据格式的选择别跟 DWG 死磕如果你的项目不是非得用 DWG我强烈建议在中间环节用 DXF 或者 STEP 这类开放格式只在最后交付的时候转成 DWG。DXF 虽然啰嗦但至少是文本、可解析、工具链成熟。STEP 是三维数据交换的标准格式OpenCASCADE 这类库支持得很好热词里dwg 图纸读取到 opencascade说的就是这个方向。我现在的习惯是所有中间处理都在 DXF 或 STEP 层面做DWG 只在两个端点出现——输入端用转换工具转进来输出端用转换工具转出去。这样避开了 DWG 二进制格式带来的大部分麻烦。转换环节虽然会丢一点信息但对于大部分批处理场景丢的那点信息不影响。5. 几个具体的踩坑记录和解决思路前面讲的是框架性的东西这一节挑几个具体的坑把排查过程和解决思路完整写出来方便你遇到类似问题时参考。5.1 DXF 导入 CAD 后图形错位或消失这个坑我踩过不止一次。现象是用脚本生成的 DXF在 ezdxf 里读着一切正常但导入 AutoCAD 之后要么图形跑到很远的地方要么干脆看不见。排查过程是这样的。第一步先确认坐标系。DXF 里的坐标是世界坐标系但 AutoCAD 显示的时候可能用了用户坐标系或者视图没缩放到图形范围。用ZOOM命令的Extents选项如果图形出现了那就是视图问题不是数据问题。第二步如果Extents之后还是看不见检查图层。生成的 DXF 里图元可能被放到了一个被冻结或者关闭的图层上。用图层管理器看看有没有异常的图层状态。第三步如果图层也正常检查图元的坐标值。我遇到过一次脚本里算坐标的时候用了一个未初始化的变量结果所有图元的坐标都是NaNDXF 里写进去的是空值CAD 自然显示不出来。解决这类问题的通用思路是分层排查从外到内。先排除视图和图层这些显示层的问题再查数据本身。我后来养成了一个习惯生成 DXF 之后先用 ezdxf 读回来把图元的包围盒打印出来确认坐标在合理范围内再拿去 CAD 里打开。这一步能提前发现大部分坐标问题。5.2 批量处理时内存爆掉处理大批量图纸的时候我遇到过程序跑着跑着内存飙升然后崩溃。原因是我一开始的写法是把所有图纸都读进内存处理完再统一写出去。几百张图纸的图元数据加起来内存直接吃满。改法很简单改成流式处理一张一张读、处理、写、释放。用 Python 的话注意及时del掉不再用的对象必要时手动触发垃圾回收。ezdxf 的文档对象比较大处理完一张就doc None释放掉。另外如果只是做简单的属性修改可以考虑用更轻量的方式比如直接操作 DXF 文本而不是完整解析成对象模型。当然直接操作文本风险高得对 DXF 结构很熟才行。还有一个相关的坑是文件句柄泄漏。批量处理的时候如果打开文件不关闭跑几百张之后系统会报too many open files。用with语句管理文件句柄或者确保每个文件处理完都显式关闭。5.3 AI 生成的脚本跑不通怎么高效调试让 AI 生成 CAD 处理脚本十有八九第一版跑不通。我的调试流程是这样的。第一步把报错信息完整贴回给 AI包括 traceback。大部分语法错误和明显的 API 误用AI 看到报错就能改对。第二步如果 AI 改了几轮还不对把问题缩小。比如脚本处理一百个图元出错先让它处理一个图元跑通了再扩大。第三步如果 AI 始终搞不定某个 API自己去查文档把正确的用法告诉 AI。AI 对 CAD 库的 API 记忆经常是过时的或者错误的这时候人工介入比反复让 AI 试更高效。我总结的经验是AI 写 CAD 脚本适合写骨架不适合写细节。让它搭出整体流程、处理常见的格式转换这些它做得不错。但涉及到具体的几何计算、库的冷门 API还是得自己把关。把 AI 当成一个打字很快但需要你 review 的初级程序员这个定位比较准。5.4 图纸里的脏数据怎么处理真实项目的图纸尤其是历史遗留的脏数据特别多。图层命名混乱、图元重叠、块引用嵌套好几层、标注和图形不对应。这些脏数据会让任何自动化处理都变得困难。我的处理策略是先清洗再处理。清洗包括合并重复图元、统一图层命名、炸开不必要的块引用、删除空图层和孤立图元。清洗这一步可以写规则脚本也可以用 AI 辅助识别异常。清洗完之后的数据规范多了后续处理的成功率大幅提升。但清洗本身也有风险炸开块引用会丢失块的参数信息合并图元可能改变原有的拓扑关系。所以清洗之前一定要备份而且清洗规则要针对具体项目定制不能一套规则打天下。6. 关于AI 辅助这件事的一些个人判断折腾了这么久我对 AI CAD 这个方向的判断是短期别指望它替代设计师中期它会成为工程师的标配工具长期它可能改变 CAD 软件的形态。短期看AI 在几何正确性、工程语义理解上的短板太明显端到端生成可用图纸基本不可能。任何宣称能做到的产品要么是在特定极窄场景下要么就是在演示层面做手脚。中期看AI 在批处理、格式转换、信息提取、规则校验这些辅助场景里已经能创造实实在在的价值这些场景的共同点是有明确的正确性标准、人类容易验证结果。长期看如果 AI 对几何和工程约束的理解能上来CAD 软件的交互方式可能会变——从人画图变成人描述需求AI 生成候选方案人挑选和修改。对想入这个方向的人来说我的建议是先把 CAD 本身搞明白再谈 AI。你得知道 DXF 的结构、知道参数化建模的原理、知道工程图纸的规范这些是地基。地基不牢AI 用得再溜也是空中楼阁。反过来如果你 CAD 功底扎实再学会用 AI 写脚本、处理数据那你的效率会比纯手工高出一个量级。最后分享一个我自己的小习惯。每次要做一个新的 AI CAD 任务之前我会先问自己一个问题这个任务的正确答案能不能被自动验证如果能比如格式转换、批量改属性那就大胆用 AI出错了好发现。如果不能比如判断一张图纸设计得好不好那就老老实实人工做AI 最多给点参考意见。这个判断标准帮我避开了很多看起来很美好但实际会翻车的坑。 
长河君 · 2026/11/3 8:07:05 · 阅读 1.2k AI生成CAD图纸为何工程落地难？一线踩坑与务实路径
AI 和 CAD 这两个词放在一起这几年被聊得太多了。打开任何一个技术社区搜AI 生成 CAD 图纸你能刷到一堆让人血脉偾张的演示视频输入一段自然语言描述几秒钟之后一张看起来像模像样的机械零件图或者建筑平面图就出现在屏幕上。评论区一片传统工程师要失业了CAD 要被颠覆了。但如果你真的在工程设计一线待过或者亲手试着把这些 Demo 往实际项目里塞过就会知道一个很尴尬的事实这些演示离能用之间隔着的不是一层窗户纸而是一整条鸿沟。我自己在过去一年多的时间里断断续续折腾过好几个 AI 辅助 CAD 的方向从最粗暴的让大模型直接吐 DXF 代码到用 Python 脚本批量处理 DWG 图纸再到研究 FreeCAD 这类开源工具能不能接进 AI 的工作流。踩的坑比做出来的东西多得多。这篇就把我这一路的观察和实操经验摊开来讲聊聊为什么 AI 加 CAD 这件事Demo 满天飞工程却走不通以及如果真想做路应该怎么走。1. 先搞清楚 CAD 世界里图纸到底是什么东西很多人对 CAD 的想象停留在一个很表面的层面图纸嘛不就是一张画着线条的图。这个认知偏差是后面所有AI 生成 CADDemo 翻车的根源。在 AI 圈子里大家习惯把图像当成像素矩阵把文本当成 token 序列然后指望模型学会这个分布之后就能生成新东西。但 CAD 图纸根本不是像素也不是自由曲线它是一套带语义的、参数化的、有严格拓扑约束的几何数据结构。1.1 图纸不是画是一份几何契约你打开一个 DWG 文件看到的那些线每一条都不是随便画的。一条直线段背后至少有这些信息起点坐标、终点坐标、图层归属、线型、线宽、颜色、是否被锁定、是否属于某个块引用。一个圆背后是圆心、半径、所在平面法向量。更复杂的是这些图元之间还存在约束关系——两条线可能平行、垂直、相切一个尺寸标注可能绑定到某两个特征点上改了其中一个另一个必须跟着变。这就是参数化 CAD 的核心图纸是一份几何契约任何一处改动都要满足所有约束。AI 模型如果只是画出一堆看起来像零件的线条它完全没有理解这份契约。它不知道哪条线是基准哪个尺寸是驱动尺寸哪个是参考尺寸。结果就是你拿到的图看着挺像但一改尺寸整个图就散架或者根本没法在 CAD 里做后续的编辑操作。我见过最典型的翻车场景有人用图像生成模型画了一张齿轮的图导入 CAD 之后发现齿廓根本不是渐开线只是一堆近似曲线拿去加工直接报废。1.2 DXF 和 DWGAI 最容易栽跟头的两个格式热词里频繁出现 DXF、DWG这俩是 CAD 数据交换里绕不开的格式。DWG 是 AutoCAD 的原生格式二进制、封闭、版本众多官方 SDK 要授权。DXF 是它的文本交换格式理论上谁都能读写但实际用起来坑极多。我最早的想法很天真让大模型直接输出 DXF 文本不就行了DXF 是 ASCII 的模型能生成文本那生成 DXF 顺理成章。真动手才发现DXF 的结构远比想象中啰嗦。一个最简单的、只包含一条直线的 DXF 文件也要有 HEADER 段、TABLES 段、BLOCKS 段、ENTITIES 段、EOF 结尾每个段里还有一堆组码group code和值成对出现。模型生成的 DXF 经常出现的问题包括组码和值错位、段顺序不对、缺少必需的 TABLES 定义、图层引用了一个不存在的图层名。这些错误在文本层面看不出来一导入 CAD 就报错或者显示空白。更麻烦的是 DWG。DWG 是二进制格式模型根本没法直接生成。市面上能读写 DWG 的库比如 ODA 的 Teigha、或者一些商业 SDK要么收费要么授权复杂。开源方案里LibreCAD 能打开 DWG 但支持有限FreeCAD 通过第三方库读 DWG 也经常出问题。所以现实中的 AI CAD 工作流往往是AI 生成中间格式再想办法转成 DWG而这个转换环节本身就是重灾区。1.3 为什么看起来对和工程可用差这么远这里有个特别值得说的认知陷阱。AI 领域评价一个生成结果好不好常用的是像不像比如图像生成的 FID 分数、文本生成的困惑度。但工程领域评价一张图纸好不好用的是完全不同的标准能不能加工、能不能装配、尺寸链是否闭合、公差是否合理、是否符合制图标准。一张图纸哪怕线条画得再漂亮只要有一个尺寸标错或者少标了一个关键尺寸它在工程上就是废的。而 AI 模型恰恰最容易在这些语义正确性上出错。它可能把直径符号 φ 漏掉可能把公差带代号写错可能把粗糙度符号放错位置。这些错误在缩略图上看不出来但到了车间就是真金白银的损失。这就是为什么很多 AI CAD Demo 只敢展示生成了一张图不敢展示这张图拿去加工会怎样。2. 那些 Demo 到底是怎么骗过你的理解了 CAD 数据的本质再回头看那些满天飞的 Demo就能看出门道了。大部分演示之所以惊艳是因为它们在你看不见的地方做了大量手脚把最难的部分绕过去了。2.1 演示里的生成往往只是检索和拼贴我拆过不少公开的 AI CAD 演示。相当一部分所谓的生成底层其实是检索加拼贴。做法是预先准备一个零件库每个零件都有对应的文本描述和 CAD 文件。用户输入描述模型做的是语义匹配找到最接近的零件然后把它渲染出来。整个过程没有任何真正的几何生成只是找了一张最像的图给你看。这种方案在演示里效果极好因为零件库是精心挑选的覆盖了演示会用到的所有输入。但一旦用户输入一个库里没有的零件或者要求改一个尺寸系统立刻露馅。我试过一个开源的文本生成 CAD项目输入一个带四个安装孔的矩形法兰它给出的结果确实是个法兰但四个孔的位置完全是随机的孔间距也不符合任何标准。因为它的训练数据里法兰就是长这样它学的是法兰大概长什么样而不是法兰的孔应该按什么规则排布。2.2 参数化模板伪装成 AI 生成另一类更隐蔽的做法是用参数化模板冒充 AI 生成。开发者预先写好一堆 CAD 脚本模板每个模板接受几个参数。用户输入自然语言模型的任务只是从这句话里抽取参数然后填进模板。比如生成一个 M8 的螺栓模型抽出M8模板里早就写好了 M8 螺栓的所有几何直接实例化。这种方案比检索拼贴高级一点因为它确实能生成新东西——换个参数就是新零件。但它的能力边界完全由模板库决定。模板库里没有的零件类型它一个都生成不了。而且模板的粒度很粗一个法兰模板可能只支持圆形法兰遇到方形法兰就歇菜。演示的时候专挑模板覆盖的输入看起来无所不能实际一用就发现能干的活非常有限。2.3 把渲染图当成可编辑模型来展示最坑的一种是把渲染图当成可编辑模型来展示。AI 生成一张看起来很像工程图的图片然后截个图给你看你以为是 CAD 模型其实背后根本没有几何数据就是一张 PNG。这种在视频演示里特别有迷惑性因为观众看不到文件属性也看不到图层结构。我有个朋友就上过这个当。他看到一个AI 一键生成建筑平面图的工具兴冲冲地拿一个真实项目去试结果生成的东西根本没法导入 CAD导出的所谓DXF打开一看全是碎线段墙不是墙门不是门连图层都没分。他后来跟我说那一刻他才明白演示视频里那些流畅的编辑操作全是后期剪出来的。提示判断一个 AI CAD 工具是不是真货最直接的办法是看它导出的文件能不能在标准 CAD 软件里正常打开、能不能选中单个图元、能不能修改尺寸后图形跟着变。这三条过不了基本就是演示级产品。3. 真正动手做的时候卡点都在哪前面说的是别人怎么骗你这一节说说你自己动手会卡在哪。我从最简单的脚本开始一路试到比较复杂的 AI 工作流把遇到的主要卡点按难度排一下。3.1 读取和解析DWG 这道坎就劝退一半人做 AI CAD第一步永远是把图纸读进来变成程序能处理的数据。这一步在 DWG 上就极其痛苦。热词里有人问dwg 图纸读取到 opencascade有人问autocad dwg 获取线段 c#说明这是普遍痛点。我试过的路径有这么几条。第一条是用 AutoCAD 官方的 COM 接口或者 .NET API前提是你装了 AutoCAD而且只能在 Windows 上跑批量处理的时候性能很差还容易被弹窗打断。第二条是用 ODA 的 Teigha SDK功能全但授权费用不低个人开发者基本用不起。第三条是走开源路线用 LibreDWG 或者 ezdxf 这类库。LibreDWG 能读一部分 DWG但格式覆盖不全遇到复杂图纸经常解析失败。ezdxf 只处理 DXFDWG 得先转成 DXF。我最后常用的组合是先用 ODA File Converter免费工具把 DWG 批量转成 DXF再用 ezdxf 在 Python 里解析。这个方案能覆盖大部分场景但转换过程会丢一些信息比如某些自定义对象、动态块的参数。而且 ODA File Converter 是命令行工具批量处理要写脚本调度转换失败的图纸还得单独处理。3.2 几何理解从图元到这是什么东西把 DXF 读进来之后你拿到的是一堆 LINE、CIRCLE、ARC、LWPOLYLINE、INSERT 之类的图元。但 AI 要做的下一步是理解这些图元组成了一个什么零件。这一步叫几何语义理解是 AI CAD 里最难的部分之一。举个具体例子。一张图纸里有一堆线段人一眼能看出这是个矩形框但程序看到的是四条独立的 LINE。你得写逻辑去判断这四条线首尾相连吗它们构成闭合环吗这个环是矩形还是别的形状如果图纸里有几百个这样的环哪些是零件轮廓哪些是辅助线哪些是标注引线这些问题没有标准答案全靠规则和启发式。我试过用图神经网络来做这件事把图元当节点把图元之间的连接关系当边让模型学习哪些图元属于同一个零件。效果嘛在简单图纸上还行一到复杂装配图就崩。因为装配图里图元之间的空间关系太复杂而且很多关系是隐含的比如两个零件通过尺寸标注关联但几何上并不相连。3.3 生成环节模型输出的东西 CAD 不认假设你前面都搞定了现在要让 AI 生成新的几何。这里最大的坑是模型输出的格式和 CAD 要求的格式对不上。大模型擅长生成文本但 CAD 要的是精确的数值几何。模型生成的坐标经常是大概在这个位置比如它说在 (100, 50) 附近画一个圆但 CAD 要的是精确的 (100.000, 50.000)。模型还可能生成自相矛盾的几何比如一条线的起点是 (0,0)终点是 (100,100)但另一条线声称和它平行起点却是 (0,10)终点是 (100,90)——斜率都不一样怎么可能平行。我试过让模型生成 Python 代码用 ezdxf 来画图而不是直接生成 DXF。这个思路好一些因为代码是结构化的模型生成代码的准确率比生成 DXF 高。但模型生成的代码经常有 bug比如引用了不存在的变量、坐标算错、循环写错。你得跑一遍、看报错、让模型改来回好几轮才能跑通。而且模型对 CAD 的几何约束理解很浅它不知道这两个圆应该同心除非你在 prompt 里明确说。3.4 校验环节谁来保证生成的图是对的这是最容易被忽略、但工程上最致命的一环。Demo 里生成完就结束了但真实工程里生成完只是开始后面还有校验。一张图纸要检查的东西太多了尺寸是否标全、尺寸链是否闭合、公差是否合理、是否符合企业制图规范、有没有和已有零件干涉。这些校验目前基本靠人工AI 能帮上的忙很有限。我试过写规则引擎来做自动校验比如检查每个尺寸标注是否绑定到了有效的图元、检查闭合轮廓是否真的闭合。规则能覆盖一部分常见错误但工程图纸的对错很多时候是经验判断写不成规则。比如一个孔的间距标准上可能允许一个范围具体取多少要看装配需求这种判断 AI 做不了。4. 如果真要做务实的路径长什么样吐槽了这么多不是说 AI CAD 没戏。恰恰相反我觉得这个方向有真价值只是要放弃让 AI 端到端生成图纸这种不切实际的幻想走一条更务实的路。4.1 把 AI 定位成助手而不是设计师最关键的认知转变AI 在 CAD 工作流里的角色应该是助手不是设计师。它不负责从零画出正确的图纸它负责帮你处理那些重复、繁琐、有规律可循的环节。具体来说AI 能干的活包括批量修改图纸里的某个属性比如把所有某型号的标注统一改掉、从图纸里提取信息生成物料清单、根据规则检查图纸里的常见错误、把一种格式的图纸批量转成另一种格式、根据已有图纸生成相似的变体。这些活的特点是有明确的输入输出、有可验证的正确性标准、不需要创造性设计。AI 在这些场景里能实实在在提效而且出错了好发现、好回滚。我自己最常用的一个场景是批量图纸处理。以前改一批图纸的标题栏信息得一张张打开改几十张图能耗掉一下午。现在写个 Python 脚本用 ezdxf 读进来批量改属性再存回去几分钟搞定。这里面 AI 的作用是帮我写脚本、处理各种格式的边界情况而不是替我做设计决策。4.2 用脚本和规则打底AI 做胶水一个我验证过比较靠谱的架构是底层用确定性的脚本和规则AI 只在需要理解自然语言或者处理模糊输入的时候介入。比如一个根据需求生成标准件的系统底层是一个参数化的标准件库每个标准件都有严格的几何定义和参数表。用户输入我要一个 M10 的内六角螺栓长度 50AI 的任务只是把这句话解析成结构化参数{type: hex_bolt, size: M10, length: 50}然后调用标准件库生成。几何的正确性由标准件库保证AI 只负责语言理解这一层。这样即使 AI 解析错了错误也是可控的、可发现的不会生成一张几何上就错的图。这个架构的好处是责任清晰。AI 出错的地方是语言理解这个错误容易发现也容易修。几何生成由确定性代码负责只要代码写对了几何就是对的。比起让 AI 端到端生成这种分工的可靠性高一个数量级。4.3 FreeCAD 这类开源工具在 AI 工作流里的位置热词里 FreeCAD 出现好几次我专门说一下。FreeCAD 是开源 CAD 里比较成熟的一个它有 Python 接口可以脚本化操作这对 AI 工作流很友好。你可以用 Python 脚本驱动 FreeCAD 建模然后把 AI 接在前面做参数解析或者接在后面做结果检查。但 FreeCAD 也有它的局限。它的 DWG 支持依赖外部库经常出问题它的 API 文档不算完善很多功能得看源码它的稳定性在复杂模型上一般。我一般把 FreeCAD 用在轻量级的参数化建模场景比如生成一些简单的标准件、做一些几何计算。复杂的装配和出图还是得靠商业 CAD。用 FreeCAD 做 AI 工作流的一个实际例子我写过一个脚本用 FreeCAD 的 Python API 生成一系列不同规格的法兰盘参数从 Excel 读AI 负责把自然语言需求转成 Excel 里的参数行。整个流程跑通之后生成一百个法兰盘变体只要几分钟而且每个都是参数化模型改参数就能更新。4.4 数据格式的选择别跟 DWG 死磕如果你的项目不是非得用 DWG我强烈建议在中间环节用 DXF 或者 STEP 这类开放格式只在最后交付的时候转成 DWG。DXF 虽然啰嗦但至少是文本、可解析、工具链成熟。STEP 是三维数据交换的标准格式OpenCASCADE 这类库支持得很好热词里dwg 图纸读取到 opencascade说的就是这个方向。我现在的习惯是所有中间处理都在 DXF 或 STEP 层面做DWG 只在两个端点出现——输入端用转换工具转进来输出端用转换工具转出去。这样避开了 DWG 二进制格式带来的大部分麻烦。转换环节虽然会丢一点信息但对于大部分批处理场景丢的那点信息不影响。5. 几个具体的踩坑记录和解决思路前面讲的是框架性的东西这一节挑几个具体的坑把排查过程和解决思路完整写出来方便你遇到类似问题时参考。5.1 DXF 导入 CAD 后图形错位或消失这个坑我踩过不止一次。现象是用脚本生成的 DXF在 ezdxf 里读着一切正常但导入 AutoCAD 之后要么图形跑到很远的地方要么干脆看不见。排查过程是这样的。第一步先确认坐标系。DXF 里的坐标是世界坐标系但 AutoCAD 显示的时候可能用了用户坐标系或者视图没缩放到图形范围。用ZOOM命令的Extents选项如果图形出现了那就是视图问题不是数据问题。第二步如果Extents之后还是看不见检查图层。生成的 DXF 里图元可能被放到了一个被冻结或者关闭的图层上。用图层管理器看看有没有异常的图层状态。第三步如果图层也正常检查图元的坐标值。我遇到过一次脚本里算坐标的时候用了一个未初始化的变量结果所有图元的坐标都是NaNDXF 里写进去的是空值CAD 自然显示不出来。解决这类问题的通用思路是分层排查从外到内。先排除视图和图层这些显示层的问题再查数据本身。我后来养成了一个习惯生成 DXF 之后先用 ezdxf 读回来把图元的包围盒打印出来确认坐标在合理范围内再拿去 CAD 里打开。这一步能提前发现大部分坐标问题。5.2 批量处理时内存爆掉处理大批量图纸的时候我遇到过程序跑着跑着内存飙升然后崩溃。原因是我一开始的写法是把所有图纸都读进内存处理完再统一写出去。几百张图纸的图元数据加起来内存直接吃满。改法很简单改成流式处理一张一张读、处理、写、释放。用 Python 的话注意及时del掉不再用的对象必要时手动触发垃圾回收。ezdxf 的文档对象比较大处理完一张就doc None释放掉。另外如果只是做简单的属性修改可以考虑用更轻量的方式比如直接操作 DXF 文本而不是完整解析成对象模型。当然直接操作文本风险高得对 DXF 结构很熟才行。还有一个相关的坑是文件句柄泄漏。批量处理的时候如果打开文件不关闭跑几百张之后系统会报too many open files。用with语句管理文件句柄或者确保每个文件处理完都显式关闭。5.3 AI 生成的脚本跑不通怎么高效调试让 AI 生成 CAD 处理脚本十有八九第一版跑不通。我的调试流程是这样的。第一步把报错信息完整贴回给 AI包括 traceback。大部分语法错误和明显的 API 误用AI 看到报错就能改对。第二步如果 AI 改了几轮还不对把问题缩小。比如脚本处理一百个图元出错先让它处理一个图元跑通了再扩大。第三步如果 AI 始终搞不定某个 API自己去查文档把正确的用法告诉 AI。AI 对 CAD 库的 API 记忆经常是过时的或者错误的这时候人工介入比反复让 AI 试更高效。我总结的经验是AI 写 CAD 脚本适合写骨架不适合写细节。让它搭出整体流程、处理常见的格式转换这些它做得不错。但涉及到具体的几何计算、库的冷门 API还是得自己把关。把 AI 当成一个打字很快但需要你 review 的初级程序员这个定位比较准。5.4 图纸里的脏数据怎么处理真实项目的图纸尤其是历史遗留的脏数据特别多。图层命名混乱、图元重叠、块引用嵌套好几层、标注和图形不对应。这些脏数据会让任何自动化处理都变得困难。我的处理策略是先清洗再处理。清洗包括合并重复图元、统一图层命名、炸开不必要的块引用、删除空图层和孤立图元。清洗这一步可以写规则脚本也可以用 AI 辅助识别异常。清洗完之后的数据规范多了后续处理的成功率大幅提升。但清洗本身也有风险炸开块引用会丢失块的参数信息合并图元可能改变原有的拓扑关系。所以清洗之前一定要备份而且清洗规则要针对具体项目定制不能一套规则打天下。6. 关于AI 辅助这件事的一些个人判断折腾了这么久我对 AI CAD 这个方向的判断是短期别指望它替代设计师中期它会成为工程师的标配工具长期它可能改变 CAD 软件的形态。短期看AI 在几何正确性、工程语义理解上的短板太明显端到端生成可用图纸基本不可能。任何宣称能做到的产品要么是在特定极窄场景下要么就是在演示层面做手脚。中期看AI 在批处理、格式转换、信息提取、规则校验这些辅助场景里已经能创造实实在在的价值这些场景的共同点是有明确的正确性标准、人类容易验证结果。长期看如果 AI 对几何和工程约束的理解能上来CAD 软件的交互方式可能会变——从人画图变成人描述需求AI 生成候选方案人挑选和修改。对想入这个方向的人来说我的建议是先把 CAD 本身搞明白再谈 AI。你得知道 DXF 的结构、知道参数化建模的原理、知道工程图纸的规范这些是地基。地基不牢AI 用得再溜也是空中楼阁。反过来如果你 CAD 功底扎实再学会用 AI 写脚本、处理数据那你的效率会比纯手工高出一个量级。最后分享一个我自己的小习惯。每次要做一个新的 AI CAD 任务之前我会先问自己一个问题这个任务的正确答案能不能被自动验证如果能比如格式转换、批量改属性那就大胆用 AI出错了好发现。如果不能比如判断一张图纸设计得好不好那就老老实实人工做AI 最多给点参考意见。这个判断标准帮我避开了很多看起来很美好但实际会翻车的坑。