Day 01:五年後再談 AI 落地——為什麼是「雙主軸」?
2021 年,我在鐵人賽寫了《從 AI 落地談 MLOps》(GitHub)。那 30 天在回答一個問題:模型訓練好了,然後呢?
五年後,這個問題不但沒有過期,還變得更尖銳了——因為現在連「訓練模型」這件事,仍不是大眾的選項,很多團隊任務不再於訓練模型,而是直接呼叫 API,兩週做出一個看起來很厲害的 Demo,然後卡在同一個地方:上不了線,或者上線了沒人知道它是好是壞。
這 30 天,我想用一個不太一樣的方式重新 回答 AI 落地:不從技術出發,而是從職缺出發。
今天要解決的問題
先講三個現實可能出現的場景,如果有遇到類似情況就是我夢到的:
場景一:Demo 很漂亮,上線遙遙無期。 資料科學家在 Notebook 裡跑出 0.92 的 AUC,交給後端說「幫我上線」。後端打開檔案,看到 47 個排序未明的 cell、路徑寫死在 /Users/xxx/Desktop/、用了三個沒寫進 requirements 的套件。這個模型最後花了三個月才上線,上線時準確率只剩 0.81,沒人知道為什麼。
場景二:上線了,然後沒人管。 模型跑了八個月,某天業務單位說「這個推薦最近怪怪的」。查下去發現上游三個月前改了資料格式,某個特徵一直是空值,模型把空值當成一個有意義的類別在用。沒有任何告警響過,因為根本沒有人設定。
場景三:RAG 做出來了,但沒人敢用。 花兩個月接了公司文件做企業知識助理,主管問:「它答錯的機率多高?」團隊答不出來——因為從來沒有評測集。上線一週後有人發現,它會把 A 部門的薪資文件內容回答給 B 部門的同事。
這三個場景,分別對應這個系列的三塊拼圖:上線的工程能力、活著的維運能力、產品的品質與安全能力。而市場已經把它們打包成了兩個職務。
📊 職缺訊號
2026 年 7 月,我對公開職缺做了一次系統性擷取與分級:12 組查詢、7,149 列原始結果,去重後 4,343 筆職缺, 其中 842 筆被判定為高/中相關(方法與限制明天詳談)。這批資料清楚地分成兩群:一群在講「平臺、部署、管線、監控」,另一群在講「RAG、Agent、提示、評測」。它們不是同一個職務,也不是上下游關係。
文章基於 2026 年 7 月的 4,343 筆職缺資料分析,雖具時效性,但公開職缺反映的是「開得出職缺的大中型企業」之需求,容易忽略不需要公開招募或直接交由外部 Vendor / 顧問處理的小型企業真實現狀。
一、現象:一條價值鏈,兩個端點
我們先看市場實際上在徵什麼樣的人。

圖 1-1:雙主軸的價值鏈分工與交會地帶(依 2026-07-25 職缺任務訊號整理的示意架構)。上排是「讓模型可靠地上線與活著」,下排是「讓模型變成有人用的產品」,中間那條黃色的 LLMOps 是兩者都要碰、目前也最缺人的地方。
主軸一:MLOps/LLMOps 工程師。 這角色關心的是:模型能不能可重現地訓練出來、能不能自動部署、掛了會不會有人知道、一個月燒多少 GPU 錢。最高頻的任務訊號是「AI/ML 平臺與基礎設施」,出現在 58.5% 的相關職缺裡。
主軸二:生成式 AI 應用與代理系統工程師。 此角色關心的是:使用者問的問題答不答得出來、答錯了怎麼辦、能不能引用來源、能不能幫使用者 真的把事情做完。最高頻的任務是「RAG 與企業知識庫」(48.1%)與「Agent、工作流程與工具串接」(47.6%)。
這兩個職務的焦慮不同:前者半夜怕被叫起來,後者白天怕被使用者說是快樂寶貝。但他們服務的是同一個系統。另外撇開技術問題,實際落地的最大瓶頸往往是兩者之間的「跨領域溝通」與「業務理解能力(Domain Knowledge)」。
二、原理:五年間,什麼變了、什麼沒變
我把 2021 年那個系列的大綱,和今天的職缺任務訊號放在一起對照:

圖 1-2:MLOps 五年對照(評分為作者依兩份系列大綱與任務訊號的主觀對照示意,非量測數據)。左側灰色是 2021 年的重心,右側藍綠色是 2026 年雙職能的重心。
沒變的地基(這是好消息):
- 可重現性依然是一切的前提。只是現在要重現的不只是「程式碼+資料+環境」,還多了「提示+檢索索引」。
- CI/CD 與自動化管線依然是規模化的唯一解。
- 監控依然是模型活著的必要條件,而且重要性上升了——因為 LLM 的失敗更安靜、更難察覺。
被改寫的任務:
- 「自己訓練模型」的重要性大幅下降。 2021 年的 MLOps 假設你會訓練模型;2026 年多數團隊直接用別人的模型。訓練管線沒有消失,但它從「主線」變成了「有需要才走的支線」。但我相信高敏感領域(金融、醫療、國防)或邊緣運算(Edge AI)中,客製化小模型(SLM)與地端微調仍是關鍵主軸。
- 提示(prompt)成了要版控的資產。 改一句系統提示就可能改變整個產品行為,這在 2021 年不存在。
- 評測從「算個 F1」變成了一整套工程。 輸出是非確定性的、沒有唯一正解,這件事逼出了 LLM-as-a-Judge、評測集管理、上線前 Gate 這一整條新的工作流。
- 成本工程成了日常。 以前是「訓練一次花多少」,現在是「每一次請求都在花錢」,token 成本、快取命中率、模型路由變成要天天看的儀表板。
- 多了一整類安全問題。 提示注入、代理過度權限——這些在傳統 ML 系統裡沒有對應物。
一句話總結:地基沒變,但上面蓋的房子換了樣式,而且多了一層以前沒有的樓。
三、動手:三十秒自我定位
在往下讀之前,先花三十秒回答這五題,決定你在這 30 天要怎麼走:
1. 你能不能寫一個 Dockerfile,把一個 Python 服務打包起來跑? □ 能 □ 不能
2. 你有沒有做過「模型/服務上線後掛掉」的排查? □ 有 □ 沒有
3. 你能不能說出 RAG 中「檢索失敗」與「生成失敗」的差別? □ 能 □ 不能
4. 你有沒有為 LLM 應用建過評測集(不是靠感覺看輸出)? □ 有 □ 沒有
5. 你比較想解決哪種問題? □ A:它為什麼掛了 / 為什麼這麼貴
□ B:它為什麼答錯 / 怎麼讓它更有用
- 1、2 答「能/有」,第 5 題選 A → 你的底子在維運端,走主軸一,重點補 Day 09–11(ML 特有的資料與管線紀律)。
- 3、4 答「不能/沒有」,第 5 題選 B → 你的底子在應用端,走主軸二,重點補 Day 18–20(RAG 全鏈路)與 Day 24(評測)。
- 全部答不出來 → 恭喜,你是這個系列設定的標準讀者,從 Day 05 老實走一遍。
- 全部都能 → Day 24–27 是給你的,那是資深職的分水嶺。
