Andrew Ng 最新 AI Engineering Skills Map：Agentic Coding 時代，工程師更該學什麼？

Coding Agent 是能讀取程式庫、修改檔案、執行測試，再持續修正結果的 AI 工具，現在甚至能自己開出 Pull Request。Pull Request 是把一組程式變更送交團隊審查與合併的流程。既然 AI 能完成這麼多工作，工程師還需要花時間學資料庫、系統架構與部署嗎？

Andrew Ng 在 2026 年 8 月 28 日公布的 AI Engineering Skills Map：Software Engineering Fundamentals 給出很直接的答案：需要，而且重要性正在提高。

我的結論是，AI 降低的是手寫語法與樣板程式的價值，沒有降低工程判斷的價值。 當程式產量變快，真正的瓶頸會移到需求是否清楚、架構能否承受變動、資料是否正確、安全漏洞能否被發現，以及系統出錯後能不能恢復。

這篇文章會拆解 Andrew Ng 提出的 5 項軟體工程基本功，檢查外部研究是否支持他的判斷，最後整理一套不需要先背完整電腦科學課綱，也能開始實作的學習路線。

AI Engineering Skills Map 是什麼？

Andrew Ng 最初公布的完整 Skills Map 把 AI Engineering 分成 4 個主要領域：

1. 建置與部署 AI 應用。
2. 軟體工程基本功。
3. 使用 Coding Agent。
4. 決定產品要做什麼，也就是 Shaping the Build。

這份地圖談的是「AI Engineering 技能」，適用範圍超過 AI Engineer 這個職稱。就像多數開發者都要懂一些雲端運算（Cloud），卻不一定掛著 Cloud Engineer 的職稱，未來的前端、後端、資料、負責開發與維運流程的 DevOps，以及產品工程師，也都會在不同程度上使用 AI 工程能力。

Andrew Ng 表示，團隊分析超過 10,000 份職缺，並訪談數十位 AI 專家、招募主管與招募顧問（Recruiter），再綜合問卷及網路資料，才整理出這 4 類能力。這讓 Skills Map 比單純的個人心得更有產業參考價值。

不過，原文沒有公開職缺的地區、產業與年資分布，也沒有提供完整問卷、抽樣方式或分析資料。因此，它適合當成學習與招募的框架，不能直接視為已經過同儕審查、能證明因果關係的學術研究。真正值得採用的方式，是再用開發現場與其他研究檢驗它的主張。

Agentic Coding 與 Vibe Coding 有什麼不同？

Agentic Coding 讓 AI 從回答一段程式碼，進一步規劃步驟、讀取檔案、呼叫工具、執行測試，再根據結果繼續修正。人類負責給目標、限制與驗收條件，Coding Agent 則處理一部分實作循環。

Vibe Coding 通常更接近用自然語言描述想法，讓 AI 快速把產品做出來，使用者未必逐行理解程式。這種方法很適合驗證概念，卻容易在登入權限、資料一致性、錯誤處理與正式環境維運上留下隱患。

兩者可以一起使用。熟悉工程基本功的人也可以 Vibe Code，但他知道哪一段只是原型、哪一個決定會影響資料安全，也知道什麼時候必須停下來檢查。真正的差異在於：使用者能不能判斷 AI 做了哪些取捨，以及這些取捨是否適合目前的產品。

例如，你請 Coding Agent 做一套預約系統，它可能很快完成頁面、後端與資料庫。畫面能送出預約，不代表系統已經處理兩個人同時搶最後一個名額、取消後名額如何釋放、時區如何計算，以及客服要怎麼追查失敗紀錄。這些問題不會因為程式是 AI 寫的就消失。

Andrew Ng 認為最重要的 5 項軟體工程基本功

Andrew Ng 把軟體工程基本功再拆成 5 類。表面上看，它們都是傳統工程主題。放進 Agentic Coding 工作流後，每一項的用途都從「親手完成所有程式」轉為「替 AI 設定正確邊界並驗收結果」。

1. Full-stack：不用每層都手寫，但要看懂整條使用者路徑

Full-stack 指的是從使用者看到的前端介面，到後端邏輯與資料儲存的完整應用。過去前端、後端與行動 App 工程師可能各自專精一塊。Coding Agent 能補上不熟悉的部分，讓個人更容易完成跨層功能。

分工沒有消失，每個人卻更需要理解改動如何穿過整套系統。以登入功能為例，畫面上的按鈕只是入口，後面還有身分驗證、Session、權限、資料讀取、逾時與登出。Session 是系統用來記住「目前是誰正在使用」的狀態。若只驗收畫面能不能登入，很容易漏掉別人是否能讀到不屬於自己的資料。

