Linus一句話說透Al局限：代碼不能直接用，bug只能創可貼式地修

編譯｜冬梅

如果只看技術履歷，Linus Torvalds 是 Linux 和 Git 的創造者，是過去三十多年開源世界繞不開的人物。但在這場對談里，更值得看的并不只是他如何評價 Linux 7.1、Rust、C 語言或 AI，而是一個長期站在復雜系統中心的人，如何理解軟件、社區、工具和人。

這場對話發生在一場開源技術會議上，由 DH Consulting 創始人、資深開源開發者 Dirk Hohndel 提問，Linus Torvalds 回答。

兩人的關系并不陌生，Dirk 熟悉開源社區的脈絡，也知道該如何把 Linus 從“技術細節”引向更大的工程問題。于是，這場對話從 Linux 7.1 發布聊起，一路談到內核開發節奏、486 等老舊硬件支持的退出、Git 與郵件驅動的協作方式、C 與 Rust 的語言取舍，以及 LLM 正在給 Linux 內核社區帶來的真實變化。

這場對話最有意思的地方在于，Linus 并沒有把技術趨勢包裝成宏大的敘事，而是始終從工程實踐出發。他談到，Linux 內核已經不追求“驚艷發布”，而是依靠 20 多年來穩定運行的開發節奏持續演進；486、ISDN、ATM 等舊硬件和舊代碼的逐步退出，也不是懷舊與否的問題，而是維護成本與代碼可維護性的現實取舍。

在語言之爭上，Linus 依然保持了典型的工程師式直白。他承認 Rust 能減少一部分類 C 語言中常見的錯誤，但也提醒外界不要神化 Rust：語言無法替人思考，更無法自動修復邏輯錯誤。相比“Rust 會不會接管世界”，他更關注 C 代碼驗證工具、自動化補丁檢查和代碼審查體系的進步。

在談到 AI 和大語言模型時，Linus 的態度同樣克制。

他把 LLM 視為工具，而不是魔法。它們已經在發現 bug、生成原型、輔助驗證方面展現出價值，尤其能把更多“眼睛”投向過去很少被充分審查的代碼角落。但與此同時，AI 生成的錯誤報告、幻覺內容和“創可貼式補丁”也在消耗維護者資源。對 Linux 內核這樣的復雜工程而言，LLM 目前還無法替代長期維護者的架構判斷、工程經驗和代碼品味。

從某種意義上說，這場對話不只是 Linus 對 Linux、Git、Rust 和 AI 的一次集中回應，也呈現了開源世界面對新技術浪潮時最樸素的一面：工具可以變化，語言可以變化，AI 也可以加入流程，但真正支撐大型工程長期運轉的，仍然是信任、經驗、審查機制和對復雜系統的敬畏。

以下為完整對話內容，經 InfoQ 編譯：

“我對技術不是特別懷舊”

Dirk Hohndel：很高興來到這里，也很高興再次回到孟買。我已經大概 21 年沒來過這里了。我叫 Dirk Hohndel，是一名開源開發者，從事開源的時間可能比在座很多人的年齡都長。你來介紹下你自己吧，Linus。

Linus Torvalds：我是 Linus。之所以采用這種有點奇怪的爐邊對談形式，是因為我非常討厭公開演講。所以解決辦法就是，不讓我自己準備演講內容，而是由別人來準備問題，然后問我一些我事先不知道的問題。這樣對話會更自然一點，也讓我沒有那么討厭這種公開場合。

Dirk Hohndel：這是一個很有說服力的開場。你最近其實是在倫敦希思羅機場發布了 Linux 7.1。這個版本有哪些亮點？

Linus Torvalds：我通常會說，從傳統意義上講，Linux 版本發布并沒有太多所謂“亮點”。對我來說，真正的重點一直是持續、穩定的改進。

我們已經用同樣的方式做了 20 多年。2005 年，我們切換到了基于 Git 的新開發模式，也采用了新的發布節奏。一開始大家需要適應，但后來這個模式運行得非常可靠。

這也意味著，我們不會做那種帶有巨大、炫目新特性的版本發布。我其實會主動避免那種模式。我們想要的是持續的、增量式的改進，讓項目一直穩定向前。

最近這件事變得稍微困難了一些，因為 AI 找到了一些有意思的 bug，這也讓社區里一些人感到壓力。但總體而言，Linux 仍然保持著穩定的發布節奏：大約每 9 到 10 周發布一個新版本，并盡量確保它穩定，不讓社區感到意外。

