# 軟體工程的典範轉移：深入解析 Martin Fowler 對於從確定性到非確定性系統的觀點

---
https://youtu.be/CQmI4XKTa0U?list=TLGGKD78I6EfcOwxMTEyMjAyNQ
Martin Fowler on AI and the Future of Software Engineering

## 1. 導論：軟體工程的新紀元

軟體工程正處於一個根本性的轉捩點。由人工智慧（AI）和大型語言模型（LLMs）所引領的變革浪潮，其規模與深度前所未見。資深軟體思想家 Martin Fowler 將此定義為他職業生涯中所見過的最重大的技術革新，這一判斷為我們理解當前的變局提供了絕佳的切入點，並確立了本文的論述核心。

Martin Fowler 是軟體開發領域的權威人物，其影響力深遠。作為 2001 年《敏捷軟體開發宣言》的共同作者之一，以及在軟體架構和重構（Refactoring）領域的開創性工作，他的觀點為業界提供了寶貴的指引。他數十年來對產業的敏銳觀察，使其能夠精準地剖析當前這場變革的本質。Fowler 的核心洞見是，這次轉變直接挑戰了過去四十年來建立在可預測性與控制之上的工程文化，從根本上動搖了我們行業的基石。

本文將深入探討 Fowler 的核心論點，解析這場典範轉移的根本驅動力。我們將回顧歷史上一次可相提並論的技術飛躍，藉以理解今日變革的規模，並進一步探討此一轉變對軟體開發的實踐、核心原則乃至工程師角色的深遠影響。

---

## 2. 歷史的迴響：從組合語言到高階語言的飛躍

要真正理解 AI 帶來變革的規模與深度，回顧軟體開發史上一次具可比性的轉變至關重要。Fowler 認為，當前的情勢堪比從組合語言（Assembly Language）過渡到第一代高階語言（如 Fortran）的歷史性飛躍。本章節將分析這次轉變的關鍵特徵，以此作為理解今日變革的參照。

從組合語言到高階語言的轉向，不僅僅是語法的改變，更是一次徹底的思維模式變革。其核心差異體現在以下幾個層面：

| 特性（Characteristic） | 組合語言（Assembly Language） | 高階語言（High-Level Languages） |
| -------------------------- | ------------------------------------- | ---------------------------------------------------------- |
| 硬體耦合度（Hardware Coupling） | - 指令與特定晶片的指令集緊密綁定，無法在不同晶片上通用。 | - 將開發者從特定的硬體中解放出來，實現了跨平台能力。 |
| 抽象層次（Level of Abstraction） | - 開發者必須思考極其底層的操作，例如將數值從記憶體位置移動到特定暫存器。 | - 提供如條件式（if statements）和迴圈（loops）等抽象概念，讓開發者能以更接近人類邏輯的方式思考。 |
| 開發思維（Developer Mindset） | - 思維以硬體為中心，需要深入了解硬體內部運作的細節。 | - 開發者的思維從硬體細節轉向解決問題的邏輯本身，這是一次根本性的「思維轉變（mind shift）」。 |

這一歷史轉變的戰略意義在於，它透過大幅提升抽象層次，將開發者從繁瑣的硬體細節中解放出來，從而極大地提升了生產力與軟體的可移植性。這次飛躍是由於抽象層次的提升所定義的。然而，Fowler 指出，當前的變革雖然規模相當，卻是由一股更具顛覆性的力量所驅動：對可預測性本身的摒棄。

---

## 3. 轉移的核心：從確定性邁向非確定性

Martin Fowler 的核心論點直指當前變革的根本：這次由 AI 驅動的典範轉移，其最關鍵的特徵並非再次提升抽象層次，而是 **「從確定性（determinism）轉向非確定性（non-determinism）」**。理解這一點，是掌握未來軟體工程的關鍵所在。

傳統程式設計的基石是確定性——給定相同的輸入，程式永遠會產生相同的輸出。這是我們構建可靠、可預測系統的基礎假設。然而，與 LLMs 的互動則完全處於一個非確定性的環境中。相同的提示（prompt）在不同時間可能會產生略有差異的結果。這種內在的隨機性，徹底顛覆了軟體開發的基礎。

