翻译文档最气人的，不是翻得准不准，是翻完之后排版炸了。表格错位、编号乱跳、字体忽大忽小、标题层级全平——明明内容对了，成品却像被揉过一遍。我用千问办公翻过产品手册、技术白皮书、合同附件，踩过不少坑，也摸出了几条真正管用的法子。这篇就讲：中英互译时，怎么把表格、字体、编号这些「面子工程」稳稳保住，外加术语表怎么用才不闹笑话。指令都给你写好了，复制改改就能用。
先认清一个现实：翻译和排版是两件事
很多工具（包括大多数通用翻译）的逻辑是「读文字→翻文字→吐文字」，它眼里只有句子，没有「这是表格第二行第三列」。所以排版崩，不是它笨，是你让它干了它不擅长的事。千问办公处理整本文档时，通常能保留一定的结构（具体以官网当前显示为准），但要稳，你得主动给它「保排版」的指令和方法。
核心思路一句话：要么让它在原结构里改字，要么先抽结构再回填，要么分块喂、各自保。 下面三种做法按「省事程度」从省到稳排列，你按文档重要程度挑。
做法一：锁定结构，只换文字（最省心）
适合场景：Word / 在线文档里表格规整、编号用的是自动列表的文档。
指令关键在「不要动结构」四个字：
请将以下文档从中文翻译为英文（或反之）。
严格要求：
1. 只替换文字内容，绝对不要改动任何表格结构、行列数、标题层级、编号顺序
2. 保留所有原有的加粗、列表、标题样式标记
3. 如果某处不确定，原样保留并标注 [待核]，不要擅自改写
4. 输出时保持与原文档完全一致的段落和表格布局为什么强调「自动编号」？因为手动敲的「1. 2. 3.」模型可能当成普通文字去翻或重排，而文档自带的自动编号它一般能识别为结构、不动。所以翻译前，先把手动编号改成自动列表，这是零成本的一招。
表格同理：只要表格本身在源文件里是「真表格」（不是用空格对齐的假表格），模型大多能守住行列。最怕的是那种用制表符、空格硬凑的「伪表格」，翻完必炸——翻译前把伪表格转成真表格，能救回一半的排版事故。
做法二：先抽结构，翻译完再回填（最稳）
适合场景：排版极其复杂、表格套表格、图文混排、或者你对成品要求极高不能有任何错位。
思路是「分而治之」：
- 先把文档里的「纯文字流」抽出来（标题、正文、列表），表格单独导出
- 文字流交给模型翻译，指令同上「只翻字不动结构」
- 每个表格单独复制进对话，下指令：
这是一个表格，请逐格翻译其中文字，保持表格行列结构完全不变，
表头也要翻译，不要增删任何行列。- 翻译完手动贴回原位
这招多花 5 分钟，但换来「零错位」。我翻技术白皮书时用得最多——白皮书表格多、术语密，一旦错位，校对成本比重翻还高。
一个细节：表格里如果是数字、公式、代码，务必在指令里写「数字与代码原样保留不翻译」。模型偶尔会把 API key、v2.3.1 这类当普通词处理，加一句限制就稳了。下面这条我每次必加：
表格中的数字、版本号、代码、专有缩写一律原样保留，不翻译、不改写。做法三：分块喂、各自保（最长文档的兜底）
适合场景：几十页、上百页的整本文档，一次性丢进去模型可能截断或前后术语不一致。
做法：
- 按章节拆成若干块，每块单独翻译
- 每块开头都附上同一份术语表（见下文），保证前后一致
- 每块都带「保持本节原有标题层级与编号」的指令
- 最后拼接，再整体过一遍「编号连续性检查」
请翻译以下「第3章」内容，保持原有的 ### 三级标题与 1.1 / 1.2 编号不变，
并沿用附带的术语表。分块法的好处是每块都在模型上下文里，质量更可控；坏处是要自己拼。我的经验：超过 15 页就值得分块，否则一次性也行。
术语表：翻译质量的隐藏开关
整本文档最怕的，不是翻错一句话，是同一个词翻出三个样。「用户」一会儿 user 一会儿 customer，「后台」一会儿 backend 一会儿 admin。术语表就是来治这个的。
用法很简单，翻译前先给模型一份：
翻译时请严格使用以下术语对照，全文保持一致：
- 用户 → user（不要译作 customer）
- 后台 → admin console
- 灰度发布 → canary release
- 千问办公 → （保留原品牌名不译，或按官网英文名）
- SaaS → SaaS（不翻译）几点心得：
- 品牌名、产品名、专有缩写一律列进去，并注明「不翻译」。模型最爱自作主张把品牌本地化。
- 中英互译都要有表。翻英文文档回中文时，同样要把
backend / frontend / churn这些固定成「后端 / 前端 / 流失」。 - 术语表可以让模型先帮你起草一版：「先通读文档，提取 20 个高频专有名词，给出建议中英对照，我再确认」。你确认后它再去翻，准确率明显高。
- 列表里写清「不要译作什么」比只写「译作什么」更有用，因为模型常踩的就是那几个近义词。
下面是一份我翻产品文档时常用的术语表示例，你可以照格式改：
| 中文 | 英文 | 备注 |
|---|---|---|
| 用户 | user | 禁用 customer |
| 租户 | tenant | SaaS 语境 |
| 控制台 | console | 非 dashboard |
| 灰度 | canary | 非 gray |
| 回填 | backfill | 数据语境 |
字体与样式：翻译动不了的部分
说句实话，字体、字号、颜色这些视觉样式，翻译环节基本碰不到——它们属于文档本身的格式，模型只动文字。所以「字体乱了」通常另有原因：
- 目标语言字符集不同（比如中文文档翻成纯英文后，原来设的中文字体在英文下回退成了别的字体）→ 翻完后在文档软件里统一重设一遍西文字体即可，不是翻译的锅
- 源文档本来就是「伪格式」（用空格对齐、用截图当表格）→ 这才是真凶，翻译前先规整
结论：翻译保的是「结构」和「文字对应关系」，保不了「视觉样式」。视觉样式靠你在源文件里用真格式 + 翻译后统一刷一遍字体。把这两层分清，就不会白生气。
翻完必做的三道校检
不管用哪种做法，成品到手我必跑三条：
- 编号连续性：让模型或自己检查「1. 2. 3.」有没有断、层级有没有跳
- 表格对账：每个表格行列数是否和原文一致，有没有多/少一格
- 术语一致性：搜一下核心术语，确认全文统一
请核对译文：① 所有自动编号是否连续无缺；② 各表格行列是否与原文一致；
③ 术语表中词汇是否全文统一。列出不一致处。我把这道校检叫「三查」，基本上能拦住九成的排版事故。尤其是表格对账，肉眼扫容易漏，让模型逐表数行列反而快。
实战示例：一份产品手册的翻译流程
我把上面三种做法套到一个真实场景：一份 20 页的中文产品手册，含 6 个配置表格、大量截图配文、若干代码段。我的流程是：
- 预处理：把 6 个表格确认都是真表格；截图里的说明文字提前 OCR 出来单独成段；代码段用等宽块标记
- 分块：按章节拆成 5 块，每块开头附同一份术语表（用户/user、租户/tenant、控制台/console 等）
- 翻译：每块指令都带「保持标题层级与编号、代码原样保留、沿用术语表」
- 回填：表格单独翻译逐格贴回；代码段整段跳过只翻前后说明
- 三查：编号连续性、表格行列对账、术语一致性
全程约两小时，比找翻译公司快且便宜，成品排版零错位。关键不在工具多强，在流程前置做得干净。
中英互译各自的额外坑
- 中译英：最易丢的是中文的「隐性主语」和客气缓冲，模型有时翻得太直给显得生硬；指令加「英文习惯补主语、加过渡句」
- 英译中：最易出问题的是长难句拆不开、被动语态翻成「被」字句啰嗦；指令加「拆分长句、被动转主动」
- 双语对照排版：若需要左右对照，让模型输出「原文 | 译文」两列表格，比段落穿插好校对
几个能直接抄的限制指令
下面这几条我几乎每次都叠在翻译指令后面，省得翻车：
- 不增删任何原有段落，不合并、不拆分句子以外的结构
- 代码块、URL、版本号、邮箱、专有缩写一律原样保留
- 如遇到无法确定的术语，保留原文并标 [术语待核]
- 输出用与原文一致的标题层级符号术语表的高级玩法：多文档统一
如果你要翻的是一个系列的多份文档（比如产品手册 + 用户指南 + API 文档），术语一致更关键。做法：先让模型从第一份抽术语表，确认后固定成团队术语库，后续每份都引用同一份。指令：
沿用我们固定的术语库（附上）翻译本文档，若遇到库中没有的新术语，
单独列出建议对照，不要擅自创造译法。这样三份文档翻完，客户搜「租户」不会出现一会儿 tenant 一会儿 subscriber。术语库本身也能让模型帮你维护：定期把新词追加进去。术语一致，是专业感的底线，也是机翻和人工最明显的分水岭。
翻译后的「母语感」润色
模型初翻往往「正确但生硬」。我习惯最后加一道：
以母语[英/中]者的视角通读译文，只优化表达自然度，不改动任何事实与术语，
把生硬处改得更地道，并列出你改了哪些。这步让它当「润色编辑」，能把「被提供给您」改成「为您提供」，把拗口长句拆顺。注意：润色阶段必须锁死术语，防止它为了顺把专有名词也顺没了。
什么情况别硬扛
- 图文混排、大量截图内文字的文档：截图里的字模型读不到，得先 OCR 或手动处理
- 排版本身就是伪格式且你没时间规整：老老实实先整理源文件，再翻
- 法律/医疗等零容错文档：翻译完必须真人通读，别只看结构对不对
- 需要保留批注、修订痕迹的：先确认工具是否保留这些元数据（以官网当前显示为准），否则翻完批注全没
翻译整本文档，千问办公能帮你保住大部分结构和文字，但「保排版」这件事，主动权在你给的指令和源文件的干净程度。源文件越规范、指令越具体、术语表越全，翻出来的东西就越像「人精细排过」而不是「机翻炸过」。把这三样备齐，排版保住，真的不靠运气。最后一句：翻译是手段，传达准确才是目的，别为了保排版反而放过了错别字和内容错误。