編譯 | 褚杏娟、核子可樂

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

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

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

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

我們翻譯了這次采訪，并在不改變?cè)饣A(chǔ)上進(jìn)行了刪減，以饗讀者。

1 個(gè)人成長歷程

進(jìn)入軟件工程領(lǐng)域

主持人：能和我們說說你是如何進(jìn)入軟件開發(fā)領(lǐng)域的嗎？畢竟這已經(jīng)是幾十年前的事了。

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

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

主持人：那時(shí)候互聯(lián)網(wǎng)還沒興起，當(dāng)時(shí)能找到什么樣的工作？你的第一份工作是什么？

Martin：我第一份工作是在 Coopers & Lybrand 這家咨詢公司。我所在的小組是做信息戰(zhàn)略咨詢的，但我的工作不一樣，因?yàn)槲掖髮W(xué)學(xué)過 Unix，是公司里少數(shù)懂 Unix 的人之一，所以我主要負(fù)責(zé)維護(hù)一批工作站，這些機(jī)子是用來跑他們做戰(zhàn)略工作的一款專用軟件的。

后來我慢慢對(duì)他們的戰(zhàn)略工作也感興趣了，就慢慢涉獵其中?，F(xiàn)在回頭想想，當(dāng)時(shí)不少東西其實(shí)都挺華而不實(shí)的，但這確實(shí)是我入行的契機(jī)，還讓我很早就接觸到了面向?qū)ο蟮乃季S，對(duì)我后來的發(fā)展很有幫助。

主持人：你是如何接觸到面向?qū)ο缶幊痰?？要知道在?dāng)時(shí)，面向?qū)ο缶幊炭墒呛芮把氐臇|西，而你所在的咨詢公司似乎并不是最前沿的那種。

Martin：雖說我們公司整體其實(shí)不算多前沿，但我待的小組卻在在做一些前前沿的事兒。那會(huì)兒我們碰到一個(gè)人，這人滿腦子都是新奇想法，其中不乏一些特別亮眼的觀點(diǎn)，當(dāng)然也有一些略顯瘋狂的想法。他還特意用“面向?qū)ο蟆边@個(gè)專業(yè)術(shù)語來包裝這些想法，雖說當(dāng)時(shí)那些內(nèi)容和真正的面向?qū)ο罄砟钇鋵?shí)沒完全對(duì)上，也算之前說的那種華而不實(shí)的東西之一，但平心而論，他的不少想法確實(shí)很有價(jià)值。

也正因?yàn)檫@個(gè)契機(jī)，我才開始往這個(gè)方向深耕，后來也慢慢摸清了面向?qū)ο缶幊痰恼嬲齼?nèi)核，直接奠定了我之后十幾年的職業(yè)基礎(chǔ)。

加入 ThoughtWorks

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

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

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

整個(gè) 90 年代，我做獨(dú)立顧問做得風(fēng)生水起，期間還寫了我的第一本書。后來我參與了 Chrysler 的 C3 項(xiàng)目，與 Kent Beck 一起工作，親眼見證了極限編程（XP）和敏捷方法論的誕生。1993 年我搬到了美國，生活也過得很愉快。90 年代末互聯(lián)網(wǎng)騰飛，行業(yè)非?；钴S。就在這期間，我開始接觸 ThoughtWorks。

最初它只是我的客戶。當(dāng)時(shí)他們?cè)谧鲆粋€(gè)大項(xiàng)目，大約 100 人，規(guī)模不小，但看起來馬上要“炸掉”了。我?guī)退麄兪崂韱栴}、止住下滑，最終也確實(shí)把項(xiàng)目救了回來。之后，他們向我發(fā)出了加入的邀請(qǐng)。

ThoughtWorks 有個(gè)很獨(dú)特的氣質(zhì)：他們從不說“這很難，所以做不了”，他們會(huì)說“這確實(shí)很難，但我們可以試試”，而且往往還能真的把事情做成。正是這種精神吸引了我。我當(dāng)時(shí)想：加入他們一兩年也不錯(cuò)。結(jié)果沒想到，這一待，就是 25 年。

主持人：你加入 ThoughtWorks 后，十多年來一直擔(dān)任首席科學(xué)家一職，這個(gè)職位具體負(fù)責(zé)什么工作？

