为啥美国互联网公司不需要 996,人均产出还更高?

很多人只是简单归结于社会文化 “内卷”、八小时工作制执行力度不足,但我觉得这些并不是主要原因。很多做出海业务的公司,海外团队不实施 996,甚至不用打卡,但国内团队仍然要 996。这是为什么呢?

作为一个对国内和美国公司都有一定了解的程序员,我认为主要是以下几个原因:

  1. 美国公司的客户单价较高
  2. 美国客户对人工服务时限要求较低
  3. 美国公司基层程序员的代码质量较高
  4. 美国公司的管理成本较低
  5. 美国公司更善于使用工具和 SaaS 服务
  6. 美国公司目标和边界更清晰
  7. 美国公司也有少数 007 大神在负重前行

美国公司的客户单价较高

一个各方面能力接近的人,投入相同的工作时间,在美国公司创造的收入和利润大概率是比中国公司高的。原因就在客户单价上。

例如在海外做一款 to C(面向普通用户)的 app,9.9 美元一个月的订阅费不算很贵,但在国内基本上就只能收 20 人民币。对传统互联网应用来说,服务器等运营成本不算贵,研发成本才是大头,此时国内的用户基数只要够大,还是可以平摊研发成本,获取利润的。但对 AI 大模型应用而言,大模型的推理成本就很高,大约是传统互联网应用服务器成本的 10 倍到 100 倍,此时如果订阅费太便宜,可能用的人越多亏得越多。

To B(面向企业的)业务也是类似的,例如批量文生图的业务,在海外可以卖到 1 美金一张图,但国内卷到只能卖 1 人民币。To B 业务比较难 scale,客户单价就决定了这个业务是盈利还是亏损。

美国公司客户单价高有两个原因,第一是地缘政治,美国公司掌握了全球高净值市场,中国公司并不容易进入。第二是技术驱动,美国公司利用更强的技术竞争力,可以占据一些早期市场或技术壁垒高的市场。

我认为,客户单价较高是大多数美国公司不需要 996 最重要的原因。客户单价高,就可以招更高薪酬的人,上述几个原因中的代码质量高、管理成本低、善于使用工具和 SaaS 服务,其实是员工平均能力强的推论。

美国客户对人工服务时限要求较低

我刚到美国访问的时候,就感觉美国整个社会的节奏明显比国内慢。作为乙方,可以摸鱼肯定是舒服的事情,但作为甲方,这就不是什么开心的体验了。

我们要把服务器部署到数据中心,在国内一周就能搞定的事情,在美国搞了两个月。数据中心的工作人员只有在工作日的工作时间才响应,如果非工作时间需要响应,就需要加收很高的费用。

在线服务也是如此。注册域名的网站经常停机维护,甚至 CloudFlare 这样的大型 SaaS 服务都有明显的 bug,国内的产品这样肯定是不行的。Google Cloud 控制台虚拟机开机关机、变更配置各种操作的延迟都比国内的云厂商高。我在给华为云干活的时候,降低这些操作的延迟都是团队的 KPI,没想到 Google Cloud 这么大的云厂商,竟然技术指标做得还没有华为云高。

海外更习惯用邮件沟通,国内更习惯用即时通信工具或电话沟通,这也体现了对人工服务时限要求的区别。国内一个微信或者电话过来,基本上就是要马上解决,不管是否在工作时间。而邮件沟通就允许更长的延迟,默认是到了工作时间再处理。

整个社会的节奏慢,客户就更容易容忍缓慢的人工服务,作为乙方,自然就不那么需要 996 了。

美国公司基层程序员的代码质量较高

很多人在计算人均产出、人均薪酬等指标的时候,忽略了人本身的水平。例如北京的基层程序员年薪只要 20 万人民币,而在湾区,程序员年薪基本上是 15 万美金起步。因此他们得到结论,国内的程序员润到美国一定生活水平提高很多。

但他们忽略了一点,20 万人民币的国内大厂程序员到了湾区很可能根本找不到大厂工作。这不只是语言的问题,更重要的是能力问题。

