DXF 图纸识别建模网站：把机械图纸变成可编辑 CAD 文件

11 min read294 字项目总结
#DXF#CAD#机械图纸#SolidWorks#项目总结
分享：

项目一句话

dxf.myonlyheart.xyz 是一个把机械图纸转换成可编辑 CAD 文件的网站。

它的核心目标很直接：把 PDF、JPG、PNG 里的机械图纸线条提取出来，生成可以继续进入 CAD 工作流的 DXF 文件；如果用户本机有 AutoCAD 或 SolidWorks，还可以通过本机桥接进一步导出 DWG 或 SLDPRT。

这不是一个单纯的“图片转文件”小工具。它更像一条轻量级机械图纸数字化管线：前端负责上传和下载，云端负责安全可运行的 DXF 生成，本机桥接负责只有 Windows CAD 软件才能完成的原生格式导出。

为什么需要它

机械设计里有大量图纸并不以干净的 CAD 源文件存在。

有些是 PDF 练习册，有些是截图，有些是扫描图，还有些是别人发来的导出文件。人能看懂，但机器不能直接编辑。传统做法往往是打开图纸、手动描线、重新建草图，再一点点补尺寸和几何约束。

这个过程很机械，也很浪费时间。

所以这个项目试图先解决一个更基础的问题：能不能把图纸里的可见几何，先变成一个 CAD 软件能打开、能继续加工的中间文件？

DXF 正好适合承担这个中间层角色。它足够开放，AutoCAD、SolidWorks 和很多 CAM / CAD 工具都能读；它也足够简单，适合作为从图纸识别走向参数化建模之前的第一站。

用户使用流程

网站入口是：https://dxf.myonlyheart.xyz/

用户看到的是一个上传页面：选择 PDF、JPG、JPEG 或 PNG 文件，选择目标格式和目标软件，然后点击生成。

当前最稳定的公网能力是 DXF：

上传 PDF / JPG / PNG
-> /api/convert
-> 识别图纸线条
-> 生成 DXF
-> 浏览器下载

如果选择 DWG 或 SLDPRT，系统不会在 Vercel 云端伪造一个“看起来像成功”的文件。它会明确要求本机 CAD 桥接服务参与，因为这些格式依赖 AutoCAD、ODA 或 SolidWorks 这类原生软件能力。

这点很重要：项目没有把“格式选项”做成一个假承诺。云端能做 DXF，就真实生成 DXF；云端不能运行 SolidWorks COM，就把边界说清楚，并交给本机桥接。

两条转换路径

项目里最关键的设计，是把 PDF 和截图类图片分成两条不同路线。

PDF：优先保留原生矢量

PDF 输入走 src/pdf_parser/vector_to_dxf.py。

它使用 PyMuPDF 读取 PDF 页面里的原生矢量路径和文字，而不是先把 PDF 截图再识别。这样做的好处是很明显的：如果 PDF 本身就是 CAD 或矢量图导出的，那么线条、曲线和文字本来就在文件里，没必要把它们降级成像素再猜回来。

这条路径还会处理两个机械图纸里很常见的噪声：图框和标题栏。

很多工程图右下角有标题栏，外圈有图框。它们对人类阅读很有用，但对后续建模通常是干扰。项目提供 remove_border 选项，默认过滤这类页面框线和标题栏区域，让导出的 DXF 更接近真正需要编辑的几何主体。

JPG / PNG：从像素里识别几何

图片输入走 src/image_processor/image_to_dxf.py。

它的流程更像传统图像处理：先加载灰度图，再做二值化和预处理，去掉一部分文字噪声，然后交给几何检测器识别线段和圆，最后通过 DXF 生成器输出文件。

这条路天然更难，因为截图只有像素，没有“这是一条线”这样的结构信息。线宽、压缩、噪点、拍照角度都会影响结果。

所以它现在更适合干净、规则、线条明确的练习册图纸，而不是复杂的真实工厂扫描件。这也是项目后续可以继续迭代的地方：更强的尺寸识别、更稳的圆弧识别、更好的文字和标注分离。

云端和本机的边界

这个项目最值得保留的架构判断，是没有把所有事情都塞进云端。

