62歲軟件教父Martin Fowler警告：AI泡沫下，裁員潮印證行業蕭條，大模型正將編程拖入“非確定性深淵”！

編譯 | 褚杏娟、核子可樂

Martin Fowler 是軟件架構乃至整個技術行業中最具影響力的人物之一。這位 62 歲的軟件開發專家，是 ThoughtWorks 的首席科學家，也是《重構》《企業應用架構模式》等多本著作的作者。數十年來，他一直在塑造工程師對設計、架構和流程的思考方式，并在他的博客 MartinFowler.com 上持續發表見解。

作為一個見證了互聯網時代興起的資深開發，他也面臨新技術帶來的變化。在近期的 The Pragmatic Engineer 節目中，Martin 討論了 AI 如何改變軟件開發：從確定性編碼向非確定性編碼的轉變、大模型如何幫助處理遺留代碼，以及 vibe coding 那些有限但很有用的應用場景。

Martin 還解釋了為什么必須對大模型的輸出進行嚴格測試、為什么重構比以往任何時候都更重要，以及如何把 AI 工具與確定性技術結合，可能正是工程團隊所需要的方向。他談到，盡管工具和工作流程在快速變化，但造就一名優秀工程師的核心能力在很大程度上始終未變。

他認為，今年科技界的大規模裁員是軟件開發行業正處于“蕭條”狀態的一個跡象。Layoffs.ai 數據顯示，截至目前，2025 年科技行業的裁員人數已達約 11.4 萬，而 2024 年全年的裁員人數則接近 15.3 萬。他指出，在當前這個“充滿不確定性”的時代，企業不愿投資軟件。而且，盡管科技界正大力投資 AI，但這種增長似乎是“另一個獨立的領域”，而且“顯然存在泡沫”。

我們翻譯了這次采訪，并在不改變原意基礎上進行了刪減，以饗讀者。

1 個人成長歷程

進入軟件工程領域

主持人：能和我們說說你是如何進入軟件開發領域的嗎？畢竟這已經是幾十年前的事了。

Martin：其實這挺偶然的。我上學時文科特別差，但凡沾寫作的科目成績都一塌糊涂，但數學、物理這類還不錯，所以就挺偏向工程類的東西。我本身對電子產品也感興趣，可動手能力實在太差，那些要體力、講身體協調性的活兒都干不了，比如車上生銹的螺母我都擰不下來，因此好多工程領域都不適合我。不過電子學還行，頂多需要會個焊接，沒別的復雜要求。后來接觸到電腦，發現特別順手，就這么慢慢摸進了計算機領域，這也是我入行軟件開發的契機。

上大學前，我還在英國原子能管理局干過一陣子，那會兒用 Fortran 4 寫了些程序，覺得這技能挺實用的。大學我學的是電子工程和計算機科學交叉專業，畢業后有兩個選擇：要么進傳統工程領域，薪資和地位都一般；要么闖計算機領域，當時看起來機會明顯更多，我就選了后者。

主持人：那時候互聯網還沒興起，當時能找到什么樣的工作？你的第一份工作是什么？

Martin：我第一份工作是在 Coopers & Lybrand 這家咨詢公司。我所在的小組是做信息戰略咨詢的，但我的工作不一樣，因為我大學學過 Unix，是公司里少數懂 Unix 的人之一，所以我主要負責維護一批工作站，這些機子是用來跑他們做戰略工作的一款專用軟件的。

后來我慢慢對他們的戰略工作也感興趣了，就慢慢涉獵其中。現在回頭想想，當時不少東西其實都挺華而不實的，但這確實是我入行的契機，還讓我很早就接觸到了面向對象的思維，對我后來的發展很有幫助。

主持人：你是如何接觸到面向對象編程的？要知道在當時，面向對象編程可是很前沿的東西，而你所在的咨詢公司似乎并不是最前沿的那種。

Martin：雖說我們公司整體其實不算多前沿，但我待的小組卻在在做一些前前沿的事兒。那會兒我們碰到一個人，這人滿腦子都是新奇想法，其中不乏一些特別亮眼的觀點，當然也有一些略顯瘋狂的想法。他還特意用“面向對象”這個專業術語來包裝這些想法，雖說當時那些內容和真正的面向對象理念其實沒完全對上，也算之前說的那種華而不實的東西之一，但平心而論，他的不少想法確實很有價值。

也正因為這個契機，我才開始往這個方向深耕，后來也慢慢摸清了面向對象編程的真正內核，直接奠定了我之后十幾年的職業基礎。

加入 ThoughtWorks

主持人：你是如何一步步發展，最終加入 ThoughtWorks 的？而且你還開始寫書、發表文章，從一個剛入行、充滿好奇的新人，慢慢變成了一個能夠指導他人的人，這個過程是怎樣的？

Martin：說起來，我的職業軌跡里充滿了巧合。在 Coopers & Lybrand 工作時，我遇到了一個美國人 Jim Odell，他可以說是我早期職業生涯中最重要的導師。他是信息工程領域的早期實踐者，兼具顧問和教師身份。他總能從各種新概念、新理論里，精準識別出真正有價值的部分，并帶著我深入理解。

在那家公司工作了幾年后，我離職加入了一家叫 PEK 的小公司。那家公司在英國的辦公室只有四個人，而這已經是公司最大的辦公室了。在那里待了兩年后，我決定成為獨立顧問。多虧了 Jim Odell 給我介紹了很多工作機會，加上我在英國本地也接到了一些項目，所以一開始發展得相當順利。當時我還在心里想：“從此以后，再也不會給任何公司打工了。”結果……這句話后來成了“名言”。

整個 90 年代，我做獨立顧問做得風生水起，期間還寫了我的第一本書。后來我參與了 Chrysler 的 C3 項目，與 Kent Beck 一起工作，親眼見證了極限編程（XP）和敏捷方法論的誕生。1993 年我搬到了美國，生活也過得很愉快。90 年代末互聯網騰飛，行業非常活躍。就在這期間，我開始接觸 ThoughtWorks。

最初它只是我的客戶。當時他們在做一個大項目，大約 100 人，規模不小，但看起來馬上要“炸掉”了。我幫他們梳理問題、止住下滑，最終也確實把項目救了回來。之后，他們向我發出了加入的邀請。

ThoughtWorks 有個很獨特的氣質：他們從不說“這很難，所以做不了”，他們會說“這確實很難，但我們可以試試”，而且往往還能真的把事情做成。正是這種精神吸引了我。我當時想：加入他們一兩年也不錯。結果沒想到，這一待，就是 25 年。

主持人：你加入 ThoughtWorks 后，十多年來一直擔任首席科學家一職，這個職位具體負責什么工作？

Martin：說實話，我不是任何人的“Chief”，而且我也不做任何科學研究。這個頭銜主要是“對外發聲”的角色，當時業界流行給思想領袖一個這樣聽上去很厲害的頭銜，比如 Grady Booch 當時就是 Rational 的 Chief Scientist。