當然，這個版本也有一些有趣的新東西。比如更新后的 NTFS 子系統，這應該是大家期待已久的，尤其是來自微軟的演講嘉賓可能會很關心。Linux 和 NTFS 的歷史一直有點奇怪。多年來，NTFS 一直像個“問題孩子”，維護者也不總是好找。現在突然出現了兩個不同的團隊，分別維護兩個不同版本的 NTFS，而且它們都能工作。所以我就讓他們先競爭，看最后哪個版本勝出，也有可能兩個版本都會長期存在。這確實算是比較有意思的變化之一。

另一個很多人提到、也有點讓人傷感的變化是：486 支持被移除了。

Dirk Hohndel：是的，很多人都在討論 486 被移除這件事。能跟我們展開講講嗎？

Linus Torvalds：現場有多少人是在 486 發布時已經出生的？

這件事該發生了。可以這么說，我對技術并不是特別懷舊。我當然支持，只要還有用戶，我們就應該盡量維護硬件支持。但到某個階段，繼續維護非常老舊硬件的成本會變成負擔。

這里的問題甚至不只是 bug，而是特性支持。我們終于要移除浮點仿真代碼了。嚴格來說，這甚至不是這次 7.1，而是下一個 7.2 版本里的事情。我們將不再支持那些在 x86 上沒有硬件浮點單元的機器。

我印象中，最后一批這樣的硬件大概是 30 年前發布的，也就是 486SX，大概是 1993 年左右。所以這真的是 30 多年前的硬件。過去我們仍然支持這類硬件平臺。它本身也許不需要很多工作，但每次你做變更時，仍然要額外考慮它。

因此，現在我們會稍微更主動地移除那些實際上已經沒有人使用、只存在于博物館環境里的硬件支持。最近類似的例子還有業余無線電 packet layer，以及一些無人維護的舊代碼，比如 ISDN、ATM 等也在逐步移除。

這也是持續改進的一部分。我們需要清理代碼庫，確保它仍然可維護。Linux 是一個非常龐大的代碼庫，它永遠不會變得“容易維護”，但至少我們不應該讓它比必要程度更難維護。

“我幾乎不寫、也不讀內核代碼了”

Dirk Hohndel：說到維護的難度，合并窗口開啟時，你其實正在飛往孟買的飛機上。也就是說，你坐在飛機座位上就開始合并代碼了。

過去幾個內核版本里，我們看到后期 RC 階段的補丁量明顯增加。那么在這次合并窗口中，是否也出現了更大規模的 merge request 更早涌入的情況？

Linus Torvalds：合并窗口確實稍微變大了一些，但沒有后期 RC 增長得那么明顯。

這里面有一個顯而易見的原因：現在有很多 AI 工具在發現問題，而這些問題隨后會被修復。有些修復不只是下一個版本的常規開發內容，而是我們有時覺得必須比較積極地修掉的問題。

但另一方面，我覺得這也有我的責任。我可能有點過于愿意接受那些并非絕對必要的修復了。上一個版本里，我基本上已經告訴大家：冷靜一點。如果不是非常重要的修復，請把它排到下一個版本，不要在最后時刻發給我。

在座很多人應該都是軟件開發者，大家應該都知道：修復確實是在修問題，但偶爾一個修復也會引入新的問題。所以這里有一個平衡。你需要判斷：是的，這是一個修復；但如果已經到了發布窗口很晚的階段，這個修復是否值得承擔它可能帶來新問題的風險？

所以我接下來會更明確地往回推一些。因為我覺得有些人已經太習慣在發布窗口很晚的時候提交修復了。尤其是內核社區的發布節奏本來就比較快，我們大約每 9 周就發布一次，所以說“我們等一下，把這個修復放到下個版本”并不是很大的問題。

如果一個修復并不是特別嚴重，而我們又對它有一點擔心，那完全可以先等幾周。我覺得過去幾個版本有點太大了，這讓我擔心方向不太對。所以現在我想把這個趨勢糾正回來。

Dirk Hohndel：那在合并 PR 的前兩天里，有什么特別突出的東西嗎？

Linus Torvalds：沒有。我一般會盡量避免在旅行期間遇上合并窗口，因為合并窗口是我最忙的時候。兩周時間里，我大概要做 200 次合并，這是一個非常粗略的數字。

這也意味著，我不想只是盲目合并。雖然我信任那些長期合作的主要開發者，有些人我甚至已經合作了 30 年，但我仍然覺得，我的工作不只是合并代碼，還要從高層次理解正在發生什么。

