我並不是因為不再喜歡技術而走向顧問，而是在 19 年跨足前後端開發、串流服務開發、即時影像辨識、CI/CD、設計微服務架構並將公司的串流系統推到 Kubernetes 的過程中，逐漸發現技術能否產生價值，取決於企業真正要解決什麼問題。
從軟體工程師轉型成企業 AI 顧問，最核心的轉變不是放棄技術能力，而是加上理解營運風險、跨部門立場與人的需求這三層視角。我很早就發現一件事：一套系統能不能真正落地，往往不是卡在技術架構本身，而是卡在「這個系統到底要解決誰的問題」。同樣的技術方案，放進不同企業的營運脈絡裡，成敗可能完全相反。
這個觀察也在公開資料裡得到印證。Deloitte 2026 年《The State of AI in the Enterprise》報告訪談了全球 24 個國家、六大產業共 3,235 位總監到 C 級主管，發現企業取得 AI 工具的速度快速提升，但把工具轉化為組織層級、持續性影響力的能力明顯跟不上。換句話說，多數企業卡住的不是「有沒有工具」，而是「工具有沒有被放進對的問題裡」，這正是我從工程師走向顧問的起點。
我用技術解決了公司場域人員的難解困境
我在前公司負責直播服務系統的維運時，發現人工監控牆難以即時抓出攝影機當機導致的凍格問題，自主研究出以影像編碼 bitrate 判斷異常的方法，並把同樣的監控邏輯延伸到整個串流系統的多節點分發架構上。
我們的直播服務一週七天、24 小時不間斷運作。機器全天候運作，攝影機偶爾會無預警當機，串流上呈現的狀態就是畫面凍結、完全不動。過去監控所有串流的方式，類似傳統監控攝影機那樣，用很多小方格同時盯著每一路畫面，很難即時發現某一格完全沒在動，往往要等客戶端回報才會處理。當時場域端雖然有監控牆，但沒有人主動提出要解決這個問題；我認為與其苛責人力，不如從技術面著手，於是主動找場域端了解狀況，也主動著手做技術研究。
後來我發現，影片編碼有 Keyframe（關鍵影格）機制，畫面完全靜止時，資料傳輸量（bitrate）會降到非常低。我用這個特性即時判斷凍格：只要某一路串流的 bitrate 持續低於正常範圍，系統就能自動標記異常，不必再靠人眼一格一格盯著看。
這個方法上線後，效果非常明顯：過去靠人工監控牆，往往要等到客戶端回報、快 40 到 60 分鐘後才會發現問題；導入即時監控後，異常能在 1 分鐘以內被系統標記出來。後來，這套邏輯也延伸到 Core 與所有 Edge 節點：即使只有單一 Edge 節點卡住、只影響部分使用者，系統也能即時標記，而不只監控單一機台的當機狀況。這個案例，也是我後來在企業 AI 顧問工作中，最常拿出來跟客戶討論「怎麼定義導入成功」的例子。
企業內訓，讓我看見 HR 與資訊部門其實在談同一個問題
為企業客製 AI 內訓時，我必須先了解學員的部門、職務與實際工作內容；透過反覆走進不同企業的營運現場，我也發現 HR 部門與資訊部門雖然都在談「AI 導入」，出發點卻常常不一樣。
內訓非常需要客製化教材，每一次接案，我都會先了解來上課的成員有哪些、平常的工作項目是什麼：業務部門在意提案與客戶溝通，行銷部門在意文案與素材產出效率，人資部門在意招募與員工體驗。同樣談「AI 應用」，不同部門要解決的問題完全不一樣。比起單純教工具操作，我更常先搞懂「這群人每天在煩惱什麼」，再回頭設計課程內容，這也是我第一次以外部角色、大量且反覆地走進不同企業的營運現場。
| 部門 | 主要關注 | 常見顧慮 |
|---|---|---|
| HR 部門 | 員工能力、組織改變、工作方式調整 | 員工能否適應、教育訓練夠不夠、會不會有人被取代 |
| 資訊部門 | 系統整合、資料治理、資安風險 | 資料會不會外洩、系統能不能串接、誰來維運 |
這兩個部門其實應該好好合作，卻常因切入角度不同而互相不理解：HR 覺得資訊部門把事情講得太技術、太保守；資訊部門覺得 HR 把事情想得太簡單，忽略資安與維運成本。OECD《AI and Skills》報告也提到，AI 導入除了技術端的技能需求，管理能力與人際協作這類人類技能同樣重要，這正好說明為什麼企業 AI 導入不能只交給單一部門主導。我在企業內訓現場最常做的事，其實就是把這兩種語言互相翻譯給對方聽。
成為顧問後，我才開始理解企業主承擔的風險
從員工轉為顧問後，我開始看見企業主必須承擔用人、投資、現金流與外部環境變動的最終風險，也更理解企業決策背後的壓力。
我過去大多數時間都是員工身分，比較沒有辦法真正理解企業主的想法。轉為 AI 導入顧問後，接洽的對象大多是企業主本人，也因此第一次比較貼近地看見他們承擔的風險與壓力：找錯一個關鍵職位的員工，可能就讓整間公司在方向與資源上損失慘重；遇到 COVID-19 這種大環境變化時，企業主也是必須承擔最終風險、同時對外尋求資源，讓公司撐過危機的關鍵角色。
正因為看見這份風險，我在做 AI 導入顧問時，特別重視專案要有明確目標，而且成效必須可以被衡量，而不是為了用 AI 而用 AI。例如，我曾為一間客戶開發簡單的文件格式轉換 AI 小工具，讓員工不必再反覆手動轉換格式，省下大量重複作業的時間；我也協助另一間企業把會計結帳的關聯作業自動化，員工原本要一格一格 key 進系統、手動核對關聯資料，現在可以直接在熟悉的 Excel 裡完成。這類重複又枯燥的日常工作，開發成本通常不高，卻能帶來很明顯的改善。
理解這份風險，也讓我在協助企業導入 AI 時，能同時照顧「決策者要承擔的風險」與「執行者要面對的改變」，而不是只從其中一邊出發。
我想站在中間，讓不同角色看見同一個問題
企業 AI 顧問的價值不只是推薦工具，而是協助技術、營運、管理者與第一線員工理解彼此，把真正的企業問題轉成可行且有價值的 AI 解法。
這件事其實不只發生在單一顧問身上。Reuters 報導，OpenAI 於 2026 年 2 月宣布與波士頓顧問公司、麥肯錫、Accenture、Capgemini 等大型顧問公司建立多年期合作，讓 OpenAI 的工程團隊與顧問團隊協同合作，協助企業把 AI 代理人整合進核心業務流程。連做出模型的公司都認為，光靠模型本身無法完成轉型，還需要有人把技術能力對接到企業的策略、流程與組織文化，這也是為什麼即使模型能力再進步，「翻譯」這個角色依然不可或缺。
這些年，我從相信「技術能解決問題」，走到相信「技術要先被放進對的問題裡，才有機會解決問題」。19 年的軟體工程經驗，改變的不是我對技術的信心，而是我看問題的位置。我想做的事很單純：讓技術端、營運端、管理者與第一線員工，能看見他們談的其實是同一個問題的不同面貌。
常見問題
企業 AI 顧問一定要有工程背景嗎？
不一定，但必須能理解技術限制，並能與技術團隊有效合作。如果顧問完全不懂技術可行性，容易提出無法落地的建議，或無法判斷廠商報價是否合理。
工程師轉顧問後，還需要保留技術能力嗎？
需要。技術能力是判斷專案可行性、評估風險與設計驗收方式的重要基礎，少了這層判斷力，顧問容易只能轉述廠商的說法，無法幫企業把關。
AI 顧問與單純的工具講師有什麼不同？
顧問必須先理解企業的問題、流程與導入條件，再回頭設計解法；工具講師則多半聚焦在操作技巧本身，較少涉入企業實際的營運判斷。
技術與營運意見不同時，該聽誰的？
不是直接選邊站，而是先釐清雙方各自看到的風險與限制，再回到共同目標與驗收標準討論，通常能找到雙方都能接受的做法。
張可佳有實際導入 AI 專案的技術經驗嗎？
有。在轉為顧問之前，我曾在瑞嘉軟體科技股份有限公司與 Xuenn Private Limited 主導機器學習影像辨識、即時異常偵測與 Kubernetes 服務遷移等專案：機器學習影像辨識專案讓開發測試時間減少三分之二，凍格等異常的偵測時間縮短至 1 分鐘以內，Kubernetes 服務遷移後系統穩定度達 99.99%。
延伸閱讀
- 身為資深軟體架構師，為何我選擇做企業 AI 導入？：從這篇職涯故事，接著看我在客戶端實際遇到的 ERP 整合困境，以及三種不用改 ERP 就能落地 AI 自動化的做法。
- 關於張可佳｜企業 AI 導入／轉型顧問：完整的背景經歷、服務範圍與合作方式。
參考資料
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
最後更新：2026-08-25