企业官网建设流程全解析

1. 从一堆炫酷 Demo 到工程落地，中间隔了什么

过去一年多，我陆陆续续接触了不少“AI + CAD”方向的项目，有做图纸识别的，有做参数化生成的，也有做自然语言驱动建模的。朋友圈里隔三差五就能刷到某个团队放出的演示视频：对着聊天框说一句“帮我画一个法兰盘”，几秒钟后屏幕上就出现了一个带孔的三维模型，弹幕一片“牛逼”。但如果你真的在制造业、建筑设计院或者工程公司待过，就会知道这些视频和真正能跑在生产环境里的系统之间，差着十万八千里。

我自己踩过这个坑。两年前接手一个内部项目，目标是把历史积累的 DWG 图纸批量解析成结构化数据，再基于这些数据做智能检索和辅助设计。当时团队里有人提议直接上大模型，说“现在 AI 这么强，喂几张图进去不就完了”。结果我们花了三个月，换了三套方案，最后发现最难的压根不是模型本身，而是图纸格式的解析、图层语义的还原、以及工程语境下对“正确”的定义。Demo 能跑通，是因为它只处理了最干净的那几张图；工程走不通，是因为真实场景里的图纸脏得超出想象。

这篇文章我想把这段时间的观察和实操经验完整梳理一遍。核心围绕几个问题：为什么 AI 和 CAD 的结合这么难？DXF、DWG 这些格式到底卡在哪里？FreeCAD、OpenCascade 这类开源工具在链路里扮演什么角色？以及，如果你现在想做一个真正能用的 AI + CAD 工具，应该从哪个环节切入。适合正在做相关产品、或者准备入坑这个方向的工程师和产品经理参考，也适合对 CAD 二次开发感兴趣但还没找到切入点的朋友。

2. 图纸格式这道坎，比模型能力更致命

2.1 DWG 和 DXF 的本质差异，决定了你的技术路线

很多人一开始会把 DWG 和 DXF 当成一回事，觉得无非是两种后缀名。实际上这两个格式的差异，直接决定了你整个技术栈的选型。DWG 是 AutoCAD 的原生二进制格式，结构封闭，官方文档极少，想要解析基本只能依赖 Autodesk 自家的 RealDWG 库或者 ODA（Open Design Alliance）的 Teigha。而 DXF 是 Autodesk 推出的交换格式，有公开的组码规范，文本和二进制两种形式都有，理论上你可以自己写解析器。

我最初选的是 DXF 路线，理由很简单：有文档、有开源库、不依赖商业组件。但实际跑下来发现，DXF 的坑一点不比 DWG 少。首先是版本问题，R12、R14、2000、2004、2007、2010、2013、2018，每个版本的组码定义都有细微差别，有些实体类型在新版本里被废弃了，有些属性是后来才加的。你写一个解析器，如果不做版本适配，遇到老图纸直接崩。其次是 DXF 里大量使用扩展数据（XDATA）和代理实体（Proxy Entity），这些是第三方软件写入的私有数据，没有公开规范，解析出来就是一堆二进制块。

后来我们转向了 ODA 的方案，用 Teigha 的 .NET 或 C++ 接口来读 DWG。好处是兼容性好，Autodesk 能打开的它基本都能打开。代价是授权费用不低，而且 API 学习曲线陡峭。如果你的项目预算有限，或者只是想做个原型验证，我建议先用 FreeCAD 的 Python 接口配合 ezdxf 库来跑通流程，等验证完业务逻辑再考虑换重型方案。

2.2 图层和块参照：图纸语义还原的真正难点

解析出线段、圆弧、文字这些几何实体只是第一步，真正难的是还原图纸的“语义”。在工程图纸里，不同的图层代表不同的专业：墙体、门窗、标注、轴线、设备、管道，每个设计院有自己的图层命名规范，有的用中文，有的用拼音缩写，有的用数字编码。你拿到一张图，如果不理解图层含义，解析出来的就是一堆没有意义的线条。

块参照（Block Reference）是另一个大坑。CAD 里的块可以嵌套，一个块里可以引用另一个块，嵌套层数可能很深。而且块有属性（Attribute），这些属性可能是文字、可能是数字、可能是带格式的字段。我们当时处理一个设备图纸，块嵌套了七层，最里层的属性文字被外层块旋转了 90 度，解析出来坐标全是错的。后来写了一个递归展开加坐标变换的模块，才把这个问题解决。

实操建议：在做图层语义映射之前，先统计一下你手头图纸的图层命名分布。如果超过 60% 的图层名是规范化的，可以考虑用规则引擎做映射；如果命名混乱，那就需要引入人工标注或者聚类算法来辅助分类。