Martin：說實(shí)話，我不是任何人的“Chief”，而且我也不做任何科學(xué)研究。這個(gè)頭銜主要是“對(duì)外發(fā)聲”的角色，當(dāng)時(shí)業(yè)界流行給思想領(lǐng)袖一個(gè)這樣聽上去很厲害的頭銜，比如 Grady Booch 當(dāng)時(shí)就是 Rational 的 Chief Scientist。

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

主持人：ThoughtWorks 每半年會(huì)發(fā)布一次技術(shù)雷達(dá)（Technology Radar），具體是如何制作這份技術(shù)雷達(dá)的？為什么它總能緊跟行業(yè)潮流？

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

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

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

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

現(xiàn)在任何人都能提交“亮點(diǎn)”（也就是雷達(dá)上的技術(shù)條目），這些提名會(huì)分給專人對(duì)接，這些負(fù)責(zé)人可能是按地域、業(yè)務(wù)線或者技術(shù)領(lǐng)域來劃分的，提名者給他們介紹這項(xiàng)技術(shù)的情況。之后，這些信息會(huì)匯總到現(xiàn)在叫 Doppler 小組的成員那里，我們開會(huì)逐條討論這些亮點(diǎn)，再?zèng)Q定哪些能納入雷達(dá)。這完全是個(gè)自下而上的過程，一般會(huì)前一兩個(gè)月就開始收集亮點(diǎn)，一步步篩選，最后再集中討論敲定。

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

它之所以能一直緊跟行業(yè)潮流，很大程度上是因?yàn)?ThoughtWorks 的很多業(yè)務(wù)本身就會(huì)涉及當(dāng)下最火的技術(shù)話題，比如人工智能和大語言模型，我們也會(huì)持續(xù)關(guān)注這些技術(shù)在實(shí)際場景里的應(yīng)用效果。

2 技術(shù)變革對(duì)比：AI 與匯編到高級(jí)語言的轉(zhuǎn)變

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

Martin：就我個(gè)人經(jīng)歷來說，AI 是影響最大的一次。如果回顧整個(gè)軟件開發(fā)歷程，相似的轉(zhuǎn)折點(diǎn)當(dāng)數(shù)從匯編語言向首批高級(jí)語言的轉(zhuǎn)變——那時(shí)候我才剛剛?cè)胄?，也是業(yè)界剛剛發(fā)布 Cobol、FORTRAN 等語言的階段。我覺得這兩者可以相提并論。

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

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

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

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

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

A：是的，大模型當(dāng)然提升了一點(diǎn)抽象層級(jí)，但遠(yuǎn)不如另一件事重要，那就是從確定性計(jì)算，轉(zhuǎn)向非確定性計(jì)算。

傳統(tǒng)軟件都是確定性的：輸入一樣，輸出一定相同。但大模型是非確定性的：同樣的輸入，每次可能都會(huì)給出不同答案。這種思維方式的轉(zhuǎn)變，比抽象層級(jí)變化更大，也更顛覆?，F(xiàn)在我們面對(duì)的是一個(gè)非確定性的環(huán)境，這完全改變了我們的工作方式。

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

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

高級(jí)語言的一個(gè)關(guān)鍵優(yōu)勢(shì)是能夠在語言內(nèi)部創(chuàng)建自己的抽象，這一點(diǎn)非常重要。比如面向?qū)ο缶幊毯透弑磉_(dá)力的函數(shù)式語言（如 Lisp），都提供了強(qiáng)大的抽象工具。Fortran 和 Cobol 雖然也能創(chuàng)建一些抽象，但現(xiàn)代語言的抽象能力要強(qiáng)大得多。創(chuàng)建抽象的能力至關(guān)重要，你可以在語言中構(gòu)建基本模塊，這也是后來領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)等理念能夠?qū)崿F(xiàn)的基礎(chǔ)。

Lisp 中有句名言：“你應(yīng)該用 Lisp 創(chuàng)建自己的語言，然后用這個(gè)語言解決問題?！蔽艺J(rèn)為這種思維方式適用于任何編程語言：既要解決問題，也要?jiǎng)?chuàng)建一種能夠描述問題的語言。如果能平衡好這兩點(diǎn)，就能寫出易于維護(hù)和擴(kuò)展的代碼。