為了說明這種思維轉變的必要性，Fowler 引用了他妻子（一位結構工程師）的類比。實體世界的工程師在設計橋樑或建築時，從不假設材料是完美的。他們必須考慮「容忍度（tolerances）」，為木材、混凝土或鋼鐵的內在變異性預留安全邊際。軟體工程師現在也必須開始培養類似的思維，去理解和管理我們工具的非確定性。Fowler 警示，若未能妥善處理這種不確定性，尤其在安全性等關鍵領域，我們可能會面臨「橋樑崩塌」式的災難性後果。

這要求我們從軟體工程師傳統的二元思維（系統要嘛正常運作，要嘛徹底損壞），轉向物理工程師的機率性思維，即定義可接受的失效模式、安全邊際和性能範圍。

這種從確定性到非確定性的轉變，要求我們發展全新的工具、技術與思維模式。它不僅改變了我們編寫程式碼的方式，更迫使我們重新思考如何驗證、測試和維護我們的系統。

---

## 4. 駕馭新版圖：AI 時代的實踐與挑戰

在理解了非確定性的理論基礎後，我們需要將目光投向 LLMs 在軟體工程中的具體應用、新興的工作流程，以及隨之而來的嚴峻挑戰。本章節將基於 Fowler 的觀察，提供一個務實的視角。

### 4.1 已驗證的成功領域：快速原型與遺留系統解析

LLMs 已在兩個特定領域展現出明確且巨大的價值：

1. **快速原型製作（Rapid Prototyping）**：
LLMs 能在數天內完成過去需要數週才能完成的原型。這種速度優勢使其成為探索性工作、一次性工具開發和概念驗證的理想選擇。開發者可以藉此更快速地測試想法，並在投入大量資源前獲得早期反饋。

2. **理解遺留系統（Legacy Systems）**：
這或許是 LLMs 目前最令人驚豔的應用之一。透過將遺留程式碼庫的資訊載入到圖形資料庫中，並利用 LLMs 進行語義查詢，開發團隊能夠極大地加速對複雜、陳舊系統的理解。Thoughtworks 的技術雷達（Technology Radar）甚至已將此應用列入「採用（Adopt）」環節，這證明了其高度的有效性與成熟度。這也標誌著一個關鍵轉變：LLMs 不僅是新開發的生產力輔助工具，更正成為管理多數企業 IT 資產中最大負債——遺留資產——不可或缺的利器。

### 4.2 「氛圍編碼」的兩難：學習迴圈的關鍵作用

隨著 AI 工具的普及，「氛圍編碼（vibe coding）」的概念應運而生，意指開發者在不細看、不理解的情況下，直接使用由 AI 生成的程式碼。Fowler 認為，這種做法有其適用場景，例如一次性或拋棄式的探索性工作。

然而，將「氛圍編碼」應用於需要長期維護的系統，則隱藏著巨大的風險。其最大的弊病在於，它移除了至關重要的「學習迴圈（learning loop）」。如果開發者不理解 AI 的輸出，就無法對其進行微調、修改與演進。雖然這種方式在短期內創造了速度的假象，但它會產生無法維護的系統，在面對不斷變化的業務需求時極其脆弱，從而危及企業的長期敏捷性。當需求變更或出現問題時，唯一的選擇往往是將程式碼完全拋棄並從頭來過。

### 4.3 尚待探索的疆域：程式碼修改與團隊協作

儘管 LLMs 在生成新程式碼方面表現出色，但在其他關鍵領域仍面臨重大挑戰：

* **修改現有程式碼**：
Fowler 提到一個例子，使用 AI 工具（如 Cursor）在一個中等大小的專案中重新命名一個類別，結果耗時一個半小時，並用掉了大量的 token 配額。相比之下，現代 IDE 中的自動化重構功能只需幾秒鐘就能安全地完成。這凸顯了當前 AI 工具的一個關鍵差距：它們雖然擅長生成，卻缺乏對現有系統進行安全、大規模演進所需的精準「外科手術」能力——而這正是任何成熟工程組織的核心競爭力。

