吳恩達挖 1 萬筆職缺：AI 工程技能沒有 prompt engineering

八月中，吳恩達（Andrew Ng）丟出一張圖，說這是現在最值得學的四個 AI 工程技能。

換成別人講，你大概會滑過去。但他這次不是憑感覺。他和團隊翻了一萬多筆職缺，又找了幾十個 AI 專家、用人主管和獵頭做結構化訪談，再加上問卷，才收斂成這四項。

有意思的是裡面缺了什麼。

沒有 prompt engineering。那個大家搶著上課、搶著買教學的東西，在真實的職缺資料裡排不上號。

這篇拆三件事：四項各自要你會什麼、他八月二十一號又補了什麼進去、以及 LinkedIn 上那則最尖銳的反駁到底有沒有道理。

先講一個很多人看漏的用詞

他在文章裡特地花一整段解釋，自己講的是「AI 工程技能」，不是「AI 工程師」這個職稱。

這個區別聽起來像在咬文嚼字，其實決定了你該怎麼讀這張圖。

他的類比是雲端。今天沒有哪個開發者可以說自己完全不碰雲，但職稱寫著 Cloud Engineer 的只有少數人。AI 也一樣。全端、資料工程、DevOps、ML，都會需要這組能力。

所以這不是「想轉職 AI 工程師要學什麼」的清單。

是「你現在這份工作再過兩年長什麼樣」的預告。

四項技能，一張圖

第一項底下那六個子節點，是八月二十一號才補上的。他說會把四項逐一展開，第一篇先寫「建構與部署 AI 應用」，另外三項目前還停在一句話的層級。

1. 建構與部署 AI 應用：重點不在元件，在閉環

AI 應用跟一般軟體差在哪？

差在你不知道它會回什麼。丟一段 prompt 給 LLM，答案每次都可能不一樣。訓練一個深度學習模型，它面對沒看過的資料會怎麼判斷，你也只能猜。

所以做 AI 系統的節奏跟做傳統軟體不同。你很難事先把流程規劃好，只能反覆地做一版、看一眼、再決定下一步試什麼，而每一步都被上一步的中間結果牽著走。

那六個子技能是這樣拆的：

LLM 基礎。 懂它怎麼切 token、怎麼生成，你才知道什麼時候能信它、什麼時候它會爆。也才判斷得出來 context window 該塞什麼、cache 有沒有命中、知識截止日在哪、reasoning effort 該開多高。

用資料為模型接地。 RAG 加向量檢索只是早期做法。現在真正要判斷的是：什麼直接寫進 prompt、什麼讓模型自己用工具去撈？該用向量索引、知識圖譜，還是在結構化資料上蓋一層語意層？

打造 agentic 系統。 從固定順序的 workflow，到讓模型自己決定下一步的 agent harness，中間有一整片光譜。你得選架構、決定哪些串接哪些平行、什麼用程式什麼用 LLM，還要設 fallback。工具權限、記憶架構、長對話怎麼管，全都是設計決策。他還特別點名要處理 guardrails、對抗性輸入，以及資料外流這類風險。

評估驅動開發。 下一段細講。

在正式環境營運。 可觀測性、偵測 drift、應付 prompt injection。而且回歸測試和 CI/CD 要用上比傳統軟體更多的統計評估。

機器學習基礎。 他說他認識的每一個真的擅長用 LLM 做東西的人，機器學習和深度學習都有一定深度。bias/variance、錯誤分析、資料工程這些老概念，正好是面對「輸出不確定的系統」時的核心心智框架。

六項裡他花最多篇幅的是評估驅動開發。原話大意是：他經驗中最能區分「AI 系統做得好」跟「做不好」的特質，就是有沒有辦法推動一個紀律嚴謹的 evals 與錯誤分析閉環。

而且他補了一句，說這技能很難練，因為做法會隨專案、甚至隨專案階段大幅改變。

這裡有個判準值得記住：如果你不知道你的 RAG 或 agent 是在哪裡失敗的，你就不是在修它，你只是在重下 prompt 直到眼前這個例子看起來對。

2. 軟體工程基本功：AI 越會寫程式，這項越值錢

這是四項裡最容易被跳過的一項，也是他花最多力氣辯護的一項。

聽起來很違和吧？AI 都會寫程式了，還學什麼基本功。

他的邏輯是這樣：工程本來就是在成本、擴展性、可靠度、速度之間做取捨，加上安全和隱私之後更複雜。而基本功真正的用途，是讓你先意識到「有哪些取捨存在」。