人工智能在一定程度上幫助我們更輕松、更靈活地構(gòu)建抽象，但問題在于，這些抽象的實(shí)現(xiàn)是非確定性的，這給我們帶來了新的挑戰(zhàn)，我們需要學(xué)習(xí)一套新的方法來應(yīng)對(duì)這種情況。

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

我曾在一本書中看到過一個(gè)例子：如果你用純英文向大模型描述大量國際象棋比賽，它并不能真正學(xué)會(huì)下棋；但如果你用國際象棋記譜法來描述這些比賽，它就能學(xué)會(huì)。這很有意思，顯然，記譜法不僅減少了 token 數(shù)量，還提供了一種更嚴(yán)謹(jǐn)?shù)膯栴}描述方式。

這或許是我們使用大模型的一個(gè)方向：找到一種嚴(yán)謹(jǐn)?shù)谋磉_(dá)方式，才能更好地發(fā)揮它的作用。這與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的通用語言，以及我十幾年前研究的領(lǐng)域特定語言和語言工作臺(tái)有很多相似之處，我覺得這方面的發(fā)展前景非常值得期待。

主持人：這是不是軟件工程領(lǐng)域第一次出現(xiàn)如此廣泛應(yīng)用的非確定性工具？這是一種全新的思維方式嗎？

Martin：你說得對(duì)，這只一種全新的思維方式。很多工程領(lǐng)域都會(huì)考慮“容差”。我太太是做結(jié)構(gòu)工程的，她每次算結(jié)構(gòu)承載都會(huì)問自己：“我要預(yù)留多少安全余量？”我們?cè)?AI 時(shí)代也需要類似的思維：我們要接受系統(tǒng)本身的不確定性，不能把架構(gòu)和邏輯壓得太極致，否則某天可能就會(huì)“橋塌了”。特別是在安全領(lǐng)域，我?guī)缀蹩梢灶A(yù)見未來會(huì)發(fā)生一些大的“撞車事故”，因?yàn)槿藗兊凸懒?AI 的非確定性。

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

Martin：有兩個(gè)方向非常明顯。首先是快速原型開發(fā)?，F(xiàn)在做一個(gè)原型可能只需要幾天，這在過去是不可想象的，這也就是所謂的“氛圍編碼”。但不僅是“快速寫個(gè) Demo”，更重要的是我們可以在很短時(shí)間內(nèi)“試錯(cuò)”，可以探索一些之前因?yàn)槌杀咎叨粫?huì)去探索的想法，而且非開發(fā)者也能快速做工具。 只要使用得當(dāng)，這是一種巨大的價(jià)值。

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

這對(duì) ThoughtWorks 來說也很有意義，因?yàn)槲覀兘?jīng)常需要做處理遺留系統(tǒng)的現(xiàn)代化。很多大公司都面臨遺留系統(tǒng)的問題，員工流動(dòng)也會(huì)導(dǎo)致知識(shí)流失，生成式 AI 至少能幫助獲得一些進(jìn)展，這總比毫無進(jìn)展要好。

主持人：除了這兩個(gè)方向，還有哪些應(yīng)用正在探索？

Martin：還有一些領(lǐng)域我們還在探索中。比如，如何與大模型一對(duì)一協(xié)作構(gòu)建高質(zhì)量的軟件。我們發(fā)現(xiàn)，關(guān)鍵是要采用小步快跑的方式，將每個(gè)任務(wù)分解成很小的模塊，把每個(gè)模塊的輸出都當(dāng)作一個(gè)“不太可信但非常高產(chǎn)的合作者”提交的 PR，必須仔細(xì)審查每一部分。如果使用得當(dāng)，確實(shí)能提高工作效率，雖然可能沒有那么夸張，但確實(shí)非常顯著，值得我們學(xué)習(xí)如何利用它。

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

另外一個(gè)懸而未決的問題是團(tuán)隊(duì)協(xié)作場景。大多數(shù)軟件都是由團(tuán)隊(duì)開發(fā)的，未來也依然如此：即使人工智能能將生產(chǎn)力提升一個(gè)數(shù)量級(jí)，我們?nèi)匀恍枰?10 個(gè)人來完成以前 100 個(gè)人的工作，而且軟件的需求一直在增長，沒有下降的跡象，所以團(tuán)隊(duì)協(xié)作是不可避免的。問題是，如何在團(tuán)隊(duì)環(huán)境中有效利用 AI，這一點(diǎn)我們還在探索中?？偟膩碚f，目前我們有一些答案，也有很多問題有待解決，這是一個(gè)非常令人興奮的時(shí)代。

