这个翻译项目的起点很小，小到只是想把一篇英文文章彻底看懂。后来一篇接一篇，慢慢整理成了现在的样子：一个以 TowardsArtificialIntelligence 博客为核心的系列中文翻译，做到这一期正好是第三百四十七篇。TowardsArtificialIntelligence 在圈内常被简称 TAI，是个长期输出 AI 技术深度文章的博客，内容包括模型原理、训练心得、部署优化、工具链实践，质量整体偏高，但篇幅一般都不短，英文阅读门槛摆在那里。翻译它对我而言不是简单的语言转换，更像是对自己技术理解的一次次体检。这篇博文就拿第 347 篇的翻译经历当主线，把整个翻译项目的搭建思路、技术拆解方式、实操流程和踩过的坑都梳理一遍。无论你是想做技术文章翻译，还是想找一种更扎实的技术学习方式，这都值得参考。

1. 翻译项目是怎么搭起来的

很多人以为技术翻译就是“英文好一点就行”，真做起来才知道，差得远。英文只是入场券，真正决定译文质量的是你能否把技术逻辑吃透。在展开第 347 篇的具体拆解之前，我先把项目骨架说明白：当初为什么选这个博客，以及整个系列从选稿到发布的流程是怎么定的。

1.1 为什么是 TowardsArtificialIntelligence

中文社区其实不缺 AI 资讯，缺的是有深度的技术文章。市面上多数内容是“标题党式”的新闻聚合，或者只是论文摘要的口语化复述，读完之后除了多个印象，什么都没留下。我第一次读 TAI 上的文章时，明显感觉到它不一样：作者通常是实际在做模型训练、推理优化或工具链开发的工程人员，写的是自己踩过的坑和验证过的做法，文章里会带推导、带实验数据、带可直接复现的代码片段。这种“实践导向”的内容，恰好是中文社区长期稀缺的。

选择 TAI 还有一层原因：覆盖面足够广。从注意力机制的变体到分布式训练的策略，从部署时遇到的显存瓶颈到数据处理管线的搭建，它的选题能帮你补齐知识盲区。对我这种什么都想摸一遍的开发者来说，跟着一个稳定的技术来源做系统性输入，比零散刷几十个网站高效得多。翻译这个系列相当于给自己设了一个定时任务：每期必须跟读、必须把一篇技术文章彻底搞懂、必须用自己的语言把它重述出来。这不是效率低，这是另一种形式的“费曼学习法”。

1.2 从选稿到发布的标准流程

这个系列做到第 347 篇，中间当然走过不少弯路。一开始拿到文章就直接翻译，经常翻到一半发现某个技术细节完全没见过，不得不回头补资料，一篇长文能拖两三个星期。后来总结出一套流程，按下面八个步骤走，稳定很多：

1. 选稿。判断原文是否值得翻译，标准有三条：技术深度够不够、可复现性强不强、是否契合中文读者的需求。第 347 篇就符合这三条，它讲的是推理阶段优化，属于工程实战里大家最关心的一块。
2. 预读。第一遍通读原文，不做翻译，只做两件事：标出所有不懂的技术点，画出文章结构图。这一步决定后面翻译能不能顺畅推进。
3. 术语提取。把原文中的专业术语、模型名、论文名、缩略语全部摘出来，先查清规范译法，有歧义的专门做记录。术语不定下来，翻译时一定会翻车。
4. 初译。这一步允许牺牲部分流畅度，优先保证准确。遇到不确定的地方用特殊的标记符号标注，绝不含糊带过。
5. 技术校验。这是最容易偷懒但最不能省的一步。逐段核对公式推导、代码逻辑、实验数据是否有误译，必要时回到原文重新理解。
6. 语言润色。在保证准确的前提下，把译文改成符合中文表达习惯的技术文档，消除翻译腔。
7. 排版与发布。统一标题层级、代码块语言标注、术语表链接，确认图表清晰后发布。
8. 返稿归档。译文发布后，把原文链接、译文链接、翻译日期、术语记录归档到索引里，方便后续检索。

这套流程看着繁琐，但真正跑起来以后，单篇平均耗时反而下降了。原因是术语库和翻译风格在持续积累，后面文章里出现的很多概念，前几篇已经翻过，不用再重新折腾一遍。

2. 以第 347 篇为例：拆解一篇 AI 技术文章

每一篇文章的翻译都是一次迷你项目。下面用第 347 篇作为例子，讲讲拿到一篇 AI 技术长文后，我是怎么拆解它的。这一期的原文主题落在语言模型推理阶段的 KV Cache 优化上。这类文章在 TAI 博客里很常见：抛出一个实际问题，给出现有方案的分析，讲清楚自己的做法，再用实验数据收尾。翻译这类文章，技术理解能力比英文能力更重要。