更有趣的是，ThoughtWorks 允許每個人自定義自己的職稱——但我不能。我不能叫“Flagpole”“Battering Ram”或者我最喜歡的 Loudmouth，只能用“Chief Scientist”。

主持人：ThoughtWorks 每半年會發布一次技術雷達（Technology Radar），具體是如何制作這份技術雷達的？為什么它總能緊跟行業潮流？

Martin：這說來話長，技術雷達最早能追溯到十多年前。ThoughtWorks 一直就很看重讓一線技術人員、實操的同事參與到公司運營里，我們的前 CTO Rebecca Parsons 就一直推動者這個里面。她上任之后，專門成立了一個技術顧問委員會，初衷是能及時掌握各個項目的一線進展。委員會成員每年會碰面兩三次，給她匯報工作情況。當時她讓我加入這個委員會，更多是我是公司對外形象的代表。

最開始的時候，我們就是湊一塊兒聊聊各個項目的近況。后來有一次開會，她的技術助理 Daryl Smith 提了個問題：公司當時就有好幾千個項目了，但技術信息在內部流轉得太慢，得搞個機制來共享技術趨勢。畢竟跟很多公司一樣，咱們也面臨好想法沒法大范圍傳播的問題，那會兒才幾千人都這樣，現在公司都擴張到一萬人了，這問題就更明顯了。我們覺得這個想法很好，Daryl Smith 提出了雷達隱喻和現在看到的雷達象限的概念，我們開了個短會，并制作出了第一份技術雷達。

我們本來是內部用的，但 ThoughtWorks 一貫的文化是：能公開就公開，能開源就開源。這也是我喜歡 ThoughtWorks 的原因：愿意分享我們所做的一切，甚至是核心經驗。發布之后行業反響很好，我們就一直堅持做到了今天。

這么些年下來，技術雷達的制作流程也有不少變化。最開始參會的大多是直接做項目、給客戶提供咨詢的一線人員，但公司規模后來擴大了十倍，再按老辦法來就越來越難推進了。于是我們就建立了更規范的流程。

現在任何人都能提交“亮點”（也就是雷達上的技術條目），這些提名會分給專人對接，這些負責人可能是按地域、業務線或者技術領域來劃分的，提名者給他們介紹這項技術的情況。之后，這些信息會匯總到現在叫 Doppler 小組的成員那里，我們開會逐條討論這些亮點，再決定哪些能納入雷達。這完全是個自下而上的過程，一般會前一兩個月就開始收集亮點，一步步篩選，最后再集中討論敲定。

對我來說，這個過程還挺特別的，我現在已經不怎么參與日常工作了，好多新技術都不太了解，但聽他們討論特別有意思，偶爾還能從中察覺到一些行業趨勢。就比如大概十年前的微服務，就是通過這個雷達流程被關注到的，后來我們還和 James Lewis 一起深入研究，寫了相關的專業內容。

它之所以能一直緊跟行業潮流，很大程度上是因為 ThoughtWorks 的很多業務本身就會涉及當下最火的技術話題，比如人工智能和大語言模型，我們也會持續關注這些技術在實際場景里的應用效果。

2 技術變革對比：AI 與匯編到高級語言的轉變

主持人：在科技領域，您覺得有哪些變革能在影響程度上與 AI 相媲美？

Martin：就我個人經歷來說，AI 是影響最大的一次。如果回顧整個軟件開發歷程，相似的轉折點當數從匯編語言向首批高級語言的轉變——那時候我才剛剛入行，也是業界剛剛發布 Cobol、FORTRAN 等語言的階段。我覺得這兩者可以相提并論。

主持人：你職業早期用過 Fortran，那時周圍應該還有不少人在寫匯編。你從他們那里感受到的“代際轉變”是什么？在思維方式、工作方法上有什么不一樣？

Martin：當時確實還有一些匯編語言的工作。匯編的指令是緊貼硬件的，而且每顆芯片的指令都不一樣，寄存器、內存訪問方式也不同。哪怕是做點最基本的事情，都需要寫一堆復雜的底層操作。

我在大學學過一點匯編，說實話，非常有幫助——因為學過之后我再也不想碰它了（笑）。即便是功能有限的 Fortran，我至少可以寫條件判斷、寫循環，雖然 Fortran 最早版本連 if 里都不能寫代碼塊，只能寫一句話，再配合大量 goto，但反正還是比純匯編強得多。

更重要的是，用 Fortran 寫程序時，我開始能脫離具體硬件，開始以更抽象的方式思考問題。代碼能在不同機器之間遷移，我不必再死盯著芯片和寄存器。這種“從硬件到抽象”的轉變，是非常重大的。

Q：你把現在的大模型變化比作從匯編到高級語言的變化，但又說更大的變化不是抽象層級提高，而是從“確定性”走向“非確定性”。能解釋一下嗎？

A：是的，大模型當然提升了一點抽象層級，但遠不如另一件事重要，那就是從確定性計算，轉向非確定性計算。

傳統軟件都是確定性的：輸入一樣，輸出一定相同。但大模型是非確定性的：同樣的輸入，每次可能都會給出不同答案。這種思維方式的轉變，比抽象層級變化更大，也更顛覆。現在我們面對的是一個非確定性的環境，這完全改變了我們的工作方式。

主持人：有看法是，編程領域有三個層次：匯編語言需要深入了解硬件；高級編程語言（比如 C、Java、JavaScript）不需要了解硬件，只需關注邏輯；而現在有了新的層次，就是用自然語言生成代碼。你似乎不認為這只是抽象層次的提升，為什么這么想？

Martin：我承認人工智能確實帶來了一些抽象層次的提升，但這并不是最核心的變化，最核心的還是確定性到非確定性的轉變。

高級語言的一個關鍵優勢是能夠在語言內部創建自己的抽象，這一點非常重要。比如面向對象編程和更具表達力的函數式語言（如 Lisp），都提供了強大的抽象工具。Fortran 和 Cobol 雖然也能創建一些抽象，但現代語言的抽象能力要強大得多。創建抽象的能力至關重要，你可以在語言中構建基本模塊，這也是后來領域驅動設計等理念能夠實現的基礎。

Lisp 中有句名言：“你應該用 Lisp 創建自己的語言，然后用這個語言解決問題。”我認為這種思維方式適用于任何編程語言：既要解決問題，也要創建一種能夠描述問題的語言。如果能平衡好這兩點，就能寫出易于維護和擴展的代碼。

人工智能在一定程度上幫助我們更輕松、更靈活地構建抽象，但問題在于，這些抽象的實現是非確定性的，這給我們帶來了新的挑戰，我們需要學習一套新的方法來應對這種情況。

我的同事 Unmesh Joshi 在這方面有一些很棒的想法，他一直在探索如何利用大模型共同構建抽象，然后再利用這些抽象更有效地與大模型溝通，我覺得這種思路非常有趣。