因此，Agentic Coding 時代的 Full-stack 能力，重點是畫出一個功能從畫面到資料庫的完整路徑，並知道每一層應該用什麼方式驗證，不必背完所有開發框架（Framework）。

2. 資料管理：AI 可以改資料結構，卻無法替你承擔錯誤資料的後果

資料通常比介面更難改。按鈕顏色可以明天重做，但使用者姓名、訂單、權限與付款紀錄一旦存錯，後續每個功能都會建立在錯誤基礎上。

資料模型是系統整理資訊的結構，例如一筆預約應該連到哪位使用者、哪個時段與哪個付款狀態。開發者還要理解交易與併發。交易用來確保一組更新要嘛一起成功、要嘛一起取消。併發則是多個請求同時發生時，系統如何避免彼此衝突。

Coding Agent 可以幫忙寫 Migration，也就是把舊資料結構轉成新結構的程式。但「哪些資料可以刪除、要保留多久、誰有權限讀取、衝突時誰優先」仍然需要產品與工程情境。AI 不知道公司與使用者沒告訴它的規則，也不會自動知道某一筆歷史資料對法遵或客服有多重要。

3. 系統架構：最佳架構要適合目前階段

系統架構決定前端、後端、資料、第三方服務與執行環境如何組合。這裡沒有永遠正確的單一答案，只有成本、速度、可靠性與擴充性的取捨。

例如，Monolith 是把主要功能放在同一套應用中，適合快速建立 MVP，也比較容易除錯。Microservices 則把系統拆成多個可獨立部署的服務，能讓大型團隊分工與擴充，但同時增加網路、部署、監控與資料一致性的成本。

Coding Agent 很容易依照常見範例產生一套看似完整的架構，卻不知道產品只有 50 位內部使用者，還是預計服務數百萬人。若開發者沒有先提供使用量、延遲、預算與團隊能力，AI 可能為小型 MVP 做出昂貴的過度設計，也可能替正式服務留下無法擴充的單點故障。

真正的工程基本功，是能說明「為什麼現在選這個架構」，也知道哪個數據出現後應該改變選擇。

4. 安全與可靠性：通過正常流程，不代表系統能承受異常

測試不能只證明「一般情況能運作」，還要檢查輸入錯誤、第三方 API 逾時、使用者重複操作與權限不足時會發生什麼。API 是不同軟體交換資料與指令的介面。只要其中一個外部服務失敗，整個流程就可能卡住。

可靠的系統會設計 Graceful Degradation，也就是部分功能故障時仍保留核心服務，並限制事故的 Blast Radius。Blast Radius 是一次故障最多會波及多少使用者、資料與服務。這些設計需要先辨認失敗模式，不能等上線後再請 AI 補救。

安全也要提前進入開發流程。GitHub 在 2026 年把 CodeQL 程式漏洞掃描、惡意依賴檢查與 Secret Scanning 憑證外洩檢查，套用到第三方 Coding Agent 產生的程式，並表示這類自動檢查已攔下數百個潛在洩密與漏洞。這個產品設計本身傳達了一個重要訊號：即使平台提供 Agent，也不會把「AI 已完成」當成「安全已確認」。

5. 上線與維運：真正的產品從部署後才開始接受考驗

在本機跑得動，只代表程式完成第一關。正式服務還需要 CI/CD、監控、告警、事故處理與容量規劃。CI/CD 是把測試、建置與部署自動串起來的流程，讓每次修改都能用一致方式檢查與發布。

Observability 則是透過 Log、Metrics 與 Traces 理解系統正在發生什麼。簡單來說，Log 記錄事件，Metrics 顯示錯誤率與延遲等數字，Traces 追蹤一個請求經過哪些服務。沒有這些資訊，AI 即使能提出修正，也只能根據不完整症狀猜測原因。

Andrew Ng 也把版本控制、Code Review、依賴更新與技術債放進這一類。Code Review 是由人或工具審查程式變更，再決定是否合併。這些工作不一定會讓 Demo 更漂亮，卻決定產品能不能持續改版。Coding Agent 增加程式變更的速度後，團隊更需要自動測試、清楚的合併規則與可回復部署，否則只是更快累積無法維護的程式。

外部研究支持這個判斷嗎？

現有資料大致支持 Andrew Ng 的方向，但不能簡化成「AI 一定讓工程師更快」或「AI 一定產生爛 Code」。比較接近現況的說法是：AI 已經能提高許多工作的產量，最終品質卻高度依賴團隊原本的工程能力與驗證流程。

DORA：AI 是放大器，無法替團隊補課

