国产CAD平台替换下，AI图元识别适配与重构实战指南-平芜编程栈

1. 国产CAD生态下的AI图元识别，到底在解决什么问题

2026年这波CAD国产化替换，身边不少做设计工具、做工程数字化、做审图系统的朋友都在聊同一个话题：图纸还是那些图纸，但底层CAD平台换了，原来跑得好好的图元识别模块，突然就不灵了。有的识别率从95%掉到60%，有的直接报错退出，还有的虽然能跑，但提取出来的图层、块、标注信息全乱了套。

这个问题的本质，是AI图元识别和CAD底层数据模型之间的强耦合关系被打破了。过去很多识别方案是建立在特定CAD平台的API之上的，比如直接调用某平台的实体遍历接口、块表访问接口、扩展数据读取接口。一旦换到国产CAD平台，这些接口的名字、参数、返回结构、甚至坐标系定义都可能不一样。你如果只是把DLL换个名字重新编译，大概率是跑不通的。

所以这篇文章想聊的，不是“AI图元识别有多牛”，而是在国产CAD平台替换的大背景下，怎么用一套相对通用的思路，把图元识别这件事重新做稳。适合谁看？如果你正在做CAD二次开发、图纸数字化、智能审图、BIM翻模、工程量提取这类工作，尤其是团队正在从国外CAD平台往国产平台迁移，那这篇内容应该能帮你少踩几个坑。

我自己的背景是做了七八年CAD相关的算法和工具开发，最近两年主要精力就花在国产CAD平台的适配和AI识别模块的重构上。下面这些内容，一部分是实际项目里验证过的方案，一部分是踩坑之后总结出来的经验，还有一部分是基于行业常见实践做的合理推演。你不需要全部照搬，但思路可以参考。

2. 先搞清楚：国产CAD平台和图元识别的核心矛盾在哪

2.1 数据模型差异：不是换个API那么简单

很多人一开始会觉得，CAD国产化替换嘛，不就是把AutoCAD换成某国产CAD，然后把代码里的AcDbEntity换成对应的国产类名就行了？实际操作下来，这个想法太天真了。

国产CAD平台虽然大多兼容DWG格式，但在内部数据组织方式上有不少差异。举个例子，国外某主流CAD的块表（Block Table）和国产某CAD的块表，在嵌套块的处理上就不完全一样。前者可能把嵌套块的变换矩阵直接乘到最底层实体上，后者可能保留层级结构让你自己去递归。这就导致同一个图元，在不同平台下提取出来的坐标、旋转角、缩放比例可能不一致。

再比如**扩展数据（XData）和扩展记录（XRecord）**的存储方式。很多AI识别模块依赖这些扩展信息来判断图元的语义，比如“这个圆是一个螺栓孔”还是“一个装饰圆”。国产CAD对扩展数据的支持程度参差不齐，有的只读不写，有的写入后在其他平台打不开，有的干脆不支持某些数据类型。

还有一个容易被忽略的点：图层和线型的映射关系。国外CAD的线型定义文件格式和国产CAD可能有细微差别，导致同一个线型在不同平台下显示效果不同，进而影响基于线型特征的识别逻辑。

注意：在迁移之前，一定要先做一轮“数据模型对齐测试”。拿同一张典型图纸，分别在原平台和目标国产平台上遍历所有实体，导出实体类型、坐标、图层、颜色、线型、扩展数据，然后逐项对比。这个测试能帮你提前发现80%的兼容性问题。

2.2 AI识别模块的两种架构，选错了后面全是坑

目前市面上做CAD图元识别的AI模块，架构上大致分两类：

第一类：基于CAD平台API的深度耦合方案。直接在CAD进程内运行，通过平台提供的API遍历实体、读取属性、甚至调用平台自身的几何计算库。优点是性能好、精度高、能拿到最原始的数据。缺点是换平台就得重写，而且国产CAD的API文档和社区支持往往不如国外平台完善。

