企业官网建设流程全解析

1. 从一堆"跑得通"的Demo说起：AI+CAD到底卡在哪

过去一年多，我陆陆续续接触过十几个号称"AI+CAD"的项目，有做图纸识别的、有做参数化生成的、有做自然语言建模的，Demo演示的时候一个比一个惊艳——上传一张DWG，几秒钟吐出结构化数据；说一句"帮我画个法兰盘"，模型自动生成。但真正要往工程里塞的时候，几乎全部卡住。这个现象不是个例，而是当前这个赛道最真实的写照。

我自己是做机械设计和工业软件集成出身的，后来因为项目需要，硬着头皮啃了OpenCASCADE、FreeCAD的源码，也写过不少基于DXF/DWG的批处理脚本。这几年AI大模型火了之后，我一直在尝试把两者接起来。踩过的坑多了，慢慢就看清了一件事：AI+CAD的难点从来不在AI本身，而在CAD这一侧的"工程语义"根本无法被AI直接消化。

这篇文章想聊的就是这个。不是唱衰，也不是画饼，而是把我在实际落地过程中看到的真实障碍、尝试过的绕行方案、以及目前能跑通的最小闭环，原原本本讲清楚。如果你正在做AI+CAD相关的产品、研究或者内部工具，或者你是个CAD工程师想知道AI到底能不能帮上忙，这篇内容应该能帮你少走几个月弯路。

核心关键词会贯穿全文：AI、CAD、DXF、DWG、FreeCAD。这几个词看起来简单，但它们之间的鸿沟，比大多数人想象的要深得多。

2. Demo与工程之间的三道鸿沟

2.1 第一道鸿沟：图纸不是数据，是"意图的化石"

很多人对CAD图纸有个根本性误解，觉得DWG文件就是一堆线段、圆弧、标注的集合，只要解析出来就能喂给AI。这个理解在几何层面没错，但在工程层面完全错了。

一张工程图纸承载的信息分三层：

• 几何层：线、圆、弧、样条曲线，这些是DXF/DWG里能直接读到的实体。
• 语义层：这条线是中心线还是轮廓线？这个尺寸是配合尺寸还是参考尺寸？这个剖面图对应的是哪个视图？
• 意图层：设计者为什么这么画？这个倒角是为了装配还是为了加工？这个公差是基于什么工况定的？

AI模型能轻松处理第一层，勉强能猜第二层，但第三层几乎无能为力。而工程落地要的恰恰是第三层。

我举个实际例子。之前做过一个项目，要从一批DWG图纸里提取零件的加工特征。用OpenCASCADE读取几何没问题，但读出来的就是一堆B-Rep实体。你问AI"这个零件怎么加工"，它只能根据几何形状瞎猜。实际上图纸里明明有粗糙度标注、有公差带、有技术要求文字，但这些信息散落在不同的图层、不同的块引用、不同的标注样式里，AI根本不知道哪些信息是关联的。

这就是为什么Demo里"识别图纸"看起来很准，一到实际工程就废掉——Demo用的是精心挑选的、干净的、标准化的图纸，而工程里的图纸是十年二十年积累下来的，图层命名混乱、块引用嵌套七八层、标注样式五花八门。

2.2 第二道鸿沟：DXF/DWG的"方言"问题

DXF格式看起来是个标准，实际上各家CAD软件导出的DXF都有自己的"方言"。AutoCAD的DXF、中望CAD的DXF、FreeCAD导出的DXF，甚至同一款软件不同版本导出的DXF，在实体组织方式、图层命名规则、扩展数据（XDATA）的使用上都有差异。

我做过一个统计，手头200多张来自不同来源的DWG图纸，用同一套解析脚本处理，能完整读出来的不到60%。剩下的要么是块引用解析出错，要么是标注信息丢失，要么是自定义实体（比如AutoCAD的ACAD_PROXY_ENTITY）根本读不了。

更麻烦的是DWG格式。DWG是闭源二进制格式，虽然有Open Design Alliance这样的组织在做逆向，但版本兼容性一直是个大问题。你用一个库能读R14的DWG，换到2018版本可能就出问题。而工程现场最常遇到的情况就是：甲方给的是各种版本的DWG，你还不能要求他们转格式。

2.3 第三道鸿沟：AI的"幻觉"在工程里是致命的

在聊天场景里，AI说错一句话无所谓，用户笑一笑就过去了。但在CAD工程场景里，AI生成一个错误的尺寸、一个不合理的结构，可能导致整个零件报废、整条产线停工。