Google Cloud 的 2025 DORA Report 蒐集近 5,000 位科技工作者的問卷，另包含超過 100 小時的訪談等質化資料。結果顯示，90% 受訪者已在工作中使用 AI，超過 80% 認為生產力提高。不過，AI 採用程度仍與交付穩定性下降有關。

DORA 的核心解讀是，AI 會放大團隊原本的狀態。測試、自動化、版本控制與快速回饋做得好的團隊，可以把更高產量轉成更快交付。流程鬆散的團隊，則可能讓更多變更一起湧入下游，增加事故與返工。

這正好補上 Skills Map 的組織層證據。除了個別開發者要會寫 Prompt，團隊也要有足夠的工程護欄，接住 AI 增加的變更速度。

Stack Overflow：最常見的問題是「幾乎正確」

2025 Stack Overflow Developer Survey 顯示，46% 受訪開發者不信任 AI 工具的正確性，信任者為 33%。有 66% 的開發者把「答案幾乎正確，但沒有完全正確」列為主要困擾，45% 認為除錯 AI 產生的程式更花時間。

「幾乎正確」比明顯錯誤更難處理，因為畫面可能正常、測試可能通過，問題只在特定權限、資料量或時間順序下出現。沒有基本功的人甚至不知道該追問哪個 Case。工程能力因此從寫出第一版程式，移到辨認邊界條件與建立驗證方法。

METR：能力進步很快，判斷力仍然落後

METR 在 2025 年的隨機對照研究中，讓 16 位熟悉自己專案的開源開發者完成 246 項任務，早期 AI 工具反而讓完成時間增加 19%。這個結果只代表特定參與者、專案與當時工具，不能推論所有 AI Coding 情境。

METR 在 2026 年 2 月的更新 已觀察到較新的 Agent 可能帶來約 4%～20% 的速度提升，但研究受到參與者不願停用 AI、多 Agent 工時難以計算等選擇偏誤影響，無法可靠估計真正幅度。這表示「AI 是否更快」會隨工具、任務與工作方式快速改變，不適合用單一舊數字下永久結論。

品質落差則更穩定。METR 對 SWE-bench Verified 程式能力測試集的維護者審查 發現，大約一半通過自動測試的 AI Pull Request，仍不會被專案維護者合併。研究只使用這套測試集的部分題目與特定 Agent 執行框架，不能代表所有程式任務，但它清楚指出：測試通過只是品質證據之一，不等於架構、範圍、可維護性與產品意圖都正確。

METR 於 2026 年 5 月發布的 Frontier Risk Report 也觀察到，Coding Agent 已能在部分可快速驗證的任務上連續工作數小時，甚至處理原本需要人類數天的工作。面對需要策略判斷的任務時，Agent 仍會做出明顯錯誤、留下限制，或選擇不值得投入的方向。

綜合來看，AI 的執行能力正在快速上升，判斷與責任卻沒有同步自動化。這正是工程基本功價值提高的原因。

工程基本功沒有消失，但學習內容需要換順序

如果仍用「先背完整語法，再做一年小練習」的方式學程式，確實會讓人覺得基本功過時。Coding Agent 已經能即時解釋語法、產生樣板、補測試與查詢文件，記憶這些內容的邊際價值正在下降。

更實際的學習順序是先做一個小而完整的產品，再用每次失敗補上需要的知識：

1. 先定義行為。 寫清楚使用者、主要流程、不做什麼，以及 5 個可以驗收的條件。
2. 畫出系統路徑。 標示前端、後端、資料庫、外部 API 與權限邊界。
3. 先處理最難回復的資料。 決定資料結構、刪除規則、重複提交與同時更新時的處理方式。
4. 把失敗寫成測試。 除了正常流程，也測試逾時、權限不足、空資料、重複操作與服務中斷。
5. 在隔離環境部署。 先使用測試資料與最低權限，確認 Log、告警、回復與備份流程。
6. 用真實指標驗收。 比較完成時間、人工修改次數、錯誤率與事故，不用產生多少行 Code 當成生產力。

可以用一套簡單預約系統練習。第一版只做註冊、查看時段與預約，讓 Coding Agent 協助實作。接著刻意加入兩人搶同一時段、取消、API 逾時與權限錯誤。每次遇到問題，都要求 Agent 解釋它做的架構取捨，再由自己用測試與 Log 驗證。

學習成果應改用三個問題檢查：「我能不能說明這段程式為什麼安全、失敗時會發生什麼，以及證據在哪裡？」能回答這些問題，比默寫程式更接近正式工作的需求。

非工程師還能不能繼續 Vibe Coding？

