Claude 4.5 Sonnet寫的，我覺得寫的相當好。 （全文有1萬7千字，先放第一部分） 代碼之神：傑夫·迪恩傳 1968年7月23日，傑夫·迪恩（Jeff Dean）出生於夏威夷。 這個太平洋上的群島，以其火山、海灘和多元文化聞名，卻很少被視為科技天才的搖籃。 但迪恩的童年註定不會平凡。 他的父親安迪（Andy）是一位熱帶疾病研究員。 他的母親維吉尼亞·李（Virginia Lee）是一位醫學人類學家，會說六種語言。 這種家庭背景意味著他的成長伴隨著全球遷徙——從夏威夷到亞特蘭大的疾病管制中心，再到日內瓦的世界衛生組織，最後定居明尼蘇達。 十三歲時，他甚至跳過了八年級的最後三個月，去索馬利亞西部的難民營幫助父母。 這種不斷變換的環境培養了他對複雜系統的早期直覺：**無論是疾病的傳播模式，還是後來電腦網路中的資料流動，都遵循著某種可以被理解、被建模、被優化的規律。 ** 為了好玩，父子倆一起編程一台IMSAI 8080套件計算機。 他們給機器焊接升級部件，學習它的每個部分。 這種從硬體層面理解電腦的經歷，將成為迪恩職業生涯的基石。 他不僅理解程式碼的邏輯，更理解電流如何在矽片中流動。 在高中時，迪恩開始為流行病學家編寫一個名為Epi Info的資料收集程式。 這個程式成為了實地工作的標準工具，最終分發了數十萬份副本，支援十幾種語言。 美國疾病管制與預防中心維護的一個網站"Epi Info的故事"中，至今仍保留著傑夫高中畢業時的照片。 但這個成就，他從未主動提及。 多年後，他的妻子海蒂才知道這個程序的重要性。 "他從不吹噓那些事，"她說。 "你得從他那裡套話。" 在明尼蘇達大學，迪恩選擇了電腦科學與經濟學的雙學位。 這個組合看似不尋常，但其實揭示了他思維的雙重向度：既追求技術的極致，也關注資源的效率。 他在大學時認識了海蒂。 他們的第一次約會是去看一場女子籃球賽。 傑夫當時穿著地鼠吉祥物服裝在做啦啦隊。 1990年，他完成了本科論文——主題是神經網路。 這個細節在當時或許微不足道，但二十年後回望，它像是命運埋下的伏筆。 當時的神經網路研究正處於"AI寒冬"的尾聲，學術界對其前景普遍悲觀。 但年輕的迪恩已經在探索機器如何透過數據"學習"的奧秘。 畢業後，迪恩做了一個不尋常的選擇：他沒有直接投身科技公司，而是前往日內瓦，為世界衛生組織的全球愛滋病規劃署工作。 在那裡，他開發流行病統計模型軟體，用程式碼幫助人類理解和對抗致命疾病的傳播。 這段經歷塑造了他對"規模"的最初理解——不是伺服器集群的規模，而是全球公共衛生危機的規模。 當你的軟體需要處理涉及數百萬生命的資料時，"失敗"不再是一個抽象的技術術語，而是真實的人類悲劇。 ## 第一幕：系統建構者的誕生 ### 學徒時代：編譯器的魔法 1996年，迪恩從華盛頓大學獲得電腦科學博士學位。 他的博士研究專注於編譯器。 將人類編寫的程式碼轉換成優化過的供電腦執行的機器語言指令的軟體。 "就吸引力而言，編譯器幾乎是最無聊的東西了" 他後來的經理艾倫·尤斯塔斯說。 但另一方面，它們讓你"非常接近機器"。 編譯器是程式設計師與機器之間的翻譯官，而最佳化編譯器的人，必須同時精通人類的抽象思考和矽片的物理限制。 這種"雙語能力"將成為迪恩職業生涯的核心競爭力。 桑傑後來在描述傑夫時，用食指在太陽穴旁打轉。 "在你寫程式的時候，他腦子裡就有一個模型在運行，"他說。 "'這段程式碼的效能會怎樣？'他幾乎是半自動地思考所有極端情況。" 博士畢業後，他加入了傳奇的DEC西部研究實驗室（後來被康柏收購）。 在那裡，他與一群頂尖工程師一起工作，專注於分析工具、微處理器架構和資訊檢索。 這三年的經驗為他後來在Google的工作奠定了堅實基礎： 分析工具教會了他如何理解系統的瓶頸，微處理器架構讓他深入理解硬體的本質，而資訊檢索則是搜尋引擎的核心問題。 傑夫曾分發過一份名為"每個程式設計師都應知道的延遲數字"的清單。 事實上，這是一份幾乎沒有程式設計師知道的數字清單： **L1快取引用通常需要半奈秒，從記憶體中順序讀取一兆位元組需要二百五十微秒。 ** 這些數字已深深烙印在他的大腦中。 ### 桑傑：另一半腦 在DEC，迪恩遇到了桑傑·格瑪沃特（Sanjay Ghemawat）。 桑傑於1966年出生在印第安納州的西拉法葉，但在印度北部的工業城市科塔長大。 他的父親馬希帕爾是一位植物學教授。 他的母親珊塔（Shanta）照顧桑傑和他的兩個哥哥和姐姐。 桑傑的哥哥潘卡伊是哈佛商學院有史以來獲得終身教職的最年輕的教員。 （他現在是紐約大學史登商學院的教授） 潘卡伊和桑傑上同一所學校，並以博學多才聞名。 "我有點活在我哥哥的陰影下，"桑傑說。 成年後，他仍然保持著一種自我謙遜的天賦。 2016年，當他入選美國藝術與科學學院時，他沒有告訴父母；是他們的鄰居把消息告訴了他們。 桑傑直到十七歲去康乃爾大學才接觸電腦。 在麻省理工學院攻讀研究生時，他的導師是芭芭拉·利斯科夫，一位有影響力的電腦科學家，她的研究領域之一是複雜程式碼庫的管理。 在她看來，最好的程式碼就像一篇好的文章。 它需要一個精心構思的結構，每個字都應該發揮作用。 以這種方式編程需要對讀者有同理心。 這也意味著將程式碼不僅僅視為達到目的的手段，而是本身就是一件藝術品。 "我認為他最擅長的是設計系統，"谷歌的第一位員工克雷格·西爾弗斯坦說。 "如果你只是看桑傑寫的一個代碼文件，它的美麗就像一座比例勻稱的雕塑那樣美。" 在DEC，傑夫會從他的研究實驗室走兩個區塊到桑傑的實驗室。 「中間有一家義式冰淇淋店，」傑夫回憶道。 桑傑高興地說："所以是因為那家冰淇淋店！" 他們開始一起編程——不是各自在自己的電腦前工作，而是共享一台電腦，一個人操作鍵盤，另一個人在旁邊引導和糾正。 這種合作方式在軟體開發中並不常見。 社會學家麥可‧P‧法瑞爾在2001年的著作《協作圈：友誼動力與創意工作》中指出： > "奠定新視野基礎的大多數脆弱見解，並非在整個團體聚在一起時出現，也不是在成員獨自工作時出現，而是在他們成對協作並相互回應時產生的。" 正是莫內和雷諾瓦在1869年夏天並肩工作，才發展出了後來成為印象派的風格。 在催生立體主義的六年合作期間，畢卡索和布拉克常常只在畫布背面簽名，以掩蓋哪幅畫是哪個人完成的。 "我不知道為什麼沒有更多人這樣做，"桑傑談到與夥伴一起編程時說。 "你需要找到一個與你的思維方式相容的人來進行結對編程，這樣你們倆在一起就能形成互補的力量，"傑夫說。 1999年中期，網路泡沫正接近頂峰。 傑夫先離開DEC，加入了一個名叫"Google"的小公司。 當時的Google只有幾十名員工，辦公室設在加州山景城的一棟不起眼的建築裡。 十個月後，桑傑也跟著來。 他們的傳奇合作即將改變網路的歷史。 ### 2000年3月：災難與重生 2000年3月的某一天，Google最優秀的六名工程師聚集在一個臨時的作戰室。 公司正面臨前所未有的緊急狀況。 去年10月，其核心系統——負責抓取網頁以建立"索引"的系統——停止了工作。 儘管用戶仍然可以在https://t.co/cHDYnkjtpa上輸入查詢，但他們得到的結果是五個月前的舊數據。 更糟的是，谷歌的聯合創始人拉里·佩奇和謝爾蓋·布林正在談判一項為雅虎（Yahoo）提供搜尋引擎支援的交易，他們承諾交付一個比當時大十倍的索引。 如果他們失敗了，https://t.co/cHDYnkjtpa將繼續停留在過去，雅虎的交易很可能泡湯，公司也將面臨耗盡資金直至倒閉的風險。 在一個靠近樓梯的會議室裡，工程師把門板架在鋸木架上，擺好了電腦。 克雷格·西爾弗斯坦，谷歌的第一位員工，坐在靠遠牆的位置。 他和一位名叫波格丹·科科塞爾的羅馬尼亞系統工程師經過四天四夜的奮戰，一無所獲。 "我們做的所有分析都毫無意義，"西爾弗斯坦回憶道。 "一切都壞了，我們不知道為什麼。" 西爾弗斯坦幾乎沒有註意到他左後方桑傑·格瑪沃特的存在。 桑傑幾個月前才加入公司，是跟著傑夫·迪恩從DEC過來的。 在戰鬥室裡，傑夫把椅子滑到桑傑的桌旁，留下自己的空位。 桑傑操作鍵盤，而傑夫則靠在他身邊，像新聞主播耳邊的製作人一樣糾正和引導。 傑夫和桑傑開始仔細研究那個停滯的索引。 他們發現有些字遺失了－搜尋"mailbox"（信箱）卻沒有任何結果，而有些字則順序混亂。 幾天來，他們一直在程式碼中尋找缺陷，沉浸在其邏輯中。 逐段檢查，一切似乎都沒問題。 他們找不到那個錯誤（bug）。 在作戰室的第五天，傑夫和桑傑開始懷疑他們尋找的問題並非邏輯上的，而是物理上的。 他們將混亂的索引檔案轉換為其最原始的表示形式：**二進位代碼。 ** 他們想看看他們的機器看到了什麼。 在桑傑的顯示器上，出現了一列密集的1和0，每一行代表一個索引詞。 桑傑指著：一個本來就該是0的數字變成了1。 當傑夫和桑傑把所有排序錯誤的單字放在一起時，他們看到了一個模式，每個單字都出現了同一個小故障。 他們機器的記憶體晶片不知何故損壞了。 桑傑看著傑夫。 幾個月來，谷歌經歷的硬體故障越來越多。 問題在於，隨著Google的發展，其運算基礎設施也在擴張。 電腦硬體很少出故障，除非你擁有足夠的硬體——那時它就會一直出故障。 電線磨損，硬碟崩潰，主機板過熱。 許多機器從一開始就無法運作；有些會莫名其妙地變慢。 奇怪的環境因素也開始運作。 當超新星爆炸時，衝擊波會產生高能粒子並向四面八方散射；科學家認為，這些被稱為宇宙射線的迷途粒子有極小的機率擊中地球上的電腦晶片，將0翻轉為1。 世界上最穩健的電腦系統，如NASA、金融公司等，使用能夠容忍單位比特翻轉的特殊硬體。 但谷歌，當時仍像新創公司一樣運作，購買的是缺乏該功能的廉價電腦。 谷歌在加州聖克拉拉的一棟建築裡，將一千五百台裸露的主機板和硬碟像三明治一樣疊成六英尺高的塔架。 由於硬體故障，只有一千二百台能運作。 公司已經到達了一個轉捩點。 它的計算集群變得如此龐大，以至於即使是罕見的硬體故障也變得不可避免。 傑夫和桑傑一起寫了程式碼來補償那些出問題的機器。 不久之後，新的索引完成了，作戰室也解散了。 ### 週末重寫：彈性系統的誕生 這場危機成為了一個轉捩點。 傑夫和桑傑意識到，隨著Google的成長，硬體失敗不會是偶然事件，而是常態。 當你有成千上萬台伺服器時，每天都會有機器宕機、硬碟損壞、網路中斷。 如果系統無法應對這些失敗，Google就無法擴展。 他們需要建構一套全新的基礎架構：**一套能夠在混亂中維持秩序的系統。 ** 這場週末重寫的核心設計理念是**預期失敗**（expect failure）。 與其假設硬體是完美的，不如假設硬體*一定會*失敗。 系統需要能夠自動偵測損壞的數據，標記故障的機器，並繞過它們繼續工作。 這種"容錯"思想在今天看來是分散式系統的常識，但在2000年，它是激進的。 在三月索引崩潰事件之前，Google的系統根植於其創始人在史丹佛大學讀研究生時編寫的程式碼。 佩奇和布林並非專業的軟體工程師。 他們是進行搜尋技術實驗的學者。 當他們的網路爬蟲崩潰時，沒有提供資訊的診斷訊息—只有一句"Whoa, horsey!"（喔唷，小馬！）。 早期員工將佩奇和布林編寫的一個名為BigFiles的軟體稱為BugFiles（充滿錯誤的檔案）。 他們至關重要的索引代碼需要數天才能完成，如果遇到問題，就必須從頭開始。 用矽谷的行話來說，Google當時不具備"可擴展性"。 羅辛（Wayne Rosing）曾在蘋果參與麥金塔電腦前身的工作，於2000年11月加入谷歌，負責管理其百人工程師團隊。 "他們是領導者，"他說。 傑夫和桑傑並肩負責了重建Google基礎架構的工作。 他們每週工作九十個小時，編寫程式碼，使得單一硬碟故障不會導致整個系統癱瘓。 他們在爬取過程中添加了檢查點，以便可以在中途重新啟動。 透過開發新的編碼和壓縮方案，他們有效地將系統容量翻了一番。 **他們是無情的優化者。 ** 當汽車轉彎時，外側輪子必須覆蓋更多地面。 同樣，旋轉硬碟的外緣比內緣移動得更快。 谷歌已將最常存取的資料移到外部，以便資料位元可以在讀寫頭下更快地流動，但內部一半是空的； 傑夫和桑傑利用這個空間儲存了常見搜尋查詢的預處理資料。 在2001年的四天裡，他們證明了Google的索引可以使用快速的隨機存取記憶體（RAM）而不是相對較慢的硬碟來儲存。 這項發現重塑了公司的經濟模型。 佩奇和布林知道用戶會湧向能夠即時提供答案的服務。 問題在於速度需要運算能力，而運算能力需要花錢。 傑夫和桑傑用軟體巧妙地解決了這個問題。 艾倫·尤斯塔斯在羅辛於2005年離開後成為工程團隊的負責人。 "要解決規模化問題，矛盾的是，你必須了解最微小的細節，」尤斯塔斯說。 傑夫和桑傑在比特層面上理解電腦。 在他們幫助引領Google核心軟體的幾次重寫過程中，系統的容量按數量級擴展。 同時，在公司龐大的資料中心裡，技術人員現在沿著蛇形路線行走，遵循軟體產生的指令更換硬碟、電源和記憶體條。 即使其部件磨損和失效，系統仍可正常運作。 ### MapReduce：簡化混亂 2004年，迪恩和格瑪沃特發表了一篇論文，題為《MapReduce: Simplified Data Processing on Large Clusters》（MapReduce：大規模集群上的簡化資料處理）。 這篇論文只有兩位作者，但它將改變整個產業。 MapReduce的核心思想極為簡潔：**將複雜的分散式運算抽象化為兩個函數－`Map`和`Reduce`。 ** `Map`函數處理輸入數據，產生中間鍵值對； `Reduce`函數將相同鍵的值聚合在一起，產生最終結果。 程式設計師只需要定義這兩個函數，系統會自動處理並行化、任務調度、機器間通訊和失敗復原。 這種抽象的威力在於它的**簡單性**。 在MapReduce之前，編寫分散式程式需要深厚的系統知識——你需要手動管理執行緒、處理網路通訊、應對機器失敗。 這些複雜性將大多數程式設計師拒之門外。 但MapReduce將這些複雜性隱藏在系統內部，讓沒有分散式系統經驗的工程師也能輕鬆處理TB級資料。 論文中的一個例子是計算大量文件中每個單字的出現次數。 `Map`函數讀取文檔，輸出`(單字, 1)`的鍵值對； `Reduce`函數將相同單字的計數相加。 整個程式只需幾行程式碼，但它可以在數千台機器上並行運行，處理整個互聯網的網頁。 MapReduce的另一個關鍵貢獻是**容錯性**。 系統會持續監控任務的執行，如果某台機器失敗，系統會自動在另一台機器上重新執行該任務。 這種"重新執行"策略之所以可行，是因為`Map`和`Reduce`函數被設計為"功能性"的－它們不修改輸入數據，只產生輸出。 這意味著重新執行一個任務不會產生副作用，結果是確定的。 這種設計直接源自於"2000年危機"的教訓：硬體會失敗，但係統必須繼續運作。 MapReduce在Google內部迅速普及。 它被用來建立搜尋索引、處理日誌資料、產生報告、訓練機器學習模型。 2004年論文發表時，Google內部已經有數百個MapReduce程式在運作。 更重要的是，MapReduce的想法傳播到了整個產業。 雅虎基於這篇論文開發了Hadoop，一個開源的MapReduce實現，它成為了大數據時代的基石。 ### Bigtable：儲存的藝術 如果MapReduce解決了大規模*計算*的問題，那麼Bigtable解決的就是大規模*儲存*的問題。 2006年，迪恩和格瑪沃特與其他幾位Google工程師發表了《Bigtable: A Distributed Storage System for Structured Data》（Bigtable：結構化資料的分散式儲存系統）。 Bigtable的設計目標是管理PB級的結構化數據，同時支援高吞吐量的批次處理和低延遲的即時查詢。 這是一個看似矛盾的需求：**批量處理需要掃描大量數據，而即時查詢需要快速返回單一結果。 ** 傳統的關係型資料庫無法同時滿足這兩種需求。 Bigtable的解決方案是一個獨特的資料模型：它是一個"稀疏的、分散式的、持久化的多維排序映射表"。 每個資料項由三個維度索引：行鍵（row key）、列鍵（column key）和時間戳記（timestamp）。 這種設計提供了極大的靈活性： - **行鍵**：資料按行鍵排序存儲，相鄰的行鍵會儲存在同一台機器上。這使得掃描某個範圍的資料非常有效率。 - **列族**：列被組織成列族，每個列族可以獨立設定存取控制和壓縮策略。這允許系統根據不同的存取模式優化儲存。 - **時間戳**：每個資料項可以有多個版本，由時間戳區分。系統可以自動保留最新的N個版本，或是保留最近T天的版本，舊版本會被垃圾回收。 Bigtable的另一個關鍵設計是它*不是*一個關係型資料庫。 它不支援複雜的SQL查詢，不支援跨行事務。 這些限制是有意為之的——**它們允許系統在數千台機器上水平擴展，而不會被複雜的一致性協議拖累。 ** 在Google內部，Bigtable被用來儲存網頁索引、Google Earth的地理資料、Google Analytics的使用者行為資料等。 它的影響力同樣擴展到了整個產業：亞馬遜的DynamoDB、Facebook的Cassandra、Apache的HBase都受到了Bigtable的啟發。 ### Spanner：全球一致性的巔峰 MapReduce和Bigtable奠定了Google基礎架構的基石，但它們都有一個共同的限制：它們主要設計用於單一資料中心。 隨著Google的全球擴張，數據需要跨越洲際分佈。 如何在全球範圍內保持數據的一致性，成為了下一個挑戰。 2012年，迪恩和葛瑪沃特與其他工程師發表了《Spanner: Google's Globally-Distributed Database》（Spanner：Google的全球分散式資料庫）。 Spanner是世界上第一個支援"外部一致性分散式事務"的全球分散式資料庫。 Spanner的核心創新是**TrueTime API**。 在分散式系統中，時間是一個棘手的問題。 不同機器的時鐘會有偏差，而網路延遲意味著你無法確定兩個事件的真實順序。 Spanner的解決方案是利用GPS和原子鐘，建構一個能夠*暴露時脈不確定性*的API。 TrueTime不會告訴你"現在是12:00:00"，而是告訴你"現在是12:00:00，誤差在±7毫秒之內"。 透過精確*知道*這種不確定性，Spanner能夠為全球事務分配有意義的提交時間戳。 如果不確定性太大，系統會主動"等待不確定性過去"—這稱為"commit wait"。 這種等待通常只需幾毫秒，但它確保了事務的外部一致性：如果事務T1在事務T2之前提交，那麼T1的時間戳一定小於T2的時間戳。 Spanner的誕生標誌著迪恩"系統三部曲"的完成。 從MapReduce（容錯運算）到Bigtable（容錯儲存），再到Spanner（全球一致性）。 這三個系統共同建構了谷歌的技術護城河。 它們不僅支撐了Google的搜尋、廣告、Gmail等核心業務，也為後來的人工智慧浪潮提供了基礎設施。 2025年，Spanner獲得了ACM SIGMOD系統獎，表彰其"重新構想了關係數據管理，以在全球範圍內實現具有外部一致性的可串行化"。 這是對迪恩和格瑪沃特十多年前工作的最新認可。 ### 規模的尾端效應：系統哲學的頂峰 2013年，迪恩與葛瑪沃特發表了另一篇影響深遠的論文：《The Tail at Scale》（規模的尾端效應）。 這篇論文探討了一個在大規模系統中普遍存在但常被忽視的問題：**尾端延遲**（tail latency）。 在谷歌的系統中，一個使用者請求可能需要呼叫數百台伺服器。 即使每台伺服器的平均回應時間很快，但只要有1%的伺服器響應緩慢（例如因為垃圾回收、磁碟I/O或網路擁塞），就會導致大多數用戶請求變慢。 這是因為使用者請求需要等待*所有*伺服器回應，而最慢的那台伺服器決定了整體延遲。 論文的深刻洞見在於，試圖消除所有延遲源頭是"不切實際的"。 硬體會失敗，網路會壅塞，作業系統會有抖動。與其追求完美，不如建構"容尾"（tail-tolerant）系統－這與"2000年危機"後他建構"容錯"系統的理念相呼應。 論文提出了一系列技術來應對尾端延遲： - **對沖請求**：向多個副本發送相同請求，使用最快的回應。 - **綁定請求**：向多個副本發送請求，但一旦某個副本開始處理，就取消其他副本的請求。 - **微分區**：將資料分成更小的分區，使得負載可以更靈活地在機器間遷移。 - **選擇性複製**：對熱點資料建立更多副本，分散負載。 這些技術的核心思想是：**在不可靠且速度不均的硬體之上，透過冗餘和智慧調度，建構出高效能的彈性服務。 ** 2025年，《The Tail at Scale》獲得了ACM SIGOPS名人堂獎，表彰其"經受住了時間的考驗"。 這篇論文不僅影響了Google的系統設計，也成為了整個產業的經典文獻。 ### 迪恩與葛瑪華特：傳奇的合作 在講述迪恩的故事時，無法迴避他與桑傑·格瑪沃特的合作。 他們是MapReduce論文的*僅有*兩位作者，是Bigtable和Spanner的核心設計者，是《The Tail at Scale》的共同作者。 他們在DEC時就開始合作，在谷歌共同經歷了"2000年危機"，並在接下來的二十多年裡聯手構建了谷歌的技術基石。 2012年，他們共同獲得了ACM計算獎，表彰其"構思、設計並實現了Google革命性的軟體基礎設施"。 2009年，他們一起被當選為美國國家工程院院士。 他們的合作被稱為"拯救了谷歌，並發明了現代互聯網的友誼"。 但這種合作關係也帶來了一個有趣的文化現象："傑夫·迪恩梗"（Jeff Dean Facts）。 ### "傑夫迪恩梗"：崇拜與遺憾 2007年愚人節前後，Google內部開始流傳一系列關於傑夫·迪恩的玩笑，模仿"查克·諾里斯梗"的形式。 這些笑話誇張地描述了迪恩的技術能力，例如： - “傑夫·迪恩先直接寫二進制；源碼只是給別人看的文檔。” - “傑夫·迪恩的鍵盤沒有Ctrl 鍵——因為他一直都在控制中。” - "編譯器不會警告傑夫迪恩。傑夫迪恩會警告編譯器。" - “真空裡的光速以前很慢，後來傑夫·迪恩用一個週末把物理優化了。” 這些梗在谷歌內部迅速傳播，後來擴散到整個科技業。 它們反映了工程師們對迪恩的敬佩——他不僅是一位傑出的技術專家，更是一位能夠解決任何問題的"代碼之神"。 但這些梗也帶來了一個問題：它們給人留下了"傑夫比桑傑更卓越"的印象。 事實上，迪恩和格瑪沃特的貢獻是平等的，他們的合作是互補的。 據說梗的創作者後來表示遺憾，認為"唯一的原因是'傑夫'這個名字似乎'更有趣'"。 這個細節揭示了公眾認知與真實歷史之間的差距。 迪恩的傳奇不是一個人的獨角戲，而是一段持續二十多年的合作關係。
正在加载线程详情
正在从 X 获取原始推文，整理成清爽的阅读视图。
通常只需几秒钟，请稍候。