在軟件開發(fā)領(lǐng)域，Martin Fowler 的名字幾乎等同于思想的燈塔。他的每一篇文章、每一次演講，都能為我們揭示行業(yè)發(fā)展的深層脈絡(luò)。最近，F(xiàn)owler 大師又發(fā)布了一篇簡短但引人深思的博文——《LLMs bring new nature of abstraction》，再次精準(zhǔn)地捕捉到了一個(gè)正在發(fā)生的、可能顛覆我們認(rèn)知和工作方式的巨大變革。

Fowler 認(rèn)為，大型語言模型（LLM）的出現(xiàn)，對軟件開發(fā)的影響，堪比從匯編語言到首批高級編程語言（HLLs）的飛躍。但關(guān)鍵在于，LLM 帶來的不僅僅是又一個(gè)“更高層次”的抽象，它正在從根本上改變編程的“本質(zhì)”——迫使我們思考，用“非確定性工具”進(jìn)行編程究竟意味著什么。在這篇文章中，我們就來簡單解讀一下。

從“確定性”的階梯到“非確定性”的岔路

回顧編程語言的發(fā)展史，我們一直在追求更高層次的抽象，以提升生產(chǎn)力、降低復(fù)雜度：

• 匯編語言 vs. 機(jī)器指令： 匯編讓我們用助記符替代了 0 和 1，但仍需關(guān)注特定機(jī)器的寄存器和指令集。
• 高級語言 (HLLs) vs. 匯編： Fortran、COBOL 等早期 HLLs 讓我們能用語句、條件、循環(huán)來思考，而不用關(guān)心數(shù)據(jù)如何在寄存器間移動(dòng)。Fowler 回憶道，他用 Fortran IV 編程時(shí)，雖然有諸多限制（如 IF 沒有 ELSE，整數(shù)變量名必須以 I-N 開頭），但這已經(jīng)是巨大的進(jìn)步。
• 現(xiàn)代語言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等現(xiàn)代語言，以及各種框架和領(lǐng)域特定語言（DSL），進(jìn)一步提升了抽象層次。我們現(xiàn)在可以本能地將函數(shù)作為數(shù)據(jù)傳遞，使用豐富的庫和模式，而不用從頭編寫大量底層代碼。

Fowler 指出，盡管這些發(fā)展極大地提升了抽象層次和生產(chǎn)力，但它們并沒有從根本上改變“編程的性質(zhì)”。我們?nèi)匀皇窃谂c機(jī)器進(jìn)行一種“確定性”的對話：給定相同的輸入和代碼，我們期望得到相同的輸出。錯(cuò)誤（Bug）也是可復(fù)現(xiàn)的。

然而，LLM 的介入，打破了這一基本假設(shè)。

Fowler 寫道：“用提示詞與機(jī)器對話，其差異之大，猶如 Ruby 之于 Fortran，F(xiàn)ortran 之于匯編”。

更重要的是，這不僅僅是抽象層次的巨大飛躍。當(dāng) Fowler 用 Fortran 寫一個(gè)函數(shù)，他可以編譯一百次，結(jié)果中的 Bug 依然是那個(gè) Bug。但 LLM 引入的是一種“非確定性”的抽象 (non-deterministic abstraction)。

這意味著，即使我們把精心設(shè)計(jì)的 Prompt 存儲(chǔ)在 Git 中，也不能保證每次運(yùn)行都會(huì)得到完全相同的行為。正如他的同事 Birgitta B?ckeler 精辟總結(jié)的那樣：

我們并非僅僅在抽象層級上“向上”移動(dòng)，我們同時(shí)也在“橫向”移入非確定性的領(lǐng)域。

圖片

Fowler 文章中的配圖非常形象地展示了這一點(diǎn)：傳統(tǒng)的編程語言、編譯器、字節(jié)碼是一條清晰的、自上而下的抽象路徑；而模型/DSL、代碼生成器、低代碼、框架是其上的不同抽象層次。自然語言（通過 LLM）則像一條從旁邊切入的、直接通往“半結(jié)構(gòu)化/接近人類思維”的道路，這條路本身就帶有模糊和不確定性。

“非確定性”編程時(shí)代的挑戰(zhàn)與啟示

這種“非確定性”的本質(zhì)，對我們 Gopher，乃至所有軟件開發(fā)者，都帶來了前所未有的挑戰(zhàn)和需要重新思考的問題：

