企業 AI 轉型為什麼還在休息室？從祕密機器人到工作流革命

本文整理自 Possible Podcast 2026 年 1 月播出的三集系列對談，是系列文章的第二篇。

系列文章：霍夫曼 × Patil 的 AI 原生對談

1. AI 原生工作者的誕生——個人如何用 AI 重新定義工作方式
2. 企業 AI 轉型為什麼還在休息室？（本篇）——從祕密機器人到工作流革命
3. AI 原生新創：兩人團隊、六個 Agent、一天取代六個月——新創公司的 AI 原生實戰

連球場都還沒上

里德．霍夫曼（Reid Hoffman）是 LinkedIn 的共同創辦人、矽谷頂級創投 Greylock Partners 合夥人，同時也是微軟董事會成員與 OpenAI 最早期的捐助者之一。他近年接觸大量企業高層，對 AI 導入的進度有第一手觀察。Parth Patil 則是他團隊中的 AI 專家，UCLA 出身的資料科學家，曾在 Clubhouse 擔任第一位資料分析師，現在負責霍夫曼旗下各種 AI Agent 專案的開發，包括打造霍夫曼的數位分身「Reid AI」。

在第二集的一開始，霍夫曼就問了一個直白的問題：有沒有哪家大企業把 AI 做得好？

Patil 的回答同樣直白：除了那些本身就在做 AI 的公司（超大規模運算商和前沿實驗室），他還沒看到。每家企業都在講 AI 策略，董事會在催、執行長在推，但真正把 AI 融進日常運營的，他還沒見過幾家。

霍夫曼接著用了一個棒球比喻來形容現狀。他說，很多人把現在叫做 AI 的「第一局」，暗示比賽已經開始了。但他認為更準確的說法是：球員連球場都還沒走上去。他們還在休息室裡，成立委員會來研究「要不要出場」。

這個比喻之所以犀利，是因為它點出了一個很多人不願意面對的事實：大多數企業對 AI 的投入，還停留在「討論」而不是「實作」的階段。他們設了小組、做了概念驗證、辦了幾場工作坊，但沒有真正改變任何一個工作流程。

工作流層級的革命，只能由下而上

Patil 對企業 AI 導入的核心觀察是：AI 的影響力存在於「工作流」的層級，不是「策略」的層級。

什麼意思？他的解釋是這樣的：每個企業裡的每個人都有自己的一套工作流程——怎麼處理信件、怎麼準備報告、怎麼跑資料分析、怎麼追蹤進度。這些流程裡有很多環節是文字性的、重複性的，而語言模型天然就擅長處理這類任務。要找出哪些環節可以被 AI 改善，最有資格回答的人不是執行長或顧問，而是每天在做那個工作的人自己。

這就是為什麼他主張「由下而上」的導入方式。讓每個人去發現自己工作流中可以用 AI 改善的環節，然後把成功經驗分享出來。組織的角色不是制定 AI 策略，而是創造一個獎勵實驗和分享的環境——「這週我們學到了什麼？省了多少時間？跳過了哪些步驟？哪三個會議因為有了自動化方案而不再需要了？」

這個觀點和大多數企業正在做的事情恰好相反。多數企業的做法是：由上而下制定 AI 策略，找一小群人做概念驗證，然後試著推廣到全公司。Patil 認為這行不通，因為你不可能靠一個「關在小房間裡的小組」來找出整個組織裡的改善機會。

溝通層：最明顯的切入點

那麼，對那些想開始動手的企業來說，最容易下手的地方在哪？

Patil 的答案是溝通協調層。他的邏輯很清楚：語言模型天生擅長加速任何跟語言相關的任務。而在一家公司裡，最大量的語言相關任務就是——溝通。會議、會議紀錄、行動項目、誰負責什麼、進度追蹤、備忘錄、通知。這一整層都是文字密集的協調工作，也是 AI 可以立刻創造價值的地方。

霍夫曼自己的做法是錄下每一場會議，然後用 AI 加上一組提示（包含他所有的專案、合作者、公司資訊），讓 AI 從會議紀錄中抽取幾個維度的資訊：有哪些行動項目？誰應該負責？有沒有我忘記諮詢的人？有沒有跟其他專案的交集需要通知相關人？

這種做法的好處不只是省時間。霍夫曼指出，它解決了一個組織裡的經典難題：「每個人都想參加大會議」。因為以前不參加就不知道發生了什麼事。但如果會議有 AI 紀錄和智慧摘要，你就可以把核心會議縮小到真正需要在場的七個人，其他人透過 AI 摘要來了解進展、被諮詢和被通知。甚至高管可以在會前告訴 agent：「我想確保這個問題在會議中被討論到。」Agent 就會在會議中提醒：「順帶一提，霍夫曼希望這個問題也被考慮。」

這不是科幻小說。這些都是現在就可以做的事，技術門檻極低。

一分鐘取代三週：資料分析的示範

第二集中最震撼的段落，是 Patil 的現場示範。