所以合并窗口是一個非常忙的階段，在飛機上用筆記本做這件事當然談不上有趣。但同時，它也不是一個特別讓我緊張的階段。我們的發布流程非常有組織，新代碼是一個技術問題，而技術問題不會讓我太焦慮，因為它們可以被修復。

我會經歷這兩周非常忙的時間，當然最好不要是在飛機上。但真正讓我緊張的不是代碼，而是偶爾出現的人際問題。相信我，代碼很容易修，人格問題、人際問題就不總是那么容易修了。這些事情往往更有壓力。雖然大多數時候，希望它們在外界看來是不可見的，因為我們并不想把這些事情變成媒體喜歡的沖突戲碼。

Dirk Hohndel：你剛剛說到，你希望對進入內核的內容有一個更高層次的理解。但兩周內有大約 200 個 merge request，你實際上有多少時間去讀代碼？你怎么理解這些代碼觸及了哪些領域？

Linus Torvalds：老實說，我現在幾乎不讀代碼了。我已經不是一個程序員了，我更像是一個開發負責人。我知道怎么寫程序，也仍然會為了興趣寫代碼。但我出于興趣寫的那些項目并不是內核，而是一些我私下玩的玩具項目。

在 Linux 內核上，我依賴的是信任。我認為開源本身也依賴信任。我們彼此認識，一起工作了很多年，有時甚至是幾十年。我合并的這大約 200 個 pull request，都是來自我長期合作、并且信任的人。

當你面對 3500 萬行代碼時，沒有人能真正理解全部代碼。所以對我來說，處理 pull request 時，我想理解的是大圖景。這也是為什么我要求 pull request 必須有非常好的解釋說明，因為我會認真讀這些說明。

我想知道發生了什么。這樣，當之后出現問題時，即便我當時沒有讀過具體代碼，我也能想起來：好，我大概知道這是什么方向的問題，也知道應該去看哪部分代碼。

這就是我現在工作的層級。我已經很多年沒有真正寫“真實代碼”了。

Dirk Hohndel：但你還是寫一些小東西吧？

Linus Torvalds：我仍然會寫代碼，意思是我會給別人發 patch。有時我會發一個很小的建議性修復，然后說：也許可以這樣做。

但我會非常明確地說明：這只是一個建議，沒有經過測試。也許我編譯過它，有時甚至可能運行過它，但我期待真正維護那部分代碼的人來判斷，并最終把修復發回來。

所以我現在很少直接提交自己的代碼。當然，這種情況也會發生，但已經相當少了。

Dirk Hohndel：你說你不怎么看代碼，這一點很有意思。因為維護者想要獲得你“全神貫注關注”的方式之一，就是提交一個會破壞構建的 pull request。那時你就會去看代碼，而且你一向以非常“友好和理解”的方式指出問題。

Linus Torvalds：我正在努力變得更好。但確實，我會看代碼。比如在合并過程中出現沖突時，我會看代碼。這種情況一直都會發生，也不是問題。有些人認為沖突很難，但這么多年下來，我已經處理過太多沖突，可能睡著了都能解決。我不擔心這個部分。

不過，當我看到沖突時，它通常意味著兩個不同小組在同一塊代碼區域同時工作。這時我確實想看一看他們分別在做什么。很多時候，我看代碼時會發現一些問題，而這些問題正是因為兩個團隊同時修改同一部分代碼、但目標不同所造成的。

另外，當某個 pull request 的解釋不夠充分時，我也會去看代碼。有人給我發 pull request，但說明不清楚，我經常會直接看代碼。然后有時我會覺得：哦，原來如此，這說得通。有時則完全說不通，那我就會反對。

所以，是的，我也許已經不再是嚴格意義上的程序員，但我仍然有足夠強的技術背景。看到代碼時，我仍然能夠做判斷。

不要以為 Rust 能修掉所有 bug

Dirk Hohndel：我們剛才談到，Linux 在 20 年前切換到了現在這套開發模式，其中一個重要原因就是 Git 的出現。Git 現在仍然是你處理所有事情的主要工具嗎？你還會使用其他工具嗎？有沒有你希望擁有但現在沒有的工具？

Linus Torvalds：對我個人來說，Git 和郵件基本上就是我真正使用的兩個工具。

當然，我也會用 Google 來查東西。也許你們中有人是超人，可以記住行業里所有三字母縮寫，但我不是。有人給我發解釋，他們可能工作在某個我不熟悉的角落，然后使用那個領域里的各種縮寫和簡寫。我會想：這到底是什么？這時候我就會用 Google。