根据我的感觉,湾区几家知名大厂初级程序员的入职门槛,综合水平基本上相当于北京年薪 50 万人民币的程序员。而国内大厂一半以上的程序员可能都达不到这个薪酬水平。

有个说法,从海外大厂跳槽到国内大厂,大概可以升 3 级。其实就是因为初级程序员的入职门槛不同,从 20 万到 50 万,大概就是 3 级。因此,在海外大厂做基础开发工作的,到了国内大厂,就必须做一些管理工作了。

初级程序员水平低的直接后果就是项目的代码质量较差,很多国内公司也是近年来才开始重视代码质量。例如,华为从 2019 年开始推行软件可信,要求研发人员必须通过类似 LeetCode 的编码能力考试和软件工程基础知识考试,代码仓库必须使用 Pull Request、Peer Review、Committer 负责制、代码风格检查、CI/CD 等现在行业通行的最佳实践;所有研发人员,不论领导还是小兵,每年必须提交一定量的代码;员工晋升、绩效评定时需要 committer 的代码质量意见作为重要参考。

很多国内公司的项目经理和领导往往不懂技术,基层程序员只要把功能尽快实现出来就行了,至于代码是不是堆成了屎山无所谓。以至于很多公司推行代码质量提升计划的时候遇到很大阻力。例如华为内部经常有些员工抱怨,写出的代码经常不能通过代码风格检查和单元测试门禁,好不容易改好代码通过这些门禁,Reviewer 又给提了几个意见给打回来,结果提交代码上库的时间比开发还长。但随着员工自己的代码风格提升,以及本地部署代码风格检查工具,提交代码上库所需的时间是逐渐降低的。

代码质量差的后果就是 bug 多,需要加班修 bug,把写代码这样一个脑力劳动变成了体力劳动。例如有些团队在下班前需要验收开发成果,测试一验收,发现 bug 太多,开发和测试就要一起加班修 bug,搞到很晚。因为只要能通过测试这一关就能尽早下班,加班过程中写出的代码自然也是补丁摞补丁,代码质量进一步恶化。这也是国内公司经常 996 的一个原因。

产品质量有产品经理和测试看护,就算代码质量差,靠堆时间 996 的方法总能修得让用户看不出来。但开发者生态就会受到代码质量的直接影响。例如国内的大模型 API 文档很多不够完善,有的样例代码甚至没有语法高亮,有的样例代码根本不能用(因为 API 更新了样例代码没有更新),有的 Python 库不支持异步,有的表面上支持异步但内部实现竟然是同步的。有的 AI 服务 SDK 有开源代码,打开一看,连缩进都没有统一,代码中充斥着各种不明所以的变量名和注释,一个函数几百行五层缩进。国内很多产品的开发者生态不好,很重要的一个原因就是代码质量差。

美国公司的管理成本较低

国内公司的管理成本较高,主要体现在会议效率低下,占用大量开发时间,有些团队甚至出现了白天基本上都在开会,晚上加班才有时间写代码的情况。

我认为主要有三个原因:

第一,沟通效率低,扯皮多。有的讲话长篇大论,有的讨论过程反复绕圈子,前面讨论过的问题没有得出结论,过一会儿又拿出来讨论。由于讨论动辄超过两个小时,与会人员的精力很难集中,很多人学会了一边开会一边摸鱼,结果讨论结论总有人没听到,又增加了沟通成本。

我在华为的一个领导是从外企过来的,讲话很简洁,一个事情只讲一遍,而且讲的过程中经常夹杂一些英文专业名词。一些华为同事会后还要来找我问领导讲的是什么意思。久而久之,大家在会上都聚精会神,会议效率都提高了。

第二,基础较差的程序员需要手把手带,这就是所谓的 “保姆式开发” 或 “保安式开发”。开会的时候,讲的技术方案不合理,资深程序员自然要纠正他的问题,但基础不好的程序员一次又听不明白,需要反反复复掰开了揉碎了才能讲懂,这样会议效率自然不可能高。

