企业官网建设流程全解析

1. 为什么“AI + CAD”的 Demo 看起来很美

过去一年多，我陆陆续续试了不下二十个号称“AI 自动画图”“AI 改 CAD”“自然语言生成图纸”的工具和开源项目。朋友圈里刷到的演示视频一个比一个震撼：输入一句“画一个带法兰的弯管”，几秒钟后屏幕上就出现了一个像模像样的三维模型；上传一张手绘草图，AI 立刻把它变成带尺寸标注的工程图。评论区一片“CAD 要完了”“画图狗要失业了”。

但真正把这种东西拿到实际工程项目里跑一遍，你会发现一个很尴尬的现实：Demo 阶段能跑通的东西，到了工程阶段几乎全部趴窝。这不是某一个工具的问题，而是整个“AI + CAD”赛道目前普遍存在的结构性断层。我把它总结成一句话：Demo 解决的是“看起来对”，工程解决的是“必须对”。

这两者之间的差距，比大多数人想象的要大得多。一个 Demo 只要在特定输入下产出一个视觉上合理的图形，就能录视频、发推文、拿融资。但一个工程项目要求的是：图纸能被下游软件正确打开、尺寸链闭合、图层规范统一、公差标注符合标准、版本可追溯、批量处理不出错、出了问题能定位到具体哪一步。这些要求里，任何一条不满足，整个方案就是废的。

我写这篇东西，不是要唱衰 AI 在 CAD 领域的应用。恰恰相反，我认为方向是对的，只是目前大量团队把力气用错了地方。他们花 90% 的精力去打磨那个“生成”的瞬间，却只花 10% 的精力去处理生成之后的工程化落地。而后者才是真正决定成败的地方。

这篇文章适合几类人看：正在做 AI + CAD 相关产品的开发者、想把 AI 引入现有设计流程的工程师、以及被各种 Demo 忽悠过、想搞清楚到底哪里出了问题的一线从业者。我会从数据格式、几何内核、工程约束、批量处理、实际案例几个层面，把“为什么走不通”这件事拆开讲清楚，并且给出我自己踩坑之后总结的一些可行路径。

2. 核心断层拆解：Demo 和工程之间到底差了什么

2.1 数据格式的“最后一公里”问题

先说一个最基础、也最容易被忽视的问题：文件格式。热词里出现了 DXF、DWG、FreeCAD，这几个词背后其实是一整套数据交换的噩梦。

Demo 通常怎么做？要么自己定义一个简单的内部格式，要么直接操作某个开源库的内存对象。比如用 Python 的ezdxf生成一个 DXF，或者用 FreeCAD 的脚本接口建一个模型。这些在演示环境里都没问题，因为演示环境是你自己控制的。

但工程环境里，图纸要在不同软件之间流转。上游可能是 AutoCAD 出的 DWG，中间要导入 Allegro 做 PCB 布局，或者导入 EPLAN 做电气设计，下游还要转成 SHP 做地理信息处理。每经过一次转换，信息就可能丢失一层。我实测过一个典型案例：一个带属性的块（Block）从 DWG 导出成 DXF，再用librecad打开，属性文字直接变成了普通文本，关联关系全没了。你用 AI 生成的东西，如果一开始就没有考虑这些格式的兼容性，到了这一步就是灾难。

更麻烦的是 DWG 本身。DWG 是闭源二进制格式，虽然有dwg trueview这类查看器，但要在程序里可靠地读写，选择非常有限。很多 AI 项目为了绕开这个坑，选择只支持 DXF，然后告诉用户“你先把 DWG 转成 DXF 再用”。这个“先转一下”在 Demo 里是一句话，在工程里可能意味着几百张图纸的批量转换，而且转换过程本身就会引入错误。

注意：如果你的 AI 工具只支持 DXF，一定要在文档里明确写清楚，并且提供一个可靠的 DWG 转 DXF 的预处理方案。不要假设用户会自己搞定这件事。

2.2 几何内核：AI 生成的是“形状”，工程需要的是“模型”

这是我认为最核心的一个断层。当前大多数 AI 生成 CAD 的方案，底层用的是网格（Mesh）或者简单的实体表示。AI 模型（比如基于扩散的、基于 Transformer 的）输出的往往是一堆顶点和面片，看起来是个三维形状，但它不是一个参数化实体模型。

这两者的区别有多大？打个比方：网格模型就像用橡皮泥捏出来的一个杯子，你能看到它、能 3D 打印它，但你没法告诉别人“这个杯子的壁厚是 2 毫米，杯口直径是 80 毫米，高度是 120 毫米”。而参数化实体模型是一组带约束的特征树：拉伸、旋转、倒角、阵列，每个特征都有明确的参数。工程图要标注尺寸、要改参数、要做干涉检查、要出 BOM 表，全都依赖这个特征树。