我见过一个案例，某团队用大模型做"自然语言转CAD参数"，Demo里输入"画一个直径100mm、厚10mm的法兰盘"，模型输出了正确的参数。但实际使用时，工程师输入"画一个DN100的法兰盘"，模型就懵了——它不知道DN100对应的实际外径、螺栓孔数量、密封面形式都是有标准规定的，不是随便定的。

这种"看起来对、实际错"的输出，在工程里比明显的错误更危险。因为工程师可能不会逐项检查，直接就拿去用了。

3. 拆解一条DWG图纸从文件到AI可理解的全链路

3.1 读取环节：为什么OpenCASCADE不是万能钥匙

很多人一提到CAD几何处理就想到OpenCASCADE。确实，OpenCASCADE在B-Rep建模、几何运算方面非常强大，FreeCAD的底层就是它。但用它来读DWG，其实是个绕路方案。

OpenCASCADE原生支持的是STEP、IGES这些中性格式，对DXF的支持是通过一个相对独立的模块，对DWG则基本没有原生支持。实际工程中的常见做法是：

1. 用ODA（Open Design Alliance）的库或者Teigha把DWG转成DXF；
2. 用ezdxf或者类似库解析DXF；
3. 把解析出来的几何数据转成OpenCASCADE能识别的TopoDS_Shape；
4. 在OpenCASCADE里做后续的几何运算。

这条链路每一步都有信息损失。DWG转DXF可能丢扩展数据，DXF解析可能丢块属性，转TopoDS可能丢图层信息。等你拿到一个干净的几何体时，原始图纸里的工程语义已经丢得差不多了。

我自己的做法是分层处理：几何信息走OpenCASCADE，非几何信息（图层、标注、文字、块属性）单独用ezdxf提取，最后在应用层做关联。这样虽然麻烦，但至少不会把有用的信息丢掉。

import ezdxf from OCC.Core.STEPControl import STEPControl_Reader # 用ezdxf提取非几何信息 doc = ezdxf.readfile("part.dxf") msp = doc.modelspace() # 提取所有文字标注 texts = [] for entity in msp.query("TEXT MTEXT"): texts.append({ "layer": entity.dxf.layer, "content": entity.dxf.text if entity.dxftype() == "TEXT" else entity.text, "position": entity.dxf.insert }) # 提取图层信息 layers = {layer.dxf.name: layer.dxf.color for layer in doc.layers}

这段代码看起来简单，但实际跑起来你会发现，很多图纸的文字是放在块引用里的，直接query TEXT是查不到的，得递归遍历INSERT实体。而且有些文字是属性定义（ATTDEF）转成的属性（ATTRIB），处理方式又不一样。

3.2 解析环节：图层命名里的"潜规则"

图层是CAD图纸里最重要的语义载体之一。一个规范的图纸，图层命名应该能反映实体类型：轮廓线、中心线、标注、文字、剖面线各占一层。但实际工程图纸里，图层命名是这样的：

• "0"层里塞了一半的实体
• "图层1"、"图层2"、"新建图层"
• "DIM"、"标注"、"尺寸线"混用
• 有些设计院有自己的标准，但标准文档早就找不到了

我试过用规则引擎去猜图层含义，准确率大概70%。后来换成用AI做分类，把图层名、颜色、线型、实体类型作为特征，准确率能到85%左右。但剩下的15%还是得人工确认。

这里有个经验：不要试图100%自动化，留一个人工确认的环节反而整体效率更高。因为工程师花5分钟确认一下，比AI猜错了导致后面全错要划算得多。

3.3 语义重建：从几何到特征的鸿沟

这是整条链路里最难的一步。你从DXF里读出来一堆线段和圆弧，怎么知道它们构成了一个"孔"、一个"槽"、还是一个"台阶"？

学术界有很多特征识别的方法，基于规则、基于图匹配、基于机器学习都有。但工业界实际能用的不多，因为：

• 特征定义因行业而异。机械行业的"孔"和建筑行业的"孔"完全不是一回事。
• 同一个几何形状可能对应不同的特征。一个圆柱面，可能是孔，也可能是轴，取决于它是材料去除还是材料添加。
• 特征之间有关联。一个螺纹孔包含底孔、螺纹、倒角，这些在几何上是分开的，但语义上是一个整体。

我目前看到比较靠谱的做法是混合方案：用规则处理标准特征（比如通孔、盲孔、螺纹孔），用AI处理非标准特征，最后用人工兜底。纯AI方案在Demo里好看，工程里不实用。

4. FreeCAD在AI+CAD链路里的真实定位

4.1 FreeCAD能做什么，不能做什么

FreeCAD是个好东西，开源、免费、可扩展，Python脚本能力很强。但它在AI+CAD链路里的定位需要搞清楚。

FreeCAD能做的：