可以，但應依風險決定 AI 能走多遠。Vibe Coding 最適合低風險、容易回復、沒有真實敏感資料的產品探索。當系統開始處理使用者帳號、付款、個資、正式資料或刪除權限，工程審查就成為必要關卡。

判斷標準不是專案看起來大不大，而是錯誤發生後能不能回復，以及會傷害多少人。若無法回答這兩題，就不該只因 Demo 正常運作而直接上線。

團隊導入 Coding Agent，最小可行流程怎麼設計？

對想快速導入的團隊，不需要先建立一套龐大的 AI 治理制度。可以從 5 個最小護欄開始：

1. 每個任務先寫清楚範圍、禁止事項與驗收條件。
2. Agent 只能使用完成任務所需的最低權限，不直接取得正式資料庫寫入權。
3. 每次變更都以 Pull Request 交付，保留差異、測試與理由。
4. 自動執行測試、依賴檢查、Secret Scanning 與安全掃描。
5. 依風險安排人工核准，正式環境保留監控、回復與事故紀錄。

這套流程的目的，是讓 AI 的速度變成可檢查的產量，而非增加文件。若團隊連「什麼算完成」都沒有共同答案，Agent 只會更快產生更多需要人工猜測的變更。

常見問題

AI Coding 會讓 Junior Engineer 消失嗎？

入門工作的內容會改變，但不能只從「AI 會寫 Code」推論所有 Junior 職位消失。樣板程式、簡單轉換與查文件的價值會下降，能釐清需求、閱讀現有系統、設計測試與解釋錯誤的新人則更有價值。真正的風險是只會接受 AI 答案，卻沒有機會建立判斷力。

非工程師需要先學哪一項基本功？

先學完整使用者流程與資料。能畫出資料從畫面進入後端、存進哪裡、誰能讀取，以及失敗後如何回復，比先背一門語言的所有語法更實用。接著再補測試、權限與部署觀念。

Coding Agent 通過所有測試，就能直接部署嗎？

不能。測試只能覆蓋已經寫進去的條件，沒有被想到的權限、資料量、成本與操作流程仍可能出錯。METR 的維護者研究也顯示，自動測試通過不等於真實專案會接受這項變更。

Vibe Coding 是錯誤的開發方式嗎？

Vibe Coding 沒有錯。它很適合原型、個人工具與探索需求，問題出在把原型的驗收標準直接搬到正式產品。風險越高，越需要清楚規格、隔離環境、自動檢查與人工責任人。

工程師還需要背程式語法嗎？

不需要把記憶語法當成主要目標，但仍要看得懂程式結構、資料流與錯誤訊息。Coding Agent 可以代寫細節，工程師必須能判斷結果是否符合需求，以及改動會影響哪些地方。

結論：AI 寫得越快，人越需要知道什麼不能交給它決定

Andrew Ng 的 Skills Map 最重要的提醒，是基本功的重心已經改變，不必把舊課本從頭再念一遍。

語法記憶與樣板程式的價值正在下降，系統思維、資料判斷、安全邊界、測試設計與正式環境維運的重要性則在提高。Coding Agent 可以替人完成更多實作，但它不知道產品願意承受多少成本、哪筆資料不能出錯，也不會自動替事故負責。

因此，最值得培養的是把模糊需求變成可驗收規格，替 Agent 提供足夠情境，再用測試、監控與工程判斷確認成果，速度競賽反而放在其次。對非工程師來說，Vibe Coding 仍然值得使用，但正式資料與高風險操作要留在有護欄的流程中。對工程師來說，角色正從主要程式產生者，移向系統設計者、驗證者與責任承擔者。

Skills Map 的詳細研究方法仍未完整公開，未來若原始資料顯示不同產業、地區或年資的需求差異很大，學習優先順序就應該調整。但在現有的 DORA、Stack Overflow 與 METR 資料下，「少背語法，多練系統判斷與驗證」已經是比單純追逐下一款 Coding Agent 更實際的方向。

資料來源

• Andrew Ng：AI Engineering Skills Map — Software Engineering Fundamentals
• Andrew Ng：The AI Engineering Skills Map
• Andrew Ng Writing：兩篇 Skills Map 文章的官方索引
• Google Cloud：2025 DORA State of AI-Assisted Software Development
• Stack Overflow：2025 Developer Survey — AI
• METR：We Are Changing Our Developer Productivity Experiment Design
• METR：Many SWE-bench-Passing PRs Would Not Be Merged into Main
• METR：Frontier Risk Report，2026 年 2 月至 3 月
• GitHub：Security Validation for Third-party Coding Agents