张 AutoCAD 图纸不是 WYSIWYG 文档。它内部包含多种文本对象类型DBText单行文本具有插入点、字高和旋转角MText多行文本嵌入格式控制码如 \fArial;、\P、\C1AttributeReference块属性如标题栏中的图纸编号、比例尺翻译面临的几道坎格式控制码不能丢。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 项自动化测试覆盖核心模块、通信层和插件端的核心路径。
张 AutoCAD 图纸不是 WYSIWYG 文档。它内部包含多种文本对象类型DBText单行文本具有插入点、字高和旋转角MText多行文本嵌入格式控制码如 \fArial;、\P、\C1AttributeReference块属性如标题栏中的图纸编号、比例尺翻译面临的几道坎格式控制码不能丢。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 项自动化测试覆盖核心模块、通信层和插件端的核心路径。
