从 HyMT2Sharp 火了说起：本地离线翻译离「能用」还差三个工程门槛

最近博客园上纯 C# 的本地翻译库（HyMT2Sharp）和本地 OCR 系列（SimdPaddleOCR）连续上热榜，「数据不出门」的离线翻译赛道明显在升温。作为在这条路上走了快两年的开发者，我乐见其成——但也想泼点冷水：从「模型能跑」到「产品能用」，中间隔着三个工程门槛，社区项目往往死在第二关。

门槛一：术语一致性——单句翻译的死穴

离线模型普遍比云端小，单句翻得还不错，但整篇文档翻下来，「部署」一会儿中文名一会儿英文、「实例」和「样本」混着来。这是所有统计和中小模型的通病，不是某个库的 bug。

解法在模型外：术语表前置。翻译前扫文档抽术语、建立强制对照表，翻译时对术语做保护（先替换成占位符、翻完再还原）。工程量不大，效果立竿见影——这是本地翻译和云端拉开差距前必须补的课。

门槛二：格式保真——PDF 是试金石

纯文本翻译谁都能做，文档翻译的生死线在格式。PDF 的文本层、表格、多栏、公式，每一样都能把「翻译后还原排版」变成噩梦。本地方案还要额外考虑：不同工具生成的 PDF 结构天差地别，你至少要按「文本层完整度」分三条处理路径。

判断一个本地翻译项目成熟度，别看 demo 翻得多流畅，扔一篇双栏带表格的 PDF 进去，看输出——这一下就分出高下。

门槛三：速度与资源的平衡——离线的代价

离线翻译跑在自己机器上，显存/内存占用直接决定它是不是「常驻」工具。这里有个工程取舍：大模型质量好但常驻不起；小模型轻快但质量打折。可行的中间路线是按需加载+文档级缓存：翻译任务来了加载模型、完成即释放，重复内容（术语表、常见句式）走缓存不重翻。

结语

本地离线翻译的时机确实在变好：模型在变小、机器在变强、「数据敏感」的觉悟在变高。但把这三个门槛补齐之前，它更像技术演示而不是生产力工具。社区项目们，第二关（格式）见真章。