AI劇場：為何90%的企業「使用AI」卻只有23%創造價值

McKinsey 2025年全球AI調查發現，90%的組織表示以某種形式使用AI，但僅有23%在生產規模上部署AI代理。其餘67%都在上演AI劇場：有可見的投資，卻無可衡量的成果。¹

在我的職業生涯中，我親眼見證了三種AI劇場的樣貌，自己也曾實踐過其中一種。

TL;DR

AI劇場描述的是一種組織行為：企業在AI上進行高調投資（聘僱AI團隊、宣布AI計畫、運行AI試驗專案），卻未能創造可衡量的商業價值。在ZipRecruiter擔任12年產品設計領導職務，以及獨立建構AI代理基礎架構一年之後，我見過了兩面：組織上演AI劇場，以及我自己早期幾乎也踩進同樣陷阱的經歷。AI採用與AI價值創造之間的落差有三個根本原因：獎勵活動而非成果的錯位激勵機制、阻止AI系統存取生產資料的技術負債，以及將AI團隊與業務決策者隔離的組織結構。

---

採用與價值的落差

McKinsey調查了跨產業的1,400位高階主管。頭條發現：AI使用率已近乎普及。被掩蓋的發現：價值創造並未跟上腳步。²

指標	百分比
「使用AI」的組織	90%
將AI投入生產的組織	~33%
擴展AI代理規模的組織	23%
停留在試驗階段的組織	67%
報告AI帶來顯著投資報酬率的組織	~15%

「使用」與「創造價值」之間的落差，並非所有企業都會自然跨越的成熟度曲線。大多數停留在試驗階段的企業都具有共同的結構性特徵，若不進行刻意的組織變革，就無法取得進展。³

---

我親眼見證的三種樣貌

樣貌一：宣傳遊戲

在我非正式顧問的一家公司，產品團隊宣布了一個「AI驅動搜尋」功能，實際上只是將使用者查詢傳送到基礎模型API，沒有微調、沒有評估框架、除了「我們上線了」之外沒有任何指標。新聞稿獲得了媒體報導。該功能的使用率僅有2%，六個月後悄然下架。

診斷問題：該AI功能是否有使用指標、留存率和客戶滿意度分數？還是團隊只追蹤「我們出貨了一個AI功能」？⁴

樣貌二：試驗工廠

我透過職業人脈認識的一家中型企業，在2024年跨部門運行了12個AI概念驗證專案。每個試驗都有專責團隊、特定使用案例和90天時程。一個試驗進入了生產環境。其餘11個產出了令人印象深刻的展示，供高階主管在董事會議上展演。該組織缺乏大規模營運AI系統所需的基礎設施（MLOps、資料管線、監控系統）。

診斷問題：該組織2024年的AI試驗中，有多少現在無需人工介入即可在生產環境中運行？⁵

樣貌三：招聘即期望策略

一位前同事以「AI主管」的身份加入一家公司，期望能轉型營運。AI團隊建構了令高階主管驚豔的展示，卻無法存取生產資料庫、客戶端系統或業務指標儀表板。每一次資料請求都需要向資料工程團隊提交工單，週轉時間為2至3週。18個月後，團隊轉向建構內部聊天機器人。⁶

診斷問題：AI團隊是否能直接存取生產資料庫、客戶端系統和業務指標儀表板？還是每次資料請求都需要向另一個團隊提交工單？

---

我自己的AI劇場時刻

坦白說：我早期的Claude Code hook系統帶有AI劇場的成分。第一個月我建構了25個hook。許多都是令人印象深刻的展示：情境注入、哲學強制執行、設計原則驗證。但我並未衡量它們是否提升了程式碼品質、減少了錯誤，或節省了時間。我在追求精密感的滿足，而非可衡量的成果。

轉捩點是建構部落格品質檢查工具。與先前的hook不同，該檢查工具有可衡量的標準：引用準確性、meta描述長度、程式碼區塊語言標籤、註腳完整性。我能計算修正前後的發現數量。我能衡量誤報率。該檢查工具從「AI驅動」轉變為「可衡量地有價值」，因為我在建構之前就定義了成功標準。

