翻译质检连载（三）：术语一致性的工程治理——从人肉盯防到自动闭环

系列索引：① 机翻为什么需要审校 ｜ ② 质检 Agent 的设计 ｜ ③ 术语一致性的工程治理（本篇·收官）

系列收官篇。前两篇解决了「发现错误」（类型学+Agent 检查），这篇解决其中非常顽固的一类：术语一致性——为什么它值得单独一篇？因为它是唯一「越到后期越严重」的错误类型：文档越长、批次越多、参与人越多，术语漂移越失控。治理它靠的不是审校的火眼金睛，是工程闭环。

术语漂移的三种来源

1. 模型内漂移：同一术语在同一次翻译里前后不一致（模型每次采样独立，长文档后半段「忘了」前半段的译法）
2. 批次间漂移：这周翻的文档和上周的译法不同（模型更新、prompt 变化、纯随机）
3. 人际漂移：不同译者/审校的用词习惯不同（「缓存失效」vs「缓存淘汰」，都对，但混用就是事故）

前两种可以工程化根治，第三种要靠规范+工具引导——三者的治理手段不同，先分清。

治理闭环的四环

环一：术语资产的单一事实源
所有术语进唯一术语库（结构见 CSDN 那篇的维护手册，这里强调治理面）：任何翻译任务的术语以库为准，人工临时改的译法必须回流入库。没有单一源，后面的环节全部失效——这是治理的地基，也是很多团队卡住的第一步（术语散落在各人脑子和各文档头部注释里）。

环二：翻译时的注入
翻译请求自动加载命中的术语子集（不是全量——文档指纹匹配 20~50 条）。关键实现细节：术语注入用「硬约束」而非「建议性 prompt」——前者是术语表机制（引擎强制遵循），后者是模型自由裁量（遵循率实测只有六七成）。工具选型时这个区别要问清。

环三：译后的自动校验
质检 Agent（系列②）跑术语一致性检查：全文扫描术语命中分布，报出「应译 X 处出现了 Y」。这里的工程细节是容差设计：允许术语在非术语语境的正常用法（比如 cache 作为普通名词），规则按词性+上下文收窄，否则误报会淹没真问题。

环四：漂移的回流修复
发现新漂移（审校纠正了一个术语）→ 自动生成入库候选（带语境）→ 双人确认进库 → 下批翻译自动生效。这一环是飞轮：没有它，术语库是静态资产，错误会重复发生；有了它，每次纠错都让未来变好。

度量的三个指标

治理效果要可度量：

1. 术语一致率：抽检文档中术语译法统一的占比（治理前基线通常 70~80%，闭环后 95%+）
2. 入库时效：新术语从首次出现到进库的天数（越短漂移窗口越小）
3. 重复纠错率：同一术语被纠正的次数（大于 1 次说明回流环节断了）

人机分工的边界

术语治理里人的职责收窄到三件事：定标准（新术语该译什么——语言判断）、裁决冲突（两种译法打架时的取舍）、季度审计（时效性 review）。其余的注入、校验、回流全部自动化——人的时间花在判断上，不花在盯防上。

系列收官

三篇串起来：机翻需要审校（①）→ 审校可以 Agent 化（②）→ 其中非常顽固的术语问题可以工程闭环（③）。质检这件事的尽头不是「找到所有错误」，是让同类错误不再发生——从检测到预防，这是「翻译质量」从手艺变成工程的完整路径。

---

写文里这些翻译场景，来自我日常在用的「随心翻译」：Edge/Chrome 浏览器插件，本地优先架构，不用不花钱。官网 suanlinfang.cn/translate?from=cnblogs