讲个常见的场景：做过技术文档翻译的人，十有八九都遇到过——一段英文翻成中文，术语没错，句子通顺，语法也挑不出毛病，但读起来就是哪里不对劲。

举个很典型的例子。“该 API 允许开发者对数据进行操作”，这是从 “perform operations on data” 逐字搬过来的。意思不能说错，但中文技术文档里很少这么写。更自然的说法通常是“该接口用于访问和管理数据”。

问题不在翻译本身，而在于译文只做到词语和句式的表面对应，没有转换成中文技术文档习惯的表达方式。

一个可行的办法就是，把翻译拆成两个独立阶段，各干各的，互不干扰。先让一个模型检查译文的准确度，确认技术参数、术语和逻辑关系都没变；再让另一个模型以中文技术编辑的视角优化表达，不动事实，只消除生硬的直译痕迹。

下面就用一段英文技术文档来演示，两个模型如何分工配合。

输入材料：一段需要优化的技术译文

先看这次用的材料。下面是一段英文运维手册，以及逐句翻译后得到的中文译文。初步译文在术语和事实上都没问题，但明显保留了英文原文的句式结构。

英文原文：

To ensure system stability during peak hours, it is recommended that
database connection pooling be enabled. Connection pooling allows
applications to reuse existing database connections rather than
establishing new ones for each request, which significantly reduces
overhead. When configuring the pool size, consider both the expected
concurrent user count and the a vailable database server memory.

初步译文：

为了确保系统在高峰时段的稳定性，建议数据库连接池被启用。连接池允许
应用程序重用现有的数据库连接，而不是为每个请求建立新的连接，
这显著减少了开销。当配置池大小时，要考虑预期的并发用户数量和
可用的数据库服务器内存。

这段译文的问题主要集中在三个地方。

“建议数据库连接池被启用”直接保留了英文的被动语态。中文技术文档通常会直接写成“建议启用数据库连接池”。

“这显著减少了开销”中的“这”指代不够明确。读者需要回看前半句，才能确认它指的是复用已有连接，而不是其他操作。

“当配置池大小时”则是对 “When configuring the pool size” 的逐字翻译。中文通常会省略“当”，直接写成“配置池大小时”。

这些句子并非翻译错误，但连在一起时，会让译文明显带有英文句法的痕迹。

处理流程：先锁定准确度，再优化表达

这次由 DeepSeek-R1 检查技术信息是否准确，再由 Gemini 3.5 Flash 优化中文表达。

两个模型的任务边界很清楚： DeepSeek-R1 只核对术语、事实和逻辑关系，不评价语言风格； Gemini 3.5 Flash 只在事实已经确认无误的基础上调整表达，不改变原文含义。

这样处理的好处是，准确度核查和语言优化不会混在一起。发现问题时，也更容易判断问题来自事实偏差，还是中文表达不够自然。

第一阶段：用 DeepSeek-R1 锁定准确度

DeepSeek-R1 是 DeepSeek 系列中针对深度推理进行优化的版本，于 2025 年 5 月发布，幻觉率降低 45% 至 50%。

在这个阶段，DeepSeek-R1 的任务不是重新翻译，而是逐句对照英文原文和初步译文，确认其中的技术术语、建议程度和逻辑关系是否一致。

提交英文原文和初步译文，使用以下核查 Prompt：

请逐句核对以下英文原文和中文译文，检查译文中的技术信息是否与原文严格一致。

核查范围：
1. 数字和参数名；
2. 技术术语；
3. 因果关系和条件关系；
4. 建议、要求、禁止等语气强度。

不评价译文的表达质量，只检查技术信息准确度。

英文原文：
[此处粘贴英文原文]

中文译文：
[此处粘贴初步译文]

将核查范围拆开后，模型需要分别确认术语和逻辑，而不是笼统地判断“翻译是否正确”。加入“不评价译文的表达质量”，则可以避免核查结果被措辞建议占据。

DeepSeek-R1 的核查结果显示，初步译文中的关键技术信息与原文一致：

• database connection pooling 对应“数据库连接池”；
• pool size 对应“池大小”；
• overhead 对应“开销”；
• it is recommended that 表达的建议关系得到保留；
• which significantly reduces 表达的因果关系没有发生变化；
• 原文没有数字和具体参数，译文也没有自行增加相关内容。

至此可以确认，初步译文的问题只在表达方式，不涉及技术事实。下一阶段可以在这个基础上调整句式。