我曾在一本書中看到過一個例子：如果你用純英文向大模型描述大量國際象棋比賽，它并不能真正學會下棋；但如果你用國際象棋記譜法來描述這些比賽，它就能學會。這很有意思，顯然，記譜法不僅減少了 token 數量，還提供了一種更嚴謹的問題描述方式。

這或許是我們使用大模型的一個方向：找到一種嚴謹的表達方式，才能更好地發揮它的作用。這與領域驅動設計中的通用語言，以及我十幾年前研究的領域特定語言和語言工作臺有很多相似之處，我覺得這方面的發展前景非常值得期待。

主持人：這是不是軟件工程領域第一次出現如此廣泛應用的非確定性工具？這是一種全新的思維方式嗎？

Martin：你說得對，這只一種全新的思維方式。很多工程領域都會考慮“容差”。我太太是做結構工程的，她每次算結構承載都會問自己：“我要預留多少安全余量？”我們在 AI 時代也需要類似的思維：我們要接受系統本身的不確定性，不能把架構和邏輯壓得太極致，否則某天可能就會“橋塌了”。特別是在安全領域，我幾乎可以預見未來會發生一些大的“撞車事故”，因為人們低估了 AI 的非確定性。

主持人：有沒有一些新的工作流程或軟件工程方法，是借助語言模型實現的，或者至少是可以嘗試，而這些在過去使用確定性工具時是不可能實現的？

Martin：有兩個方向非常明顯。首先是快速原型開發。現在做一個原型可能只需要幾天，這在過去是不可想象的，這也就是所謂的“氛圍編碼”。但不僅是“快速寫個 Demo”，更重要的是我們可以在很短時間內“試錯”，可以探索一些之前因為成本太高而不會去探索的想法，而且非開發者也能快速做工具。 只要使用得當，這是一種巨大的價值。

其次，理解遺留系統。我的同事在過去一兩年做了很多這方面工作，他們把遺留系統的代碼做語義分析，然后導入圖數據庫，再以類似 RAG 的方式，通過查詢圖數據庫來了解數據在程序中的流向、哪些代碼會影響這些數據等情況。這種方法非常有效。我們甚至把“用大模型理解遺留系統”放進了 ThoughtWorks 技術雷達的“強烈建議采用”一欄，那是最少、最重要的類別，說明我們在真實項目中得到的成果很不錯。

這對 ThoughtWorks 來說也很有意義，因為我們經常需要做處理遺留系統的現代化。很多大公司都面臨遺留系統的問題，員工流動也會導致知識流失，生成式 AI 至少能幫助獲得一些進展，這總比毫無進展要好。

主持人：除了這兩個方向，還有哪些應用正在探索？

Martin：還有一些領域我們還在探索中。比如，如何與大模型一對一協作構建高質量的軟件。我們發現，關鍵是要采用小步快跑的方式，將每個任務分解成很小的模塊，把每個模塊的輸出都當作一個“不太可信但非常高產的合作者”提交的 PR，必須仔細審查每一部分。如果使用得當，確實能提高工作效率，雖然可能沒有那么夸張，但確實非常顯著，值得我們學習如何利用它。

我們知道大模型能幫助我們理解遺留代碼，但它能安全地修改遺留代碼嗎？這是一個未知的問題。我最近和 James Lewis 聊過，他用 Cursor 嘗試在一個不算大的程序中修改一個類的名字，結果花了一個半小時，還消耗了他每月 10% 的令牌配額。而在 IDE 中，這種重構功能已經存在了很長時間，比如 20 年前 JetBrains 的 ReSharper 插件就能實現類名和變量名的批量修改，當時人們愿意每年花 200 美元購買這個插件。蘋果的 Xcode 在 Swift 剛推出時沒有重構功能，還引起了開發者的不滿。這說明有些問題我們早就解決了，而大模型在這方面的表現并不理想，效率很低。

另外一個懸而未決的問題是團隊協作場景。大多數軟件都是由團隊開發的，未來也依然如此：即使人工智能能將生產力提升一個數量級，我們仍然需要 10 個人來完成以前 100 個人的工作，而且軟件的需求一直在增長，沒有下降的跡象，所以團隊協作是不可避免的。問題是，如何在團隊環境中有效利用 AI，這一點我們還在探索中。總的來說，目前我們有一些答案，也有很多問題有待解決，這是一個非常令人興奮的時代。

3 氛圍編程

主持人：那您如何理解和看待“氛圍編程”這個新興概念？

Martin：對于“氛圍編程”這個術語，我更傾向于回歸其本義，即不再關注實際生成的代碼。在氛圍編程中，產出的代碼已經不再重要，用戶對于編程也很可能毫無概念，只將其當作自動生成的產物。在我看來，這種方式適合探索性嘗試，即開發那種一次性、即拋性質的東西。但千萬別用它制作任何需要長期維護的成果，那就太魯莽了。

前幾天我和同事就嘗試制作一份隨時間變化的偽圖表，他對曲線性質做出描述，想讓大模型幫忙生成。他把結果提交到代碼庫后，我看著覺得效果勉強能接受，但還需要稍微調整一下，就是把標簽和相應曲線的間距縮小點。于是，我打開大模型生成的 SVG 文件，天哪，簡直令人震驚。我之前用 SVG 寫過的很多功能只需要十幾行，但這次生成的代碼卻復雜得離譜，令人瞠目結舌。

這就是氛圍編程的最大弊端：沒人知道最終生成的代碼是什么樣子，也幾乎無法進一步調整，最好的辦法就是丟掉重來，祈禱大模型下次能生成我們想要的東西。

另外還有個關鍵區別，這也是我跟同事討論得出的核心觀點：在用這種方式進行快速編程時，實際上剝離了學習這個重要環節。

我們認為，絕大多數工作模式的本質都是先構思創意，而后在計算機上反復驗證，這就形成了計算機輸出與思維構想間的持續交互，也就是學習循環的程序化過程。這個過程無法被捷徑取代，大模型草草掠過的各個環節根本沒辦法成為我們的學習素材。當你不學習時，就不知道如何微調、修改和擴展生成的代碼，只能徹底拋棄重新開始。

主持人：現在很多公司都在采用這些工具，導致需要審查的代碼越來越多，他們都在困惑如何在代碼審查時保持嚴謹。你有沒有看到一些有前景的方法，能幫助經驗不足和經驗豐富的工程師在使用這些工具時繼續學習？

Martin：沒有太多。我一直關注 Unmesh 在這方面的探索。他的核心思路是構建一種適合跟大模型直接對話的語言，通過這種協作方式建立起更精準、更細致的表達方式，從而清晰傳達我們的需求。我認為這種方法確實很有前景，甚至比其他方案更具潛力。