• 作为几何处理引擎，通过Python API做参数化建模
• 作为格式转换中间层，读写STEP、IGES、DXF等格式
• 作为验证工具，把AI生成的参数转成实际模型看效果
• 作为二次开发平台，用Python写自定义工作台

FreeCAD不能做的：

• 直接读DWG（需要先转DXF，而且转换质量不稳定）
• 处理大型装配体（性能是硬伤）
• 替代商业CAD做生产级出图

我自己的用法是：把FreeCAD当成一个"几何沙盒"。AI生成的参数先扔进FreeCAD里跑一遍，看看能不能生成合理的几何体，能生成再往商业CAD里导。这样即使AI出错，也不会污染正式的设计文件。

4.2 用FreeCAD做AI输出的"几何校验层"

这个思路我觉得挺有价值，展开说一下。

AI模型输出参数后，不要直接信任。写一个FreeCAD脚本，把参数转成几何体，然后做几项检查：

• 几何有效性检查：生成的实体是不是有效的Solid？有没有自相交？
• 尺寸合理性检查：关键尺寸是不是在合理范围内？
• 装配干涉检查：如果是装配体，零件之间有没有干涉？

import FreeCAD import Part def validate_ai_output(params): """用FreeCAD校验AI生成的参数""" try: # 根据参数生成几何体 cylinder = Part.makeCylinder( params["radius"], params["height"] ) # 检查几何有效性 if not cylinder.isValid(): return {"valid": False, "reason": "几何体无效"} # 检查尺寸范围 if params["radius"] <= 0 or params["height"] <= 0: return {"valid": False, "reason": "尺寸非正"} # 检查体积是否合理 volume = cylinder.Volume if volume > 1e6: # 假设1立方米是上限 return {"valid": False, "reason": "体积异常"} return {"valid": True, "volume": volume} except Exception as e: return {"valid": False, "reason": str(e)}

这层校验不能保证AI输出100%正确，但能过滤掉大部分明显错误。在实际项目里，这一层帮我们拦掉了大约30%的AI错误输出。

4.3 FreeCAD脚本化的坑：版本兼容与API变动

FreeCAD的Python API在不同版本之间变动挺大的。0.18、0.19、0.20、0.21这几个版本，Part模块的API就有不少差异。如果你写的脚本要分发给别人用，最好锁定版本，或者在脚本里做版本判断。

另外FreeCAD的文档相对分散，很多API得看源码才知道怎么用。我的习惯是遇到不确定的API，直接在FreeCAD的Python控制台里试，试通了再写进脚本。

5. 那些真正跑通的场景长什么样

5.1 场景一：批量图纸的标准化预处理

这是目前我觉得最成熟、最容易落地的场景。不涉及AI生成，只用AI做识别和分类。

具体做什么：

• 批量读取DWG/DXF图纸
• 识别图纸类型（零件图、装配图、工艺图）
• 提取标题栏信息（图号、名称、材料、比例）
• 按规则重命名文件、归档

这个场景为什么能跑通？因为容错率高。AI识别错了，人工改一下就行，不会造成严重后果。而且这个场景的需求量大，几乎每个制造企业都有这个痛点。

我用ezdxf + 一个微调过的分类模型做过这个，处理1000张图纸，标题栏信息提取准确率能到90%以上，剩下的10%人工复核。整体效率比纯人工提升大概5倍。

5.2 场景二：基于历史图纸的参数推荐

这个场景稍微进阶一点。企业积累了大量历史图纸，新设计时可以参考。传统做法是人工翻图纸，效率很低。

用AI的做法：

1. 把历史图纸的几何特征和参数提取出来，建成数据库
2. 新设计时，输入需求描述，AI检索相似的历史设计
3. 推荐参考参数，工程师在此基础上修改

这个场景的关键是检索质量。我试过用几何特征做检索，也试过用图纸标题和描述做检索，效果都不错。但要注意，推荐结果必须标注来源，让工程师知道这个参数是从哪张图纸来的，方便追溯。

5.3 场景三：自然语言驱动的参数化建模（受限场景）

这个场景Demo最多，但落地最难。我的建议是把范围缩到足够小。

比如只做"标准件生成"：螺栓、螺母、垫圈、法兰这些有国家标准的零件。用户输入规格，AI解析成参数，FreeCAD生成模型。这个场景能跑通，因为标准件的参数空间是有限的、明确的。

但如果你想让AI做"任意零件的自然语言建模"，目前基本不现实。不是AI不够强，而是自然语言本身的歧义性太大，工程语义又太精确，两者很难对齐。

6. 落地路上最容易踩的五个坑

6.1 坑一：低估图纸的"脏乱差"程度