第三,国内的管理层级较多,这不是因为所谓 “扁平化管理” 和 “金字塔式管理” 的差别,而是因为前面提到的基层程序员较多,同等水平的程序员在国内公司的级别可能比美国公司高 3 级。管理级别越高,在管理上要花的时间就越多。

相对来说,大多数美国公司开会较少,管理成本较低,程序员的有效工作时间也就较长。

管理成本低也是员工平均素质较高的一个推论。水平较高的员工一般有较强的自我驱动力,时间管理能力一般也较强,而且技术方案设计较为合理,技术沟通效率较高,这样管理成本就能大大降低。

美国公司更善于使用工具和 SaaS 服务

工具与 SaaS 的充分使用是美国公司保持高效的重要原因之一。

美国公司擅长利用现有的成熟工具和 SaaS(软件即服务)平台来提升工作效率,减少重复性劳动。比如,工程团队广泛使用 GitHub、Jira、Slack、Notion 等工具进行项目管理和团队协作,极大减少了内部沟通和任务追踪的成本。而国内公司往往倾向于自主开发或者本地部署方案,因为自主研发能 “提升 KPI”,显得创新,但事实上效率低下,重复造轮子。

很多能提升程序员开发效率的工具是付费的,一些国内公司宁可多雇一个每月薪酬几万的程序员,也不愿意每个月花几百块钱购置开发工具。例如 Cursor 这样的编辑器一个月 20 美元,很多国内公司就觉得太贵了,其实一个程序员一个小时的工资就不止 20 美元。

SaaS 服务更是一个关键的分水岭。我用国内一家大模型厂商的 API,一个月用了 5000 人民币,他们还把我当成大客户了,我很吃惊为什么才花了 5000 块钱就成了大客户,他们说大多数国内厂商都是自己买 GPU 部署开源模型,不喜欢用 API。

美国公司喜欢使用第三方付费服务,如向量数据库、大模型 API 等,愿意为更好的工具和服务付费,以换取更高的生产力。而国内公司,特别是规模较小的公司,为了节省成本,往往选择本地部署或开源项目,这虽然看似便宜,实际上长期成本高昂,因为维护成本、时间成本都被忽视了。

美国公司目标和边界更清晰

清晰的目标与边界是避免内耗的关键。

国内公司频繁调整方向、盲目跟风的现象屡见不鲜。新产品上马很快,但很大一部分项目没上线就被搁置,导致大量的资源和时间被浪费。这种项目管理的混乱源自于公司战略定位不清,什么热门做什么,短期目标频繁改变,员工也无所适从。

美国公司则大多制定了长期明确的战略目标,并清晰划定了业务边界。成熟的公司知道自己的核心竞争力是什么,专注于相关领域的深耕,不会轻易涉足不擅长的领域。明确的边界不仅帮助公司集中资源,还能减少内部的纷争与内耗,提升整体运转效率。

清晰的目标与稳定的业务方向让美国公司得以有效利用员工的时间和精力,不必通过 996 弥补战略失误带来的资源浪费。

少数 007 大神在负重前行

其实美国公司也不是每个人都在摸鱼。虽然大多数美国公司的生活和工作较为平衡,很多创业公司和独角兽(例如 OpenAI)的员工,甚至都不是 996,而是 007 了(一周 7 天,每天 24 小时)。

很多湾区创业公司的创始团队一起生活在一座房子里,白天一起在客厅办公,晚上就回各自房间睡觉,吃住都在一起,几乎没有个人生活,所有时间都投入到公司里了。我遇到几个在洛杉矶创业的朋友,一年甚至都没有去过海边玩。他们并不认为这种生活很苦,相反,他们认为创造用户喜欢的产品是在实现自己的梦想。

美国创业公司有较好的退出机制,大多数创业者不会因为创业背上债务,也使得很多优秀人才创业时可以没有太多后顾之忧。公司只要做得较为成功,创业者在财务上的回报也高于大多数大厂。

