海外远程开发岗的价是国内的两倍多，英语是那道闸

上个月想搞清楚一个 AI 接口的某个参数到底怎么传，中文搜出来十几条结果，点进去内容几乎一样，都是从同一篇一年前的博客抄的，而那篇博客写的用法在新版本里已经改了。最后是翻官方英文文档，加上啃一条 GitHub issue 里维护者的回复，才把这事弄明白，前后多花了大概一个小时。

这种事一年里会碰上很多回。碰多了我就在盘算一个问题：要不要干脆花点时间，把英语认真补到「能用」。

这里说的补英语，不是背单词考试，是三件具体的事：能直接读英文的一手文档和源码注释，能在开源项目里提 issue、跟维护者来回讨论，能跟海外的客户或同事开英文会、写英文需求。对一个已经在上班的人来说，补到这个程度大概是几百个小时的投入。

值不值这几百小时，我后来想明白了一条判断标准。

英语对写代码的人是不是必需，得先看一件事：你走不走海外那条线。

海外那条线上，有三样东西的入口都是英文，没有别的路绕过去。

一是远程岗。按 arc.dev 和 jobicy 今年的薪资统计口径，美国的远程开发者平均年薪约 9.7 万美元，中国的开发者平均约 4.2 万美元，差两倍还多。这个差不是代码写得好两倍，是背后市场付费能力的差。想够到这个市场，前提是能用英语做异步协作——写得清楚的 PR 描述、在文档和 issue 里把事说明白，这些每天都在发生，绕不过去。

二是自己做产品面向全球收费。同样一个小工具，只面向国内中文用户，和能挂到面向全球的渠道上收美元订阅，用户盘子和付费习惯差一个数量级。但落地页、文档、客服邮件、社区回复，全是英文。

三是开源社区里的话语权和一手信息。技术圈真正的新东西基本是英文先出，中文转述慢半年、还常抄串（开头那件事就是）。想早点拿到、甚至下场参与讨论，得能读也能写。

这三样你要沾任何一样，英语就是必须过的那道闸。

但这道闸也有另一面。

把账算清楚：你的手艺，现在的买家、加上未来三年能看见的买家，如果全都在国内中文圈（公司在国内、同事说中文、接的私活甲方也是中文沟通、做的东西也没打算卖到国外），那么英语补到「能用」这个程度，边际收益接近零。

日常那点「读」的需求，现在的翻译工具基本能兜住。读文档、读 release notes，AI 翻一遍再对着原文扫一眼关键处，够用了。为这点需求专门花几百小时补到能开会、能吵架的水平，是把成本花在了用不上的地方。何况语言这东西不用就退，补上去半年不碰又掉回来，等于反复交学费。

判断到这一步其实很干脆：先确定你要不要海外那条线的钱，再决定要不要认真补英语。 顺序反过来，先补了再找用处，多半半途而废。

有人会说，AI 翻译都做到这样了，这道闸迟早会平。

我的看法是，「读」这一半确实在被抹平，「写」和「接话」这一半没有。

读是单向的，翻错了还能对着原文核一遍。但在开源 issue 里被人质疑你的方案、跟海外客户当场谈需求怎么改、异步协作里回一条别人能一次看懂的消息，这些要的是你自己能实时组织出分寸合适的英文。中间垫一个翻译器，你的话会被磨平语气，对方追问一句你就接不住，来回几轮，信任就没了。

读文档和参与讨论，是两种不同的能力。 翻译工具让第一种变得几乎免费，也正因为这样，第二种在海外那条线上反而更值钱了。能直接下场说话的人，一直是少数。

回到最初那个问题。我现在不纠结要不要补英语，先纠结另一件事：

我这门手艺的买家，现在有几个在中文圈以外？未来三年，我打算让这个数字变成多少？

这个数得自己诚实地报。报出来是「零，而且不打算变」，那就安心用翻译工具兜着，别为一道你不会走的闸交学费。报出来是「现在没有，但想有」，那这几百个小时就不是成本，是提前量。而且越往后，能直接下场的人越值钱，补的时机只会更贵。