企业官网建设流程全解析

1. 从"能跑通"到"能交付"之间，隔着一条工程化的鸿沟

过去一年多，我参与过三个把 AI 能力往 CAD 工作流里塞的项目，有做图纸信息提取的，有做参数化建模辅助的，也有做批量改图脚本的。三个项目有一个共同点：Demo 阶段都异常顺利，两周内就能录出一段看起来很唬人的演示视频，但一旦进入真实工程环境，进度就像撞了墙，怎么推都推不动。这个现象不是个例，我身边做 CAD 二次开发、做工程数字化的朋友，几乎都遇到过同样的困境。

标题里说的"Demo 满天飞，工程却走不通"，说的就是这件事。它不是一个技术悲观论调，而是一个非常具体的工程现实：AI 在 CAD 场景里的单点能力已经足够惊艳，但 CAD 这个领域本身是一个高度工程化、格式封闭、精度敏感、历史包袱极重的系统，AI 的"概率性输出"和 CAD 的"确定性要求"之间存在结构性矛盾。这篇文章我想把这条鸿沟拆开讲清楚——它到底卡在哪几个环节，每个环节的根因是什么，以及我实际试过哪些绕过去的办法。

适合读这篇的人有三类：一是正在做 AI + CAD 方向探索的开发者，二是被老板要求"用 AI 改造设计流程"的技术负责人，三是对 CAD 数据格式和工程落地感兴趣、想少走弯路的从业者。我不会给你画大饼，也不会唱衰，只讲我踩过的坑和验证过的路径。

2. 先搞清楚 CAD 数据的真实形态，再谈 AI 能做什么

2.1 DWG、DXF、EXB 不是"文件格式"，是三套不同的世界

很多人做 AI + CAD 的第一反应是"我把图纸读进来，喂给模型不就行了"。问题就出在这个"读进来"上。CAD 图纸的主流格式至少有三种形态，每一种背后的数据模型都不一样。

DWG是 AutoCAD 的原生二进制格式，封闭程度最高。它内部不是简单的图形列表，而是一个包含图层、块引用、属性、扩展数据、字典、句柄索引的复杂对象数据库。你用一个开源库去读 DWG，读出来的往往只是几何图元，图层语义、块定义关系、字段表达式这些"工程信息"大量丢失。

DXF是交换格式，分 ASCII 和二进制两种。ASCII DXF 看起来是文本，好像很好解析，但它有版本差异——R12、R2000、R2007、R2018 的段结构、实体类型、组码含义都有变化。我见过一个团队用只支持 R12 的解析器去读 R2018 的图纸，结果样条曲线全部退化成折线，尺寸标注的关联关系全丢，模型拿到的输入本身就是错的。

EXB是国产 CAD 的格式，生态相对封闭，转换工具链不完整。热词里出现的"exb转dwg转换器""exb转换工具"，恰恰说明这个环节在真实工作流里是个高频痛点。

这三套世界之间的转换，每一次都是有损的。而 AI 模型对输入是"照单全收"的——你给它错的几何，它就基于错的几何给你一个自信满满的错误答案。

2.2 图纸里的"语义"和"几何"是两回事

这是我在项目里花了最长时间才想明白的一件事。CAD 图纸对工程师来说，价值不在线条本身，而在线条承载的工程语义：这条线是墙还是轴线，这个圆是螺栓孔还是管道截面，这个标注是公差还是参考尺寸。

但对 AI 来说，它首先看到的是一堆坐标点、直线段、圆弧、多段线。几何是显性的，语义是隐性的，而且语义往往藏在图层名、块名、线型、颜色、扩展属性这些"元数据"里。一个真实的机械图纸，图层可能有几十个，命名规则还因设计院、因项目、因年代而异。

我做过一个实验：把同一张装配图分别用"纯几何"和"几何 + 图层语义"两种方式喂给模型做零件识别，前者的准确率大概在六成出头，后者能到八成五以上。差距全在语义上。所以 AI + CAD 的第一个工程化门槛，不是模型能力，而是你能不能把图纸的语义完整、无损地提取出来，并且结构化地交给模型。

2.3 精度这件事，AI 的思维方式天然不匹配

