企业官网建设流程全解析

1. 为什么“AI + CAD”的 Demo 看起来无所不能，一进工程就趴窝

过去两年，我陆陆续续参与了几个把 AI 往 CAD 工作流里塞的项目，从最开始的“用大模型读图纸、自动生成标注”，到后来的“自然语言驱动参数化建模”，再到“批量识别 DWG 里的图层和线型做合规检查”。几乎每一个项目都经历过同一个剧本：第一周做出一个惊艳的 Demo，第二周信心满满地拿去给一线工程师看，第三周开始被各种“这个图它读不了”“这个尺寸它算错了”“这个图层它认反了”按在地上摩擦，最后要么砍需求，要么退回人工兜底。

这个现象太普遍了，普遍到我觉得有必要把踩过的坑系统性地写一写。标题里说的“Demo 满天飞，工程却走不通”，不是唱衰，而是一个真实存在的断层。Demo 面对的是“一张干净、标准、理想化的图纸”，工程面对的是“十年积累下来的、图层命名混乱、块嵌套七八层、线型自定义、外部参照丢失、单位不统一”的真实文件。这两者之间的差距，不是模型能力差一点，而是整个数据链路、工程约束、验证机制全都不在一个维度上。

这篇文章适合三类人看：一是正在或准备把 AI 能力接入 CAD 流程的开发者，二是被各种“AI 自动出图”方案轰炸过、想搞清楚到底能不能落地的一线工程师，三是做技术选型、需要判断一个 AI+CAD 方案靠不靠谱的负责人。我会围绕AI、CAD、DXF、DWG、FreeCAD这几个核心关键词，把“为什么走不通”拆成可操作的层面，给出我实际验证过的思路和避坑经验。全文不吹不黑，只讲我亲手试过、亲眼见过的东西。

2. 先搞清楚 CAD 数据的真实形态，别拿 Demo 的理想数据骗自己

2.1 DWG 和 DXF 到底差在哪，为什么选错格式直接决定项目生死

很多人做 AI+CAD 的第一步就栽在格式上。Demo 阶段大家习惯用 DXF，因为它是文本格式，解析库多，Python 里ezdxf几行代码就能读出来，看起来特别美好。但一到工程现场，甲方给你的十有八九是 DWG，而且是各种版本、各种来源的 DWG。

DWG 是 Autodesk 的私有二进制格式，官方没有公开完整规范。你能找到的开源解析方案，要么依赖 ODA（Open Design Alliance）的库，要么用一些逆向出来的读取器，稳定性和覆盖度都参差不齐。DXF 虽然是交换格式，但它分 ASCII 和二进制两种，而且不同版本（R12、R2000、R2004、R2007、R2010、R2013、R2018）的实体支持差异很大。我见过一个项目，Demo 用 R12 的 DXF 跑得飞起，结果现场给的是 R2018 的 DWG，里面用了大量动态块和自定义对象，解析出来直接丢了一半信息。

这里有个很实际的判断逻辑：如果你的 AI 能力只需要读几何（线段、圆弧、多段线、文字），那 DXF 够用，优先让上游导出 DXF。但如果你的能力依赖图层语义、块属性、标注样式、外部参照，那必须直面 DWG，而且要接受“解析不完整”这个现实，在设计方案时就留好降级路径。

2.2 图层、块、外部参照：AI 最容易误读的三座大山

我做过一个“自动识别图纸内容并分类”的实验，用大模型去读 DXF 里提取出来的文字和图层名。结果发现，同一个“墙体”概念，在不同项目里可能叫WALL、Q-墙体、A-WALL、墙、WALL-200、0（对，很多人画图全在 0 层）。你让模型去猜，它猜对的概率在 Demo 里很高，因为 Demo 数据是你自己整理的。但工程里图层命名是历史遗留问题，没有统一标准。

块（Block）更麻烦。一个图块可能嵌套了五层，每层有自己的缩放和旋转，块属性里还藏着关键信息。AI 如果只读最外层的几何，拿到的坐标和实际位置对不上。外部参照（Xref）则是另一个坑：图纸本身不包含被参照的内容，你解析出来的是一堆“占位符”，真正的几何在另一个文件里。Demo 里没人用 Xref，工程里 Xref 是常态。

实操心得：在解析阶段就把“图层名归一化”和“块展开”做成独立模块，不要指望 AI 模型去理解这些。规则能解决的，不要交给模型。模型应该用在“规则解决不了”的地方，比如模糊语义匹配、异常检测。

2.3 单位、比例、坐标系：一个没对齐，后面全白算