但要不要創建這種專屬語言，實際上又引出了另一個議題，就是大模型在“理解陌生環境”方面的作用。我和 James Lewis 聊過，他最近在 Mac 上用 Godot 游戲引擎開發，使用的是他不太熟悉的 C 語言。借助大模型，他能夠快速學習相關知識，嘗試各種功能。我自己也有過類似的經歷，比如在 R 語言中做一些已經做過很多次的操作，但就是記不住方法，就會向大模型求助。這種在陌生環境下快速獲取幫助，支撐探索性工作，進而幫助我們駕馭陌生 API 和編程理念的能力真的非常重要。

主持人：這讓我想到十多年前 Stack Overflow 的出現，那是行業內一次重大的生產力提升，我們可以直接復制代碼片段使用。很多年輕人和經驗不足的開發者（包括我自己）都會直接復制代碼嘗試運行，而經驗豐富的工程師會告訴他們，即使代碼能運行，也要先理解原理，要閱讀代碼。我覺得我們現在似乎又回到了類似的階段，很多人在盲目使用大模型生成的代碼。比如曾經有一個關于電子郵件驗證的熱門答案并不完全正確，但很多開發者都在使用它。你覺得這兩者有相似之處嗎？

Martin：確實有相似之處，但規模要大得多，相當于“升級版”。現在的問題是，有了 AI 直接回答問題，未來誰還會寫 Stack Overflow 的答案呢？我并不反對直接使用大模型生成的代碼進行測試，但測試通過后，一定要理解它的工作原理，還要審視代碼結構是否合理，不要害怕重構。當然，最重要的是測試，任何能運行的代碼都需要有測試用例，而且在使用大模型的過程中，要不斷進行測試和迭代。

使用大模型時，測試的重要性

主持人：說到測試，你覺得在使用大模型時，測試有多重要？

Martin：測試非常重要。Simon Willis 在這方面有很多深入的研究，他一直強調測試的重要性，認為測試是讓這些工具發揮作用的關鍵。Bita 來自 ThoughtWorks，我們公司是一家非常推崇極限編程的公司，所以她也深受測試文化的影響，同樣認為測試至關重要。但語言模型在測試方面表現得并不好，比如它會告訴你“所有測試都已運行，沒有問題”，但你自己運行 npm test 時，卻會發現有五個失敗的用例。

不過我注意到，隨著 Cursor 等工具的發展，這種情況已經有了一些改善。但問題的核心還是非確定性：大模型有時會“撒謊”，這很奇怪。如果它是一個初級開發者，我可能會找人力資源部門談談。

我最近有過一次很奇怪的經歷：當時我在某個配置文件里剛剛添加了一個新的 JSON 數據塊，并在注釋中標記了添加日期，比如“10 月 2 日添加”、“11 月 1 日添加”等等。而在大模型幫助添加配置項時，我特意強調“請添加當前日期”，結果它直接復制了最后一次修改的日期。我說“這不是當前日期啊”，大模型卻說“真抱歉，馬上修正”，然后把結果改成了昨天的日期。

這件事讓我意識到，即使是最簡單的事情，大模型也可能出錯。這可能和使用的模型、模型的優化目標（比如令牌使用量）等因素有關。所以，專業人士在處理重要工作時，絕對不能信任大模型的輸出，必須遵循“不信任，要驗證”的原則。

主持人：在 ThoughtWorks 跟開發者和相關人士交流時，他們日常會在哪些領域應用大模型？剛剛我們提到了測試場景，此外還有原型設計，你有沒有觀察到逐漸步入主流的其他操作領域？

Martin：除了原型開發和遺留代碼理解，還有幾個領域也很常見。比如用它探索新的技術領域，甚至是新的業務領域。當然，對它在這些領域提供的信息，信任度要遠低于十年前的維基百科。另外，Burgita 正在探索的“規格開發”也很有意思：雖然大模型有其局限性，但如果我們能清晰地定義需求，給出詳細的規格說明，它就能在此基礎上進行迭代和擴展。

4 規格開發與瀑布開發的對比

主持人：你對這種“規格開發”有什么看法？我感覺有點似曾相識，因為你的職業生涯始于瀑布開發時代。你覺得這次的“規格開發”和瀑布開發有什么相似之處，又有什么不同？

Martin：要說跟瀑布模式的相似之處，就是人們同樣希望制定大量規范說明，但卻不太關注代碼本身。我認為關鍵在于要避免瀑布式開發中“先構建完整規范”的弊端。相反，應盡可能采用最低規范推進項目，再以構建功能→測試驗證→部署生產環境的循環持續推進。規范文檔并不是重點，而僅僅是支撐緊湊迭代循環與細分切片實踐的依托。這有點類似“規格驅動開發”，但核心是小步快跑、快速迭代。作為人類，必須全程參與其中，每次都要驗證結果，這一點至關重要。

有趣之處在于，它又回到了“構建領域語言”的思路上：我們能否設計出更嚴謹的規格說明語言，這和我之前提到的 Unmesh 的研究方向一致。本質上，這是利用大模型，以更靈活的方式構建和表達抽象，但這些抽象仍然不能脫離代碼庫，要遵循“通用語言”的原則：我們腦海中的語言、規格說明中的語言和代碼中的語言應該保持一致，名稱和結構要相互對應，只是我們的思維方式比代碼更靈活。

借助大模型，我們或許可以模糊這兩者之間的界限，這是一個很有前景的方向。這種方式的新穎之處在于，我們從未能夠如此近距離地用自然語言來表示代碼或業務邏輯。

主持人：確實，之前也有人嘗試過在編程中融入領域特定語言（DSL）的思想，比如用 Ruby 寫業務邏輯并展示給領域專家看，專家雖然不會寫，但能理解其中的內容，指出問題所在。你覺得大模型能在這方面取得更大的進展嗎？

Martin：是的，很多人都會將領域特定語言的思想融入編程中。這種思路類似于在編程語言之內構建領域特定語言，當然也可以在外部構建領域特定語言，比如在跟會計合作時，采取對方慣用的術語體系和表達方式。總之，我們的目標就是建立順暢的溝通渠道，讓非程序員至少能理解代碼內容、理解問題所在并提出修改建議。有些人已經在某些場景下實現了這個目標，大模型的出現，或許能讓這種方式得到更廣泛的應用。

主持人：這在企業中應該尤為重要吧？在大型企業中，軟件開發者只占員工總數的 10% 到 20%，還有會計、市場營銷等多個業務部門，他們都需要定制軟件，也清楚自己的需求。但歷史上，需要項目經理、技術專家等多個角色進行需求翻譯。你覺得大模型有沒有可能為雙方提供一個更便捷的溝通方式，或者至少是一個值得嘗試的方向？

Martin：其實這是我最熟悉的領域。你當然深諳科技巨頭和初創企業的運作模式，但其他常規業務企業則完全是另一回事，軟件開發者在其中的比例相當低，同時面對著極其復雜的業務流程，更別提必然存在的遺留系統問題。此外，還有法規約束、歷史包袱、因知識體系產生的特殊例外等狀況。

