AI 和 CAD 这两个词放在一起，这几年被聊得太多了。打开任何一个技术社区，搜"AI 生成 CAD 图纸"，你能刷到一堆让人血脉偾张的演示视频：输入一段自然语言描述，几秒钟之后一张看起来像模像样的机械零件图或者建筑平面图就出现在屏幕上。评论区一片"传统工程师要失业了""CAD 要被颠覆了"。但如果你真的在工程设计一线待过，或者亲手试着把这些 Demo 往实际项目里塞过，就会知道一个很尴尬的事实：这些演示离"能用"之间，隔着的不是一层窗户纸，而是一整条鸿沟。我自己在过去一年多的时间里，断断续续折腾过好几个 AI 辅助 CAD 的方向，从最粗暴的"让大模型直接吐 DXF 代码"，到用 Python 脚本批量处理 DWG 图纸，再到研究 FreeCAD 这类开源工具能不能接进 AI 的工作流。踩的坑比做出来的东西多得多。这篇就把我这一路的观察和实操经验摊开来讲，聊聊为什么 AI 加 CAD 这件事，Demo 满天飞，工程却走不通，以及如果真想做，路应该怎么走。
1. 先搞清楚 CAD 世界里"图纸"到底是什么东西
很多人对 CAD 的想象停留在一个很表面的层面：图纸嘛，不就是一张画着线条的图。这个认知偏差，是后面所有"AI 生成 CAD"Demo 翻车的根源。在 AI 圈子里，大家习惯把图像当成像素矩阵，把文本当成 token 序列，然后指望模型学会这个分布之后就能"生成"新东西。但 CAD 图纸根本不是像素，也不是自由曲线，它是一套带语义的、参数化的、有严格拓扑约束的几何数据结构。
1.1 图纸不是画，是一份"几何契约"
你打开一个 DWG 文件，看到的那些线，每一条都不是随便画的。一条直线段背后至少有这些信息：起点坐标、终点坐标、图层归属、线型、线宽、颜色、是否被锁定、是否属于某个块引用。一个圆背后是圆心、半径、所在平面法向量。更复杂的是，这些图元之间还存在约束关系——两条线可能平行、垂直、相切，一个尺寸标注可能绑定到某两个特征点上，改了其中一个，另一个必须跟着变。这就是参数化 CAD 的核心：图纸是一份几何契约，任何一处改动都要满足所有约束。
AI 模型如果只是"画"出一堆看起来像零件的线条，它完全没有理解这份契约。它不知道哪条线是基准，哪个尺寸是驱动尺寸，哪个是参考尺寸。结果就是，你拿到的图看着挺像，但一改尺寸整个图就散架，或者根本没法在 CAD 里做后续的编辑操作。我见过最典型的翻车场景：有人用图像生成模型画了一张齿轮的图，导入 CAD 之后发现齿廓根本不是渐开线，只是一堆近似曲线，拿去加工直接报废。
1.2 DXF 和 DWG：AI 最容易栽跟头的两个格式
热词里频繁出现 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 只处理 DXF，DWG 得先转成 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 的内六角螺栓，长度 50"，AI 的任务只是把这句话解析成结构化参数{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 里图元可能被放到了一个被冻结或者关闭的图层上。用图层管理器看看有没有异常的图层状态。第三步，如果图层也正常，检查图元的坐标值。我遇到过一次，脚本里算坐标的时候用了一个未初始化的变量，结果所有图元的坐标都是NaN，DXF 里写进去的是空值，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 最多给点参考意见。这个判断标准帮我避开了很多"看起来很美好但实际会翻车"的坑。