跳過這段的人會踩到兩個坑。一是不知道該餵 agent 什麼上下文，二是看不出來 agent 正在做糟糕的架構決定。

這不是抽象的擔憂。

Keyhole Software 在今年六月彙整了十四份產業報告和開發者調查，裡面有兩組數字很難忽視。一組是今年 Q1 對兩百多個純靠 AI 生出來的應用做的評估，91.5% 至少有一個漏洞可以追溯到 AI 幻覺。另一組來自資安團隊 Tenzai，他們用 Claude Code、Codex、Cursor、Replit 各建了同樣的十五個應用，總共挖出六十九個不同漏洞，其中六個是 critical。

講白了：AI 幫你做的取捨，你看不懂，就等於沒做取捨。

所以基本功的價值換了個位置。它從「親手把每行程式寫出來」，變成「用精準的工程語言去指揮 agent」。

這也是為什麼在 AI Coding 時代的工程師工具鏈裡，型別系統和規則檔會比選哪個模型更關鍵。那是你把工程語言翻譯成 agent 看得懂的約束的地方。

3. 使用 coding agent：三年前沒有任何職缺會寫這條

這項最新，也最沒有標準答案。

他列的能力清單長這樣：對 agent 怎麼運作有正確的心智模型，知道它的限制在哪、怎麼繞；判斷該介入多少、該放手多少，不要浪費時間和 token；管理 agent 的 context，在規劃和執行之間做取捨；提供 verifier 或 evals，讓 agent 能自己把迴圈收掉；知道什麼時候要寫清楚的 spec、什麼時候不用；協調多個 agent 一起工作；還有避開高風險錯誤，例如不小心讓 agent 弄壞正式環境的資料庫。

清單很長，但最後他補的那句我覺得最重要：因為 agentic coding 變化太快，這項技能不只是「知道當下的最佳做法」，還包括有沒有一套持續試新工具、持續更新工作流的習慣。

這是四項裡唯一一個今天學會、半年後可能要重學的。

多 agent 協調尤其明顯。Claude Code 那套讓一百個 agent 不打架的做法，一年前根本還不存在。

他自己在五月也劃過一條線：coding agent 對 frontend 加速最多，對 research 幾乎沒用。知道加速邊界在哪，本身就是「該介入多少」這個判斷的一部分。

4. 塑造開發方向：從寫 code 移到決定 spec 寫什麼

只要 spec 寫得夠清楚，agent 交付的能力正在快速變好。

所以他的結論是：工程師的工作重心，正在往「決定 spec 裡該放什麼」移動。

白話一點就是，不要再期待有人給你一份 pixel-perfect 的設計稿，你只負責照著實作。

傳統軟體團隊的分工是三段式：PM 跟客戶談、寫需求，設計師做 mockup，工程師照規格做。這條線之所以成立，是因為實作本身很貴。當 agent 可以把清楚的規格直接變成能跑的軟體，實作就不再是唯一的瓶頸，這道分工線也就開始鬆動。

團隊還是需要有人找出真正值得解決的問題、理解客戶要什麼、權衡各種取捨。而這些工作正在往工程師身上移。

講直接一點：工程師工作裡「結果明確、單純執行」的那部分在減少，「充滿不確定、需要人類判斷」的那部分在增加。

他也提到另一面。AI 給了你比以前更大的 ownership 空間，你可以自己找出有意思的問題、自己執行。但要吃到這個紅利，你得知道怎麼推動一個專案，包括判斷什麼時候該快做一個 MVP 丟給用戶測，什麼時候該慢下來好好蓋。

如果你在想這對履歷代表什麼，用 Claude Code 全自動求職那套流程其實已經示範了一半。能被寫進 portfolio 的不是「我用 AI 生了一個 app」，是「我看到什麼問題、設計了什麼架構、AI 錯在哪、我怎麼測出來的」。

這張圖被罵了什麼

貼文在 X 上有五百七十萬次瀏覽，LinkedIn 版本有近四百則留言。

大部分是叫好。但有兩則反方值得單獨拿出來看。

第一則來自工程師 Jonathan Sandhu，他講得很不客氣：這根本不是一張 AI 工程的地圖，是四個寬到可以描述幾乎任何現代軟體工作的標籤。他認為真正難的東西全部消失了，包括 evals、provenance、可觀測性、失效隔離、資安、部署限制、模型與 runtime 的經濟性、人類授權、rollback，以及當 agent 改動了真實狀態之後的問責。

