AI 啃 DWG图纸：从二维到三维

让大模型读懂 CAD 图纸，是"AI + 工程数据"里最硬的一块骨头之一。本文不谈具体业务，只讲一个纯技术命题：给定一套二维 DWG 图纸，让 AI 理解它、重建三维结构，并由参数驱动重新生成二维图。把这条链路上试过的四条路线、踩过的坑和最后沉淀下来的方法论写出来，供做同类问题的人参考。

一、问题抽象：二维进、二维出，为什么绕不开三维

最常见的需求形态是这样的：输入是一套二维 DWG 图纸（含零件的三视图，也含装配后的总三视图），输出是同样形式的二维图，但必须由一组参数驱动生成------参数变了，图纸要跟着变。

听起来是个"二维进、二维出"的问题，但第一反应就应该是：这东西必须先在一个三维里成立。

用最简模型看清死结

把它抽象成一个正方体：六个面，每个面的花纹不同，有的地方凸、有的地方凹。输入就是 6 个 DWG 文件，一个面一个文件。

纯二维的做法会死在三处：

尺度变化不成立。 等比例放大或许还能糊过去，但一旦要求出一块更大尺度的、且每个面上的图文要求并不一致的实体，二维的"缩放"就没有意义了。
面间关系无处安放。 六个面是各自独立的文件，不存三维关系，你甚至不知道哪张图和哪张图是要拼在一起的。
装配碰撞无法预判。 真实世界的装配是三维的，纯二维推理无法保证它在三维里不干涉。

两条路线

路线	思路	代价
A：二维 + 三维关系字段	全程只在二维图上作业，额外存一份"与其它面/其它零件之间的三维关系"	二维数据里挂三维语义，别扭；每个面各自为政，关系容易失效
B：先建三维，再投影	由二维图重建三维模型，参数改三维模型，再从三维模型投影出三视图	多一层建模成本，但语义统一、可验证

结论很干脆：无论走哪条路，三维关系都必须维护。 既然躲不掉，不如在三维里光明正大地维护它。最终路线：

复制代码

二维 DWG 图纸 ──► 三维模型 ──► 参数驱动调整 ──► 投影生成三视图（整体 + 零件）
                     ▲
              位置关系约定（关键约束）

方向定了，真正的难点才开始：怎么让 AI 把二维图读懂，并且可靠地转成三维？

二、让 AI 读懂 CAD：四次迭代，三次失败

第 1 次：整张图丢给视觉模型 ❌

最直接的思路：CAD 转图片，整张丢给多模态大模型。

结果很差。工程图纸尺寸大、线条密，而视觉模型对图像的有效识别能力是有明确上限的。整张图丢过去，无论当时哪个带图识别能力的模型，识别效果都不理想。

第 2 次：像地图瓦片一样切开 ❌

改进思路是：在不损失分辨率的前提下，把大图切成模型能处理的大小，再逐片分析。

效果确实好了一点，但很有限。原因是结构性的：CAD 图里的零件并不是横平竖直摆放的，模型没法"按零件"切，只能按固定网格切------就像地图服务的瓦片切片。于是：

零件完整落在某一片内：识别尚可；
零件被切缝劈成两半：大概率输出错误结果。

第 3 次：DWG → PDF → 切片 → 逐片识别 ❌

再往下走，是"CAD 转 PDF、切 PDF、逐片识别"。

跑得很慢，整体耗时以"周"计，结论仍然不行 ：大量零件识别不出来。根因没变------图被切碎，零件本身就认不准。

到这里可以下一个明确判断：视觉路线在这类图纸上是有天花板的，不是调参能救的。

第 4 次：DWG → DXF，让模型"读数据"而不是"看图" ✅

转折点是换了信息载体。

关键事实：DWG 是闭源二进制格式，没有成熟的开源解析方案 。商用 CAD 提供的命令行调用即便能用，拿到的数据结构也不完整；而且图纸数据量很大，一次性读出来会直接撞上上下文上限。

于是改成两步：

第一步：用能读 DWG 的 CAD，把 DWG 转成 DXF。

DXF 是开放格式、体积更小、开源工具链都能读。

