一天开13个会、一个Bug要修200天!前亚马逊L7爆料:这轮大裁员,AI只是“背锅侠”

一天开13个会、一个Bug要修200天!前亚马逊L7爆料:这轮大裁员,AI只是“背锅侠”

整理 | 郑丽媛

出品 | ZEEKLOG(ID:ZEEKLOGnews)

过去一年,大型科技公司的裁员消息几乎从未停过。但当公司对外给出的理由越来越统一,“AI 让组织更高效”,也有越来越多内部员工开始提出另一种质疑:事情或许没那么简单。

最近,一段来自前亚马逊员工 Becky 的 YouTube 视频在开发者社区流传开来。她曾在亚马逊工作 7 年,其中 5 年担任 L7 级别的技术管理者,负责过团队年度规划(OP1)等核心管理工作——可去年,她主动离开了亚马逊。

就在最近,她的三位前同事接连被裁,其中两人还是 H-1B 签证员工,都背着房贷压力。其中一位同事忍不住给 Becky 发消息:“你去年离开的时候,是不是已经预料到会发生这些?”

对此,Becky 的回答很坦诚:她不知道具体什么时候会裁员,但她早就感觉情况不对劲了。

在她看来,这轮裁员被归因为 AI,更多只是一个“方便解释的理由”——真正的问题,其实早在几年之前就已经埋下了。

疫情之后,亚马逊开始疯狂扩张

Becky 回忆说,如果要追溯问题的源头,大概要回到疫情那几年。

2019 年时,亚马逊员工总数大约 80 万人。但随着电商需求暴涨,公司在短短两年内疯狂扩张——到 2021 年员工规模直接翻倍,达到约 160 万人。

很多人以为扩张主要发生在仓储和物流中心,但 Becky 说,事实上几乎所有部门都在扩张。

那几年,她每年都会负责组织的 OP1(Operating Plan 1)年度规划。这是一项非常重要的内部流程,各个团队都会在这个阶段提交下一年的预算、项目计划以及人员编制申请(headcount)。

也正是在这些规划会议上,她逐渐意识到事情开始失控。“那时候,几乎每个团队都在申请更多人。” Becky 说,“而且很多申请理由,现在回头看简直匪夷所思。”

她举了一个典型例子:有团队申请 6 名产品经理,只是为了检查一个结账页面里的用户体验问题。按正常逻辑,这种需求在 VP 层应该会被直接否掉。但现实情况却是——几乎所有申请都被批准了。

在 Becky 看来,亚马逊在那个阶段逐渐发生了某种变化:公司似乎从一台“创新机器”,变成了一台“抢地盘机器”。更多员工意味着更大的组织规模,而更大的组织规模又意味着更高的话语权。因此在内部政治结构中,这几乎形成了一种激励机制:谁的人多,谁的权力就大。

但商业世界有一个残酷的事实——财务报表并不会因为组织结构而改变。

一个越来越明显的信号:人均产出下降

随着人员规模迅速膨胀,一些数据开始变得越来越刺眼。

公开财报显示,2020 年亚马逊的人均收入约为 48.4 万美元,到 2021 年,这个数字下降到 36.2 万美元,而在 2022 年则进一步降至约 32 万美元。

Becky 表示,这些数据其实已经算是“好看版本”了。在她当年接触到的内部数据里,某些业务部门的人均收入下降得更为明显。

而当公司高层意识到这个问题时,一系列变化开始悄然发生:

● 第一步:人员编制申请越来越难批。曾经几乎“随便批”的 headcount 申请,突然开始被严格审查。

● 第二步:招聘冻结。甚至已经批准的岗位,也被要求暂停招聘。

● 第三步:公司开始推出各种“返回办公室”政策。表面上是管理措施,但实际上很多人都知道,这是一种不支付裁员补偿、逼员工主动离开的方式。

“如果你当时足够留意,其实就能看出公司迟早会裁员。”Becky 说,“这件事早在 ChatGPT 出现之前,就已经摆在明面上了。”

AI 是原因吗?更像是一种“理由”

当然,Becky 并不否认 AI 对企业组织结构的影响。她认为 AI 确实可能加速了一些岗位的调整——但把整轮裁员都归因为 AI,在她看来显然过于片面。

“对董事会来说,说‘我们正在大规模投资 AI’听起来更好。”她解释说,“这比承认当年招人太多、内部政治让组织效率下降要体面得多。”

不过比起裁员,更让 Becky 困惑的是另一个问题:亚马逊一直以招聘高质量人才著称,她在公司期间也确实与很多非常优秀的工程师共事——但为什么,明明有这么多聪明人,却很难做出真正高效的成果?

