做技术翻译这件事说实话一开始我没把它当成什么正经事。五年前某天晚上我刷到一篇讲强化学习入门的外文博客看完觉得写得真不错随手把其中几段翻译好丢到群里分享。本意只是抛砖引玉结果评论区追着问下一期什么时候出。就这样一个叫 TowardsArtificialIntelligence 博客中文翻译下称 TAI 系列的专栏草草开张——当年那句“下一期”谁也没想到会一路做到第四百期。四百期是个什么概念按平均每期译出三千到四千个中文字符来算这个系列光是正文就已经超过一百二十万字按每期对应一篇数千词的英文技术稿来算差不多等于耐着性子精读了好几本机器学习方向的外文专著。数字当然唬人真正让我觉得这个系列能活下来的是背后一套被反复捶打出来的选文逻辑、翻译规范和质检流程。这一篇就当作第四百期的交代把这些年的土办法、栽过的跟头连同现在还留在工具箱里的习惯一并倒出来。无论你是想长期做技术内容还是只想提高自己的英文精读能力都可以从里面挑几条用。1. 四百期的源头一个没人催更的系列是怎么活下来的1.1 起点只是一篇多臂老虎机的入门稿TAI 本身是一个长期更新的人工智能议题内容源几乎每天都会推送新的技术文章覆盖面从机器学习、深度学习、自然语言处理、强化学习、计算机视觉到工程落地案例和行业观察都有。它最讨巧的地方在于“两头通吃”既有保姆级新手教程也有给老手看的调参与架构分析单篇长度普遍落在三五千词左右刚好够一次通勤读完。系列第一期翻的是一篇讲多臂老虎机问题的入门稿。现在回看那篇文章内容已经足够古旧连我自己都不会再推荐别人去读。但也是从那一期开始我慢慢摸清了 TAI 的选题脾性它偏爱那些“有完整实验支撑的小问题”而不是宏大叙事的行业预言。这个认知直接决定了后来几百期的选文方向——我在前面五期里有一大半时间都在乱翻今天翻个新闻明天翻篇观点直到某位读者私信我说“你能不能多翻点能直接跑起来的文章”才第一次意识到读者要的是什么。1.2 活下来的四个原因没有一个与“坚持”有关很多人觉得做长线系列要靠意志力我的经验正好相反。这个系列能走到四百期靠的是下面四件事。第一没有商业目标和流量 KPI。从头到尾它都是个人项目不靠它吃饭所以不用追热点、不用攒标题党唯一指标就是“读者照着文里的思路真的做出来了”。第二不追热点。热点文章的半衰期只有两周翻译周期却至少要四天。等译文上线热点早凉了。我后来给自己立了条规矩宁可晚一期不翻时效性太强的东西。第三固定的节奏而不是固定的产出量。每周日抽半小时扫一遍过去一周的新投稿存下两三个候选周一早上下决心翻哪一篇周三前出初稿周五前完成质检发布。这套节奏像生物钟一样稳定忙的时候允许这周空窗但从不留下半截烂尾。第四允许自己“慢下来”。早期我总觉得每周必须翻两篇才算称职后来发现把一篇文章读三遍再动笔比读一遍就硬翻的产出质量高得多。慢反而省了返工的时间。读者群体的变化也很有意思。前一百期的读者多半是学生和转行者问题集中在“怎么看论文”“怎么入门深度学习”两百期之后在职工程师的比例明显上来了问的是“这个做法在线上预测环境里稳不稳”“推理延迟能不能接受”。这类真实反馈比任何阅读量数字都更能校准这个系列的方向。2. 选文标准每周二三十篇凭什么挑出这一篇2.1 六条筛子筛掉八成候选翻译本身并不难难的是判断“什么值得译”。每周 TAI 上能当候选的新文章有二三十篇但我通常只翻译一两篇。给不熟悉的读者解释一下我的筛选过程它其实由六条筛子组成。第一条是增量信息。文章不能只是官方文档的复读必须带有作者自己的实验痕迹或者一个文档里不会写的解释角度。凡是那种“把某个工具的手册翻译成博客体”的稿子直接淘汰。第二条是可复现性。代码、超参数、数据集全部摆在明面上才算数。如果作者写“我们取得了不错的效果”却不给配置翻出来也没法验证等于给读者看空气。第三条是内容半衰期。纯新闻类直接跳过行业趋势类文章除非里面有可以长期引用的数据和图否则也不收。我倾向于留下那些“两年后再看仍然成立”的方法论文章。第四条是引用的严谨性。干这行越久越容易发现技术稿里的错漏引用。凡是参考文献链接失效的、论文标题对不上的、数据来源语焉不详的一律不翻。理由很简单翻译会放大错误一个错的引用经过中文转述会被更多人当真。第五条是话题平衡。我给自己定过一个大概的配比训练技巧与实验分析占三分之一模型与架构解读占四分之一工程落地与工具链占四分之一剩下的留给行业观察、职业成长和伦理讨论。这样做的目的是保证长线营养均衡而不是被某一类热门话题带跑。第六条是读者需求信号。评论区或私信里被反复问到的主题优先安排。比如有一段时间连续四个人问我“怎么理解 embedding”我在两周后就安排了相关译文顺带在译者注里补充了中文语境下的常见误读。2.2 话题配比不是拍脑袋定的是读者用反馈“投”出来的上面这个比例看起来很理性实际上是被读者用脚投票投出来的。前五十期我翻了不少模型综述类文章结果阅读和收藏都不差但私信里几乎没人反馈“照着做成功了”反而是实验分析、踩坑记录类的译文隔三差五就有人回来说“按你的注释跑通了”。这让我意识到一个很关键的区别综述文章提供的是“知道感”实验文章提供的是“做成的路径”。前者读起来过瘾后者用起来有用。对一个以“读者复现成功”为核心指标的系列来说后者永远应该占更大的权重。类别代表性话题我实际采用的选文频率训练技巧与实验分析学习率调度、正则化、数据增强、知识蒸馏高约占三分之一模型与架构解读注意力机制、Transformer 变体、CNN 结构设计中高约占四分之一工程落地与工具链推理加速、模型压缩、部署中的真实踩坑中约占四分之一行业观察某个细分领域引入智能系统的案例复盘低偶尔出现职业成长与伦理入门路线、数据偏差、算法公平性讨论低按需安排表格里的频率不是一成不变的每过五十期我会重新统计一次看哪类译文的读者反馈最多、复现成功率最高然后微调配比。这套“统计驱动选文”的做法本质上是把读者当成了一个巨大的测试集。3. 术语、代码与语境技术翻译真正难啃的三块硬骨头3.1 单词好翻术语难定说句得罪人的话很多翻译腔文章“死”在第一句不是因为英文没看明白而是因为术语在中文里没有安顿好。中文机器学习术语存在大量约定俗成和方言并存的情况同一个词在不同文章里可能差出三种译法。举个最典型的例子“agent”。在强化学习语境里它指的是与环境交互并做决策的那个“智能体”。早期我按通用翻译写成“代理”结果有读者问“代理是什么是代理服务器吗”。后来社区反馈多了我在第两百期前后统一改成“智能体”并把索引里所有旧译文的相关段落都做了修订说明。这个教训让我明白术语表不是静态的词表而是一个需要持续维护的基础设施。我长期维护的术语决策表长这样节选英文术语容易踩的错译我最终采用的译法为什么这么定embedding直接不译或译成“嵌入”丢在句子里向量表示首次出现时保留英文并加注避免中文读者误以为和“嵌入网页”有关fine-tuning微调微调首次出现加注英文已是行业通译保留即可loss丢失、损耗损失函数看语境“丢失”无法体现训练中数值下降的含义attention注意力注意力机制补上“机制”二字读起来更接近技术概念coverage覆盖范围覆盖率指标语境量化指标时用“率”定性语境说“覆盖范围”benchmark基准基准测试 / 评测基准单独写“基准”会让读者猜不出是数据集还是指标vanilla香草、原味基础版 / 标准版直译“香草”会让中文读者以为在说调香这张表不是一次性建好的而是每次审核遇到新词就往上加遇到读者提出更好的译法就更新。四百期下来表里已经积累了六百多行相当于一份很个人化的“机器学习中文术语词典”。3.2 代码块是翻译的“高压线”代码块处理不好比术语错误更容易劝退读者。我的原则很简单代码本身一个字符不动但代码注释要翻译成中文。这里有个很容易翻车的细节——Python 的字符编码和缩进对外观极其敏感如果翻译注释时不小心引入了多余的半角冒号或方括号整段代码就会“好看但跑不动”。还有一类问题是“正文与代码对不上”。作者在正文里说学习率是 0.001代码里写的却是 0.0001正文说用 Adam代码里用的是 SGD。这类不一致在英文原文里经常出现因为作者改完代码忘了改正文。翻译时必须逐行对照发现不一致要在译者注里说明。我甚至遇到过整篇代码与核心结论完全矛盾的文章——那一次我在译文开头加了一段判断建议读者直接放弃运行示例只看方法部分。公式和引用的处理也属于这一步。公式一律原样保留不做任何改写但公式里用到的符号如果在上文没解释我会加一个简短的译者注补上定义。这种做法带来的额外工作量不小但对读者复现实验结果非常有帮助。3.3 语境与语气把英文的俏皮话翻成中文的明白话技术作者大多爱用口语和比喻来降低理解门槛但英文里的幽默和中文不是一一对应的。比如原文写 “this approach is a bit hacky”直译成“这种方法有点黑客”读者肯定一头雾水。我通常处理成“这个方法有点糙属于野路子但能跑”。再比如 “the model just memorizes the data”直译“模型只是记住了数据”没问题但如果上下文有讽刺意味我会补一句“也就是俗称的死记硬背”让语气自然落地。这句经验也延伸到了长句处理。英文技术写作习惯用长定语从句中文读者读三行不换气就会迷路。我的处理是超过两行的从句一律拆开主谓宾先放前面补充信息用括号或另起小句。翻译腔最典型的表现就是“为了……而……使得……”这种假文言结构我在中文回读阶段会专门把它们揪出来改掉。4. 质检流程每篇译文都过四遍手宁可慢也不可错4.1 初译带着“存疑标记”而不是通顺执念第一遍就是老老实实翻译但有一个小技巧遇到拿不准的术语或没理解透的断言不要在脑子里硬想直接在译文里打一个[存疑]标记后面加一句自己理解的猜测然后继续往下翻。这样做可以避免在单个词上卡十分钟。我的经验是一篇文章里真正需要停下来考证的地方最多只有三四处初稿阶段把“怀疑清单”列出来到第二遍统一解决效率最高。4.2 事实核验最花时间也最值钱第二遍是事实核验。所有引用链接要逐个点开确认标题、作者、年份对得上所有数据要重新算一遍或者至少和原文出处核对所有公式要顺着推导一遍看看从这步到下一步是否成立。代码能跑就跑不能跑就至少逐行走读一遍。这里分享一个真实案例。有一期讲学习率调度原文笔误写“余弦退火从 0.1 降到 1e-5”公式和文字都保持一致。按常规流程这里照抄就能通过。但我在核验引用的实现源码时发现作者仓库里的实际配置是“从 0.3 到 1e-6”正文和代码完全是两套参数。最后我在译文里加了一条译者注说明正文与源码的差异并提示读者“以源码为准”。这类事情每隔三四十期总会遇上一两次完全靠核验阶段的那点强迫症。4.3 术语统一与中文回读让译文告别翻译腔第三遍做术语统一。把术语表打开按“英文→中文”逐个检查全文同时搜一下这个系列的历史译文凡是出现过的固定译法都保持一致尤其是 “agent”、“attention”、“fine-tuning” 这类高频词。这一步做完译文在专业层面就过关了。第四遍是中文回读。我会把译文通读一遍读出声来凡是念起来拗口的地方基本就是翻译腔的重灾区。常见的病句有两类一类是长定语连环套另一类是滥用“我们”。英文技术文爱用 “we”翻成“我们”倒没错但中文里每句都“我们”就显得像念报告。我的处理是开头用一次“我们”后面全部换成“你”或者直接省略主语读者读起来会轻松很多。四遍下来一篇三千词的源稿通常要消耗八到十小时。有人觉得慢但我宁可一期少翻一篇也不愿意让带着错误的译文流出去。技术内容有一个特点错误会被复读。今天你偷的懒明天就是读者照着踩的坑。5. 第四百期之后做长线内容系列最有用的几个土办法5.1 术语表要像代码库一样维护前面说过术语表要从第一天就建这里再补充一点具体做法。我用的是一个纯文本文件加一份简单表格格式是“英文术语 中文译法 备注 首次出现的期号”。每次遇到新词先搜一遍历史译文看有没有翻过翻过就沿用没翻过就定一个新译并记下决策理由。这个文件就是整个系列的“公共依赖”任何一期都需要它才能编译通过。5.2 索引比翻译本身活得更久从第三十期开始我维护了一份索引字段包括期号、原文链接、发布日期、类别、标签、核心结论一句话。这份索引最初是为了方便查找后来发现它最大的价值是让系列文章之间产生了“内链”译者在第两百一十七期聊损失函数时可以直接在译者注里提示“参见本系列第 108 期”。当四百篇文章真正连成一张网读者搜索任何一个主题看到的就不再是孤立的一篇而是一整套由浅入深的阅读路径。5.3 批处理与订阅式更新而不是日更式消耗长期做内容的人最容易死在“每天都要产出”上。我的节奏是批量处理周一周二各翻一篇周三下午集中做事实核验周四做术语统一和中文回读周五发布。这个安排的好处是把“翻译”和“核验”两种思维模式隔离开来——前者需要发散后者需要较真混在一起会两头不讨好。5.4 让读者替你找出盲区最后一个习惯是把读者反馈当成免费的高质量测试集。每一条纠错私信我都会先记下来不做情绪反应事后的处理方式统一是确认错误、修订译文、把该条目写进第二遍核验的检查清单。到三百期以后这份“错误清单”已经积累了上百个真实案例从“术语不统一”到“引用的论文标题拼写错误”都有。它就像一本私人出的勘误备忘录比任何校对工具都管用。第四百期做下来我最想分享的个人体会只有一句别把翻译当成搬运把它当成一次再创作。技术内容会过时但对问题本质的解释不会。你多花在核验、注译和打磨上的每一分钟最后都会以读者复现成功的方式原封不动地还回来。
