初級工程師如何在 AI 時代累積能力？職場瓶頸與培訓設計

生成式 AI 正在改變軟體工作的切入點：樣板程式、文件初稿、測試案例、除錯線索與程式碼說明，都能更快產生。對初級工程師來說，真正的問題不是「還要不要學寫程式」，而是當一部分入門任務被加速後，要如何持續累積判斷、除錯與交付責任。

這不是一個能用「AI 會取代新人」或「AI 只會讓新人更強」回答的問題。不同國家、公司、職類與景氣週期的資料會得到不同結果；更重要的是，職缺數量、工作內容、學習機會與實際生產力不是同一件事。

初級工程師面臨的瓶頸，正在從打字轉向判斷

傳統的入門工作常包括閱讀既有程式、修正小型錯誤、補測試、寫文件、調整介面和在 code review 中修改。這些任務不只是產出，也是建立心智模型的練習：新人會學到系統的邊界、資料如何流動、錯誤如何發生、修改會影響哪些地方。

AI 工具可以迅速給出看似合理的答案，但合理不等於正確、可維護或符合團隊架構。若新人只接收程式碼而沒有驗證過程，就可能少掉理解需求、重現問題、閱讀日誌、寫測試與權衡方案的回饋迴路。真正要防止的不是使用工具，而是把工具變成跳過學習與審查的捷徑。

就業資料該怎麼讀？

Stanford Digital Economy Lab 的研究以美國資料觀察到，22–25 歲、AI 高暴露職業的就業出現相對下滑；論文把軟體開發者列為案例之一，並報告該年齡層在 2025 年相對於 2022 年底高點的就業下降趨勢。不過作者也明確指出，還需要更好的公司層級 AI 採用資料來估計可信的因果效果，因此不能把這個相關趨勢直接說成「AI 已造成所有初級工程師失業」。這項研究的資料、職類定義與勞動市場也不等同於台灣或其他地區。

同樣地，美國勞工統計局預測 2024 至 2034 年整體軟體開發、QA 與測試職業會成長 15%。這是長期、整體職業的預測，不是在保證每一種入門職缺都會增加。把兩種資料放在一起，較合理的解讀是：工作總量與職能需求可能仍擴張，但入門工作如何被切分、誰得到訓練、雇主如何定義「可獨立交付」正在改變。

AI 不會在每個工程情境都自動提升效率

工具效果高度依賴任務與環境。METR 的隨機對照研究讓 16 位熟悉自己大型開源專案的資深開發者處理真實任務，結果在研究當時可用的 AI 工具下，使用工具的一組平均花了更久。這個結果不能直接推論到初級工程師或所有產品團隊，但足以提醒我們：自我感覺更快、展示範例更快，與長期交付品質或真實工時不一定相同。

針對初級開發者的系統性文獻回顧則發現，LLM 不只被用來產生程式碼，也被用於學習；同時，研究中反覆出現錯誤建議、資料外洩與幻覺等風險。這表示培訓的目標應是讓新人能問對問題、看出風險並驗證結果，而不是只學會寫提示。

把 AI 納入培訓，而不是取代培訓

先有自己的初步判斷

在向工具提問前，先寫下需求理解、可能的資料流、風險與最小測試方案。即使答案不完整，這一步能讓新人把 AI 的回覆拿來比較，而不是把第一份輸出當作標準答案。

把 AI 當作提出選項的同伴

請它解釋取捨、列出邊界條件、提出測試、找出可能遺漏的例外，通常比直接要求「幫我完成」更有學習價值。敏感原始碼、客戶資料與秘密資訊是否可輸入，也必須遵從團隊的明確政策。

用可重複的證據驗證

生成的程式碼應通過測試、靜態檢查、人工 code review 與必要的安全檢視；遇到故障時，要能重現、查看日誌並說明根因。若不能說明為何修改、測試覆蓋什麼，就還不算真正完成。

留下反思與回饋

在任務結束後記錄：AI 哪裡幫上忙、哪個建議錯了、最後採用什麼方案、下次要如何更快驗證。這些紀錄能把一次性工具使用轉成可累積的工程判斷。

把培訓設計成可觀察的學習循環

對主管與資深工程師而言，培訓不應只剩下「把任務切小，再看新人能不能交付」。更有效的做法是替每一段任務設定可觀察的學習證據：新人是否能說明需求與限制、提出測試案例、從監控或日誌找到線索、在 review 中解釋取捨，以及在下一次相似任務中少走哪些彎路。這些證據比一次完成的程式碼更能反映是否正在建立可遷移的能力。

可從一個小功能建立固定節奏：先由新人寫出問題重述與驗收條件，再使用 AI 協助列出方案與風險；接著自行完成最小修改與測試，最後在 review 中說明哪些內容來自工具、哪些地方已親自驗證。若結果出錯，復盤的重點不是追究「為什麼相信 AI」，而是找出需求、測試、資料或溝通在哪一個環節缺少防線。

當團隊把這些步驟留在 issue、設計說明或 pull request 裡，AI 的使用就不再是難以判讀的黑箱。主管可以據此提供具體回饋，新人也能看到自己從接受答案，進展到比較方案、主動驗證與承擔小範圍所有權。這種成長路徑同樣能降低新工具更迭時，培訓制度被一次打散的風險。

培訓設計也需要留出「可以安全犯錯」的空間。把練習放在可回復的小範圍變更、匿名化或模擬資料、明確的測試環境與可追溯的版本紀錄中，新人便能在風險受控的情況下比較 AI 建議與實際系統行為。待他們能穩定說明決策、處理例外並接受 review 後，再逐步擴大責任，會比一開始就以產出速度作為唯一標準更可靠。