Meta Project OT 是什麼？AI Agent 取代員工為何受挫，企業導入 AI 的 5 個警訊

2026 年，Meta 曾試圖用一個代號 Project OT（Organization Transformation） 的內部計畫，把公司重組成更接近「AI-native」的工作模式：團隊變小、管理層減少，更多工作交給 AI 工具與 Agent 完成，部分團隊甚至評估縮減最多 60%。

幾個月後，Meta 收縮了這項計畫。

問題並不是 AI 完全沒有效果。Reuters 取得的 Meta 內部資料顯示，AI 導入後部分程式碼活動大幅增加；真正暴露的問題是，產出量、生產力、產品價值與可靠性其實是四件不同的事。

Project OT 因此成為目前企業導入 AI Agent 最值得研究的案例之一。

Project OT 是什麼？

Project OT 是 Meta 在 2026 年推動的內部組織轉型計畫，OT 代表 Organization Transformation。

Reuters 根據內部文件及超過 20 名知情人士的訪談報導，Meta 當時希望建立更「AI-native」的組織：讓 AI-ready 工具、Agent 與自動化流程進入日常工作，再重新思考一個團隊究竟需要多少人。

其中一項構想是把傳統大型團隊改成更小的工作單位，讓少數員工搭配 AI 完成原本需要更多人的工作。

Meta 向 Reuters 確認，規劃中確實曾評估部分團隊最多縮減約 60%的情境。

但這個數字不能理解成 Meta 原本準備裁掉全公司 60% 員工。

縮減方式包含裁員、人員重新配置及不再填補空缺，而且只適用於部分被重新設計的團隊。

這個差異很重要。

Project OT 真正想測試的不是單純裁員，而是一個更激進的假設：

一家公司如果讓 AI Agent 承擔大量工作，是否可以重新設計整個組織結構？

Meta 真的因此裁員了嗎？

有。

Meta 官方 2026 年第二季財報顯示，5 月的人力縮減影響約 8,000 名員工，公司並因此認列約 11.8 億美元遣散相關費用。

截至 2026 年 6 月 30 日，Meta 公布員工數為 75,472 人。這個數字當時仍包含約 8,000 名受到 5 月裁員影響、但尚未全部離開公司帳面的員工。

不過 Reuters 報導顯示，原本 Project OT 還曾規劃第二輪更廣泛的人員調整。

這一輪最後沒有按照原計畫執行。

Meta 之後向員工表示，2026 年不再進行公司層級的大規模裁員。

因此 Project OT 最有意思的地方不是「Meta 有沒有裁員」。

Meta 確實裁了。

真正值得研究的是：公司原本以為 AI 能支撐更激進的人力與組織重構，後來為什麼改變判斷。

AI 真的讓 Meta 工程師生產力提高 220% 嗎？

這是 Project OT 最容易被誤讀的數字。

Reuters 引述 Meta CTO Andrew Bosworth 6 月的內部文章指出，Meta 員工使用的內部軟體平台與基礎設施，其 code changes 年增約 220%。

如果只看到這個數字，很容易得到一個結論：

AI Coding 成功了。

但同一組內部資料還有另一個數字。

真正造成 Meta 使用者看到新功能或功能升級的變更，只增加約 36%。

兩個指標不能直接相除，也不能因此計算一個精確的「AI 有效率」。

但它揭露了一個企業非常容易犯的錯：

Activity 不等於 Outcome。

AI 可以讓工程師：

• 寫更多程式碼；
• 建立更多 Pull Request；
• 修改更多檔案；
• 產生更多測試；
• 更快完成初稿。

這些都屬於活動量。

公司的最終產出則是：

• 使用者真正得到多少改善；
• 新功能是否成功上線；
• 系統是否更穩定；
• 客戶是否增加；
• 成本是否下降；
• 人工覆核是否減少。

這才是 Outcome。

Meta 的案例提醒企業，AI dashboard 如果只量「生成多少東西」，很可能會得到過度樂觀的結論。

更多 AI 程式碼也帶來更多可靠性與資安問題

Project OT 更值得注意的數據出現在可靠性。

