做技术翻译这件事，说实话一开始我没把它当成什么正经事。五年前某天晚上，我刷到一篇讲强化学习入门的外文博客，看完觉得写得真不错，随手把其中几段翻译好丢到群里分享。本意只是抛砖引玉，结果评论区追着问下一期什么时候出。就这样，一个叫 TowardsArtificialIntelligence 博客中文翻译（下称 TAI 系列）的专栏草草开张——当年那句“下一期”，谁也没想到会一路做到第四百期。

四百期是个什么概念？按平均每期译出三千到四千个中文字符来算，这个系列光是正文就已经超过一百二十万字；按每期对应一篇数千词的英文技术稿来算，差不多等于耐着性子精读了好几本机器学习方向的外文专著。数字当然唬人，真正让我觉得这个系列能活下来的，是背后一套被反复捶打出来的选文逻辑、翻译规范和质检流程。这一篇就当作第四百期的交代，把这些年的土办法、栽过的跟头，连同现在还留在工具箱里的习惯，一并倒出来。无论你是想长期做技术内容，还是只想提高自己的英文精读能力，都可以从里面挑几条用。

1. 四百期的源头：一个没人催更的系列是怎么活下来的

1.1 起点只是一篇多臂老虎机的入门稿

TAI 本身是一个长期更新的人工智能议题内容源，几乎每天都会推送新的技术文章，覆盖面从机器学习、深度学习、自然语言处理、强化学习、计算机视觉，到工程落地案例和行业观察都有。它最讨巧的地方在于“两头通吃”：既有保姆级新手教程，也有给老手看的调参与架构分析；单篇长度普遍落在三五千词左右，刚好够一次通勤读完。

系列第一期翻的，是一篇讲多臂老虎机问题的入门稿。现在回看那篇文章，内容已经足够古旧，连我自己都不会再推荐别人去读。但也是从那一期开始，我慢慢摸清了 TAI 的选题脾性：它偏爱那些“有完整实验支撑的小问题”，而不是宏大叙事的行业预言。这个认知直接决定了后来几百期的选文方向——我在前面五期里有一大半时间都在乱翻，今天翻个新闻，明天翻篇观点，直到某位读者私信我说“你能不能多翻点能直接跑起来的文章”，才第一次意识到读者要的是什么。

1.2 活下来的四个原因，没有一个与“坚持”有关

很多人觉得做长线系列要靠意志力，我的经验正好相反。这个系列能走到四百期，靠的是下面四件事。

第一，没有商业目标和流量 KPI。从头到尾它都是个人项目，不靠它吃饭，所以不用追热点、不用攒标题党，唯一指标就是“读者照着文里的思路真的做出来了”。

第二，不追热点。热点文章的半衰期只有两周，翻译周期却至少要四天。等译文上线，热点早凉了。我后来给自己立了条规矩：宁可晚一期，不翻时效性太强的东西。

第三，固定的节奏，而不是固定的产出量。每周日抽半小时扫一遍过去一周的新投稿，存下两三个候选；周一早上下决心翻哪一篇；周三前出初稿；周五前完成质检发布。这套节奏像生物钟一样稳定，忙的时候允许这周空窗，但从不留下半截烂尾。

第四，允许自己“慢下来”。早期我总觉得每周必须翻两篇才算称职，后来发现把一篇文章读三遍再动笔，比读一遍就硬翻的产出质量高得多。慢反而省了返工的时间。

读者群体的变化也很有意思。前一百期的读者多半是学生和转行者，问题集中在“怎么看论文”“怎么入门深度学习”；两百期之后，在职工程师的比例明显上来了，问的是“这个做法在线上预测环境里稳不稳”“推理延迟能不能接受”。这类真实反馈，比任何阅读量数字都更能校准这个系列的方向。

2. 选文标准：每周二三十篇，凭什么挑出这一篇

2.1 六条筛子，筛掉八成候选

翻译本身并不难，难的是判断“什么值得译”。每周 TAI 上能当候选的新文章有二三十篇，但我通常只翻译一两篇。给不熟悉的读者解释一下我的筛选过程，它其实由六条筛子组成。

