企业官网建设流程全解析

读外文 PDF 这件事，几乎每个做技术、做研究、做外贸单证的人都绕不开。真正让人头疼的从来不是“看不懂”，而是看得懂却读得慢：一篇三十页的双栏论文，公式、图表、脚注、参考文献层层嵌套，复制一段正文丢进翻译框，出来的是公式炸成乱码、段落顺序彻底打乱、上下标全丢的残骸。想要一份既保留原版排版、又能读懂意思的译本，过去要么靠人工重排，要么忍受整页截图 OCR 出来的错字。pdf2zh 这类工具之所以在圈子里被反复提起，核心就在于它把“解析—翻译—重排”这条链路做成了可复用的流水线，输出的是排版基本忠实原文、公式和表格不散架、还能同时给你单语版和双语对照版的两个 PDF。这篇内容我打算从安装环境一路讲到参数调优和踩坑排查，面向的是手上有英文文献、技术手册、外文标准文档需要处理的人：刚入门的小白能照着命令直接跑通，已经用过一两次、觉得效果时好时坏的老手，也能在后半部分找到排错思路和成本估算方法。

1. PDF 翻译的真正难点：卡住的是复原，不是翻译

1.1 复制粘贴为什么永远做不好这件事

很多人对 PDF 翻译的第一层误解，是把它当成“文本翻译问题”。实际上 PDF 从诞生那天起就不是为了承载“文本”而设计的，它承载的是“绘制指令”。你在阅读器里看到的一段话，在文件内部可能被拆成几十个独立的文本块，每个块带着自己的坐标、字体、字号、旋转角度、字距微调。阅读器按坐标把这些块画到页面上，肉眼看上去是连贯的段落，可一旦你选中复制，取出来的顺序取决于文件里对象的排列，而不是视觉上的阅读顺序。这就是为什么双栏论文复制出来经常左右栏串行，也是为什么公式里的积分号和上下限会跑到句子末尾去。

更麻烦的是字体子集。生成 PDF 时，很多软件只嵌入用到的字符子集，并且把字符编码改成自定义映射。你复制出来的“文本”，在文件里可能压根不是 Unicode，而是一串私有编码。这类文件在翻译工具里会直接变成方块或者乱码，跟翻译质量毫无关系，纯粹是取词环节就断了。理解这一层，你就能明白后面所有工具选型的逻辑：谁能把 PDF 的“版面结构”还原出来，谁才有资格谈翻译质量。

1.2 pdf2zh 的处理链路拆成三段看

pdf2zh 的定位是命令行工具，思路可以拆成三段来看。第一段是版面解析，把 PDF 页面拆成若干“可翻译单元”，同时识别出哪些区域是不可动的——图片、矢量图形、公式块、表格线框。这一步决定了后面排版能不能保住。第二段是文本翻译，把每个单元的文本内容送去翻译后端，这里的后端是可插拔的，你可以接在线通用翻译接口、也可以接大模型接口、还可以接本地推理服务。第三段是重排与回写，把译文按原单元的边界框重新塞回页面，字号不够就缩、行数变多就调行距，实在放不下就溢出到旁边的空白区。

这个设计和“整页扔给 OCR 再整页重新排版”是两条完全不同的路。后者的产物是一篇新文档，版式跟原文没关系了；前者的产物是“原文的替身”，你翻到第 12 页看到的图 3，跟原文第 12 页的图 3 是同一个位置。做文献综述的人应该能立刻体会到这个差别的价值：引用页码、对照图表、跟同行讨论“你看第三页那个式子”，全都不需要重新建立坐标。

1.3 几类常见方案摆在一起比一比

表格里最后一行才是这篇要展开的主角。它的优势不在于翻译得更“信达雅”，而在于它知道哪些东西不该动。公式、化学结构式、电路图、流程框图，这些内容一旦被当成文本送去翻译，结果必然是灾难；把它们识别为图形区域原样保留，反而让译文可用性大幅提升。

2. 环境准备：三条安装路线与选型逻辑

2.1 路线一：用包管理器直接装

最省事的路径是用 Python 的包管理工具从包索引仓库拉取。我一般推荐用 uv 而不是裸 pip，原因是这类工具依赖树不小，uv 的解析和缓存速度快很多，装完不会把全局环境搞脏。基本形态是先建一个独立虚拟环境，再在里面安装：