Vercel 适合处理轻量、无状态、可跨平台运行的部分，例如：

  • 接收上传文件
  • 调用统一转换管线
  • 生成 DXF
  • 返回下载响应
  • 提供健康检查和静态页面

但 DWG 和 SLDPRT 是另一回事。

DWG 往往需要 AutoCAD 或 ODA 转换后端。SLDPRT 更依赖 Windows 上的 SolidWorks COM。它们不是普通 Linux serverless 环境可以稳定完成的事情。

于是项目设计了本机桥接：浏览器把任务提交到 http://127.0.0.1:8765，本机服务再调用 AutoCAD 或 SolidWorks 完成原生导出。

这条链路的隐私边界也更清楚：DXF 云端生成会上传文件到 Vercel；DWG / SLDPRT 本机生成则不把源图纸发到公网服务器，而是在用户电脑上完成。

统一转换层

项目目前最重要的工程整理，是 src/conversion/ 这层。

过去一个容易出现的问题是：Vercel 入口 api/index.py 和本地入口 src/web_app.py 各写一套转换逻辑。这样一来，线上和本地行为就会慢慢分叉，修一个 bug 要改两处，还容易漏。

现在统一由 convert_drawing_file() 调度：

入口接收文件
-> 校验输入格式和输出格式
-> 保存临时文件
-> 调用 src/conversion/pipeline.py
-> PDF 走矢量提取
-> 图片走几何识别
-> 返回统一 ConversionResult

入口文件只处理 HTTP、表单和响应；转换层处理业务逻辑；PDF、图片、本机 CAD 各自保持清晰边界。

这让项目从一个“能跑的脚本”往“可维护的产品”靠近了一步。

它现在能做什么

当前版本可以稳定表达几件事：

  • 支持 PDF、JPG、JPEG、PNG 输入。
  • 公网环境真实生成 DXF。
  • PDF 优先读取原生矢量和文字。
  • 图片走预处理、几何检测、DXF 生成。
  • 支持删除图框和标题栏。
  • 前端能直接下载生成文件。
  • 本机桥接可以承接 AutoCAD / SolidWorks 原生导出。
  • DWG / SLDPRT 不在云端假装支持，而是明确提示所需后端。

这已经足够构成一个实际可用的 MVP。

它还不是什么

它还不是一个完整的“AI 自动建模”系统。

从图纸到可制造零件，中间还有很多困难问题：尺寸识别、投影视图理解、剖视图判断、公差和技术要求解析、草图约束恢复、三维特征推理、装配关系推断。

这个项目现在更像第一层地基：先把图纸里的可见几何可靠地搬进 CAD 世界。

只有这一层稳定了，后面才谈得上从 DXF 草图继续生成 SolidWorks 特征树，或者让 AI 根据图纸理解零件结构。

下一步

我希望它后续往三个方向进化。

第一，增强识别质量。尤其是圆弧、孔、中心线、尺寸标注和文字区域的分离，让截图类图纸不再只是“能导出线条”，而是尽量接近可编辑草图。

第二，增强本机桥接。让 AutoCAD / SolidWorks 任务队列更稳定，进度更清晰，失败信息更可理解。用户不应该面对一堆底层 COM 错误，而应该知道是软件没启动、文件不合规，还是格式后端缺失。

第三，走向结构理解。DXF 是中间结果，但不是终点。真正有价值的是从二维工程图里推断机械特征：孔、轴、槽、齿轮、轴承位、装配关系。那会把项目从“图纸转换器”推进到“机械图纸理解器”。

总结

dxf.myonlyheart.xyz 的价值不在于它一次性解决所有 CAD 自动化问题，而在于它把最现实的第一步做出来了：

把机械图纸从不可编辑的 PDF 或图片，变成可以进入 CAD 工作流的 DXF。

它承认云端能力的边界，也保留本机 CAD 软件的价值；它把 PDF 矢量、图片识别、格式校验、前端下载和本机桥接拆成清晰模块；它不是空喊“AI 建模”，而是在一点点打通从图纸到模型的工程链路。

这类项目真正迷人的地方也在这里：它不是为了展示一个炫技 demo，而是在把机械设计里最笨、最耗时间、最容易重复劳动的部分，一点点交给程序。