吳恩達公布 AI 工程師技能地圖：如何把充滿隨機性的模型做成可靠系統

生成式 AI 熱潮進入 Agent 與企業落地階段後，「AI 工程師到底該會什麼」正在快速改寫。

DeepLearning.AI 創辦人、史丹佛大學教授 Andrew Ng（吳恩達）近日進一步拆解其 AI Engineering Skills Map，將「建構與部署 AI 應用」列為 AI 工程師最核心的高階能力之一。

並進一步拆成六大技能：LLM 基礎、以資料 Grounding 模型、Agentic Systems、Evaluation-driven Development、生產環境營運，以及 Machine Learning 基礎。

吳恩達指出，AI 軟體與傳統軟體最大的差異，是輸出具有不確定性。

傳統軟體通常可以預期一段程式碼在特定輸入下會產生什麼結果，但開發者無法事先知道大型語言模型會生成哪一句話，也無法完全預測機器學習模型會做出什麼判斷。

因此，AI Engineering 的核心能力是：如何利用本質上不可靠、具有機率性的 AI 元件，組合出一個可靠的軟體系統。

AI 開發比傳統軟體更像「反覆實驗」

吳恩達認為，正因模型輸出不確定，AI 系統的開發流程也比傳統軟體更加迭代。

優秀的 AI 工程師會不斷建立一小段系統、觀察結果、分析錯誤，再決定下一步應該修改 Prompt、資料、模型、工具、Agent 架構，還是評估方式。

換句話說，AI 開發很難在專案開始前就完全規劃完畢。

真正重要的能力，是看到中間結果後，能不能正確判斷：下一個最值得做的實驗是什麼？

這也解釋了為什麼吳恩達把 Evaluation，也就是評估能力，放到如此核心的位置。

第一項能力：不能只會呼叫 API，還要理解 LLM 底層行為

第一項是 LLM foundations。

吳恩達認為，AI 工程師至少需要理解大型語言模型如何 tokenize 輸入、逐步生成輸出，以及模型在哪些情境可以信任、哪些地方容易失敗。

這也延伸到大量今天實際開發 AI 產品時會碰到的工程判斷，例如：context window 應該放多少資訊、多模態模型什麼時候比純文字模型更適合、cache hit 如何影響成本、模型知識截止日期、reasoning effort、sampling parameters，以及何時使用 tool calling。

真正理解這些基礎後，工程師才有能力判斷應該選哪個模型，甚至是否應該同時混合多種模型。

更進一步，工程師也需要知道什麼情況值得做 fine-tuning，以及什麼時候應該自行部署模型，而不是永遠依賴外部 API。

第二項：RAG 已經不是全部，真正能力是「讓模型拿到對的資料」

第二項是 Grounding models with data。

過去談到企業 AI，RAG 幾乎等同於「把公司資料接進 LLM」。

但吳恩達指出，vector search 只是早期的一種方式，現在 Grounding 的技術選項已經大幅增加。

工程師必須決定哪些資訊應該直接放進 Prompt，哪些應該讓模型透過工具即時查詢；不同資料也可能需要完全不同的表示方式。

例如，文件搜尋可能適合 vector index，但複雜實體關係可能更適合 knowledge graph；如果處理的是客戶資料、訂單與其他結構化資訊，則可能需要建立 semantic layer。

此外，工程師還必須把 PDF、HTML、圖片與文字文件整理成模型可以有效使用的輸入格式，並維護一套能確保資料乾淨、正確而且持續更新的 pipeline。

真正的能力因此不是「會不會做 RAG」，而是面對一種資料與一個查詢需求時，知道該用哪一種方式把正確 context 交給模型。

第三項：Agent 不只是讓模型自己跑，而是整套架構設計

第三項則是目前產業最熱門的 Building agentic systems。

吳恩達將 Agentic Systems 的範圍定義得相當廣。

最簡單的形式可以是預先定義好的 workflow，例如依序呼叫數次 LLM；更進階的架構則是使用 agent harness，讓模型反覆觀察目前狀態、自行判斷下一步，再採取行動。

其中真正困難的地方在於架構選擇。

工程師需要決定哪些步驟應該串行、哪些可以平行、什麼工作應該由傳統程式碼處理，又有哪些問題值得交給 LLM。

在 Agent loop 裡，還要決定模型能呼叫哪些工具，包括 MCP、CLI、sandbox execution environment 等；長時間任務則涉及 memory architecture 與 context management。