uv venv .venv source .venv/bin/activate uv pip install pdf2zh

Windows 下激活脚本换成对应目录下的可执行文件即可。装完直接敲pdf2zh --help，能打出帮助信息就说明入口脚本挂上了。这一步最容易出问题的地方是 PATH：如果提示找不到命令，多半是虚拟环境没激活，或者脚本装进了用户级目录但那个目录不在 PATH 里。我的习惯是永远在项目目录下建虚拟环境，不搞全局安装，出问题直接删目录重来，比排查依赖冲突快得多。

如果你的机器上有多个 Python 版本，务必确认虚拟环境用的是 3.10 以上。低版本在解析某些用了新语法特性的依赖时会直接报错，而且报错信息往往指向一个跟你操作毫无关系的模块，很容易让人误判。

2.2 路线二：容器化运行，隔离依赖

当你的系统里已经有一堆互相打架的 Python 环境，或者需要在多人共用的服务器上跑批量任务，容器方案会更稳。思路很简单：拉一个带完整运行时的镜像，把本地 PDF 目录挂载进容器，命令照常在容器里执行。好处是依赖全部封在镜像内，不会污染宿主机；坏处是要处理文件权限和挂载路径映射，尤其是输出目录的写权限，Linux 下经常出现容器里写出来的文件属主是 root、宿主机上改不动的情况。

处理办法是在启动容器时显式指定用户 ID 和组 ID，或者在跑完之后统一改一次权限。这一点看着琐碎，但在做几百篇批量翻译时很关键——脚本跑到一半因为写不进文件而中断，排查起来相当浪费时间。

2.3 硬件门槛到底卡在哪一步

很多人以为这类工具吃显卡，实际测下来，纯翻译流程里最耗资源的是版面解析那一步的模型推理。如果你只用在线翻译后端，显卡不是必需品，CPU 也能跑，只是慢；一份三十页的论文，用中端 CPU 大概几分钟到十几分钟量级，具体取决于页面复杂度和是否启用了额外的版面识别能力。

真正需要显卡的场景是“翻译后端也放在本地”——也就是大模型推理自己扛。这时候显存需求取决于模型规模，七 B 级别的量化模型在消费级显卡上能跑，但吞吐很低，几十页文档排着队跑一晚上是常态。我的建议很明确：先把在线后端跑通，确认整条链路和输出效果符合预期，再考虑本地化。上来就折腾本地部署，很容易在环境问题上耗掉全部耐心，连工具本身好不好用都没验证到。

另外提醒一句，磁盘空间要留够。解析中间产物、字体子集、双份输出文件，一篇论文占几十兆是正常的，批量处理时临时目录很快就能吃满。

3. 翻译后端选型：质量、速度、成本的三方权衡

3.1 三类后端的能力边界

pdf2zh 把翻译后端做成了可切换的插件式结构，通过参数指定用哪一家。粗分下来是三类。第一类是通用在线翻译接口，特点是快、便宜甚至免费、术语稳定，但长句处理和上下文中的人称、被动语态转换比较死板，遇到专业术语经常给出通用领域的释义。第二类是大模型接口，长句连贯性和术语理解明显更好，能根据上下文把缩写还原成完整表达，代价是按量计费，长文档成本会累积。第三类是本地推理服务，把模型跑在自己机器上，隐私最好、长期成本最低，但首次部署麻烦、速度受硬件制约。

我的实际搭配是这样的：正文类、叙述性强的章节用大模型后端；参考文献列表、附录的表格、参数表这类内容用通用接口批量过一遍就够了，没必要为了一堆数字和作者名付费。工具本身支持按页码范围分段处理，你可以把同一篇文档拆成两三次跑，分别指定不同的后端，最后手动合并——虽然麻烦一点，但在成本敏感的场景下很值得。

3.2 成本估算怎么算才靠谱

按量计费的后端，成本取决于字符数而不是页数。经验值是一页标准双栏论文的正文大约三千到五千字符，含公式和图表说明的页面会少一些。这里有个换算要提醒：中文译文的字符数通常比英文原文少三到四成，但计费一般按输入输出双向算，所以别只按原文长度估。