銀行領域就是典型：法規不斷更迭，機構本身忙著規避未來可能發生的事故，還有 VIP 客戶的特殊需求。更重要的是，這些業務單元各自遵循獨立的規則框架，而且體系本身比技術形成得還早，某些銀行的歷史已經超過了百年。要知道，銀行在軟件技術方面已經比大多數企業先進了。

我還和波士頓聯邦儲備銀行的人聊過，他們目前完全不能使用大模型，因為作為重要的政府金融機構，任何錯誤都可能帶來嚴重后果，所以必須極其謹慎。這讓我想到一句格言：要了解一個組織的軟件開發方式，就要看它的核心業務。

我曾參觀過波士頓聯邦儲備銀行的貨幣處理中心，我親眼看到匯來的紙幣被運進處理中心，經過清洗、清點等工序后重新分發。他們實施的管控措施極其嚴密，遠遠超乎想象。這種嚴謹的思維方式也會滲透到他們的軟件開發中，因為他們習慣了對每一個細節都保持高度警惕。

很多企業都是如此，比如航空公司非常重視安全，這種理念會影響他們的整個工作方式。這也是為什么不同類型的組織在技術使用上存在差異：初創公司要么剛拿到融資，要么沒有融資，沒有客戶可失去，他們毫無顧慮，唯一的追求就是緊跟最新潮流，因此他們熱衷嘗試前沿技術，常在現有技術基礎之上開發新的方案或者銷售工具，本質上是在靠打破規則來生存。而當企業逐漸積累下一定客戶之后，他們就會變得越來越謹慎；而五十年甚至七十年之后，當創始人離開、企業蛻變為大型機構時，風險承受度也自然不同。

主持人：我覺得大模型是近年來普及速度最快的技術之一。即使是聯邦儲備銀行這樣出于合理原因在技術采用上比較滯后的機構，也在評估它，這說明它已經無處不在了。你覺得大型企業和更靈活的公司在對待 AI 的態度和方法上最大的區別是什么？僅僅是謹慎程度不同，還是有其他特點？

Martin：任何大型企業需要記住的一點是，企業并非鐵板一塊。企業內部的不同部門差異很大，有些部門可能非常勇于嘗試新事物，而有些部門則極其保守。就像我當初在 Cheetum & Lightum 工作時，我所在的小團隊就一直在積極嘗試一些看似古怪的前沿事物。在任何大型組織中，你都能找到這樣的小團隊。所以很多時候，企業內部的差異比企業之間的差異還要大，這一點很重要。

5 關于“重構”

主持人：說到重構，大模型在這方面可謂造詣深厚。而你早在 1999 年就撰寫過《重構》一書，并在二十年后發布了第二版修訂。這本書非常詳盡且系統地梳理了各種代碼風格及其對應的重構技術，開篇第一頁就列出了重構清單。我特別喜歡這個設計，真不知道出版社是怎么排版的，但出來的效果真是驚艷。您在 1999 年時為什么決定要寫這本書？能不能帶我們回顧一下當時的時代背景，還有首版書籍產生的影響？

Martin：沒問題，我第一次接觸重構是在克萊斯勒公司，當時是跟 Kent Beck 合作。我還記得當時我們窩在旋律的酒店房間還有大堂那邊，他給我演示了如何重構一段 smalltalk 代碼。其實我自己就經常回頭修改自己寫過的代碼，也一直非常重視代碼的可理解性，這種好習慣覆蓋了從專業寫作到軟件編寫的整個歷程。但 Kent 想得更深，他采用微小步進的重構方式持續推進，憑借精妙的組合取得了驚人的效果，最終依托連續微調實現巨大改進。這種方法徹底顛覆了我的認知，也讓我為這個發現而著迷。但 Kent 當時正在全力撰寫另外一本編程白皮書，無暇分心于重構方面的專著，于是我決定接手這項工作。

早期探索重構時我也會認真記錄，而從中總結出的經驗和記錄下的步驟都成了《重構》一書中的具體操作指南。我為每個步驟都配上了示例，最終形成了第一版書稿。不過因為 smalltalk 當時已經日薄西山，所以我選擇用 Java 來實現。當時的 Java 被視為未來的版本答案，90 年代末的我們堅信未來只要有 Java 就足夠了。種種背景共同促成了這本書的誕生。至于影響嘛，我要再次強調——重構的概念也非 Kent 首創，而主要來自伊利諾伊大學香檳分校的 Ralph Johnson 團隊。他們用 smalltalk 語言開發了首款重構瀏覽器，這也是如今各類自動重構工具的雛形。

而最終真正引發執法的當數 JetBrains 團隊，他們將重構技術融入了 IntelliJ IDEA 的早期版本并非全力推進，終于讓自動化重構成為用戶可以仰仗的重要功能。當然，手動重構的能力依然重要，畢竟不是所有語言環境都有對應的重構工具可用。總之在此之后，重構成為流行術語，但也被濫用得相當離譜——有人用“重構”泛指一切程序修改，這顯然不準確。我們對重構有著極其嚴格的定義，必須只是微小的語義變更，強調在保持行為不變的前提下通過極其細微的步驟來實現。我一直認為雖然每個具體步驟看似微不足道，但在將它們串聯起來之后就能創造驚人的效果。

主持人：那你為什么會在二十年后的 2019 年發布《重構》的第二版？

Martin：主要是想更新書中的一些內容，補充一些新的想法。另外, 初版是九十年代末針對 Java 寫出來的，很多東西難免過時。雖然核心理念仍然可靠，但我覺得應該讓這本書更適應現代環境。而最大的難題就是，繼續使用 java 還是換一門語言？最終我決定轉向 JavaScript，這樣既能覆蓋更廣泛的讀者群體，又能擺脫過度面向對象的描述方式。所以，第二版中采取了提取函數、而非提取方法的思路，這是因為重構不會改變函數的本質。新版本中還引入了很多新的示例，希望能讓這本書再延續二十年的生命力。

主持人：那是一定的。這本二十多年前出版的行業著作，讓人們對于重構的認知發生了怎樣的變化？

Martin：這個不太好說，因為我的主要交流對象是 ThoughtWorks 的開發者，他們對這類技術肯定比普通開發者更熟悉。當然，我在網上看到過很多讓人無語的重構敘事，嚴重缺乏系統性和我最關注的可控性。相反，我追求的向來是高效快速的重構。這恰恰印證了“受約束的方法反而更高效”的道理，并且已經成為我們團隊內部的共識。

不過值得肯定的是，越來越的人討論重構，越來越多的工具支持重構，而且執行效率相當不錯。總之，我覺得我們確實取得了一定進展，雖然沒能完全達到預期，但我也沒什么可抱怨的。