2.1 文章的技术主线与结构分析

先说这篇原文的大致结构，典型的长文四段式。开头介绍推理阶段为什么慢：语言模型在生成时是逐 token 输出的，每生成一个新 token，都要重新读取之前所有 token 对应的 Key 和 Value，自注意力机制的计算开销随序列长度线性增长。针对这个问题，工程上普遍采用 KV Cache 技术，把前面已经计算好的键值对缓存下来，避免重复计算。这一部分属于背景铺垫，术语相对集中，但概念密度也不低。

第二段进入原理推导，解释 KV Cache 的存储结构和更新方式：预填充阶段（prefill）并行处理所有输入 token 并生成初始缓存；自回归生成阶段（decode）逐 token 更新缓存，同时从缓存中读取历史信息计算注意力分数。这一段是整个文章中翻译难度最高的地方，涉及注意力分数的计算式、缓存张量的维度变化，以及新增计算量与数据搬运量之间的权衡。里面反复出现的 memory-bound（内存带宽受限）这个概念，英文读者一眼能懂，中文读者如果不加解释，很容易理解成“内存不够用”或“内存出错”，这是翻译时最容易埋下的坑。

第三段讲工程实现技巧，包括缓存如何组织、批次大小如何影响缓存命中率、量化缓存值带来的精度损失。最后一段是实验对比，展示不同策略下的吞吐量变化与显存占用变化。翻译这一段必须保持严谨：所有数字、单位、坐标轴标注都不能错，任何一个数值错误都会让整篇文章失去可信度。

拆解下来你会发现，这类文章本质上是由“概念、推导、代码、实验”四个模块搭成的，模块之间的翻译策略完全不同。

2.2 翻译时要盯住的四个关键环节

结合第 347 篇的翻译经历，我梳理出四个最需要留意的环节。

第一个环节是核心术语的首次出场。术语第一次出现时，是建立“中文命名”的关键时刻。第 347 篇里“prefill 阶段”和“decode 阶段”同时出现，我把后者译为“逐 token 生成阶段”，而不是生硬地音译为“解码阶段”。为什么这么选？因为“解码”在中文语境里容易被联想到传统编码解码，但这里的实际流程是把前面算好的缓存逐个喂给模型生成新词，用“逐 token 生成”能更准确传递这个过程。术语翻译不是找一个“看起来对”的对应词，而是要让读者在读完上下文后能直接建立正确的技术直觉。

第二个环节是抽象概念的生活化转述。KV Cache 这个概念，直接说“缓存键值对”也不是不行，但理解门槛还在。我在译文的补充说明里打了个比方：KV Cache 就像提前备菜，做饭的时候先把菜洗净切好放进冰箱，之后每炒一道菜就直接取用，不用重新洗一遍。用这个类比带读者建立直觉，再回到具体的技术描述，理解成本会低很多。

第三个环节是公式与文字的衔接口。英文写作里公式常常嵌套在句子中间，主谓宾结构清晰，直译成中文会很别扭。典型情况是原文写“given the stored KV pairs, the attention score is computed as ...”，直译成“给定存储的 KV 对，注意力分数被计算出为……”完全不像中文。我处理时会把公式从句中抽出来，改成“在拿到缓存中的 KV 对之后，注意力分数的计算方式如下”，把被动语态拆掉，让公式自己当主角。

第四个环节是代码块的注释和逻辑标注。AI 技术文章里的代码通常不是完整可运行的项目，而是表达算法细节的伪代码。翻译伪代码时，变量名和函数名保持原样，注释必须翻译，但更重要的是在代码块前加一段中文导语，告诉读者这段代码在算法的哪个环节出现。例如第 347 篇里有一段 KV Cache 的更新伪代码，我加了这样的导语：下面的伪代码展示的是 decode 阶段缓存更新的最小逻辑，head 维度的增删被省去了，重点看两个分支——读取旧缓存和追加新缓存。

3. 实操记录：一篇译文从英文到中文的完整路径

思路说完了，具体怎么落笔？这一节记录一次相对完整的翻译实操过程，包含术语表怎么建、长难句怎么处理、图表和代码怎么本地化，每一步配一个能直接抄作业的示例。

3.1 术语库：先定标准再动手

