在建筑工程领域，CAD 图纸是工程师的语言。当一张图纸需要跨国交付时，翻译不是简单的"文字替换"------图纸中的文本散落在数百个对象中，每个对象都有自己的空间坐标、图层属性、字体样式和排版约束。直接修改文本可能破坏图纸结构，导致图层丢失、坐标偏移或排版溢出。
本文以笔者参与的一个 CAD 翻译项目为技术原型，探讨这类系统的架构设计、进程间通信、知识管道和安全写回策略。
1. 问题域：图纸文本翻译为什么困难
一张 AutoCAD 图纸不是 WYSIWYG 文档。它内部包含多种文本对象类型：
- DBText：单行文本，具有插入点、字高和旋转角
- MText ：多行文本，嵌入格式控制码（如
\fArial;、\P、\C1） - AttributeReference：块属性，如标题栏中的图纸编号、比例尺
翻译面临的几道坎：
- 格式控制码不能丢。MText 的控制码如果被送给翻译引擎就是噪声，但在回写时必须原样还原。
- 工程符号不可侵犯 。直径符号
%%c、管径代号DN200、电机型号------这些不是自然语言，是工程数据。 - 排版溢出风险。中文→英文通常长度膨胀 1.5-2 倍，在固定的包围盒内可能超出边界。
- 图层与引用关系。锁定图层不可写，块定义被多处引用，Model Space 和 Paper Space 的文本要区分处理。
2. 架构分层：插件端 + 业务核心 + 通信中间层的解耦
架构采用三层设计，核心思想是把 CAD 相关的操作隔离在插件端，业务逻辑收敛到纯 C# 核心库：
CAD 宿主
└── 插件端
│ 命名管道 (自定义帧协议)
▼
通信中间层
└── 管道服务器 + 消息路由
│
▼
核心业务层
会话管理 | 术语匹配 | QA 校验 | 占位符保护 | 回写计划为什么这样分层
核心业务层不引用任何 CAD/BIM API，不直接读写 DWG 文件。它接收的是已结构化的文本对象（坐标、图层、样式等字段），输出的是回写指令集。这让业务逻辑可被插件端、命令行批处理和桌面工作台复用，也便于单元测试。
通信中间层可嵌入桌面进程。在工作台模式下，管道服务器直接在桌面进程中启动为单例，不需要独立进程。UI 层通过服务接口间接消费路由事件，与通信层完全解耦。
3. 进程间通信：自定义命名管道帧协议
插件端与中间层之间采用 Windows Named Pipes 通信，这是当前场景的最优选择：
- gRPC 引入额外依赖和 HTTP/2 复杂度，不适合本地进程通信
- HTTP loopback 有端口冲突和防火墙风险
- 共享内存在文本提取这种非高频场景下过度设计
帧格式与消息语义
[4 字节小端序长度前缀][UTF-8 JSON 载荷]所有消息使用统一信封，包含协议版本、消息类型（request / response / event / error）、请求 ID、命令名和时间戳。设计要点：
request → response是同步语义event是单向推送，不需要响应（如翻译进度通知）error携带retryable标记，区分可重试错误与不可恢复错误
request_id 贯穿整个请求生命周期，关联首轮响应、进度推送和最终结果。
死锁防护：出站队列的异步推送
翻译调用可能耗时数分钟。如果中间层采用"收到请求 → 阻塞处理 → 发送响应"的同步环路，翻译完成后的结果消息会被卡在发送队列中，直到插件发出下一条请求才能被刷出------而插件此时正在接收循环中死等结果。
解决方案：中间层维护独立的出站队列，由后台线程持续异步将消息推送到管道，与接收循环互不阻塞。协议层面体现为：
插件: 翻译请求 (同步 request)
中间层: 确认接收 (立即 response，释放通道)
中间层: 翻译进度 (异步 event × N 次)
中间层: 翻译结果 (异步 event，最终完成)
中间层: 写回请求 (从中间层主动推送)
插件: 写回结果 (异步 event 回报)第一个响应释放了请求-响应的同步锁，后续的进度和结果事件通过出站队列独立推送。插件的接收循环始终保持就绪，不会因为等待响应而阻塞事件的接收。
4. 知识管道：四级短路查找的翻译决策链
工程翻译的核心约束是术语一致性------同一个词在整个图纸集中必须用同一个译法。为此我们设计了一个四级优先级的短路查找管道：
人工修正记忆 ← 最高优先级：用户修正过的翻译直接复用
→ 精确匹配 → 跳过所有后续步骤
│ 未命中
▼
翻译记忆库
→ 精确匹配原文 + 置信度达标 → 命中历史译文
│ 未命中
▼
术语表精确匹配
→ 源文本恰好是一个术语 → 直接使用术语表规定的译法
│ 未命中
▼
大模型翻译 ← 兜底：调用 LLM，同时注入术语上下文为什么是这个顺序
-
人工修正排第一：用户纠正过的翻译具有绝对权威。同一原文再次出现时不应再调用 LLM------否则可能产生不一致的翻译。
-
翻译记忆在术语表之前：翻译记忆存储的是整句翻译，术语表存储的是词汇。如果一句完整的话已经翻译过（如"设备基础详见结构图"），应该直接复用整句记忆，而不是拆成词汇逐一查术语表。
-
术语精确匹配是特殊路径：只有当源文本恰好是一个术语（如"镀铝锌"），才直接替换为术语表译法。部分匹配（源文本包含术语但不完全是术语）则在 LLM 调用时通过 system prompt 注入。
-
LLM 兜底但带上下文约束：调用大模型时，将匹配到的术语作为约束注入 Prompt，让模型遵守术语规范的同时保留对上下文的语义理解。
术语冲突检测
术语表支持优先级字段。当同一个源词对应多条记录且优先级相同时，系统自动生成冲突警告，要求人工裁决。标记为"不翻译"的术语（如管径代号"DN"）直接保留原文，不经过任何翻译引擎。
5. 安全写回：非破坏性策略、占位符保护与排版检测
写回是风险最高的环节。核心原则是：任何情况下，源对象不能被破坏。
clone_to_layer：最安全的写回策略
实现方式是克隆源文本对象、替换克隆体的文本内容、将克隆体移动到目标图层（如追加语言后缀）。所有操作在数据库事务（Transaction）内完成：
- 克隆成功 → 提交事务
- 任何一个操作失败 → 事务回滚，源对象毫发无损
- 锁定图层的对象拒绝写入，提示用户
对于块属性（AttributeReference），由于修改块属性会影响所有引用该块的实例，采用特殊处理：不修改源块的属性定义，而是生成独立的文本对象。
占位符保护机制
MText 格式控制码的完整处理流程：
提取阶段:
源文本 (含控制码): "\fArial;|b0|i0|p34;设备基础"
→ 占位符提取器处理
→ 规范化文本: "[FMT:1]设备基础"
翻译阶段:
使用规范化文本发送给翻译引擎
回写阶段:
译文: "[FMT:1]Equipment Foundation"
→ 占位符还原器处理
→ 最终文本: "\fArial;|b0|i0|p34;Equipment Foundation"每条文本对象维护一个占位符数组，记录每个被替换控制码的原始内容和 ID。翻译完成后运行占位符一致性校验------如果数量、顺序或内容不匹配，标记为阻断级，禁止回写。
防爆版检测
即使翻译正确，如果长度远超原文，也可能在图纸中溢出包围盒。处理策略链：
缩小字号 → 调整宽度因子 → 智能换行 → 人工确认系统记录每条文本对象的包围盒坐标，回写前估算译文的预估宽度，触发溢出警告。
6. 持久化格式：自描述的工作文件设计
工作文件是翻译任务的核心持久化格式。设计要求：
- 自描述：打开文件即可了解语言对、翻译器、知识库溯源，不依赖外部数据库
- 可恢复：中断后重新打开可继续工作
- 可审计：每条译文记录来源和编辑历史
数据结构要点
每条翻译单元包含：
翻译单元
├── 源文本、目标文本、审批状态
├── 翻译来源追踪
│ └── 来源类型: LLM | 术语表 | 翻译记忆 | 人工修正 | 手动编辑
├── 编辑历史 (追加模式，每次修改记录一条)
│ └── { 动作, 修改前文本, 修改后文本, 时间戳 }
├── QA 发现 (校验问题列表)
│ └── { 错误码, 严重级别, 描述 }
├── 知识库命中记录 (本条翻译命中了哪些术语/记忆)
└── 源实体快照 (CAD 对象属性，只读)
├── 对象句柄 (回写定位的核心依据)
├── 图层、锚点、包围盒、文本样式
└── 占位符列表状态机保证数据一致性
已提取 → 已翻译 → 已审批 → 已写回
↘ 失败 (需重试)"已写回"状态的条目被拦截，不能再次写回。任何阶段都可以转入"失败"状态，记录错误原因供人工重试。
7. 测试策略
CAD 翻译系统的测试不能只靠单元测试覆盖业务逻辑，还必须验证真实的图纸写回行为：
- 纯逻辑测试：核心业务层用 xUnit 覆盖术语匹配、占位符校验、状态流转
- 端到端验证：涉及 CAD 写回的行为通过命令行无头模式跑图验证------用真实的 DWG 文件走完完整闭环
- 契约测试：管道消息的序列化/反序列化、信封结构校验
当前项目维护 126 项自动化测试，覆盖核心模块、通信层和插件端的核心路径。
结语
CAD 翻译是一个典型的"表面简单，实则复杂"的技术领域。文本提取和替换只是冰山一角，真正的工程挑战在格式保持、排版安全、术语一致性管理和进程间通信的设计上。
本文讨论的架构模式------三层解耦、异步出站队列的死锁防护、四级短路查找的知识管道、clone_to_layer 安全写回策略、占位符保护机制------是针对这一领域的一些实践总结。如果你正在设计类似的工程数据处理系统，希望这些思路对你有参考价值。