1. 版本控制與可復(fù)現(xiàn)性： 當(dāng) Prompt 不能保證結(jié)果一致時(shí)，我們?nèi)绾喂芾砗桶姹净覀兊摹癆I輔助代碼”？如何確保開發(fā)、測試、生產(chǎn)環(huán)境的一致性，或者至少是可接受的差異性？僅僅版本化 Prompt 可能不夠，我們還需要版本化模型、參數(shù)（如 temperature）甚至是一些關(guān)鍵的種子（seed）嗎？
2. 測試與調(diào)試： 如何測試一個(gè)輸出不完全固定的“組件”？傳統(tǒng)的單元測試、集成測試方法是否依然有效？我們可能需要引入新的測試策略，例如基于屬性的測試、對輸出結(jié)果的統(tǒng)計(jì)驗(yàn)證、或者更側(cè)重于行為和意圖的驗(yàn)證。當(dāng) LLM 生成的代碼出現(xiàn)問題，調(diào)試的難度是否會(huì)指數(shù)級增加？
3. 可靠性與契約： 在一個(gè)包含非確定性AI組件的系統(tǒng)中，如何定義和保證整體的可靠性？服務(wù)間的“契約”又該如何描述和強(qiáng)制執(zhí)行？
4. 思維模式的轉(zhuǎn)變： 我們習(xí)慣了對代碼的精確控制，追求邏輯的嚴(yán)密和行為的可預(yù)測。現(xiàn)在，我們可能需要學(xué)會(huì)與“模糊”和“概率”共存，從“指令下達(dá)者”轉(zhuǎn)變?yōu)椤耙鈭D溝通者”和“結(jié)果篩選者”。

這對我們 Gopher 意味著什么？

Go 語言以其明確性、強(qiáng)類型、簡潔的并發(fā)模型以及相對可預(yù)測的行為，深受開發(fā)者喜愛。當(dāng)我們嘗試將 LLM 融入 Go 的生態(tài)和開發(fā)流程時(shí)，這些“非確定性”的特性會(huì)帶來新的思考：

• AI 生成 Go 代碼： 當(dāng)我們使用 LLM 生成 Go 代碼片段、單元測試，甚至整個(gè)模塊時(shí)，如何確保生成的代碼符合 Go 的最佳實(shí)踐、是高效且安全的？如何對生成的代碼進(jìn)行有效的審查和集成？
• 用 Go 構(gòu)建與 LLM 交互的工具/Agent： 如果我們用 Go 開發(fā)與 LLM 交互的后端服務(wù)或智能體（Agent），我們需要在架構(gòu)設(shè)計(jì)上充分考慮 LLM 的非確定性，設(shè)計(jì)更魯棒的錯(cuò)誤處理、重試機(jī)制，以及對 LLM 輸出結(jié)果的驗(yàn)證和篩選邏輯。
• 利用 LLM 理解復(fù)雜 Go 系統(tǒng)： LLM 或許能幫助我們理解遺留的復(fù)雜 Go 代碼庫，但其解釋的準(zhǔn)確性和一致性也需要我們審慎評估。

Fowler 在文末表達(dá)了他對這一變革的興奮之情：“這種改變是戲劇性的，也讓我頗為興奮。我相信我會(huì)為一些失去的東西感到悲傷，但我們也將獲得一些我們中很少有人能理解的東西。”

小結(jié)：擁抱不確定，探索新大陸

Martin Fowler 的這篇文章，為我們揭示了 LLM 時(shí)代編程范式可能發(fā)生的深刻轉(zhuǎn)變。它不再僅僅是工具的進(jìn)化，更是與機(jī)器協(xié)作方式的本質(zhì)性變革。

作為 Gopher，作為軟件工程師，我們需要開始認(rèn)真思考這種“非確定性”帶來的影響，積極探索與之共存、甚至利用其特性創(chuàng)造價(jià)值的新方法。這無疑是一個(gè)充滿挑戰(zhàn)但也充滿機(jī)遇的新大陸。

你如何看待 Fowler 的這個(gè)觀點(diǎn)？你認(rèn)為 LLM 帶來的“非確定性”會(huì)對你

的日常開發(fā)工作產(chǎn)生哪些具體影響？

資料地址：https://martinfowler.com/articles/2025-nature-abstraction.html