工程图纸无损翻译系统的技术挑战与架构实践
. 问题域：图纸文本翻译为什么困难
一张 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 层通过服务接口间接消费路由事件，与通信层完全解耦。
- 进程间通信：自定义命名管道帧协议
插件端与中间层之间采用 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 回报)
第一个响应释放了请求-响应的同步锁，后续的进度和结果事件通过出站队列独立推送。插件的接收循环始终保持就绪，不会因为等待响应而阻塞事件的接收。
- 知识管道：四级短路查找的翻译决策链
工程翻译的核心约束是术语一致性——同一个词在整个图纸集中必须用同一个译法。为此我们设计了一个四级优先级的短路查找管道：
人工修正记忆 ← 最高优先级：用户修正过的翻译直接复用
→ 精确匹配 → 跳过所有后续步骤
│ 未命中
▼
翻译记忆库
→ 精确匹配原文 + 置信度达标 → 命中历史译文
│ 未命中
▼
术语表精确匹配
→ 源文本恰好是一个术语 → 直接使用术语表规定的译法
│ 未命中
▼
大模型翻译 ← 兜底：调用 LLM，同时注入术语上下文
为什么是这个顺序
人工修正排第一：用户纠正过的翻译具有绝对权威。同一原文再次出现时不应再调用 LLM——否则可能产生不一致的翻译。
翻译记忆在术语表之前：翻译记忆存储的是整句翻译，术语表存储的是词汇。如果一句完整的话已经翻译过（如"设备基础详见结构图"），应该直接复用整句记忆，而不是拆成词汇逐一查术语表。
术语精确匹配是特殊路径：只有当源文本恰好是一个术语（如"镀铝锌"），才直接替换为术语表译法。部分匹配（源文本包含术语但不完全是术语）则在 LLM 调用时通过 system prompt 注入。
LLM 兜底但带上下文约束：调用大模型时，将匹配到的术语作为约束注入 Prompt，让模型遵守术语规范的同时保留对上下文的语义理解。
术语冲突检测
术语表支持优先级字段。当同一个源词对应多条记录且优先级相同时，系统自动生成冲突警告，要求人工裁决。标记为"不翻译"的术语（如管径代号"DN"）直接保留原文，不经过任何翻译引擎。
- 安全写回：非破坏性策略、占位符保护与排版检测
写回是风险最高的环节。核心原则是：任何情况下，源对象不能被破坏。
clone_to_layer：最安全的写回策略
实现方式是克隆源文本对象、替换克隆体的文本内容、将克隆体移动到目标图层（如追加语言后缀）。所有操作在数据库事务（Transaction）内完成：
克隆成功 → 提交事务
任何一个操作失败 → 事务回滚，源对象毫发无损
锁定图层的对象拒绝写入，提示用户
对于块属性（AttributeReference），由于修改块属性会影响所有引用该块的实例，采用特殊处理：不修改源块的属性定义，而是生成独立的文本对象。
占位符保护机制
MText 格式控制码的完整处理流程：
提取阶段:
源文本 (含控制码): “\fArial;|b0|i0|p34;设备基础”
→ 占位符提取器处理
→ 规范化文本: “[FMT:1]设备基础”
翻译阶段:
使用规范化文本发送给翻译引擎
回写阶段:
译文: “[FMT:1]Equipment Foundation”
→ 占位符还原器处理
→ 最终文本: “\fArial;|b0|i0|p34;Equipment Foundation”
每条文本对象维护一个占位符数组，记录每个被替换控制码的原始内容和 ID。翻译完成后运行占位符一致性校验——如果数量、顺序或内容不匹配，标记为阻断级，禁止回写。
防爆版检测
即使翻译正确，如果长度远超原文，也可能在图纸中溢出包围盒。处理策略链：
缩小字号 → 调整宽度因子 → 智能换行 → 人工确认
系统记录每条文本对象的包围盒坐标，回写前估算译文的预估宽度，触发溢出警告。
- 持久化格式：自描述的工作文件设计
工作文件是翻译任务的核心持久化格式。设计要求：
自描述：打开文件即可了解语言对、翻译器、知识库溯源，不依赖外部数据库
可恢复：中断后重新打开可继续工作
可审计：每条译文记录来源和编辑历史
数据结构要点
每条翻译单元包含：
翻译单元
├── 源文本、目标文本、审批状态
├── 翻译来源追踪
│ └── 来源类型: LLM | 术语表 | 翻译记忆 | 人工修正 | 手动编辑
├── 编辑历史 (追加模式，每次修改记录一条)
│ └── { 动作, 修改前文本, 修改后文本, 时间戳 }
├── QA 发现 (校验问题列表)
│ └── { 错误码, 严重级别, 描述 }
├── 知识库命中记录 (本条翻译命中了哪些术语/记忆)
└── 源实体快照 (CAD 对象属性，只读)
├── 对象句柄 (回写定位的核心依据)
├── 图层、锚点、包围盒、文本样式
└── 占位符列表
状态机保证数据一致性
已提取 → 已翻译 → 已审批 → 已写回
↘ 失败 (需重试)
"已写回"状态的条目被拦截，不能再次写回。任何阶段都可以转入"失败"状态，记录错误原因供人工重试。
- 测试策略
CAD 翻译系统的测试不能只靠单元测试覆盖业务逻辑，还必须验证真实的图纸写回行为：
纯逻辑测试：核心业务层用 xUnit 覆盖术语匹配、占位符校验、状态流转
端到端验证：涉及 CAD 写回的行为通过命令行无头模式跑图验证——用真实的 DWG 文件走完完整闭环
契约测试：管道消息的序列化/反序列化、信封结构校验
当前项目维护 126 项自动化测试，覆盖核心模块、通信层和插件端的核心路径。