2.3 从 DWG 到 OpenCascade：几何内核的转换损耗

有些场景需要把二维图纸转成三维模型，这就涉及到几何内核的转换。OpenCascade 是开源领域最成熟的几何内核，FreeCAD 就是基于它构建的。但 DWG 里的二维实体转到 OpenCascade 的 TopoDS_Shape 时，会有精度损失和拓扑错误。比如两条本该相交的线段，因为浮点精度问题没有真正相交，导致后续的布尔运算失败。

我们当时的做法是，在转换前先做一轮几何清理：合并重合点、修复微小间隙、删除零长度线段。OpenCascade 提供了 ShapeFix 工具包，可以自动修复一部分问题，但不能全指望它。有些图纸的精度问题非常隐蔽，需要你自己写检测逻辑。比如我们遇到过一个案例，图纸里有一条线段的端点坐标是 (100.0000001, 200.0000002)，而相邻线段的端点是 (100.0, 200.0)，差了 0.0000001，肉眼完全看不出来，但布尔运算就是过不去。

3. 大模型在 CAD 场景里到底能干什么

3.1 自然语言转参数：看起来很美，边界很窄

现在很多 AI + CAD 的 Demo 都在展示“说一句话生成模型”，比如“画一个直径 100 毫米、厚度 10 毫米的法兰盘，带 6 个直径 12 毫米的孔”。这个场景在演示里很惊艳，但实际落地时你会发现，它的适用范围非常窄。首先，用户的需求描述往往是不完整的，他可能只说“画个法兰盘”，但不说具体参数。其次，工程语境下的约束条件极其复杂，材料、公差、表面处理、装配关系，这些都不是一句话能说清楚的。

我试过用大模型做参数提取，输入是一段设计说明文字，输出是结构化的参数表。在测试集上准确率能到 85% 左右，但剩下 15% 的错误里，有一半是致命错误，比如把“M12 螺纹孔”理解成“直径 12 的圆孔”，把“倒角 2x45°”理解成“边长 2 的三角形”。这些错误在 Demo 里看不出来，但在工程里就是废品。

我的判断是：自然语言转参数这个方向，短期内更适合做“辅助输入”而不是“自动生成”。也就是说，让 AI 生成一个初稿，然后由工程师确认和修改，而不是直接输出最终结果。

3.2 图纸理解：OCR 加几何推理的组合拳

相比生成，AI 在图纸理解方面的落地可能性更大。一张 CAD 图纸里包含了几何信息、文字标注、尺寸公差、技术要求，这些信息如果能够自动提取并结构化，对后续的检索、复用、审核都有巨大价值。

我们的做法是分两步走：先用 OCR 提取图纸里的文字信息，包括标注文字、标题栏、技术要求；然后用几何推理引擎把文字和几何实体关联起来。比如一个尺寸标注“100±0.05”，OCR 识别出文字后，需要找到它对应的两条尺寸界线，才能确定这个尺寸标注的是哪一段距离。这个关联过程需要结合空间位置、图层信息、标注样式来综合判断。

这里有个经验：不要指望 OCR 能 100% 准确。工程图纸里的字体五花八门，有宋体、仿宋、黑体，还有手写体。有些图纸扫描质量差，文字模糊。我们的做法是，OCR 结果只作为候选，最终由几何推理来验证。比如 OCR 识别出一个数字“100”，但几何测量出来是“99.8”，那就需要人工复核。这种“AI 初筛 + 规则校验 + 人工兜底”的模式，在实际项目里比纯 AI 方案靠谱得多。

3.3 代码生成：让 AI 写 CAD 脚本的可行性

还有一个方向是用大模型生成 CAD 脚本，比如 AutoLISP、Python 脚本或者 FreeCAD 的宏。用户描述需求，AI 生成代码，代码在 CAD 里执行。这个思路在理论上很优雅，因为脚本是确定性的，执行结果可复现。

我实测过用 GPT-4 生成 FreeCAD Python 脚本，让它画一个简单的齿轮。结果它生成的代码能跑，但齿轮的齿形参数是错的，模数和齿数搞反了。后来我调整了提示词，把 FreeCAD 的 API 文档和几个示例脚本一起喂进去，准确率明显提升。这说明大模型在代码生成方面是有潜力的，但前提是你要给它足够的上下文和约束。

关键技巧：在提示词里明确指定 API 版本和函数签名，并提供 2-3 个正确示例。不要指望模型自己“猜”对你的环境。

4. 一条能跑通的工程链路应该长什么样

4.1 数据层：从图纸入库到结构化存储