第二类：基于文件解析的松耦合方案。不依赖CAD平台运行，直接解析DWG/DXF文件格式，自己构建图元数据结构。优点是平台无关，一次开发到处运行。缺点是实现复杂度高，DWG格式的私有部分很难完全解析，而且性能通常不如进程内方案。

我的建议是：如果你的业务场景对实时性要求极高，比如交互式设计工具，那优先考虑第一类方案，但要把平台相关的代码隔离成独立层，方便后续替换。如果是对批量图纸做离线处理，比如审图、算量、数字化归档，那第二类方案更稳妥，虽然前期投入大，但长期看迁移成本最低。

实际项目中，我见过太多团队把平台相关代码散落在各个模块里，结果换平台时发现要改几百个文件。正确的做法是定义一个图元抽象层，上层AI识别逻辑只依赖这个抽象层，底层具体用哪个CAD平台的API来实现，通过适配器模式隔离。这样换平台时，只需要重写适配器层，上层逻辑基本不动。

2.3 国产CAD平台的API成熟度现状

客观地说，2026年的国产CAD平台在API能力上已经比前几年好很多了。主流的几家国产CAD都提供了比较完整的二次开发接口，包括实体遍历、属性读写、几何运算、选择集操作等。但在一些细节上还是有差距：

文档完整性：部分国产CAD的API文档更新不及时，有些接口没有示例代码，需要自己摸索。
异常处理：国产CAD的API在异常情况下的行为定义不够清晰，比如传入非法参数时是抛异常还是返回错误码，不同版本可能不一致。
性能特性：大规模图纸下的遍历性能、内存占用，国产CAD和国外CAD可能有数量级差异，需要针对性优化。
扩展机制：自定义实体、自定义对象的支持程度不同，影响AI识别模块的扩展能力。

这些差异意味着，你不能假设国产CAD的API行为和国外CAD完全一致。每一个关键接口，都要写单元测试验证其行为，尤其是在边界条件下。

3. AI图元识别的核心技术点拆解

3.1 图元特征提取：从几何到语义的桥梁

AI图元识别的第一步，是把CAD图元转换成AI模型能理解的特征向量。这个过程叫特征提取，也是整个识别流程中最影响最终效果的一环。

对于基本的几何图元，比如直线、圆、圆弧、多段线，特征提取相对直接：

直线：起点坐标、终点坐标、长度、角度、图层、颜色、线型。
圆：圆心坐标、半径、图层、颜色、线型。
圆弧：圆心、半径、起始角、终止角、图层、颜色、线型。
多段线：顶点序列、是否闭合、全局宽度、图层、颜色、线型。

但实际图纸中，图元往往不是孤立的。一个螺栓孔可能由圆、中心线、标注文字共同组成；一个门窗可能由多条直线和圆弧组合而成。所以上下文特征同样重要：

空间邻接关系：图元之间的距离、包含关系、相交关系。
图层共现关系：哪些图层的图元经常一起出现。
拓扑关系：图元之间的连接、平行、垂直、同心等关系。
文字关联：图元附近的文字标注，往往包含关键语义信息。

我在实际项目中用过的一个特征工程方案是这样的：对每个图元，提取三类特征——自身几何特征（约20维）、局部上下文特征（约50维，包括最近邻图元的类型、距离、角度关系）、全局统计特征（约10维，包括所在图层的图元密度、该图元在整张图纸中的稀有度等）。这三类特征拼接起来，形成一个80维左右的向量，输入到分类模型中。

实操心得：特征维度不是越高越好。我试过把特征堆到300多维，结果模型训练时间翻倍，精度反而下降了。后来做了一轮特征重要性分析，砍掉了大量冗余特征，最终稳定在80维左右，效果最好。建议每增加一批特征，都做一次消融实验，确认它真的有用。

3.2 模型选型：不是越深越好，合适最重要

图元识别本质上是一个分类问题：给定一个图元及其上下文，判断它属于哪一类（比如“螺栓孔”“门窗”“轴线”“标注”等）。也有场景是检测问题：在图纸中找出所有符合某种模式的图元组合。

