CAD_Converter：从图纸转换到 AI 分析的工程实践

CAD_Converter 是我参与设计和构建的一套 CAD 图纸处理工具。仓库目前是私有的，这里只记录可以公开的技术方案，不涉及内部图纸、模型配置和接口信息。

这个仓库要解决什么问题

项目面对的不是单纯的格式转换，而是一批来源、版本和绘图习惯都不统一的工程图纸。使用者需要先把 DWG 转成可处理的 DXF，再按规则清理图层、文字和颜色，最后导出 PNG、PDF 或 SVG。部分图纸还要继续交给视觉模型分析，从中提取设备与连接关系，并把识别结果标回图中。

如果这些步骤各自做成零散脚本，每换一张图就要手动搬文件、改参数，也很难知道失败发生在哪一步。因此我想把它做成一套有界面、能批量运行、能记录进度，也可以直接打包交付的完整工具。

我采用的整体方案

我把仓库分成入口、核心能力、界面页面和交付脚本几层。

src/main.py 负责启动 Qt 应用和处理运行期消息；src/gui/main_window.py 组织主窗口，并把功能拆成“格式转换”“图纸清理”“AI 分析”三个页面。页面只负责收集参数、展示预览和反馈任务状态，真正的处理逻辑放在 src/core。

核心层继续分工：dwg_converter.py 适配 ODA File Converter 与 LibreDWG，cad_processor.py 负责可组合的清理流水线，converter.py 负责图像和矢量格式导出，font_manager.py 处理工程字体，ai_analyzer.py 负责图像编码、模型调用、结构化解析与标注回绘。设置和通用路径处理也各自独立。

这种拆法是我在构建整套代码时定下来的。三个界面页共享同一套核心能力，命令行工具的特殊规则不会进入 GUI，AI 分析也建立在转换结果之上，不会反过来改坏原图。

DWG 转换层怎么统一

ezdxf 适合读取和修改 DXF，却不能直接覆盖所有 DWG 场景。我没有把某一个转换器写死，而是定义了转换引擎枚举和统一入口。程序先检测本机可用工具，兼容性上优先 ODA，找不到时再回退到 LibreDWG。

两种工具的调用方式不同。LibreDWG 接近单文件转换，ODA 则要求传入输入和输出目录。我在 ODA 适配器里为每个任务建立临时目录，把单个 DWG 放进去，转换完成后再取回目标 DXF。上层始终只传源文件和输出文件，不需要知道目录转换这项限制。

这一层还负责进度回调、超时、输出文件检查和错误整理。只有外部进程退出并且目标文件真实存在，任务才算成功。

图纸清理做成可组合流水线

清理规则不是写在一个很长的函数里。cad_processor.py 中有统一的 ProcessingStep，下面分别实现查找最大图块、单次炸块、删除轴线层、删除文字密集层、删除全部文字、灰白实体筛选和统一灰色等步骤。

默认流水线把这些步骤按顺序组合，CADProcessor 负责执行。这样做是因为顺序会改变结果：图块没有展开，内部实体就可能无法被后续规则命中；辅助文字和轴线没有清掉，也会干扰导出效果与模型判断。

每一步都能单独汇报进度。遇到图纸处理异常时，我可以保存中间 DXF，确认是输入图块、图层规则还是颜色判断出了问题，不必只盯着最终图片猜。

工程字体也是这一层必须处理的现实问题。仓库随程序整理了一批 SHX 字体，并在找不到原字体时尝试映射到可用的 TTF。字体回退不一定完全还原原始排版，但至少避免换一台电脑后直接缺字或中文乱码。

从批处理到 AI 分析

大图渲染和批量转换不能占住 Qt 主线程。我把耗时任务放进工作线程和线程池，页面只接收进度、结果与异常。失败后要恢复按钮、清理临时目录，并指出问题属于 DWG 转换、DXF 清理、导出还是模型调用。

AI 分析层先限制图像尺寸并编码，再通过 httpx 调用视觉模型。模型返回内容会被解析成 Equipment、Connection 和 AnalysisResult 等结构，最后由本地代码绘制设备框与连接标记。解析失败时保留转换后的图像和原始响应，方便继续定位，不会覆盖原始 CAD 文件。

项目同时维护 build_nuitka.py 和 build_pyinstaller.py。打包时不仅要收集 Python 与 Qt 依赖，还要带上字体、图标、LibreDWG 和 ODA 所需文件。开发环境能运行只是第一关，换到干净电脑后还能启动、转换和正确报错，才算交付完成。