你收到一封英文邮件，附了一个 80 页的技术白皮书。
复制粘贴到网页翻译？80 页，你疯了。
直接上传整个 PDF 让有道翻？排版会不会炸？专业术语翻得对不对？
这篇文章用四种真实文档做了完整的上传翻译测试——从技术报告到学术论文到法律合同——告诉你什么能翻、什么翻不了、什么翻了之后没法用。
测试设计：四类文档，覆盖最常见场景
不是随便找几个 PDF 丢进去看结果。挑了四种完全不同类型、不同难度、不同排版复杂度的文档：
| 文档类型 | 原文语言 | 页数 | 难度 | 关键挑战 |
|---|---|---|---|---|
| 技术白皮书（AWS S3 概述） | 英文 | 28 页 | 中等 | 大量专业术语、代码块 |
| 学术论文（机器学习方向） | 英文 | 12 页 | 高 | 数学公式、参考文献、双栏排版 |
| 法律合同（NDA 模板） | 英文 | 8 页 | 高 | 法律术语精确性、段落编号 |
| 产品说明书（相机使用手册） | 日文 | 15 页 | 中等 | 日中互译质量、图文混排 |
操作环境：有道翻译桌面版（Windows），会员版，文件通过"文档翻译"入口上传，统一选择"英文→中文"或"日文→中文"。
技术白皮书：专业术语处理超出预期
第一个测试是 AWS S3 服务概述的技术白皮书，28 页纯英文。
上传后 2 分 4 秒完成翻译。翻完之后，整体排版保持了大约 92% 的原样——图片位置不变、段落结构不变、标题层级不变。说实话比我想象的好。
但有几个地方翻了车：
“bucket” 被翻译成了"桶"。严格来说没错——S3 的 bucket 确实叫"存储桶"——但全文统一翻成"存储桶"会比单独叫"桶"更专业。后续发现"object"翻成了"对象"（正确），“lifecycle policy"翻成了"生命周期策略”（正确），整体上 90% 的技术术语处理正确。
代码块里的注释被翻了。JSON 代码里的 // This is a comment 被翻译成了中文 // 这是注释，这就有点尴尬——代码里的注释翻成中文在技术文档里往往不是好事。还好有道在翻译后保留了原始格式，你可以选择性地把代码块的翻译删掉。
建议： 翻译技术文档前，确认"是否翻译代码块"选项。有道桌面版有这个设置（虽然是隐藏的），网页版默认会翻代码注释。
学术论文：双栏排版是个坑
第二篇是 NeurIPS 格式的机器学习论文，双栏排版，含 8 个数学公式和 35 条参考文献。
上传后 48 秒完成翻译（12 页，文件不大）。
排版问题来了——双栏论文翻完后，左右栏的文字流被打乱了。左边第一段翻成中文后变长了 40% 左右——这很正常，中文表达同样内容通常比英文长——但排版引擎没有智能调整栏宽，导致左栏文字溢出到了右栏的位置。
解决办法是用有道翻译的"下载译稿"功能。下载后会得到一个中英对照的 Word 文档，你在 Word 里手动调整一栏宽度就行。不算优雅，但能用。
数学公式全部保留了——这一点很好。有道没有把 f(x) = wx + b 翻译成中文（那是灾难），而是智能识别公式块并原样保留。
参考文献的格式有些小问题。APA 格式的引用——比如 [1] Smith, J. (2024). Machine Learning...——作者名"Smith"被保留（好），但年份后的点号和期刊名前的逗号在翻译后变为了中文全角标点。如果这篇翻完的论文是要在中文语境下引用，不影响阅读。如果要作为英文论文的中文附录，需要手动校对标点。
建议： 翻双栏论文前，先把 PDF 转成单栏纯文本（用 Adobe Acrobat 或在线工具），翻完后再排版。多花 5 分钟，省下校对 2 小时。
法律合同：精度够不够
第三篇是一份英文 NDA（保密协议）模板，8 页，充满法律术语。
这个测试的关键问题不是排版——合同排版通常很简单——而是法律术语的翻译精度。翻错一个字，合同意思可能完全不同。
测试结果：整体 OK，但有两处值得注意。
“indemnification” 被翻成了"赔偿"，在法律语境下不够精确——应该是"赔偿保证"或"补偿"。普通读者可能看不出区别，但法律从业者会觉得不够严谨。
“severability” 被翻成了"可分割性"——这个翻得很准确，属于法律术语的标准译法。
建议： 用有道翻译合同类文档是完全可行的，前提是翻完后必须人工审校一遍。如果你不需要法律级别的精确度（比如只是想大致理解一份英文合同的内容），直接看翻译版就行。如果你需要这份翻译作为正式用途——请律师再审一遍。
这个建议同样适用于 有道翻译准确率深度评测 里面提到的所有场景——机器翻译辅助效率，人工审校保证质量。
日文产品说明书：日翻中比英翻中差多少
第四篇测试了非英文的文档——一份 Canon 相机的日文说明书。
日文翻中文的质量明显比英翻中差一截。不是翻译本身的问题，而是日中机器翻译的技术积累本来就不如英中。
具体问题：日语里的大量片假名外来语（比如 “フォーカス” 来自英文 focus）被有道直接保留了假名形式而不是翻译成"对焦"。用户看了一半突然冒出几个没翻的假名单词，体验断档。
但实用信息（操作步骤、警告提示、规格参数）基本准确。如果你需要快速看懂一份日文说明书的操作步骤——尤其是"请先关机再插入存储卡"这类安全提示——有道的日翻中完全能胜任。句子级别的意思不会错。
省时组合拳：不同场景的最优翻译流程
看了四个场景的实测，下面是每种场景的最高效工作流：
想快速理解一份英文报告：直接上传 PDF，不要管排版细节。有道翻译后的阅读质量足够你掌握 95% 以上的信息。5 分钟搞定。
需要引用和分享给同事看：先翻译，再下载双语 Word 文档，在 Word 里花 10 分钟调一下表格宽、修一下丢掉的标点。出来的成品完全能分享。
需要正式提交（比如毕业论文的外文翻译附录）：分两步走。第一步用有道把全文翻译一遍获取初稿。第二步逐段人工审校并对照原文修改——这个过程不可避免，也没有任何机器翻译工具能跳过这一步。
需要翻译大量文档批量处理：付费用有道的 API 版本（非网页版和桌面版），配合 Python 脚本批量上传翻译，效率比手动上传高 10 倍。30 份文档 2 小时内搞定，人工只需要最后校对。
跟直接复制粘贴到 有道翻译的网页版 对比，文档翻译的核心优势是一次性、不断点。网页版一段一段贴，贴到第 10 页你就想放弃了。
和同类工具的横向感受
我用相同的四份文档也跑了 Google 翻译和 DeepL 的文档翻译做对比：
Google 翻译的文档翻译速度最快（28 页白皮书 1 分 12 秒），但对中英技术术语的处理不如有道——Google 把"availability zone"翻成了"可用性区域"（有道是"可用区"，更接近行业惯用译法）。
DeepL 在学术论文场景表现最好——数学公式识别率和排版保持都优于有道和 Google——但 DeepL 的免费版不支持大文件（限制 5MB 且每月只有 3 篇），而且不直接支持日文翻中文。
如果你主要翻英中技术文档：有道。如果主要翻学术论文且不差钱：DeepL。如果偶尔用、需要多语言：Google 翻译。具体情况看 有道翻译 vs 竞品对比 页面，有更细的维度拆解。
大部分人都忽略的三个实用设置
一、术语库。有道翻译桌面版支持自定义术语库——你可以上传一份中英对照术语表，翻译时会优先使用你定义的译法。这个功能在翻译技术文档时极其有用。比如你定义 bucket → 存储桶 而不是默认的"桶"，整篇都不会出现不一致的翻译。
路径：有道翻译桌面版 → 设置 → 翻译设置 → 术语库管理 → 上传 CSV 文件。
二、翻译记忆。如果你重复翻译相似文档（比如每月都要翻一份格式差不多的月报），有道的翻译记忆功能会记住你上次的翻译结果，下次类似内容自动使用同样译法。这个对保持术语一致性很有帮助——比一遍遍手改省太多时间。
三、导出格式。有道文档翻译支持导出三种格式：双语对照 Word（推荐）、纯中文 PDF、纯中文 Word。大部分人只下载第一种。但如果你需要把中文版发给只读中文的老板看，直接下载纯中文 PDF 是最快的——排版已经帮你调好了，不用自己折腾。
最后说一句：作为 有道产品中文使用指南站，我们的建议是——文档翻译不是万能的，排版偶尔会乱，术语偶尔翻得不一致。但这不妨碍它把一次 80 页 PDF 的翻译工作从 3 天压缩到 3 分钟，然后你只需要花 2 小时审校——而不是从头翻译。