Day 30：結賽 — 2026 之後的 AI 人才養成之路

2026年10月11日 · 閱讀時間約 7 分鐘

Willis Chen

Tech Instructor

30 天前，本系列從一份 AI 新興職缺資料出發，說市場已經分成兩個職務。29 天後，我們把這兩個職務的每一項工作任務都拆解、實作、並討論了取捨。

今天做三件事：回顧這條路徑的核心主張、檢討這個系列的限制、給三種讀者各一張路線圖。

今天要解決的問題

「這些內容還能用多久？」

這是一個必須誠實回應的問題。2021 年我寫《從 AI 落地談 MLOps》時，如果有人問我，我大概會低估答案——當年談的地基（可重現、CI/CD、監控），五年後依然全部成立；而當年沒能預見的是，「訓練模型」這件事會從主線退場。

所以今天不預測技術，我們談哪些東西的保鮮期比較長。

📊 職缺訊號

最後一次回顧這組數字：MLOps 側的平臺（58.5%）、部署（49.2%）、管線（42.6%）；生成式 AI 側的 RAG（48.1%）、Agent（47.6%）、LLMOps（38.7%）、整合（38.7%）、評測安全（34.3%）。

這 30 天的篇幅配比，就是照這組數字分配的。 這也是這個系列與其他 AI 教學最大的不同——它的課綱不是我決定的，是市場決定的。

一、現象：這 30 天的六個核心主張

如果把整個系列壓縮成六句話：

#	主張	出處
1	兩個職務不是上下游，是同一條價值鏈的兩端，中間的 LLMOps 是交會地帶，也最缺人	Day 01、03、26
2	地基沒變，上層被改寫：可重現、CI/CD、監控依然成立；不再自己訓練、提示成為資產、評測變成工程	Day 08
3	軟體大聲地壞，模型無聲地壞——縮短那 14 天的空窗期，就是這份工作的價值	Day 14
4	能用簡單的就別用複雜的：能批次別即時、能工作流別代理、能提示別微調	Day 13、21、23
5	沒有評測就沒有工程——它是「做得出 demo」與「做得出產品」的分界線	Day 20、24
6	與其防止模型被騙，不如讓它就算被騙也做不到壞事	Day 25

這六句話有一個共同點：它們都不是關於某個工具的。 工具會換——今天的 vLLM、Chroma、MLflow，三年後可能都不是主流。但「先量測再優化」「權限在執行層」「自動化會放大問題」這些判斷，會活得比工具久。

這是我對「保鮮期」這個問題的回答：越接近判斷與取捨的內容，保鮮期越長；越接近特定工具操作的內容，保鮮期越短。

二、原理：三張路線圖

三條主流轉職路線的優勢與缺口

圖 30-1：三條主流轉職路線的既有優勢與待補缺口（依職缺任務訊號與常見團隊分工整理的示意歸納）。

同時別忘了那張決定一切的分工圖——不論你走哪條路，最終都要能在這張圖上指出自己的位置：

雙主軸的價值鏈分工與 LLMOps 交會地帶

圖 30-2：雙主軸的價值鏈分工與交會地帶（依職缺任務訊號整理的示意架構）。30 天前這是本系列的第一張圖，30 天後你應該能對每一格說出「這裡在做什麼、會怎麼壞、怎麼量測」。

給轉職者：先取得入場券，再談深度

未來三個月：完成 Day 28 的作品集版專題（1–2 週），補齊 Day 29 檢核表中你那條主軸的項目，投遞主軸明確的職缺。

別做的事：不要為了「看起來很全面」而每個工具都碰一點。一個做完整、能講出取捨的專題，勝過五個半成品。

給在職者：往交會地帶走

如果你已經在做其中一邊，最高投報率的方向是往中間走：

做 MLOps 的 → 補 RAG 與 Agent 的使用者視角（Day 18–22）。你會發現自己突然能參與產品討論。
做生成式 AI 應用的 → 補部署、監控與成本（Day 12–15、26）。你會發現自己的東西終於上得了線。

理由：Day 02 的資料顯示「LLMOps」職缺只有 19 筆——但那是因為這個詞還沒普及。實際做這件事的人極度稀缺，而稀缺就是議價能力。

給教學者與主管：用任務訊號設計課綱

如果你要規劃課程或團隊訓練，這個系列提供的不只是內容，還有方法：

從職缺任務訊號決定篇幅配比（Day 02）——而不是從老師會什麼決定。
用「現象 → 原理 → 動手 → 取捨」的四段結構——最後一段是多數教材缺的。
用 Day 29 的檢核表當驗收標準——「能講清楚且做得出來」，而不是「上過課」。