粗算公式是这样：总成本约等于（输入字符数 × 输入单价）加上（输出字符数 × 输出单价），其中输出字符数按输入的 0.7 倍估。一篇三十页的文档，字符量在两万到十万之间浮动，具体看排版密度。跑之前建议先拿前五页试一次，看看实际消耗，再决定要不要全量跑。我见过有人一口气把几百页的手册扔进去，结果账单出来才发现里面的目录和索引页占了将近三成字符，纯属浪费——这类页面完全可以跳过不翻，或者用页码参数把它们排除掉。

3.3 术语一致性靠术语表，不靠模型自觉

翻译长文档最怕的是同一个术语前后译法不同。第二章叫“吞吐量”，第五章变成“通过量”，读者会很困惑。指望模型自己保持一致是不现实的，每一段都是独立请求，它看不到前面译过什么。解决办法有两个：一是准备一份术语对照表，在支持自定义提示的后端里把这些固定映射塞进去；二是先在文档里做一次全文检索，把核心术语列出来，翻译完成后逐一检查译法是否统一，发现偏差就批量替换。

第二种办法笨但有效。我处理技术手册时一般会先花十分钟把出现频率最高的二十个术语抓出来，做成一个简单的替换脚本，译完之后跑一遍。这一步的收益比调任何参数都高，因为它直接影响可读性。特别注意产品名、型号、单位符号——型号通常不该翻译，单位符号要保持原样，这两个地方被“翻译”了会闹笑话。

4. 核心参数逐个拆解：一条命令跑通一篇论文

4.1 最小可用命令和它产出的东西

最精简的用法就是给一个输入文件：

pdf2zh paper.pdf

默认行为是按配置里的源语言和目标语言处理全文，在输入文件同目录下生成两个 PDF：一个单语版（原文内容被替换成译文），一个双语版（通常是原文与译文对照，或者是译文按段落附在原文旁）。文件名一般带后缀区分，比如paper-mono.pdf和paper-dual.pdf。

我一开始也不理解为什么要出两份。用久了才体会到这两个版本的用途完全不同：单语版适合通读和打印，页面干净；双语版适合精读和校对，尤其是你需要确认某个技术细节的原始表述时，能立刻左右对照。做技术文档审校的人应该会喜欢双语版，因为术语翻译有争议时可以直接看原文。

4.2 语言对和页码范围：两个最常用的开关

语言对通过两个参数指定，一个是源语言，一个是目标语言，用语言代码表示，比如英文到中文就写-li en -lo zh。源语言尽量别偷懒写自动检测，虽然工具可能支持，但检测错一次整篇就白翻了。中文和日文、韩文之间有大量共用汉字，自动检测在这几种语言上翻车概率不低，明确指定最保险。

页码范围参数用来只处理某几页，接受单个页码或者区间，多个区间可以用逗号分隔。这个参数的价值被严重低估了。它至少有三个用途：试跑验证效果、跳过封面目录和参考文献、把超长文档拆成几段分别处理。我处理一百页以上的手册时，习惯按章节拆成五到八段，每段跑完立刻检查，发现问题只重跑那一段，不用整篇重来。

pdf2zh manual.pdf -li en -lo zh -p 1-20 -o ./out

4.3 输出目录、并发数和排版保留相关的开关

输出目录参数决定产物落在哪，批量处理时一定要显式指定，否则文件散落在各处很难管理。并发参数控制同时处理的任务数，默认值偏保守，页码多的文档可以适当调高，但要看你用的翻译后端有没有速率限制——免费接口调太快通常会被限流，表现是大量请求失败或者返回空内容。

排版相关的开关里，最值得关注的是字体处理。译文用的是中文字符，而原 PDF 里嵌的英文字体不包含这些字形，工具需要做字体替换或者追加字体子集。这里常见的坑是：某些 PDF 用了特别刁钻的嵌入方式，替换后中文显示成方块或者豆腐块。遇到这种情况，先试试换一个字体参数，指定一个系统里确定存在的字体；如果还不行，就考虑放宽对排版的要求，让它以更宽松的方式重排。

