文組人不是 AI 時代的弱勢，是企業 AI 導入裡常被漏看的角色

好幾個企業內訓在洽詢期間，HR 都曾擔心地問我：

「這些內容，文組同事聽得懂嗎？」

我每次聽到，都會有一點熟悉的尷尬。

因為我曾經就是那個文組同事。政大華語教學碩士，討厭數學，進科技新創以後長期被一群理工學霸 carry。AI 大舉進入工作的那一兩年，我心裡其實也閃過很多次同樣的問題：這些東西，我真的聽得懂嗎？

後來很慢很慢地，我才意識到這個問題問反了。

文組人不是 AI 時代的弱勢。比較像是，企業 AI 導入裡最容易被低估、但也最需要被放在正確位置上的角色。

我一開始也以為 AI 導入是工程題

剛開始接觸企業 AI 導入的時候，我下意識覺得這應該是工程部門的題目。模型、API、RAG、權限、資料安全，聽起來每個字都很工程。

但這幾年因為演講、內訓和 Numbers Protocol 自己的轉型，我看了不少團隊從「買了 AI 工具」走到「沒有人用 AI 工具」。

他們卡住的地方，常常不是模型不夠強。比較常見的是：老闆買了 ChatGPT Enterprise，期待全公司自然變聰明；HR 辦了 prompt 課，大家課堂上覺得很有趣，回到工作裡還是回 Excel；某個同事自己摸出一套很好用的 AI 工作流，但沒有文件、沒有交接，其他人學不會。

這些都不是純工程問題。是「人怎麼理解一個新同事」、「組織怎麼改變習慣」、「複雜概念怎麼被翻譯成日常動作」的問題。

這些問題文組人其實並不陌生。

文組訓練裡，有一種很不顯眼的肌肉

我以前在華語教學所受過一種訓練：把你覺得理所當然的語言規則，講給完全沒有那套語感的人聽。

你不能只說「這個語感不對」。你要先想對方腦中的英文、日文、越南文文法是怎麼運作的，找一座小橋讓他從他熟悉的邏輯走到中文的邏輯。

後來我發現，prompt engineering 很大一部分也是這件事。

不是你把指令寫得很長 AI 就會懂你。你要知道它目前看得到什麼、看不到什麼；你要知道它會怎麼誤解你的話；什麼資訊要先給，什麼標準要明說，什麼例外要放在旁邊。

文組訓練裡還有另一種肌肉，是處理曖昧。

文學作品沒有唯一標準答案，歷史詮釋也沒有一個 forever correct 的版本。你習慣在「有點對，但還不夠準」的狀態裡工作。

AI 的輸出其實也是這樣。它很少是 0 分或 100 分，更常見的是 60 分。如果你期待它一次給標準答案，你會很快崩潰；如果你習慣處理不完整的文本，你反而比較知道怎麼接住它。

我們把 AI 當工具，所以一直失望

我看過最常見的企業 AI 導入誤會，是把 AI 當工具。

工具要好用，工具最好開箱即用，工具壞掉是工具的問題。可是 AI 很不像工具。它比較像一位新進同事。

新進同事第一個月不會完全懂公司語氣，不知道客戶的地雷，不知道創辦人對某幾個字有過敏反應。你會教他、會 review、會補 context、會把「這次哪裡不對」寫下來，下次讓他少踩一次。

這也是我們後來在 Numbers Protocol 慢慢走到的狀態。2025 年 4 月，我們開始很認真地把公司工作環境改成 AI-friendly 的樣子。不是再多買幾套工具，而是重新想：如果 AI 真的是同事，它需要什麼樣的辦公室？

於是我們開始幫 AI 同事取名字、定義職責、留下紀錄。每個 AI 同事都有自己窄一點的 scope，不再用一個萬能 prompt 應付全部。我會在另一篇談 95% AI pilot 失敗那篇裡，把這套設計講得更細。

過程其實也有很多時候很煩。教 AI 同事跟教人類同事一樣需要耐心，而且它還會用一種很自信的語氣犯錯。

但回頭看，真正改變的不是工具，是人類同事的位置。

當 AI 接掉大量整理、草稿、校稿、重複性檢查以後，人類不是消失，而是被迫升級成主管、編輯、判斷者、context provider。

那個位置，其實很文組。

翻譯者不是輔助角色

企業 AI 導入裡，我越來越覺得最缺的不是更多工具，而是翻譯者。

不是中翻英那種翻譯。

是把技術翻成人話，把人話翻成 spec，把主管的焦慮翻成可測試的問題，把第一線同事的抱怨翻成 workflow 裡真的卡住的那一格。

很多 AI 導入失敗的現場長得很像。工程部說，功能已經做好了；業務說，可是我不知道什麼時候該用；主管說，我們不是已經導入 AI 了嗎；員工說，這跟我每天要交出去的東西有什麼關係？

中間缺的不是 API。缺的是有人願意坐在交界處，把每一邊在說什麼翻出來。

文組人如果只把自己看成「不懂技術的人」，會錯過這個位置。但如果文組人願意承認自己不懂，同時也願意學到足夠可以翻譯，那會是一個很有 leverage 的位置。

我自己到現在也不是工程師。我不會假裝自己能寫 production code。但我現在可以讀懂 PR 在改什麼，可以問工程師 issue 怎麼拆，可以跟 AI 一起把技術文件翻成內訓裡聽得懂的版本。

這些能力不是因為我突然變理工，是因為我終於接受自己的角色是翻譯者。

關於人在 AI 時代到底要守什麼、放手什麼，這幾年 Tammy 跟我講過的一句話我一直記得，我把它寫在 《AI 焦慮這件事，我後來比較願意把它看成提醒》 那篇。那篇可以跟這一篇連著看。

把已有的能力重新命名

我不太想把這篇寫成「文組人的 AI 生存指南」。那種標題很容易讓人更焦慮，好像我們又要多學十個工具、多考一張證照、多追三個 newsletter。

我自己的體感比較像是，先不要急著證明自己懂 AI。先把你本來就有的能力重新命名。

你會把複雜概念講清楚，那是 prompt 和 onboarding 能力。

你會聽出一句話背後真正的情緒，那是 user research 能力。

你會把散亂資訊整理成一條故事線，那是 context engineering 能力。

你願意在不確定裡慢慢修出一個比較準的版本，那是跟 AI 協作最重要的耐性。

這些不是 AI 時代的邊角料。這些是 AI 時代組織最缺的中介層。

回到 HR 那句話

寫到這裡，我想回到開頭那位 HR 的擔心。

「這些內容，文組同事聽得懂嗎？」

如果有機會再被問一次，我大概會這樣回答：聽不聽得懂，不是文組這個身分決定的。是公司有沒有人願意坐下來，把工程、業務、行銷、客服各自講的話翻成同一種語言。

那個翻譯者，常常剛好就是文組同事。

這件事沒有很帥，也很容易在組織裡被當成「行政」而不是「核心」。但我越來越覺得，這就是很多公司 AI 導入能不能走下去的差別。

延伸問答

Q: 文組人真的需要學寫 code 嗎？

A: 不一定。更重要的是學會讀懂系統在做什麼、限制在哪裡、怎麼把需求說清楚。能寫 code 當然很好，但不是唯一入口。

Q: 企業 AI 導入最容易卡在哪裡？

A: 很多時候卡在期待錯誤。把 AI 當工具，就會希望它開箱即用；把 AI 當新同事，才會留下 onboarding、review、scope 和責任邊界。