1. 从一篇翻译博客说起为什么人工翻译AI内容仍然值得做做技术内容翻译这件事我从几年前就开始断断续续地做。最初的想法很简单英文技术博客里有很多好东西但语言门槛把大部分人挡在外面。机器翻译虽然越来越强但技术类内容有个特点——术语密度高、上下文依赖强、很多表达是“圈内黑话”机翻经常翻得让人哭笑不得。所以当我看到“Towards Artificial Intelligence 博客中文翻译”这个系列做到第二百六十二篇的时候第一反应是这个工作量不小而且能坚持到这个数量说明背后有一套相对成熟的流程。这篇要聊的就是围绕这个翻译项目展开的完整拆解。我会从整体设计思路、核心翻译流程、实操环节、常见问题排查几个维度把“技术博客翻译”这件事讲透。适合谁看如果你正在做技术内容本地化、想搭建自己的翻译工作流、或者单纯好奇一篇英文AI博客是怎么变成中文读者能看懂的文章这篇内容应该能给你一些可以直接抄作业的东西。核心关键词先摆出来技术博客翻译、AI内容本地化、术语一致性、翻译工作流、人工校对。这些词会贯穿全文也是整个项目的骨架。翻译一篇技术博客和翻译一篇新闻、一篇小说完全是两码事。新闻讲究时效和通顺小说讲究文笔和意境技术博客讲究的是准确、一致、可复现。一个术语翻错了读者照着操作就会出问题同一个概念前后翻法不一致读者就会困惑“这到底是不是同一个东西”。所以这个项目的核心目标不是“翻得漂亮”而是“翻得对、翻得稳、翻得让人能照着做”。2. 整体设计与思路拆解为什么不用全自动机翻2.1 机翻人工校对的混合模式很多人第一反应是现在机翻这么强直接丢进去不就行了我试过而且试过很多次。结论是技术类内容纯机翻可用率大概在六成左右。剩下的四成里有一部分是术语翻错有一部分是语序混乱导致逻辑断裂还有一部分是机翻完全无法处理的“文化梗”和“圈内表达”。所以这个项目采用的是机翻打底人工精校的混合模式。具体来说先用翻译引擎跑一遍初稿然后人工逐段核对。这样做的好处是效率比纯人工高很多同时质量又比纯机翻高出一大截。关键在于人工校对不是“重翻一遍”而是“在机翻基础上做修正和润色”这个定位很重要决定了整个流程的节奏。为什么不全人工因为二百六十二篇的体量摆在那里纯人工翻译一篇三千词的博客熟练译者也要四到六个小时全部人工根本不现实。为什么不全机翻因为技术博客的读者是来学东西的翻错了会误导人这个责任担不起。混合模式是在效率和质量之间找到的平衡点。2.2 术语库先行避免“一词多译”这个项目做到二百多篇还能保持质量稳定核心秘诀之一是术语库。在开始翻译之前先建立一份术语对照表把AI领域的常见术语固定下来。比如“neural network”统一翻成“神经网络”“gradient descent”统一翻成“梯度下降”“transformer”统一翻成“变换器”或者根据语境保留英文。术语库不是一次建好就完事的而是随着翻译过程不断补充。每遇到一个新术语先查有没有既定译法没有的话就确定一个然后录入术语库。这样后面再遇到同一个词直接调用不会出现“这篇翻成A下篇翻成B”的情况。提示术语库建议用表格管理至少包含三列——英文原词、中文译法、备注比如“首次出现时保留英文原词”。这个表格可以放在在线文档里方便多人协作时同步更新。2.3 风格指南让二百六十二篇读起来像一个人翻的除了术语库还需要一份风格指南。技术博客翻译的风格指南主要规定几件事人称怎么用“我们”还是“你”、代码和命令怎么处理保留原文还是加注释、长句怎么断英文长句翻成中文要不要拆、标题怎么翻直译还是意译。这个项目做到二百六十二篇风格指南肯定已经迭代了很多版。我的经验是风格指南不用一开始就写得很完美先定几条大原则然后在实践中不断补充。比如遇到“you”怎么翻一开始可能没规定翻了几篇发现有的地方翻成“你”有的地方翻成“您”有的地方翻成“读者”这就乱了。这时候就要定下来技术博客统一用“你”亲切且不啰嗦。3. 核心细节解析与实操要点一篇博客的翻译全流程3.1 预处理读懂原文再动手拿到一篇英文博客不要急着丢进翻译引擎。先通读一遍搞清楚几个问题这篇文章在讲什么核心论点是什么有哪些关键术语有没有代码块、图表、公式作者的写作风格是偏学术还是偏口语这一步看起来费时间但实际上能省下后面大量返工的时间。因为如果你不理解原文机翻出来的东西你根本判断不了对错。比如原文说“this approach scales well”机翻可能翻成“这种方法扩展得很好”但如果你不理解上下文就不知道这里的“scales”指的是“可扩展性”还是“规模化”翻法是不一样的。通读的时候顺手把关键术语标出来查一下术语库里有没有。没有的话先确定译法。代码块和命令单独标记这些内容通常保留原文只翻译注释部分。3.2 机翻初稿选对引擎分段处理机翻引擎的选择上我的经验是不要只用一个。不同引擎在不同类型的文本上表现不一样。有的引擎对技术术语处理得好有的引擎对长句拆分做得好。实际操作中可以先用一个引擎跑一遍遇到明显不通顺的段落换另一个引擎再跑一次对比取优。分段处理很重要。技术博客通常有很多小标题和短段落如果整篇丢进去机翻很容易把上下文搞混。建议按段落或按小节分段翻译这样每段的上下文更清晰翻出来的质量更高。代码块的处理要特别注意。机翻引擎有时候会把代码里的变量名也翻掉这是绝对不能接受的。所以代码块要么提前抽出来不参与翻译要么翻译后逐行核对确保代码原封不动。3.3 人工精校三个层次的检查人工精校是整个流程中最耗时的环节但也是最关键的。我通常分三个层次来做第一层准确性检查。逐句对照原文和译文看意思有没有翻错、翻漏、翻多。技术博客里经常有“not”“only”“except”这类词机翻有时候会漏掉导致意思完全相反。这一层要特别仔细。第二层术语一致性检查。把译文里的术语和术语库对照看有没有不一致的地方。同时检查同一篇文章内部同一个概念有没有前后翻法不同。第三层可读性润色。前两层过了之后再通读一遍译文看有没有拗口的地方、有没有机翻腔、有没有长句需要拆分。这一步的目标是让译文读起来像中文原创而不是“翻译过来的”。注意润色的时候不要过度发挥。技术博客的翻译要忠实原文不能为了通顺而改变原意。遇到拿不准的地方宁可保留原文的表述方式也不要自作主张。3.4 代码与命令的专项处理技术博客里代码和命令是重头戏处理不好读者直接照着敲就会出错。我的做法是代码块整体保留原文包括缩进、注释符号、变量名。代码中的注释可以翻译但要用注释符号标清楚不能直接替换代码。命令行示例保留原文但在必要的地方加中文说明。输出结果如果包含英文提示信息保留原文必要时在括号里加中文解释。这一步的检查方法是把译文里的代码块复制出来和原文的代码块做逐字符对比。听起来很笨但确实能避免很多低级错误。4. 实操过程与核心环节实现从零搭建翻译工作流4.1 工具链选型与配置这个项目的工具链不需要很复杂核心就是几个东西翻译引擎、术语库、风格指南、版本管理。翻译引擎用网页版或API都行看个人习惯。术语库用在线表格方便随时查和改。风格指南用文档写放在同一个文件夹里。版本管理用Git或者简单的文件夹命名规则比如“第262篇_初稿”“第262篇_校对稿”“第262篇_终稿”。如果要做长期项目建议把术语库和风格指南放在云端这样换电脑也能用。翻译引擎的API key要保管好不要泄露。4.2 单篇翻译的完整操作步骤以这篇“第二百六十二篇”为例完整流程如下通读原文花十五到二十分钟通读一遍标记术语和难点。查术语库把标记的术语逐个查术语库确定译法。新术语录入。分段机翻按小节分段逐段丢进翻译引擎得到初稿。人工精校第一层逐句对照检查准确性。这一步最耗时一篇三千词的博客大概需要一到两个小时。人工精校第二层检查术语一致性对照术语库逐项核对。人工精校第三层通读润色调整语序和表达让译文更自然。代码专项检查逐字符对比代码块。终稿排版统一标题格式、列表格式、引用格式确保和系列其他文章一致。归档终稿存入项目文件夹术语库和风格指南如有更新同步保存。这个流程走下来一篇三千词的博客大概需要三到四个小时。二百六十二篇就是八百到一千小时的工作量确实是个长期项目。4.3 批量处理的效率技巧如果一次要处理多篇可以做一些批量优化。比如把多篇博客的术语先统一查一遍一次性更新术语库。机翻初稿可以批量跑但人工精校必须逐篇做不能批量。排版可以用模板把固定的格式比如标题层级、代码块样式做成模板直接套用。提示批量处理的时候要注意不同博客的上下文不一样同一个术语在不同语境下可能需要不同的译法。所以术语库要留“备注”列记录特殊语境下的处理方式。5. 常见问题与排查技巧实录5.1 术语翻错最常见的坑术语翻错是技术博客翻译中最常见的问题也是最容易误导读者的。比如“supervised learning”翻成“监督学习”是对的但“unsupervised learning”如果翻成“无监督学习”在某些语境下可能不够准确更准确的译法是“无监督学习”或“非监督学习”需要根据领域惯例来定。排查方法建立术语库翻译前查、翻译后核。遇到拿不准的术语查权威资料或请教领域内的人。5.2 长句逻辑断裂机翻的典型问题英文技术博客喜欢用长句一个句子套三四个从句。机翻经常处理不好这种句子翻出来的中文读起来像“翻译腔”逻辑关系模糊。解决方法人工精校时把长句拆成短句用“因为”“所以”“但是”“而且”这类连接词把逻辑关系显性化。但要注意拆分不能改变原意只是让表达更符合中文习惯。5.3 代码块被误翻低级但致命机翻引擎有时候会把代码块里的变量名、函数名也翻掉比如把“get_user_input”翻成“获取用户输入”。这种错误如果没检查出来读者照着敲代码就会报错。排查方法代码块提前抽出来不参与机翻。或者机翻后逐字符对比。这个步骤不能省。5.4 风格不统一系列文章的通病二百六十二篇博客如果风格不统一读者读起来会很割裂。比如有的文章用“你”有的用“您”有的用“读者”有的文章代码块保留英文有的翻译了注释。解决方法风格指南要明确每篇终稿都要对照风格指南检查。新加入的译者要先读风格指南再开始翻译。5.5 常见问题速查表问题类型典型表现排查方法预防措施术语翻错同一术语前后译法不同对照术语库逐项核对翻译前查术语库新术语及时录入长句断裂译文逻辑模糊读不通逐句对照原文拆分长句机翻后重点检查长句代码误翻变量名、函数名被翻译逐字符对比代码块代码块提前抽出不参与机翻风格不统一人称、格式前后不一致对照风格指南检查每篇终稿必须过风格检查漏翻多翻意思和原文有出入逐句对照重点检查否定词精校第一层专门做准确性检查6. 翻译之外的思考这件事的长期价值做技术博客翻译表面上是语言转换实际上是在做知识搬运。英文世界里的AI技术内容更新快、质量高但语言门槛把很多人挡在外面。翻译这件事的价值就是把这扇门打开让更多人能接触到前沿内容。从项目管理的角度看二百六十二篇的积累本身就是一笔资产。术语库、风格指南、翻译流程这些都是可以复用的。如果以后要做其他领域的技术翻译这套东西可以直接迁移过去。从个人成长的角度看翻译技术博客是学习AI知识的好方法。因为你要翻得对就必须理解原文要理解原文就必须搞懂技术原理。翻着翻着很多概念就自然记住了。我自己的很多AI知识就是通过翻译和校对积累起来的。提示如果你也想做技术翻译建议从自己熟悉的领域开始。熟悉领域意味着你有判断力能看出机翻的错误也能把术语翻准。不要一上来就挑战完全陌生的领域那样很容易翻车。最后分享一个我自己的小习惯每翻完一篇我会把这篇的核心知识点用自己的话总结成三到五条记在一个单独的笔记里。这样做的好处是翻译不只是“过一遍”而是真正留下了东西。二百六十二篇下来这个笔记本身就是一份不错的学习资料。