3 氛圍編程

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

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

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

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

另外還有個(gè)關(guān)鍵區(qū)別，這也是我跟同事討論得出的核心觀點(diǎn)：在用這種方式進(jìn)行快速編程時(shí)，實(shí)際上剝離了學(xué)習(xí)這個(gè)重要環(huán)節(jié)。

我們認(rèn)為，絕大多數(shù)工作模式的本質(zhì)都是先構(gòu)思創(chuàng)意，而后在計(jì)算機(jī)上反復(fù)驗(yàn)證，這就形成了計(jì)算機(jī)輸出與思維構(gòu)想間的持續(xù)交互，也就是學(xué)習(xí)循環(huán)的程序化過程。這個(gè)過程無法被捷徑取代，大模型草草掠過的各個(gè)環(huán)節(jié)根本沒辦法成為我們的學(xué)習(xí)素材。當(dāng)你不學(xué)習(xí)時(shí)，就不知道如何微調(diào)、修改和擴(kuò)展生成的代碼，只能徹底拋棄重新開始。

主持人：現(xiàn)在很多公司都在采用這些工具，導(dǎo)致需要審查的代碼越來越多，他們都在困惑如何在代碼審查時(shí)保持嚴(yán)謹(jǐn)。你有沒有看到一些有前景的方法，能幫助經(jīng)驗(yàn)不足和經(jīng)驗(yàn)豐富的工程師在使用這些工具時(shí)繼續(xù)學(xué)習(xí)？

Martin：沒有太多。我一直關(guān)注 Unmesh 在這方面的探索。他的核心思路是構(gòu)建一種適合跟大模型直接對(duì)話的語言，通過這種協(xié)作方式建立起更精準(zhǔn)、更細(xì)致的表達(dá)方式，從而清晰傳達(dá)我們的需求。我認(rèn)為這種方法確實(shí)很有前景，甚至比其他方案更具潛力。

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

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

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

使用大模型時(shí)，測(cè)試的重要性

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

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

不過我注意到，隨著 Cursor 等工具的發(fā)展，這種情況已經(jīng)有了一些改善。但問題的核心還是非確定性：大模型有時(shí)會(huì)“撒謊”，這很奇怪。如果它是一個(gè)初級(jí)開發(fā)者，我可能會(huì)找人力資源部門談?wù)劇?/strong>

我最近有過一次很奇怪的經(jīng)歷：當(dāng)時(shí)我在某個(gè)配置文件里剛剛添加了一個(gè)新的 JSON 數(shù)據(jù)塊，并在注釋中標(biāo)記了添加日期，比如“10 月 2 日添加”、“11 月 1 日添加”等等。而在大模型幫助添加配置項(xiàng)時(shí)，我特意強(qiáng)調(diào)“請(qǐng)?zhí)砑赢?dāng)前日期”，結(jié)果它直接復(fù)制了最后一次修改的日期。我說“這不是當(dāng)前日期啊”，大模型卻說“真抱歉，馬上修正”，然后把結(jié)果改成了昨天的日期。

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

主持人：在 ThoughtWorks 跟開發(fā)者和相關(guān)人士交流時(shí)，他們?nèi)粘?huì)在哪些領(lǐng)域應(yīng)用大模型？剛剛我們提到了測(cè)試場景，此外還有原型設(shè)計(jì)，你有沒有觀察到逐漸步入主流的其他操作領(lǐng)域？

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

4 規(guī)格開發(fā)與瀑布開發(fā)的對(duì)比

主持人：你對(duì)這種“規(guī)格開發(fā)”有什么看法？我感覺有點(diǎn)似曾相識(shí)，因?yàn)槟愕穆殬I(yè)生涯始于瀑布開發(fā)時(shí)代。你覺得這次的“規(guī)格開發(fā)”和瀑布開發(fā)有什么相似之處，又有什么不同？

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

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

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