格式一变，局面就打开了：大模型可以调用它能找到的脚本去解析 DXF ，于是它在相当程度上"理解"了图纸的几何与结构。再配合一份位置关系约定文档 （只需规定关键位置的约束，不必写全），把"DXF + 约定"一起交给模型，让它生成完整的结构骨架。

结果：出来的模型虽然还糙，但已经具备可辨认的整体形态了------与纯视觉路线相比是质的变化。

第 5 步：逐件对账，把骨架收敛成可用的模型 ✅

骨架有了，剩下的是精度。唯一的收敛方式是逐件校正：

把单个零件单独截图（或在原图上隔离出干净几何后截图）；
连同这个零件的具体参数要求 和它与其他零件的位置关系一起交给模型；
让模型规范化地重建这一个零件；
循环处理完整套图纸。

零件数量到上百个量级时，逐件对账是笨办法，但也是唯一稳定的办法。

迭代	方案	结果
1	CAD → 整张图片 → 视觉模型	❌ 超出图像识别上限
2	大图无损切瓦片 → 逐片识别	⚠️ 略好；切缝截断零件即出错
3	CAD → PDF → 切片 → 逐片识别	❌ 耗时以周计，零件识别不出来
4	DWG → DXF + 位置关系约定 → 生成结构骨架	✅ 一次拿到大部分结构，约 60%~70%
5	单零件截图 + 位置关系 → 逐件校正	✅ 收敛到可用

三、踩坑清单

1. 标注与引线污染几何

工程图里除了零件几何，还有大量辅助元素：尺寸标注、引出线、零件序号、角度注释 。这些标注本身没有统一规范，每张图都可能不一样。

模型的典型错误是：把标注文字、引线当成零件几何的一部分去重建。

两个应对办法：

显式声明"某条线/某段文字只是标注，不属于零件"；
当标注密集到说不清时，在原图上把真正构成零件的若干条线隔离出来、拷贝到干净图层，再截图给模型，它才能排除干扰。

由此也能看清一个本质矛盾：要让 AI 稳定读懂图纸，前提是有一套完整的规范；而 CAD 被广泛使用的原因，恰恰是它约束少、定义宽松。 这两件事天生冲突，所以这类方案短期内都很难做到"全自动闭环"。

2. DWG → DXF 会丢信息

转换过程通常正常，但一定会丢失一部分信息（丢线、丢属性都可能）。好在主体几何能保留，够支撑后续流程------但设计链路时必须把它当成有损转换来对待，而不是无损管道。

3. 源图纸本身可能就是错的

反向验证时出现过"模型理解与图纸画法不一致"的情况。仔细核对模型的分析过程后会发现：模型是对的，图纸是错的 ------某些图形画错，甚至零件数量与图上的明细表对不上，部分尺寸也对不上。

所以任何"生成结果 vs 原图明细"的自动对账，都不能默认基准是对的，校验逻辑必须双向可解释。

4. 两个硬上限始终存在

图像识别上限：单张图不能无限大；
上下文上限：一次性读入全部 DXF 数据不现实。

这也解释了为什么最终方案必须是"格式转换 + 分而治之"，而不是"更大的模型"。

5. 领域语料稀缺，模型之间拉不开差距

在 CAD 这类小众方向上，主流模型的差距明显小于 前端/后端/云原生这类语料充沛的领域。原因很直白：训练语料不足，产出质量就都上不去 。这意味着------在这类场景里，工程方法的收益远大于换模型的收益。

四、沉淀下来的方法论

① 先解决"格式"，再谈"能力"

最大的教训：别急着让模型看它看不懂的东西，先把它翻译成模型能吃的形式。

复制代码

DWG（闭源二进制，模型读不了）
   └─► DXF（开放文本，可脚本解析）   ← 这一步换来 60%~70% 的完成度
          └─► 三维结构骨架
                 └─► 逐件隔离 + 位置约束   ← 剩下 30% 靠人机对账磨出来

② 局部对账优于整体理解

不要指望一次性整体理解。正确姿势是：先要一版能看的整体骨架，再一部分一部分地检查、隔离、纠正。