他打開一個 Claude Code agent，指向一個資料夾，裡面有一家虛構玩具公司的幾個 CSV 檔案——訂單資料、退貨資料、商品資料。然後他只下了一個指令：「看這個資料夾裡的每一個 CSV，用你認為合適的方式分析資料，然後幫我建一個儀表板，讓我們可以用視覺化的方式理解這家公司的數據。」

不到一分鐘，Claude Code 就用 Python 分析完資料，生成了一個完整的互動式儀表板：營收成長趨勢、利潤變化、轉換率分析，全部到位。然後 Patil 追加一個要求：「幫我用 McKinsey 風格做一份簡報。」幾分鐘後，一份有經典配色、結構化數據和「建議下一步行動」的 HTML 簡報就出來了。

霍夫曼看完之後說了一句話很到位：「這看起來確實像我在 McKinsey 看過的簡報。」

Patil 強調的重點不是「AI 能做簡報」這件事本身，而是時間尺度的崩塌。他說，以前他當資料分析師的時候，同樣的工作需要兩到三週——理解數據結構、寫查詢、做視覺化、排版、彙整洞察。現在一分鐘就完成了。

而當分析的成本從三週降到一分鐘，整個遊戲規則就變了。以前你只負擔得起問最重要的幾個問題，因為每個問題都要耗費分析師的時間。現在你可以一路追問下去：轉換率會不會隨時段變化？跟假日有沒有關係？有沒有什麼意外的發現？這些「以前問不起的問題」，現在問起來幾乎零成本。

「BI 是 AI 的子集」

Patil 在示範之後說了一句聽起來狂妄但其實很有道理的話：「商業智慧（BI）是 AI 的子集。」

傳統的理解是反過來的——企業先有 BI 系統、有資料倉儲、有分析團隊，AI 是後來加上去的錦上添花。但 Patil 的論點是：如果你有一個具備通用智慧的系統，商業智慧只是它能力範圍內的一個應用。你不需要先建好整套 BI 基礎設施才能開始做分析。你只需要有資料（即使是雜亂的 CSV），加上一個 coding agent，就能開始提問和獲得洞察。

這個觀點的實際意義在於：很多中小企業之所以沒有做好數據分析，不是因為不想，而是因為「資料不乾淨」——這是 Patil 當資料分析師時最常聽到的抱怨。大家都知道數據很重要，但真正動手分析之前，要先花大量時間整理資料格式、處理缺失值、統一命名規則。

而語言模型恰好特別擅長的一件事，就是從非結構化的混亂資料中提煉出結構。你可以把一整封客訴信丟給它，它會整理出三個行動項目和一個主要結論，然後轉成適合塞進 CRM 系統的格式。資料清理——這個過去最耗時、最枯燥、最容易被拖延的環節——突然之間變成了語言模型最容易處理的任務之一。

祕密機器人：組織裡的 AI 地下運動

Patil 在討論企業文化時提到了一個現象：很多公司並不是「抗拒」AI，而是對它「封閉」。結果就是，某些員工偷偷學會了用 AI 大幅提升效率，但不敢讓別人知道。他們擔心分享之後會惹麻煩——也許公司不允許使用外部工具處理內部資料，也許同事會覺得他們在「作弊」。

賓州大學華頓商學院教授伊乘．乘利克（Ethan Mollick）給這種人取了一個名字：「祕密機器人」（Secret Cyborg）。他們在暗處用 AI 武裝自己，效率遠超同事，但選擇保持沉默。

Patil 承認，短期來看這對個人是有利的。但長期來看，一個「獎勵實驗與分享」的團隊會走得遠得多，因為個人的學習最終會變成組織的學習。如果每個人都在地下各自摸索，公司永遠無法把這些分散的突破串連成系統性的能力。

霍夫曼在這裡插入了一個有趣的旁枝。他問 Patil：你猜好萊塢有多少比例的編劇在家偷用 AI？（由於工會規定，編劇室裡不能使用 AI。）Patil 猜 40%。霍夫曼說他猜 70%。Patil 回應說，他確實認識一些，他們不會承認，但當你跟他們深聊，他們會抱怨「AI 沒辦法完美記住之前每一場戲的細節」——這顯然是在高頻使用之後才會有的抱怨。

分析師不再寫 SQL，而是問對的問題

AI 對專業角色的重塑也是這幾集反覆出現的主題。Patil 用自己的老本行——資料分析——做了最清楚的說明。

他說，分析師的新工作不再是「寫出正確的 SQL 查詢」，而是「問出正確的問題」。語法對不對已經不是重點了，重點是你有沒有提出正確的分析方向。這把整個角色從「執行者」提升到了「策略者」的層級。

霍夫曼延伸了這個類比，引用了微軟的 Sam Schillace 的觀點：程式設計正在從「寫程式」變成「系統架構」。他強調，這不只是 coding 的事，同樣的轉變正在發生在法律文書、稽核風控、簡報製作、備忘錄撰寫等所有知識工作領域。

Patil 補充了一個重要的面向：平行化。人類是單執行緒的，一次只能做一件事。但如果你把分析需求拆成十個不同角度，同時丟給十個 agent，你就能在同一段時間內從十個方向攻擊同一個問題。這是以前完全不存在的能力。