CAD 图纸里的单位是个隐形杀手。有的图按毫米画，有的按米画，有的图框是 1:100 但模型空间是 1:1。你从 DXF 里读出来的坐标是“图形单位”，不是“现实尺寸”。如果 AI 要做尺寸校验、面积计算、碰撞检测，单位不统一直接导致结果错得离谱。

我遇到过一个案例：AI 判断两根管线间距不足，报警了。工程师一看，说“这俩差着 300 毫米呢”。问题出在，一根线在模型空间按毫米画，另一根在布局空间按米画，AI 把两个坐标直接相减，得出了“间距 0.3”的结论，然后按毫米理解成 0.3 毫米。这种错误在 Demo 里永远不会出现，因为 Demo 数据是你自己按统一单位造的。

坐标系还涉及 UCS 和 WCS 的区别。很多图纸在绘制时旋转过 UCS，你读出来的坐标是 WCS 下的，但工程师标注的尺寸是基于 UCS 的。AI 如果不做转换，算出来的角度和距离全是错的。

3. 把 AI 塞进 CAD 流程，到底哪些环节真的能提效

3.1 从“读图”到“懂图”：语义理解的边界在哪里

AI 在 CAD 里最容易做出效果的是“读图”这一步，也就是把图形信息转成结构化数据。比如用 OCR 或视觉模型识别图纸里的文字标注，用几何算法提取线段和圆弧，用分类模型判断图元类型。这些在 Demo 里效果都不错，因为输入相对干净。

但“懂图”是另一回事。懂图意味着理解设计意图：这条线为什么画在这里，这个尺寸为什么这么标，这个图层为什么用这个颜色。这需要领域知识，而领域知识在图纸里往往是隐式的。比如建筑图里，一根虚线可能代表梁的投影，也可能代表吊顶边界，还可能代表隐藏的管线。你让 AI 去判断，它需要上下文，而上下文可能分散在图纸说明、图层规范、甚至项目文档里。

我的经验是：把 AI 的能力边界划在“提取和初筛”上，不要让它做“最终判断”。AI 可以告诉你“这里有 200 个文字标注，其中 15 个可能不符合命名规范”，但最终确认必须由规则或人来兜底。Demo 喜欢展示“AI 全自动完成”，工程需要的是“AI 辅助 + 人工确认”的闭环。

3.2 参数化建模与自然语言驱动：FreeCAD 为什么是个好试验田

FreeCAD 在这波 AI+CAD 探索里被频繁提到，不是没有原因。它是开源的，Python API 完善，参数化建模的底层逻辑清晰，非常适合做“自然语言生成模型”的实验。你可以用大模型把“画一个长 5 米、宽 3 米、高 2.8 米的房间”转成 FreeCAD 的脚本，然后执行生成几何。

但这里有个关键限制：FreeCAD 的建模逻辑是“特征树”，每一步操作都依赖前一步的结果。大模型生成的脚本如果顺序错了、参数引用错了，整个模型就崩了。Demo 里你生成一个简单盒子没问题，工程里你要生成一个有几十个特征、依赖关系复杂的装配体，模型出错率会指数级上升。

我试过一个折中方案：不让 AI 直接生成完整脚本，而是让它生成“参数和约束”，然后由预置的模板脚本去执行。比如 AI 只负责输出“长度=5000，宽度=3000，高度=2800，墙体厚度=200”，模板脚本负责调用 FreeCAD API 建模。这样 AI 的输出空间被压缩，出错概率大幅降低，而且模板脚本可以复用、可以测试、可以版本管理。

3.3 批量处理与合规检查：AI 真正能落地的场景

如果说有一个场景是 AI+CAD 目前最接近工程落地的，我认为是“批量合规检查”。比如检查图纸里有没有违反图层规范的图元，有没有未闭合的多段线，有没有标注缺失，有没有线型用错。这些任务的特点是：规则明确、重复性高、人工做很枯燥、AI 做初筛很合适。

我参与过一个项目，用规则引擎 + 轻量模型对上千张 DWG 做批量检查。规则引擎负责硬性检查（图层名、线型、颜色），模型负责软性检查（文字语义、图元分类）。最终输出一份问题清单，工程师只需要复核清单，不需要从头看图。这个方案的效果是：检查效率提升了大概 3 到 4 倍，但前提是我们花了大量时间把规则梳理清楚，并且接受了“模型会有误报”这个事实。

注意：批量处理最怕的是“静默失败”。一张图解析出错，如果程序不报错、不记录，你根本不知道漏了多少。一定要在流程里加日志和校验点，每处理一张图都记录状态，失败的单独拎出来人工处理。