一条完整的 AI + CAD 工程链路，数据层是地基。我的建议是，不管后续用什么 AI 方案，先把图纸的解析和结构化做扎实。具体来说，需要完成以下几件事：

第一，图纸格式统一。如果手头有 DWG、DXF、PDF 多种格式，先统一转成 DXF 或 STEP，减少后续处理的复杂度。第二，几何实体提取。把线段、圆弧、多段线、文字、标注、块参照全部解析出来，存成结构化的 JSON 或数据库表。第三，图层语义映射。建立图层名到业务含义的映射表，比如“WALL”对应墙体，“DOOR”对应门。第四，元数据抽取。从标题栏提取图号、名称、材料、比例、设计者等信息。

这一步做完，你就有了一个“图纸数据库”，后续的检索、分析、AI 应用都建立在这个基础之上。我见过太多项目跳过这一步，直接上大模型，结果模型再强也架不住输入是一堆乱码。

4.2 推理层：规则引擎和 AI 模型的分工

数据层之上是推理层。我的经验是，规则引擎和 AI 模型不是替代关系，而是互补关系。规则引擎擅长处理确定性的、有明确逻辑的判断，比如“如果图层名包含‘标注’，则跳过几何分析”；AI 模型擅长处理模糊的、需要语义理解的判断，比如“这段文字描述的是材料还是工艺”。

具体分工可以这样设计：规则引擎负责预处理和过滤，把明显无关的实体排除掉；AI 模型负责核心的语义理解和分类；最后再用规则引擎做后校验，把 AI 输出的结果和几何约束做一致性检查。这种“规则-AI-规则”的三明治结构，在实际项目里比纯 AI 或纯规则都稳定。

4.3 应用层：检索、审核、辅助设计三个落地方向

链路跑通之后，应用层可以做的事情就多了。我按落地难度从低到高排个序：

图纸检索是最容易落地的。基于结构化数据，你可以做全文检索、相似图纸推荐、按参数筛选。我们当时做了一个“找相似图纸”的功能，输入一张图纸，系统返回历史上最相似的 10 张，设计师反馈很有用。

图纸审核难度中等。基于规则引擎，可以自动检查图纸里的常见错误，比如标注缺失、图层错误、尺寸矛盾。AI 模型可以用来检查技术要求描述是否规范、材料选择是否合理。

辅助设计难度最高。这需要 AI 理解设计意图，并生成符合工程约束的方案。目前我还没看到真正能落地的案例，大多停留在实验室阶段。

5. 那些 Demo 不会告诉你的坑

5.1 图纸脏数据的七种典型形态

真实工程环境里的图纸，脏数据的花样比你想象的多。我整理了几种最常见的：

• 重复实体：同一条线段被画了两遍，坐标完全一样，但属于不同图层。
• 零长度线段：起点和终点坐标相同，肉眼看不见，但解析时会报错。
• 未闭合多段线：本该闭合的轮廓，起点和终点差了 0.001 毫米。
• 文字乱码：老图纸用的字体在新系统里找不到，显示成问号或方框。
• 块参照循环引用：A 块引用 B 块，B 块又引用 A 块，递归展开时死循环。
• 坐标偏移：图纸的基点不在原点，所有坐标都偏了一个大数。
• 图层冻结：有些实体在冻结图层里，解析时容易被忽略。

处理这些问题，没有一劳永逸的方案。我的做法是写一个“图纸体检”工具，在解析前先跑一遍，把问题列出来，能自动修的就修，不能修的就标记出来让人工处理。

5.2 精度问题：浮点数在 CAD 里的隐形杀手

CAD 里的坐标都是浮点数，浮点数比较是编程里的经典坑。在 CAD 场景下，这个问题尤其严重，因为图纸的精度要求很高，但浮点运算的误差会累积。

我的经验是，在 CAD 相关的代码里，永远不要用==比较两个浮点数。要用一个容差（tolerance），比如 1e-6 毫米。OpenCascade 里默认的容差是 1e-7，但实际项目里可能需要调整。另外，在做布尔运算之前，一定要先做几何清理，把距离小于容差的点合并，把角度接近 0 或 180 度的线段处理掉。

有个反直觉的点：精度不是越高越好。容差设得太小，会导致本该合并的点没合并，布尔运算失败；容差设得太大，会把本该分开的实体合并在一起，结果错误。需要根据你的图纸精度等级来调整。

5.3 性能瓶颈：当图纸大到几十兆

小图纸跑得飞快，大图纸直接卡死，这是 CAD 处理的常见问题。一张几十兆的 DWG 图纸，可能包含几十万个实体，解析、存储、渲染每一步都是挑战。