主持人：確實(shí)，之前也有人嘗試過在編程中融入領(lǐng)域特定語言（DSL）的思想，比如用 Ruby 寫業(yè)務(wù)邏輯并展示給領(lǐng)域?qū)＜铱?，專家雖然不會(huì)寫，但能理解其中的內(nèi)容，指出問題所在。你覺得大模型能在這方面取得更大的進(jìn)展嗎？

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

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

Martin：其實(shí)這是我最熟悉的領(lǐng)域。你當(dāng)然深諳科技巨頭和初創(chuàng)企業(yè)的運(yùn)作模式，但其他常規(guī)業(yè)務(wù)企業(yè)則完全是另一回事，軟件開發(fā)者在其中的比例相當(dāng)?shù)?，同時(shí)面對(duì)著極其復(fù)雜的業(yè)務(wù)流程，更別提必然存在的遺留系統(tǒng)問題。此外，還有法規(guī)約束、歷史包袱、因知識(shí)體系產(chǎn)生的特殊例外等狀況。

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

我還和波士頓聯(lián)邦儲(chǔ)備銀行的人聊過，他們目前完全不能使用大模型，因?yàn)樽鳛橹匾恼鹑跈C(jī)構(gòu)，任何錯(cuò)誤都可能帶來嚴(yán)重后果，所以必須極其謹(jǐn)慎。這讓我想到一句格言：要了解一個(gè)組織的軟件開發(fā)方式，就要看它的核心業(yè)務(wù)。

我曾參觀過波士頓聯(lián)邦儲(chǔ)備銀行的貨幣處理中心，我親眼看到匯來的紙幣被運(yùn)進(jìn)處理中心，經(jīng)過清洗、清點(diǎn)等工序后重新分發(fā)。他們實(shí)施的管控措施極其嚴(yán)密，遠(yuǎn)遠(yuǎn)超乎想象。這種嚴(yán)謹(jǐn)?shù)乃季S方式也會(huì)滲透到他們的軟件開發(fā)中，因?yàn)樗麄兞?xí)慣了對(duì)每一個(gè)細(xì)節(jié)都保持高度警惕。

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

主持人：我覺得大模型是近年來普及速度最快的技術(shù)之一。即使是聯(lián)邦儲(chǔ)備銀行這樣出于合理原因在技術(shù)采用上比較滯后的機(jī)構(gòu)，也在評(píng)估它，這說明它已經(jīng)無處不在了。你覺得大型企業(yè)和更靈活的公司在對(duì)待 AI 的態(tài)度和方法上最大的區(qū)別是什么？僅僅是謹(jǐn)慎程度不同，還是有其他特點(diǎn)？

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

5 關(guān)于“重構(gòu)”

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

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

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

而最終真正引發(fā)執(zhí)法的當(dāng)數(shù) JetBrains 團(tuán)隊(duì)，他們將重構(gòu)技術(shù)融入了 IntelliJ IDEA 的早期版本并非全力推進(jìn)，終于讓自動(dòng)化重構(gòu)成為用戶可以仰仗的重要功能。當(dāng)然，手動(dòng)重構(gòu)的能力依然重要，畢竟不是所有語言環(huán)境都有對(duì)應(yīng)的重構(gòu)工具可用?？傊诖酥?，重構(gòu)成為流行術(shù)語，但也被濫用得相當(dāng)離譜——有人用“重構(gòu)”泛指一切程序修改，這顯然不準(zhǔn)確。我們對(duì)重構(gòu)有著極其嚴(yán)格的定義，必須只是微小的語義變更，強(qiáng)調(diào)在保持行為不變的前提下通過極其細(xì)微的步驟來實(shí)現(xiàn)。我一直認(rèn)為雖然每個(gè)具體步驟看似微不足道，但在將它們串聯(lián)起來之后就能創(chuàng)造驚人的效果。

主持人：那你為什么會(huì)在二十年后的 2019 年發(fā)布《重構(gòu)》的第二版？

