1. 从一堆跑得通的Demo说起过去一年多我陆陆续续接触了十几个号称AI CAD的项目有创业团队做的有设计院内部孵化的也有大厂实验室流出的原型。几乎每一个在演示环节都让人眼前一亮上传一张图纸AI自动识别出墙、柱、梁、门窗输入一段自然语言模型直接吐出对应的参数化草图甚至还有能根据规范条文自动检查图纸合规性的。但真正推进到工程落地阶段十个里有九个卡住了剩下那一个也在勉强维持。这个现象不是偶然。我后来复盘了这些项目的共同特征发现问题几乎都集中在几个固定的环节上数据格式的转换损耗、几何语义的丢失、工程约束的不可验证性以及最要命的——Demo阶段可以容忍的误差在工程语境下是不可接受的。一个识别准确率90%的模型在演示时看起来很美但放到一张有几千个图元的施工图上10%的错误意味着几百处需要人工复核这比从头画一遍还累。所以这篇内容我想聊的不是AI能不能做CAD而是为什么从Demo到工程之间有一条几乎被低估的鸿沟以及这条鸿沟到底由哪些具体的工程问题构成。适合正在做相关探索的开发者、想引入AI能力的设计团队技术负责人以及对CAD数据链路感兴趣但还没踩过坑的同行。我会尽量把每个环节的技术细节和实际踩坑经验都摊开讲不回避那些看起来能解决但其实解决不了的部分。2. 图纸数据从DWG到可计算格式的损耗链条2.1 DWG不是为AI准备的数据格式很多人一开始会低估这件事的难度。DWG是Autodesk的私有二进制格式它的设计目标是高效存储和渲染而不是语义表达。这意味着当你把一个DWG文件解析出来的时候你拿到的是一堆图元线段、圆弧、多段线、块引用、文字、填充。这些图元之间没有显式的拓扑关系没有这是一面墙的语义标签甚至同一个建筑构件可能由十几条独立的线段拼成。我见过一个团队的做法是直接用ODAOpen Design Alliance的库把DWG转成DXF然后用ezdxf或者类似工具读取实体列表。这个链路本身没问题但问题在于转换过程中的信息丢失。比如块引用INSERT在转换后可能被展开成散落的图元动态块的参数信息完全丢失图层信息虽然保留了但很多设计院的图层命名毫无规律——0层图层1A-WALL-临时混在一起。2.2 DXF作为中间格式的取舍DXF是文本格式可读性好几乎所有CAD软件都支持导入导出。但它在AI场景下有几个硬伤。第一是文件体积膨胀一个10MB的DWG转成DXF可能变成80MB甚至更大解析时间成倍增加。第二是精度问题DXF的浮点数表示在某些实现里会有舍入误差对于需要精确对齐的几何操作来说这是致命的。第三是版本碎片化DXF有R12、R2000、R2004、R2007、R2010、R2013、R2018等多个版本不同版本支持的实体类型和属性不同你写的解析器要兼容所有版本几乎是不可能的任务。我个人的经验是如果只是做二维图纸的语义识别DXF够用但要选一个固定版本推荐R2013或R2018并且在转换时明确指定不展开块引用、保留图层和扩展数据XDATA。如果要做三维几何相关的操作DXF基本可以放弃了直接上STEP或者用OpenCascade的原生格式。2.3 OpenCascade在CAD-AI链路中的真实位置OpenCascadeOCCT是一个开源的几何建模内核支持BRep边界表示数据结构能做布尔运算、倒角、曲面求交这些真正的几何操作。很多AICAD项目会提到它但实际用对的很少。我见过一个典型的误用团队把DWG转成DXF再把DXF的线段喂给OCCT去构建拓扑试图自动识别出房间这样的封闭区域。这个思路在简单图纸上能跑通但一旦遇到线段不闭合、有微小间隙、或者存在重叠线段的情况拓扑构建就会失败或者产生错误的区域。OCCT的BRep构建对输入几何的容差非常敏感默认容差是1e-7而实际图纸里线段端点之间的间隙经常在0.1到1个单位之间。正确的做法是在喂给OCCT之前做一轮几何清理端点吸附snap、线段合并、重复图元去重、微小间隙填充。这一步听起来简单但实际写起来要考虑的情况非常多而且不同设计院的图纸风格差异巨大很难有一套通用的清理规则。2.4 一个真实的转换链路踩坑记录去年我参与过一个项目目标是从电气图纸中自动提取回路信息。原始文件是DWG我们设计的链路是DWG → DXF用ODA转换→ 解析实体 → 构建连接关系 → 输出回路表。第一步就出了问题。ODA转换出来的DXF里原本在DWG中是一个块引用的断路器符号被展开成了7条线段和2个圆弧。我们原本指望通过块名来识别设备类型结果块名信息完全丢失了。后来改成在转换时保留块引用不展开但新的问题来了块引用只给了插入点和缩放比例块定义里的图元需要另外去BLOCKS段里找而且嵌套块的情况要递归处理。第二步的问题更隐蔽。电气图纸里的连线经常是多段线LWPOLYLINE但有些设计院习惯用直线段拼接还有些用样条曲线。这三种情况在解析时要做不同的处理而且判断两条线是否连接不能简单地比较端点坐标要考虑容差和图层。我们最后写了一个基于并查集的连接关系构建算法容差设成0.5个图纸单位才勉强把回路提取的准确率做到85%左右。这里的关键教训是CAD数据的预处理工作量往往比AI模型本身大得多。如果你在规划一个AICAD项目建议把60%以上的开发时间预算放在数据链路上而不是模型调优上。3. 几何语义识别的三层困境3.1 第一层图元级识别的准确率陷阱图元级识别是最基础的一层任务通常是把线段分类成墙、梁、柱、门窗等构件。很多团队用YOLO或者Mask R-CNN这类视觉模型把图纸渲染成图片再做目标检测。这个方法在Demo阶段效果很好因为演示用的图纸通常比较规整图元清晰干扰少。但实际工程图纸的情况完全不同。我统计过一批真实的建筑图纸单张A1图纸上的图元数量普遍在5000到20000之间图层数量在30到80之间而且存在大量的重叠图元、隐藏图层、冻结图层、打印样式覆盖等情况。视觉模型在这种密度下的漏检率和误检率会急剧上升。更麻烦的是尺度问题。一张图纸上可能同时存在1:100的平面图和1:20的节点大样视觉模型如果没有尺度感知能力很容易把节点大样里的填充图案误识别成墙体。我试过用多尺度训练来缓解这个问题但效果有限因为图纸里的尺度变化不是连续的而是离散的、由图框和视口决定的。3.2 第二层拓扑关系构建的工程约束识别出图元只是第一步真正有价值的是图元之间的拓扑关系。比如一面墙和另一面墙是否相交、一个门窗是否嵌在墙上、一根梁是否支撑在柱子上。这些关系在CAD数据里不是显式存储的需要从几何位置推断。推断拓扑关系的难点在于工程约束的复杂性。举几个实际例子两面墙在图纸上看起来是相交的但实际上一个是建筑墙一个是结构墙它们在不同的标高上并不真正相交一个门窗图块看起来嵌在墙上但它的插入点可能在墙的中心线上也可能在墙的边线上不同设计院的习惯不同梁和柱的连接关系在平面图上往往看不出来需要结合立面图或者结构说明。我目前见过的最靠谱的做法是结合图层信息和几何信息做联合推断。图层名虽然不规范但通常还是有一些规律的比如包含WALL、墙、Q墙的拼音首字母的图层大概率是墙体。把图层先验和几何位置结合起来比单纯用几何或者单纯用图层都要准。3.3 第三层规范语义的不可计算性这是最深的一层也是我认为目前AICAD落地最难跨越的一层。工程图纸不仅仅是几何图形的集合它还承载着规范语义。比如这个房间的疏散距离是否满足规范、这根梁的配筋率是否在合理范围内、这个防火分区的面积是否超标。这些语义在图纸上往往不是显式表达的而是隐含在尺寸标注、文字说明、图例符号、甚至图纸之间的引用关系里。一个AI模型要理解这些不仅需要识别图元和拓扑还需要理解规范条文、理解设计意图、理解工程惯例。我见过一些尝试用大语言模型来做规范检查的项目思路是把规范条文和图纸信息都转成文本让模型做推理。这个思路在简单场景下能跑通比如检查所有门的宽度是否大于900mm这种规则明确的检查。但一旦涉及需要多步推理或者需要工程判断的检查模型的可靠性就急剧下降。而且工程上对检查结果的要求是零漏报一个漏报可能导致严重的安全问题这是当前AI模型无法保证的。3.4 三层困境的叠加效应这三层困境不是独立的而是叠加的。图元识别的误差会传播到拓扑构建拓扑构建的误差会传播到规范检查。假设每一层的准确率是90%三层叠加后的整体准确率只有73%。而在工程场景下73%的准确率意味着大量的返工和复核实际上是不可用的。这也是为什么很多Demo看起来很美但工程走不通的核心原因Demo通常只展示单层能力而工程需要的是端到端的可靠性。一个能识别墙体的模型和一个能检查规范的模型单独看都很厉害但把它们串起来之后误差的累积效应会让整个系统变得不可用。4. 工程落地中被低估的非技术壁垒4.1 设计院的工作流惯性技术问题之外我感受最深的是工作流惯性。设计院的设计师们已经习惯了现有的工具链和操作流程任何新工具的引入都会改变他们的工作习惯而改变习惯的成本往往被技术团队严重低估。我见过一个项目AI辅助审图工具做得确实不错能自动标出图纸中的一些常见问题。但推广到设计院之后设计师的反馈是我还要花时间理解你标出来的问题不如我自己看一遍快。这个反馈听起来不合理但仔细想想是有道理的设计师看图纸是整体性的他们的大脑经过多年训练能快速扫描整张图纸并抓住关键问题。而AI工具是逐项检查的输出的是一堆离散的问题列表设计师需要额外花时间把这些离散问题重新放回整体语境中理解。4.2 责任归属的模糊地带工程图纸是要承担法律责任的。如果AI辅助生成的图纸出了问题责任算谁的设计师的AI工具开发方的还是设计院的这个问题目前没有明确的答案导致很多设计院对AI工具持保守态度。我接触过的一个设计院技术负责人说得很直白AI帮我画图可以但最后签字的是我出了问题是我负责。如果AI给我一个我无法验证的结果我宁可用传统方式自己画。这句话点出了核心矛盾AI的输出必须是可验证的否则设计师不敢用。4.3 数据安全与协作边界CAD图纸往往涉及项目的核心信息很多设计院对图纸的外传有严格的限制。这意味着基于云端的AI服务在很多场景下是不可用的必须做本地化部署。而本地化部署又带来了新的问题模型体积、推理速度、硬件成本、更新维护。我见过一个团队为了做本地化部署把模型压缩到了原来的十分之一结果准确率掉了将近20个百分点。这个取舍在Demo阶段不会遇到但工程落地时必须面对。4.4 从能用到好用的距离即使技术问题都解决了从能用到好用还有很长的路。一个AI工具要真正被设计师接受需要满足几个条件速度快不能比手动操作慢、结果稳不能时好时坏、可干预设计师能修正AI的结果、可解释设计师能理解AI为什么这么判断。这四个条件里我觉得最难的是可解释。深度学习模型本质上是个黑盒而工程设计需要的是可追溯、可审计的判断过程。这也是为什么我认为符号推理和神经网络结合可能是未来的方向纯神经网络的路在工程场景下会越来越难走。5. 几条可能走得通的技术路线5.1 规则引擎 轻量模型的分工模式我目前比较看好的路线是规则引擎负责确定性判断轻量模型负责模糊识别。具体来说图元级的分类可以用轻量模型做因为这部分容错率相对高拓扑关系的构建用规则引擎做因为这部分需要精确性和可解释性规范检查用规则引擎做因为规范条文本身就是规则。这个分工的好处是每一层的能力边界清晰出了问题容易定位。而且规则引擎的部分是可解释的设计师能理解为什么某个判断被触发。5.2 以OpenCascade为几何底座的语义层构建如果项目涉及三维几何或者需要做真正的几何运算我建议以OpenCascade为底座在上面构建语义层。具体做法是用OCCT做几何清理和拓扑构建然后在拓扑结构上附加语义标签墙、梁、柱等语义标签的来源可以是图层信息、图块信息、或者轻量模型的识别结果。这个路线的技术门槛比较高需要团队里有懂几何建模的人。但它的好处是几何操作的可靠性有保障不会出现看起来对齐了但实际上有微小偏差这种问题。5.3 人机协同的交互设计比模型精度更重要我越来越觉得在工程场景下交互设计的重要性不亚于模型精度。与其追求100%的自动识别不如设计一个高效的人机协同流程AI做初步识别和标注设计师做快速复核和修正修正的结果反馈给模型做增量学习。这个思路的关键是降低设计师的复核成本。比如AI识别出的墙体用不同颜色标注设计师只需要点击确认或者拖拽修正而不是从头画起。我见过一个团队做的交互设计非常巧妙AI识别结果以半透明图层叠加在原图上设计师可以用画笔快速涂抹修正修正操作会被记录并用于模型微调。5.4 从单点工具到平台化能力的演进路径最后说一个战略层面的观察。很多AICAD项目一开始就想做平台结果什么都做不深。我觉得更现实的路径是先做单点工具验证价值后再平台化。比如先做一个AI辅助墙体识别的工具在一个具体项目上跑通证明能节省多少时间、提高多少准确率然后再扩展到其他构件、其他专业。这个路径的好处是每一步都有明确的验证标准不会陷入什么都想做但什么都做不好的困境。而且单点工具更容易被设计院接受因为它不改变整体工作流只是在某个环节提供辅助。6. 我在实际项目中的几点体会踩了这么多坑之后有几个体会我想单独拎出来说。第一不要低估数据预处理的工作量。如果你在规划项目排期数据链路的开发时间至少要占总时间的50%而且要做好反复迭代的准备。不同来源的图纸差异巨大很难有一套通用的预处理方案。第二Demo阶段就要考虑工程约束。很多项目在Demo阶段为了追求效果会刻意选择简单的图纸、放宽容差、忽略边界情况。这些妥协在Demo阶段看起来无所谓但会在工程阶段集中爆发。我的建议是Demo阶段就用真实项目图纸哪怕效果差一点但暴露的问题都是真实的问题。第三可解释性不是锦上添花而是刚需。在工程场景下一个无法解释的判断结果等于没有结果。设计师需要知道AI为什么这么判断才能决定是否采纳。这一点在技术选型时就要考虑进去不要等到产品化阶段才发现模型是个黑盒。第四人机协同的交互设计要尽早介入。不要等到模型做完了再想怎么让设计师用而是从一开始就把设计师放在流程里观察他们的操作习惯理解他们的痛点。我见过太多技术很牛但没人愿意用的工具问题都出在交互设计上。第五规范检查是最后一块硬骨头。如果项目涉及规范检查建议放在最后做而且要做好长期迭代的准备。规范条文的复杂性和工程判断的模糊性决定了这部分很难做到完全自动化人机协同可能是更现实的方案。这个领域现在还在早期很多问题没有标准答案。我分享的这些也只是基于我个人有限的经验不一定适用于所有场景。但有一点我比较确定AICAD的落地不是单纯的算法问题而是一个系统工程问题需要同时考虑数据、算法、交互、工作流、责任归属等多个维度。只盯着模型精度大概率会走进死胡同。