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零样本学习避免缩写为ZSRAG检索增强生成首次出现时展开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期里有一些小标题是名词短语中文化之后如果还是“XXYY”的格式我会保留冒号因为中文读者对冒号标题接受度很高。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 这个博客还在持续产出我的中文翻译系列也会继续跟下去。第一百一十八期是一段路的标记也是一条新起点的开始。