模型选型上，我见过几种常见的做法：

方案一：传统机器学习 + 手工特征。用SVM、随机森林、XGBoost等模型，输入是手工提取的特征向量。优点是训练快、可解释性强、对小样本友好。缺点是特征工程工作量大，对复杂模式的表达能力有限。

方案二：深度学习 + 图神经网络。把图纸构建成图结构，图元是节点，图元之间的关系是边，用GNN做节点分类或图分类。优点是能自动学习图元之间的复杂关系，对拓扑结构敏感的场景效果好。缺点是需要大量标注数据，训练和推理资源消耗大。

方案三：深度学习 + 序列模型。把图纸按某种顺序（比如空间扫描顺序）展开成序列，用Transformer或LSTM做序列标注。优点是能捕捉长距离依赖，适合有先后逻辑关系的图纸。缺点是对空间关系的建模不如GNN直观。

方案四：混合方案。用传统方法做初筛，再用深度学习做精细分类。比如先用规则引擎把明显是标注文字的图元过滤掉，剩下的再用模型分类。优点是兼顾效率和精度，缺点是系统复杂度高。

我的实际选择是：中小规模场景（单张图纸图元数<10万）用XGBoost + 手工特征，大规模场景（图元数>10万或需要跨图纸学习）用GNN。原因很简单：XGBoost的训练和推理速度比GNN快一个数量级，而且在特征工程做到位的情况下，精度差距并不大。GNN的优势在于能自动学习关系，但前提是你有足够的标注数据，否则很容易过拟合。

3.3 训练数据从哪来：标注是个体力活，但有技巧

做AI图元识别，最头疼的往往不是模型，而是标注数据。CAD图纸的标注需要懂专业知识，不是随便找个人就能标。而且图纸涉及行业机密，很多设计院不愿意把图纸拿出来。

我总结了几种获取训练数据的途径：

途径一：历史项目积累。如果团队之前做过类似项目，可能已经有一些标注好的图纸。这是最宝贵的资源，优先利用。

途径二：规则生成 + 人工校验。先用规则引擎自动标注一批数据，比如“所有在‘螺栓孔’图层上的圆都标为螺栓孔”，然后人工抽查校验。这样能快速扩大数据集，但要注意规则本身的偏差会传递到模型里。

途径三：数据增强。对已有图纸做旋转、镜像、缩放、平移等变换，生成更多样本。CAD图元对这些变换是等变的，所以增强后的样本标签不变。这个方法能有效扩充数据量，尤其是对稀有类别。

途径四：主动学习。先训练一个初始模型，然后用它去预测未标注数据，挑出模型最不确定的样本让人工标注。这样能用最少的标注量获得最大的精度提升。

途径五：合成数据。用程序生成模拟图纸，比如随机生成一批螺栓孔、门窗、轴线，然后组合成完整图纸。优点是数据量无限，标签准确。缺点是合成数据和真实图纸有分布差异，需要做域适应。

注意：标注数据的质量比数量重要得多。我见过一个项目，标注了10万张图纸，但标注规范不统一，不同人标出来的结果不一致，导致模型怎么训都训不好。后来重新制定了标注规范，只标了2万张，效果反而更好。建议在标注之前，先花时间制定详细的标注手册，明确每个类别的定义、边界情况怎么处理。

4. 国产CAD平台下的实操适配方案

4.1 环境准备与基础配置

假设你现在拿到了一套国产CAD平台的开发包，准备开始做图元识别模块的适配。下面是我建议的起步流程：

第一步：确认开发环境和版本。国产CAD平台通常提供C++、C#、Python等多种语言的SDK。选择你团队最熟悉的语言，但要注意不同语言的SDK在功能覆盖上可能有差异。比如某些平台C++ SDK支持自定义实体，但Python SDK不支持。确认SDK版本和CAD平台版本的对应关系，不要混用。

