最近看了不少关于 Meta 裁员的讨论，也拿到了一些当事人的分享。
裁员到底是怎么选人的
有一份 court filing 披露了 Meta 这轮裁员的一些 decision process。
实际操作比很多人想象中更像一条流水线：决策者面前会有一张表，列着员工的 job title、job level、tenure、performance rating、skills、training records 等信息，然后根据这些数据决定谁留下、谁进裁员名单。
表面看起来挺客观，毕竟都是数据。但问题也恰恰在这里：数据是一回事，最后怎么用这些数据，还是有很大的操作空间。
比如一个 mgr 本来就想淘汰某个人，但又不想走完整的 PIP 流程，那么裁员就是一个很方便的机会。直接把人放进名单，最后对外完全可以解释成：这是公司的裁员决定。
对被裁的人来说，这种情况其实很难申诉。因为你甚至不知道自己到底为什么被选中：是某几个指标真的把你筛出来了，还是有人主动把你放了进去。
真正已经明显不受待见的员工，很多早就被打了低分。裁员反而更适合处理另一批人——绩效有问题，但还没严重到公司愿意花时间走正式流程的人。残酷是残酷，但放到公司的实际操作里，好像也不难理解为什么会这么做。
休假期间被裁，问题出在什么时候通知
还有一个案例。有朋友的伴侣当时正在 maternity leave ，也受到了这轮 Meta 裁员的影响。
实际操作不是在休假期间直接通知她，而是公司先在内部把她标记成“受影响”，等她休假结束、正式返岗的那一天再通知。
这样一来，从时间点上看，公司并没有在 leave 期间正式解雇她。
更让人难受的是，她最后只拿到了 statutory leave ，公司额外提供的 company benefit 没有继续给，一天都没多。公司知道一个刚生完孩子的人，这时候通常没有多少精力和资源去跟公司打官司，所以只要程序上卡准时间点，就很难处理。
这个细节看完确实挺唏嘘的。很多事情最后争的可能已经不是能不能做，而是公司愿意把规则用到什么程度。
AI 到底有没有参与裁员
另一个大家比较在意的问题，是 Meta 内部一个叫 Checkpoint 的 AI 工具。这个工具会追踪员工对 AI 工具的 adoption 和 token usage，而且这些数据会成为裁员评估的重要指标之一。
目前已经有 20 多名前 Meta 员工因此提起 lawsuit，认为这套系统不成比例地影响了正处于 protected medical leave 的员工。
这件事已经有主流科技媒体跟进，法官也允许裁员继续推进，至少暂时没有支持“系统存在 bias”这个说法。但案子本身还没有结束，所以现在下结论也还太早。
相比 AI 有没有直接决定裁谁，大家反而更在意另一个问题：如果公司越来越多地把 AI 使用量、绩效评分之类的数据放进同一个评估体系里，那么最后即使是人做决定，员工也很难知道究竟是哪一个指标影响了自己。
还有一些讨论是关于 procurement team。他们以前负责跟 supplier 谈合同、处理 invoice、对接 ERP 系统。后来 AI agent 慢慢接手了其中大量工作，最后团队规模只剩原来的五分之一。
关键是，同一时期业务量并没有下降，反而每年还在增长 2—3 倍。如果这个描述属实，那就不是传统意义上的业务不行了，所以需要裁人，而是另一条路径：先让 AI agent 接手越来越多的工作，再缩减原来负责这些工作的人。
也就是先把活替掉，再把人裁掉。
如果这种两步走真的开始变成行业里常见的做法，那我觉得比单纯说 AI 会不会抢工作更值得关注。因为最后公司给出的理由可能依然只是很普通的业务需要或者 formal layoff，但前面其实已经发生了一轮工作内容的替代。
另外也有被裁的人说，自己属于 bottom 10% performance cut（也就是 stack ranking／forced ranking 里的末位）。
所以至少从这些分享来看，也不能简单理解成AI 指标决定谁被裁。AI 相关指标和传统的绩效考核，很可能是在一起起作用。
最后的一点感受
你越来越难知道自己为什么被裁。
绩效评分里有经理的判断，裁员名单里又可能有人为调整；休假员工可以通过通知时间来处理；再加上 AI adoption、token usage 之类以前根本不会出现在绩效体系里的指标，最后整个过程会变得越来越难还原。
公司当然可以说这是业务需要，每一个单独的步骤也可能都有自己的流程和理由。但站在员工这边，问题是：你很难验证，更难反驳。你不知道究竟是哪一步出了问题，也不知道应该证明什么。
所以如果真的担心自己可能受到裁员影响，至少 performance record、重要的邮件和书面沟通、leave 相关证明这些东西，还是尽量自己留好。