从图纸截图到 DWG：一次本机 CAD 桥接实践

最近我把机械图纸识别网站做了一次比较关键的升级：它不再只是把 PDF 图纸转成 DXF，而是开始尝试把真实工程软件也接进工作流里。

新的目标很直接：

上传一张 PDF 图纸，或者一张 JPG / PNG 截图，网站识别图纸线条，然后根据用户选择生成 AutoCAD 的 .dwg 文件，或者 SolidWorks 的 .sldprt 文件。

听起来像是一个简单的“格式转换”功能，但真正做起来会发现，DWG 和 SLDPRT 不是普通文件格式转换那么轻松。它们背后分别站着 AutoCAD 和 SolidWorks 这样的本机工程软件。

所以这次升级的重点不是“把扩展名改掉”，而是设计一条更可靠、更尊重隐私的链路。

为什么不能全部放在云端做

网站现在部署在 Vercel 上。Vercel 很适合运行前端、API、轻量图像处理和文件生成，但它不适合直接运行 AutoCAD 或 SolidWorks。

原因很现实：

SolidWorks COM 只能在 Windows 本机环境里稳定运行。
AutoCAD 原生 DWG 保存也依赖本机 AutoCAD 或专门的 DWG 转换后端。
Vercel serverless 不适合启动大型桌面软件。
用户的工程图纸也不应该为了生成本机 CAD 文件而被不必要地上传到云端。

因此我把能力拆成两层：

云端：负责网站页面、PDF/JPG/PNG 到 DXF 的通用转换。
本机：负责调用 AutoCAD / SolidWorks 生成真实 DWG / SLDPRT。

这也是这次架构里最重要的取舍。

整体流程

现在网站的处理流程大致是这样：

用户上传 PDF / JPG / PNG
        |
        |-- 选择 DXF
        |      -> 上传到 Vercel
        |      -> 提取图纸线条
        |      -> 返回 DXF
        |
        |-- 选择 DWG / SLDPRT
               -> 浏览器直接发送到本机 127.0.0.1:8765
               -> 本机先生成中间 DXF
               -> AutoCAD 保存 DWG
               -> 或 SolidWorks 保存 SLDPRT
               -> 浏览器下载本机生成的文件

这样做有一个很重要的好处：生成 DWG / SLDPRT 时，原始图纸不会经过 Vercel。

它只在用户自己的电脑里流转。

PDF 与图片输入

PDF 和截图的处理方式不一样。

PDF 如果本身带有矢量线条，最好的方式是直接读取 PDF 里的原生路径。这样线条更干净，精度也更好。

JPG / PNG 是像素图，就只能走图像识别路线：

JPG / PNG
-> 灰度化
-> 阈值处理
-> 去除小噪点
-> Hough 线段 / 圆识别
-> 生成 DXF 几何

第一版并不追求看懂所有工程图纸。它更适合规则清楚、线条干净的练习册图纸，比如矩形板、孔、槽、简单轮廓这类结构。

为什么中间格式选择 DXF

DXF 在这个系统里扮演中间层角色。

它有几个优点：

文本结构相对开放。
AutoCAD 和 SolidWorks 都能导入。
适合承载线段、圆、圆弧、多段线等基础图纸元素。
方便调试，不会像 DWG / SLDPRT 那样完全依赖专有软件内部结构。

所以系统的策略是：

图纸识别
-> 中间 DXF
-> AutoCAD / SolidWorks 本机导入
-> 保存为 DWG / SLDPRT

这比直接“猜一个 DWG 文件结构”可靠得多。

本机 CAD 桥接服务

为了让网页能调用本机 AutoCAD 和 SolidWorks，我在电脑里部署了一个本机桥接服务。

它只监听：

http://127.0.0.1:8765

也就是说，它只接受本机浏览器访问，不对局域网开放。

网页在用户选择 DWG 或 SLDPRT 时，会先检查桥接服务是否已经运行。如果没有运行，会尝试通过本机协议唤起；如果系统拦截，也可以手动运行：

scripts/start_cad_bridge.bat

这避免了开机自启动。只有用户真的要生成 DWG / SLDPRT 时，才启动桥接。

任务队列与进度

AutoCAD 和 SolidWorks 启动都比较重，不能把它们当成普通 HTTP 请求一样瞬间完成。

所以本机桥接增加了任务队列：

POST /api/local-cad/jobs
GET  /api/local-cad/jobs/{job_id}
GET  /api/local-cad/jobs/{job_id}/download

网页提交任务后，会每秒查询一次进度。任务状态包括：

queued：已排队
running：正在转换
completed：已完成
failed：失败

这样用户不会面对一个一直转圈的按钮，而是能看到“正在生成中间 DXF”“正在调用 AutoCAD”“转换完成”这样的过程。

隐私边界

这次设计里，我最在意的是隐私边界。

DXF 云端生成可以上传文件到 Vercel，因为它是普通的图纸转换服务。

但 DWG / SLDPRT 生成不一样。它们通常意味着更完整的工程资产，因此我让这条链路只在本机发生：

浏览器
-> 127.0.0.1 本机桥接
-> 本机 AutoCAD / SolidWorks
-> 本机文件下载

文件不会被发到公共服务器，也不会写入远程日志。

当前能力边界

目前这个系统已经能完成基础链路，但它仍然是第一版。

已经支持：

PDF / JPG / PNG 上传。
PDF 矢量线条提取。
图片线条识别。
DXF 生成。
本机 AutoCAD 生成 DWG。
本机 SolidWorks 生成 SLDPRT。
本机任务队列与转换进度。

还不追求：

自动理解复杂多视图工程语义。
完整恢复尺寸约束。
从任意装配图恢复 3D 装配体。
复杂曲面、拔模、工程公差驱动建模。

我更愿意先把“规则明确的练习册零件”做稳，再逐步扩展。

下一步

后续我想继续补三件事：

加入更明确的图纸结构识别：主视图、俯视图、左视图、标题栏、尺寸线分离。
把 OCR 尺寸识别和几何识别关联起来，生成更可编辑的 features.json。
让 SolidWorks 不只是导入 DXF，而是根据特征自动拉伸、切孔、开槽，最终生成更干净的参数化 SLDPRT。

这条路线的长期目标不是做一个“黑箱转换器”，而是做一个可解释、可人工修正、能逐渐积累工程知识的图纸理解系统。

从截图到 DWG，只是第一步。