我试过一个开源项目，用 AI 从图片生成 FreeCAD 模型。生成出来的东西在 FreeCAD 里能看，但打开特征树一看，只有一个导入的网格对象，没有任何可编辑的特征。你想改一个孔的直径？对不起，只能重新生成。这在 Demo 里没问题，在工程里完全没法用。

所以，AI 生成 CAD 的真正难点不在于生成形状，而在于生成带约束的特征树。这需要 AI 模型理解几何约束、尺寸驱动、特征依赖这些概念，而目前大多数模型根本没有在这个层面上训练过。

2.3 工程约束：图层、线型、标注、公差，一个都不能少

工程图纸不是艺术品，它是一份技术文档，有严格的规范。图层怎么分、线型怎么定、标注样式是什么、公差怎么标，这些都有行业标准和企业标准。AI 生成的东西，如果不符合这些规范，审图这一关就过不了。

热词里有个“逆冲断层 cad 线型”，这其实是个很好的例子。地质剖面图里，逆冲断层要用特定的线型和符号表示，这不是随便画条线就行的。AI 如果不懂这个规范，生成的图就是废的。类似的还有“freecad 标注公差”，公差标注涉及配合制度、基准体系，不是加个数字就完事。

我在实际项目里遇到过这样的情况：用 AI 辅助生成了一批零件图，形状都对，但图层全乱套了。所有线条都在默认图层上，标注样式用的是默认的 Standard，线型比例也不对。结果就是，这批图没法直接进企业的 PDM 系统，必须人工重新整理一遍。这个“人工整理”的时间，比直接手画还长。

2.4 批量处理与稳定性：Demo 跑一次，工程跑一千次

Demo 的另一个特点是：只跑一次，而且是在精心准备的输入上跑。工程场景是什么？是批量处理。比如“把这一千张图纸里的标题栏信息提取出来”“把这两百个 DWG 批量转成 DXF 并清理图层”“对这批零件图批量添加公差标注”。

批量处理对稳定性的要求是指数级上升的。单次运行成功率 95%，听起来不错吧？但跑一千次，全部成功的概率是 0.95 的 1000 次方，约等于零。工程上要求的是 99.9% 以上的单次成功率，而且失败的时候要能明确知道是哪一张、哪一步、什么原因失败的。

我见过太多 AI 工具，在单张图纸上表现惊艳，一上批量就各种崩溃：内存泄漏、文件句柄没释放、异常没捕获、编码问题、路径问题。这些问题在 Demo 里根本暴露不出来，因为 Demo 只跑一次。

3. 实操层面：一个真实的 AI + CAD 落地尝试

3.1 项目背景与目标设定

去年我参与了一个内部项目，目标是：用 AI 辅助从二维工程图自动提取几何信息和标注信息，生成结构化的数据，用于后续的自动报价和工艺规划。输入是 DWG 格式的零件图，输出是 JSON 格式的结构化数据，包含轮廓、孔位、尺寸、公差、材料等信息。

选这个目标，是因为它比“AI 直接生成图纸”要务实得多。提取信息比生成信息，对几何精度的要求低一些，但对数据完整性和一致性的要求高一些。而且这个需求在制造业里非常普遍，做好了确实能省大量人工。

3.2 技术选型与踩坑记录

我们一开始的选型是这样的：

这里重点说几个坑。

第一个坑是DWG 读取。我们一开始想用某个开源方案，结果发现它对 AutoCAD 的自定义实体（比如动态块、约束）支持极差，读出来的东西缺胳膊少腿。后来换成 ODA 的库，情况好一些，但还是要自己写一层解析，把各种实体类型统一成内部表示。这个过程花的时间，比预想的多了一倍。

第二个坑是标注识别。工程图里的标注不是简单的文字，它包含尺寸线、尺寸界线、箭头、公差符号、基准符号。你用通用 OCR 去识别，它只能认出数字，认不出这个数字属于哪个尺寸，也认不出公差。我们最后是自己写了一个基于 DXF 实体关系的解析器：先找到标注实体，再根据它的关联点找到被标注的几何，最后把尺寸值和几何关联起来。这个逻辑不复杂，但需要你对 DXF 的标注实体结构非常熟悉。