Reuters 取得的 Meta 內部資料顯示，隨著 AI Coding 使用量增加，公司內部曾出現 AI Agent 執行大規模、破壞性操作的問題。

相關內部資料指出，重大技術與安全事件較前一年增加約 40%，員工處理這些問題所花的時間最多增加約 70%。

這些數字來自 Reuters 報導取得的 Meta 內部資料，並不是 Meta 財報公開 KPI；Meta 對部分內部紀錄沒有公開評論。

但它呈現的工程問題非常典型。

AI Agent 最危險的失敗不一定是「回答錯」。

如果 Agent 擁有 Repository Write、Database Write、Deploy、Infrastructure、Cloud、Identity、Internal Admin 等權限，錯誤就可能從文字錯誤變成系統狀態變更。

一個工程師手動犯錯，通常只會執行自己想到的那幾個步驟。

Agent 可以在短時間內重複操作、跨系統執行，錯誤半徑可能反而更大。

這也是企業 AI Agent 和普通 Chatbot 最大的治理差異。

第一個警訊：不要先裁員，再驗證 AI 能不能接手

Project OT 最值得其他企業避免的地方，是組織變更與技術驗證的順序。

安全的導入順序應該是：現有人工作業 → 建立 Baseline → AI Shadow Mode → Agent 執行但不寫入 → 人工比較結果 → 受限工具權限 → 真實工作 PoC → 驗證穩定性 → 才重新設計人力。

如果順序變成：預期 AI 很快會變強 → 先計算可以少多少人 → 縮小團隊 → 要求 Agent 補回產能，企業其實是在拿未來模型能力當目前的人力配置依據。

這兩種方式風險完全不同。

YOLO LAB 在〈AI Agent 導入流程怎麼開始？7 步驟與 30 天試點〉中使用的 Shadow Mode，目的就是避免這種問題：先讓 AI 在真實流程旁邊跑，再決定它到底能承擔多少工作。

第二個警訊：AI 生產力不能用 Token、Code 或 Task 數量衡量

Agent 系統最容易製造的東西就是「看起來很忙」。

Coding Agent 可以大量產生 code、tests、comments、PR、documentation、tickets。

Marketing Agent 可以大量產生文案、Email、廣告版本、Landing Page、社群貼文。

Sales Agent 可以產生 Leads、Outreach、Follow-up、CRM updates。

如果 KPI 設成這些活動數，AI 幾乎一定會讓數字暴增。

問題是，公司並不是為了製造更多文件或更多程式碼存在。

企業真正需要驗收的是：任務完成率、錯誤率、人工覆核時間、Critical Error、返工率、最終交付時間、客戶結果與實際成本。

這也是為什麼 AI Agent PoC 不能只看 Demo 成功率。

第三個警訊：Human Review 可能變成新的瓶頸

AI Coding 很容易形成一個新的生產力悖論。

模型生成速度增加之後：Agent → 更多 Code → 更多 Pull Request → 更多 Diff → 更多人工 Review。

如果 Review 能力沒有同步提升，整個系統只是在把瓶頸往後移。

過去工程瓶頸可能是 Writing Code，AI 之後則可能變成 Understanding、Review、Testing、Integration、Security、Decision。

這對所有企業 Agent 都成立。

例如客服 Agent 可以瞬間寫出 10,000 封回覆，但如果其中高風險案例仍需要人類逐一檢查，企業並沒有獲得 10,000 倍效率。

因此導入 Agent 時，除了問「Agent 可以做多少」，還要問：

Agent 增加的輸出，需要多少新的人類驗證工作？

第四個警訊：Agent 權限必須跟能力分開

模型變強並不代表應該自動得到更大的系統權限。

一個 Agent 可以完成部署，不代表它應該擁有 production deploy 權限。

一個 Agent 可以修改 CRM，不代表它應該可以修改所有客戶。

一個 Agent 可以發 Email，不代表它可以直接向全部客戶寄信。

因此企業 Agent 的成熟方式應是：Read → Draft → Approval → Limited Write → Scoped Autonomy，而不是模型看起來很強就開全部工具。

Meta 報導中出現的 disruptive actions，正好說明「Agent 能做什麼」與「Agent 被允許做什麼」必須分開設計。

第五個警訊：企業需要衡量「修復成本」

