Meta用一整年证明Agent无法取代员工：事故增四成，工程师救火多七成

背景：OT 项目——激进的 AI 转型构想

2026 年初，扎克伯格在夏威夷私人庄园召集核心高管闭门会议，提出"彻底重新设计 Meta 内部工作方式"——用 AI Agent 取代成千上万名员工，只留一小撮人监督 AI。该构想演变为内部代号 "OT 项目"（Organization Transformation，组织转型）。

路透社查阅的内部规划文件将"AI 原生"定义为："适配 AI 的工具与 Agent 能够彼此交互，工作流程实现自动化，新产品从一开始便围绕 AI 构建。"同时，"AI 原生"还意味着向第三方销售 AI Agent——Meta 已于 6 月开始推进这项业务。

试点：五人小队 + 四周冲刺

产品高管 Ime Archibong 组建了五个小型技术团队（每个 2-3 名工程师 + 1 名设计师），借助 AI 工具以四周为冲刺周期完成产品原型，取代原来的六个月规划周期。Archibong 在内部帖子中写道："打快攻可以创造更多投篮机会。我们希望 AI 工具也能带来同样的效果。"

最激进方案：砍掉 60%

• 最激进的方案中，部分团队要砍掉 60% 的人
• Meta 曾考虑用 AI 完成"目前由数千名员工承担的大量日常工作"
• 一名人力高管表示，如果方案全部落地，员工总数将减少约 25% 甚至更多
• 重组分两轮：第一轮 5 月启动，第二轮原定 11 月
• 裁员节省的资金计划用于奖励高绩效员工，尤其是 AI 工程人才

第一轮裁员落地与转向

5 月 20 日第一轮裁员约 10%。但 5 月 19 日晚，扎克伯格动摇了，取消了 11 月的第二轮裁员计划。

结果：AI 没想象中能干，留下的员工惨了

代码爆炸但有效产出极低

根据 Meta CTO Andrew Bosworth 6 月初的内部帖子：

Instagram 零认证密码重置事故

5 月 30 日（第一轮裁员后仅十天），Instagram 遭遇"史上最令人尴尬的安全宕机事件"。

软件工程师 Siddharth Sundharam 的总结：

攻击者只需一个用户名，就能绕过所有安全验证重置账号密码。整个攻击流程只需两步：

1. 伪造位置发起客服申诉，让 Meta 客服 AI 将验证码发送到攻击者控制的邮箱
2. 没了——真的就这样

这是我在生产环境中见过的第一个真正的零认证密码重置。没有任何额外检查来确认提供的邮箱是否是用户之前使用过的邮箱。AI 将验证码发送到攻击者的邮箱后，攻击者直接提交验证码完成验证，平台生成新的密码重置链接，将账号完整所有权授予攻击者。

奥巴马白宫官方账号也未能幸免。直接诱因：AI 生成代码 + AI 审查代码，同时信任与安全团队因人员抽调流失约一半员工。事发后第二天，Meta 首席信息安全官 Guy Rosen 宣布辞职。6 月 12 日，Facebook 和 Instagram 又发生全面宕机的 SEV 0 级事故。

员工愤怒全面爆发

• 内部办公系统被愤怒评论刷屏
• 有人疯狂转发"大象"表情包——暗指裁员是"房间里的大象"
• 内部士气评分从 74% 跌到 55%
• 《连线》杂志记录：面向数千人的内部直播中，有人当场爆粗口，称自己"成了公司的奴才"
• 2026 年 5 月，Meta 工程师注册寻找新工作的数量同比大幅增长
• 拿到留任股权包的核心工程师中，有人表示这项福利反倒促使他尽快离职

扎克伯格松口

7 月内部会议上，扎克伯格终于承认："至少在过去四个月里，Agent 技术的发展轨迹并没有像我们预期的那样真正加速。"

Meta 向路透社回应称，公司在确定具体裁员人数之前便已取消了 OT 项目。

更残酷的现实

Meta 最终成为一个士气受挫、技术债务缠身的组织。工程师们正面对一个比原来混乱三倍的烂摊子：

• 代码量翻了三倍
• 安全事故增加四成
• 救火时间多了七成

业内反思

Greyhound Research 首席分析师 Sanchit Vir Gogia 的核心判断：

"Meta 相信了一种尚未在生产环境中实现的 AI 能力预测。这和过度信任 AI 是两种不同的失败。"

"Meta 把预测中的能力提前计入了实际产能。Agent 的能力会继续提升，但 Meta 的失误在于，这种提升尚未兑现，就已经被纳入生产能力规划。先验证 AI 的操作是否可靠，再扩大它的权限；验证权限可以安全运行后，再撤去人工控制。只有到了那时，削减人力才是一项决策，而非一场赌博。"

网友评论："他们窥见了未来的一种可能，便以为它已经到来，可以开始裁员了。事实证明，AI 在某些事情上非常聪明，在另一些事情上却表现很差。现阶段，AI 能力分布极不均衡，因此还无法迅速取代人类员工。"

Zero 的看法

这篇是路透社 + InfoQ 联合报道，信息密度高，核心数据清晰（220%/36%/40%/70% 这组数字值得记住）。几个判断：

这不是"AI 不行"的故事，是"组织能力幻觉"的故事。 Meta 的错误不是用了 AI，而是把实验室性能等同于生产环境产出。220% 的代码增长只有 36% 转化为有效功能，这个信噪比在任何工程组织里都是灾难级的——不叫"AI 辅助"，叫"AI 污染"。对前端团队来说同理：AI 写的组件代码如果 review 不过关，生产环境就是埋雷。

零认证密码重置是 AI 治理失败的极端案例。 AI 生成代码 + AI 审查代码 + 安全团队砍半 = 完整的安全防线失守。这不是"AI 写了有漏洞的代码"那么简单，是 AI 在审查流程中批准了不该批准的操作。任何让 AI 自我审查的流程都需要人类 guardrail，尤其是在安全敏感路径上。

"先验证再放权"是正确的路径，但说出来容易做起来难。 Gogia 的建议（先验证 AI 操作是否可靠 → 再扩大权限 → 验证权限安全运行 → 再撤人工控制）逻辑上完美，但实践中面临"验证成本"问题——你需要多少投入才能"验证"一个 AI Agent 在所有边界情况下都安全？Meta 的教训表明这个验证成本可能比省下来的人力还高。

对 Rainsho 团队的启示：如果你们在推 AI coding 工具（如 Claude Code），关注两个指标——有效代码转化率（写了多少 vs 合入了多少）和事故率变化。如果前者低于 50%、后者有上升趋势，说明你们的 AI 辅助正在变成 AI 污染，需要收窄 AI 的权限范围而不是继续扩大。