CAD 是确定性系统。一条线画在 (100.000, 50.000)，它就是精确的，尺寸链闭合就是闭合，公差带就是公差带。工程上"差一点"就是废品。

AI 是概率性系统。它输出的是"最可能的答案"，天然带误差。你让模型去识别一个尺寸标注是 25 还是 26，它可能给你 25.3 这种既不是 25 也不是 26 的结果。你让它生成一段轮廓，它可能给你一条"看起来像"但端点不闭合、切线不连续的曲线。

这个矛盾在 Demo 里被掩盖了——Demo 只需要"看起来对"，工程需要"精确对"。我见过太多演示里模型把图纸识别得漂漂亮亮，一上真实产线，尺寸偏差 0.5mm，整条工艺链就崩了。所以工程化的关键，是在 AI 的概率输出和 CAD 的确定性要求之间，加一层校验和修正机制，而不是指望模型自己变精确。

3. 那些让 Demo 惊艳、让工程崩溃的具体环节

3.1 数据入口：读取环节的坑比想象中深

我拿一个真实案例说。项目目标是"读取一批 DWG 图纸，自动提取所有孔位坐标，生成加工清单"。Demo 阶段用的是十几张自己画的、图层规范、块命名统一的测试图，跑得很顺。

上真实数据后，问题一个接一个：

• 块引用嵌套：真实图纸里块套块，有的嵌套三四层，还带镜像和旋转。简单遍历块表拿到的坐标是块定义坐标系下的，不是世界坐标系下的，直接算就全错。
• 外部参照：图纸里插了外部参照（Xref），参照文件没一起给，几何直接缺失。热词里"cad多重引用插入解除工具"就是这个痛点的产物。
• 字段表达式：有些标注用的是字段表达式，值是动态计算的，静态读取拿到的是缓存值或者空值。
• 比例问题：热词里"pr0tel导入dxf文件时怎么改图纸比例"很典型——不同来源的图纸单位不一致，有的是毫米，有的是英寸，有的是"图纸单位"，不做单位归一化，坐标全是错的。

我最后的做法是：读取环节不追求"一把梭"，而是分三步走——先用成熟库（比如 ODA 的转换能力，或者 FreeCAD 的导入模块）把 DWG 转成中间格式，再在中间格式上做几何和语义的分离提取，最后做单位、坐标系、比例的归一化。每一步都留校验点，任何一步数据异常就报警，绝不带着脏数据往下走。

3.2 模型输入：图纸不是图片，别当图片喂

这是另一个高频误区。很多人做 AI + CAD，直接把图纸导出成 PNG 或者 PDF，然后当图像识别任务做。短期看效果不错，长期看是死路。

原因有三。第一，图像化会丢精度，一张 A0 图纸导出成 2000 像素宽的图，一个 0.1mm 的细节可能就一两个像素，模型根本分不出来。第二，图像化会丢语义，图层、块、属性这些信息在像素里荡然无存。第三，图像化后模型输出的坐标是像素坐标，要反算回图纸坐标，中间又引入一次误差。

我现在的做法是双通道输入：几何通道用矢量数据（DXF 实体、FreeCAD 的拓扑结构），语义通道用结构化元数据（图层、块名、属性表），两条通道在模型侧做融合。图像只作为辅助，用来做版面理解、区域划分这类粗粒度任务，不承担精确测量。

3.3 输出环节：模型给的答案，CAD 不认

就算模型识别得准，输出环节还有一道坎。模型输出的是自然语言或者 JSON，CAD 要的是能直接落地的实体。中间这个转换，坑非常多。

举个具体的：模型说"在 (120, 80) 处有一个直径 10 的孔"。你要把它变成 CAD 里一个真实的圆实体，需要确定：它在哪个图层、用什么线型、是不是块的一部分、有没有关联的标注、公差怎么标。这些模型通常不管，你得自己补。

更麻烦的是批量修改场景。热词里"python批量对cad修改"是个真实需求。模型判断"这批图纸的某个尺寸要统一改"，但改的时候要考虑：这个尺寸是不是被别的尺寸引用、改了之后尺寸链还闭不闭合、关联的标注会不会失效。模型给的是"改成多少"，工程要的是"怎么改才不出连锁问题"。