主持人：AI 工具的發展讓快速生成海量代碼成為可能。面對代碼量激增的現實，你覺得重構思維在梳理底層設計意圖方面有多重要？這種重要性是不是已經有所體現？

Martin：目前還沒有看到明顯的跡象，但我肯定它的重要性會越來越高。畢竟隨著更多質量存疑但還能運行的代碼出現，重構將成為讓代碼既保持功能、又徐徐提升質量的理想途徑。現在這些工具還不能獨立完成重構，不過 Adam Tornhill 正在嘗試將大模型與其他工具結合，探索更有效的重構路徑，這種結合方式很有前景。重構的核心思維是把修改拆分成一系列微小且易于組合的步驟，這才是關鍵所在。將步驟的“小”和“可銜接性”結合起來，就能實現巨大的改進。

有趣的是，目前的重構還離不開 IDE 環境。最快捷的辦法要么是使用內置工具，要么手動調整代碼。而我發現在 Claude Code 等工具的命令行界面中描述操作時，耗費在解釋說明上的時間反而超過相當一部分手動修改。我不確定未來是否會出現更多集成方案，讓大模型能夠自動完成這些操作。但任何優質軟件都遵循這樣一條鐵律：當函數變得過于復雜、類越來越臃腫，則必須及時進行拆分和重組，否則后續維護將陷入困境。

另外，我也很期待能否出現工具控制接口，比如用大模型描述查詢語句來生成 SQL。很多用戶是不知道如何編寫 SQL 語句的，但只要把需求輸入到大模型里，它就能生成 SQL 代碼，再由用戶試運行來判斷效果對不對。重構也是類似的原理，通過快速嘗試幫助用戶取得進展。記得一年之前，某巨頭公司曾表示要推動大規模 API 改造與代碼清理項目，并嘗試使用某種大模型工具。最終情況是，大模型大概解決了 10% 的工作量，其余 90% 還是要靠其他工具。看似比例不高，但這種組合還是提供了額外杠桿，推動了工作進展。我覺得這類實踐還是很有趣的，就是以大模型為起點提供驅力，再觀察其上確定性工具的運作機制。這種交互模式中蘊含著獨特的價值。

主持人：從重構延伸到軟件架構，2002 年你曾出版《企業應用架構模式》一書，其中匯聚了 40 多種模式，包括懶加載、身份映射、模板視圖等。那時候我參加技術面試時，面試官們總會詢問我這些架構細節，這也讓軟件架構的概念風靡一時。但 2010 年代起，這一切似乎起了變化，如今我幾乎聽不到技術人員再討論模式或者架構了。你會如何看待這段時期及其產生的影響？為什么對軟件架構的討論如此重要，現在為什么大家不再關注了？

Martin：架構模式的意義在于構建一套術語體系，讓大家能更高效地溝通復雜問題。我深切地感受到，這些術語確實能夠促進溝通，讓人們不再往系統里繼續塞新規則，而是使用已有模式描述自己的備選方案并做出適用性權衡。當然，模式本身僅在特定場景下才有價值，因此必須要對相應的情境具備深刻理解。

遺憾的是，機構模式熱潮似乎已經消退，或許是有人說得太多太濫，把大家搞煩了。但模式這個概念本身的價值仍然存在，最近我與 Unmesh 合作編寫分布式系統設計模式的新書時，就能感受到這種用于描述核心要素的語言體系，會幫助我們更透徹地理解分布式系統的運作機制。

至于為什么它不再那么流行，我也說不好，或許未來會重新熱門起來。我一直致力于傳播知識、讓復雜事物變得易懂，而我確實覺得識別并創建精準的名詞來，是實現這一目標的有效方法。

主持人：我發現有些公司會廣泛使用架構模式，有些則完全不用，差異似乎和公司規模、態度有關。初創公司更傾向于從零開始，在白板上簡單畫個框或圈來表示架構，不糾結于嚴格的規則，就像 UML 曾經有嚴格的箭頭規范，甚至能生成代碼，但初創公司根本不關注這些，他們覺得不該被現有方式束縛，而且掌握這些模式需要學習成本和共同認知，這可能也是原因之一，或許還有代際差異？

Martin：確實是這樣。任何行業都需要簡化溝通的術語，總不能每次都從最基礎的原理開始解釋，所以人們自然會創造自己的行話。初創公司內部也會形成自己的架構溝通語言，只是這些語言沒有寫成書籍，只能在公司內部或有共同背景的人之間傳播。

Grady Booch 對這個問題有個很有意思的觀點，他認為架構模式在主流行業的熱度下降，和云計算的興起有關。那個時期，AWS、谷歌云等云服務提供商崛起，很多公司開始使用這些架構良好的云服務，比如 DynamoDB 或托管 PostgreSQL 服務，不用再自己從頭構建數據存儲等基礎組件，所以架構的重要性似乎被削弱了，大家更多是在組合使用這些現成的構建塊。但我覺得，使用這些云服務依然存在模式可循，只是我還沒深入研究這方面的內容。

其實每個公司都會給系統命名，不管是古怪的名字還是邏輯化的名字，內部溝通時都會圍繞這些名字展開，討論它們的功能、規模和關聯方式，這本質上也是一種行業用語。越是歷史悠久的公司，這種內部用語越根深蒂固，新人可能需要好幾年才能搞懂所有系統及其關聯。

主持人：多年之前我曾與美國運通的高層有過一次對話，當時他負責將公司系統重構為新一代架構。我問他這活已經做了多久了，他說三年。我驚訝地回道：“那現在進展到哪一步，快完成了吧？”他說：“沒有，還在規劃階段，但規劃工作快要收尾了。”當時我完全無法理解——整整三年還在做規劃？但隨著我對他們的業務規模、涉及的資金量還有遺留系統的數量有所了解后，才明白他很大一部分時間都在說服業務相關方。這種情況在多數企業中都會發生，除非是 2010 年之后創立的年輕公司，或者是數字 / 技術優先類的企業。而即便如此，這些尚未經歷轉型的企業在未來十年也會遇到類似的困境。

Martin：是的，我還記得曾跟某位加入傳統銀行的創業者聊天，他的任務是幫助銀行推動流程現代化。他感慨道，“入職三年之后，我才真正理解問題所在。我大概知道自己該做什么，但透徹把控這個新領域非常困難，它體量龐大、歷史悠久、極其復雜且缺乏邏輯。”

大型組織的系統復雜且不那么“邏輯化”，因為它們是人類逐步構建的，包含了各種歷史因素，比如不同時期的供應商選擇、人員變動帶來的決策變化等，這些都會慢慢積累成復雜的體系，任何大公司最終都可能面臨這種情況。

6 敏捷生涯

主持人：說起敏捷，你曾是參與制定《敏捷宣言》的 17 位元老之一，前面提到的 Kent Beck 也在其中。能不能回憶一下當時的情況？你們是怎么聚集在一起，宣言得到的反響如何？

