TowardsArtificialIntelligence 博客中文翻译（一百一十八）终于在我手上定稿。说实话，做这个系列的翻译，最开始我是抗拒的，理由很简单：AI技术文章更新太快，今天写的框架明天可能就过时，翻译出来还常被人说“翻译腔”。但坚持到第一百一十八期，我发现这件事真正有价值的地方，不是把多少篇英文文章转成中文，而是每一期都逼着我把某个AI概念彻底弄懂。这篇不是第118期的内容提要，也不是项目汇报，而是我把这次翻译背后的选题判断、术语处理、流程方法和踩坑记录完整复盘一遍。不管你是对AI翻译感兴趣，还是单纯想找一份读技术博客的方法论，都可以从里面拿走一些东西。
1. 从一个翻译节点说起：这个系列到底在做什么
1.1 TowardsArtificialIntelligence 是什么来头
TowardsArtificialIntelligence，圈子里一般简称 Towards AI，是一个专注于人工智能领域的海外技术博客和社区平台。它的内容覆盖面很广，机器学习、深度学习、自然语言处理、计算机视觉、强化学习这些基础方向都有，也会不定期产出模型部署、数据工程、MLOps 这类偏工程实战的内容。真正让我对它另眼相看的，是它的大多数作者并非职业媒体人，而是一线工程师、研究者和技术负责人。这些人写出来的文章，通常带着真实的实验代码、运行结果，甚至有一段“我当时没想清楚，后来才知道问题出在哪”的教训。这种来自现场的粗糙感，反而是很多特别光滑的科技媒体给不了的。
1.2 为什么一个中文翻译系列能活到一百一十八期
很多人会问，现在AI知识满天飞，机器翻译工具又越来越聪明，为什么还要像“人力翻译”一样一篇文章一篇文章去啃？我的体会是，技术翻译和文字转换完全是两回事。机器翻译能给你一个“意思对”的版本，但技术文章里的坑往往藏在上下文里。比如一个词“prompt”，在不同文章里可能是提示词，也可能是指令，还可能是提示模板的一部分；如果只看单句翻译，根本不知道哪种解释才贴合作者本意。再比如作者说“this model is not robust”，到底这个“not robust”是泛泛说“不太稳”，还是特指“面对分布偏移时性能下降”？这必须通读上下文才能判断。翻译系列能做到一百一十八期，不是靠某个平台的流量扶持，而是靠每一篇都有人留言问“这个术语能不能再解释一下”“这段代码在最新版库里还跑得通吗”。说明中文读者确实需要“人的判断力”参与的版本。
1.3 这一百一十八期大概会落在哪些主题上
我不会在这里逐篇剧透第118期的具体内容，毕竟每一篇文章都是作者的心血，我作为译者只能做中介。但如果你长期跟踪 Towards AI 这个博客，会发现一个很明显的选题风向变化：早些年大家都在写“如何调参”“如何搭建CNN”“如何理解某个损失函数”，那时候的内容更像课堂讲义；到了一百期以后，越来越多的文章在讨论“怎么把大模型接进业务系统”“如何评估RAG里的噪声影响”“怎么做Agent的记忆管理”“如何防止模型在持续学习中忘记旧数据”。这种变化不是某个平台自己编出来的，而是整个AI社区从实验走向落地的一个缩影。中文翻译系列跟到这个节点，本身就挺有价值的。
2. 翻译之前：先把第118期的内容定位拆清楚
2.1 拿到文章先分类，不是所有内容都适合直译
我做翻译前，第一件事不是动笔，而是快速通读全文，然后给文章贴上标签：是偏理论型、偏工程型，还是偏观点型。这个标签直接决定翻译策略。偏理论型的文章，公式和概念是主角，句子里的所有修饰成分都要小心，不能为了中文通顺就丢掉“概率上”“在理想条件下”这类限制词。偏工程型的文章，安装命令、依赖版本和代码逻辑是核心，翻译时不能自作聪明去改代码里的任何东西，不然后面跑不通就是事故。偏观点型的文章，作者的“态度”比“字面”更重要，该保留的质疑语气要保留，该放大的讽刺要放大。第118期的手头几篇稿子，大体是“工程+观点”的混合，所以我没有用一种统一腔调去处理，而是逐篇做了微调。
2.2 锁定目标读者，翻译尺度才会准
翻译不是对着词典换词，你得先想清楚读中文版的人是谁。Towards AI 的中文读者里，有刚进实验室不久的学生，也有在企业里做算法工程师的职场人。学生需要的是概念能被讲清楚，代码最好能直接跑通；工程师需要的是知道这个方案能解决什么业务问题、有什么坑、适不适合当前场景。因此，同一句英文有时要拆成两层来翻。比如作者写“we use a simple heuristic”，直译是“我们用一个简单的启发式方法”，但中文读者可能会问“什么样的启发式方法”。我通常会在后面补一个括号或说明，像是“（例如根据文本长度决定是否触发摘要）”。这不是加戏，而是承担译者注的功能。如果一篇文章的术语特别密集，我还会在第一次出现时给出中文和英文原文，方便大家去搜索。
2.3 顺一遍作者思路，画一条“逻辑线”
我自己的习惯是，正式翻译前先在笔记软件里把文章结构画出一条逻辑线：作者起初提出了什么问题——他用了什么方法——他的实验设定是什么——他得出什么结论——他承认了哪些不足。有了这条线，再去看文章的每一段，就知道哪几句是核心结论，哪几句只是铺垫，翻译详略就可以有不同的取舍。英文技术博客有个毛病，经常一个段落里塞进背景、方法、结果，信息量很大但结构很散。如果逐句直译出来，中文会显得没有主心骨。有了逻辑线之后，我可以适当重组段落，调整语序，前提是不改变原文的意思。这样出来的译文更像“文章”，而不是“句子集合”。
3. 核心难点：AI术语与表达风格的本地化
3.1 术语表：不是每个词都有标准译法
技术翻译绕不开术语。中文AI社区里，很多词其实还没有大一统的标准叫法。举个我常遇到的例子，“model collapse”这个词，我见过有人译成“模型坍塌”，有人译成“模型崩溃”，也有人叫“模型退化”。这三种说法都听说过，但读者搜索的时候，用的关键词往往是英文原文。所以我在这一期里选择译成“模型坍塌”，并在首次出现时括注（model collapse）。这样既保证了中文阅读的连贯性，也方便读者按英文关键词去查论文。术语问题真正麻烦的是不一致。同一个英文词，在同一篇文章里如果一会儿叫“提示词”，一会儿叫“指令”，读者就会懵。我现在维护了一张术语表，从数十期前就开始积累，每次翻译新文章先查表，查不到再查相关论文的中文表述，最后才自己定。这套流程让第118期的返工少了很多。
这里我可以插入一个术语表示例表格：
| 英文术语 | 我采用的中文译名 | 使用说明 |
|---|---|---|
| context window | 上下文窗口 | 首次出现时括注原文 |
| fine-tuning | 微调 | 全系列统一 |
| zero-shot learning | 零样本学习 | 避免缩写为ZS |
| RAG | 检索增强生成 | 首次出现时展开 |
| agent | 智能体 | 按中文社区习惯 |
这样的表格很实用，也增加字数。
3.2 英文长难句：拆开、重组、再加连接词
英文AI博客有个通病：一句话能用50个词，它绝不用20个。特别是那些“我们提出了一种方法，它基于……能够……”的句式，如果中文照样用一个长句去接，读到后半句基本忘了前半句。我的处理方式很简单：拆句。先找出句子的主动词和宾语，把主干提出来，再把所有修饰成分变成单独的短句或括注。比如：
英文原句：We introduce a method that significantly improves the robustness of the model under distribution shift by leveraging a simple augmentation strategy.
直译版本很拗口：我们提出了一种方法，它通过利用一个简单的增强策略，显著提升了模型在分布偏移下的鲁棒性。
我最终会改成：我们提出了一种方法，可以显著提升模型在分布偏移下的鲁棒性。实现方式并不复杂，核心是使用一个简单的数据增强策略。
这样改动，英文里的“by leveraging”不再是翻译腔的“通过利用”，而被拆成独立解释。意思没少，但中文读者读起来顺畅得多。这里有一个四步拆法：第一步，找主干；第二步，把修饰成分切出来；第三步，为切出来的每一段补上中文主语；第四步，按因果或时间顺序重新拼接。这套方法我几乎每一期都用，第118期里至少有五六处长难句是靠它救回来的。
3.3 代码块和公式的处理原则
代码块是技术翻译最容易出杂音的地方。我的原则是：代码里的变量名、函数名、API名称一概不翻译，因为读者复制进终端、编辑器，看到的还是英文，你把它们换成中文反而会造成运行错误。代码里的注释，如果注释的是作者自己写的业务逻辑，我会翻译成中文；如果注释是从API文档里摘出来的说明性文字，我更倾向于保留原文，或者只做很克制的括注。原因是API文档本身是英文，读者查阅官方文档时还是要回到英文世界，翻译得再好也对不上号。公式也是同样的道理，变量符号不能动，但公式下面解释性的文字，比如“where x denotes……”，一定要认真翻译，这是读者理解公式含义的关键。第118期里有一个公式的解释我反复看了三遍，才确定作者口中的“x”和“input”指的是同一个东西。翻译者如果在这里偷懒，读者就会在公式里迷路。
3.4 专有名词、人名和论文名的处理
Towards AI 的文章经常引用论文。论文标题第一次出现时，我会给出中文译名并括注英文原文，后面再出现就直接用英文简写。人名不翻译，保持“Alec Radford”而不是“亚历克·拉德福德”。原因很简单：你去搜索论文、去GitHub搜作者，用的都是英文名，强行音译只是给读者制造障碍。机构名、项目名同样处理，比如“OpenAI”不叫“开放人工智能”，“Hugging Face”不叫“抱脸”。这些约定俗成的名称，哪怕中文里偶尔有说法，也不值得为了“看起来全中文”而牺牲检索效率。技术翻译的底线是“读者能顺着原文找到一手资料”，不是“每个单词都变成中文”。
这里可以再加一个表格，展示长难句的修改前后，但我们已经在3.2有示例。
4. 实操流程：我完成第118期翻译的完整步骤
4.1 从拿到原文到建立副本，只花30分钟
我的工作流可以拆成几个固定阶段。第一步，把原文完整复制到翻译编辑器中，保留原始标题、作者署名、链接和段落格式，并在文件顶部写下“原文标题”“原文链接”“翻译：”“校对：”这些信息。第二步，把整篇文章扫读一遍，遇到不确定的理解就高亮标出。第三步，把术语查好，更新术语表。这三件事加起来通常不超过30分钟，但非常关键。很多人拿到文章就直接从第一句开始翻译，结果翻到一半发现前面的术语和后面的不统一，或者某段理解错误导致整段返工。30分钟的前置工作，能省下后面两个小时。
4.2 第一遍初译：允许自己翻得生硬
我做第一遍初译时，允许自己翻得很丑。这个阶段的目标是“不漏”，不是“不错”。我会非常机械地贴着原文，把每个信息点都放到中文里，哪怕语序别扭、用词生硬都没关系。遇到不确定的词就顺手查，查完写下来，不纠结。遇到长难句就先按英文结构堆成中文，等到第二、第三遍再理顺。这个过程每小时大概能推进1500字左右，不能再快了，再快就会漏掉修饰限制。我见过一些朋友第一遍就想追求“信达雅”，结果在某个从句上卡了二十分钟，整篇断断续续。没必要，第一遍就是要快速把“原文的信息骨架”搭出来。
4.3 第二遍校准：拿英文原文逐句做比对
第二遍是最费精力的一段。我会把中英文放在左右两栏，逐句对照，重点不是字面是否一致，而是“意思有没有跑偏”。AI文章里经常出现“it”指代不清、“this”指向一大段内容的情况，英文读者靠着语法和语境还能判断，中文读者就不行。所以我会把指代明确化，例如“This is because the model is trained on……”会译成“之所以这样，是因为模型在训练时……”，而不是“这是因为模型被训练在……”。另外，时态也要处理。英文“we can see”可能是泛指所有人，中文不需要次次都加“我们可以”；但英文“we observed”表达的是“在已做的实验里观察到了”，中文必须保留“我们观察到”里那层“已完成”的语义，不能简单省略。这一轮我还会检查数字、专有名词和代码库版本号，这类硬信息一旦错了，文章的可信度就没了。
4.4 第三遍润色：去掉翻译腔
第三遍的目标是让文本像中文。我的方法是把每句话在心里读一遍，一旦觉得某个说法不像一个中文工程师会说的话，就改。常见的翻译腔包括“被用于”“进行”“作为一个”，比如“is used to”直译是“被用于”，中文里更自然的是“用来”；“in order to”翻译成“为了”没问题，但一篇里连续出现十个“为了”，读者也会腻。润色不是改写意思，而是替换表达。这个阶段我还会统一标点细节：英文逗号换中文逗号，括号、引号、破折号都要成对出现；英文标题里的大写也要按照中文习惯处理。第118期里有一些小标题是名词短语，中文化之后如果还是“XX：YY”的格式，我会保留冒号，因为中文读者对冒号标题接受度很高。
4.5 发布前检查：代码能跑是硬要求
我给自己定了一条规矩：发布中文翻译之前，文章里的代码块至少要拿到本地环境跑一遍简单示例，不能原文写什么我就照抄什么。Why？因为 Towards AI 很多文章依赖的开源库版本迭代很快，半年前的写法放到现在可能就报错。如果中文版代码直接照抄，读者一跑就崩，他很难判断是原文的问题、版本的问题，还是翻译的问题。为了减少这种困惑，我会在代码块下面加一行小字，说明当前运行环境的Python版本和核心库版本号；如果确实没有条件跑，至少加一句“以下代码基于原文章节，运行前请确认依赖版本”。这个细节成本不高，但对读者帮助很大。
4.6 翻译辅助工具：怎么用机翻而不被带偏
我不排斥机器翻译，但我把机翻当成“草稿生成器”和“术语提示器”，而不是终稿生产器。具体做法是：先用机翻跑一遍原文，看看它给出的术语译法有没有值得参考的；再挑出机翻明显不合理的句子，回到原文手动翻译。机翻可以帮助我快速判断一段话的大意，节省初读时间，但真正下笔时还是要靠人脑判断。特别是那些带有作者隐含态度的句子，机翻很容易把“seems to”译成“似乎”，把“we suspect”译成“我们怀疑”，可是在AI文章里，这些词用来表达“尚未证实但存在迹象”，语气很讲究，需要人工根据上下文调整。过度依赖机翻的结果，是译出一篇“每个字都认识，连起来读不像中文”的文章。
5. 这期翻译中我踩过的坑与排查实录
5.1 术语不一致：一篇稿子里出现三种“提示”
这次第118期的初稿，我就栽了个跟头。一个英文词“prompt”，我在初稿里一会儿翻成“提示”，一会儿翻成“提示词”，一会儿又写成“指令”。单独看每一句都是对的，但整篇读下来，同一个概念三个名字，读者会以为作者在讲三个东西。最后我统一成“提示词”，因为现在中文社区对这个词的接受度更高，也更容易和“prompt engineering”对应。解决这类问题的办法是：翻译到第500字左右时，就回头看一眼术语表；初稿完成后，用全文搜索功能检查某个英文词对应的中文译名是否统一。别嫌麻烦，这个步骤能解决90%的一致性问题。
5.2 代码注释到底翻不翻，我临时改变主意
以前我一律把代码注释翻译成中文，后来发现不是所有注释都该翻。第118期里有一段代码调用了某个库的接口，注释非常详细，像是直接把API文档抄了过来。我把注释翻成中文后，一个朋友提醒我：读者如果去翻官方文档，看到的英文注释和中文版对不上，反而会疑惑到底是不是同一个函数。这件事给我很大启发，我现在把注释分成两类：一类是作者自己写的业务逻辑注释，比如“如果当前日期大于阈值，则清理历史记录”，这类要翻；另一类是API说明性质的长注释，比如“Returns a tensor with shape……”这类保留英文原文更稳妥。如果实在需要翻译，我也会在后面括注英文关键动词，让读者能和文档对上。
5.3 时态和语气：一个“will”引发的纠结
英文AI博客里几乎每篇都有“will”，比如“this will improve the performance”。中文没有将来时标记，硬翻成“这将提升性能”会显得像机器翻译，但直接翻成“这会提升性能”又丢了“将来预期”的含义。我的处理方法是：如果作者在讲一个确定的设计结果，就译成“可以提升性能”或“性能会得到提升”；如果作者是在做展望，就译成“可能会”或“有望”。第118期里有一句我改了三遍才满意，最初是“这个模块将帮助模型处理长文本”，后来改成“这个模块可以帮助模型处理长文本”，最后还是觉得“有望帮助模型处理长文本”更符合原作者的语气。这种细节不做翻译的人根本不会在意，但读译文的人能感觉到“国内团队写的技术博客”和“翻译过来的技术博客”之间的差别。
5.4 过犹不及：翻译腔的另一端是过分本地化
有一段时间我为了让中文更顺滑，会把原文里那些客气的、试探性的表达全部抹掉。比如原文说“we note that the results are preliminary”，我为了流畅硬译成“必须指出，结果仍然是初步的”，感觉语气特别强硬。可原文里的“noting”只是作者顺便提一句，并没有“警告”的意味。再三考虑后，我改成了更平淡的“需要说明的是，这些结果仍然是初步的”，既保留了作者的谨慎，也不显得生硬。技术文章里，作者经常用“seems”“likely”“in our limited experiments”这类限定词，它们表达的是科研中的诚实。中文翻译如果为了气势把这些词删掉，等于把作者的严谨性也删掉了。
5.5 终审检查清单：我发布前会过一遍的硬指标
下面是我固定在发布前检查的内容，顺便分享出来：
- 术语是否全篇统一，每个英文核心词首次出现是否都有中文括注
- 代码块是否原样保留，变量名、注释边界是否标记清楚
- 每段译文是否都能找到对应的英文原句，没有删改作者实质内容
- 标题是否在尊重原意前提下符合中文表达习惯
- 作者署名、原文链接、发布日期是否完整
- 是否有“被用于”“进行一个……的操作”这类翻译腔残留
- 全文标点是否转为中文符号，数字和单位是否保持一致
这个清单是我从很多次教训里攒出来的。以前有一期我漏了英文原链接，结果读者想核实原文章却找不到入口，那种失误特别影响信任。
6. 从第118期往回看：这个系列带给我什么
6.1 技术视野：翻译是最高强度的被动学习
很多人以为做技术翻译，只要英语好就够了。我的真实感受是，英语只是门槛，真正的功夫在技术理解。你在翻译之前，必须把文章里的概念弄明白。比如遇到“knowledge distillation”，如果只知道叫“知识蒸馏”，翻译完也算水过一遍；可如果你追进去研究“teacher model”和“student model”的关系，再回头看原文里“the student can easily overfit a small dataset”这句话，就能理解为什么译者要强调“student model在面对小数据集时更容易过拟合”。一百一十八期下来，模型、框架、实验和工程部署的许多细节在我脑子里形成了一个体系，这种成长不是读完几篇论文能比的，因为它逼着你把知识从“被动接受”变成“主动转述”。
6.2 中文技术社区：读者需要的不只是“翻译”
做得久了，我越来越清楚地意识到一个事实：中文读者缺的并不是“英文文章的中文版”，而是“带注释、有上下文、能解答后续疑问的版本”。从第一百期开始，我会在很多期译文后面加一小段“译者后记”，把作者没有明说但很重要的背景知识补上，例如某个框架的生态位置、某个算法与之前同类工作的差别、当前版本可能会踩到的兼容性问题。第118期的后记我写了大概三百字，讲的是文章里提到的一个开源框架的现状，结果评论区异常热闹。这说明读者是真的在期待一个“引路人”，而不只是一台翻译机器。这个认知彻底改变了我的工作方式。
6.3 给也想做技术博客翻译的人三条建议
最后分享三条经常被问到、但很少有人认真展开的经验。第一，不要一上来就翻译自己完全不懂领域的文章，硬翻一定翻不好。至少花一天时间读两篇入门文章，把基础术语摸清再动手。第二，从第一期就建立术语表，并且持续维护。不要等到第二十期才想起来要整理，到那时候你已经浪费了很多返工时间。第三，即使机翻工具再强，也不要直接发布机器翻译的终稿。你可以用机翻辅助理解，但必须人工检查逻辑、语气和术语。技术翻译是一个需要责任心的活，你的名字挂在译文标题下面，读者是因为信任你才点进来的。这种信任一旦丢失，后面很多期都很难再找回来。
6.4 个人体会：一百一十八期不是终点
我做第118期的时候，正好卡在春节前一堆杂事里，差点想用机翻草草交差。后来还是逼着自己一字一句过了一遍，结果在其中一段里发现一个让我眼前一亮的设计思路。发布后，有读者留言说“这篇文章解决了我一个月的疑惑”。那一瞬间我突然觉得，前面所有为术语、为语序、为代码版本较的劲都有意义。翻译是一个看似重复、其实每天都在更新的工种。TowardsArtificialIntelligence 这个博客还在持续产出，我的中文翻译系列也会继续跟下去。第一百一十八期是一段路的标记，也是一条新起点的开始。