我们当时的优化策略是分三层：第一层是解析优化，用流式解析代替一次性加载，边读边处理，减少内存占用。第二层是存储优化，用空间索引（比如 R-tree）来加速查询，不要每次都全表扫描。第三层是计算优化，把耗时的几何运算放到后台线程或者分布式任务队列里，前端只做展示。

还有一个容易被忽略的点：DXF 文件里的实体顺序会影响解析速度。如果实体是按空间位置有序排列的，解析时可以提前终止；如果是乱序的，就得全部读完。有些 CAD 软件导出的 DXF 是乱序的，这时候可以考虑先做一次排序预处理。

6. 工具选型的实战对比：FreeCAD、OpenCascade 和商业方案

6.1 FreeCAD 作为原型验证平台的优势和局限

FreeCAD 是我最常用的原型验证工具，原因有三：开源免费、Python 接口友好、社区活跃。你可以用几行 Python 代码就完成一个 CAD 文件的读取和几何分析，非常适合快速验证想法。

但 FreeCAD 的局限也很明显。首先是性能，处理大图纸时明显吃力。其次是稳定性，某些复杂实体的操作会崩溃。第三是文档，虽然社区文档不少，但版本更新快，很多教程已经过时了。我建议把 FreeCAD 定位为“原型工具”，验证完业务逻辑后，核心模块用 OpenCascade 的 C++ 接口重写。

6.2 OpenCascade 的学习曲线和关键 API

OpenCascade 是工业级的几何内核，功能强大但学习曲线陡峭。我刚开始用的时候，光是把一个 STEP 文件读进来显示出来，就花了两天时间。关键是要理解它的数据结构：TopoDS_Shape 是顶层抽象，下面分 TopoDS_Solid、TopoDS_Shell、TopoDS_Face、TopoDS_Wire、TopoDS_Edge、TopoDS_Vertex。每个层级有自己的属性和操作方法。

几个高频 API 值得重点掌握：BRep_Builder用于构建拓扑结构，BRepTools用于读写文件，BRepAlgoAPI用于布尔运算，BRepExtrema用于距离计算。另外，ShapeFix_Shape和ShapeAnalysis这两个工具包在修复脏几何时非常有用。

6.3 商业方案值不值得上：成本与收益的权衡

商业方案（比如 ODA 的 Teigha、Autodesk 的 RealDWG）的优势是兼容性好、技术支持到位、文档齐全。劣势是授权费用高，而且通常按年收费。如果你的项目是内部工具，预算有限，我建议先用开源方案跑通，等业务价值验证清楚了再考虑商业方案。如果是面向外部客户的产品，商业方案的稳定性和法律合规性更有保障。

7. 如果现在让我重新做这个项目

7.1 从最小可用闭环开始，别一上来就搞大模型

如果让我重新做一遍，我会把节奏放慢，先做一个最小可用闭环。具体来说，第一步只做图纸解析和结构化存储，不做任何 AI。把这一步做扎实，确保能稳定处理 80% 的图纸。第二步加规则引擎，做图纸检索和简单审核。第三步才引入 AI 模型，做语义理解和辅助生成。

这样做的好处是，每一步都有明确的交付物，风险可控。我见过太多项目一上来就搞大模型，结果数据层没做好，模型效果上不去，最后项目烂尾。

7.2 数据质量比模型能力更值得投入

在 AI + CAD 这个领域，数据质量的重要性远高于模型能力。一张干净的、结构化的图纸数据，用简单的规则引擎就能做出很好的效果；一张脏的、混乱的图纸数据，再强的模型也救不回来。

我的建议是，把 60% 的精力花在数据清洗和结构化上，30% 花在规则引擎和业务逻辑上，10% 花在 AI 模型上。这个比例可能和很多人的直觉相反，但实际项目里就是这么回事。

7.3 工程化落地的三个关键指标

最后分享三个我用来判断项目是否真正落地的指标：

第一，覆盖率。你的系统能处理多少比例的图纸？如果低于 80%，说明数据层还有问题。第二，准确率。你的系统输出的结果，有多少是工程师直接采纳的？如果低于 70%，说明推理层还需要优化。第三，使用率。你的目标用户里，有多少人每周至少用一次？如果低于 30%，说明产品价值还没被验证。

这三个指标比任何 Demo 视频都更能说明问题。Demo 可以只展示最好的那 10%，但工程落地必须面对剩下的 90%。

我在实际项目里最大的体会是，AI + CAD 这个方向，技术不是瓶颈，耐心才是。愿意花时间把数据层做扎实、把边界条件处理干净的团队，最后都跑出来了；急着上模型、追热点的团队，大多卡在了半路上。如果你正在做类似的事情，不妨先停下来，看看你的图纸数据是不是真的准备好了。