如果單一 Agent 不夠，還要判斷是否真的需要 multi-agent orchestration，而不是為了使用多 Agent 而增加系統複雜度。

Agent 真正難的是「上線」

Agent 的另一個問題是 Prototype 與 Production 之間存在巨大落差。

Demo 能跑一次，並不代表可以放心交給數十萬名使用者。

吳恩達因此特別提到 guardrails、對抗式輸入、資料外洩以及治理等問題。

例如，一個可以讀取公司內部資料並呼叫外部工具的 Agent，一旦遭遇 prompt injection，就可能把原本只是「聊天模型回答錯誤」的問題，升級成真正的資安事件。

因此，Agent Engineering 不只是讓模型獲得更多自主能力，還必須理解模型究竟可以做什麼、不可以做什麼，以及做錯時系統如何阻止它。

此外，Agent 技術本身也仍快速演進，包括 voice agents、computer-use agents 以及 generative UI，都可能逐漸成為 AI 工程師需要掌握的新型態。

吳恩達：最能區分優秀 AI 工程師的能力，是 Evals

六項能力之中，吳恩達特別強調 Evaluation-driven Development。

他甚至直言，依照自己的經驗，判斷一個人是否真正擅長開發 AI 系統，最重要的特徵之一，就是對方能不能建立紀律化的：Eval → Error Analysis → Development 迴圈。

原因很簡單，模型本身具有隨機性，因此開發者如果只是「感覺這個 Prompt 好像變好了」，整個開發過程很容易變成亂試。

好的 evals 則能讓團隊系統性知道產品究竟改善了多少，以及下一步應該優先解哪一類問題。

Evals 不是跑一個 benchmark 就結束

吳恩達也提醒，建立好的評估系統本身是一項深度技術能力。

開發者可能需要閱讀系統 trace、檢查大量模型輸出、進行 exploratory data analysis，再搭配產品與商業理解，才知道真正值得衡量的指標是什麼。

評估方式本身也不只有一種。有些問題適合 deterministic、也就是直接用程式碼檢查；某些主觀品質問題則可能使用 LLM-as-a-judge；而在高風險場景下，仍可能需要 human-in-the-loop。

甚至連「eval 本身準不準」也需要被評估。隨著產品演進，eval system 本身也必須跟著迭代。

這正是 AI 開發與傳統軟體測試最大的差異之一：測試不再永遠存在唯一正確答案。

第五項：AI 上 Production 後，成本與延遲都是工程問題

另一項核心能力是 Operating in production。

AI 軟體正式上線後，工程師不只要監控 uptime，也需要追蹤實際使用情境中的模型表現。

包括模型品質是否 drift、某類輸入是否持續失敗，以及是否出現 prompt injection 等資安問題。

CI/CD 與 regression testing 同樣需要調整。

傳統軟體可能檢查「輸出是否完全符合預期」，但 AI 系統往往需要統計式評估，而且測試嚴格程度也應該隨風險而變。

例如，一個推薦餐廳的 AI 偶爾答錯，與一個醫療系統偶爾答錯，所需要的測試標準顯然完全不同。

模型成本也是產品架構的一部分

AI 應用另一個不能忽略的問題，是 inference cost 與 latency。

產品使用者規模一旦上升，原本 Demo 階段看似不重要的每次模型呼叫成本，都可能直接影響產品毛利。

因此工程師必須知道如何混合使用模型，包括 model choice optimization、distillation、fine-tuning，以及簡化 agentic workflow。

這也是 AI Engineering 與純 Prompt Engineering 之間的重要差異。

前者最終仍需要對產品的可靠性、延遲與單位經濟負責。

第六項：LLM 時代，Machine Learning 基礎並沒有過時

最後一項則是 Machine Learning foundations。

在 ChatGPT 出現後，一度有人認為 AI 應用開發已經不再需要學傳統機器學習。

吳恩達的觀點恰好相反。

他表示，自己認識真正擅長建構 LLM 系統的工程師，幾乎都對 machine learning 與 deep learning 有一定程度的理解。

一方面，LLM 本身就是利用 supervised learning、reinforcement learning 等方法訓練而成；另一方面，很多實際應用仍然需要使用傳統 ML 模型，甚至自行訓練模型。

工程師因此仍需要理解不同模型在 accuracy、training speed、inference speed 等方面的 trade-off。

更重要的是，bias/variance、error analysis 與 data engineering 等經典機器學習概念，依然是理解「不確定輸出系統」的重要思考框架。