* **團隊協作**：
目前絕大多數關於 AI 輔助開發的經驗都集中在個人開發者的工作流程上。然而，軟體開發本質上是團隊活動。如何將 AI 有效地整合到團隊的協作流程中，是一個至今尚未解決的重大問題。

總而言之，LLMs 雖然帶來了強大的新能力，但也伴隨著需要我們審慎應對的風險與未知。這引導我們去思考，在這樣的新環境下，那些被時間驗證過的軟體開發原則將扮演何種角色。

---

## 5. 核心原則的再確認：AI 時代的軟體工藝

在一個由非確定性工具驅動的時代，堅守核心的軟體工藝原則不再僅僅是最佳實踐，而是一種根本的風險緩解策略。高品質軟體開發的基石——如測試、重構和敏捷——不僅沒有過時，反而變得比以往任何時候都更加重要。

* **測試的重要性（The Importance of Testing）**：
當你的協作者是一個會「說謊」、會產生不可預測輸出的非確定性工具時，嚴謹的自動化測試成為了對其施加經驗控制的唯一機制。如同 Simon Willison 和 Birgitta Böckeler 所強調的，測試是我們與 LLMs 安全互動的護欄。你必須「不信任但驗證（don't trust but do verify）」，而測試正是實現驗證的核心紀律。

* **重構的價值提升（The Increased Value of Refactoring）**：
隨著 AI 工具大量產出程式碼，重構作為管理 AI 生成程式碼固有「技術債」的主要紀律，其價值將顯著提升。重構是在不改變軟體外部行為的前提下，改善其內部結構的嚴謹實踐。面對 AI 可能產生的程式碼——Fowler 在檢視一個 AI 生成的 SVG 文件時發現其可能「複雜和 convoluted 得令人吃驚」——重構將成為將其整理、簡化並維持系統長期健康度的關鍵手段。

* **敏捷精神的延續（The Continuity of Agile Principles）**：
敏捷開發的核心理念是「小步快跑、快速迭代」。專注於縮短週期時間（cycle time）和收緊反饋迴圈，是應對複雜系統的最佳策略。AI 或許能讓我們更快地完成每一個「切片（slice）」，但敏捷的精神——持續交付價值、快速學習與適應——依然是指導我們前進的根本原則。

擁抱 AI 的同時，我們更應堅守這些被時間驗證過的軟體工藝原則。它們是我們在充滿不確定性的新時代中，打造卓越、可靠軟體的定海神針。

---

## 6. 結論：軟體工程師角色的演化

本文的核心論點是，當前由 AI 引領的典範轉移，其根本在於從確定性到非確定性系統的轉變。這一轉變深刻地影響了我們的開發實踐、挑戰了傳統的工作流程，並反而強化了軟體工藝的核心原則。

AI 不會取代軟體開發，而是將其重心從「編寫程式碼」這一具體行為，轉移到更高層次的活動上。根據 Martin Fowler 的觀點，未來的軟體工程師需要具備並強化以下核心能力：

1. **溝通與協作（Communication and Collaboration）**：
理解業務需求、與使用者和領域專家進行有效溝通的能力，將變得比以往任何時候都更加重要。軟體的價值最終體現在它為人類解決了什麼問題，而這需要深刻的理解與共情。

2. **批判性思維與驗證（Critical Thinking and Verification）**：
工程師必須培養對 AI 輸出保持懷疑的態度，並透過嚴格的測試、程式碼審查等手段進行驗證。我們將從程式碼的創作者，更多地轉變為高品質的審閱者與守門人。

3. **終身學習與指導（Lifelong Learning and Mentorship）**：
在技術快速變化的環境中，持續學習的能力是生存的基礎。同時，尋找並成為優秀的導師（Mentor）將至關重要。資深工程師的經驗與判斷力，是引導初級工程師安全駕馭新工具、避免陷阱的寶貴資產。

軟體工程的未來充滿了變數與機遇。架構師與資深工程師的角色，將從打造確定性的機器，演變為培育具備韌性的適應性生態系統。我們的使命不再是消除變異性，而是設計出在 AI 組件的內在變異性面前，依然能穩健運作的系統。這正是軟體工藝在新紀元的核心挑戰與價值所在。