AI Agent 最常被忽略的成本不是 API Token。

是錯誤之後的人力。

例如一次 Agent 錯誤可能造成：錯誤部署 → Incident → Rollback → Debug → Security Review → 資料修復 → 客戶處理 → Postmortem。

如果公司只計算「Agent 幫工程師省了 20 分鐘」，卻沒有計算「Incident 花掉 15 個工程師 6 小時」，AI ROI 就會被嚴重高估。

因此正式 Agent KPI 應加入：Cost of Failure。

這也是 YOLO LAB〈AI Agent POC 怎麼驗收？〉中需要把 Critical Error、人工覆核與工具執行結果獨立計算的原因。

Project OT 是否代表 AI Agent 沒有生產力？

不是。

Meta 自己仍然在大規模投資 AI。

Meta 2026 年第二季財報將全年資本支出預估維持在約 1,300 億至 1,450 億美元，主要支撐 AI 基礎設施與未來運算容量。

Mark Zuckerberg 也沒有放棄 Agent 或 AI-native 工作方式。

因此 Project OT 比較準確的結論不是「AI 失敗」。

AI 的能力進展，沒有快到足以按照最激進的人力假設重新設計整家公司。

這兩者差很多。

Agent 可以有很高價值。

但 Agent 有價值，不代表「1 Agent = 1 Employee」，更不代表「AI 產出增加 200% = 公司可以少 60% 人」。

企業組織不是單純的 Token → Output 函數。

裡面還有責任、判斷、協作、知識、審核、溝通與例外處理。

Meta 的真正教訓：先證明工作可以消失，再決定職位是否消失

企業今天討論 AI Agent 時，很容易先問：

可以省多少人？

Project OT 顯示，更有效的順序是先問：

哪些工作真的已經不需要人做？

這兩個問題非常接近，結果可能完全不同。

例如 AI Coding 可以消除 boilerplate、基本測試、API client、文件初稿與重複 refactor。

工程師因此可以把時間移向 architecture、review、security、product judgment、system design。

這種轉變仍然能提高生產力，但未必等於同比例減少工程師。

企業要怎麼避免自己的 Project OT？

第一步是建立人工 Baseline。

在 Agent 上線以前先知道：

• 一個任務現在花多久；
• 成功率是多少；
• 錯誤率是多少；
• 哪些地方需要主管判斷；
• 失敗會造成多少成本。

第二步，用真實案例跑 PoC，而不是 Demo。

第三步，把 Agent 放進 Shadow Mode。

第四步才逐步開放 Write 權限。

第五步比較 Before、Agent、Agent + Human。

最後再決定工作流程、職位與團隊結構是否需要重組。

順序不能反過來。

Project OT 最值得企業記住的一個數字不是 60%

60% 的團隊縮減構想最容易成為新聞標題。

但真正值得企業管理者記住的是另一組數字：

220% 與 36%。

前者代表工作活動。

後者更接近產品結果。

AI Agent 時代真正稀缺的能力，很可能不再只是「產生更多東西」，而是判斷哪些產出值得保留、哪些可以安全執行、哪些真的創造價值。

Meta 擁有全球頂尖 AI 研究人才、自己的模型、巨額基礎設施預算與龐大的工程團隊，仍然需要重新校正 AI 對組織生產力的假設。

對一般企業而言，這已經是一個足夠清楚的訊號：

先驗證工作，再改組組織。

資料來源

• Reuters，〈Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here’s how it imploded〉，2026 年 8 月 26 日。
• Reuters，〈How Meta’s AI workforce transformation plans went kaput〉，2026 年 8 月 26 日。
• Meta Platforms，2026 Q2 Financial Results，2026 年 7 月 29 日。

延伸閱讀

• 企業 AI Agent 是什麼？白話定義、適用工作與導入邊界
• AI Agent 導入流程怎麼開始？7 步驟與 30 天試點
• AI Agent POC 怎麼驗收？KPI、測試案例與 Go／No-Go 標準
• AI Agent 有哪些資安風險？Prompt Injection、資料外洩、過度授權與 Red Team 指南
• Mark Zuckerberg 如何把 Meta 從社群廣告推向 AI 平台？