之所以美国公司的大多数员工能够享受生活工作平衡(Work-Life Balance),是因为有一群 007 大神推动着技术突破和商业创新,打造了公司的核心竞争力,他们真的是站在浪潮之巅,是人类文明之光。

哪有什么岁月静好,不过是有一批 007 大神在负重前行。

总结

美国公司不需要 996,背后有一套清晰的逻辑链条。

首先,美国公司的客户单价普遍较高。无论是 to B 还是 to C 业务,美国公司通常能够从每个客户身上赚取更高的收入。这一点至关重要,因为它直接影响公司能为员工提供更高的薪酬。薪酬更高,自然就能吸引到更优秀的员工。而优秀员工带来的直接效应,就是基层程序员的能力远高于一般水平。

基层员工能力强,意味着代码质量好,项目开发的技术基础稳固。高水平的程序员在编写代码时,通常遵循严格的代码规范,采用行业最佳实践。这种代码质量的提升不仅减少了项目中出现的 bug,也减少了后期维护和修复的工作量,从根本上降低了对加班的依赖。程序员不需要通过 996 来修复问题,因为问题从一开始就少得多。

高水平员工还带来了更低的管理成本。优秀的程序员自我驱动力强,工作自主性高,减少了过度依赖上级管理的情况。美国公司的会议少、沟通效率高,员工大多能在工作时间内完成任务,管理成本自然也就大幅下降。

再者,高水平的员工善于利用现有的技术工具和外部 SaaS 服务,减少了重复造轮子的成本和运维成本,让员工能专注于核心任务。

此外,美国客户对人工服务时限的要求较低。客户服务的宽松节奏,使得公司不必强行压榨员工的时间来满足马上就要的即时需求。美国公司的目标和边界更清晰,相比于国内公司频繁调整方向、盲目跟风的现象,美国公司相对明确的目标和稳定的业务方向避免了员工陷入反复修改需求的内耗中。

然而,美国公司中并非每个人都享受着这样的工作节奏。有一群 007 大神在背后负重前行,尤其是在初创公司中,这些人几乎全年无休,将全部精力投入到技术突破和商业创新中。他们站在浪潮之巅,是公司的核心竞争力。

总的来说,客户单价高带来高薪酬,吸引优秀员工,优秀员工带来高代码质量和低管理成本,工具和 SaaS 服务的充分利用,再加上客户宽松的服务时限要求以及公司清晰的目标边界,使得美国公司只需要少数 007 大神创造核心竞争力,大多数员工不需要 996 依然能够高效运转。

AI 辅助创作说明

这篇 5000 多字的文章是我在 2.5 小时内用 AI 辅助创作写完的,如果一个字一个字敲,这样一篇文章至少要花我 6 个小时时间。前两天有编辑跟我说 OpenAI o1 发布当天我就写出了 6000 多字的点评,比他专业做自媒体的写得都快,问我怎么做到的。其实从我看到 o1 的新闻到写出那篇文章只用了 3 个小时,没有 AI 辅助我也是不可能做到的。

有人说,AI 生成的文字内容比较四平八稳,缺少犀利的观点,语言也缺少张力,更不用说缺少个人经历这种独特的东西了。我也不相信现在的 AI 模型能够根据一个简单的提纲直接生成这篇文章。但就像 AI 可以在编程过程中帮人写胶水代码,AI 也可以在写作过程中帮人展开解释和润色语言。我们应该把 AI 想象成一个干活很快但不太靠谱的初级员工,应该当作一个助手,不能指望有了 AI 就可以做甩手掌柜了。

前些天 用 Cursor 2 小时写 800 行代码的 RAG 应用 demo 引起了不少反响,如果不借助 AI,我也需要至少 10 个小时。这里面的关键就是 AI 辅助写作、AI 辅助编程,人和 AI 是需要不断交互的,不是给一个初始 prompt 之后就全交给 AI 了。

希望每位程序员和文字工作者都能学会使用 AI 辅助编程和写作,这样工作效率提高了,本文所讲的 996 问题也许可以大大缓解。

Comments