團隊訓練的順序建議：監控 → 實驗追蹤 → 資料驗證 → 管線化 → 自動化（Day 08），因為前面的能立刻降低風險，後面的才是效率投資。

三、動手：接下來三十天

30 天的閱讀不會讓你變強，接下來的 30 天才會。給一份具體的行動清單：

【第 1 週】定位與起步
□ 做完 Day 29 的檢核表，誠實打勾
□ 決定你的主軸（或確認要走交會地帶）
□ 建好開發環境（Day 05），把 uv、Docker、Git 流程跑順

【第 2-3 週】做出第一個作品
□ 選 10 份公開文件，做出有引用的 RAG（Day 18-20）
□ 建 20 題評測集，含 3 題拒答題 —— 這一步不能跳
□ 記錄每次優化的前後數字（這是你面試要講的東西）

【第 4 週】工程化與呈現
□ 容器化 ＋ docker compose 一鍵啟動（Day 05、12）
□ 加上最小可行監控：成本、延遲、拒答率（Day 14、26）
□ 加上權限過濾與 audit log 的示範（Day 27）
□ 把 README 寫成「決策紀錄」而非功能清單（Day 29）

【持續】
□ 每次遇到失敗案例，就加進評測集
□ 每月回頭看一次職缺 JD，確認自己的方向與市場一致

注意第 2-3 週那句「這一步不能跳」。 如果你只能做一件事，就做評測集——因為它是唯一能讓你證明自己有進步的東西。

四、取捨：這個系列的限制

最後，誠實檢討。一個從資料出發的系列，如果不敢說自己的限制，那就違背了 Day 02 的精神：

限制一：資料是單日橫斷面。 2026-07-25 的 4,343 筆去重職缺，來自單一平臺、12 組關鍵字。它能回答「哪些任務被反覆提及」，不能回答「市場總量多大、成長多快」。所有引用請一併標示擷取日期與這項限制。

限制二：職缺文字 ≠ 實際工作。 招募文字反映的是期待，不是實際工時分配。一份寫著「熟悉 K8s」的 JD，實際上可能只需要你會 kubectl logs。

限制三：兩個職務名稱可能會變。 它們目前是 iCAP 職能基準的預擬方案，正式版可能調整名稱或分類。但這個系列以「工作任務」為主體敘事——任務不會因為職稱改變而消失。

限制四：深度受篇幅所限。 30 天、每天 2,000–3,000 字，只能做到「從 0 到 1」。

限制五：我也有盲區。 我在 MLOps 這一邊的實務年份較長，生成式 AI 應用這邊的內容更多來自近兩年的專案與公開資料。如果你在某個主題上有更深的實戰經驗，歡迎在留言區或 GitHub issue 指正——這也是我把原始稿放在 GitHub 的原因。

今日小結

六個核心主張都不是關於工具的：價值鏈兩端、地基不變上層改寫、模型無聲地壞、能簡單就別複雜、沒有評測就沒有工程、讓它被騙也做不到壞事。
越接近判斷與取捨的內容，保鮮期越長；越接近工具操作的，越短。
三張路線圖：轉職者先做一個完整專題、在職者往交會地帶走、教學者用任務訊號設計課綱。
接下來 30 天的行動清單中，評測集是唯一不能跳的一步——它是你能證明自己進步的唯一憑據。
五項限制要一併記得：單日橫斷面、職缺文字非實際工作、職務名稱可能調整、深度受篇幅所限、作者有盲區。

完賽的話

30 天前我說，這個系列要從需求出發，而不是從技術出發。

現在回頭看，我想補一句：從需求出發的真正意義，不是為了追著市場跑，而是為了看清楚「市場為什麼要這個」。

當你理解「為什麼 58.5% 的職缺在講平臺」（因為模型周圍的東西才是工作量的主體）、「為什麼 48.1% 在講 RAG」（因為企業要的是自己的知識，不是通用的聰明）、「為什麼評測的成長率最高」（因為大家都做得出 demo 了）——你就不只是在追關鍵字，而是在讀懂這個行業正在往哪裡走。

這兩個職務目前還是職能基準的預擬方案，標準還沒定下來。這既是不確定，也是機會：

標準還沒定下來的時候，做出成果的人就在定義標準。

謝謝陪我走完這 30 天。五年前我寫《從 AI 落地談 MLOps》時沒想過會有這個續集；五年後如果還有人在問「模型訓練好了，然後呢」，我大概還會再寫一次。

今天要解決的問題​

一、現象：這 30 天的六個核心主張​

二、原理：三張路線圖​

給轉職者：先取得入場券，再談深度​

給在職者：往交會地帶走​

給教學者與主管：用任務訊號設計課綱​

三、動手：接下來三十天​

四、取捨：這個系列的限制​

今日小結​

完賽的話​

延伸閱讀​