第一条是增量信息。文章不能只是官方文档的复读，必须带有作者自己的实验痕迹，或者一个文档里不会写的解释角度。凡是那种“把某个工具的手册翻译成博客体”的稿子，直接淘汰。

第二条是可复现性。代码、超参数、数据集全部摆在明面上才算数。如果作者写“我们取得了不错的效果”却不给配置，翻出来也没法验证，等于给读者看空气。

第三条是内容半衰期。纯新闻类直接跳过；行业趋势类文章除非里面有可以长期引用的数据和图，否则也不收。我倾向于留下那些“两年后再看仍然成立”的方法论文章。

第四条是引用的严谨性。干这行越久，越容易发现技术稿里的错漏引用。凡是参考文献链接失效的、论文标题对不上的、数据来源语焉不详的，一律不翻。理由很简单：翻译会放大错误，一个错的引用经过中文转述，会被更多人当真。

第五条是话题平衡。我给自己定过一个大概的配比：训练技巧与实验分析占三分之一，模型与架构解读占四分之一，工程落地与工具链占四分之一，剩下的留给行业观察、职业成长和伦理讨论。这样做的目的是保证长线营养均衡，而不是被某一类热门话题带跑。

第六条是读者需求信号。评论区或私信里被反复问到的主题，优先安排。比如有一段时间连续四个人问我“怎么理解 embedding”，我在两周后就安排了相关译文，顺带在译者注里补充了中文语境下的常见误读。

2.2 话题配比不是拍脑袋定的，是读者用反馈“投”出来的

上面这个比例看起来很理性，实际上是被读者用脚投票投出来的。前五十期我翻了不少模型综述类文章，结果阅读和收藏都不差，但私信里几乎没人反馈“照着做成功了”；反而是实验分析、踩坑记录类的译文，隔三差五就有人回来说“按你的注释跑通了”。

这让我意识到一个很关键的区别：综述文章提供的是“知道感”，实验文章提供的是“做成的路径”。前者读起来过瘾，后者用起来有用。对一个以“读者复现成功”为核心指标的系列来说，后者永远应该占更大的权重。

表格里的频率不是一成不变的，每过五十期我会重新统计一次，看哪类译文的读者反馈最多、复现成功率最高，然后微调配比。这套“统计驱动选文”的做法，本质上是把读者当成了一个巨大的测试集。

3. 术语、代码与语境：技术翻译真正难啃的三块硬骨头

3.1 单词好翻，术语难定

说句得罪人的话：很多翻译腔文章“死”在第一句，不是因为英文没看明白，而是因为术语在中文里没有安顿好。中文机器学习术语存在大量约定俗成和方言并存的情况，同一个词在不同文章里可能差出三种译法。

举个最典型的例子：“agent”。在强化学习语境里，它指的是与环境交互并做决策的那个“智能体”。早期我按通用翻译写成“代理”，结果有读者问“代理是什么，是代理服务器吗”。后来社区反馈多了，我在第两百期前后统一改成“智能体”，并把索引里所有旧译文的相关段落都做了修订说明。这个教训让我明白：术语表不是静态的词表，而是一个需要持续维护的基础设施。

我长期维护的术语决策表长这样（节选）：

这张表不是一次性建好的，而是每次审核遇到新词就往上加，遇到读者提出更好的译法就更新。四百期下来，表里已经积累了六百多行，相当于一份很个人化的“机器学习中文术语词典”。

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 让读者替你找出盲区

最后一个习惯是把读者反馈当成免费的高质量测试集。每一条纠错私信我都会先记下来，不做情绪反应，事后的处理方式统一是：确认错误、修订译文、把该条目写进第二遍核验的检查清单。到三百期以后，这份“错误清单”已经积累了上百个真实案例，从“术语不统一”到“引用的论文标题拼写错误”都有。它就像一本私人出的勘误备忘录，比任何校对工具都管用。

第四百期做下来，我最想分享的个人体会只有一句：别把翻译当成搬运，把它当成一次再创作。技术内容会过时，但对问题本质的解释不会。你多花在核验、注译和打磨上的每一分钟，最后都会以读者复现成功的方式，原封不动地还回来。