Martin：主要是想更新書中的一些內(nèi)容，補(bǔ)充一些新的想法。另外, 初版是九十年代末針對(duì) Java 寫出來的，很多東西難免過時(shí)。雖然核心理念仍然可靠，但我覺得應(yīng)該讓這本書更適應(yīng)現(xiàn)代環(huán)境。而最大的難題就是，繼續(xù)使用 java 還是換一門語言？最終我決定轉(zhuǎn)向 JavaScript，這樣既能覆蓋更廣泛的讀者群體，又能擺脫過度面向?qū)ο蟮拿枋龇绞?。所以，第二版中采取了提取函?shù)、而非提取方法的思路，這是因?yàn)橹貥?gòu)不會(huì)改變函數(shù)的本質(zhì)。新版本中還引入了很多新的示例，希望能讓這本書再延續(xù)二十年的生命力。

主持人：那是一定的。這本二十多年前出版的行業(yè)著作，讓人們對(duì)于重構(gòu)的認(rèn)知發(fā)生了怎樣的變化？

Martin：這個(gè)不太好說，因?yàn)槲业闹饕涣鲗?duì)象是 ThoughtWorks 的開發(fā)者，他們對(duì)這類技術(shù)肯定比普通開發(fā)者更熟悉。當(dāng)然，我在網(wǎng)上看到過很多讓人無語的重構(gòu)敘事，嚴(yán)重缺乏系統(tǒng)性和我最關(guān)注的可控性。相反，我追求的向來是高效快速的重構(gòu)。這恰恰印證了“受約束的方法反而更高效”的道理，并且已經(jīng)成為我們團(tuán)隊(duì)內(nèi)部的共識(shí)。

不過值得肯定的是，越來越的人討論重構(gòu)，越來越多的工具支持重構(gòu)，而且執(zhí)行效率相當(dāng)不錯(cuò)?？傊?，我覺得我們確實(shí)取得了一定進(jìn)展，雖然沒能完全達(dá)到預(yù)期，但我也沒什么可抱怨的。

主持人：AI 工具的發(fā)展讓快速生成海量代碼成為可能。面對(duì)代碼量激增的現(xiàn)實(shí)，你覺得重構(gòu)思維在梳理底層設(shè)計(jì)意圖方面有多重要？這種重要性是不是已經(jīng)有所體現(xiàn)？

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

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

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

主持人：從重構(gòu)延伸到軟件架構(gòu)，2002 年你曾出版《企業(yè)應(yīng)用架構(gòu)模式》一書，其中匯聚了 40 多種模式，包括懶加載、身份映射、模板視圖等。那時(shí)候我參加技術(shù)面試時(shí)，面試官們總會(huì)詢問我這些架構(gòu)細(xì)節(jié)，這也讓軟件架構(gòu)的概念風(fēng)靡一時(shí)。但 2010 年代起，這一切似乎起了變化，如今我?guī)缀趼牪坏郊夹g(shù)人員再討論模式或者架構(gòu)了。你會(huì)如何看待這段時(shí)期及其產(chǎn)生的影響？為什么對(duì)軟件架構(gòu)的討論如此重要，現(xiàn)在為什么大家不再關(guān)注了？

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

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

至于為什么它不再那么流行，我也說不好，或許未來會(huì)重新熱門起來。我一直致力于傳播知識(shí)、讓復(fù)雜事物變得易懂，而我確實(shí)覺得識(shí)別并創(chuàng)建精準(zhǔn)的名詞來，是實(shí)現(xiàn)這一目標(biāo)的有效方法。

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

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

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

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

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

Martin：是的，我還記得曾跟某位加入傳統(tǒng)銀行的創(chuàng)業(yè)者聊天，他的任務(wù)是幫助銀行推動(dòng)流程現(xiàn)代化。他感慨道，“入職三年之后，我才真正理解問題所在。我大概知道自己該做什么，但透徹把控這個(gè)新領(lǐng)域非常困難，它體量龐大、歷史悠久、極其復(fù)雜且缺乏邏輯?！?/p>

大型組織的系統(tǒng)復(fù)雜且不那么“邏輯化”，因?yàn)樗鼈兪侨祟愔鸩綐?gòu)建的，包含了各種歷史因素，比如不同時(shí)期的供應(yīng)商選擇、人員變動(dòng)帶來的決策變化等，這些都會(huì)慢慢積累成復(fù)雜的體系，任何大公司最終都可能面臨這種情況。

6 敏捷生涯

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