在這之上，Patil 給出了一個具體的工程生產力數字：一個過去需要 12 個工程師花兩年才能完成的大規模遷移專案，如果用上 Claude Code，4 個工程師可以在六個月內完成。這不只是「效率提升」，而是根本改變了你估算「這件事需要多少人月」的整個框架。

非技術主管該怎麼辦？

霍夫曼和 Patil 都意識到，很多決策者本身並不懂技術。他們的建議分成兩層。

第一層是心態：你不需要懂語言模型的原理（什麼是 token、為什麼它能預測下一個字），你需要的是理解「跟語言模型一起工作是什麼感覺」。這是一種新的技能，跟理解底層技術是不同的事。Patil 的比喻是：你不需要知道汽車引擎的運作原理才能開車，但你需要知道方向盤和油門在哪裡。

第二層是行動：如果你是非技術主管，最重要的事情是授權你的技術同事（CTO 或工程主管）去嘗試這些工具，然後讓那些學習向下擴散到整個組織。不要讓你的技術同事害怕實驗、害怕犯錯、害怕探索這些工具的價值。

對於更積極的主管，霍夫曼有一個務實的建議：找一個技術人幫你設定好環境。你不需要自己學 Claude Code 的操作細節，你只需要說：「我想要這種分析能力、我想要這種自動化，幫我設定好，讓我可以開始用。」就像學跳舞一樣——放下身段，跟會跳的人搭檔，在過程中自然就學會了。

霍夫曼在這裡畫了一個跟第一集「放下自尊」相呼應的連結：學習跟 AI 搭檔的心態，跟學習跟比你懂的人搭檔的心態是一樣的。都需要放下「我應該什麼都會」的包袱。

軟體便宜到不需要理由

第二集的尾聲觸及了一個更根本的轉變：當製作軟體的成本趨近於零，你應該做更多軟體。

Patil 分享了他用 Repl.it 做的各種個人工具——大多數都不是拿來賣的，純粹是為自己的需求而做。他說，以前建一個軟體需要評估 ROI、寫需求文件、估時程；但當你可以用 Vibe Coding 在一天之內做出一個堪用的版本，「這東西值不值得做」的門檻就不再是阻礙了。

這改變了「買還是做」的判斷框架。Patil 的建議是：如果是標準化、需求不太變動的東西（CRM、合規工具、SOC 2 相關），買現成的就好。但如果是你獨特的問題空間、獨特的客戶群、獨特的工作流程，就自己做。因為現在做的成本已經低到，比你花時間去找、評估、導入一套外部工具還要快。

而且內部工具有一個天然優勢：你就是使用者，回饋循環極短。以前需要 UX 研究員、產品經理、工程師三個人才能推動的功能開發，現在一個人可以扮演所有角色——而且因為迭代速度快，一天可以做六七個功能，早上還沒有的工具，晚上就有了一個相當好用的第一版。

我的觀察

「祕密機器人」現象在臺灣企業可能更普遍，但動機不太一樣。 Mollick 描述的美國版本是員工怕被認為「偷懶」或「作弊」。但在臺灣的企業文化裡，更常見的恐懼可能是「怕被說不專業」——如果你用 AI 寫出來的報告比你自己寫的好，那是不是代表你的能力不夠？這種恐懼讓很多人寧可偷偷用，也不願意在團隊面前承認 AI 幫了大忙。結果就是，整個組織錯失了從個人學習升級為集體學習的機會。

霍夫曼的棒球比喻放到臺灣，可能更嚴重。 他說美國企業連球場都還沒上。但臺灣企業的狀況可能是——不只沒上場，可能連球場在哪裡都還在討論。很多臺灣企業的「AI 策略」停留在「開幾堂教育訓練」或「找顧問寫一份報告」的階段，離真正改變任何一個工作流程還有一大段距離。而 Patil 的「由下而上」主張——讓每個員工在自己的崗位上發現 AI 的應用點——對臺灣企業來說可能是更實際的路徑，因為它不需要等待管理層的「策略共識」。

「BI 是 AI 的子集」這句話值得反覆咀嚼。 它翻轉了一個根深蒂固的假設：「我們要先把資料整理好，才能開始做分析。」無數的資料專案就是卡在這一步——永遠在整理、永遠整理不完。但 Patil 的示範告訴我們，語言模型本身就擅長處理雜亂資料。你不需要先有完美的資料倉儲才能開始。這對預算有限、資料品質參差的中小企業來說，可能是最重要的認知突破。

工程生產力的數字（12 人兩年→ 4 人六個月）值得臺灣企業認真看待。 這不是某個特殊案例的極端值，而是 Patil 基於實際觀察給出的一般性估算。如果這個估算大致準確，它的意思是：臺灣企業沿用至今的「人月估算」框架——這個專案需要多少工程師、要做多久——整個需要打掉重算。過去你可能需要開一個 20 人的團隊來做某件事，現在也許 5 個人加上適當的 AI 工具就夠了，而且完成得更快。這不只是效率問題，而是預算分配、團隊規模、專案時程的全面重估。