做技术翻译最容易犯的错，是翻译到一半发现同一个概念在前面出现了别的译法。第 347 篇这种技术文章尤其如此，“key”“query”“value”“token”“inference”这些词，在上下文中各有一个最合适的译法，但顺口一翻很容易一会儿“键”、一会儿“密钥”、一会儿“Key 键”。我现在的做法是动笔前先建一张术语表，只放这篇里高频出现、容易出歧义的词。第 347 篇我当时建的术语表大概是这个样子的：

这张表不是一次性做完的。每翻一段，遇到底部出现的新术语，我会回填进去，并把术语表放在正文之前，读者阅读时能随时对照。这样做的好处是：正文里可以放心用阶段性简写，术语表维持最精准的表达，两边不冲突。

3.2 长难句的拆分与中文重组

英文技术写作有个习惯，喜欢把条件、前提、结果全部塞进一个长句。第 347 篇里有一句，大意是说“在序列长度不断增长、单条背景下一次性缓存全部历史键值对不再可行的场景下，普遍采用的替代方案是将缓存内容有选择性地淘汰，以便让内存占用维持在一个可接受的区间”。如果按英文语序硬翻，中文读者会被“的”字套得喘不过气。

我的处理分三步。第一步拆出句子的主干：场景不行了，所以采用替代方案。第二步拆出修饰条件：场景是什么场景？序列长度不断增长、缓存全部历史键值对不可行。替代方案是什么？有选择地淘汰缓存内容。第三步用中文叙事逻辑重组：先交代背景矛盾——序列越长，一次性缓存全部历史键值对越不可行；再给结论——于是引入了缓存淘汰策略，把内存占用控制在一个可接受的范围；最后补一句翻译时的解释性说明——这里的“淘汰”指丢弃部分早期 token 对应的缓存。重组后的译文仍然保持原文信息增量，但读起来不再需要反复翻看前文。

长难句处理是翻译质量的分水岭。很多机械翻译输出的内容也“没有错”，但就是不像人话，根源就在于没有完成从英文分支结构到中文线性结构的转换。你可以把这套三步法当作标准动作做成一个自查清单：句子是否超过两行？主干是否明确？修饰条件是否后置？如果都符合，说明还没有拆分到位。

3.3 图表、公式与代码的本地化处理

技术文章里的图表、公式和代码，是翻译的“半自动区域”。先说公式。数学式子本身不需要翻译，符号含义也不需要改，但公式前后的引导句必须准确。比如原文写“the cache size is proportional to the input length”，我翻译成“缓存大小与输入长度成正比”，这里不能加个人理解去发挥，原文说什么就译什么。

图表处理是最容易被忽略的一环。TAI 博客的文章里时不时会有性能对比图，坐标轴、图例、标签全英文。我的做法是：坐标轴和图例必须翻译，因为读者要看懂数据含义；但图内小数字比如刻度、坐标值一律保留原样，避免不小心改错数据。在实践里发现，图表文字翻译完以后，要在图片下方加一段“读图指南”，用一两句话点出图里最关键的对比关系，这对中文读者非常友好。

代码块处理有一点要特别提醒：代码逻辑不能动，注释必须全译，但遇到非常口语化的注释词，比如“Keep it simple here”，不要直译成“这里保持简单”，应该转换成中文程序员习惯的表达方式——“此处简化处理”。更进一步的优化是给代码块加“前导说明”。第 347 篇的代码块我一般在代码上方加三四行说明性文字，交代代码的运行环境、输入输出是什么、这段代码要验证什么假设。这样代码块不再是孤零零的英文伪代码，而成为文章叙事的一部分。

4. 常见问题与排查技巧实录

做了三百多篇翻译，踩过的坑可以写成一本书了。这一节挑出现频率最高、对质量影响最大的三个问题，附上排查思路和解决办法。每个问题都不是一次性解决的，但经过几轮的修正，现在基本能在一开始就避开。

4.1 术语不统一这个老问题

早期做技术翻译时，最常被读者挑刺的就是术语不统一。同一篇文章里，前面叫“注意力分数”，后面叫“注意力权重”；前一篇叫“梯度累积”，后一篇叫“梯度累加”。问题根源不在单词不认识，而在于没有在一开始锁定全系列术语标准。我在第 80 篇左右才开始正式建术语表，当时花了两个晚上把前面所有译文的关键词统一替换了一遍，工程量巨大。现在每翻一篇新文章之前，都会先查询历史索引里这个术语是否已经出现过，有过就沿用，没有才新建。

