1.5 軟體工程師的角色轉變#

從「建築工」到「指揮官」#

1.4 節論證了 AI 消滅附屬性困難、卻無法消滅本質性困難。這一節我們問一個更個人的問題：這對軟體工程師自己意味著什麼？

過去，一個軟體工程師的核心技能是「把想法翻譯成程式碼」——記住語法、熟悉函式庫、手寫有效率且正確的實作。這些都屬於附屬性困難的範疇。

當 AI 能幾秒生成這些程式碼時，「寫程式快不快」不再是工程師的核心競爭力。正如 1.4 節所說，價值重心移向了本質性困難——而那些，正是「指揮官與架構師」的技能，而不是「寫程式」的技能。

我們可以這樣描述這個轉變：

這不是說工程師不再寫程式——而是說，「寫程式」變成了工程的起點，而不是全部。

與其焦慮「我的工作會不會被取代」，不如思考「我的價值現在集中在哪裡」。AI 時代的軟體工程師，其核心價值集中在以下四個層次：

AI 不知道使用者真正要什麼。工程師的第一個核心能力，是傾聽、訪談、理解痛點，並把模糊的想法轉化成可執行的規格。這是在 1.4 節強調的需求分析能力，在第 2 章深入。

AI 提供了無限的「解答能力」，但人類必須提供唯一的「問題與情境」。

面對一個問題，有千百種實作方式。該用單體還是微服務？資料一致性要怎麼保證？擴展性與成本如何取捨？這些宏觀的技術決策需要對業務、對系統有深刻理解，AI 可以輔助分析，但不能替工程師做決定、更無法承擔後果。這是第 3 章的主題。

既然大量實作由 AI 完成，工程師的新技能就是如何正確地引導 AI。具體包括：

這套「引導 AI」的能力，在第二篇（第 7-10 章）會系統性展開。它本質上是一種新的「程式設計」——用自然語言與結構化規格程式化地指揮 AI。

AI 會產生幻覺、會寫出有漏洞的程式碼。因此，工程師承擔最終的品質與安全責任：審查 AI 生成的程式碼是否符合需求、架構是否一致、是否有安全漏洞。這是第 4、5 章的主題。

一個反直覺的結論是：AI 讓每個工程師都必須成為更好的審查者。因為過去你寫多少程式就審多少，現在 AI 幫你寫十倍，你就必須審查十倍——而審查往往比撰寫更難、更需要經驗。

回顧 1.3 節 Brooks 的「外科手術團隊」，在 AI 時代有了一個精彩的對應：人類工程師成為那位「主治醫師」，而 AI Agent 成為環繞在旁的專業副手。

外科手術團隊角色	AI 時代的對應
主治醫師（核心設計與關鍵程式碼）	人類工程師（定義 Spec、引導、做決策）
副手（隨時接替）	高階 AI（作為思想夥伴、預演架構）
系統分析員（撰寫需求與資料結構）	AI Spec Generator（從對話生成 Schema/規格）
測試員（編寫測試）	AI Test Agent（根據規格生成測試）
工具員（維護建置環境）	AI DevOps（生成 Dockerfile / CI/CD）
記錄員（維護文件）	AI Auto-Documentation（生成 README/文件）

Brooks 當年說「為每個頂尖工程師配 5-8 個專業副手太貴了」，而 AI 讓這個夢想第一次變得經濟可行——「一人大軍」成為可能。

但請注意一個關鍵前提：主治醫師（人類）的判斷與責任仍然無可替代。副手再多，手術台上的最終決策與成敗責任，還是由主治醫師扛。AI 時代的工程師，正是那個扛起「問題定義、架構設計、品質責任」的主治醫師。

要避免一個常見的誤解：「指揮官」不是指工程師不用再懂技術、只需要動動嘴。 恰恰相反，要指揮好 AI，工程師必須比過去更深刻地理解程式碼運作的原理——才能判斷 AI 的輸出是否真的正確、是否能看懂它並為它負責。不懂技術的人，連「審查 AI 輸出」這件事都做不了。

所以更精確的比喻是：未來優秀的工程師，是既懂技術、又懂業務、又會指揮 AI 的複合型人才。 他們不是更「輕」了，而是更深了——深度從「記憶與撰寫」轉向「理解、判斷與責任」。