长文档翻译最怕前后不一致：术语、记忆和领域画像如何协同

做长文档或项目翻译时，一个非常常见的问题是：单句看起来都对，但整份文件读起来不一致。

同一个产品名，前面一个译法，后面一个译法。

同一个功能模块，合同里叫一个名字，PPT 里又换了说法。

同一个客户项目，上一批文件已经确认过译法，下一批又漂了。

这不是简单调高模型能力就能彻底解决的问题。

它需要术语、记忆、领域和上下文一起进入翻译链路。

为什么大模型也会术语漂移？

模型是按上下文生成译文的。

这带来一个好处：它能根据语境翻译。

也带来一个问题：如果没有明确约束，同一个词在不同段落里可能被翻成不同说法。

尤其是这些内容：

• 产品名、模块名、按钮名。
• 法律条款和合同固定表达。
• 医疗、工程、财务、制造等行业术语。
• 客户已经确认过的长期译法。
• 同一批文件中反复出现的标题、标签和短句。

如果只是把每个分片单独交给模型，前后漂移几乎不可避免。

LinkEngine 不是只把术语表塞进提示词

很多系统的做法是：把术语库整段塞进 prompt。

小项目还凑合，大项目很快就会遇到问题：

• 术语库太大，塞不下。
• 每段都线性扫描，速度很慢。
• 无关术语干扰当前语境。
• 模型看到了术语，但未必稳定执行。

LinkEngine 的思路更工程化一点。

术语库加载后会构建规范化索引，并按当前分片文本命中候选，而不是每段都扫全表。翻译记忆也会按阈值参与匹配：100% 完全匹配可以直接覆盖译文，低于阈值但足够相似的历史译法作为参考注入。

这样术语和记忆不是“堆在提示词里”，而是按当前文件、当前分片、当前语言方向精准参与。

领域画像为什么重要？

同一个词在不同领域里可能完全不同。

例如：

• cell 在医学、电子、Excel 表格里含义不同。
• seal 在合同、机械、包装、印章语境里译法不同。
• terminal 在工程、计算机、物流、金融里都有不同用法。

所以 LinkEngine 和 LinkClaw 共用领域画像服务，会综合文件名、用户提示、正文样本、术语候选、标准/法规号、医学临床词、法律义务、财务指标、工程参数和贸易单证等信号，判断当前主领域和风险术语。

领域画像不是为了替代局部语境。

它的作用是提醒模型：这份文件更可能属于哪个专业场景，哪些词需要更谨慎，哪些术语值得联网或知识库核验。

当前批次的一致性也要管

长期术语库和翻译记忆很重要，但一批文件内部也需要临时一致。

比如同一批产品说明书里，某个短语第一次被翻译为一个稳定译法，后面又重复出现。如果每次都让模型重新判断，就可能前后不一致。

LinkEngine 会维护批次级一致性 ledger。

它只记录通过有效性校验的全句或短语译法，跳过非译项、纯数字、目标语言已满足内容和疑似未译内容。

这份 ledger 只服务当前任务或当前批次，不会污染全局记忆库。

这样既能减少当前项目里的译法漂移，又不会把一次错误译法长期固化。

LinkClaw 在这里能做什么？

LinkEngine 负责主翻译链路里的术语、记忆和领域注入。

LinkClaw 更适合做翻译后的追问和审校：

• 检查某个术语是否前后一致。
• 对比原文和译文里关键术语。
• 生成术语风险报告。
• 把审校发现整理成可修改建议。
• 对高风险术语做联网核验或知识库查询。

例如用户翻译完以后可以问：

帮我检查这批文件里产品名和功能名有没有译法不一致。

这时 LinkClaw 可以绑定最近任务上下文，让 OpenClaw 或 Hermes 按结构化结果继续检查，而不是重新读一遍混乱的 Office 文件。

一致性不是越死越好

这里还有一个细节：术语一致不等于机械替换。

同一个源词在不同结构角色、文件类型和上下文里，可能确实应该有不同译法。

所以 LinkEngine 的策略不是“同词必同译”，而是：

• 已确认术语优先。
• 100% 翻译记忆优先。
• 当前批次稳定译法作为参考。
• 混合语境下让模型保留局部判断。
• 高风险术语给出证据和审校提示。

这比简单替换更符合真实翻译项目。

最后

文件翻译要做到“能用”，不只是每句话通顺。

长期看，团队真正需要的是：

• 同一客户的表达能延续。
• 同一项目的术语能统一。
• 高风险专业词有证据。
• 当前批次不会前后漂移。
• 发现问题后还能继续审校和修复。

这就是 LinkEngine 做术语、记忆、领域画像，LinkClaw 做后续智能体审校的原因。

如果你也在做企业文档翻译、术语库、翻译记忆和 AI 审校工作流，