Martin：那大概是在 2001 年，起源應該是 Kent 在一年之前主持的一場會議。敏捷宣言的制定者是一群從事極限編程的人員，我們在會上討論的核心議題是：極端編程到底只適用于 Kent 在白皮書中描述的狹窄范疇，還是可以拓展為更廣泛的主流實踐？Kent 最終選擇了后者，于是問題轉向我們該如何處理更廣泛的主流實踐與 Scrum 等方法的重疊部分。正是這些因素，讓我們萌生了召集不同立場的人士共同商議的構想。

當時大家還為會議地點爭論過，Alistair 想在猶他州，Dave Thomas 想在加勒比海的安圭拉島，最后定在了猶他州，不記得原因了，我們還一起滑雪。參與的人都是各方邀請來的，也有很多人受邀但沒來。我對會議的具體組織過程記憶不太深，Bob Martin 說我參與過芝加哥的一次午餐討論，我大概率是去了，但沒什么印象。至于會議本身，我記不清太多細節了，真后悔沒有把那幾天的詳細經歷記錄下來。

我隱約記得 Bob Martin 堅持要我做一份“宣言”。我當時對這樣的宣言沒有抱太大希望，覺得大概率無人理會，只要討論和創作得開心就夠了。但后來它竟然產生了些許影響，著實令我們震驚。但就像 Alistair Cockburn 說的：“你絕妙的想法要么被無視，要么被誤解，你別無選擇”，敏捷宣言大部分時間被濫用了。

主持人：宣言中列出的 12 條原則也助長了這種現象，很多人總會挑揀自己最認可、最想強調的部分。

Martin：是的，其實我們在宣言開往就聲明“仍在探索”，強調這應該是個持續進程，宣傳本身也只是對階段性成果的記錄。這些成果的來源，就是我們渴望以某種方式為 ThoughtWorks 客戶編寫軟件，但對方卻不愿意接受我們的工作方式。我們主張投入大量精力編寫測試代碼，推行專業化的構建流程，建立自動化構建體系等等。我們還希望能以小步迭代的方式推進工作。

但這些理念在當時簡直是大逆不道，因為當時客戶認為必須制定未來五年的宏大計劃：其中用兩年設計方案，再花一年左右來實現，最后才開始測試。這就是他們認定的正確流程，也確實是那時候的共識。但我們認為不對，我們希望只關注其中一部分需求，然后把整個流程壓縮到一個月內完成、甚至最好能在一周內完成。

主持人：現在企業客戶對敏捷的接受度是不是比二十多年前高多了？比如與客戶協作、增量交付、摒棄冗長的工作模式，這些是不是已經很普遍了？

Martin：我們確實取得了顯著進步，但和我們的愿景相比還有很大差距，我想其他還在世的“宣言”簽署者大概也會有同樣的感受。我們依然可以做得更好，只是進步速度比預期的慢。

主持人：敏捷理念的核心在于通過快速迭代實現漸進式改進，周期越短越好。但如今 AI 的普及讓客戶已經不愿等待漸進式改進，他們希望立即看到高質量成果。在這樣的背景下，你認為敏捷方法在 AI 領域仍能奏效嗎？未來的迭代周期會進一步縮短，還是說我們需要探索新的模式，比如在開發初期就聚焦質量保證，把 AI 的產出優勢轉化成卓越軟件產品？

Martin：AI 的未來尚不明朗，畢竟我們還處于早期發展階段。所以我仍然認為，以人類可審查的小片段形式構建產品才是最佳選擇。AI 當然有可能幫助我們加快這些片段的產出，或者兩袖清風能在每個片段中實現更多功能，但我更傾向于增強片段的迭代頻率。這就是通過加速流程循環來實現效率提升。我向來認為，最大的進步一定來源于：尋求提速途徑，審視工作環節，從海口尋找阻滯點并設法消除。我曾與頂尖 AI 實驗室探討過他們的實踐方式。

以 Anthropic 的 Claude Code 團隊為例，他們就在兩天之內并行構建并測試了 20 種不同的原型，收集反饋并敲定了最終方案。現在有了大模型，他們可以通過提示詞和輸出結果并行構建起 20 個真正運行在系統中的原型。AI 在本質上仍然是在加快迭代頻率，其中很多原型直接被丟棄了，余下比較好的會逐步開放給小團隊和大團隊。總之，我們還遠沒有觸及快速驗證的極限，反饋周期和信息獲取的效率仍有提高的空間。

7 如何掌握 AI

主持人：說到學習和保持領先認知，你是如何掌握 AI 發展趨勢的？你和同事們會用哪些方式來保持對行業動態的關注？

Martin：我最近主要通過編輯工作來獲取優質內容。我會替網站篩選高水平文章，并借此機會了解各種趨勢和想法。老實講，我已經很久沒做生產開發了，近期唯一編寫的生產代碼就是網站運行代碼。對我來說，跟一線開發的同行們合作，幫助他們將理念和經驗傳遞給更多人才是更適合自己的工作內容。而這種將他人理念轉化為文字的過程，對應一種非常獨特的學習體驗，也成為目前我最喜歡的學習方式。雖然偶爾也會抽空做些實驗，但我始終將這種合作式學習置于優先級首位。

另外，我會關注一些可靠的信息來源，比如 Bita（和我合作過）、Simon Willis（他的產出效率很高，我很佩服），還有 Kent，我的很多職業生涯都受益于他的想法，現在也依然如此。有時候，我也會通過新出的書獲取靈感，偶爾甚至會看視頻。但老實講，我真的超討厭看視頻。

主持人：你如何判斷一個信息來源是否可靠？尤其是在當下這個信息繁雜、難以分辨真假的環境中。

Martin：我覺得整個行業乃至整個世界都處于認識論的危機當中，人們越來越難以理解世界的真相。這是個宏大的話題，總結一下，我的核心標準是：要以坦誠的態度面對不確定性。因此相較于“我很肯定就是這樣”，我覺得“這只是我目前的理解，且不敢斷定”的態度更值得欣賞。

記得早期寫關于軟件架構的書時，我曾瘋狂尋找微軟陣營的文獻支持，畢竟 Java 這邊的文獻浩如煙海，但那會微軟陣營則鮮有著作。后來我看到了瑞典技術作家 Jimmy Nilsson 寫的書，他始終用“這只是我目前的理解，且不敢斷定”這種審慎的態度討論問題，給我留下了深刻印象。后來我們成了好朋友，而且我很清楚地知道，正是他這份既明確表達當下感受、也承認情況隨時可能改變的立場，讓他成為我眼中真正值得信賴的人。他會更熱衷于探究細節上的差異，據此確定“這套方案適用于特定場景”，而不像很多大嘴巴那樣宣稱“永遠別碰微服務”或者“必須無腦上微服務”。