所以從這個意義上說，Google 也是我使用的工具。但大部分時間，我就是讀郵件，然后用 Git 做合并。這是我的主要工具。

不過我也要指出，我是一個比較特殊的例子。大多數其他維護者會使用更多工具。我認為很多人已經開始使用 AI 工具做 patch 檢查。但因為我聲稱自己是在更高的層次上工作，我面對的是人，而不是工具。

這也是為什么我一直強調，最重要的是信任，是信任那個人。我信任的是具體的人。幾十年來都是這樣。開發者會從一家公司跳到另一家公司，我并不關心他們用什么郵箱，也不關心他們在哪家公司工作，因為我信任的是這個人，相信他能做出判斷。

我認為很多項目都是這樣運作的，但在開源里尤其如此。在公司內部，你可能因為某個人和你在同一家公司，所以信任他；但在開源里，你信任一個人，是因為你和這個人一起工作了很長時間。

Dirk Hohndel：Git 當然也是你啟動的另一個重要項目。這個月，Git 決定讓 Rust 成為默認開啟的選項，雖然它目前仍然是可選的；而在下一個版本 Git 3 中，Rust 將成為要求。你認為這種情況會出現在更多領域嗎？內核現在也已經把 Rust 作為官方允許和支持的編程語言之一。

Linus Torvalds：我不確定 Rust 會接管整個世界。我仍然認為 Rust 非常有意思。但與此同時，我仍然覺得 C 是一個簡單得多的工具。所以我個人其實更興奮的是，現在我們有了很多用于驗證 C 代碼的工具。

很多靜態分析工具已經存在很多年了，但我很喜歡的是，現在我們開始有一些自動化補丁驗證工具，它們確實帶來了實際價值。它們不一定能帶來 Rust 那種意義上的安全性，但它們相當于給傳統 C 代碼里人們常犯的錯誤多加了一雙眼睛。所以，對正在出現的這類工具，我其實非常興奮。

Dirk Hohndel：我們現在也有一些針對補丁的自動郵件檢查工具，比如 Sashiko。

Linus Torvalds：對。我一直覺得，C 就像一把鏈鋸，而 Rust 更像是一臺帶有嚴格控制的 CNC 機床。不同的人適合不同的工具。有些人就是更適合鏈鋸，而我更像是喜歡直接上手、一路砍過去的那種人。我仍然喜歡 C 那種原始、簡單但強大的力量，而且我不認為這一點會改變。

不過回到 Git。對我來說，Git 的目標之一從來不是 C 本身。C 不是問題，C 只是一個實現選擇，因為那是我一直使用的語言。

我真正希望 Git 擁有的是少數幾個非常高層次的概念，這些概念可以解釋整個架構。你其實可以從很早期的 Git 歷史里看到這一點。我們不只有 C 版本，也有 Java 版本。很多公司后臺其實都在運行 Java 版本，因為在服務器環境里，一個 Java 版本的 Git 通常非常方便。

所以，Git 現在支持 Rust，我認為這并不像 Rust 進入內核那樣是一個巨大的變化。因為 Git 早就已經有多種不同語言并存的情況。

Dirk Hohndel：你這么說很有意思。Rust 現在已經被推向很多領域。我們已經看到一些人用 LLM 把現有工具重寫成 Rust，也已經看到一些相當糟糕的 bug，比如 Ubuntu 25.10 的自動更新問題。這件事你怎么看？

Linus Torvalds：公平地說，Rust 的確可以避免一些你在 C 里面容易犯的簡單錯誤，但它不會修復邏輯錯誤，對吧？它不會替你思考。

如果你寫的是錯誤代碼，那么語言本身并不重要，最后結果仍然會是錯的。所以我完全不反對 Rust，但我也想降低大家的預期：不要以為 Rust 能修掉所有 bug。

Rust 確實能修掉幾類 bug，讓這些 bug 更難出現。但你仍然可以犯很多邏輯錯誤。事實上，最近內核里一些比較大、比較受關注的 bug，就是邏輯錯誤。它們不是內存安全問題，也不是某種微妙的語言問題，就是糟糕的編程。而遺憾的是，即使在維護非常謹慎的子系統里，這種事情也會發生。即使是那些很重要、理論上應該非常安全的內核代碼里，也會發生。

所以，不要期待一門語言能神奇地替你修掉所有 bug。

