AI翻译+润色+排版：技术文档生产线的全面改造

我们团队维护着一套对外开源的技术文档（API文档+使用指南），中英双语。以前这套文档的维护是"老大难"：中文版改一次，英文版要人工翻一次（一篇2000字的文档翻译+校对要半天），排版格式还经常不统一，被用户吐槽"文档格式五花八门"。上个月我搭了一条"AI文档生产线"：翻译、润色、排版全部自动化，一篇文档的发布周期从两天压缩到半小时。这篇记录整个改造过程。

一、改造前的痛点

1. 翻译慢：人工翻译一篇2000字的技术文档，加上校对，至少半天；
2. 术语不统一：同一个词"workflow"，有人翻"工作流"，有人翻"流程"，文档里前后不一致；
3. 风格不统一：中英文版风格差异大，中文版口语化，英文版生硬，像两个团队写的；
4. 排版靠手：Markdown转HTML、代码块高亮、表格格式，每篇都要人工调一遍。

二、生产线设计：三站式流水线

我把文档生产拆成"翻译→润色→排版"三站，全部用AI+脚本自动化：

第一站：AI翻译（带术语表）

翻译不是直接丢给AI就完事，关键是术语管理。我建了一份"术语对照表"（术语表文件，约200个词条）：

| 英文 | 中文 |
|------|------|
| workflow | 工作流 |
| deployment | 部署 |
| callback | 回调 |
| idempotency | 幂等 |

翻译时把术语表一起喂给AI，要求"术语必须按表中翻译，不得自行发挥"：

请将以下技术文档翻译为英文。注意：必须严格使用术语表中的术语翻译，未列出的技术词汇保持常见译法。保持Markdown格式不变，保留代码块内容不翻译。

实测效果：加上术语表后，术语一致率从70%提到98%，这是整个改造里性价比最高的一步。

第二站：AI润色（双风格）

翻译完的英文版，我再过一遍润色站，让它按"技术文档规范"改写：句子简洁、动词开头、避免被动语态堆砌。中文版同理，按"简洁、专业、不啰嗦"的风格统一。润色站还有一个隐藏功能：检查翻译是否漏段——对比原文和译文的结构，段落数量不一致就告警。

第三站：排版自动化（脚本+模板）

排版用脚本处理，不再依赖AI（排版是确定性的活，脚本比AI更可靠）：

1. 代码块统一高亮：写了个脚本统一代码块的language标记，保证各语言高亮一致；
2. 表格格式规范：自动对齐Markdown表格、补全缺失的列分隔；
3. 构建发布：Markdown直接通过静态站点生成器（如Docsify/VitePress）构建发布，改完即上线。

三、实测效果对比

上线三周，发布了12篇双语文档，全部走这条生产线，质量和速度都稳定。

四、踩坑记录

1. 术语表不维护=白搭：第一周新词条没及时加进表里，AI按自己的理解翻了，又出现不一致。后来规定：发现新术语，当天必须更新术语表，这条纪律比AI本身更重要；
2. 翻译会"过度意译"：技术文档需要"信达雅"中的"信"优先。早期AI翻译偶尔会把技术细节"翻译没了"（比如把参数说明简化掉），后来提示词里明确"不得省略任何技术细节，宁可生硬不可丢失"；
3. 代码块里的注释会被翻译：AI偶尔把代码注释也翻译了，导致和源码对不上。修复：提示词强调"代码块内容原样保留"，加脚本检查代码块是否被改动；
4. 敏感信息：文档脱敏后才送AI处理，公司内部接口地址、密钥示例全部替换成占位符。

五、总结

这条生产线的核心思路：把"人做的判断"（术语、风格、技术准确性）留给人和规则，把"人做的苦力"（翻译初稿、排版）交给AI和脚本。术语表管准确性，提示词管风格，脚本管排版，AI只管翻译初稿——每一站都有明确的质量关卡。

改造完成后，我最大的感受是：文档团队从"翻译机器"变成了"质量管理员"，精力放在审校和术语维护上，而不是在翻译软件和排版工具之间来回切换。AI生产线的价值，不是让每个环节都变快，而是把人的时间从低价值环节里解放出来。