第二步：搭建最小可运行Demo。不要一上来就搞大工程。先写一个最简单的程序，能启动CAD、打开一张图纸、遍历所有实体、打印实体类型和数量。这个Demo跑通了，说明基础环境没问题。

第三步：建立图元抽象层。定义一套与平台无关的图元数据结构，比如：

class CADEntity: def __init__(self): self.entity_type = None # 实体类型：line, circle, arc, polyline等 self.layer = None # 图层名 self.color = None # 颜色 self.linetype = None # 线型 self.geometry = {} # 几何数据，不同实体类型结构不同 self.attributes = {} # 扩展属性 self.handle = None # 实体句柄

然后为每个国产CAD平台写一个适配器，把平台特有的实体对象转换成这个抽象结构。上层AI识别逻辑只操作CADEntity，不直接接触平台API。

第四步：编写数据模型对齐测试。拿同一张图纸，在原平台和目标平台上分别运行遍历程序，导出所有实体的抽象结构，然后逐字段对比。重点关注：坐标数值是否有精度差异、图层名大小写是否一致、扩展数据是否完整、块参照的变换矩阵是否相同。

4.2 图元遍历的性能优化

国产CAD平台在大规模图纸下的遍历性能，是我踩过的最大的坑之一。一张10万图元的图纸，在某些国产CAD平台上遍历一遍可能要几十秒，而国外CAD可能只要几秒。如果AI识别模块需要多次遍历，性能问题会非常突出。

我总结了几条优化经验：

优化一：批量读取代替逐个读取。不要在一个循环里反复调用getLayer()、getColor()这种单属性接口。很多国产CAD平台支持批量获取实体属性，比如一次性获取所有实体的图层名数组。用批量接口能减少跨语言调用开销。

优化二：空间索引加速。如果识别逻辑需要查询“某个图元附近的图元”，不要每次都全图遍历。在第一次遍历时构建R-tree或网格索引，后续查询直接走索引。我实测下来，构建索引的时间通常能在后续查询中赚回来。

优化三：多线程并行。如果国产CAD平台的API支持多线程访问（有些平台不支持，需要确认），可以把图纸按空间区域切分，多个线程并行处理。但要注意线程安全问题，尤其是涉及平台内部状态的操作。

优化四：缓存中间结果。图元识别往往需要多轮处理，比如先提取特征，再分类，再后处理。每一轮的输出都缓存下来，避免重复计算。

优化五：懒加载。不是所有图元都需要完整读取。比如如果识别逻辑只关心圆和直线，那遍历时可以先判断实体类型，非目标类型直接跳过，不读取详细属性。

下面是一个批量遍历的示例代码结构：

def batch_extract_entities(cad_doc): entities = [] # 批量获取所有实体句柄 handles = cad_doc.get_all_entity_handles() # 分批处理，每批1000个 batch_size = 1000 for i in range(0, len(handles), batch_size): batch = handles[i:i+batch_size] # 批量获取实体类型 types = cad_doc.get_entity_types(batch) # 批量获取图层 layers = cad_doc.get_entity_layers(batch) # 批量获取几何数据 geometries = cad_doc.get_entity_geometries(batch) for j, handle in enumerate(batch): entity = CADEntity() entity.handle = handle entity.entity_type = types[j] entity.layer = layers[j] entity.geometry = geometries[j] entities.append(entity) return entities

实操心得：批量接口的批次大小需要调优。太小了调用次数多，太大了内存占用高。我一般从1000开始试，根据实际内存和速度调整。另外要注意，有些国产CAD平台的批量接口返回顺序和输入顺序不一定一致，需要自己根据句柄做映射。

4.3 扩展数据与自定义属性的兼容处理

很多AI识别模块依赖CAD图元上的扩展数据来判断语义。比如设计院可能在图元上附加了“构件编号”“材料类型”“施工阶段”等信息。国产CAD平台对扩展数据的支持程度不同，需要做兼容处理。

