1. 从能跑通到能交付AICAD落地的真实鸿沟过去一年多我参与过三个不同规模的AI辅助CAD项目从最简单的图纸信息提取到复杂的参数化建模辅助再到图纸合规性自动审查。每一次立项的时候团队都很兴奋Demo演示也很顺利但真正推到工程环境里几乎无一例外地卡住了。这个现象太普遍了以至于我现在听到我们做了个AICAD的Demo这句话第一反应不是好奇而是想问一句你的DXF解析在真实图纸上跑过吗这个问题的核心在于AICAD这个方向Demo和工程之间的鸿沟远比大多数人想象的要宽。Demo阶段你面对的可能是几张干净的、图层规范的、实体类型单一的测试图纸工程阶段你面对的是十年积累下来的、图层命名混乱的、块引用嵌套五层的、线型比例错乱的、甚至包含大量冗余实体的真实DWG文件。这两者之间的差距不是靠调几个参数就能弥合的。我写这篇东西不是要唱衰AICAD恰恰相反我认为这个方向的价值被严重低估了。但正因为有价值才更要把落地过程中的真实障碍讲清楚。这篇文章适合三类人看正在做AICAD产品但卡在工程化阶段的开发者、想引入AI能力但不知道从哪切入的CAD工程师、以及对这个交叉领域感兴趣但还没踩过坑的技术管理者。我会从数据格式、几何内核、工程约束、验证体系四个维度把为什么Demo满天飞但工程走不通这件事拆开来讲每个维度都会给出我实际踩过的坑和验证过的应对思路。2. DXF/DWG数据层的隐形陷阱为什么你的解析器在真实图纸上崩溃2.1 DXF不是一种格式而是几十种格式的集合很多人对DXF的理解停留在CAD的交换格式这个层面觉得只要找个解析库把实体读出来就行了。但实际情况是DXF格式从AutoCAD R12到现在的2018版本经历了多次重大变更不同版本之间的实体类型、组码含义、甚至坐标系的定义方式都有差异。你用ezdxf或者libdxfrw解析一个R12版本的DXF和解析一个2018版本的DXF遇到的坑完全不一样。我印象最深的一次是处理一批来自不同设计院的图纸。同样是标注这个实体有的图纸用的是DIMENSION有的用的是LEADER加MTEXT的组合还有的干脆把标注炸开成了LINE和TEXT。如果你的解析逻辑只处理DIMENSION那后两种图纸的标注信息就全丢了。更麻烦的是这些差异在Demo阶段根本暴露不出来因为Demo用的测试图纸通常来自同一个来源格式高度一致。提示在写任何解析逻辑之前先用一个脚本统计你手头所有图纸的DXF版本号、实体类型分布、图层命名模式。这个统计结果会直接决定你的解析策略。2.2 块引用与嵌套解析器的递归噩梦块引用是DXF解析里最容易出问题的地方。一个BLOCK定义里可以包含INSERTINSERT又可以引用另一个BLOCK嵌套层数理论上没有上限。我见过最夸张的一张图纸块嵌套了七层而且每一层都有不同的缩放比例和旋转角度。你要提取一个块内实体的真实坐标必须把从根节点到叶子节点的所有变换矩阵乘起来任何一层算错最终坐标就偏了。更隐蔽的问题是有些块定义在图纸里存在但实际没有被任何INSERT引用属于僵尸块。有些块被引用了但引用它的INSERT在图纸的不可见图层上。还有些块在模型空间和布局空间里的表现完全不同。这些情况在Demo图纸里几乎不会出现但在工程图纸里是常态。我的做法是在解析阶段就建立一棵完整的块引用树记录每个节点的变换矩阵和可见性状态。对于不可见的块可以选择跳过但一定要记录下来因为后续的合规审查可能需要知道这里有个东西被隐藏了。这个树的构建过程本身不复杂但要做好异常处理——我遇到过块引用形成循环的情况虽然理论上不应该发生但实际图纸里确实出现过解析器如果没有循环检测直接栈溢出。2.3 坐标系统与单位一个被严重低估的坑DXF里的坐标系统比大多数人想象的复杂。模型空间有WCS和UCS的区别布局空间有自己的坐标系视口还有独立的变换。更麻烦的是单位问题——DXF文件头里有一个$INSUNITS变量但这个变量经常是错的或者干脆是0表示无单位。你拿到一个坐标值如果不确定单位根本不知道它代表的是毫米、厘米还是英寸。我处理过一个案例图纸的$INSUNITS设置是毫米但实际绘图时用的是厘米导致所有尺寸都差了10倍。这个问题在Demo阶段完全看不出来因为Demo只关心能不能读出实体不关心读出来的数值对不对。但到了工程阶段尺寸错了整个下游的分析全部作废。应对这个问题的办法是不要信任$INSUNITS而是通过图纸中的已知参照物来推断单位。比如如果图纸里有标注标注的测量值和实际标注文字之间有一个比例关系这个比例可以用来反推单位。如果没有标注可以通过图框的尺寸来推断——标准A3图框是420x297如果你读出来的图框尺寸是4200x2970那单位就是0.1毫米。2.4 图层与线型工程语义的载体在CAD图纸里图层不仅仅是组织工具它承载了大量的工程语义。不同的图层可能代表不同的专业建筑、结构、暖通不同的线型可能代表不同的构件类型实线是可见轮廓虚线是隐藏轮廓点划线是中心线。AI模型如果只看到几何信息看不到这些语义做出来的判断往往是错的。但问题是图层命名极其不规范。我见过用0、图层1、图层2这种默认命名的也见过用拼音首字母缩写的还见过用设计院内部编码的。同一个含义在不同图纸里可能对应完全不同的图层名。更麻烦的是有些图纸把所有实体都放在一个图层上靠颜色来区分——这在一些老图纸里特别常见。我的经验是不要试图建立一个通用的图层名映射表那个东西永远不够用。更务实的做法是把图层名、颜色、线型、线宽这些属性全部作为特征输入给模型让模型自己去学习它们和工程语义之间的关联。同时保留一个人工映射的接口对于重点图纸可以手动指定图层含义提高准确率。3. 几何内核的选型困局OpenCASCADE、FreeCAD与自研的取舍3.1 为什么几何内核的选择决定了项目的天花板AICAD项目里几何内核的选择是一个战略级决策但很多团队在立项时并没有意识到这一点。他们往往先选一个AI框架然后随便找个库来读CAD文件等到发现几何操作做不了的时候已经积重难返了。几何内核决定了你能做什么、不能做什么。如果你只需要读取图纸信息、做分类或检测那用ezdxf或者libdxfrw就够了不需要完整的几何内核。但如果你需要做布尔运算、倒角、抽壳、参数化建模那就必须上OpenCASCADE或者类似的BRep内核。如果你还需要做网格划分、有限元分析那可能还要考虑Gmsh或者Netgen。我见过一个团队用Python的dxfgrabber读图纸然后用numpy做几何计算一开始做得很顺但后来需要做实体之间的干涉检查发现dxfgrabber只能读线框读不了实体整个方案推倒重来。这个教训是在项目初期就要想清楚最终的几何操作需求然后倒推内核选型。3.2 OpenCASCADE的工程化门槛OpenCASCADEOCCT是目前开源领域最完整的BRep几何内核功能强大但工程化门槛很高。首先是编译OCCT的依赖很多在Windows上编译一套完整的OCCT顺利的话半天不顺利的话两天。其次是API的复杂度OCCT的API设计是C风格的大量使用句柄Handle和模板Python绑定pythonocc虽然能用但性能和稳定性都不如原生C。更关键的是OCCT的容差tolerance机制非常复杂。BRep实体的每个顶点、边、面都有自己的容差这些容差在布尔运算、缝合、修复过程中会发生变化。如果你的AI模型生成的几何体容差设置不当后续的布尔运算可能直接失败而且失败信息往往很模糊很难定位问题。我的建议是如果你的团队没有C几何开发经验不要直接上OCCT。可以考虑先用FreeCAD的Python API做原型FreeCAD底层也是OCCT但封装了一层更友好的接口。等原型验证通过再把性能关键的部分用C重写。3.3 FreeCAD作为AICAD中间层的可能性FreeCAD在这个领域的位置比较特殊。它本身是一个完整的CAD应用但它的Python API可以让你在不启动GUI的情况下操作几何体。这意味着你可以把FreeCAD当作一个几何计算服务来用——AI模型生成参数FreeCAD负责建模然后再把结果导出。我实际测试过这条路线用FreeCAD的Part模块做参数化建模用Draft模块做2D操作用Mesh模块做网格导出。整体是可行的但有几个坑要注意。第一FreeCAD的Python API在不同版本之间变化较大0.19、0.20、0.21的API有差异生产环境要锁定版本。第二FreeCAD的文档对象模型和OCCT的BRep模型之间有一层映射有时候操作FreeCAD对象不会立即反映到OCCT层面需要手动触发 recompute。第三FreeCAD的启动时间较长如果做成服务要考虑常驻进程或者连接池。注意FreeCAD没有内置齿轮工具这件事经常被吐槽但这其实反映了FreeCAD的定位——它是一个通用的CAD平台不是机械设计专用工具。如果你需要齿轮、轴承这类标准件要么用插件要么自己用Python脚本生成。3.4 自研轻量级几何引擎的边界有些团队会考虑自研几何引擎觉得OCCT太重自己只需要一个子集。这个想法在某些场景下是合理的比如你只需要做2D轮廓的偏移和布尔运算那用Clipper或者Boost.Geometry就够了不需要上完整的BRep内核。但自研的边界要划清楚。2D的布尔运算、偏移、倒角这些用成熟库可以做。3D的BRep操作特别是涉及曲面求交、容差处理的自研的成本极高而且很难保证鲁棒性。我见过一个团队自研了3D布尔运算在简单情况下没问题但遇到两个曲面几乎相切的情况算法直接崩溃。这种边界情况在工程图纸里出现的概率不低一旦出现就是致命问题。我的判断是2D可以自研或使用轻量库3D必须用成熟内核。如果你的项目需要3D操作老老实实上OCCT或者商业内核不要在自研上浪费时间和人力。4. 工程约束下的AI模型精度、速度与可解释性的三角困境4.1 工程精度要求与AI概率输出的根本矛盾AI模型输出的是概率分布工程要求的是确定性结果。这个矛盾在AICAD领域特别突出。比如一个图纸元素分类模型输出这个实体有87%的概率是墙体这在Demo里看起来没问题但在工程里87%的概率意味着13%的错误率对于一张有几千个实体的图纸就是几百个错误完全不可接受。解决这个矛盾有几种思路。一种是提高模型精度把准确率推到99%以上但剩下的1%仍然可能造成严重问题。另一种是引入人工复核环节模型只做初筛最终结果由人确认。还有一种是改变输出形式不让模型直接输出分类结果而是输出多个候选由后续的规则引擎或几何约束来筛选。我倾向于第三种思路。比如模型识别出三个可能的墙体候选然后几何引擎检查这三个候选是否满足墙体的几何约束厚度一致、端点连接、与楼板相交等最终确定哪个是真正的墙体。这样AI负责提供候选几何约束负责做最终判断两者互补。4.2 推理速度从能跑到能用的距离Demo阶段推理速度通常不是问题因为只处理几张图纸等几秒也无所谓。但工程阶段可能需要批量处理几千张图纸每张图纸的推理时间必须控制在可接受的范围内。我做过一个测试用一个大模型做图纸元素分类单张图纸的推理时间是8秒。对于1000张图纸就是8000秒超过2小时。如果加上前后处理的时间可能要4小时以上。这个速度对于日常设计工作来说太慢了设计师不可能等4小时才拿到结果。优化推理速度的手段有几个。模型量化是最直接的把FP32量化到INT8速度可以提升2-4倍精度损失通常在1%以内。模型剪枝和蒸馏也可以考虑但需要重新训练。另外批处理batching可以显著提升GPU利用率但要注意显存限制。还有一个容易被忽略的点是前处理和后处理的时间往往比推理本身还长特别是DXF解析和几何特征提取这些环节的优化同样重要。4.3 可解释性工程师为什么不信任黑盒工程师对AI模型的不信任很大程度上源于不可解释性。如果一个模型说这个图纸有问题但说不出具体哪里有问题、为什么有问题工程师是不会采纳的。在工程领域每一个判断都需要有依据这个依据必须是可追溯、可验证的。我在项目里尝试过几种提升可解释性的方法。一种是注意力可视化把模型关注的区域高亮出来让工程师看到模型在看哪里。另一种是规则提取从模型的行为中反推出近似规则用规则的形式呈现给工程师。还有一种是反事实解释告诉工程师如果这个参数改成X结果就会变成Y帮助工程师理解模型的决策边界。这些方法各有优劣注意力可视化直观但可能误导规则提取可解释但可能失真反事实解释精确但计算成本高。实际项目中我通常组合使用根据场景选择最合适的方式。4.4 数据标注工程领域的隐性成本中心AICAD项目里数据标注的成本经常被低估。CAD图纸的标注和普通图像标注完全不同需要标注者有工程背景能理解图纸的语义。一个合格的标注员培养周期至少三个月。而且CAD图纸的标注复杂度远高于图像——一张图纸可能有几千个实体每个实体都需要分类标注一张图纸的时间可能是几小时。更麻烦的是标注的一致性很难保证。不同的标注员对同一个实体的分类可能不同甚至同一个标注员在不同时间对同一个实体的分类也可能不同。这个问题在Demo阶段不明显因为Demo用的标注数据通常由同一个人完成一致性有保证。但到了工程阶段标注量大了必须多人协作一致性问题就暴露出来了。我的做法是建立一套详细的标注规范对每个类别给出明确的定义和边界案例。同时引入交叉验证机制每个标注结果由至少两个人独立完成不一致的地方由第三人仲裁。这套机制会增加成本但能显著提升标注质量。5. 从Demo到工程验证体系与迭代策略的缺失5.1 为什么你的Demo指标在工程环境里失效Demo阶段的评估指标通常是准确率、召回率、F1值这些统计指标。这些指标在Demo环境里看起来不错但到了工程环境里往往和实际表现严重脱节。原因有几个。第一Demo的测试集和工程的实际数据分布不同。Demo测试集通常是精心挑选的、干净的、有代表性的图纸而工程数据是杂乱的、有噪声的、长尾分布的。一个在Demo测试集上达到95%准确率的模型在工程数据上可能只有70%。第二统计指标不反映错误的严重程度。在工程里一个关键尺寸的错误和一个无关紧要的文字标注错误严重程度完全不同。但统计指标把它们同等对待。一个模型可能准确率很高但错误都集中在关键尺寸上实际不可用。第三工程环境有Demo环境没有的约束。比如模型必须在规定时间内完成推理必须能处理异常输入必须能给出可解释的结果。这些约束在Demo阶段通常被忽略但到了工程阶段就是硬性要求。5.2 建立分层验证体系从单元测试到端到端验收我的经验是AICAD项目必须建立分层验证体系不能只靠一个端到端的准确率指标。这个体系至少应该包含四层。第一层是单元测试针对每个独立的模块比如DXF解析、几何特征提取、模型推理、结果后处理分别设计测试用例。这些测试用例应该覆盖正常情况、边界情况和异常情况。第二层是集成测试把各个模块串起来测试模块之间的接口和数据流。这一层最容易发现的问题是模块之间的数据格式不匹配、坐标系不一致、单位不统一。第三层是场景测试针对典型的工程场景设计端到端的测试用例。比如一张包含嵌套块引用的建筑平面图模型能否正确识别所有墙体。这一层的测试用例应该来自真实项目而不是人工构造。第四层是验收测试由最终用户参与在实际工作流程中验证系统的可用性。这一层关注的不只是技术指标还有用户体验、工作效率、错误处理等方面。5.3 迭代策略小步快跑还是大步慢走AICAD项目的迭代策略和纯软件项目或纯AI项目都不一样。纯软件项目可以小步快跑快速迭代纯AI项目可以大步慢走一次训练很久。AICAD项目需要兼顾两者既要快速响应工程需求的变化又要保证模型的稳定性和可靠性。我的做法是把项目分成两条线。一条是工程线负责数据管道、几何处理、系统集成这些工程化的工作这条线可以小步快跑每周都有产出。另一条是模型线负责模型训练、调优、评估这条线需要更长的周期通常以月为单位。两条线通过明确的接口对接工程线的进展不依赖模型线的突破模型线的更新可以平滑地接入工程线。这种双线策略的好处是即使模型线暂时没有突破工程线也可以持续交付价值。比如先把数据管道和几何处理做好即使AI模型还没上线工程师也可以用这些工具做半自动化的处理效率已经比纯手工高很多。5.4 工程化落地的组织保障技术之外组织保障同样重要。AICAD项目通常需要三类人懂AI的、懂CAD的、懂工程的。这三类人的思维方式和关注点差异很大如果组织不好很容易各说各话项目推进不下去。我的经验是项目初期就要建立一个跨职能的核心团队包括AI工程师、CAD工程师、领域专家和产品经理。这个团队要定期同步确保大家对目标、进度、问题有共同的理解。特别是领域专家他们的作用不可替代——他们能判断模型输出的结果在工程上是否合理能提供标注规范能参与验收测试。另外要建立和最终用户的反馈闭环。AICAD系统的最终用户是设计师和工程师他们的使用体验和反馈是改进系统的重要依据。我见过一些项目技术指标很好但用户不用原因是系统的操作流程和他们的工作习惯不匹配。这种问题只有通过持续的用户反馈才能发现和解决。6. 一些实际项目中的经验碎片上面讲的都是框架性的东西最后分享几个实际项目中积累的具体经验可能比较零散但都是踩过坑之后总结出来的。关于DXF解析我的建议是永远不要假设输入是规范的。我现在的做法是解析之前先跑一个体检脚本检查图纸的版本、实体类型分布、图层数量、块引用深度、坐标范围、单位设置等。这个体检报告不仅能帮你发现潜在问题还能作为后续处理的依据。比如如果发现图纸的单位设置可疑就触发单位推断逻辑。关于几何内核如果你的项目需要处理大量图纸建议把几何计算做成独立的服务而不是嵌入在主流程里。这样做的原因是几何计算往往是最耗时的环节独立成服务后可以单独扩展也可以做缓存。我实际项目中几何计算服务的缓存命中率能达到60%以上因为很多图纸的几何特征在之前的处理中已经计算过了。关于AI模型不要追求一个大而全的模型而是针对具体任务训练多个小模型。比如一个模型专门做图层分类一个模型专门做实体类型识别一个模型专门做尺寸提取。这些小模型可以独立优化也可以组合使用。而且当某个任务的需求变化时只需要重新训练对应的小模型不影响其他部分。关于验证一定要建立真实图纸的回归测试集。这个测试集应该包含各种疑难杂症——不同版本、不同来源、不同规范程度的图纸。每次模型或系统更新都要在这个测试集上跑一遍确保没有回归。这个测试集的维护本身就是一个持续的工作需要定期补充新的案例。关于团队协作我强烈建议AI工程师和CAD工程师结对工作。AI工程师往往不了解CAD的细节CAD工程师往往不了解AI的能力边界。结对工作可以让双方快速建立共同语言减少沟通成本。我实际项目中结对工作的团队问题解决速度比分开工作的团队快一倍以上。这个领域还在快速演进新的模型、新的工具、新的方法不断出现。但底层的工程逻辑是不变的——数据要干净几何要准确验证要严格迭代要持续。把这些基础打牢AICAD的落地才有可能从Demo走向工程。