Martin：那大概是在 2001 年，起源應(yīng)該是 Kent 在一年之前主持的一場會(huì)議。敏捷宣言的制定者是一群從事極限編程的人員，我們?cè)跁?huì)上討論的核心議題是：極端編程到底只適用于 Kent 在白皮書中描述的狹窄范疇，還是可以拓展為更廣泛的主流實(shí)踐？Kent 最終選擇了后者，于是問題轉(zhuǎn)向我們?cè)撊绾翁幚砀鼜V泛的主流實(shí)踐與 Scrum 等方法的重疊部分。正是這些因素，讓我們萌生了召集不同立場的人士共同商議的構(gòu)想。

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

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

主持人：宣言中列出的 12 條原則也助長了這種現(xiàn)象，很多人總會(huì)挑揀自己最認(rèn)可、最想強(qiáng)調(diào)的部分。

Martin：是的，其實(shí)我們?cè)谛蚤_往就聲明“仍在探索”，強(qiáng)調(diào)這應(yīng)該是個(gè)持續(xù)進(jìn)程，宣傳本身也只是對(duì)階段性成果的記錄。這些成果的來源，就是我們渴望以某種方式為 ThoughtWorks 客戶編寫軟件，但對(duì)方卻不愿意接受我們的工作方式。我們主張投入大量精力編寫測(cè)試代碼，推行專業(yè)化的構(gòu)建流程，建立自動(dòng)化構(gòu)建體系等等。我們還希望能以小步迭代的方式推進(jìn)工作。

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

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

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

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

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

以 Anthropic 的 Claude Code 團(tuán)隊(duì)為例，他們就在兩天之內(nèi)并行構(gòu)建并測(cè)試了 20 種不同的原型，收集反饋并敲定了最終方案?，F(xiàn)在有了大模型，他們可以通過提示詞和輸出結(jié)果并行構(gòu)建起 20 個(gè)真正運(yùn)行在系統(tǒng)中的原型。AI 在本質(zhì)上仍然是在加快迭代頻率，其中很多原型直接被丟棄了，余下比較好的會(huì)逐步開放給小團(tuán)隊(duì)和大團(tuán)隊(duì)?？傊?，我們還遠(yuǎn)沒有觸及快速驗(yàn)證的極限，反饋周期和信息獲取的效率仍有提高的空間。

7 如何掌握 AI

主持人：說到學(xué)習(xí)和保持領(lǐng)先認(rèn)知，你是如何掌握 AI 發(fā)展趨勢(shì)的？你和同事們會(huì)用哪些方式來保持對(duì)行業(yè)動(dòng)態(tài)的關(guān)注？

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

另外，我會(huì)關(guān)注一些可靠的信息來源，比如 Bita（和我合作過）、Simon Willis（他的產(chǎn)出效率很高，我很佩服），還有 Kent，我的很多職業(yè)生涯都受益于他的想法，現(xiàn)在也依然如此。有時(shí)候，我也會(huì)通過新出的書獲取靈感，偶爾甚至?xí)匆曨l。但老實(shí)講，我真的超討厭看視頻。

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

Martin：我覺得整個(gè)行業(yè)乃至整個(gè)世界都處于認(rèn)識(shí)論的危機(jī)當(dāng)中，人們?cè)絹碓诫y以理解世界的真相。這是個(gè)宏大的話題，總結(jié)一下，我的核心標(biāo)準(zhǔn)是：要以坦誠的態(tài)度面對(duì)不確定性。因此相較于“我很肯定就是這樣”，我覺得“這只是我目前的理解，且不敢斷定”的態(tài)度更值得欣賞。

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

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

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

給初級(jí)工程師的建議

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

Martin：我們當(dāng)然應(yīng)該多用 AI 工具并探索其適用場景。但對(duì)新手工程師來講，最難的地方在于大家缺乏判斷力：大模型給我的輸出結(jié)果到底可不可靠？在這個(gè)時(shí)候，最好找位優(yōu)秀的資深工程師擔(dān)任導(dǎo)師，這永遠(yuǎn)是掌握開發(fā)技能的最佳途徑。