情况一：目标平台完整支持扩展数据。那直接读写即可，但要注意数据类型映射。比如国外CAD的扩展数据支持字符串、实数、整数、句柄等类型，国产CAD可能只支持部分类型。需要做类型转换。

情况二：目标平台不支持扩展数据。那就要找替代方案。常见的有：

用图层名编码信息，比如“螺栓孔_M20”表示M20螺栓孔。
用图元颜色或线型编码信息。
用图元附近的文字标注传递信息。
用外部数据库关联，图元句柄作为主键。

情况三：目标平台支持但格式不同。需要写转换层，在读取时把国产CAD的扩展数据格式转换成AI模块期望的格式，在写入时反向转换。

我实际项目中遇到过一个典型问题：原平台用扩展数据存储了图元的“专业类型”（建筑、结构、机电），国产CAD平台虽然支持扩展数据，但只支持字符串类型，而原平台用的是整数枚举。解决方案是在适配层做映射：读取时把字符串转成整数枚举，写入时把整数枚举转成字符串。这个映射表需要维护好，新增专业类型时要同步更新。

4.4 坐标系与单位制的坑

CAD图纸的坐标系和单位制，是另一个容易出问题的地方。国外CAD通常使用世界坐标系（WCS）和用户坐标系（UCS），国产CAD可能对UCS的支持不完整，或者UCS的变换逻辑有差异。

我遇到过的情况包括：

同一图元在原平台下提取的坐标是(100, 200)，在国产平台下变成(100.0001, 200.0002)，精度差异导致后续空间关系判断出错。
原平台支持UCS，图元坐标是UCS下的，国产平台只返回WCS坐标，需要自己转换。
单位制不一致，原平台默认毫米，国产平台默认米，导致所有尺寸差1000倍。

解决方案：

在适配层统一坐标系，所有图元坐标都转换到WCS下。
在适配层统一单位制，所有尺寸都转换到毫米。
对坐标数值做精度处理，比如保留小数点后4位，避免浮点误差影响空间关系判断。
在数据模型对齐测试中，专门加一项“坐标一致性检查”，确保同一图元在不同平台下的坐标差异在可接受范围内。

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

5.1 识别率突然下降，怎么定位问题

这是迁移过程中最常见的问题。原来识别率95%，换到国产CAD后掉到60%。怎么排查？

第一步：确认是数据问题还是模型问题。拿同一张图纸，在原平台和国产平台上分别导出图元数据，对比差异。如果数据本身差异很大，那是适配层的问题。如果数据基本一致但识别结果不同，那是模型推理环境的问题。

第二步：逐层排查。从输入到输出，逐层检查：

图元遍历是否完整？有没有漏掉某些类型的图元？
特征提取是否正确？坐标、角度、长度等数值是否和原平台一致？
模型输入是否正常？特征向量的分布是否和训练时一致？
模型输出是否合理？分类概率分布是否正常？

第三步：可视化对比。把识别结果在原平台和国产平台上分别可视化出来，用不同颜色标注不同类别，肉眼对比差异。往往能快速定位到是哪类图元识别错了。

第四步：小样本复现。找一张最小的、能复现问题的图纸，逐步简化，直到找到最小复现条件。这个过程可能很耗时，但能帮你精准定位问题根源。

下面是一个常见问题速查表：

问题现象	可能原因	排查方法	解决方案
识别率整体下降	特征分布偏移	对比特征向量统计量	重新训练或做域适应
某类图元全部识别错	该类图元的特征提取有误	检查该类图元的几何数据	修复适配层
识别结果不稳定	遍历顺序不一致	检查遍历接口的返回顺序	排序后再处理
性能急剧下降	批量接口未使用	检查API调用次数	改用批量接口
扩展数据丢失	平台不支持该数据类型	检查扩展数据读写接口	改用替代编码方案
坐标偏差大	坐标系或单位制不一致	对比同一图元坐标	统一坐标系和单位

5.2 国产CAD平台API的“坑”清单