“这个问题的答案,也是我最终决定离开的原因。”Becky 强调,她并不讨厌老板,工作也没有过劳,她选择离职只是因为:“我感觉自己在里面快‘死掉了’。”

一天 13 个会议,却什么都没完成

在离职前的一段时间里,Becky 曾经做过一件有点“实验性”的事情:她拍摄了一整天的工作 vlog,想看看自己到底把时间花在了哪里。

结果那一天,从早到晚,她一共参加了 13 个会议。而且那天还不算特别忙——毕竟她还有时间拍视频。回看那天的记录,她得出的结论是:自己几乎没有完成任何实际工作。

重要的是,这种情况并不只发生在她一个人身上。

如果是 L7 或 L8 级别的管理者,日历往往被各种会议塞满:团队对齐会议、项目文档评审、跨部门协调、战略讨论……以及各种“讲故事”、“互相甩锅”的汇报准备。

一个 Bug,可以拖上 200 天

说到这里,Becky 举了个真实案例,那是一次典型的系统事故。

某天,亚马逊的全球结账页面突然崩溃,大量用户无法下单。这本该是一场紧急修复行动,但事情的发展却完全不同。

接下来几个月,公司内部展开了漫长的讨论:23 个团队参与调查,6 位 VP 介入会议,无数份文档被写出来,各种责任归属争论不断……整个过程基本变成了一场“甩锅游戏”,而真正的系统长期修复,却迟迟没有推进。

原因很简单:长期解决方案往往需要时间,而短期内最容易获得“成绩”的方式,是快速打补丁。于是,每个团队都在争取通过临时修复来证明自己的价值,而不是解决根本问题。

类似这样的事件,一年可能要发生几十次。再加上组织重组、季度评审(QBR)、年度规划、路线图调整……工程师很快就会发现,大量时间都被消耗在组织流程而不是产品建设上。

例如,在 Becky 的团队里,工程师平均只有 1/3 时间在写代码,剩下 2/3 时间都在开会、写文档、给那些自称为 “GM(General Manager)”、完全不懂技术的领导解释。

结果就是,一个普通 Bug 的平均修复周期可能长达 200 天,还有很多 Bug 干脆永远都没人碰。

七年里,没有一个总部项目准时上线

Becky 说,在她七年的亚马逊职业生涯里,有一件事情始终让她印象深刻:总部的工程团队几乎没有一个项目是按时上线的,而唯一准时上线的项目,是由一个日本团队做的。

结果,你猜怎么着?据 Becky 透露,在最近的裁员中,这个团队是最先被裁掉的一批。

在这样的环境里,技术能力已不再是最重要的评价标准。正如 Becky 所说:“你会慢慢意识到,在公司内部,真正决定晋升和资源分配的,往往是政治能力。”

回想当初加入亚马逊时,Becky 十分认同公司的文化原则:Customer Obsession(客户至上)。但最近几年,她逐渐感觉到,这种文化正在悄悄发生变化:“本来的‘客户至上’,慢慢变成了‘政治至上’。”

这种变化并不是一夜之间发生的,而是在无数次会议、无数次组织调整中慢慢形成。而最终,Becky 意识到自己已经失去了继续留下来的动力:“这份消耗,一点点杀死了我心里的热情。”

“公司不值得我把人生交给它”

因此,当开头提到的那位前同事问起她裁员时,Becky 的回答非常简单:

“我其实不知道裁员什么时候会发生。毕竟当时我只是一个普通的 L7 经理。但说实话,我当时已经有一种感觉:公司给我的薪水,已经不值得我拿。同时,公司也不值得我继续把人生交给它。所以,我选择了离开。”

在视频最后 Becky 提到,裁员当然是一件痛苦的事情,她也非常同情那些突然失去收入来源的人。但在她看来,这或许也可能成为一种重新开始的契机。

“时代变化的时候,人通常有两种选择。”她说,一种是等变化发生,然后被迫应对;另一种,是提前跳出来,尝试抓住新的浪潮——而 Becky,显然选择了后者。

原视频链接:https://www.youtube.com/watch?v=uyCcgG4nm90

推荐阅读:

上门安装“龙虾”几天赚26万?工程师提出质疑;雷军:未来每天上班两小时就够了;大四学生AI开源项目获陈天桥3000万投资 | 极客头条

48小时“烧光”56万!三人创业团队濒临破产,仅因Gemini API密钥被盗:“AI账单远超我们的银行余额”

