上個月我在新竹陪一家做精密塑膠零件的老闆做 AI 工具評估。他坐下來第一句話：「老師我要先跟你坦白，我到現在還是用注音一個字一個字打字，我兒子說我是科技恐龍。我這種人真的可以帶公司做 AI 導入嗎？」

我把這個問題記在筆記本裡。不是因為特別，是因為這個月我聽到不下十次了。

老實說，這個問題問對了，但問的方向錯了。

「老闆不懂技術能不能帶 AI 導入」這個問法，預設了一件事：懂技術的人才能做這件事。但我在陪各種規模的公司做企業 AI 導入這兩年多，遇到的反例比正例多。很多技術背景的老闆，反而卡在導入中途，因為他會自己去改 prompt、自己去調參數、自己去做本來應該讓團隊來做的事——然後三個月後變成只有他一個人在用 Claude，其他人還是照舊。

不懂技術不是障礙。問題意識不清楚，才是障礙。

老闆的角色不是工程師

我喜歡用易經師卦來解釋這件事。師卦講的是「帶兵打仗」。卦辭說：「師，衆也，貞也。」用師卦問事，問的不是你個人有多強，是你能不能帶領一個群體往同一方向走。

師卦初爻更直接：「師出以律，否藏凶。」帶兵出征要有紀律、要有清楚的規則，否則藏凶。這和 AI 導入有多像：工具本身是中性的，能不能用好，在於帶領它的人有沒有給出清楚的問題框架。

老闆在整個導入過程裡的角色，是「出以律」，不是「自己上陣殺敵」。

那家新竹的塑膠零件廠老闆，他不會寫 Python，他也搞不懂 token 是什麼。但他跟我說了一件事，我立刻知道這個導入有機會成功：

「我們每個月在品質異常報告上花的時間，三個工程師加起來大概一百二十個小時。這個我不能接受。」

他知道問題在哪。他知道痛點是什麼、數字是多少、誰在受苦。這就夠了。

企業 AI 導入失敗，通常不死在技術

我見過最快失敗的案例，不是因為技術沒串接好，是因為沒有人說清楚「這個工具要解決什麼問題」。

有一家做食品外銷的公司，老闆找了一個懂 AI 的年輕人進來主導導入。那個年輕人很厲害，把一整套 LLM 工作流程架起來了，文件做得很漂亮。但三個月後老闆跟我說：「這些工具我的業務沒有在用，因為他們不知道為什麼要用。」

沒有人告訴業務，用了這些工具要解決什麼具體的問題。老闆覺得這是技術部門的事，技術部門覺得業務應該自己去學，業務覺得這是額外工作。工具導入變成了一個「技術部門的自嗨項目」。

問題不在那個年輕人不夠好。問題在老闆沒有把「問題定義」的工作攬在自己身上。

老闆的實際工作只有三件

這是我陪了幾十家公司之後得出的結論，不是理論，是從失敗案例裡倒推出來的。

第一，把問題說清楚。

不是「我要導入 AI」，是「我在採購詢價這個環節每週浪費八個人工小時，我要把它壓到兩個小時以下」。具體到可以量測。沒有這個，任何工具選型都會偏掉。

第二，給團隊空間去試。

很多老闆說「我不懂技術，所以我不干涉」，但實際上遇到工具測試期的小失誤就開始緊張，催進度，搞得團隊不敢試、不敢失敗。導入期間容忍一定程度的不完美，是老闆能給的最重要支持。說起來容易，做到的人不多。

第三，接受「不懂技術但要做判斷」這件事。

在 Claude Code 教學課上，我常遇到老闆說「這個我交給 IT 部門決定」。但 IT 部門不知道業務流程，業務不知道技術限制，老闆不介入，就沒有人做整合性判斷。老闆不需要懂 API 怎麼接，但需要能問出「這個工具如果跑起來，我的業務流程要改變哪一個步驟」——這是管理判斷，不是技術判斷。

---

那個注音打字的老闆，後來怎麼樣了？

我們花了兩個下午把品質異常報告的流程拆開來，確認 AI 可以介入的三個節點。他自己去跟兩個工程師說明要解決的問題，讓工程師去測試工具。六週後，那三個工程師的月度報告時間從一百二十小時降到四十三小時。

他自始至終沒有碰過一行程式碼。

這就是老闆在企業 AI 導入裡的角色。不是工程師，不是產品經理，不是提示詞高手——是問題的持有者，方向的設定者。

就這樣。

---