如果你是团队协作式翻译，这个问题更严重。后来我观察到，多人协作时术语很容易“各自为政”，同一个 Transformer 概念在三个人手下变成三种中文。应对办法是强制要求每个成员在动笔前先查共享术语表，校对阶段再专门检查一遍术语一致性。这个步骤单次耗时不大，但能避免返工带来的巨大时间成本。

4.2 上下文缺失带来的翻译偏差

英文技术文章经常依赖上下文省略主语，比如“we set the batch size to 32”，后面再用“the setting is also used in ...”指代前面的设置。直译时，如果你没把“the setting”还原成“批大小设置为 32 这个配置”，中文就会变成“这个设置也被用于……”，读者完全不知道“这个”指什么。对此我的排查习惯是：初译完成后，从头到尾只读中文译文，凡是发现“这”“那”“其”这些指示词却找不到明确指代对象的，全部替换为指代完整的名词短语。这个过程有点笨，但效果很好。

上下文还有一个容易踩的点是交叉引用。技术文章里经常有“see Figure 3”或“as discussed in the previous section”这类指路词。翻译时我会顺手把“Figure 3”改成“图 3”，把“我们前面提到”改成“第 2 节提到过”，尽可能让中文读者不需要跳到英文原文去对图号。

4.3 译文发布后的反馈与更正

技术领域的知识更新太快。一篇比较早的译文里讲的是缓存量化方案，后来社区试验发现有精度问题，作者也在原文里修订了结论。这时候译文如果原地不动，就成了一篇过时内容。我处理这个问题的方式是建立“译文更新标记”：原文章有重大修订时，译文会通过索引文件标上“修订日期”，并补上一段译者说明，向读者交代旧方案存在的问题和新方案的指向。这个机制虽然不复杂，但坚持下来后发现一个好处——老读者会更愿意阅读这个系列的译文，因为他们知道译者不只是“搬文章”，还在跟随技术演进做内容维护。

反馈机制本身也很重要。我发现最有价值的信息往往来自两类人：一类是第一次接触这个技术细节的初学者，他们会指出译文中概念解释不够直观；另一类是深度研究者，他们会给出术语上的精确修正建议。整理这些反馈并归档，等于给译文做了长期质量巡检。至少对我而言，别人的一个追问，比我自己读三遍译文更能发现问题。

5. 翻译到第 347 篇后的几点心得

写到这里，聊点不那么技术性的内容。翻译一个系列到三百多篇，坚持下来最大的收获不是词汇量，而是对技术理解深度的重塑。这节内容不空谈情怀，分享几个具体的体会和建议，给想尝试技术翻译的朋友做参考。

5.1 翻译为什么是最笨也最有效的精读方式

很多人问我：读论文和翻译论文，效果差多少？我觉得差别非常明显。读原文时，很容易“自以为懂了”——那些公式和术语在眼前过了一遍，大脑会自动补全理解，但说不出来到底懂了多少。翻译则完全相反，你得把每一句话用中文重新表达出来，任何一个模糊地带都会卡壳。每当卡壳时，你就知道自己对这段技术逻辑的理解有了盲区，不得不回头重读原文或者查资料。这个“被迫回头”的过程，就是技术精读的核心价值。

我自己的体会是，做了十几篇翻译之后，英文阅读速度提高了不少，但更关键的是“技术盲区被系统性地清扫了一遍”。很多概念以前看综述文章时觉得很简单，真正翻译技术文章才知道里面细节多到吓人。如果你有耐心做一次完整的系列翻译，我强烈建议选一个自己关注但又不完全熟悉的领域，效果比重复阅读十篇综述都来得扎实。

5.2 给想入坑技术翻译的朋友几个建议

第一，别从太硬核的论文翻译开始。先找几篇实践导向的技术博客来练手，因为它们的语言更接近工程表达，术语密度相对适中，容易建立信心。第二，建立自己的术语库，哪怕只有十几个词也比没有强。第三，千万不要追求“逐字精确”，技术翻译的优先级是准确传达逻辑，而不是字字对应。英文和中文的表达习惯差异很大，一旦陷入字字对应的思路，译文会变得生硬难读。第四，发布译文时必须标注原文链接。技术内容有原作者的知识贡献，翻译是二次创作，链接是基本的尊重，也是读者查证的入口。

最后再分享一个小技巧：翻译一篇长文时，我一般先把图表、代码块、公式标题翻译完，再翻译正文。这样做的原因是，图表和代码往往包含文章最核心的信息，先把这些模块定下来，正文翻译时遇到具体引用就不会前后矛盾。这算是我坚持了快一百篇才沉淀下来的习惯，实际执行时会发现，正文翻译意外的顺畅，因为最难的技术骨架已经被你先啃下来了。