1. 从一篇翻译项目说起：为什么人工翻译在AI时代反而更值得做看到“TowardsArtificialIntelligence 博客中文翻译”这个标题，很多人的第一反应可能是：现在机器翻译这么强，为什么还要花时间做人工翻译？这个问题我在刚开始接触这个项目时也问过自己。但真正动手翻译了几十篇技术博客之后，我的看法完全变了——人工翻译技术博客这件事，在AI时代不但没有贬值，反而变成了一种稀缺能力。原因很简单：机器翻译能处理“字面意思”，但处理不了“语境”。技术博客里充斥着大量行业黑话、缩写、隐喻和作者的个人风格，这些东西机器翻出来往往让人哭笑不得。比如“attention”在深度学习语境下是“注意力机制”，机器可能翻成“关注”；“transformer”是“变换器”架构，机器可能翻成“变压器”。更别提那些作者随手写的吐槽和玩笑，机器翻出来完全变味。这个翻译项目本质上是一个持续性的内容工程，不是翻一篇就完事。它要求译者对人工智能领域有基本认知，同时具备把英文技术表达转化成中文读者能顺畅理解的能力。适合参与的人包括：对AI有兴趣但英文阅读速度不够快的开发者、想通过翻译来倒逼自己精读论文的学生、以及希望建立个人技术品牌的内容创作者。翻译的过程本身就是一次深度学习，你不仅要理解原文，还要用另一种语言重新组织它，这个过程中暴露出来的理解盲区，比自己随便读一遍要多得多。我参与这个项目的翻译工作断断续续持续了几个月，踩过的坑从术语不统一到格式错乱，从版权边界模糊到翻译腔太重被读者吐槽，几乎每个环节都交过学费。下面我把整个流程拆开，把那些“只有真正翻过才知道”的细节全部摊开来讲。2. 翻译前的准备工作：术语库和风格指南比什么都重要2.1 为什么不能上来就翻我见过太多人拿到一篇英文博客，打开翻译工具就开始逐段粘贴。这种做法在短文本上问题不大，但翻译系列博客时是灾难性的。原因在于：同一个术语在不同文章里可能被翻成不同的词，读者读起来会觉得这不是一个系列，而是几十个不同的人各翻各的。举个例子，“neural network”这个词，有人翻“神经网络”，有人翻“类神经网络”，还有人翻“神经网路”。单看每一篇都没错，但放在一起就让人出戏。更麻烦的是缩写词，比如“LLM”，有的文章里翻成“大型语言模型”，有的直接保留“LLM”，有的翻成“大语言模型”。读者看到后面会怀疑自己是不是漏掉了什么定义。所以我在正式动手之前，先花了两天时间做了一件看起来“不产出内容”的事：建立术语库和风格指南。这件事的回报在后面翻译过程中体现得淋漓尽致——每当遇到不确定的词，查一下术语库就能保持一致性，不用每次都重新做决策。2.2 术语库的建立方法术语库不需要搞得很复杂，一个简单的表格就够了。我用的结构是这样的：英文术语中文译法备注attention mechanism注意力机制不翻“关注机制”fine-tuning微调不翻“精细调整”prompt engineering提示工程有时保留“prompt”不翻inference推理区别于“推断”token词元首次出现时加英文注释这个表格在翻译过程中会不断扩充。我的习惯是每遇到一个新术语，先查一下行业内主流译法是什么，如果实在没有统一译法，就自己定一个，然后记进表格。下次再遇到同一个词，直接查表，不重复决策。提示：术语库最好用在线表格工具维护，方便多人协作时同步更新。如果是一个人做，本地Excel也够用，但记得定期备份。2.3 风格指南要解决哪些问题风格指南解决的是“语气”和“格式”层面的问题。技术博客的翻译和学术论文翻译不一样，前者可以稍微口语化一点，后者必须严谨。这个项目里的博客大多带有作者的个人观点和吐槽，翻译时要不要保留这种语气？我的选择是保留，但做适度调整。具体来说，风格指南需要明确这几件事：人称处理：原文的“I”翻成“我”还是“笔者”？我倾向于翻“我”，因为博客本身就是个人表达，翻“笔者”反而显得疏远。代码和命令：保留原文不翻，但注释部分要翻。变量名、函数名一律不动。链接和引用：原文的外链保留，但如果链接文字是英文描述，要翻成中文。标点符号：英文的破折号、引号、括号在中文里的对应写法要统一。数字和单位：什么时候用阿拉伯数字，什么时候用中文数字，要定一个规则。这些规则看起来琐碎，但如果不提前定好，翻到后面就会出现前后不一致的情况，回头统一修改的成本远高于一开始就定好。2.4 工具链的选择逻辑翻译工具的选择取决于你的工作流。如果只是偶尔翻一两篇，浏览器翻译插件加人工润色就够了。但如果是系列翻译，我建议用专业的翻译辅助工具，比如支持翻译记忆库的软件。这类工具的核心价值是：当你翻过的句子再次出现时，它会自动提示你之前的译法，避免重复劳动和不一致。我自己的工具链是这样的：用支持翻译记忆的编辑器做初翻，用术语库插件保证术语一致，最后导出成Markdown格式。为什么不直接在Markdown编辑器里翻？因为翻译过程中需要频繁查词、查术语、对比原文，专业工具的侧边栏和快捷键能省很多时间。注意：不要用机器翻译直接出终稿。机器翻译可以作为初稿参考，但必须逐句人工校对。我试过直接拿机器翻译的稿子改，结果发现改的成本比重新翻还高，因为机器翻译的语序和用词会干扰你的判断。3. 翻译过程中的核心难点：技术博客和普通文章到底差在哪3.1 术语密度带来的理解门槛技术博客的术语密度远高于普通文章。一段话里可能连续出现五六个专业术语，而且这些术语之间还有逻辑关系。如果译者对AI领域没有基本了解，翻译出来的东西自己都看不懂，更别说读者了。我遇到过一个典型的例子：原文在讨论“self-attention”和“cross-attention”的区别，如果不知道这两个概念在Transformer架构里的具体含义，翻译时就会把“self”翻成“自我”，“cross”翻成“交叉”，读起来像是某种心理学概念。正确的做法是理解它们在模型结构中的位置和作用，然后用中文技术社区通用的说法来表达。这就引出一个关键问题：译者需不需要是AI专家？我的看法是不需要，但需要具备“快速学习一个概念”的能力。遇到不懂的术语，花十分钟查一下资料，理解它的核心含义，再决定怎么翻。这个时间投入是值得的，因为一个术语翻错了，整段话的意思可能就偏了。3.2 长难句的拆解策略英文技术博客里经常出现那种三四行长的句子，从句套从句，修饰语一堆。这种句子直接按英文语序翻成中文，读者读起来会喘不过气。我的处理方法是：先找出句子的主干（主语、谓语、宾语），然后把修饰成分拆成独立的短句，用中文的逻辑重新组织。举个例子，原文可能是这样的结构：“The model, which was trained on a large corpus of text data that had been collected from various sources over a period of several years, demonstrated remarkable performance on a range of tasks that required understanding of context.”直接翻：“这个模型，它是在一个大型文本数据集上训练的，这个数据集是从各种来源在几年时间里收集的，在一系列需要理解上下文的任务上展示了显著的表现。”读起来很累。我的翻法：“这个模型在一个大型文本数据集上训练，数据来自多种渠道，收集时间跨越数年。在一系列需要理解上下文的任务上，它表现出了显著的优势。”拆成两句，把修饰成分变成独立的分句，读起来顺畅多了。这个技巧说起来简单，但实际操作时需要判断哪些信息是核心、哪些是补充，以及拆开之后怎么衔接才不显得突兀。3.3 代码块和公式的处理技术博客里经常夹杂代码块和数学公式。代码块的处理原则很简单：代码本身不翻，但代码里的注释要翻。如果代码有配套的文字说明，说明部分要翻。数学公式一般保留原样，但公式里的变量说明要翻。有一个容易忽略的细节：代码块里的中文注释要注意编码问题。有些编辑器默认用UTF-8，有些用GBK，如果编码不统一，中文注释会变成乱码。我在这个项目里就遇到过这个问题，后来统一规定所有文件都用UTF-8编码，才解决了。另外，代码块里的缩进和空格要原样保留。Markdown对缩进敏感，如果翻译过程中不小心改了缩进，代码的层级关系就乱了。我的做法是：代码块整体复制粘贴，只在注释部分做修改，其他部分一个字都不动。3.4 文化差异和本地化表达英文技术博客里经常有一些文化特定的表达，比如体育比喻、电影梗、俚语。这些东西直译过来中文读者看不懂，意译又可能失去原味。我的处理原则是：如果这个表达不影响核心意思，就替换成中文读者熟悉的类似表达；如果它是理解上下文的关键，就保留并加简短注释。比如原文说“this approach is a slam dunk”，直译“这是一个扣篮”中文读者可能反应不过来。翻成“这个方案稳了”或者“这个方案是板上钉钉的”，意思就传达到了。再比如“move the needle”，翻成“带来实质性改变”比“移动指针”清楚得多。但有些表达不能随便替换。比如作者在讨论某个技术方案时用了“elephant in the room”这个说法，如果翻成“显而易见的问题”，虽然意思对了，但失去了原文那种“大家都知道但没人说”的微妙含义。这种情况下我会保留比喻，加一个简短的括号说明。4. 翻译之后的校对与润色：好译文是改出来的4.1 冷处理校对法初翻完成之后，不要马上校对。我的习惯是放一晚上，第二天再回头看。这个“冷处理”的过程能让大脑从“翻译模式”切换到“阅读模式”，更容易发现那些翻译时没注意到的问题。冷处理之后的第一遍校对，重点看三件事：一是有没有漏译，二是术语是否一致，三是句子是否通顺。漏译在长文里很常见，尤其是段落中间的某句话，翻译时可能因为注意力转移就跳过去了。术语一致性靠术语库来检查，但也要人工扫一遍，因为有些词可能不在术语库里。句子通顺度是最主观的，我的判断标准是：读出声来，如果读着别扭，那就需要改。4.2 朗读校对法朗读是我最推荐的校对方法。默读的时候，大脑会自动补全不顺畅的地方，很多问题就被忽略了。但朗读的时候，嘴巴和耳朵会强迫你面对每一个字，那些拗口的、不通顺的地方会立刻暴露出来。我通常在第二遍校对时用这个方法。找一个安静的地方，把译文从头到尾读一遍。遇到读不下去的地方就停下来改，改完再读一遍。这个过程很耗时，但效果非常好。很多“看着没问题”的句子，一读就发现毛病了。提示：如果条件允许，可以用文字转语音工具把译文读出来听。虽然机器朗读没有感情，但用来发现语句不通顺的问题足够了。4.3 对照原文的终审最后一遍校对要对照原文逐段检查。这一遍的重点不是语言流畅度，而是准确性。具体检查这些点：数字、日期、版本号有没有翻错人名、产品名、公司名有没有统一引用的链接是否有效代码块是否完整图表说明是否对应这一遍最枯燥，但绝对不能省。我遇到过好几次数字翻错的情况，比如把“10x”翻成“10倍”没问题，但把“10x”看成“1x”就麻烦了。还有一次把版本号“v2.3”翻成了“v2.3版”，虽然意思没错，但和原文格式不一致，后来统一规定版本号不加“版”字。4.4 读者视角的最终检查在发布之前，我会做一次“读者视角”的检查。具体做法是：假装自己是一个完全不懂AI的读者，从头读一遍译文，看能不能理解。如果某个地方需要反复读才能明白，那就说明翻译有问题，需要改。这个检查能发现一些“译者觉得没问题但读者看不懂”的地方。比如有些术语，译者因为太熟悉了，觉得不需要解释，但普通读者可能完全不知道在说什么。这种情况下，我会在术语首次出现时加一个简短的括号说明，或者用一句话解释一下。5. 系列翻译的工程化管理：一个人也要像团队一样运作5.1 文件命名和版本控制系列翻译最大的挑战不是单篇的质量，而是整体的可维护性。如果文件命名混乱、版本到处飞，翻到第十篇的时候你就找不到第一篇的术语库了。我的做法是建立一套严格的命名规则：文件名格式：编号-原文标题-翻译日期.md，比如071-TowardsAI-20240115.md术语库文件：glossary.md，放在根目录风格指南：style-guide.md，放在根目录每篇译文单独一个文件夹，里面放原文、译文、笔记版本控制用Git，每次翻译完成提交一次，提交信息写清楚翻了哪篇、改了什么。这样做的好处是：如果后面发现术语翻错了，可以快速定位到所有受影响的文章，批量修改。5.2 进度追踪和任务管理系列翻译最怕的是“翻到一半断了”。为了避免这种情况，我用一个简单的看板来追踪进度：待翻译、翻译中、校对中、已完成。每篇文章是一个卡片，从左边移到右边。这个看板可以是实体白板，也可以是Trello之类的工具，关键是让自己一眼能看到整体进度。我还会给每篇文章预估一个翻译时间，然后记录实际用时。这样做几次之后，就能比较准确地预估后续文章的耗时，安排时间更合理。一般来说，一篇2000词的AI技术博客，初翻需要3-4小时，校对需要1-2小时，总共5-6小时。如果遇到术语特别密集或者句子特别复杂的文章，时间可能翻倍。5.3 质量反馈的收集和处理译文发布之后，读者的反馈是改进的重要依据。我会关注这几类反馈：术语翻错了、句子不通顺、意思理解错了、格式有问题。每一条反馈都记录在一个反馈表里，定期回顾，看看有没有共性问题。有一次读者指出我把“gradient descent”翻成了“梯度下降法”，而行业内更常用的说法是“梯度下降”。虽然只多了一个“法”字，但读起来就是不够专业。这种细节靠自己很难发现，但读者一眼就能看出来。所以我现在会主动邀请几位懂行的读者帮忙审阅，他们的反馈比我自己反复读十遍都有用。6. 翻译项目带给我的意外收获6.1 对AI概念的理解反而更深了翻译和阅读是两种完全不同的认知活动。阅读的时候，你可以跳过不懂的地方，靠上下文猜个大概。但翻译的时候，你必须把每个词都搞清楚，否则翻出来的东西自己都不信。这种“被迫理解”的过程，让我对很多AI概念的理解比单纯读论文时深得多。举个例子，“embedding”这个词我以前一直模糊地理解为“嵌入”，但具体嵌入什么、怎么嵌入，说不清楚。翻译了几篇相关文章之后，我被迫去查资料、看代码，才真正理解了它是把离散的符号映射到连续向量空间的过程。这种理解是翻译带来的副产品，但价值可能比译文本身还大。6.2 中文技术写作能力被动提升翻译做多了，中文技术写作能力会不知不觉提高。因为你在翻译过程中会反复对比英文和中文的表达方式，慢慢就摸清了中文技术写作的节奏和用词习惯。哪些词该用、哪些词不该用、句子多长合适、段落怎么组织，这些感觉都是在大量翻译实践中培养出来的。我现在写自己的技术文章时，会不自觉地用翻译时总结的那些原则：术语首次出现加注释、长句拆短、代码和文字分开、用具体例子代替抽象描述。这些原则看起来简单，但真正内化成写作习惯需要大量练习。6.3 建立了一个小型的知识库翻译过的文章本身就是一个小型知识库。我把每篇译文的术语、核心概念、关键结论都提取出来，整理成一个索引。这个索引后来成了我查资料的首选入口——想了解某个概念，先看看自己翻过的文章里有没有涉及，有的话直接看译文，比重新搜英文资料快得多。这个知识库还有一个用途：当有人问我某个AI概念时，我可以直接分享对应的译文链接，省去了重复解释的时间。虽然这些译文是别人的原创内容，但翻译本身也是一种知识整理，分享译文链接的同时也是在分享自己的学习成果。7. 如果你也想做翻译项目，这几条经验可能对你有用翻译这件事，说到底是“用输出倒逼输入”。你不需要等到自己成为专家才开始翻，因为翻译的过程本身就会让你变成更懂行的人。但有几条经验我想提前告诉你，能帮你少走一些弯路。第一条：不要追求“完美译文”。我刚开始翻译时，一句话反复改十几遍，总觉得不够好。后来发现，译文永远有改进空间，但读者的耐心是有限的。与其花大量时间打磨一句话，不如把整体质量提上去，让读者能顺畅读完。完美主义在翻译项目里是效率的敌人。第二条：建立自己的“翻译肌肉记忆”。每次遇到类似的句式，用同样的处理方式，不要每次重新决策。比如“which means that”统一翻成“这意味着”，“in other words”统一翻成“换句话说”。这种一致性会让译文读起来更顺畅，也让你翻得更快。第三条：定期回顾旧译文。我每隔一段时间会随机抽一篇以前翻的文章重读，经常能发现当时没注意到的问题。这种回顾不是为了修改，而是为了看看自己有没有进步，以及有没有形成新的坏习惯。第四条：找到你的“第一读者”。这个人不需要懂AI，但需要中文语感好。他读不懂的地方，大概率是翻译有问题。我的第一读者是一位做编辑的朋友，她帮我指出了很多“译者自己看不出来”的问题。最后说一个我自己的体会：翻译AI博客这件事，最大的回报不是译文本身，而是翻译过程中建立起来的对技术的理解和对语言的敏感。这些东西不会写在简历上，但会在你写自己的文章、做自己的项目时悄悄发挥作用。如果你正在犹豫要不要开始，我的建议是：先翻一篇试试，翻完你就知道值不值得继续了。
1. 从一篇翻译项目说起：为什么人工翻译在AI时代反而更值得做看到“TowardsArtificialIntelligence 博客中文翻译”这个标题，很多人的第一反应可能是：现在机器翻译这么强，为什么还要花时间做人工翻译？这个问题我在刚开始接触这个项目时也问过自己。但真正动手翻译了几十篇技术博客之后，我的看法完全变了——人工翻译技术博客这件事，在AI时代不但没有贬值，反而变成了一种稀缺能力。原因很简单：机器翻译能处理“字面意思”，但处理不了“语境”。技术博客里充斥着大量行业黑话、缩写、隐喻和作者的个人风格，这些东西机器翻出来往往让人哭笑不得。比如“attention”在深度学习语境下是“注意力机制”，机器可能翻成“关注”；“transformer”是“变换器”架构，机器可能翻成“变压器”。更别提那些作者随手写的吐槽和玩笑，机器翻出来完全变味。这个翻译项目本质上是一个持续性的内容工程，不是翻一篇就完事。它要求译者对人工智能领域有基本认知，同时具备把英文技术表达转化成中文读者能顺畅理解的能力。适合参与的人包括：对AI有兴趣但英文阅读速度不够快的开发者、想通过翻译来倒逼自己精读论文的学生、以及希望建立个人技术品牌的内容创作者。翻译的过程本身就是一次深度学习，你不仅要理解原文，还要用另一种语言重新组织它，这个过程中暴露出来的理解盲区，比自己随便读一遍要多得多。我参与这个项目的翻译工作断断续续持续了几个月，踩过的坑从术语不统一到格式错乱，从版权边界模糊到翻译腔太重被读者吐槽，几乎每个环节都交过学费。下面我把整个流程拆开，把那些“只有真正翻过才知道”的细节全部摊开来讲。2. 翻译前的准备工作：术语库和风格指南比什么都重要2.1 为什么不能上来就翻我见过太多人拿到一篇英文博客，打开翻译工具就开始逐段粘贴。这种做法在短文本上问题不大，但翻译系列博客时是灾难性的。原因在于：同一个术语在不同文章里可能被翻成不同的词，读者读起来会觉得这不是一个系列，而是几十个不同的人各翻各的。举个例子，“neural network”这个词，有人翻“神经网络”，有人翻“类神经网络”，还有人翻“神经网路”。单看每一篇都没错，但放在一起就让人出戏。更麻烦的是缩写词，比如“LLM”，有的文章里翻成“大型语言模型”，有的直接保留“LLM”，有的翻成“大语言模型”。读者看到后面会怀疑自己是不是漏掉了什么定义。所以我在正式动手之前，先花了两天时间做了一件看起来“不产出内容”的事：建立术语库和风格指南。这件事的回报在后面翻译过程中体现得淋漓尽致——每当遇到不确定的词，查一下术语库就能保持一致性，不用每次都重新做决策。2.2 术语库的建立方法术语库不需要搞得很复杂，一个简单的表格就够了。我用的结构是这样的：英文术语中文译法备注attention mechanism注意力机制不翻“关注机制”fine-tuning微调不翻“精细调整”prompt engineering提示工程有时保留“prompt”不翻inference推理区别于“推断”token词元首次出现时加英文注释这个表格在翻译过程中会不断扩充。我的习惯是每遇到一个新术语，先查一下行业内主流译法是什么，如果实在没有统一译法，就自己定一个，然后记进表格。下次再遇到同一个词，直接查表，不重复决策。提示：术语库最好用在线表格工具维护，方便多人协作时同步更新。如果是一个人做，本地Excel也够用，但记得定期备份。2.3 风格指南要解决哪些问题风格指南解决的是“语气”和“格式”层面的问题。技术博客的翻译和学术论文翻译不一样，前者可以稍微口语化一点，后者必须严谨。这个项目里的博客大多带有作者的个人观点和吐槽，翻译时要不要保留这种语气？我的选择是保留，但做适度调整。具体来说，风格指南需要明确这几件事：人称处理：原文的“I”翻成“我”还是“笔者”？我倾向于翻“我”，因为博客本身就是个人表达，翻“笔者”反而显得疏远。代码和命令：保留原文不翻，但注释部分要翻。变量名、函数名一律不动。链接和引用：原文的外链保留，但如果链接文字是英文描述，要翻成中文。标点符号：英文的破折号、引号、括号在中文里的对应写法要统一。数字和单位：什么时候用阿拉伯数字，什么时候用中文数字，要定一个规则。这些规则看起来琐碎，但如果不提前定好，翻到后面就会出现前后不一致的情况，回头统一修改的成本远高于一开始就定好。2.4 工具链的选择逻辑翻译工具的选择取决于你的工作流。如果只是偶尔翻一两篇，浏览器翻译插件加人工润色就够了。但如果是系列翻译，我建议用专业的翻译辅助工具，比如支持翻译记忆库的软件。这类工具的核心价值是：当你翻过的句子再次出现时，它会自动提示你之前的译法，避免重复劳动和不一致。我自己的工具链是这样的：用支持翻译记忆的编辑器做初翻，用术语库插件保证术语一致，最后导出成Markdown格式。为什么不直接在Markdown编辑器里翻？因为翻译过程中需要频繁查词、查术语、对比原文，专业工具的侧边栏和快捷键能省很多时间。注意：不要用机器翻译直接出终稿。机器翻译可以作为初稿参考，但必须逐句人工校对。我试过直接拿机器翻译的稿子改，结果发现改的成本比重新翻还高，因为机器翻译的语序和用词会干扰你的判断。3. 翻译过程中的核心难点：技术博客和普通文章到底差在哪3.1 术语密度带来的理解门槛技术博客的术语密度远高于普通文章。一段话里可能连续出现五六个专业术语，而且这些术语之间还有逻辑关系。如果译者对AI领域没有基本了解，翻译出来的东西自己都看不懂，更别说读者了。我遇到过一个典型的例子：原文在讨论“self-attention”和“cross-attention”的区别，如果不知道这两个概念在Transformer架构里的具体含义，翻译时就会把“self”翻成“自我”，“cross”翻成“交叉”，读起来像是某种心理学概念。正确的做法是理解它们在模型结构中的位置和作用，然后用中文技术社区通用的说法来表达。这就引出一个关键问题：译者需不需要是AI专家？我的看法是不需要，但需要具备“快速学习一个概念”的能力。遇到不懂的术语，花十分钟查一下资料，理解它的核心含义，再决定怎么翻。这个时间投入是值得的，因为一个术语翻错了，整段话的意思可能就偏了。3.2 长难句的拆解策略英文技术博客里经常出现那种三四行长的句子，从句套从句，修饰语一堆。这种句子直接按英文语序翻成中文，读者读起来会喘不过气。我的处理方法是：先找出句子的主干（主语、谓语、宾语），然后把修饰成分拆成独立的短句，用中文的逻辑重新组织。举个例子，原文可能是这样的结构：“The model, which was trained on a large corpus of text data that had been collected from various sources over a period of several years, demonstrated remarkable performance on a range of tasks that required understanding of context.”直接翻：“这个模型，它是在一个大型文本数据集上训练的，这个数据集是从各种来源在几年时间里收集的，在一系列需要理解上下文的任务上展示了显著的表现。”读起来很累。我的翻法：“这个模型在一个大型文本数据集上训练，数据来自多种渠道，收集时间跨越数年。在一系列需要理解上下文的任务上，它表现出了显著的优势。”拆成两句，把修饰成分变成独立的分句，读起来顺畅多了。这个技巧说起来简单，但实际操作时需要判断哪些信息是核心、哪些是补充，以及拆开之后怎么衔接才不显得突兀。3.3 代码块和公式的处理技术博客里经常夹杂代码块和数学公式。代码块的处理原则很简单：代码本身不翻，但代码里的注释要翻。如果代码有配套的文字说明，说明部分要翻。数学公式一般保留原样，但公式里的变量说明要翻。有一个容易忽略的细节：代码块里的中文注释要注意编码问题。有些编辑器默认用UTF-8，有些用GBK，如果编码不统一，中文注释会变成乱码。我在这个项目里就遇到过这个问题，后来统一规定所有文件都用UTF-8编码，才解决了。另外，代码块里的缩进和空格要原样保留。Markdown对缩进敏感，如果翻译过程中不小心改了缩进，代码的层级关系就乱了。我的做法是：代码块整体复制粘贴，只在注释部分做修改，其他部分一个字都不动。3.4 文化差异和本地化表达英文技术博客里经常有一些文化特定的表达，比如体育比喻、电影梗、俚语。这些东西直译过来中文读者看不懂，意译又可能失去原味。我的处理原则是：如果这个表达不影响核心意思，就替换成中文读者熟悉的类似表达；如果它是理解上下文的关键，就保留并加简短注释。比如原文说“this approach is a slam dunk”，直译“这是一个扣篮”中文读者可能反应不过来。翻成“这个方案稳了”或者“这个方案是板上钉钉的”，意思就传达到了。再比如“move the needle”，翻成“带来实质性改变”比“移动指针”清楚得多。但有些表达不能随便替换。比如作者在讨论某个技术方案时用了“elephant in the room”这个说法，如果翻成“显而易见的问题”，虽然意思对了，但失去了原文那种“大家都知道但没人说”的微妙含义。这种情况下我会保留比喻，加一个简短的括号说明。4. 翻译之后的校对与润色：好译文是改出来的4.1 冷处理校对法初翻完成之后，不要马上校对。我的习惯是放一晚上，第二天再回头看。这个“冷处理”的过程能让大脑从“翻译模式”切换到“阅读模式”，更容易发现那些翻译时没注意到的问题。冷处理之后的第一遍校对，重点看三件事：一是有没有漏译，二是术语是否一致，三是句子是否通顺。漏译在长文里很常见，尤其是段落中间的某句话，翻译时可能因为注意力转移就跳过去了。术语一致性靠术语库来检查，但也要人工扫一遍，因为有些词可能不在术语库里。句子通顺度是最主观的，我的判断标准是：读出声来，如果读着别扭，那就需要改。4.2 朗读校对法朗读是我最推荐的校对方法。默读的时候，大脑会自动补全不顺畅的地方，很多问题就被忽略了。但朗读的时候，嘴巴和耳朵会强迫你面对每一个字，那些拗口的、不通顺的地方会立刻暴露出来。我通常在第二遍校对时用这个方法。找一个安静的地方，把译文从头到尾读一遍。遇到读不下去的地方就停下来改，改完再读一遍。这个过程很耗时，但效果非常好。很多“看着没问题”的句子，一读就发现毛病了。提示：如果条件允许，可以用文字转语音工具把译文读出来听。虽然机器朗读没有感情，但用来发现语句不通顺的问题足够了。4.3 对照原文的终审最后一遍校对要对照原文逐段检查。这一遍的重点不是语言流畅度，而是准确性。具体检查这些点：数字、日期、版本号有没有翻错人名、产品名、公司名有没有统一引用的链接是否有效代码块是否完整图表说明是否对应这一遍最枯燥，但绝对不能省。我遇到过好几次数字翻错的情况，比如把“10x”翻成“10倍”没问题，但把“10x”看成“1x”就麻烦了。还有一次把版本号“v2.3”翻成了“v2.3版”，虽然意思没错，但和原文格式不一致，后来统一规定版本号不加“版”字。4.4 读者视角的最终检查在发布之前，我会做一次“读者视角”的检查。具体做法是：假装自己是一个完全不懂AI的读者，从头读一遍译文，看能不能理解。如果某个地方需要反复读才能明白，那就说明翻译有问题，需要改。这个检查能发现一些“译者觉得没问题但读者看不懂”的地方。比如有些术语，译者因为太熟悉了，觉得不需要解释，但普通读者可能完全不知道在说什么。这种情况下，我会在术语首次出现时加一个简短的括号说明，或者用一句话解释一下。5. 系列翻译的工程化管理：一个人也要像团队一样运作5.1 文件命名和版本控制系列翻译最大的挑战不是单篇的质量，而是整体的可维护性。如果文件命名混乱、版本到处飞，翻到第十篇的时候你就找不到第一篇的术语库了。我的做法是建立一套严格的命名规则：文件名格式：编号-原文标题-翻译日期.md，比如071-TowardsAI-20240115.md术语库文件：glossary.md，放在根目录风格指南：style-guide.md，放在根目录每篇译文单独一个文件夹，里面放原文、译文、笔记版本控制用Git，每次翻译完成提交一次，提交信息写清楚翻了哪篇、改了什么。这样做的好处是：如果后面发现术语翻错了，可以快速定位到所有受影响的文章，批量修改。5.2 进度追踪和任务管理系列翻译最怕的是“翻到一半断了”。为了避免这种情况，我用一个简单的看板来追踪进度：待翻译、翻译中、校对中、已完成。每篇文章是一个卡片，从左边移到右边。这个看板可以是实体白板，也可以是Trello之类的工具，关键是让自己一眼能看到整体进度。我还会给每篇文章预估一个翻译时间，然后记录实际用时。这样做几次之后，就能比较准确地预估后续文章的耗时，安排时间更合理。一般来说，一篇2000词的AI技术博客，初翻需要3-4小时，校对需要1-2小时，总共5-6小时。如果遇到术语特别密集或者句子特别复杂的文章，时间可能翻倍。5.3 质量反馈的收集和处理译文发布之后，读者的反馈是改进的重要依据。我会关注这几类反馈：术语翻错了、句子不通顺、意思理解错了、格式有问题。每一条反馈都记录在一个反馈表里，定期回顾，看看有没有共性问题。有一次读者指出我把“gradient descent”翻成了“梯度下降法”，而行业内更常用的说法是“梯度下降”。虽然只多了一个“法”字，但读起来就是不够专业。这种细节靠自己很难发现，但读者一眼就能看出来。所以我现在会主动邀请几位懂行的读者帮忙审阅，他们的反馈比我自己反复读十遍都有用。6. 翻译项目带给我的意外收获6.1 对AI概念的理解反而更深了翻译和阅读是两种完全不同的认知活动。阅读的时候，你可以跳过不懂的地方，靠上下文猜个大概。但翻译的时候，你必须把每个词都搞清楚，否则翻出来的东西自己都不信。这种“被迫理解”的过程，让我对很多AI概念的理解比单纯读论文时深得多。举个例子，“embedding”这个词我以前一直模糊地理解为“嵌入”，但具体嵌入什么、怎么嵌入，说不清楚。翻译了几篇相关文章之后，我被迫去查资料、看代码，才真正理解了它是把离散的符号映射到连续向量空间的过程。这种理解是翻译带来的副产品，但价值可能比译文本身还大。6.2 中文技术写作能力被动提升翻译做多了，中文技术写作能力会不知不觉提高。因为你在翻译过程中会反复对比英文和中文的表达方式，慢慢就摸清了中文技术写作的节奏和用词习惯。哪些词该用、哪些词不该用、句子多长合适、段落怎么组织，这些感觉都是在大量翻译实践中培养出来的。我现在写自己的技术文章时，会不自觉地用翻译时总结的那些原则：术语首次出现加注释、长句拆短、代码和文字分开、用具体例子代替抽象描述。这些原则看起来简单，但真正内化成写作习惯需要大量练习。6.3 建立了一个小型的知识库翻译过的文章本身就是一个小型知识库。我把每篇译文的术语、核心概念、关键结论都提取出来，整理成一个索引。这个索引后来成了我查资料的首选入口——想了解某个概念，先看看自己翻过的文章里有没有涉及，有的话直接看译文，比重新搜英文资料快得多。这个知识库还有一个用途：当有人问我某个AI概念时，我可以直接分享对应的译文链接，省去了重复解释的时间。虽然这些译文是别人的原创内容，但翻译本身也是一种知识整理，分享译文链接的同时也是在分享自己的学习成果。7. 如果你也想做翻译项目，这几条经验可能对你有用翻译这件事，说到底是“用输出倒逼输入”。你不需要等到自己成为专家才开始翻，因为翻译的过程本身就会让你变成更懂行的人。但有几条经验我想提前告诉你，能帮你少走一些弯路。第一条：不要追求“完美译文”。我刚开始翻译时，一句话反复改十几遍，总觉得不够好。后来发现，译文永远有改进空间，但读者的耐心是有限的。与其花大量时间打磨一句话，不如把整体质量提上去，让读者能顺畅读完。完美主义在翻译项目里是效率的敌人。第二条：建立自己的“翻译肌肉记忆”。每次遇到类似的句式，用同样的处理方式，不要每次重新决策。比如“which means that”统一翻成“这意味着”，“in other words”统一翻成“换句话说”。这种一致性会让译文读起来更顺畅，也让你翻得更快。第三条：定期回顾旧译文。我每隔一段时间会随机抽一篇以前翻的文章重读，经常能发现当时没注意到的问题。这种回顾不是为了修改，而是为了看看自己有没有进步，以及有没有形成新的坏习惯。第四条：找到你的“第一读者”。这个人不需要懂AI，但需要中文语感好。他读不懂的地方，大概率是翻译有问题。我的第一读者是一位做编辑的朋友，她帮我指出了很多“译者自己看不出来”的问题。最后说一个我自己的体会：翻译AI博客这件事，最大的回报不是译文本身，而是翻译过程中建立起来的对技术的理解和对语言的敏感。这些东西不会写在简历上，但会在你写自己的文章、做自己的项目时悄悄发挥作用。如果你正在犹豫要不要开始，我的建议是：先翻一篇试试，翻完你就知道值不值得继续了。