我自己就很幸運(yùn)，不光在職業(yè)生涯早期遇到了 Jim Odell，還有被我視為導(dǎo)師的同齡人 Kent Beck，因?yàn)樗乃季S總是領(lǐng)先我一步?？傊?，認(rèn)真尋找自己的領(lǐng)路人。AI 雖然方便，但它容易出錯(cuò)并誤導(dǎo)我們。記得在提問時(shí)多深入探究，比如為什么給出這樣的建議、依據(jù)是什么？不光是對(duì) AI，對(duì)人也是如此。要搞清楚對(duì)方怎么得出的結(jié)論、所處的情境是什么樣。

主持人：那面對(duì)當(dāng)前大模型掀起的變革浪潮，你會(huì)如何看待科技行業(yè)的整體發(fā)展？

Martin：從宏觀角度講，我持樂觀態(tài)度，技術(shù)與軟件領(lǐng)域仍有巨大的潛力可挖。我們?nèi)蕴幱谛枨罅扛哂谙胂罅O限的階段。當(dāng)然，這是長遠(yuǎn)視角下的結(jié)論，短期內(nèi)的生活則處于一種相當(dāng)怪異的階段。

全球經(jīng)濟(jì)正陷入嚴(yán)重衰退，大規(guī)模裁員潮襲來，據(jù)說消失的崗位數(shù)量達(dá)到 25 萬至 50 萬之巨。這種現(xiàn)象在 ThoughtWorks 也有體現(xiàn)：我們?cè)３种昃?20% 的增長執(zhí)行，但從 2021 年以來我們開始遭遇瓶頸，客戶明顯縮減了相關(guān)支出。AI 領(lǐng)域雖然一枝獨(dú)秀地保持發(fā)展，但也形成了極其恐怖的價(jià)值泡沫，我們不知道它還能脹多大、什么時(shí)候會(huì)爆。

不過，我可以肯定地講，AI 確實(shí)具有價(jià)值，這跟之前的區(qū)塊鏈和加密貨幣不一樣。至于 AI 技術(shù)中蘊(yùn)藏著多大的機(jī)遇，這個(gè)我說不好。我親歷過九十年代和 2000 年初的互聯(lián)網(wǎng)技術(shù)周期，如今是當(dāng)時(shí)的重演，只不過規(guī)模擴(kuò)大了十倍。所有這些都在發(fā)生，但真正沖擊我們的并不是 AI，而是零利率時(shí)代的終結(jié)。失業(yè)潮早在 AI 興起之前就因?yàn)榱憷收叩慕Y(jié)束而爆發(fā)，我們也無法預(yù)知這樣的宏觀經(jīng)濟(jì)變局會(huì)通向何方。

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

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

其實(shí)這個(gè)問題并不新鮮啦，很多人都在關(guān)注：怎樣才能成為杰出的軟件工程師？但答案似乎從來沒變過，關(guān)鍵是好奇心、對(duì)深度的鉆研和對(duì)廣度的拓展。但更重要的是，要掌握良好的溝通能力——能夠高效協(xié)作的人，才有機(jī)會(huì)成為頂尖開發(fā)者。這一點(diǎn)在企業(yè)領(lǐng)域體現(xiàn)得尤其突出。因?yàn)槲覀兙帉懙能浖头?wù)對(duì)象所從事的，是跟我們完全不同的工作。記得在醫(yī)療系統(tǒng)工作時(shí)，我就常說：我對(duì)醫(yī)療概念建模和醫(yī)療流程的理解很深，但完全不知道該怎么看病。那我的理解是怎么來的？當(dāng)然是跟醫(yī)生交流得來的，他們也得參與整個(gè)流程。

快問快答

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

Martin：我目前最喜歡的 Ruby，因?yàn)槲易钍煜?、用得也很久。但最早讓我癡迷的無疑是 smalltalk，九十年代用它編程時(shí)的那種樂趣簡直無可比擬。

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

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

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

我認(rèn)為要想理解當(dāng)今世界的運(yùn)行邏輯，這類著作有著無可替代的價(jià)值。

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

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

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

聲明：本文為 InfoQ 翻譯整理，不代表平臺(tái)觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

AI 重塑組織的浪潮已至，Agentic 企業(yè)時(shí)代正式開啟！當(dāng) AI 不再是單純的輔助工具，而是深度融入業(yè)務(wù)核心、驅(qū)動(dòng)組織形態(tài)與運(yùn)作邏輯全面革新的核心力量。

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