4. 工程走不通的五个真实卡点与破解思路

4.1 卡点一：数据脏，且脏得没有规律

工程图纸的“脏”是全方位的：图层乱、块嵌套深、文字是炸开的、线型是自定义的、标注是手动改过的。你没法用一套规则覆盖所有情况，因为每个项目、每个设计院、甚至每个绘图员都有自己的习惯。

破解思路是“分层处理”。第一层用最宽松的规则做粗筛，把明显无关的图元过滤掉；第二层用模型做分类和语义提取；第三层用人工确认关键结果。不要试图一步到位，Demo 的一步到位是假象，工程的分层兜底才是现实。

4.2 卡点二：AI 的输出不可验证，错了也不知道

大模型有个特性：它输出错误答案时，语气和输出正确答案时一样自信。在 CAD 场景里，这意味着 AI 告诉你“这条线长度是 5000”，你如果不手动量一下，根本不知道它是不是在胡说。Demo 里没人验证，工程里必须验证。

我的做法是：所有 AI 输出的关键数值，都要有一个“可验证的锚点”。比如 AI 说某段距离是 5000，那就用几何算法独立算一遍，两者对比，不一致就标记出来。几何算法是确定性的，模型是概率性的，用确定性去校验概率性，是目前最务实的方案。

4.3 卡点三：CAD 软件生态封闭，集成成本极高

AutoCAD、MicroStation、Allegro、EPlan 这些软件各有各的格式和 API，你想把 AI 能力嵌进去，要么用它们的二次开发接口，要么走文件交换。二次开发接口学习成本高、版本兼容性差、授权费用贵；文件交换则面临格式转换的信息丢失问题。

FreeCAD 和 LibreCAD 这类开源工具在这里反而有优势，因为它们的格式和 API 是开放的，适合做原型验证。但工程现场不会因为你用 FreeCAD 就改用 FreeCAD，最终还是要回到 DWG 生态。所以我的建议是：用开源工具做能力验证，用文件交换做工程集成，接受转换损耗，在转换前后加校验。

4.4 卡点四：工程师不信任黑盒，AI 必须可解释

一线工程师对 AI 的态度，用一句话概括就是“你先证明你靠谱，我再考虑用你”。Demo 展示的是“AI 自动完成了”，工程师关心的是“它为什么这么做”“它什么时候会出错”“出错了我怎么改”。如果你的 AI 是个黑盒，工程师不会把关键任务交给它。

可解释性在 CAD 场景里尤其重要，因为图纸是要负责的。我的做法是：AI 的每一个输出都附带“依据”。比如“判断这条线是墙体，因为它在 WALL 图层且线宽为 0.3”，把依据展示出来，工程师可以快速判断对错，也可以基于依据去调整规则。

4.5 卡点五：项目周期和 AI 迭代周期不匹配

AI 模型的迭代是以周甚至天为单位的，CAD 工程项目是以月甚至年为单位的。你在项目中期换一个模型版本，可能之前调好的提示词、阈值、后处理逻辑全要重来。这种不匹配导致很多 AI+CAD 项目在 Demo 之后无法持续维护。

破解思路是“解耦”。把 AI 能力封装成独立的服务，输入输出接口固定，模型版本可以独立升级。CAD 流程只依赖接口，不依赖具体模型。这样模型迭代不会影响工程流程，工程流程的变更也不会影响模型。

5. 一套可复现的 AI+CAD 最小验证流程

5.1 环境准备与工具选型

如果你想自己动手验证，我建议从下面这套组合开始，成本低、可控性强：

• Python 3.10+：主语言，生态最全。
• ezdxf：读写 DXF，文档清晰，社区活跃。
• FreeCAD：做参数化建模验证，Python API 直接调用。
• OpenCASCADE（通过 pythonocc 或 FreeCAD 内置）：做几何运算和拓扑检查。
• 一个本地可跑的大模型：用于语义提取和分类，避免依赖外部服务。

安装 FreeCAD 的 Python 环境时要注意版本匹配，FreeCAD 内置的 Python 版本可能和你系统的 Python 不一致。我一般直接用 FreeCAD 自带的 Python 解释器跑脚本，省去环境冲突的麻烦。

5.2 从 DWG 到结构化数据的关键步骤

第一步是格式转换。如果拿到的是 DWG，先用 ODA File Converter 或同类工具转成 DXF。转换时注意选择版本，建议用 R2013 或 R2018，兼容性较好。转换后一定要做一次完整性校验，对比转换前后的实体数量，差异过大说明转换丢了东西。

