Linus：別指望Rust能修復所有Bug、沒人能徹底搞懂Linux內核的3500萬行代碼

賬號設置我的關注我的收藏申請的報道退出登錄登錄搜索36氪Auto數字時氪未來消費智能湧現未來城市啟動Power on36氪出海36氪研究院潮生TIDE36氪企服點評36氪財經職場bonus36碳後浪研究所暗湧Waves硬氪氪睿研究院媒體品牌企業號企服點評36Kr研究院36Kr創新諮詢企業服務核心服務城市之窗政府服務創投發佈LP源計劃VClubVClub投資機構庫投資機構職位推介投資人認證投資人服務尋求報道36氪Pro創投氪堂企業入駐創業者服務創投平臺AI測評網 首頁快訊資訊推薦財經AI自助報道安徽最新創投汽車科技專精特新直播視頻專題活動搜索尋求報道我要入駐城市合作Linus：別指望Rust能修復所有Bug、沒人能徹底搞懂Linux內核的3500萬行代碼CSDN·2026年07月08日 19:36486時代該結束了 “我完全不反對 Rust，但我也希望降低大家對它的期待，不要認為 Rust 能夠像魔法一樣修復所有 Bug。” 近日，Linux、Git 之父 Linus Torvalds 現身印度孟買，在與 Verizon 開源項目辦公室負責人 Dirk Hohndel 展開最新一輪圍爐式深度對話時如是說道。這場對話伴隨 Linux 7.1 新版本發佈，此次他同樣摒棄了正式演講、以自由問答形式拆解開源內核數十年運轉邏輯。 在 3500 萬行龐大內核代碼的維護壓力下，Linus 再次強調自己早已不再是一線寫核心代碼的程序員，日常工作核心是把控“大局”，關注 Linux 的整體架構。 同時他進一步解釋了 Linux 最新版本中眾人關注的熱點話題：淘汰 486S 處理器、內核中兩套 NTFS 實現的並行競爭、Rust 語言定位邊界，也直面道出 AI 給內核社區帶來的雙面衝擊 ——LLM 能挖出埋藏多年的隱蔽 Bug，卻只會產出缺乏全局思考的 “創可貼式補丁”，至今仍缺失成熟工程思維。 他還明確收緊內核合併窗口規則，要求內核維護者不要扎堆在版本合併窗口的最後期限提交修復補丁；坦言維護大型開源項目最大壓力從來不是代碼衝突，而是複雜的人際溝通。 整場對話跳出技術表層，Linus 從三十餘年開源實操視角，聊透穩定迭代、語言取捨、工具邊界、社區治理等底層問題，還原 Linux 內核當下真實的開發現狀。 視頻地址：https://www.youtube.com/watch?v=YKkEe-PxW10 Linux 7.1 新版發佈！ Dirk Hohndel：很高興能來到這裡。回到孟買非常令人興奮，我大概有 21 年沒來過這裡了。我們非常享受這裡宜人的天氣。之前有人告訴我會是 120 華氏度且大雨傾盆，所以現在的天氣看起來真的很不錯。我們也享用了這裡的美食，非常棒。我是 Dirk Hohndel，從事開源開發的時間可能比在座大多數人的年紀都要長。而這位是…… Linus Torvalds：我是 Linus。請先別鼓掌，因為我極其討厭公開演講。之所以採用這種“圍爐談話”的形式，是因為這樣我就不需要提前準備和思考我要說什麼，而是由別人準備好問題來問我，我甚至不知道問題是什麼。希望這能讓對話更自然流暢，也讓我沒那麼討厭這種公開場合。 Dirk Hohndel：這是一個非常有說服力的開場。你在倫敦希思羅機場時發佈了 Linux 7.1，這一版有哪些亮點？ Linus Torvalds：其實我常說，我們已經很久沒有傳統意義上的“亮點”了。對我來說，真正的亮點在於，Linux 一直在穩定地向前發展。過去 20 多年裡，我們一直堅持同樣的方式。 自 2005 年起，我們轉向了使用 Git 的新開發模式並採用新的發佈週期，整個開發流程一直運行得非常可靠。這也意味著，我們不再發布那種擁有“重大、華麗新功能”的版本，事實上，我甚至在刻意避免這種模式。我們追求的是持續的增量改進，以及穩步推進的發展節奏。 最近，這件事變得稍微困難了一些，因為 AI 發現了一些有趣的 Bug，給社區成員帶來了不小的壓力。但總體而言，我們依然保持著每 9 到 10 周發佈一個新版本的節奏，確保系統始終穩定演進，而不是時不時給社區帶來意外的“驚喜”。 Dirk Hohndel：但我們還是看到了一些有趣的新東西，比如更新後的 NTFS 子系統。 Linus Torvalds：我們在 NTFS 上有一段很奇特的歷史。Linux 有幾十種不同的文件系統，多到數不清。 多年來，NTFS 一直是個“問題兒童”，有時候很難找到人來維護它。現在突然出現了兩個不同的團隊在維護兩個不同版本的 NTFS，而且它們都能正常工作。我目前的態度就是讓他們競爭，看看哪一個能勝出，或者可能兩個都會長期存在。 37 年後 Linux 停止支持 Intel 486 處理器 Dirk Hohndel：這確實是比較令人興奮的事情之一。另一件被廣泛討論的事則帶點傷感：對 486 架構的支持消失了。 Linus Torvalds：我想說，是時候放手了。在技術問題上，我並不是一個感性的人。我始終認為，只要還有用戶，就應該繼續維持對硬件的支持；但與此同時，到了某個階段，維護舊硬件的成本終究會變成一種沉重的負擔。這不僅體現在修復 Bug 上，更多體現在為新功能提供兼容支持上。 我們終於要移除浮點模擬代碼了。不過，這不是針對 486，而是針對更早一代的硬件。從即將發佈的 7.2 版本開始，我們將不再支持那些在 x86 架構上沒有硬件浮點運算單元（FPU）的機器。我想，最後一款這樣的硬件大概是 30 年前發佈的 486SX。 Dirk Hohndel：486SX，沒錯。那是 1993 年左右的事情了。 Linus Torvalds：是的，距今已有 30 多年。我們以前一直支持那個硬件基礎。雖然它不需要太多維護工作，但在你每次進行更改時，它依然是需要額外關注的對象。 因此，我們現在正更積極地嘗試放棄對那些除了在博物館外、實際上已經沒人在用的硬件支持。 Dirk Hohndel：沒錯，最近好像還處理了業餘無線電數據包層、ISDN、ATM 等老舊且無人維護的代碼。 Linus Torvalds：是的，我們正在嘗試清理源代碼庫。這屬於持續改進的一部分，目的是確保代碼是可維護的。Linux 的代碼庫非常龐大，維護起來絕非易事，但至少我們不應該讓它變得比必要的更難。 Linus：不要總是趕在合併窗口前再提交修復 Dirk Hohndel：在飛往孟買的飛機上時，合併窗口開啟了，你坐在飛機座位上就開始處理合併請求了。 最近幾個內核版本中，我們看到後期 RC（發佈候選版）的數量明顯增加。那麼，這種趨勢在合併窗口階段是否也存在？比如，規模更大的合併請求是否會更早地集中湧入？ Linus Torvalds：合併窗口的代碼量確實略有增加，但沒那麼多。 我認為，現在出現這種情況，除了 AI 幫助發現了更多問題這一顯而易見的原因之外，還有一點是：這些問題一旦被發現，我們有時會選擇非常激進地立即修復，而不是把修復留到下一版本繼續開發。 不過，這其中也有一部分原因在於我自己。過去，我可能太願意接受那些並非絕對必要的修復補丁了。所以上一個版本中，我告訴大家：“冷靜一點。如果不是特別重要的修復，就把它排到下一版本，不要總是在最後一刻給我發修復補丁。” 希望在座的軟件開發者都能理解這一點：修復補丁噹然是為了解決問題，但它本身也可能帶來新的問題。因此，每到發佈窗口後期，我們都要權衡一個問題：這個修復雖然能解決現有問題，但它是否值得冒著引入新 Bug 的風險，在這個階段合入？ 因此，我現在開始收緊這方面的做法，因為有些人已經習慣在發佈窗口臨近結束時才提交修復。對於 Linux 內核來說，這其實沒有太大必要。我們的發佈節奏本來就很快，一個版本週期大約只有九周，因此把修復推遲到下一版本，通常並不是一件大事。 如果一個修復並不是為了解決特別嚴重的問題，而且我們對它仍有一些顧慮，那麼即使它確實是一個修復，也完全可以推遲幾周，在下一版本中再合入。之前連續幾個版本規模都太大了，我擔心我們正在朝著錯誤的方向發展，所以現在正努力把節奏重新調整回來。 Dirk Hohndel：經過兩天的 PR 合併，有什麼讓你印象深刻的事情嗎？ Linus Torvalds：沒有。我會盡量避免在旅行期間開啟合併窗口，因為那通常是我最忙碌的時候。 在兩週的合併窗口期內，我大概需要完成 200 次合併，這是一個比較粗略的數字。這意味著，我不希望自己只是進行“盲目合併”。雖然我非常信任那些長期與我合作的核心開發者，其中一些人甚至已經和我共事了三十年，但我仍然認為，我的職責不僅僅是把代碼合併進來，還需要從更宏觀的角度理解整個過程中發生了什麼。 同時，這並不是一個特別有壓力的時期。我們有一套非常有序的發佈流程，新代碼雖然會帶來技術問題，但這些問題本身並不會讓我感到困擾，因為它們都是可以解決的。 我會經歷兩週高強度的合併工作，當然，我希望這不是在飛機上完成。但即使如此，這也並不會真正帶來壓力。真正讓我感到壓力的，往往是偶爾出現的“人際關係”問題。要知道，代碼很容易修復，但人的性格和相處問題並不總是那麼容易解決。這也是為什麼在合併窗口期間，真正困難的地方往往並不只是處理技術細節，而是需要同時面對各種人與人之間的問題。 “Linux 內核有 3500 萬行代碼，沒有人能夠真正理解全部代碼” Dirk Hohndel：你剛才提到，你希望更多瞭解進入內核的代碼。考慮到你需要在兩週內處理大約 200 個 PR，你實際上還有多少時間去閱讀代碼、理解代碼背後的意圖，或者瞭解它涉及的具體領域？ Linus Torvalds：說實話，我現在幾乎不再閱讀代碼了。我不是傳統意義上的程序員，而是一名開發主導者。當然，我知道如何編程，也依然會為了興趣寫代碼，但那些業餘項目並不是 Linux 內核，而只是一些我享受其中過程的小玩意。 我更多依賴的是“信任”。我認為，開源項目本質上都建立在信任之上——我們彼此瞭解，已經共同工作了很多年，甚至幾十年。我合併的那 200 個拉取請求，來自於那些我長期合作並且信任的人。 我並不認為自己需要完全理解每一行代碼。畢竟，面對一個擁有 3500 萬行代碼的項目，沒有任何人能夠真正理解全部代碼。 在處理一個拉取請求時，我真正想了解的是“大局”。這也是為什麼我要求提交者必須提供非常詳細的說明。我會認真閱讀這些說明，瞭解發生了什麼，以及為什麼要做這些改變。 這樣做的意義在於，未來如果出現問題，我能夠回憶起當時的背景。即使我從未親自查看過那部分代碼，遇到問題時也能馬上想到：“我知道這件事是怎麼回事，也知道應該從哪裡開始排查。”這就是我現在工作的層面。 事實上，到目前為止，我已經幾十年沒有真正編寫所謂的“核心代碼”了。 Dirk Hohndel： 但你還是會寫一些小東西…… Linus Torvalds： 我當然還會寫代碼。比如，我可能會給別人發送補丁，或者提出一個可能的修復方案：“嘿，也許可以這樣處理。” 但我會明確說明，這只是一個建議，沒有經過完整測試。它可能只是我剛剛編譯過，甚至偶爾運行過的東西。 我希望真正負責這一部分代碼的維護者，能夠基於這個思路進一步完善，並提交最終的修復方案。所以現在，我親自提交代碼的情況已經非常少了。偶爾會發生，但確實非常罕見。 Dirk Hohndel：你說自己不再看代碼，這一點很有意思。因為對於維護者來說，想獲得你全部注意力，一個有效的方法就是提交一個會導致構建失敗的拉取請求。那時候，你一定會認真檢查代碼，而且還會“非常仁慈、非常體諒”地對待他們。 Linus Torvalds： 我正在努力改進這一點。 其實，我並不是完全不看代碼。比如，在合併過程中遇到代碼衝突時，我就會查看相關代碼。這種情況很常見，也沒有什麼問題。 有些人覺得解決衝突很困難，但多年來我處理過太多衝突了，甚至閉著眼睛都能完成這類工作。我並不擔心這一點。 不過，衝突往往意味著兩個不同團隊同時修改了同一部分代碼。這時候，我會仔細看看雙方到底做了什麼，而很多問題恰恰會在這個階段暴露出來。有時，問題的根源在於兩個團隊實際上有著不同的目標。 另外，如果一個拉取請求的說明寫得不夠清楚，我也會去查看代碼。有時候，看完代碼後，我會明白：“哦，原來他們想做的是這個。” 但也有一些情況，即使看完代碼，我仍然覺得這個改動不合理，那麼我就會拒絕它。 所以，雖然我已經不是傳統意義上的程序員，但我仍然擁有足夠深厚的技術背景，能夠在需要查看代碼時做出判斷。 “不要認為 Rust 能夠像魔法一樣修復所有 Bug” Dirk Hohndel：我們剛才提到，這種開發模式的轉變發生在 20 年前，其中一個重要原因就是 Git 的誕生。如今，Git 仍然是你處理所有工作的主要工具嗎？你還會使用其他工具嗎？或者有沒有什麼工具是你希望擁有的？ Linus Torvalds：對我個人來說，Git 和電子郵件基本就是我使用的全部工具。我會用 Google 查詢資料。我相信在座的一些人可能天生就能記住整個行業裡的各種三字母縮寫，但我做不到。人們經常會在提交說明中提到一些我並不熟悉的領域，使用各種縮寫和專業術語，讓我完全摸不著頭腦。這時候，我就會去 Google 搜索。所以，從這個意義上來說，Google 也是我的工具。 但絕大多數時候，我做的事情就是閱讀郵件，以及使用 Git 進行代碼合併。這就是我工作的核心工具。 不過，我想強調一點：我是一個特殊案例。大多數其他維護者使用的工具要豐富得多，很多人現在也開始使用 AI 工具來輔助補丁檢查。 但既然我說自己的工作是在更高層級上進行，那麼我面對的核心對象其實是“人”，而不是工具。這也是為什麼我一直強調“信任”。 我信任的是開發者本人，以及他們做出的判斷。這種信任往往已經建立了幾十年。開發者可能會從一家企業跳槽到另一家企業，但我並不關心他們使用什麼郵箱，也不關心他們現在效力於哪家公司。我信任的是這個人本身，以及他長期以來展現出的判斷能力。 我認為，很多開源項目都是以這種方式運轉的。而且在開源社區中，這一點比公司內部更加明顯——在公司裡，你可能因為某個人是同事而信任他；但在開源社區，你信任一個人，是因為你們已經長期合作，並且共同經歷了很多事情。 Dirk Hohndel：Git 當然也是你發起的另一個重要項目。這個月，Git 決定引入 Rust。雖然目前 Rust 仍然是可選項，但默認配置已經開啟，而在未來的 Git 3 中，Rust 將成為必需項。你認為這種趨勢會在更多領域出現嗎？比如 Linux 內核目前也已經正式將 Rust 作為支持的編程語言之一。 Linus Torvalds：我不確定 Rust 是否會接管整個世界。我認為 Rust 確實很有趣，但也許因為我的個人經歷，我仍然覺得 C 語言是一種更簡單、更直接的工具。 其實，我個人更感興趣的是那些幫助驗證 C 代碼的工具。我們已經擁有多年的靜態分析工具，但我更喜歡近年來出現的自動化補丁驗證工具。這些工具正在真正創造價值。它們並不能提供 Rust 那樣的安全保障，但它們能夠讓更多“眼睛”去檢查代碼，幫助發現開發者在傳統 C 語言開發中經常犯的錯誤。 所以，我對正在出現的這一類工具非常興奮。現在我們已經有了像 Sashiko 這樣的自動化測試工具，以及針對補丁的自動化郵件檢查流程。 Dirk Hohndel：我總覺得，C 語言就像一把“電鋸”，而 Rust 更像是一臺帶有精密控制系統的 CNC 數控機床。有些人更習慣使用電鋸…… Linus Torvalds：我更像是那種“簡單粗暴”的人。我依然喜歡 C 語言那種原始而直接的力量，我不認為這一點會改變。 回到 Git 的話題，Git 的目標之一從來不是 C 語言本身。C 只是一個實現選擇，因為它是我一直使用的語言。我希望 Git 擁有幾個非常高層的概念，能夠解釋整個架構。 你可以從 Git 的早期歷史中看到這一點，我們不僅有 C 語言版本，還有實際上在很多公司後臺運行的 Java 版本。在服務器環境中，擁有 Java 版本的 Git 通常非常方便。Git 現在開始支持 Rust 也不像 Rust 進入內核那樣是一個巨大的變化，因為 Git 本來就已經支持多種不同的語言實現了。 Dirk Hohndel：這很有意思，因為 Rust 正在被推廣到越來越多的領域。我們已經看到了一些早期案例：開發者使用 LLM 將現有工具重寫並遷移到 Rust。但與此同時，也出現了一些相當嚴重的問題，比如 Ubuntu 23.10 的自動更新故障。 Linus Torvalds：公平地說，Rust 確實能夠避免一些在 C 語言中很容易犯的低級錯誤，但它並不能解決邏輯錯誤。它不會替你思考。 如果你的代碼邏輯本身有問題，那麼無論使用什麼編程語言，最終結果都會是錯誤的。 我完全不反對 Rust，但我也希望降低大家對它的期待，不要認為 Rust 能夠像魔法一樣修復所有 Bug。它只能解決某些特定類型的問題，讓一些錯誤更難發生，但你依然可能犯大量邏輯錯誤。 事實上，最近 Linux 內核中一些影響較大的 Bug，恰恰都是邏輯錯誤，而不是內存安全問題，也不是由於某些複雜的語言特性導致的，而是單純的編程邏輯出了問題。 遺憾的是，即使是在維護良好的子系統中，甚至是在那些理論上應該非常安全的內核核心部分，也依然可能發生這種情況。所以，不要期待某種編程語言能夠自動幫你解決所有 Bug。 Dirk Hohndel：在向 Rust 過渡的過程中，像 Linux 內核或者 Git 這樣的項目，都需要面對 C 代碼和 Rust 代碼之間的交互問題。Rust 提供的安全保證只存在於純 Rust 代碼中，一旦涉及 C 代碼調用，這些保證就會消失。 Linus Torvalds：客觀地說，大多數 Rust 與 C 代碼的交互，實際上都是在和內核核心部分的 C 代碼打交道。而內核核心代碼的質量，通常要高於外圍代碼。 這並不是因為編寫核心代碼的人更聰明，或者能力一定更強，而是因為核心代碼會在各種環境中經歷極其充分的測試。畢竟，它是內核的基礎部分，無論運行什麼場景，都會涉及內存管理、核心調度器等組件，因此這些代碼會在 Linux 支持的幾乎所有平臺上不斷接受實際運行檢驗。 相比之下，具體的硬件驅動程序則不同。一個驅動只有在對應硬件存在並被使用時，才有機會得到充分測試。 所以，Linux 內核中的代碼質量實際上存在差異，有些部分非常成熟穩定，有些部分則沒有經過同等程度的驗證。我認為，Rust 目前主要交互的，往往正是那些最穩定、開發最完善的部分。 Dirk Hohndel：顯然，內核本身其實也存在這樣的差異：有些代碼經過了大量測試，而一些實驗性代碼可能並沒有得到同等程度的驗證。 此外，還有一些歷史更久的代碼，由於對應的硬件已經不再常見，甚至已經不存在，因此也很少有人繼續使用和測試。比如，我不知道現在還有多少人在自己的 S390 機器上運行 Linux，但我不認為 Linux 是大型機領域的主流操作系統。 所以，我認為，經過最多測試、最多審查，也最值得信任的代碼，往往是所有人都會依賴的核心代碼。 Linus Torvalds：是的。核心代碼通常也會獲得最多關注。即使你是一名驅動開發者，通常也需要理解核心代碼以及相關接口的工作方式；但反過來，維護核心 VFS（虛擬文件系統）層的人，可能永遠都不需要查看某個具體硬件驅動的實現。 這也是為什麼，我通常建議希望參與內核開發的新開發者可以從驅動程序入手，因為那裡有大量學習和實踐的機會。不過，同時也要提醒大家，Linux 內核是一個極其龐大的項目，並不是一個容易上手的領域。我們對新開發者以及整個開發流程都有非常嚴格的規範和要求。 AI 仍然缺少一些“工程品位” Dirk Hohndel：我們要記錄一下，我們的對話已經進行了 26 分鐘，竟然還沒有聊到 AI 和 LLM。我想，這可能是本次大會中少有的、直到這麼久之後才提及 AI 的討論。 不過，我們確實應該談談這個話題。你之前在明尼阿波利斯也提到過，大語言模型本質上只是一個工具，它可能帶來大約 10 倍的效率提升。這個說法被很多人反覆引用。 Linus Torvalds：我需要先澄清一下，“10 倍”並不是經過科學計算得出的結果。那只是我當時隨口舉的一個數字。 Dirk Hohndel：那麼，你認為大語言模型目前能夠為 Linux 內核社區帶來多少真正的價值？ Linus Torvalds：目前來看，我希望它創造的生產力能夠超過它消耗的精力。 在今年年初之前，我們看到的更多是大語言模型生成的垃圾代碼，而不是有實際價值的代碼。即使到了現在，它仍然會消耗開發者大量資源。 比如，你可能會收到一些看起來非常合理的 Bug 報告，但最終發現它們只是 AI 產生的“幻覺”。開發者需要花費大量時間去驗證這些報告，最後卻發現它們並不真實。這實際上造成了巨大的資源浪費。 不過，過去幾個月裡情況確實有所改善，我們開始收到一些質量非常高的 Bug 報告。但這些高質量報告通常並不是單靠 LLM 產生的，而是需要一個“中間人”——也就是人類開發者參與其中。 我們也一直在強調這一點：如果你使用 LLM 發現了一個 Bug，僅僅讓模型生成一份報告，然後直接提交給我們是不夠的。 我們希望看到建議性的補丁，也希望看到運行 LLM 的那個人參與後續溝通，幫助我們討論和判斷這個問題。因為有些情況下，修復可能只是簡單的一行代碼修改；但更多時候，情況會變成：“我們之前沒有考慮到這個問題，需要重新組織部分代碼，才能真正解決它。” 這時候，就需要最初提交報告的人繼續參與。當開發者提出：“這是我們的修復方案，你的 LLM 對此有什麼看法？”時，需要有人在中間幫助溝通。 Dirk Hohndel：你剛才提到的，其實揭示了一個很多人容易混淆的區別。 LLM 在發現 Bug 方面已經變得非常強大。作為一種“攻擊工具”或者“找問題工具”，它們的能力提升非常明顯，尤其是在過去半年裡。 但另一方面，在編寫符合 Linux 內核標準的高質量、穩定代碼方面，我仍然認為 LLM 更擅長的是“從零到 Demo”。它可以非常快速地幫助你做出一個演示版本，但從 Demo 到真正可投入生產的代碼，我並不認為 LLM 一定能夠帶來同樣程度的效率提升。這也是我之前提到生產力提升時想強調的區別。 Linus Torvalds：沒錯。我自己會在一些“玩具項目”中使用 LLM，而且我非常享受這個過程。我把它看作一種原型開發工具。 比如，我可能會想：“我想嘗試實現某個功能，但如果讓我親自為這個小項目從頭寫一堆不確定是否可行的代碼，成本太高了。”這時候，我會讓 LLM 幫我完成初步實現。 當然，這些代碼通常不能直接用於生產環境，但它非常適合探索新的想法。我希望這也是目前大多數人使用 LLM 的方式。 我也同意，AI 生成的 Bug 報告有時確實會附帶補丁。在簡單情況下，這些補丁可能完全有效。但很多時候，它們更像是一種“盲目的創可貼”。它們可能解決了眼前的問題，卻沒有修復底層邏輯錯誤。結果只是讓 Bug 換了一種形式存在，未來可能在另一個地方再次暴露。 這類問題，仍然需要那些長期維護代碼、真正理解系統整體結構的開發者來解決。根據我的經驗，目前 LLM 還沒有達到這個水平。 未來也許會改變。也許有一天，你可以通過提示詞告訴模型：“請從整體角度理解這個問題，請嘗試徹底修復它，請展現出一些工程品位。”但至少現在，AI 仍然缺少這種“品位”。 Dirk Hohndel：我認為，反覆調整提示詞確實能夠提升結果質量。但至少目前，它們仍然無法取代經驗豐富的架構師所具備的系統級理解能力。 Linus Torvalds：是的，你依然需要一個能夠理解整體架構的人。我出於好奇想問一下，在座各位看起來大約有一半是軟件工程師，你們當中每天使用 LLM 的有多少人？（現場觀眾舉手）哇，人數非常多。這完全不令人意外，我只是想確認一下。 Dirk Hohndel：顯然，AI 已經有很多非常好的應用場景。我們剛才談到了 Bug 報告質量的變化，以及它們如何幫助內核發現一些長期存在的問題。 Linus Torvalds：有些發現甚至讓人感到震驚——當然，是一種有些痛苦的震驚。不要誤解，處理 Bug 從來都不是一件令人開心的事情。尤其當 Bug 涉及安全問題，並且幾天後登上科技媒體頭條時，那種感覺非常糟糕。 但我絕不會因此“遷怒於發現問題的人”。恰恰相反，我認為 LLM 幫助我們發現 Bug 是一件非常好的事情。 即使這些 Bug 讓我們感到尷尬，即使它們可能已經存在了幾十年，最終能夠找到並修復它們，仍然是一件好事。我們會因此變得更強大。 過去幾個月確實有些艱難，因為 LLM 發現了一系列相關問題。但這其實並不奇怪：一個人通過 AI 找到了一個 Bug，另一個人可能會繼續問 AI：“類似的位置是不是也存在問題？” 於是，我們可能會在幾周內看到三四個高度相關的 Bug 接連成為新聞焦點。 Dirk Hohndel：以這個話題結束似乎有點沉重，那我們換一個輕鬆的話題，聊聊 AI 的另一個有趣用途。聽說你會在旅行時使用 AI，把“哥斯拉”加入發給家人的照片裡？ Linus Torvalds：沒錯，我自己也會在一些小項目中使用 AI。每次去新的地方旅行——這次是我第一次來到印度——我都會給孩子們發送當地的照片。出於某種奇怪的原因，哥斯拉似乎總是會跟著我，並出現在這些照片裡。 所以，AI 既有很多嚴肅的用途，也有很多純粹為了娛樂的玩法。 Dirk Hohndel：我想“哥斯拉”是一個非常完美的收尾話題。非常感謝各位的聆聽，感謝大家到來。 本文來自微信公眾號“CSDN程序人生”，整理：屠敏，36氪經授權發佈。 該文觀點僅代表作者本人，36氪平臺僅提供信息存儲空間服務。+13好文章，需要你的鼓勵CSDN特邀作者0收 藏+10評 論打開微信“掃一掃”，打開網頁後點擊屏幕右上角分享按鈕微 博沉浸閱讀返回頂部舉報參與評論評論千萬條，友善第一條登錄後參與討論提交評論0/1000你可能也喜歡這些文章WAIC前瞻：Agent接管終端、機器人進廠，AI敘事邏輯劇變美國算力之城爛尾項目+12026最值得期待的AI硬件，是卡片工信部首次定調：Claude Code危害嚴重人工智能來到“真實世界AI”階段年薪600萬搶AI博士，讀書不如“進廠煉丹”？DeepSeek、智譜被曝造芯，國產大模型繞開英偉達GPT-5.6，本週四全量上線小扎「芒果」生圖只輸GPT Image 2，沒人教它改稿，它自己學會了CSDN特邀作者TA沒有寫簡介，但內斂也是一種表達發表文章1455篇最近內容Linus：別指望Rust能修復所有Bug、沒人能徹底搞懂Linux內核的3500萬行代碼23分鐘前沒人能徹底搞懂Linux內核的3500萬行代碼，Linus談未來演進：掌控“大局”、別指望Rust能修復所有Bug、486時代該結束了23小時前C盤“憑空”少了513GB，Win11又曝離譜Bug，拖了幾個月，微軟終於低調認錯並修復23小時前閱讀更多內容，狠戳這裡下一篇2026最值得期待的AI硬件，是卡片AI 應該少偷點個人信息，多幫打工人幹活24分鐘前關於36氪城市合作尋求報道我要入駐投資者關係商務合作關於我們聯繫我們加入我們36氪歐洲站36氪歐洲站36氪歐洲站Ai產品日報網絡謠言信息舉報入口熱門推薦熱門資訊熱門產品文章標籤快訊標籤合作伙伴36氪APP下載iOS & Android本站由 阿里雲 提供計算與安全服務 違法和不良信息、未成年人保護舉報電話：010-89650707 舉報郵箱：[email protected] 網上有害信息舉報© 2011~2026 北京多氪信息科技有限公司 | 京ICP備12031756號-6 | 京ICP證150143號 | 京公網安備11010502057322號意見反饋36氪APP讓一部分人先看到未來36氪鯨準氪空間推送和解讀前沿、有料的科技創投資訊一級市場金融信息和系統服務提供商聚焦全球優秀創業者，項目融資率接近97%，領跑行業