AI 時代，軟體工程師真正的工作是什麼？

「AI 會取代我嗎？」這大概是近幾年來，每個軟體工程師心中或多或少都浮現過的疑問。大家都在討論 AI 將如何取代勞動力，但如果我們只停留在這個問題上，其實就問錯了方向。

在 AI 時代，我們的任務不是被動地使用 AI，而是要反過來思考：如何讓 AI 變得更有效率？

這聽起來可能有點違反直覺，但這背後牽涉到 AI 目前的本質與極限。如果我們不理解這些，直接將 AI 應用在開發流程中，很容易會感到綁手綁腳。這篇文章將從 AI 的基本概念、訓練方法的困境，一路談到軟體工程師在 AI 協作中的新角色與實戰心法。

揭開大型語言模型 (LLM) 的神秘面紗

首先，我們要理解一件事：至今所有的大型語言模型（LLM），本質上都只是在「模仿」人類的文本與對話。它們最主要的任務，就是預測下一個字 (Token)。

AI 缺乏「世界模型 (World Model)」

LLM 並沒有真正地去「理解」一件事情發生的因果關係。最近 AI 領域的大佬們都在談論一個概念叫做「世界模型 (World Model)」，指的是一種能理解世界運轉原理，並依此進行預測的能力。

舉個例子，我們人類知道「滾燙的熱水壺不能碰，因為會燙傷」，這背後隱含著物理原理。但如果我們只告訴 AI：「看到正在燒的熱水壺，不能碰」，它學到的只是一個指令。當場景換成早餐店裡發燙的鐵板時，它可能就無法舉一反三，因為它不懂那個共通的底層邏輯——「高溫物體會造成傷害」。

Andrej Karpathy（前 Tesla AI 負責人）曾說，我們現在訓練 LLM，不像在培育一個學習中的動物，更像在「召喚一個幽靈 (Ghost)」。動物或小孩會透過與世界的互動、嘗試與犯錯來學習；而現在的 LLM 則是大量吞噬人類的文本，成為我們思想與語言的「分身」，但它本身並沒有真正的思考與理解能力。

當前的訓練方法：為何 AI 會「蒙對答案」？

既然 LLM 有其極限，那為什麼它有時看起來那麼厲害，有時候又幻覺重重？這與它的訓練方式有關。

目前主流的訓練方法，例如監督式微調或強化學習 (Reinforcement Learning)，在某種程度上是非常「暴力」的。模型在解決一個問題時，會產生一連串的思考路徑，但我們通常只根據「最終答案」的對錯來給予獎勵或懲罰。

這就像學生時代考選擇題，就算中間的思考過程完全錯誤，只要最後「蒙對」了答案，一樣能得分。這種訓練方式會導致一個問題：模型可能因為錯誤的理由，產生了正確的結果。這也是造成 AI「幻覺 (Hallucination)」的主要原因之一。

一個更理想的方式，是所謂的 Process-based Supervision，也就是像大學申論題一樣，重視整個解題的邏輯與過程，而不僅僅是最終的答案。但這種方式實作起來非常困難：

• 人力評分太慢：讓人類去評估 AI 每一步的思考路徑，成本極高且效率低下。
• AI 評分有風險：讓舊模型（如 GPT-4）去評分新模型（如 GPT-5），新模型很容易找到舊模型的漏洞並產生「對抗樣本」，學會如何「欺騙」評分系統。

一個更聰明的訓練方向：經驗反思 (Experiential Reflection)

既然逐格審查思考路徑如此困難，那還有沒有別條路？最近，來自 Meta AI 等實驗室的研究者提出了一個更接近人類學習方式的方向，稱為經驗反思 (Experiential Reflection) – Agent Learning via Early Experience。

這個概念的核心是將 LLM 視為一個代理人 (Agent)。我們不再只餵給它靜態的文本，而是給它一個任務，讓它在一個真實或模擬的環境中去「嘗試」。

整個流程大致如下：

1. 給定任務：例如，「去這個電商網站上買一個東西」。
2. 生成行動方案：AI 會生成數十種可能的行動方案（Action），例如「點擊這個按鈕」、「在搜尋框輸入文字」等等。
3. 與環境互動：系統會執行這些行動，並從環境中得到真實的回饋 (Feedback)，可能是「成功加入購物車」，也可能是「頁面錯誤」。
4. 學習因果：最後，模型會根據「問題 + 行動 + 環境回饋」這個完整的數據組來進行再訓練。