以下是我在实际项目中遇到的国产CAD平台API的典型问题，供你参考：

坑一：接口行为不一致。同一个接口，在CAD界面打开图纸时调用和后台无界面调用时，行为可能不同。比如某些平台在无界面模式下不支持某些选择集操作。

坑二：异常处理不完善。传入非法参数时，有的接口直接崩溃，有的返回空值，有的抛异常。需要自己做防御性编程，对每个接口调用都做参数校验和异常捕获。

坑三：内存管理问题。某些国产CAD平台的API返回的对象需要手动释放，否则会内存泄漏。长时间运行的批量处理程序尤其要注意。

坑四：版本兼容性。国产CAD平台更新频繁，不同版本之间的API可能有细微差异。建议在代码中做版本判断，或者锁定一个稳定版本。

坑五：文档与实际不符。文档说支持的功能，实际可能不支持；文档没说的功能，实际可能支持。以实际测试为准。

注意：在项目初期，建议花一周时间专门做API摸底测试。把AI识别模块需要用到的所有API接口列出来，逐个写测试用例，记录实际行为。这份测试报告会成为后续开发的宝贵参考。

5.3 模型部署与推理优化

模型训练好了，怎么在国产CAD环境下高效推理，也是个大问题。

优化一：模型量化。如果用的是深度学习模型，可以做INT8量化，推理速度能提升2-4倍，精度损失通常不到1%。对于XGBoost模型，可以限制树的最大深度和叶子节点数。

优化二：模型剪枝。去掉模型中不重要的特征和分支。我试过把一个200维特征的XGBoost模型剪到80维，推理速度提升一倍多，精度只掉了0.3%。

优化三：批推理。不要一个图元一个图元地推理，攒一批（比如1024个）一起推理。GPU上批推理的吞吐量比单条推理高一个数量级。

优化四：缓存推理结果。如果同一张图纸会被多次处理，把推理结果缓存起来。可以用图元的几何哈希作为缓存键。

优化五：异步推理。如果识别模块是交互式的，把推理放在后台线程，不阻塞UI。用户操作时先显示粗略结果，推理完成后再更新。

5.4 跨平台一致性保障

如果你需要同时支持多个国产CAD平台，一致性保障就很重要。我的做法是：

做法一：统一的测试集。准备一批覆盖各种图元类型和场景的测试图纸，在每个平台上跑同样的测试用例，对比结果。

做法二：自动化回归测试。每次修改适配层代码，都自动跑一遍回归测试，确保没有破坏已有功能。

做法三：差异容忍度定义。不是所有差异都需要修复。比如坐标精度差异在0.001mm以内，可以接受。识别率差异在1%以内，可以接受。定义好容忍度，避免过度优化。

做法四：平台特性开关。如果某个平台有特殊行为，用配置开关控制，而不是写死在代码里。这样新增平台时只需要加配置，不需要改代码。

6. 一个完整的适配案例拆解

6.1 项目背景与目标

假设有一个智能审图系统，原本基于国外某CAD平台开发，功能是自动识别图纸中的“消防栓”“灭火器”“安全出口”等消防设施图元，并检查其布置是否符合规范。现在需要迁移到国产CAD平台。

系统原来的识别流程是：

遍历图纸所有图元。
对每个图元提取几何特征和上下文特征。
用XGBoost模型分类，输出图元类别。
对分类结果做后处理，合并同一设施的多个图元。
根据规范检查设施布置。

6.2 适配层设计与实现

适配层的核心是定义一个FireEntityExtractor接口，然后为每个CAD平台实现一个具体类。

class FireEntityExtractor: def extract_all(self, drawing_path): """提取图纸中所有图元，返回CADEntity列表""" raise NotImplementedError def get_nearby_entities(self, entity, radius): """获取指定图元附近指定半径内的图元""" raise NotImplementedError class DomesticCADExtractor(FireEntityExtractor): def __init__(self, cad_app): self.cad_app = cad_app self.spatial_index = None def extract_all(self, drawing_path): doc = self.cad_app.open(drawing_path) entities = batch_extract_entities(doc) self.spatial_index = build_rtree(entities) return entities def get_nearby_entities(self, entity, radius): if self.spatial_index is None: raise RuntimeError("请先调用extract_all") return self.spatial_index.query(entity.geometry['center'], radius)