第二步是解析 DXF。用 ezdxf 读取时，重点提取这几类信息：图层列表、图元类型和坐标、文字内容、块定义和块引用、标注样式。解析完先做统计，看看图层有多少、图元有多少、块有多少，心里有个数。

第三步是归一化。把图层名统一大小写、去掉前后空格、按规则映射到标准分类。把块展开成基本图元，记录展开后的坐标变换。把单位统一到毫米，所有坐标乘以对应的比例因子。

第四步才是 AI 介入。把归一化后的文字和图层信息喂给模型，做分类和语义提取。模型的输出要结构化，比如 JSON 格式，方便后续程序处理。

5.3 用 FreeCAD 做参数化验证的实操记录

我拿一个简单的房间模型做过验证。流程是：用户输入“画一个 5 米乘 3 米的房间，墙厚 200，高 2800”，大模型输出参数 JSON，FreeCAD 脚本读取 JSON 并建模。

脚本的核心逻辑是：先创建草图，画矩形，约束尺寸，然后拉伸成墙，再开洞。每一步都加了异常捕获，如果某一步失败，记录失败原因并回滚。实测下来，简单模型成功率很高，但一旦参数之间有冲突（比如墙厚大于房间宽度的一半），模型就会报错。这时候 AI 是不知道的，需要脚本把错误信息返回给用户，让用户调整参数。

这个验证让我确认了一件事：AI 负责“翻译需求”，脚本负责“执行建模”，两者之间用结构化参数解耦，是目前最稳的方案。

5.4 验证结果的评估标准

怎么判断一个 AI+CAD 方案是否值得继续投入？我一般看三个指标：

• 解析完整度：能正确读取的图元占比，低于 90% 就要警惕。
• 语义准确率：AI 分类和提取的准确率，抽样人工核对，低于 85% 就要优化。
• 人工兜底成本：AI 处理完后，人工需要花多少时间复核和修正。如果比纯人工还慢，方案就没有价值。

这三个指标在 Demo 阶段往往被忽略，因为 Demo 数据太干净了。一定要用真实项目的数据去测，哪怕只有十张图，也比一百张理想图有参考价值。

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

6.1 解析类问题速查

6.2 模型输出类问题速查

6.3 我踩过的三个印象最深的坑

第一个坑是“以为 DXF 是标准”。我早期做一个批量检查工具，只支持 DXF，结果现场一半的图是 DWG，而且转出来的 DXF 丢了很多块信息。后来我学乖了，任何方案都先问清楚数据来源和格式，再决定技术路线。

第二个坑是“让模型做算术”。我试过让大模型直接从图纸文字里提取尺寸并计算面积，结果它算错了好几次。后来改成模型只负责提取文字，计算交给 Python，准确率立刻上去了。模型擅长语义，不擅长精确计算，这个边界要划清楚。

第三个坑是“忽略日志”。早期跑批量任务，程序不报错但结果不对，查了半天才发现是某几张图的图层名有特殊字符，导致解析异常但被静默跳过了。后来我在每个环节都加了日志和校验点，问题定位时间从半天缩短到几分钟。

实操心得：在 AI+CAD 项目里，最值钱的不是模型，而是“数据清洗 + 规则引擎 + 校验机制”这套基础设施。模型可以换，基础设施换起来成本极高。先把基础设施搭好，再考虑模型选型。

7. 我对这个方向的一些真实判断

AI+CAD 不是伪命题，但它目前被过度包装了。Demo 满天飞是因为做 Demo 的成本很低，拿几张干净图纸、调一个模型、录个视频就能展示。工程走不通是因为工程要面对的是真实数据的复杂性、验证的严格性、集成的封闭性，这些都不是靠一个更强的模型能解决的。

我个人的判断是：短期内，AI 在 CAD 里最有价值的场景是“辅助提取”和“批量初筛”，而不是“全自动设计”。把 AI 放在流程的中间环节，前面用规则做清洗，后面用人工做确认，这个组合目前最稳。FreeCAD 这类开源工具会继续扮演试验田的角色，但工程落地还是要回到 DWG 生态，接受格式转换的损耗，在损耗可控的前提下做能力集成。

如果你正在做类似的项目，我的建议是：先用真实数据跑一遍最小验证，别急着上模型，先把数据链路打通。数据链路通了，模型的效果会自然显现；数据链路不通，再强的模型也是空中楼阁。这个顺序搞反了，就是 Demo 和工程之间那道跨不过去的坎。