他最後丟了一個問題：一張有用的技能圖，應該告訴工程師「哪種能力可以避免哪一類失敗」。

我覺得他對了一半。

錯的那一半是，他抱怨「evals 消失了」這點在八月二十一號的後續文章裡就被打臉了。那六個子技能裡有一整項就叫 evaluation-driven development，而且是篇幅最長的一項。

對的那一半比較麻煩。這張圖說的是「你需要具備什麼」，不是「什麼能力擋掉什麼失敗」。前者是課程大綱的寫法，後者才是工程師實際在用的思考方式。而 DeepLearning.AI 本身就是賣課的，這個偏向不算意外。

第二則來自 Dr. Sam Zolfagharian，他補了三項自己認為同樣關鍵的技能：AI 的 UI/UX（傳統軟體不用設計「出錯時長什麼樣」，AI 要）、資料整備（實務上佔掉的工時比想像多）、以及成本最佳化。

第三項我覺得最有道理。原文只在「在正式環境營運」的子技能裡順帶提了成本與延遲。但對獨立開發者和小團隊來說，「這個 agent 跑一次要多少錢」根本是架構決策的第一順位，不是附註。

如果你只能從一件事開始

四項一起練是不可能的，所以優先順序這樣排。

先把 evals 練起來。 這是他自己說最能拉開差距、也最難學的一項。從最小的做起：把你手上 AI 功能的二十個真實輸入抓下來，人工標一遍對錯，寫一個二十行的 script，每次改動都跑一次。這樣就已經是閉環了。

再補基本功的缺口。 不用重讀演算法課本。從你的 agent 最近做過哪個架構決定開始問：這個決定犧牲了成本、可靠度、還是安全性？答不出來的地方，就是你的缺口。

coding agent 的用法只能用時間換。 這項沒有捷徑，只能持續換工具、持續改工作流。把它當成每一季要重跑一次的例行工作。

shaping the build 得靠你自己開專案。 在別人的 spec 底下做事，永遠練不到決定 spec 的能力。

利益揭露：以下是聯盟連結。真要練 evals 閉環，桌面環境其實比顯卡重要得多，因為你會坐在那裡一筆一筆讀資料。桌面開發者 4 件套（機械鍵盤、USB-C Hub、螢幕掛燈、站立書架）是常見的 CP 值組合，適合剛開始整理工作桌的人。

常見問題

AI 工程技能是什麼？跟「AI 工程師」這個職稱一樣嗎？

不一樣。前者是一組能力，後者是一個職稱。吳恩達刻意用前者，因為全端、資料、DevOps、ML 工程師都會需要這組能力，就像今天所有開發者都得懂雲端，但職稱叫 Cloud Engineer 的只有少數人。

吳恩達說的四個 AI 工程技能是哪四個？

建構與部署 AI 應用、軟體工程基本功、使用 coding agent、塑造開發方向。來源是一萬多筆職缺分析、數十場對專家與招募主管的結構化訪談，加上問卷資料。

為什麼這張技能圖裡沒有 prompt engineering？

因為它已經被吃進更大的能力裡了。八月二十一號補的六個子技能中，對應的是「用資料為模型接地」和「評估驅動開發」。重點從「怎麼下指令」變成「怎麼餵對的上下文，以及怎麼量測輸出對不對」。

只有時間練一項，該練哪一項？

練 evals 與錯誤分析的閉環。他直接說這是他看過最能區分「會做 AI 系統」跟「不會做」的特質，而且很難學會，因為每個專案、每個階段的做法都不一樣。

這四項技能什麼時候會全部展開？

他說會逐項寫成後續文章，並釋出更完整的技能圖。到八月二十五號為止，只有第一項展開成六個子技能。

這張圖真正有意思的地方，其實不是它列了哪四項，是排序。

四項裡有三項（基本功、指揮 agent、決定做什麼）講的都是同一件事：在一個你無法完全控制的系統上做判斷。沒有一項是「更快產出更多程式碼」。

那問題就變成：如果判斷力是你剩下的全部價值，你今年花在練判斷力的時間，有沒有比花在追工具的時間多？

這篇是總覽。四項技能各自怎麼練，接下來會拆成四篇單獨寫：evals 閉環怎麼從二十筆輸入開始、怎麼看出 agent 幫你做了什麼架構取捨、該介入還是放手的判斷點、以及 spec 該寫到多細。用上面的系列導覽跳過去。