还有一个容易忽略的点是公式保护。部分版本对公式区域的处理方式是识别为图形后原样保留，这个行为通常不需要额外配置，但如果你发现某些行内公式被当成普通文本翻译了，说明版面解析没识别出来，可以考虑先用 PDF 编辑工具把那几行标记出来单独跳过，或者在参数里调整识别灵敏度。

4.4 批量处理：写个循环比什么都实在

工具本身不一定带批量目录扫描，但写个 shell 循环就够了：

mkdir -p ./out for f in ./papers/*.pdf; do name=$(basename "$f" .pdf) pdf2zh "$f" -li en -lo zh -o ./out -p 1-40 echo "$name done" done

这个脚本加了进度回显，跑批量时很重要——几百个文件排队处理，没有输出你根本不知道跑到哪了。更进一步可以加错误捕获，把失败的文件名记到一个日志里，跑完统一重试：

for f in ./papers/*.pdf; do if ! pdf2zh "$f" -li en -lo zh -o ./out 2>> ./error.log; then echo "$f" >> ./failed.txt fi done

批量处理还有个隐形问题：命名冲突。如果两个子目录里有同名文件，输出会互相覆盖。解决办法是把输出路径带上原目录的相对路径，或者干脆一个文件一个输出子目录。

5. 实操现场：一篇双栏论文从解析到成品的全过程

5.1 第一步：先判断这份 PDF 有没有文本层

拿到任何 PDF，我的第一个动作不是直接跑翻译，而是用阅读器试着选中一段正文复制出来。能复制出通顺的英文，说明有文本层，走正常流程；复制出来是空白、或者是一堆乱序字符、或者压根选不中，那就是扫描件或者字体编码有问题的文件，得先做预处理。

扫描件的处理路径完全不同：需要先做 OCR 把文字层叠加上去，再交给翻译工具。这一步的识别质量直接决定最终效果，因为版面解析看到的是 OCR 给出的文字块。中低质量的 OCR 会把1和l、0和O搞混，专业术语更是错得离谱，翻译出来自然一塌糊涂。我的经验是扫描件先花点时间做一次高质量 OCR，比事后修译文省力得多。

5.2 第二步：解析阶段到底发生了什么

跑起来之后，工具先做的是页面元素分类。它需要判断哪些区块是正文段落、哪些是标题、哪些是图注、哪些是表格。双栏排版在这里是个考验，因为一页里有左右两条独立的阅读流，解析器必须先把栏分开，再在每栏内部按纵向顺序拼接段落，否则就会串行。

这一步出错的表现很有特征：译文读起来像是把左右两栏的行交替拼在一起，语义完全断裂。遇到这种情况，先确认原 PDF 是不是用了非常规的分栏方式，比如三栏、或者栏内还有嵌套的文本框。有些期刊的排版确实会玩花样，工具识别不了属于正常现象，这时候可以考虑把页面裁切后分栏处理。

表格是另一个难点。工具一般会把表格整体识别为一个不可翻译区域而原样保留，这其实是合理的策略——表格里的文字如果被逐格翻译，列宽会全部崩掉，反而更难读。所以我处理含大量表格的文档时，心理预期就是“表格保留原文，正文翻译”，需要读懂表格内容时再单独处理。

5.3 第三步：译完之后怎么校对效率最高

全篇逐字校对是不现实的，我的做法是分层检查。第一层看结构：翻到中间几页，确认图表位置没偏移、页码对得上、目录条目还在。第二层看关键段落：摘要、引言最后一段、方法部分的核心描述、结论——这几处的翻译质量基本能代表全文水平。第三层看术语：把事先列出的高频术语在译文里搜一遍，确认译法统一。

双语版在这里的价值就体现出来了。读到某句译文觉得别扭时，直接对照原文，判断是译文生硬还是原文本身表述就绕。有些英文长句是作者故意写得复杂，译文跟着复杂其实是对的，不该改；有些是模型没理解从句关系，那就需要人工介入。分得清这两种情况，校对效率能提高一大截。

5.4 成品验收清单

跑完之后我会按这几项过一遍，任何一项不过关就回到相应环节调整：

• 页数与原文一致，没有缺页或多页
• 图表位置与原文对应，编号未错乱
• 公式区域未被翻译，仍为原始图形
• 中文字体渲染正常，无方块、无重叠
• 段落顺序符合阅读逻辑，双栏未串行
• 页眉页脚、页码未被误翻
• 参考文献列表的处理方式符合预期

最后一项要特别说明。参考文献里的作者名、期刊名、年份，翻译了反而是负担。有些版本默认会跳过参考文献区域，有些不会。如果发现被翻了，用页码范围把它排除掉最省事。

6. 踩坑实录与排查速查表

6.1 安装和启动阶段的典型故障

安装问题九成出在环境不干净。我的固定做法是每接一个新任务就新建一个项目目录，虚拟环境建在里面，跑完整个目录归档，下次要用直接复用，不跟别的项目混。

6.2 翻译阶段的失败模式

最常见的是请求失败。表现是部分页面译文为空、或者整篇只翻了前几页就停住。原因通常有三类：后端接口限流、密钥额度耗尽、网络请求超时。排查顺序是先看日志里的错误码，再手动发一个最小请求验证后端是否可用，最后调低并发数重试。并发数这个参数是双刃剑，调高能提速，但免费额度下很容易触发限流，反而更慢。

第二类是译文质量断崖式下跌。同一篇文档，前面翻得好好的，后面突然变成机翻腔。这种情况多半是中途切换了后端，或者某个后端额度用尽自动降级了。跑长文档时建议盯着日志，确认全程用的是同一个后端。

第三类是重复翻译或漏翻。页面里如果有跨页的段落，解析器可能把它当成两个独立单元，各翻一遍，读起来就是重复。这种只能人工处理，找到位置删掉一段。

6.3 版面错乱的三种成因和对策

版面问题是最影响观感的，按成因分三种。第一种是文本框溢出：译文比原文长，塞回原来的框里放不下，字号被缩到极小或者文字压到图形上。对策是允许工具在必要时扩展文本框，或者干脆接受稍微宽松的排版，别死抠原位置。第二种是阅读顺序错乱：双栏、多栏、侧边栏混排时容易发生。对策是预处理阶段把侧边栏、注释区裁掉，只留主内容区。第三种是字体缺失：中文渲染成方块。对策是指定一个确定存在的字体文件。

6.4 扫描件和特殊文档怎么处理

扫描件的预处理顺序是：先 OCR 加文字层、再检查文字层质量、最后翻译。OCR 阶段建议保留原始图像层，只叠加文字，这样翻译工具做版面解析时还能看到原始的图形边界。纯图像 PDF 直接翻译，结果基本不可用。

还有一种特殊情况是加密 PDF。有编辑权限限制的文件，工具读不了内容，得先用其他手段解除限制。这类操作要注意文件的来源和使用授权，只处理自己有权限处理的内容。

7. 进阶：把这个工具接进日常工作流

7.1 图形界面和脚本化的取舍

这个工具有一个内置的本地网页界面，启动后浏览器打开就能用，上传文件、选参数、点按钮，适合偶尔用一次的场景。但我更推荐把命令行跑熟，原因是可复现、可批量、可写进脚本。网页界面每次都要手动选一堆参数，跑十篇文档就是十次重复劳动；命令行写成一个函数，传文件名进去就行。

7.2 和笔记、阅读器配合的用法

我的工作流是这样的：新收到一篇文献，先跑双语版，快速扫一遍判断值不值得精读；值得精读的，把单语版导入阅读器做标注，标注时遇到术语疑问再回查双语版；标注完的内容整理进笔记系统，术语和关键结论单独摘出来。这套流程里，翻译只是第一道粗筛，真正的价值在于它把“读不读”这个决策的成本降到了几分钟。

如果你的阅读器支持按页跳转和书签，建议在翻译前给原文加上章节书签，输出的译本一般会继承这些结构，后续定位会方便很多。

最后分享一个我自己反复验证的小技巧：处理不确定效果的文档时，永远先用页码范围跑前三页，看完再全量。这三页的成本几乎为零，但能帮你提前发现字体问题、栏位问题、后端问题——比跑完三十页再返工划算太多。另外，术语表这件事值得养成习惯，每处理一个新领域就积累一份，攒到第三份的时候你会发现，译文质量的天花板其实是由术语一致性决定的，而不是由你选了多贵的翻译后端。