做Demo时用的图纸都是精心准备的，图层清晰、标注规范。一到实际项目，拿到的图纸能让你怀疑人生。

我的建议：在项目开始前，先随机抽100张实际图纸做评估。看看图层命名有多乱、块引用有多深、标注有多不规范。这个评估结果直接决定你的技术方案能做到什么程度。

6.2 坑二：把AI当万能钥匙

AI能做的事很多，但不是所有事都该用AI做。图层分类可以用规则+AI混合，几何运算老老实实用OpenCASCADE，格式转换用专门的库。不要为了AI而AI。

我见过一个团队，非要用大模型做DXF解析，结果准确率还不如ezdxf。这就是典型的用错工具。

6.3 坑三：忽视DWG的版本问题

DWG有R12、R14、2000、2004、2007、2010、2013、2018等多个版本。不同版本的二进制结构差异很大。如果你的工具只支持某几个版本，一定要在文档里写清楚，并且提供一个版本检测和提示功能。

6.4 坑四：没有人工复核环节

纯自动化的AI+CAD方案，目前我还没见过能稳定跑通的。一定要设计人工复核环节，而且要让复核变得简单高效。比如AI提取的信息，用高亮的方式在图纸上标出来，工程师一眼就能看出对不对。

6.5 坑五：忽略性能问题

一张复杂的装配图，可能有几万个实体。用Python逐实体处理，速度会慢到无法接受。该用C++的地方就用C++，该做并行就做并行，该缓存就缓存。工程场景对性能的要求比Demo高得多。

7. 给不同角色的实操建议

7.1 如果你是CAD工程师

不要等着AI来替代你，而是主动去用AI工具。从最简单的场景开始：用AI帮你整理图纸、提取信息、做重复性工作。你比AI更懂工程，你的价值在于判断AI输出对不对。

学一点Python，学一点ezdxf或者FreeCAD的脚本。不需要学到能开发软件的程度，能写个批处理脚本就够了。这个技能在未来的CAD工作里会越来越重要。

7.2 如果你是AI开发者

不要只盯着模型效果，多去现场看看工程师怎么用CAD。你会发现很多你以为的问题不是问题，很多你没想到的问题才是真问题。

学一点CAD基础知识，知道DXF和DWG的区别，知道图层、块、标注是什么。这些知识不需要很深，但能让你和工程师沟通顺畅很多。

7.3 如果你是产品经理

不要被Demo迷惑。评估一个AI+CAD方案，不要看它演示时多流畅，要看它在真实图纸上的表现。要求提供真实场景的测试报告，要求有明确的人工复核流程，要求有失败案例的处理方案。

8. 我目前跑通的最小闭环

说了这么多问题，最后分享一下我目前实际在用的方案。不完美，但能跑通。

整体架构是：

• 输入层：DWG/DXF图纸，先做版本检测和格式转换
• 解析层：ezdxf提取几何和非几何信息，OpenCASCADE做几何运算
• AI层：用微调过的小模型做分类和提取，不用大模型做生成
• 校验层：FreeCAD做几何校验，规则引擎做逻辑校验
• 输出层：结构化数据 + 人工复核界面

这个方案处理一张普通零件图，从输入到输出大概30秒，人工复核1-2分钟。比纯人工处理快3-5倍，而且质量更稳定。

关键设计原则就一条：AI做它擅长的（识别、分类、检索），传统方法做它擅长的（几何运算、格式转换、规则校验），人工做只有人能做的（最终判断）。

这个原则听起来简单，但实际执行时很容易走偏。因为AI太火了，大家都想多用一点。但工程落地不是比谁用的AI多，是比谁能稳定解决问题。

我在实际项目里最大的体会是：AI+CAD的落地，技术只占30%，剩下70%是对工程场景的理解和对工作流程的重构。你把工程师的工作流程摸透了，知道哪个环节最耗时、哪个环节最容易出错、哪个环节最需要辅助，然后针对性地用AI去解决，成功率会高很多。反过来，如果你只是拿着一个AI模型去找场景，大概率会碰壁。

另外一个小技巧：从"辅助"而不是"替代"的角度切入。不要想着让AI自动完成整个设计流程，而是让AI帮工程师省掉某个具体环节的重复劳动。这样即使AI只做到70分，工程师补上剩下的30分，整体效率还是提升的。而且工程师的接受度会高很多，因为他们感觉到的是"AI帮我干活"，而不是"AI要抢我饭碗"。

这个方向还在快速演进，今天跑不通的场景，可能半年后就有新方案了。但底层的逻辑不会变：工程场景要的是可靠、可追溯、可复核，而不是炫酷。谁能把这三件事做好，谁就能真正落地。