从手动到自动：一个CAD图纸翻译工具的演进实录

引言
作为一个长期关注CAD二次开发的开发者，我亲眼见证了图纸翻译这件事，从最初的手动操作，一步步走到今天的自动化处理。这篇文章，我想以一个开发者的视角，记录这个技术演进的过程。不是产品评测，不是技术教程，只是一个技术人的观察笔记。

第一阶段：手动时代
大概五年前，我参与一个海外项目时，第一次接触到图纸翻译的需求。当时的做法是：在CAD里打开图纸，选中文字，Ctrl+C复制，切到翻译软件，Ctrl+V粘贴，翻完再切回CAD，双击文字，粘贴译文。一张图纸几十处文字，这么来回切几十次。一套五十张的图纸，两个人翻了两天。

这个阶段没什么技术可言，纯体力活。但它让我第一次意识到：CAD图纸翻译，本质上不是一个翻译问题，而是一个数据提取与回写的问题。翻译本身有现成的引擎可用，但“怎么从DWG里把所有文字拿出来、翻完再放回去”，当时没有一个成熟的方案。

第二阶段：脚本时代
手动翻了几套图纸后，我开始琢磨能不能写个脚本自动化。当时用AutoCAD自带的LISP，写了一个简单的程序：遍历当前文档中的所有TEXT实体，把文字内容导出到一个TXT文件，人工翻译后，再导回去。

这个脚本只支持TEXT，不支持MTEXT，不支持块属性，不支持表格。而且每次都要在CAD里手动加载、运行。但它省了至少一半的复制粘贴时间。后来我把这个脚本分享给同事，他们用了一阵子，反馈说“能不能把多行文本也加上”。

于是我开始迭代：加MTEXT支持、加ATTRIB支持、加嵌套块遍历。每加一个功能，脚本就臃肿一圈，维护也越来越吃力。而且有一个问题始终没解决：没装AutoCAD的同事还是用不了。

第三阶段：独立工具时代
真正转做独立工具，是在发现ODA库之后。ODA（Open Design Alliance）提供了独立于AutoCAD的DWG解析能力，不需要安装CAD就能读写DWG文件。这解决了脚本时代最大的限制。

我把之前脚本的核心逻辑用Python重写了一遍，基于ezdxf和ODA File Converter，做了一个独立的命令行工具。支持批量处理，整个文件夹拖进去排队翻译。同事不用装AutoCAD也能用了。

但命令行工具的门槛还是太高。没有图形界面，普通用户根本不知道怎么操作。所以后来又加了一层桌面端壳子，做成了现在这个软件的雏形。

核心技术决策
在这个过程中，有几个技术决策我觉得值得记录下来：

1. “原地修改”还是“删了重建”？

这个选择决定了图纸翻译后图层是否保留。早期我的脚本就是“删了重建”的，翻完后所有文字都在0层，被同事抱怨了很久。后来改成“直接修改原实体的文本内容”，图层问题才解决。

2. 表格怎么处理？

表格是CAD中最复杂的文字承载实体。每个单元格独立存储，不能整段替换。我的第一版表格处理是整段替换的，翻完后材料表全串行了。后来改成按Cell逐个处理，才解决串行问题。

3. 天正图纸怎么办？

国内设计院用天正的很多，天正的自定义实体普通工具读不出来。我试过直接解析天正的代理实体，太复杂了，而且不同版本的天正结构还不一样。最后选择了引导用户导出T3格式这个方案——不是最完美的，但是最稳定的。

技术之外的收获
做这个工具的这几年，最大的收获不是技术上的，而是对用户需求的理解。

很多开发者做工具，喜欢堆功能，觉得功能越多越好。但实际上，用户最需要的往往不是“多”，而是“稳”。图层不乱、表格不串、标注不跑，这些看似基础的事情，恰恰是最难做到的，也是用户最在乎的。

另一个收获是：不要替用户做太多假设。我最早设计的工作流是“打开文件→选择翻译语言→选择输出目录→开始翻译”，四个步骤。后来发现用户只想拖进去就完事。改成拖入自动翻译后，使用率明显上升。

写在最后
从一个几十行的LISP脚本，到现在一个完整的桌面端软件，这条路走了好几年。回头看，每一步迭代都不是计划好的，而是被用户需求推着走的。

这个领域虽然不大，但技术深度足够。光是“把DWG里所有文字找全”这一件事，就够研究很久。希望这篇记录能给同样在做CAD二次开发的同行一些参考。

作者简介：CAD二次开发爱好者，多年从事DWG文件解析与工程图纸翻译技术研究。个人博客持续更新相关技术文章。