第二阶段：用 Gemini 3.5 Flash 优化中文表达

确认准确度后，切换到 Gemini 3.5 Flash。 Gemini 3.5 Flash 于 2026 年 5 月发布，是首款融合前沿智能与快速行动的模型。

这一步需要同时提交英文原文、初步译文和 DeepSeek-R1 的核查结果。英文原文用于确认语义边界，初步译文是待修改对象，核查结果则标明了不能改变的技术信息。

使用的优化 Prompt 如下：

你是一位中文技术文档编辑。请在不改动任何技术事实的前提下，
优化以下译文的中文表达。

优化原则：
1. 将英文被动语态转换为自然的中文主动表达；
2. 将英文长句调整为中文技术文档常用的句式；
3. 消除“当……时”“这……”等生硬的直译痕迹；
4. 保持技术文档的严谨性，不使用口语化或营销化表达；
5. 不改变术语、因果关系、条件关系和建议程度；
6. 对无法确定的内容保留原译，并说明原因。

英文原文：
[此处粘贴英文原文]

初步译文：
[此处粘贴初步译文]

准确度核查结果：
[此处粘贴核查结果]

Gemini 3.5 Flash 给出的优化版本如下：

为确保高峰时段系统稳定性，建议启用数据库连接池。连接池允许
应用程序复用已有数据库连接，避免每次请求都建立新连接，
从而大幅降低系统开销。配置池大小时，需同时考虑预期并发
用户数量和数据库服务器的可用内存。

这个版本主要做了四处调整。

“建议数据库连接池被启用”改为“建议启用数据库连接池”，把英文被动语态转换成了中文更常用的主动表达。

“这显著减少了开销”改为“从而大幅降低系统开销”，不再使用指代模糊的“这”，同时保留了复用连接与降低开销之间的因果关系。

“当配置池大小时”改为“配置池大小时”，删除了直译产生的冗余连接词。

“要考虑”改为“需同时考虑”，语气更加简洁，也更符合中文技术文档的表达习惯。

优化前后对照

几个关键句子的调整如下：

DeepSeek-R1 在第一阶段确认技术信息无误， Gemini 3.5 Flash 在第二阶段将逐字对应的句式调整成自然的中文表达。

两个环节各自处理一个问题：核查阶段不评价语言风格，优化阶段不改动技术事实。

如何验收优化结果

完成表达优化后，可以按照以下清单逐项检查：

验收时不能只看译文是否流畅。技术译文即使读起来很自然，也可能在优化过程中改变原文的语气强度。

例如，原文中的 “recommended” 表示建议，如果改成“必须”，就会把建议升级为强制要求。类似的变化不属于表达优化，而是事实和逻辑层面的偏差。

处理时需要注意的问题

首先是原始材料的脱敏。

如果需要翻译内部技术文档，在提交给任何模型之前，都应删除或替换内部域名、服务器地址、访问凭据、客户信息和未公开参数。本次使用的是公开运维文档片段，不涉及内部信息。

其次是准确度核查的范围。

除了数字和术语，还需要检查条件、因果关系以及语气强度。“可以”“建议”“应该”和“必须”在技术文档中的含义并不相同，不能在优化时随意替换。

最后是优化边界。

Gemini 3.5 Flash 的任务是在不改变事实的前提下让中文表达更加自然。如果某个句子同时存在事实疑问和表达问题，应先返回准确度核查阶段，确认原文含义后再继续优化，不能依靠语言润色掩盖语义上的不确定性。

在这套流程中，DeepSeek-R1 提供了表达优化所需的准确度基础，Gemini 3.5 Flash 则负责解决直译句式、模糊指代和表达生硬等问题。

可以在同一个工作区中切换模型，原文、初步译文和核查结果仍然保留在当前上下文中，可以直接继续处理。

总结

技术译文“内容都对，但读起来像机翻”，通常不是术语或语法出了问题，而是英文句式被原样带进了中文。

解决这个问题时，可以先用 DeepSeek-R1 核对术语、事实和逻辑关系，再用 Gemini 3.5 Flash 从中文技术编辑的角度调整表达。前者确保内容没有偏差，后者负责消除直译痕迹。

这套方法适用于技术文档、API 文档、运维手册和产品说明等同时要求准确度与可读性的内容。实际使用时，可以把准确度核查 Prompt 和表达优化 Prompt 保存为模板，再根据具体文档补充术语表、语气规范和禁止改动的内容。