Dirk Hohndel：這里還有一個問題。在內核、Git 這類工具的過渡階段，C 代碼和 Rust 代碼會互相交互。Rust 給你的那些保證，只適用于代碼庫里純 Rust 的部分。一旦你和 C 代碼交互，這些保證就不再完全成立了。

Linus Torvalds：公平地說，大多數和 C 代碼交互的 Rust 代碼，交互的是內核里的核心 C 代碼。而這些核心代碼的質量通常比外圍的一些 C 代碼要高得多。

我這么說不是因為寫這些代碼的人更聰明，或者是更好的程序員，而是因為這些代碼已經在各種環境下被測試過。它們太核心了。無論你做什么，都會和內存管理、核心內核代碼之類的東西打交道。所以這些代碼已經在 Linux 支持的每一個平臺上被測試過。

但另一方面，很多單獨的驅動程序，只有當你擁有特定硬件時才會被測試。所以在內核里，代碼的可靠程度確實是不一樣的。我認為，Rust 側現在接觸到的很多 C 代碼，恰恰是更穩定、更成熟的核心代碼。

Dirk Hohndel：內核本身也有這樣的結構：有些代碼經過了大量測試，有些實驗性代碼可能沒有測試得那么充分。還有我們前面提到的，一些更老的代碼因為硬件已經不常見，甚至已經不存在了，所以也不太常被使用。

比如有多少人在自己的 S390 上跑 Linux，我不知道。但我不認為那是大型機上運行的主要操作系統。所以我覺得，測試最多、審查最多、最值得信任的代碼，往往是所有人都依賴的核心代碼。是這樣嗎？

Linus Torvalds：是的。而且這類代碼通常也是被最多人看到的代碼。即使你是一個驅動開發者，通常也需要了解一點核心代碼。你需要知道內核里的內存分配是怎么工作的，所以你至少會看過那些接口。

但反過來就不一定成立。如果你維護的是核心 VFS 層之類的東西，你可能永遠不會去看某一個具體的驅動。

所以我確實會鼓勵那些想進入內核開發的人從驅動開始。因為那里有很多……我不想說“問題”，但那里確實有很多邊緣情況。

Dirk Hohndel：我們可以稱之為學習機會。

AI 可以帶來 10 倍提效？

Linus Torvalds：對，學習機會。但與此同時，我也想提醒大家，內核真的很大。它不是最容易上手的項目。所以我也想稍微降低大家的預期。我們對新開發者有相當嚴格的規則，也有固定的做事方式。

Dirk Hohndel：我想先鄭重指出一下：我們已經聊了很多內容了，但居然還沒有談到 AI 和 LLM。不過我覺得，這可能是本次會議里唯一一場能堅持這么久才談 AI 的對話。當然，我們還是應該談談這個話題。一個月前，我們在明尼阿波利斯也做過一場類似形式的對談。那次有很多人注意到，你在臺上說，你認為 LLM 只是一個工具。這個觀點我完全同意。

你當時還說了一句很有意思的話：你說它可能帶來 10 倍的增量效率。然后很多人就說，“哦，Linus 認為 LLM 能讓一切都變好 10 倍。”

所以我很好奇，你當時說的那個 10 倍，到底是什么意思？

Linus Torvalds：那不是科學數字，顯然，那就是我隨口拍出來的數。

Dirk Hohndel：本來這是后面兩個問題之后才要問的。所以換句話說，那是你憑直覺給出的一個數字。那么 LLM 到底提供了多少真實的增量價值？

我們剛才說，核心代碼會得到更多人的關注。但 LLM 可以把同樣的審查力度、同樣的算法、同樣的邏輯測試能力應用到所有代碼上。你覺得 LLM 現在能在多大程度上為 Linux 內核社區帶來生產力提升？我說的不是對你個人，而是對整個內核社區。

Linus Torvalds：現在我們大概處在這樣一個階段：希望它創造的生產力已經超過它消耗掉的生產力。

直到今年年初左右，我們看到的 LLM 生成內容里，垃圾內容肯定比有用代碼多。即使到現在，它仍然會占用開發者很多資源。

因為你會收到一些 bug 報告。我不知道在座有多少人在自己的工作中見過這種模式。我敢打賭，或者說我知道這種情況不只發生在內核里：你會收到一個看起來完全合理的 bug 報告，但你可能要花相當多精力，最后才發現它其實只是幻覺。

當人類需要花很多時間去判斷一個機器生成的報告是不是真的時，這會非常消耗資源。