第三个坑是字体问题。热词里有“cad 字体 hz-s”，这其实是个典型问题。工程图里用的字体五花八门，有 SHX 字体、有 TrueType 字体、有自定义字体。AI 模型如果没见过这些字体，识别率会惨不忍睹。我们的做法是：先把图纸里的文字实体导出成图片，用这些图片去微调一个 OCR 模型。这个过程需要标注数据，我们人工标了几千张，才把识别率从 60% 提到 95% 以上。

3.3 关键步骤的详细实现

整个流程我拆成五步，每一步都有具体的操作和参数。

第一步：DWG 预处理与格式转换。我们写了一个批处理脚本，用 ODA 的接口把 DWG 转成 DXF，同时做几件事：炸开所有块（因为块里的实体不炸开，后续解析会漏）、清理无用图层、统一线型比例。这一步的输出是干净的 DXF 文件。参数上，炸开块的时候要注意保留属性，否则标题栏信息会丢。

第二步：实体解析与几何重建。用ezdxf读取 DXF，遍历所有实体。对于 LINE、ARC、CIRCLE、LWPOLYLINE 这些基本实体，直接提取几何参数。对于标注实体（DIMENSION），提取它的定义点和测量值。对于文字实体（TEXT、MTEXT），提取内容和位置。这一步的关键是建立实体之间的关联关系，比如哪个标注对应哪条线。

第三步：轮廓识别与特征提取。把提取到的线段和圆弧，按照端点连接关系拼成闭合轮廓。这里用的是图论的方法：把每个端点当成图的节点，线段当成边，找连通分量和环。拼出轮廓后，再识别孔、槽、台阶这些特征。这一步的难点是处理断线和不闭合的情况，工程图里这种情况很常见。

第四步：标注与几何的关联。对于每个标注，找到它标注的几何对象。DXF 的标注实体里有defpoint和defpoint2这些定义点，根据这些点去找最近的几何对象。然后判断标注类型：是线性标注、半径标注、直径标注还是角度标注。最后把尺寸值和公差信息提取出来。

第五步：结构化输出与校验。把前面提取的所有信息，按照下游系统的 schema 组装成 JSON。同时做一轮校验：轮廓是否闭合、尺寸是否齐全、公差是否在合理范围。校验不通过的，标记出来人工复核。

3.4 实测数据与效果评估

这个项目跑下来，单张图纸的处理时间在 3 到 8 秒之间，取决于图纸复杂度。准确率方面，几何提取的准确率在 98% 以上，标注识别的准确率在 95% 左右，特征识别的准确率在 90% 左右。这个数字看起来不错，但距离“无人值守”还有距离。

我们算过一笔账：原来人工处理一张图纸平均需要 15 分钟，用这个工具之后，平均需要 3 分钟（包括人工复核和修正）。效率提升了 5 倍，但并没有完全替代人工。这个结果我认为是符合预期的，也是目前 AI + CAD 落地的一个典型状态：能大幅提效，但还不能完全自动化。

4. 常见问题与排查技巧实录

4.1 格式转换类问题速查

4.2 几何与标注类问题排查

问题一：轮廓拼不闭合。这是最常见的。原因通常是线段之间有微小间隙，或者端点坐标有浮点误差。解决办法是设置一个容差，比如 0.001 毫米，在这个容差内认为端点是重合的。另外要注意，有些线段看起来连着，实际上中间有个很小的圆弧过渡，这种要特殊处理。

问题二：标注识别错位。有时候标注的尺寸值识别对了，但关联到了错误的几何对象。这通常是因为标注的定义点离多个几何对象都很近。解决办法是结合标注的类型和方向来判断，比如线性标注通常关联到两条平行线，半径标注关联到一个圆弧。

问题三：公差符号识别不了。公差符号（比如直径符号、±、角度符号）在 DXF 里可能是特殊字符或者自定义实体。我们的做法是建立一个符号映射表，把常见的符号编码映射成标准字符。对于自定义实体，只能针对特定软件做适配。

问题四：批量处理时内存溢出。这是工程化的典型问题。单张图纸处理完，对象没有释放，跑几百张之后内存就爆了。解决办法是每处理完一张图纸，显式调用垃圾回收，并且把大对象置空。另外，用多进程而不是多线程，因为 Python 的 GIL 会限制多线程的效果。

4.3 独家避坑技巧

第一个技巧：永远不要相信 AI 生成的几何是精确的。AI 生成的坐标、尺寸，一定要做一轮几何校验。比如检查轮廓是否闭合、尺寸是否自洽、公差是否合理。我见过 AI 生成的图纸，标注的尺寸和实际几何差了 0.5 毫米，这种错误在 Demo 里看不出来，在工程里是致命的。