我的经验是：输出环节必须有一层"CAD 语义适配器"，把模型的意图翻译成符合 CAD 数据模型的操作序列，并且在执行前做一次影响面分析。这层适配器是工程化的核心，也是最难写的部分，因为它需要对 CAD 数据模型的深刻理解，不是调个 API 就完事。

3.4 验证环节：没有 ground truth，就没有工程可信度

Demo 不需要验证，工程必须验证。但 CAD 场景的验证特别难，因为缺少标注好的 ground truth。

我试过几种验证思路。一是规则校验：尺寸链闭合、图层规范、线型一致这些可以用规则自动查，不依赖模型。二是交叉验证：同一张图用两种不同方法提取，结果比对，差异大的人工复核。三是增量验证：在历史项目里找已经人工确认过的图纸，作为回归测试集。

这里有个反直觉的结论：验证环节的投入，往往比模型本身还大。我那个孔位提取项目，模型部分大概占了三成工作量，剩下七成全花在数据清洗、格式转换、验证机制上。这也是为什么很多团队 Demo 做得快、工程推不动——他们把七成的工作量低估成了一成。

4. 我实际验证过的几条可行路径

4.1 用 FreeCAD 做中间层，绕开格式封闭的坑

FreeCAD 在这个场景里被低估了。它本身是个开源参数化 CAD，但更重要的是它的数据模型开放、Python 接口完整、支持多种格式导入导出。热词里"freecad"出现多次，说明关注度在上升。

我的用法是：把 FreeCAD 当成"CAD 数据的中间表示层"。DWG、DXF、STEP、IGES 这些格式，先通过 FreeCAD 导入，转成它内部的拓扑结构（Shape、Solid、Face、Edge），在这个结构上做几何和语义的提取，再喂给 AI。好处是 FreeCAD 的拓扑结构是标准化的，不用为每种源格式写一套解析逻辑。

要注意的是 FreeCAD 导入 DWG 依赖外部转换器，导入质量取决于转换器版本，复杂图纸会有几何丢失。我的做法是导入后做一次几何完整性检查，边数、面数、体积这些指标和源文件比对，差异超阈值就报警。

另外热词里"freecad没有齿轮工具"这类问题，其实反映的是 FreeCAD 生态的插件化特点——核心功能精简，专业功能靠插件和工作台。做 AI + CAD 集成时，要评估清楚哪些能力是原生的、哪些要自己补。

4.2 用 OpenCascade 做几何内核，把精度问题交给确定性系统

这是我目前最推荐的一条路径。核心思路是：AI 只负责"理解和决策"，几何的精确操作全部交给 OpenCascade 这类确定性几何内核。

具体分工是这样的：AI 从图纸里识别出"这里有一个孔，直径大概 10，位置大概在 (120, 80)"，这是概率性的、允许有误差的。然后由 OpenCascade 去执行"在 (120, 80) 创建一个直径 10 的圆，并做布尔运算"，这是确定性的、精确的。AI 的输出经过一层"意图到操作"的翻译，翻译过程中做参数校验和修正，最终落到几何内核上的都是精确值。

热词里"【c++python土木4】dwg图纸读取到opencascade"说的就是这个方向。C++ 做几何内核的性能和精度，Python 做 AI 和胶水逻辑，这个组合在工程上很实用。我实测下来，几何操作的精度问题基本被这个架构解决了，剩下的问题集中在"意图翻译"这一层——也就是怎么把 AI 的模糊输出，可靠地翻译成精确的几何操作。

4.3 用规则引擎兜底，别让 AI 独自承担关键决策

我踩过最大的一个坑，是让 AI 独自决定"哪些尺寸需要修改"。结果它把一些关联尺寸也改了，导致尺寸链不闭合，图纸直接废掉。

后来我改成规则引擎 + AI 的混合架构：AI 负责识别和推荐，规则引擎负责把关。规则引擎里写清楚哪些尺寸是"主尺寸"可以改、哪些是"从尺寸"跟着变、哪些是"参考尺寸"不能动、改了主尺寸后哪些关联要重算。AI 的推荐先过规则引擎，通过才执行，不通过就打回或者转人工。

