英文技术文档读得慢，多半不是英语问题

读了十几年英文文档（Javadoc、Spring 官方指南、各种 RFC），回头想，真正拖慢阅读速度的从来不是词汇量，而是几个工程性的摩擦。把我后来调顺的做法整理一下。

摩擦一：逐句查词打断的不是阅读，是上下文

很多人读英文文档的习惯是遇到生词就切到词典查一下。单次开销不大，但代价是工作记忆被打断——回来之后往往要把前半句重读一遍。一段文档读二十分钟，其中十五分钟花在「回到哪了」。

后来我改成整段对照：先把一段读完（允许有词不认识），再看对照译文确认理解，最后只把反复出现的生词记下来。查词次数从每页十几次降到两三次，关键是上下文没断。

摩擦二：术语不统一比生词更致命

生词只是慢，术语不一致是错。同一个文档里 orchestrator 一会儿译「编排器」一会儿译「调度器」，读者会以为这是两个组件。我自己读文档时吃过亏，做工具时就把它当成硬需求：术语表在翻译之前建，而不是读完再整理。高频名词短语先扫出来定死译名，后面整篇统一。

这个思路对人工阅读同样成立：开始读一篇长文档前，先花五分钟把领域词过一遍（README 的术语节、或者项目的 glossary），收益贯穿全文。

摩擦三：双栏对照的位置感

对照阅读最大的痛点其实是「对位」：译文在旁边或下面，眼睛来回跳，找位置的时间超过读的时间。我的经验是对照单元要小——按段落对齐，不要按页。段落级对齐后，译文可以放心跳读，原文位置永远一目了然。

机器翻译的边界

这三年模型翻译的质量已经能扛文档阅读的大部分工作，但有两块要留给自己：

1. 代码块和命令行参数：机器翻译偶尔会「好心」处理代码内的字符串，读的时候要警惕译文里被改动的标识符
2. 歧义句的取舍：模型对歧义句会替你做选择，而做文档阅读的人恰恰需要知道哪里有歧义

所以我的工作流是：机器翻整篇 → 对照读 → 术语和歧义点手动标注。机器负责 80% 的转换，人负责 20% 的判断，这个比例下速度和理解深度都能保住。

结语

这些做法最后攒成了我做的一个翻译小工具（随心翻译，浏览器插件），核心就是上面三条：整篇对照、术语表前置、段落级对位。工具是次要的，思路是主要的——英文文档读得慢的时候，先检查是不是摩擦没除掉，而不是急着背单词。