先用一句白話問
AI 導入應該由高層從上往下推，還是由第一線團隊從下往上開始？
務實答案是：兩者都需要，但角色不同。
由下而上比較容易找到真實痛點；由上而下則提供優先順序、資源、風險邊界與責任歸屬。
少了任何一邊，AI 導入都很容易卡住。
由下而上的優點
最接近工作的人，通常最知道時間浪費在哪裡。
他們知道哪些問題每天重複、哪些文件最難找、哪些交接最混亂、哪些任務大家其實都不想做。
所以由下而上的探索很有價值。
例子：
- 客服知道哪些問題每天重複出現。
- 營運知道哪些試算表交接最容易出錯。
- 銷售知道 inbound 線索哪裡最不一致。
- HR 知道哪些制度問題一直被問。
這些觀察通常比抽象策略更接近真實工作。
由下而上會在哪裡失敗
但只有由下而上的熱情，也很容易失敗。
常見問題包括：
- 太多零散工具實驗
- 沒有共同的安全與資料規則
- 沒有預算 owner
- 不知道怎樣算成功
- 個人生產力工具無法變成團隊工作流
結果就是大家都在試 AI，但公司沒有真正學到如何導入 AI。
由上而下的優點
管理層可以創造 AI 進入營運所需要的條件。
主管可以決定：
- 哪些商業問題最重要
- 哪些風險不能碰
- 誰負責試點
- 預算在哪裡
- 要回報哪些指標
- 什麼時候擴大，什麼時候停止
這很重要，因為 AI 工作流導入不只是技術決策。它會改變責任、審核、品質控管，有時候也會影響客戶體驗。
由上而下會在哪裡失敗
由上而下的 AI 計畫，常常敗在太抽象。
例子：
- 「我們需要 AI strategy。」
- 「每個部門都應該用 AI。」
- 「我們要用自動化轉型營運。」
這些方向可能沒錯，但它們沒有說出第一段要改的工作流。
沒有工作流，團隊不知道星期一早上到底要改什麼。
更好的模式：主管定框架，工作流做證明
比較好的方式是把兩者結合。
主管先定框架：
- 為什麼 AI 對公司重要
- 哪些風險不能接受
- 哪些業務領域優先
- 試點要用什麼標準判斷
團隊提出工作流候選：
- 重複客服問題
- 內部知識查找
- 文件處理
- 銷售 intake
- 營運交接
接著公司選一到兩段工作流，用清楚 owner 和指標來測試。
例子
比較弱的由上而下說法：
「今年我們要成為 AI-first company。」
比較弱的由下而上說法：
「大家可以自己試任何 AI 工具。」
比較好的結合說法：
「這一季我們先測兩段重複工作流：客服政策回覆與內部 SOP 查詢。每個試點都要有 workflow owner、核准來源、人工審核與一個可衡量成果。」
這樣既有方向，也能落地。
主管可以問的問題
在啟動 AI 導入前，可以先問：
- 哪些工作流是團隊已經想改善的？
- 哪些足夠重複，可以被測試？
- AI 可以安全使用哪些資料或來源？
- 每段工作流由誰負責？
- 哪裡需要人工審核？
- 哪個指標決定是否擴大？
這些問題可以把管理層的企圖心，接到實際營運證據。
Glasrocks 的看法
只有由上而下，容易變成策略口號。
只有由下而上，容易變成零散實驗。
真正有用的是中間那條路：被管理的工作流試點。主管設定邊界，團隊提出真實工作，再用試點證明 AI 是否真的能進入日常營運。
可以先用 AI 工作流適配度診斷 測一段工作流，再用 Glasrocks Method 設計試點路徑。