這些經歷再次證明，權衡取舍才是軟件工程中的永恒母題。比如最常見的“還要多久”的問題，答案永遠是“具體要看……”——要看是否構建原型、要看技術掌握程度等。所以參考資料中那些“在我的案例中”，就是作者希望你能知曉的具體情境。只有這樣，方案的成功或者失敗才能在未來轉化為可參考的經驗。畢竟在一家歷史悠久、受到高度監管的零售企業擔任軟件工程師，跟在初創公司里自由發揮的開發經歷根本就不是一回事。

別嫌我啰嗦，很多客戶都會要求我們提供現成的解決方案，想得到一份可以粗暴照搬的“食譜”。千萬別執著于這種標準答案，任何聲稱存在標準答案的家伙要么是蠢、要么是壞。

給初級工程師的建議

主持人：有觀眾線上提問說，面對當前 AI 浪潮席卷行業的情況，新手軟件工程師們如果過度依賴 AI 會不會阻礙自己的成長進程？比如說有位新手工程師，希望能逐步成長為資深工程師，那到底該采取哪些策略？要不要刻意避免使用 AI 工具？

Martin：我們當然應該多用 AI 工具并探索其適用場景。但對新手工程師來講，最難的地方在于大家缺乏判斷力：大模型給我的輸出結果到底可不可靠？在這個時候，最好找位優秀的資深工程師擔任導師，這永遠是掌握開發技能的最佳途徑。

我自己就很幸運，不光在職業生涯早期遇到了 Jim Odell，還有被我視為導師的同齡人 Kent Beck，因為他的思維總是領先我一步。總之，認真尋找自己的領路人。AI 雖然方便，但它容易出錯并誤導我們。記得在提問時多深入探究，比如為什么給出這樣的建議、依據是什么？不光是對 AI，對人也是如此。要搞清楚對方怎么得出的結論、所處的情境是什么樣。

主持人：那面對當前大模型掀起的變革浪潮，你會如何看待科技行業的整體發展？

Martin：從宏觀角度講，我持樂觀態度，技術與軟件領域仍有巨大的潛力可挖。我們仍處于需求量高于想象力極限的階段。當然，這是長遠視角下的結論，短期內的生活則處于一種相當怪異的階段。

全球經濟正陷入嚴重衰退，大規模裁員潮襲來，據說消失的崗位數量達到 25 萬至 50 萬之巨。這種現象在 ThoughtWorks 也有體現：我們曾保持著年均 20% 的增長執行，但從 2021 年以來我們開始遭遇瓶頸，客戶明顯縮減了相關支出。AI 領域雖然一枝獨秀地保持發展，但也形成了極其恐怖的價值泡沫，我們不知道它還能脹多大、什么時候會爆。

不過，我可以肯定地講，AI 確實具有價值，這跟之前的區塊鏈和加密貨幣不一樣。至于 AI 技術中蘊藏著多大的機遇，這個我說不好。我親歷過九十年代和 2000 年初的互聯網技術周期，如今是當時的重演，只不過規模擴大了十倍。所有這些都在發生，但真正沖擊我們的并不是 AI，而是零利率時代的終結。失業潮早在 AI 興起之前就因為零利率政策的結束而爆發，我們也無法預知這樣的宏觀經濟變局會通向何方。

巨大的不確定性讓企業不愿投資，軟件行業自然難以取得實質性進展。于是，我們陷入了奇特的矛盾境地：軟件行業拿不到應有的投入，AI 領域卻形成大到畸形的泡沫。現在的情況就是，跟 AI 沾邊的企業都活得還可以，但初創公司或者非 AI 領域的企業則舉步維艱。但我還是覺得這個行業擁有巨大潛力，值得進入。雖然現在的時機不如 2005 年，但作為職業選擇肯定還是優質的。

我覺得 AI 不會徹底取代軟件開發，它更像是匯編語言向著高級語言的轉變，在顯而易見的變革下仍然保留了核心技能的價值。在我看來，優秀軟件開發者最重要的能力并不是編寫代碼，而是明白哪些東西有寫出來的價值——這本質上是一種溝通能力。誰能掌握這種溝通能力，誰才會成為最強的專家型通才。

其實這個問題并不新鮮啦，很多人都在關注：怎樣才能成為杰出的軟件工程師？但答案似乎從來沒變過，關鍵是好奇心、對深度的鉆研和對廣度的拓展。但更重要的是，要掌握良好的溝通能力——能夠高效協作的人，才有機會成為頂尖開發者。這一點在企業領域體現得尤其突出。因為我們編寫的軟件和服務對象所從事的，是跟我們完全不同的工作。記得在醫療系統工作時，我就常說：我對醫療概念建模和醫療流程的理解很深，但完全不知道該怎么看病。那我的理解是怎么來的？當然是跟醫生交流得來的，他們也得參與整個流程。

快問快答

主持人：你最喜歡的編程語言是什么？

Martin：我目前最喜歡的 Ruby，因為我最熟悉、用得也很久。但最早讓我癡迷的無疑是 smalltalk，九十年代用它編程時的那種樂趣簡直無可比擬。

主持人：那能不能給大家推薦幾本書？

Martin：第一本是 Daniel Kahneman 的《思考，快與慢》。它能幫助讀者建立起對數字的直覺，并揭示出我們在概率和統計思維中常犯的各種謬誤。這種能力在軟件開發中至關重要，畢竟我們的工作成效很大程度上取決于能否理解所見事物的統計效應。現在很多學校更關注微積分，但我真心覺得如果能更側重統計學知識就好了。我特別喜歡玩桌游，就是因為這種游戲要求玩家隨時進行概率判斷。而這本書正是入門此道的絕佳途徑，堪稱我近年來讀過的最棒書籍之一。

另一本讓我著迷的書叫《權力掮客》，講述了 Robert Moses 這位鮮為人知的紐約巨頭在 1920 至 1960 這近四十年間，如何掌控紐約市大權。他從未通過選舉上任，卻支配著比市長和州長更龐大的資金。全書剖析了他如何一步步成長為權勢滔天的幕后操盤手。更妙的是，這本書文筆極佳、引人入勝。我在讀的時候經常會翻回上一個段落再次體驗，舍不得就這么跨過那段彌足珍貴的文字。雖然這本書有 1200 頁厚，但卻是本讓我讀得如此沉醉、絲毫不覺冗長的巨著。

我認為要想理解當今世界的運行邏輯，這類著作有著無可替代的價值。

主持人：最后能不能給大家推薦款桌游？

Martin：這個就有點為難了，就像有人要求推薦部電影一樣。桌游類型豐富，差別巨大。但如果非要選一款門檻不高又具有深度的作品，那我會推薦《Concordia》。這是一款規則不難，過程中又蘊含豐富決策空間的抽象策略類桌游。

https://www.youtube.com/watch?v=CQmI4XKTa0U

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

AI 重塑組織的浪潮已至，Agentic 企業時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。

把握行業變革關鍵節點，12 月 19 日 - 20 日，AICon 全球人工智能開發與應用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。