透過這個循環，AI 就能慢慢學會「如果我採取了某個行動，大概會發生什麼事」。它不再是單純地模仿文字，而是開始透過試錯來理解行為與結果之間的因果關係，這是建構「世界模型」非常關鍵的一步。雖然這個方向仍在積極研究中，但它代表了未來 AI 訓練的一個更理想的典範。

軟體工程師的新角色：成為 AI 的架構師

了解了 LLM 的極限後，我們就能重新定位自己的角色。我們的價值不再是逐行撰寫樣板程式碼，而是成為 AI 的引導者與架構師。

從高層次來看，我們的任務轉變為：

1. 定義系統架構與模組邊界：高層次的架構設計、模組如何切分、介面如何定義，這些是 AI 的弱項，卻是我們的強項。
2. 控制複雜度與技術債：AI 看過的文本大多是大型、完善的系統，容易產生「過度設計」的程式碼。我們需要判斷情境，控制實作的複雜度，避免不必要的技術債。
3. 確保系統的可維護性與可擴展性：AI 產生的程式碼不一定好維護。我們需要審視其成果，確保整個系統的健康度。

簡單來說，我們負責搭好骨架、劃清邊界，讓 AI 這位超級會寫程式碼的「實習生」去填充血肉。

小心上下文腐爛 (Context Rot)

許多 LLM 號稱擁有超長的上下文視窗（例如 100K Token），但研究與實踐都發現，模型對於上下文的注意力主要集中在「開頭」與「結尾」，中間的資訊很容易被遺忘。這就是所謂的「上下文腐爛 (Context Rot)」。

如果我們一股腦地把十幾個檔案、上百個函式全部丟給 AI，不僅會迅速消耗寶貴的上下文空間，真正重要的資訊也可能被淹沒在中間而被忽略。

因此我們要理解 Prompt Engineering、Context Engineering，負責把大問題切成幾個明確的小步驟，並在提示詞清楚定義目標、約束、格式，最後給足必要背景，但避免無差別塞一大堆。

實戰分享：我的 AI 協作工作流

在實際開發中，我不會只用一句話叫 AI 寫 Code，而是透過更結構化的方式與它協作。

Case 1：從 API 到前端頁面的開發

在開發一個新功能頁面時，我的習慣是先開一個文字檔，把整個需求從頭到尾定義清楚：

1. 定義 API 規格：條列出所有會用到的 API Endpoint，以及 Request/Response 的格式。
2. 定義資料傳輸物件 (DTO)。
3. 定義前端狀態管理 (State / Store) 的結構。
4. 定義 Component 的 Props 與互動行為。

我會將這個脈絡清晰、從上到下的完整說明貼給 AI，讓它一次性生成整個功能的程式碼。這種「頭尾都掐好」的方式，成功率遠高於一句句地下指令。

Case 2：後端 API 的重構與擴充

之前在修改一個後端 API、需要加入新的檢查條件時，我並沒有時間去追溯所有相關的程式碼。我的做法是：

1. 提供精準的上下文：我先大致瀏覽了 API 的進入點、呼叫了哪個 Service，然後明確告訴 AI：「請你看這幾個檔案，特別是這個函式。我需要在裡面增加 B 和 C 的檢查。」
2. 先 Review 計畫，再實作：我會要求 AI：「先不要動手改，告訴我你打算怎麼改。」它會列出修改計畫，我確認這個計畫符合我們的系統架構，並提出調整建議。
3. 迭代與修正：來回幾次，確認命名風格、錯誤訊息都符合需求後，才讓它開始實作。

這個過程，我扮演的角色是提供關鍵資訊的偵探和審核設計圖的架構師，把繁瑣的程式碼閱讀與撰寫交給 AI。

結語

回到最初的問題，AI 不會「取代」我們，但它正在徹底「改變」我們的工作模式。

人類工程師的任務，是透過我們的經驗與智慧，進行系統設計、切分複雜問題、提供精準的上下文，將 AI 的能力最大化。我們不再是單純的「Coder」，而是「AI Coder」，是懂得如何駕馭 AI、讓 AI 為我們高效產出的指揮家。

我們正處於 AI 時代，或者說，AI Agent 十年的第一年，許多訓練方式與應用都還很原始。但可以肯定的是，未來軟體工程師的核心價值，將更多地體現在思考、設計與決策上。

投影片