AI 不会全错------它一定不是全都不对。对的部分测一遍就过，错的部分截图丢回去，一次改一点。

③ 先审方案，再让 AI 执行

固定流程：让 AI 先根据需求列一份测试/处理方案 → 人审一遍、补齐遗漏项 → 再让它执行。 长任务一跑就是大半天，方案审对了才不浪费。

④ 决策必须由人兜底

AI 不能替你做决定，也不该替你背锅。 它输出的中间结果与结论，必须经过人的复核才能进入下一环------这条在"上游数据本身可能有错"的场景里尤其重要。

⑤ 中间表示的选择是关键设计决策

DXF 在这里扮演的角色，本质是**"机器可读的中间层"**：

它比原始格式更开放（可解析、可脚本化）；
它比图像更结构化（几何即数据，不依赖像素识别）；
它又比完整三维模型更轻（可控上下文占用）。

这类"中间层"的设计，往往比模型选型更能决定整条链路能不能跑通。

五、延伸：AI 做数据转换与测试，比人细

同一套思路用在数据格式转换与校验上，收益非常直接：让 AI 连接真实数据环境，跑输入输出、验证格式、检查拓扑与关联。

一个典型例子：把数据从坐标系 A 转换到坐标系 B。

一种做法是 A 直接转 B，任务形式上完成；
更细的做法发现：虽然两者基于同一椭球，但参数存在细微差异，直转会产生米级误差 ，正确路径是先 A → C → B，几米误差即被消除。

在大范围、对几米误差不敏感的成果数据上，这种偏差肉眼几乎不可见------靠人测，很难测到这一层。事后在专业 GIS 软件中复核，确实存在该问题。

结论：技术性的数据输入输出与转换测试，是 AI 目前最合适的落点之一，可以做得极细。（界面类测试则会难一些。）

另外一条省钱经验：处理图像这类任务，用自带本地工具的办公类 AI 更划算------它内置了不少图像处理能力，不必每一步都跟大模型交互一轮，token 消耗会低不少。

六、工具与模型选型体感

工具侧，值得关注的是"流程模式的颗粒度"：

模式	特征	适用
可定制流程模式	有轻量流程控制，但允许模型自行编写脚本执行任务	需求不标准、需要在中途用数据判断下一步怎么做的探索型任务
标准软件工程模式	先设计文档、再工作计划、再执行	大型、需求明确、可分解的项目
极简模式	不预设流程与定义，直接编码	小改动、快速验证

另一个被低估的指标是啰嗦程度 ：工具啰嗦的好处是问题描述更清楚，坏处是大量消耗 token。同一件事，不同工具/配置的 token 开销可能差出数倍。

模型侧（个人体感，非评测）：

模型	体感
快速型 Flash 版本	出结果快、质量好，性价比高；适合"全程单一模型"的短链路
识图强项模型	多模态识图能力明显更强，适合仍需视觉辅助的环节
顶配推理版本	结果不一定更惊艳，在这类小众领域性价比一般

综合判断：在 CAD 这类小众方向上，没有哪个模型是碾压性的 。真正拉开差距的是工程方法------格式转换、分而治之、逐件对账这三件事，比换模型有效得多。

七、结语：卡点不在模型

回头看整条链路，AI 啃 CAD 卡住的地方，从来不是"模型不够聪明"，而是：

格式不通------DWG 读不了，转成 DXF 才有得谈；
规范缺失------CAD 定义宽松是它的优点，也是 AI 理解它的最大障碍；
数据有错------人画的图会错，校验必须双向可解释；
决策在人------AI 负责 60%~70%，剩下的靠人带着它一点点磨。

所以现在拿到一个任务，第一反应应该是：这件事如果交给 AI，该怎么做？ 绝大部分开发工作大模型都能完成，真正拉开差距的，是你怎么把领域知识翻译成模型能处理的形式 ------在 CAD 和空间数据这一块，就是怎么让它更快、更准地读懂图纸。

开卷有益，多多益善。 工具大同小异，关键是多用、多观察细节，在过程中建立起自己对"AI 怎么处理这件事"的理解。