大家好，我是Tony Bai。
在軟體開發領域，Martin Fowler 的名字幾乎等同於思想的燈塔。他的每一篇文章、每一次演講，都能為我們揭示產業發展的深層脈絡。最近，Fowler 大師又發布了一篇簡短但引人深思的部落格文章——《LLMs bring new nature of abstraction》，再次精準地捕捉到一個正在發生、可能顛覆我們認知與工作方式的巨大變革。
Fowler 認為，大型語言模型（LLM）的出現，對軟體開發的影響，堪比從組合語言到首批高階程式語言（HLLs）的飛躍。但關鍵在於，LLM 帶來的不僅僅是又一個「更高層次」的抽象，它正在從根本上改變程式設計的「本質」——迫使我們思考，用「非確定性工具」進行程式設計究竟意味著什麼。在這篇文章中，我們就來簡單解讀一下。
從「確定性」的階梯到「非確定性」的岔路
回顧程式語言的發展史，我們一直在追求更高層次的抽象，以提升生產力、降低複雜度：
• 組合語言 vs. 機器指令：組合語言讓我們用助記符取代了 0 和 1，但仍需關注特定機器的暫存器和指令集。
• 高階語言 (HLLs) vs. 組合語言：Fortran、COBOL 等早期高階語言讓我們能用語句、條件、迴圈來思考，而不用關心資料如何在暫存器間移動。Fowler 回憶道，他用 Fortran IV 程式設計時，雖然有諸多限制（如 IF 沒有 ELSE，整數變數名稱必須以 I-N 開頭），但這已是巨大的進步。
• 現代語言、框架、DSL vs. 早期高階語言：Ruby、Go、Python 等現代語言，以及各種框架和 領域特定語言（DSL），進一步提升了抽象層次。我們現在可以本能地將函式作為資料傳遞，使用豐富的函式庫和模式，而不用從頭編寫大量底層程式碼。
Fowler 指出，儘管這些發展極大地提升了抽象層次和生產力，但它們並沒有從根本上改變「程式設計的性質」。我們仍然是在與機器進行一種「確定性」的對話：給定相同的輸入和程式碼，我們期望得到相同的輸出。錯誤（Bug）也是可重現的。
然而，LLM 的介入，打破了這一基本假設。
Fowler 寫道：「用提示詞與機器對話，其差異之大，猶如 Ruby 之於 Fortran，Fortran 之於組合語言」。
更重要的是，這不僅僅是抽象層次的巨大飛躍。當 Fowler 用 Fortran 寫一個函式，他可以編譯一百次，結果中的錯誤依然是那個錯誤。但 LLM 引入的是一種「非確定性」的抽象 (non-deterministic abstraction)。
這意味著，即使我們把精心設計的 Prompt 儲存在 Git 中，也不能保證每次執行都會得到完全相同的行為。正如他的同事 Birgitta Böckeler 精闢總結的那樣：
我們並非僅僅在抽象層級上「向上」移動，我們同時也在「橫向」移入非確定性的領域。
Fowler 文章中的配圖非常形象地展示了這一點：傳統的程式語言、編譯器、位元組碼是一條清晰的、自上而下的抽象路徑；而模型/DSL、程式碼生成器、低程式碼、框架是其上的不同抽象層次。自然語言（透過 LLM）則像一條從旁邊切入的、直接通往「半結構化/接近人類思維」的道路，這條路本身就帶有模糊和不確定性。
「非確定性」程式設計時代的挑戰與啟示
這種「非確定性」的本質，對我們 Go 開發者，乃至所有軟體開發者，都帶來了前所未有的挑戰和需要重新思考的問題：
• 版本控制與可重現性：當 Prompt 不能保證結果一致時，我們如何管理和版本化我們的「AI輔助程式碼」？如何確保開發、測試、生產環境的一致性，或者至少是可接受的差異性？僅僅版本化 Prompt 可能不夠，我們還需要版本化模型、參數（如 temperature）甚至是一些關鍵的種子（seed）嗎？
• 測試與偵錯：如何測試一個輸出不完全固定的「元件」？傳統的單元測試、整合測試方法是否依然有效？我們可能需要引入新的測試策略，例如基於屬性的測試、對輸出結果的統計驗證、或者更側重於行為和意圖的驗證。當 LLM 生成的程式碼出現問題，偵錯的難度是否會指數級增加？
• 可靠性與協定：在一個包含非確定性 AI 元件的系統中，如何定義和保證整體的可靠性？服務間的「協定」又該如何描述和強制執行？
• 思維模式的轉變：我們習慣了對程式碼的精確控制，追求邏輯的嚴密和行為的可預測。現在，我們可能需要學會與「模糊」和「機率」共存，從「指令下達者」轉變為「意圖溝通者」和「結果篩選者」。
這對我們 Go 開發者意味著什麼？
Go 語言以其明確性、強型別、簡潔的並發模型以及相對可預測的行為，深受開發者喜愛。當我們嘗試將 LLM 融入 Go 的生態和開發流程時，這些「非確定性」的特性會帶來新的思考：
• AI 生成 Go 程式碼：當我們使用 LLM 生成 Go 程式碼片段、單元測試，甚至整個模組時，如何確保生成的程式碼符合 Go 的最佳實踐、是高效且安全的？如何對生成的程式碼進行有效的審查和整合？
• 用 Go 建構與 LLM 互動的工具/代理：如果我們用 Go 開發與 LLM 互動的後端服務或 智能體（Agent），我們需要在架構設計上充分考慮 LLM 的非確定性，設計更穩健的錯誤處理、重試機制，以及對 LLM 輸出結果的驗證和篩選邏輯。
• 利用 LLM 理解複雜 Go 系統：LLM 或許能幫助我們理解遺留的複雜 Go 程式碼庫，但其解釋的準確性和一致性也需要我們審慎評估。
Fowler 在文末表達了他對這一變革的興奮之情：「這種改變是戲劇性的，也讓我頗為興奮。我相信我會為一些失去的東西感到悲傷，但我們也將獲得一些我們中很少有人能理解的東西。」
總結：擁抱不確定，探索新大陸
Martin Fowler 的這篇文章，為我們揭示了 LLM 時代程式設計範式可能發生的深刻轉變。它不再僅僅是工具的進化，更是與機器協作方式的本質性變革。
身為 Go 開發者，身為軟體工程師，我們需要開始認真思考這種「非確定性」帶來的影響，積極探索與之共存、甚至利用其特性創造價值的新方法。這無疑是一個充滿挑戰但也充滿機遇的新大陸。
你如何看待 Fowler 的這個觀點？你認為 LLM 帶來的「非確定性」會對你的日常開發工作產生哪些具體影響？歡迎在評論區分享你的看法！
資料連結：https://martinfowler.com/articles/2025-nature-abstraction.html