全球26w+用户在线「养虾」:OpenClaw这一波泼天流量,到底让谁接住了?

未来没有前后端,只有 AI Agent 工程师。

这场十倍速的变革已至,你的下一步在哪?

4 月 17-18 日,由 ZEEKLOG 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开,大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题,为你绘制通往未来的认知地图。

成为时代的见证者,更要成为时代的先行者。

奇点智能技术大会上海站,我们不见不散!

Read more

[开源] 纯前端实现楼盘采光模拟工具:从2D规划图到3D日照分析

[开源] 纯前端实现楼盘采光模拟工具:从2D规划图到3D日照分析

前言 买房是人生大事,不仅要看户型,更要看采光。尤其是现在高层住宅密集,低楼层的日照时长往往是购房者的心病。虽然市面上有专业的日照分析软件,但对于普通开发者或购房者来说门槛太高。 最近利用周末时间,我开发了一套纯前端、零依赖的楼盘规划与采光模拟工具。它包含两个部分: 1. 配置器 (Editor):基于 Canvas,在普通的楼盘规划图(JPG/PNG)上绘制楼栋轮廓、标定比例尺。 2. 可视化 (Viewer):基于 Three.js,将配置好的数据生成 3D 模型,模拟冬至/夏至不同时间段的日照阴影。 本文将分享这个项目的核心技术实现思路。 开源地址:[https://github.com/SeanWong17/building-sunlight-simulator] 欢迎 Star ⭐ 和 Fork! 🚀 功能演示 1. 2D 规划图配置器 这是数据生产的入口。用户上传一张总平图,

By Ne0inhk
从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南

从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南

🧑 博主简介:ZEEKLOG博客专家,历代文学网(PC端可以访问:https://literature.sinhy.com/#/?__c=1000,移动端可关注公众号 “ 心海云图 ” 微信小程序搜索“历代文学”)总架构师,16年工作经验,精通Java编程,高并发设计,分布式系统架构设计,Springboot和微服务,熟悉Linux,ESXI虚拟化以及云原生Docker和K8s,热衷于探索科技的边界,并将理论知识转化为实际应用。保持对新技术的好奇心,乐于分享所学,希望通过我的实践经历和见解,启发他人的创新思维。在这里,我希望能与志同道合的朋友交流探讨,共同进步,一起在技术的世界里不断学习成长。 🤝商务合作:请搜索或扫码关注微信公众号 “ 心海云图 ” 从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南 引言:为什么我们需要新的网络请求方案? 在前端开发领域,XMLHttpRequest (XHR) 长期统治着浏览器端的网络请求。然而,随着 Web

By Ne0inhk

移动前端开发与 Web 前端开发的区别

目录 一、平台与目标设备的区别 1. Web 前端开发 2. 移动前端开发 二、技术栈与开发框架的区别 1. Web 前端开发 2. 移动前端开发 三、用户体验与交互设计的区别 1. Web 前端开发 2. 移动前端开发 四、性能优化与资源管理的区别 1. Web 前端开发 2. 移动前端开发 五、开发工具与流程的区别 1. Web 前端开发 2. 移动前端开发 六、适配问题的核心差异 1. Web 前端开发 2. 移动前端开发 七、应用场景与选择建议 1. 选择 Web 前端开发的场景 2.

By Ne0inhk
35道常见的前端vue面试题,零基础入门到精通,收藏这篇就够了

35道常见的前端vue面试题,零基础入门到精通,收藏这篇就够了

来源 | https://segmentfault.com/a/1190000021936876 今天这篇文章给大家分享一些常见的前端vue面试题。有一定的参考价值,有需要的朋友可以参考一下,希望对大家有所帮助。 对于前端来说,尽管css、html、js是主要的基础知识,但是随着技术的不断发展,出现了很多优秀的mv*框架以及小程序框架。因此,对于前端开发者而言,需要对一些前端框架进行熟练掌握。这篇文章我们一起来聊一聊VUE及全家桶的常见面试问题。 1、请讲述下VUE的MVVM的理解? MVVM 是 Model-View-ViewModel的缩写,即将数据模型与数据表现层通过数据驱动进行分离,从而只需要关系数据模型的开发,而不需要考虑页面的表现,具体说来如下: Model代表数据模型:主要用于定义数据和操作的业务逻辑。 View代表页面展示组件(即dom展现形式):负责将数据模型转化成UI 展现出来。 ViewModel为model和view之间的桥梁:监听模型数据的改变和控制视图行为、处理用户交互。通过双向数据绑定把 View 层和 Model 层连接了起来,而View

By Ne0inhk