我現在的反劇場檢核清單： 1. 在建構之前定義指標。「如果這個有效，哪個數字會改變？」如果我回答不出來，我就是在做劇場。 2. 衡量基線。沒有AI的情況下，現行流程表現如何？我的部落格文章在自動化系統之前平均有4.2個檢查發現。之後：0.3個。 3. 追蹤持續價值。我的95個hook在每次會話中運行。遞迴防護已阻擋了23次失控的生成嘗試。git安全守護已攔截了8次強制推送嘗試。這些是真實的數字。⁷

---

根本原因

錯位的激勵機制

大多數組織獎勵AI團隊的活動（啟動的試驗、訓練的模型、宣布的功能），而非成果（產生的營收、降低的成本、改善的決策）。活動指標更容易衡量和報告。⁸

激勵機制的錯位會層層傳遞。AI團隊為了啟動令人印象深刻的試驗而優化，因為上線會受到表揚。生產營運被忽視，因為維護是隱形的。

技術負債阻礙資料存取

AI系統需要存取生產資料。生產資料存在於AI成為策略優先事項之前建構的系統中。資料基礎設施投資通常是模型開發成本的3至5倍。那些為「AI」編列預算卻不為「使AI成為可能的資料基礎設施」編列預算的組織，始終無法達到預期成效。⁹

組織孤立

被定位為「創新團隊」或「卓越中心」的AI團隊在產品開發流程之外運作。成功擴展AI規模的企業將AI工程師嵌入產品團隊，遵循與嵌入式設計師和嵌入式分析師相同的已證明有效的模式。組織模式比技術更重要。¹⁰

---

真正有效的做法

從決策開始，而非從模型開始

創造AI價值的組織從識別AI可以改善的特定業務決策開始。以決策為先的方法將AI系統限縮在可衡量的成果上：量化當前決策品質、衡量AI輔助品質、計算差異。¹¹

我的部落格檢查工具遵循這個模式。決策：「哪些部落格文章達到發布的品質標準？」指標：每篇文章的檢查發現數。基線：沒有檢查工具時每篇文章4.2個發現。當前狀態：使用檢查工具和自動化發布前閘門後每篇文章0.3個發現。

先投資資料基礎設施

將AI擴展到試驗之外的組織會在模型開發之前投資資料基礎設施：

• 資料管線——持續交付乾淨的生產資料
• 特徵儲存庫——維護一致的特徵定義
• 監控系統——偵測模型退化
• 治理框架——追蹤資料血統¹²

將AI嵌入產品團隊

坐在產品團隊中的AI工程師共享團隊目標、理解團隊限制，並且每天看到團隊的資料。Google最成功的內部AI應用（垃圾郵件偵測、廣告排名、搜尋品質）都是由嵌入在負責這些系統的產品團隊中的AI工程師所建構。¹³

---

代理的前沿

McKinsey報告將AI代理視為下一個轉折點。在已經從AI中創造價值的組織中，62%正在試驗代理。在仍處於試驗模式的組織中，僅有8%在研究代理。¹⁴

代理加劇了AI劇場的挑戰。一個自主採取行動的代理需要對模型輸出更高的信心、更強的監控和更清晰的治理。我的審議系統透過任務自適應共識門檻（安全決策85%、文件50%）和生成預算強制來解決這個問題。無法成功部署推薦模型的組織，也不會成功部署自主代理。

---

重點摘要

給高階主管： - 用成果指標（營收、成本、決策品質）而非活動指標來審計AI計畫；如果團隊報告活動卻沒有成果，該組織就是在上演AI劇場 - 為資料基礎設施編列模型開發成本3至5倍的預算；基礎設施是每個AI生產系統的先決條件

給AI/ML領導者： - 將AI工程師嵌入產品團隊，而非建構集中式AI團隊；與生產系統的組織鄰近性決定了擴展的成敗 - 終止無法在90天內闡明生產路徑的試驗；沒有生產計畫的試驗只是展示

給個人從業者： - 在建構任何AI功能之前定義可衡量的成功標準；「哪個數字會改變？」是反劇場的關鍵問題 - 追蹤持續價值，而非上線指標；我的git安全守護已攔截了8次強制推送嘗試，這個數字比「我們部署了一個安全hook」更重要

---

參考文獻