企业官网建设流程全解析

评价一次翻译好不好，大多数人下意识用的标准是“这句话翻得对不对"。这个标准没有错，但它只覆盖了任务的一半。另一半——文件本身能不能继续被使用——很少被单独拿出来讨论，可它恰恰是让很多翻译结果在实际工作中打折扣的地方。这篇文章想把"文本翻译"和"文档翻译"这两件事分开说清楚。

一、两个术语的区分

先给两个词一个明确的定义，避免后面讨论时混着用。

文本翻译，指的是把一种语言的字符串转换成另一种语言的字符串。输入是文字，输出也是文字，评价标准是准确、通顺、语境贴合。这是语言模型最擅长、也是过去几年进步最明显的部分。

文档翻译，指的是把一份文件——PDF、Word、PPT、扫描件——从一种语言的版本变成另一种语言的版本，同时保持这份文件原有的组织形式：还是那本报告，还是那份合同，打开之后该有的标题、表格、页码、引用关系都还在，可以正常阅读、编辑、交付。

区别在哪里？文本翻译的对象是句子集合，文档翻译的对象是一个带结构的容器。前者做完，只能说“字翻完了"；后者做完，才能说"文件翻完了"。很多场景下用户说“帮我翻译一下这份文件"，心里想要的其实是后者，但拿到的往往只是前者的结果。

二、文档中的结构性信息清单

要理解两者的差距具体在哪，可以把一份文档拆开看，列出那些“不属于文字本身，但决定文档能不能用"的信息：

• 标题层级：一级标题、二级标题、正文之间的从属关系，决定了大纲和目录能不能正常生成。

• 表格：行列对应关系、合并单元格、表头与数据的绑定。表格翻译最容易出问题，因为单元格内的文字一旦被当成独立句子处理，行列结构就没有人维护了。

• 公式：理工科文档里常见，公式本身通常不需要翻译，但公式前后的变量说明、公式编号需要和正文保持对应，公式的位置也不能跑到别的段落里。

• 分栏：很多报告、论文采用双栏或三栏排版，阅读顺序是“先读完左栏再读右栏"，如果翻译时把分栏当成从左到右的普通文本读取，句子顺序会直接错乱。

• 交叉引用：正文里“见第 3 章"“如图 5 所示"这类引用，依赖的是章节号、图号在翻译后依然准确对应，一旦编号或位置发生偏移，引用就会指向错误的内容。

• 图文关系：图片、图注、脚注之间的绑定关系。图还在原处，图注却漂移到别的页面，是最常见也最影响观感的问题之一。

这六类信息共同构成了一份文档的“骨架"。文本翻译只处理骨架上附着的文字，骨架本身谁来维护，是文档翻译需要额外解决的问题。

三、为什么大模型不等于文档翻译方案

这两年大语言模型让翻译的语言质量有了明显提升，很多人因此觉得“翻译问题已经解决了"。但这个判断混淆了两件事。

大模型擅长的是语言层面的转换：理解上下文、处理歧义、保持语气和术语的一致性。这些能力直接提升的是文本翻译的质量。但大模型本身的输入输出形式是 token 序列，一段文字进去，一段文字出来，这个过程里并不天然携带“这段文字在页面上的第几栏"“这是不是表格的一个单元格"这类结构信息。

也就是说，大模型能力的边界，止步于“这句话翻得好不好"，并不延伸到“这份文件翻完还能不能用"。要让模型的输出重新变成一份结构完整的文档，需要在模型之外再搭建一层——文档解析和版式重建的能力。这层能力和语言能力是两套不同的技术栈，一套做得好，不代表另一套也做得好。这也是为什么市面上有些工具译文质量很高，但用户拿到手之后还是要花时间重新排版：语言这一半做得不错，文档这一半没有配套跟上。

四、“可用性"的四个检验维度

与其笼统地说“这份翻译好不好用"，不如拆成四个具体可以检验的维度，逐一去看：

1. 可读：打开文件，内容顺序是否符合原文的阅读逻辑，段落有没有因为分栏、跨页被打乱。这是最基础的一层，如果连顺序都乱了，后面几层无从谈起。

2. 可编辑：拿到的文件是不是一份可以直接在原有软件里继续修改的文件，还是一份只能整体复制粘贴、结构已经被破坏的“死文件"。可编辑意味着字体、段落样式、表格框架这些属性都还保留在文件里，而不是变成图片或纯文本堆叠。