这个架构看起来"不够 AI"，但工程上非常稳。我的体会是：在 CAD 这种高精度、强关联的场景里，AI 应该是"副驾驶"而不是"自动驾驶"。关键决策要有确定性的兜底机制，AI 的价值在于降低人工工作量，而不是取代人工判断。

4.4 多 AI 协作处理复杂任务链

单一模型处理复杂 CAD 任务往往力不从心。热词里"多ai协作""ai agent"反映的就是这个趋势。我的实践是把 CAD 任务拆成几个子任务，每个子任务用最合适的模型或方法：

这个分工不是固定的，要根据具体任务调整。核心原则是：让每个环节用最可靠的方法，而不是让一个模型包打天下。

5. 工程化落地时，那些没人告诉你的经验

5.1 先做数据治理，再谈 AI

我现在的项目，第一步永远是数据治理，不是模型选型。具体包括：图纸格式统一、图层规范梳理、块命名标准化、单位归一化、历史图纸的版本清理。这一步做完，AI 的效果往往能提升一大截，因为输入干净了。

很多团队跳过这一步直接上模型，结果模型效果不好，就以为是模型不行，换模型、调参数，折腾半天，其实问题在数据。我的经验是：数据治理的投入产出比，远高于模型调优。

5.2 建立"人机回环"，别追求全自动

全自动在 Demo 里很性感，在工程里很危险。我现在的做法是设计"人机回环"：AI 处理大部分，不确定的、高风险的、影响面大的，转人工确认。人工确认的结果又回流成训练数据，模型越用越准。

这个机制的关键是设计好"什么时候转人工"的触发条件。我的触发条件包括：模型置信度低于阈值、涉及关键尺寸、影响超过 N 个实体、规则引擎校验不通过。这些条件要根据项目实际调整，没有万能公式。

5.3 版本兼容是个长期战争

CAD 格式在演进，AI 模型在演进，你的代码也在演进。三者版本不匹配，是工程后期最常见的故障源。我吃过亏之后，现在所有项目都强制做版本矩阵管理：记录每个版本组合下的测试结果，升级任何一个组件前先跑回归测试。

热词里"cad过期""cad安装激活步骤"这些，反映的是 CAD 软件本身的版本管理问题。做集成时，要明确你的方案支持哪些 CAD 版本、哪些格式版本，不支持的要提前说清楚，别等上线了才发现。

5.4 性能问题往往在最后才暴露

Demo 用十几张图，工程用几万张图。单张处理 3 秒，一万张就是 8 个多小时。而且真实场景往往是批量、并发、还要实时反馈。

我遇到过的性能坑包括：几何内核的内存泄漏、模型推理的批处理效率、格式转换的 IO 瓶颈、并发时的资源竞争。这些在 Demo 阶段完全看不出来，一上量就全冒出来。我的建议是尽早做压力测试，别等到上线前才发现性能不达标。

6. 关于"走不通"这件事，我的真实看法

说了这么多坑，可能有人觉得 AI + CAD 是不是根本走不通。我的看法恰恰相反：不是走不通，是走法不对。

Demo 满天飞，说明单点技术已经成熟了，这是好事。工程走不通，说明大家还在用做 Demo 的思路做工程，把 AI 当成了万能钥匙，忽略了 CAD 领域本身的工程复杂度。一旦把架构调整过来——AI 做理解和决策，确定性系统做精确操作，规则引擎做兜底，人机回环做保障——很多"走不通"的地方其实是能走通的。

我最近一个项目，用这套架构做图纸信息提取，准确率从最初的六成多提到了九成以上，人工复核工作量降了七成。它不是全自动，但它真的在工程里跑起来了，每天都在产出价值。这比一个惊艳但落不了地的 Demo，有意义得多。

如果你正在做类似的方向，我的建议是：先把数据入口和验证机制做扎实，再谈模型。这两块做不好，模型再强也是空中楼阁。至于模型选型、参数调优这些，反而是后面的事，而且随着基础模型能力提升，这部分会越来越简单。

最后分享一个我自己的判断标准：一个 AI + CAD 方案能不能落地，不看它 Demo 多惊艳，看它出错的时候能不能被及时发现、被可靠修正、被人工接管。能回答清楚这三个问题的方案，才值得往工程里推。