第二个技巧：把 AI 当成“第一稿生成器”，而不是“最终稿生成器”。AI 生成的东西，一定要有人工复核的环节。这个环节不是可有可无的，而是必须的。我们的项目里，人工复核的时间占了总时间的 40%，但如果没有这个环节，错误率会高到无法接受。

第三个技巧：建立自己的测试集。不要用网上的公开数据集来评估你的工具，因为那些数据集和你的实际业务场景差太远。你要从自己的历史图纸里，挑出有代表性的样本，建立一个测试集。这个测试集要覆盖各种边界情况：简单件、复杂件、带公差的、带特殊符号的。每次迭代都用这个测试集跑一遍，看准确率有没有下降。

第四个技巧：日志要详细到能复现问题。批量处理的时候，出了问题要能定位到具体是哪张图纸、哪个实体、哪一步出的错。我们的日志里记录了每张图纸的处理时间、实体数量、识别结果、校验结果。出了问题，直接看日志就能定位。

5. 从 Demo 到工程：可行的落地路径

5.1 重新定义问题边界

我认为目前 AI + CAD 落地最大的误区，是试图一步到位解决“AI 自动设计”。这个目标太宏大，涉及几何推理、工程约束、行业知识，短期内不可能做好。更可行的路径是：把问题拆小，先解决那些“AI 擅长、工程需要、人工做很烦”的环节。

哪些环节符合这个条件？我列几个：

• 图纸信息提取：从 DWG/DXF 里提取标题栏、明细表、尺寸、公差，生成结构化数据。这个 AI 做起来比人快，而且不需要生成几何，风险低。
• 图纸格式转换与清理：批量转换格式、统一图层、清理无用实体。这个用脚本就能做，加上 AI 可以做智能判断。
• 图纸比对与查重：找出两张图纸的差异，或者从图纸库里找出相似的图纸。这个用几何哈希加 AI 特征匹配，效果不错。
• 辅助标注与检查：检查图纸有没有漏标尺寸、公差是否合理、图层是否规范。这个用规则引擎加 AI 判断，能省很多审图时间。

这些环节的共同特点是：输入是已有的图纸，输出是数据或判断，不涉及生成新的几何。这样就绕开了几何内核和参数化建模的难题，落地难度大幅降低。

5.2 技术栈的务实选择

如果你现在要做一个 AI + CAD 的项目，我的建议是：

• 格式处理层：用 ODA 或者ezdxf做 DXF 读写，DWG 用 ODA 转换。不要自己造轮子去解析 DWG 二进制。
• 几何处理层：用shapely做二维几何运算，用trimesh做三维网格处理。如果需要参数化建模，用 FreeCAD 的 Python API 或者 OpenCASCADE。
• AI 层：对于文字识别，用 PaddleOCR 或者自己微调；对于几何特征识别，用传统的计算机视觉加规则，不要什么都上大模型；对于语义理解（比如理解图纸标题栏的含义），可以用大模型。
• 工程化层：用 Celery 或者 RQ 做任务队列，用 PostgreSQL 存结构化数据，用 MinIO 存文件。日志用 ELK 或者 Loki。

这个技术栈不新潮，但稳。工程落地，稳比新潮重要。

5.3 评估指标与迭代节奏

评估一个 AI + CAD 工具好不好，不要看 Demo 视频，要看这几个指标：

迭代节奏上，我建议小步快跑。先做一个最小可用版本，在真实场景里跑，收集问题，然后迭代。不要憋大招，憋出来的大招往往一上真实场景就崩。

6. 一些个人体会

这个项目做下来，我最大的体会是：AI 在 CAD 领域的价值，不在于替代人，而在于把人从重复劳动里解放出来。那些真正需要工程判断、需要经验积累的环节，AI 短期内替代不了，也不应该替代。但那些“看一眼就知道、但要看一千遍”的环节，AI 可以做得很好。

另一个体会是：工程落地是一个系统工程，不是单点技术突破。你有一个很牛的 AI 模型，但格式转换做不好、批量处理不稳定、错误没法定位，整个方案就是废的。反过来，即使 AI 模型一般，但工程化做得好，也能产生实际价值。

最后分享一个小技巧：如果你在做 AI + CAD 的项目，一定要尽早接触真实数据。不要用网上的公开数据集，不要用自己造的测试数据，要用真实项目里的图纸。真实图纸的“脏”程度，会远超你的想象。早点面对这些脏数据，早点找到解决方案，比在干净数据上刷指标有意义得多。

这个方向后续还可以这样扩展：把提取出来的结构化数据，和工艺知识库结合，做自动工艺规划；或者和报价系统结合，做自动报价。这些都是在“信息提取”这个基础上自然延伸出来的，比直接做“AI 生成图纸”要靠谱得多。