6.3 特征提取的适配

原平台的特征提取代码直接调用了平台API获取图元属性。迁移时，把这些调用替换成从CADEntity抽象结构读取。

def extract_features(entity, nearby_entities): features = [] # 几何特征 if entity.entity_type == 'circle': features.append(entity.geometry['radius']) features.append(entity.geometry['center'][0]) features.append(entity.geometry['center'][1]) elif entity.entity_type == 'line': features.append(entity.geometry['length']) features.append(entity.geometry['angle']) # 图层特征 features.append(1 if entity.layer == '消防设施' else 0) # 上下文特征 features.append(len(nearby_entities)) features.append(sum(1 for e in nearby_entities if e.entity_type == 'text')) return features

6.4 模型推理与后处理

模型推理部分基本不需要改，因为输入是特征向量，和平台无关。后处理部分可能需要调整，因为不同平台的图元遍历顺序不同，合并逻辑要能处理任意顺序。

def post_process(entities, predictions): # 按空间位置聚类，合并同一设施的多个图元 clusters = spatial_clustering(entities, predictions, distance_threshold=500) facilities = [] for cluster in clusters: facility_type = majority_vote([predictions[e] for e in cluster]) center = compute_centroid([e.geometry['center'] for e in cluster]) facilities.append({ 'type': facility_type, 'center': center, 'entities': cluster }) return facilities

6.5 适配效果与经验总结

这个项目最终迁移到国产CAD平台后，识别率从原来的96%掉到91%，经过一轮特征调优后恢复到94.5%。性能方面，由于使用了批量接口和空间索引，单张图纸的处理时间从原来的3秒降到2.5秒，反而略有提升。

踩过的坑包括：

国产CAD平台的块参照变换矩阵和原平台不一致，导致嵌套块内的图元坐标偏差。解决方案是在适配层统一做一次变换。
国产CAD平台的文字图元提取接口返回的字符串编码不同，导致中文乱码。解决方案是统一转成UTF-8。
国产CAD平台在无界面模式下的选择集操作不稳定，偶尔返回空结果。解决方案是改用全图遍历加空间过滤。

7. 后续扩展方向与个人建议

这套适配方案不仅适用于消防审图，也可以扩展到其他场景，比如建筑构件识别、机电管线识别、结构配筋识别等。核心思路是一样的：定义图元抽象层，隔离平台差异，上层AI逻辑保持稳定。

如果你正准备做类似的迁移，我的建议是：

第一，不要低估适配层的工作量。很多人觉得适配层就是写几个转换函数，实际上要考虑的细节非常多，包括坐标系、单位制、扩展数据、异常处理、性能优化等。预留充足的时间。

第二，测试驱动开发。先写测试用例，再写适配代码。每个平台接口都要有对应的测试，确保行为符合预期。

第三，保持抽象层简洁。抽象层只定义AI识别需要的最小接口集，不要把CAD平台的所有功能都抽象进来。抽象层越简单，适配成本越低。

第四，关注国产CAD平台的更新。国产CAD平台还在快速迭代，API能力会越来越完善。定期关注更新日志，及时利用新特性。

第五，建立跨平台测试基准。准备一套标准测试图纸和预期结果，每次修改后都跑一遍，确保没有引入回归问题。

最后再分享一个小技巧：如果某个国产CAD平台的API实在不满足需求，可以考虑用文件解析作为补充。比如用开源的DXF解析库读取图纸，和CAD平台API的结果做交叉验证。虽然DXF格式和DWG格式有差异，但对于大部分几何图元，DXF解析的结果是可靠的。这样即使CAD平台API有问题，你也有一个备选方案。