3. 可核对：如果需要对照原文检查译文准确性，是否方便逐段、逐句地找到对应位置。目录能不能跳转、章节编号是否和原文一致，都是可核对的具体体现。

4. 可交付：这份文件能不能不经过额外整理，直接发给同事、客户或者用在正式场合。这是四个维度里最贴近实际使用场景的一条，也是前面三条共同作用的结果。

这四个维度是递进关系：可读是底线，可交付是终点。多数翻译工具能保证前两条勉强达标，第三、第四条往往需要用户自己动手补齐，这也是“翻译完之后还要花时间整理"这件事的根源所在。

五、文档翻译的完整链路

把前面的分析串起来，一个完整的文档翻译任务，实际上需要经过几个相对独立的步骤，而不是“输入文字、输出译文"这一步就能完成：

解析文件：这是链路的入口，任务是把不同格式的原始文件读进系统里，转换成程序可以处理的数据形式。PDF、Word、PPT、扫描件的底层编码方式各不相同，PDF 本质上是一堆带坐标的绘图指令，Word 是带标记语言的树状结构，扫描件甚至连文字层都没有，需要先过一道 OCR。这一步做得不到位，后面所有环节都无从谈起——比如一份扫描件如果文字识别有偏差，后面的翻译从源头上就是错的。

识别结构：在拿到可处理的数据之后，系统需要判断页面上每一块内容“是什么"：这一段是标题还是正文，这一块是表格还是普通文本，这几行属于左栏还是右栏，这张图对应的图注在哪里。这一步的输出不是文字内容，而是一份结构地图，记录着每个元素的类型、位置和相互关系。识别结构和解析文件常常被混为一谈，但其实是两件事：解析解决的是“读得进来"，识别解决的是“读得懂版面"，后者的难度往往更高，因为不同文档的排版习惯千差万别，没有统一的规则可以套用。

翻译内容：在结构地图确定之后，才轮到语言转换登场，把每一块内容对应的文字单独送去做翻译，同时保留它在结构地图里的位置标记，确保译文出来之后还能对应回原来的位置。这一步是语言模型发挥作用的环节，也是过去几年技术进步最明显的部分，但它处理的始终只是内容本身，不涉及内容之间的排布关系。

重建输出：把翻译完成的内容，按照识别结构阶段留下的位置标记重新装配回去，恢复标题层级、表格框架、图文绑定关系、交叉引用的对应关系，最终生成一份可以在常规软件里打开的文件。这一步同样需要处理很多细节，比如中文和英文的排版密度不同，同样的表格宽度，中文译文可能比英文原文更短或更长，需要做适当的自适应调整，否则表格会出现留白过多或者文字溢出的问题。

这四步里，翻译内容只是其中一环，前后各有两道工序需要独立完成。识别结构做得不够细，重建输出就没有依据；重建输出做得不够严谨，即使前面识别和翻译都准确，最终交到用户手里的依然是一份需要二次整理的文件。这也是为什么判断一个文档翻译工具是否合格，不能只看译文读起来顺不顺，还要看它有没有认真对待解析、识别、重建这几个环节，而不是把全部精力都投在翻译内容这一步上。

六、LingoMirror 在各环节的对应能力

我们在设计 LingoMirror（上海比孚）时，是把上面这条链路当作一个整体去对待的，而不是只做中间的翻译环节。

在解析和重建这两端，我们的核心目标是版式结构保留：文档进来之后，标题层级、表格的行列关系、图文的绑定关系会先被识别和记录下来，翻译完成后再按照这份记录把内容装配回原有的版式里，尽量让“翻完的文件"和“原来的文件"在结构上保持一致，而不只是文字内容对应。

在输出环节，我们坚持给到可编辑输出：交付的文件是可以在常规办公软件里直接继续修改的格式，而不是只能查看的静态版本。这一点是从“可编辑"、“可交付"这两个可用性维度倒推回来的产品要求——如果输出的文件不能编辑，前面结构保留得再好，用户依然要花时间做格式转换或重新录入。

这套思路目前主要解决的是“结构不丢失、文件能继续用"这个层面的问题，复杂版式的完全还原仍然是持续在优化的方向，不存在一次性解决所有排版情况的通用方案。

结语

判断一次翻译是否合格，逐句准确是必要条件，但不是充分条件。文本翻译解决的是语言问题，文档翻译解决的是结构问题，两者需要不同的能力去支撑，也应该用不同的标准去检验。下次评估一个翻译工具时，不妨把“译文准不准"和“文件能不能用"分开来看，这样得到的判断会更接近实际使用体验。