上周三晚上快11点了，我还在赶一份技术文档的英文版。合同写的是周四早上交付，12000字的中文API文档要翻成英文。
我一直用DeepL Pro，每个月花100块（13.99美元那档），用了两年确实舒服，术语比Google Translate准不少。
但那天晚上DeepL给我上了一课。
我把一段带大量代码注释和Markdown格式的文档丢进去，翻译结果里代码块全乱了。反引号被吃掉、缩进错位，离谱的是它把变量名userId翻译成了"用户身份"。
我手动修了40多分钟，改到第三节的时候心态直接崩了。
那个时候我就想：2025年了，AI翻译工具这么多，就没有一个能好好处理技术文档的？保留代码格式、术语别瞎翻，这要求不过分吧？
我花了一整个周末，拿同一份文档测了6个工具。中译英、英译中各一份，里面有Markdown格式、代码块、API参数表格。
结果挺意外的——最后胜出的是个国产选手。
先说下我怎么测的
不搞主观打分那套，直接上硬指标：
| 测评维度 | 怎么测的 |
|---|---|
| 术语准确率 | 抽了50个技术术语，一个个人工核对 |
| 格式保留度 | Markdown标题、代码块、表格、链接有没有被搞乱 |
| 翻译速度 | 12000字中文文档跑完要多久 |
| 上下文连贯性 | 同一个术语全文是不是统一的，长句读不读得通 |
| 价格 | 按我每月大概30万字的量算成本 |
测试文档选了三种典型场景：
- 一份REST API接口文档（大量参数表格和代码示例）
- 一篇技术博客（偏叙述，有口语化表达）
- 一段带注释的Python代码文件
下面一个个说。
DeepL Pro —— 老大哥翻纯文本还是猛，但碰到代码就拉了
纯文本翻译质量没话说，第一梯队。英译中的长句处理、语序调整确实比Google自然很多。
但格式处理这块真的有问题。我把Markdown文档直接粘进去：
## 请求参数
| 参数名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| userId | string | 是 | 用户唯一标识 |
| token | string | 是 | 鉴权令牌 |
DeepL给我翻成了：
## Request Parameters
| Parameter name | Type | Required | Description |
|--------|------|------|------|
| User ID | string | Yes | Unique user identifier |
| token | string | Yes | Authentication token |
看到没——userId这个字段名被翻译成了"User ID"。
搞开发的都知道，API文档里字段名是绝对不能翻译的，这玩意儿翻了下游直接报错。类似的问题整份文档里出现了17处。
术语准确率：41/50（82%） 格式保留度：70%（表格勉强保住了，代码块里的内容被误翻） 速度：12000字约22秒 月成本：约100元
Google Translate —— 免费确实能打，但长句一眼机翻
其实吧Google Translate这两年进步不小，短句翻译已经很能用了。
但技术文档里那种又臭又长的复合句，它一处理就露馅。
比如这句：
"当请求超时时间超过配置的阈值且重试次数已耗尽时，系统将自动触发熔断机制并将该服务实例标记为不可用。"
Google翻出来：
"When the request timeout exceeds the configured threshold and the number of retries has been exhausted, the system will automatically trigger the fuse mechanism and mark the service instance as unavailable."
"熔断机制"翻成了"fuse mechanism"。
说实话这个我真没想到它会犯这种错。正确的术语是"circuit breaker"，这在微服务领域是基础概念。技术文档里出现这种术语错误，发给客户就是事故。
术语准确率：34/50（68%） 格式保留度：65% 速度：12000字约8秒（六个里面最快） 月成本：免费（有API调用限额）
ChatGPT（GPT-4o）—
...