但與此同時，過去幾個月里確實發生了一個變化：我們開始收到很多非常好的 bug 報告。不過，大多數好的報告并不只是 LLM 自己生成的。它們需要一個人去檢查 AI 生成的報告，確認它是有效的，并且在修復問題的開發者之間扮演中間人的角色。

我們也不得不反復提醒一些人：如果你用 LLM 找到了一個 bug，并不意味著你只要讓 LLM 寫一份 bug 報告，然后把它扔給我們就夠了。

我們希望看到一個建議性的補丁。我們也希望運行 LLM 的那個人能夠參與往返溝通。我們需要有人可以討論問題。

有些時候，補丁只是一個非常簡單、顯而易見的一行修改。但很多時候，問題會變成：我們過去沒有考慮到這個問題，要真正修好它，需要重新組織一些代碼，需要投入一些精力。

這時候，你就非常希望最初提交報告的那個人能參與進來。開發者可能會回來問：“這是我們建議的修復方案，你的 LLM 怎么看？”

對復雜系統要有敬畏之心

Dirk Hohndel：你剛才描述的其實指出了一個很多人容易忽略的區別。LLM 現在非常擅長找 bug。作為一種攻擊工具，或者說作為一種發現問題的工具，它們已經強了很多。尤其是過去六個月，我們確實看到了一些明顯進步。

但另一方面，如果是讓它們生成 Linux 內核這個級別所要求的可靠代碼，我仍然沒有完全被說服。我一直覺得，LLM 很擅長“從零到 demo”。你可以很快做出一個演示。但“從零到生產級代碼”，我不確定它一定會做得更快。

Linus Torvalds：是的。我個人會在自己的玩具項目里使用 LLM，而且我確實很喜歡這一點。我把它們當作原型工具。

比如我會說：我想試試這個東西，但這只是我的玩具項目，如果完全自己寫，成本太高，而且我還不確定它能不能行。于是我就讓 LLM 幫我做。很多時候，生成出來的代碼并不能直接使用，但它是一種很好的試驗方式。我希望大多數人今天也是這樣使用 LLM 的。

我同意，當我們看到 AI 生成的 bug 報告時，有時也會收到 AI 生成的補丁。在簡單情況下，這些補丁完全沒問題。

但很多時候，它們更像是沒有思考的“創可貼式”補丁。它們沒有修復底層問題。它們可能修掉了眼前的問題，但同類 bug 還在那里，只是在走廊里等著從另一個地方跳出來打你。

這類修復往往需要那些長期維護代碼、真正理解代碼的維護者和開發者來處理。以我的經驗，LLM 還沒有達到這個層次。

當然，這未來可能會改變。也許有一天你可以告訴它：“請看大局，請真正把這個問題修好，請表現出一點好的工程品味。”但至少現在，大多數時候還缺少這種品味。

我認為，對 LLM 進行反復提示，確實常常能幫助它生成更好的質量。但至少在今天，它們還不能替代那種來自經驗的架構級知識。

Dirk Hohndel：是的，你確實需要一個理解大局的架構師。出于個人好奇，在座大概有一半人看起來像軟件工程師。你們當中有多少人每天都在使用 LLM？

Linus Torvalds：顯然，AI 有很多很好的用例。我們剛剛談到了它在 bug 方面帶來的變化。有些被發現的問題不只是在當前代碼里，有些甚至可以說非常驚人。當然，是以一種痛苦的方式驚人。

別誤會，bug 從來都不好玩。如果是安全相關的 bug，而且兩天后就出現在科技媒體上，那就更不好玩了。

但與此同時，我絕不是那種“射殺信使”的人。我認為，LLM 能找到 bug，對我們來說整體上是一件好事。即使這些 bug 讓人尷尬，即使它們是我們可能 20 年前就應該發現的長期存在的嚴重 bug，最終它們被發現仍然是好事。

當下可能會有點痛苦，但最終我們會因此變得更強。只是過去幾個月確實有點痛苦，因為 LLM 指出了幾個相關的 bug。這并不奇怪：一個人發現一個 bug 后，另一個人就會去問 LLM：“那這個相似區域呢？”

所以我們才會在幾周內看到三四個關系非常緊密的 bug 變成大新聞。

原視頻鏈接：

https://www.youtube.com/watch?v=YKkEe-PxW10

聲明：本文為 InfoQ 編譯，不代表平臺觀點，也不構成投資建議，未經許可禁止轉載。

會議推薦

大會限時早鳥票享 8 折專屬優惠，現在報名立減 1160，更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。