Project OT：Meta 秘密規劃用 AI 砍掉六成團隊——最後被內部數據親手埋葬的計畫

本週最重要的 AI 新聞不是模型發布，而是一份驗屍報告。

8 月 26 日，路透根據 Meta 內部文件與訪談公布特別報導，完整重建了 Mark Zuckerberg 最大一場人力豪賭——代號 Project OT（Organization Transformation，組織轉型）——如何被規劃、被辯護，最終又被放棄。這個計畫的野心簡單而駭人：讓 Meta 成為「AI native」公司，手段是將全公司許多團隊的規模縮減至多 60%、分兩波執行，由 AI agent 吸收離職人員的日常業務。

它沒能撐過與現實的碰撞。而解釋失敗原因的內部數據，是目前為止最清晰的一組量化證據，說明當一家大型科技公司試圖把 AI 編程熱潮直接換算成裁員人數時，會發生什麼事。

計畫內容：刪掉組織圖，而不只是修剪

根據路透，Project OT 於 2026 年 1 月在 Zuckerberg 的夏威夷莊園成形。這個構想遠不止「給每位員工一個 AI 助手」。內部文件設想的是更小的「AI 輔助小組（pods）」、刪除層層中階管理、產品開發逐步改由 agent 勞動力驅動。2 月時，Zuckerberg 為部分部門初始 40% 的裁員辯護，說 AI「從根本上改變了建立與經營一家公司的意義」。

計畫中結構性的那一半才是最激進的部分。正如 Times of India 的摘要所言，Project OT「是設計來刪除 Meta 的組織圖，而不只是修剪人力」。多種情境模擬了部分團隊在兩波之後縮編至多 60%，剩餘工作則分配給 AI agent 與更精簡的人類核心。

實際發生的事如今已有詳細記錄。2026 年 5 月，Meta 裁撤 8,000 名員工（約 10% 人力），另外將 7,000 人轉調至 AI 相關職位，合計影響約 20% 員工。Zuckerberg 起初將裁員歸因於沉重的資本支出——Meta 的 AI 支出正衝向據報 1,450 億美元。但那波更深入的第二波裁員、真正會把許多團隊推向 60% 目標的裁員，從未到來。

數據：程式碼更多、功能更少、火災更頻繁

路透報導的核心，是 Meta 在 AI 轉型啟動後收集的一組內部指標。這些數字值得精確引用：

• 內部平台與基礎設施的程式碼變更同比增加 220%。 AI 工具正在產生遠超以往的程式碼流動量。
• 但實際觸及使用者的新功能或功能改善只增加 36%。 產出數量與使用者價值嚴重背離。
• 重大事故暴增 40%。 更多的變更代表更多的東西壞掉。
• 工程師花在救火上的時間大幅膨脹。 工程師越來越被清理工作吞噬，而非創造。

Ars Technica 引述報導時還點出另一個細節：內部貼文據報指出 AI agent 做出了「大規模破壞性行動（large-scale disruptive actions）」——這些自主變更的影響之大，員工在內部將其標記為動搖系統的行為。

這就是 AI 編程 agent 的生產力悖論，直接以正式環境遙測數據呈現。220% 的程式碼變更暴增，正是積極部署 agent 從內部看起來的樣子：agent 迭代飛快、持續產生 diff、無情地觸碰各個系統。但 diff 不等於功能。當功能交付成長 36%、而變更量成長 220%，代表新增流量中約有六分之五從未以價值的形式觸及使用者。而當同一時間窗口內重大事故上升 40%，剩餘人力中有一大塊就從建設被轉移到修復。

反叛：工程師不是被動的基礎設施

數據不是扼殺第二波的唯一力量。路透描述了一個公開反抗中的員工群體。員工們確信這些 AI 轉型倡議部分就是為了取代他們，於是強力反彈——The Pragmatic Engineer 電子報形容員工處於「公開反抗」轉型任務的狀態。士氣在春季就已崩塌：4 月的 Reddit 討論串記錄了裁員公告與執行之間「4 到 6 週的零士氣」，員工形容那段時間是「28 天的地獄」。

Zuckerberg 自己的姿態也轉變了。根據路透另一篇報導，6 月他在內部備忘錄告訴員工，公司在 AI 人力轉型中犯了「錯誤」。到了 8 月，第二波裁員已被取消——報導指出，在員工反抗與 AI agent 未能交付預期生產力提升的雙重打擊下，Zuckerberg 叫停了原定 11 月的裁員。

時間順序上有個殘酷的諷刺：agent 在生產力測試中失敗的那一刻，正是它們產出最漂亮原始統計數字的時候。如果 Meta 用變更行數衡量成功，Project OT 看起來會是一場大勝。它選擇衡量真正重要的東西——交付的功能、事故、工程師時間——計畫就在證據之下崩塌。

為什麼這件事超越 Meta

三個可以推廣的教訓。

第一，「AI native」是組織層面的主張，不是工具層面的主張。 Meta 不只是給大家裝個 Copilot。它嘗試圍繞「agent 產出能以 60% 的比率替代人力」這個假設重新架構整家公司。這個假設跑在 agent 實際能力前面——而落差出現在事故儀表板上，不是在 demo 裡。

第二，程式碼生成指標是錯誤的 KPI。 220% 對 36% 的背離，是對所有圍繞「開發者速度」儀表板建立 AI 策略的公司的警告。數量指標美化 agent；結果指標揭露 agent。任何企業級 AI 導入都應以觸及使用者的功能、事故率與維運負擔來評估——正是那組淹沒 Project OT 第二波的遙測數據。

第三，員工的同意是真實的約束。 一個被員工理解為「取代方案」的計畫，會遭遇削弱其自身可行性的抵抗——被期待去訓練並監督取代自己的 agent 的人，正是被取代的人。Meta 的工程師同時被要求讓 agent 成功運作，又被要求接受 agent 的成功意味著自己的離開。這種結構不穩定，而且它斷裂了。

接下來呢

第二波裁員的取消是暫停，不是終章。Meta 確認 Project OT 是為期一年的計畫，聚焦成本、團隊結構、將員工移入優先 AI 業務與訓練。1,450 億美元的 AI 資本支出軌跡沒有改變，公司也依然保有隨模型進步重啟裁員的結構性選項。

但舉證責任已經轉移。一年來，整個產業的預設假設是：AI 能力曲線可以或多或少直接換算成人力配置曲線——在 benchmark 上有效的東西，可以放大到組織圖上。Project OT 是迄今為止最大、文件最完整的反例：一家擁有頂尖工程人才、近乎無限算力與最高層全力支持的公司，大規模跑了這場實驗，收集了內部數據，然後退縮了。

當企業 AI 導入的歷史被書寫時，「220% 程式碼變更對 36% 功能交付」這個數字，值得與定義過往科技浪潮的生產力統計並列。這是取代假說撞上遙測數據的時刻——而遙測數據贏了。

在下一個模型世代到來之前，每個正在規劃「AI native」組織重整的董事會，手上都多了一個附有數字的案例研究。Meta 試圖刪掉自己的組織圖；結果組織圖在增加 40% 重大事故的幫助下，先刪掉了那個計畫。