“如果我們必須用對底層的絕對掌控來換取物理極限的性能，那么 C++ 依然是這個星球上無可替代的語言?！?/p>

嘉賓| David Sankel 采訪 | 吳詠煒

責(zé)編｜夢依丹

出品 | AI 科技大本營（ID: rgznai100）

在 Rust 強(qiáng)勢崛起、AI 編程重塑開發(fā)范式的今天，C++ 這座歷經(jīng)四十載風(fēng)雨的編程大廈，似乎正面臨著前所未有的生存拷問。

• 內(nèi)存安全漏洞是否真的無解？

• AI 生成的代碼究竟是福音還是隱患？

• 當(dāng)“未定義行為”從優(yōu)化的基石變?yōu)榘踩膲趑|，C++ 標(biāo)準(zhǔn)委員會又將如何應(yīng)對？

帶著這些尖銳而深刻的問題，在 2025 全球 C++ 及系統(tǒng)軟件技術(shù)大會的采訪間，奇點(diǎn)智能研究院首席技術(shù)咨詢師吳詠煒與 Adobe 首席科學(xué)家、C++ 標(biāo)準(zhǔn)委員會資深委員 David Sankel 展開了一場直擊痛點(diǎn)的深度對話。

左：吳詠煒，右： David Sankel

如有興趣觀看完整視頻，可在文末獲取

David Sankel 沒有回避任何一個敏感話題。從揭示“新代碼比舊代碼更脆弱”的反直覺真相，到坦陳 C++ 在工具鏈生態(tài)上被 Rust“降級打擊”的無奈，再到對 AI 編程助手“既依賴又懷疑”的矛盾心態(tài)，Sankel 以一位頂尖語言設(shè)計者的視野，為我們抽絲剝繭，還原了一個真實(shí)、復(fù)雜且充滿生命力的 C++ 世界。

這不僅是一場關(guān)于技術(shù)的探討，更是一次關(guān)于如何在不確定的技術(shù)浪潮中尋找確定性的思想碰撞。

以下為對話全文：

吳詠煒：嗨 David，歡迎來全球 C++ 及系統(tǒng)軟件技術(shù)大會的采訪間。請你先向大家打個招呼。

David Sankel：大家好。真的很高興能來到這里，感覺特別棒。

吳詠煒：首先，我們來探討一下現(xiàn)代代碼與遺留系統(tǒng)的安全性問題。你在本次大會演講中提到了一個耐人尋味的趨勢：大多數(shù)內(nèi)存安全漏洞源于新編寫的代碼，而不是遺留系統(tǒng)。 你認(rèn)為這是什么原因造成的？是因?yàn)檎Z言固有的復(fù)雜性、對現(xiàn)代特性的誤用、開發(fā)者經(jīng)驗(yàn)不足，還是工程流程和工具鏈存在缺口？

David Sankel：這個現(xiàn)象的核心在于“代碼硬化”（Code Hardening）的過程，它通常只發(fā)生在那些長期承受巨大安全審查壓力的舊代碼上。

以 Zlib 這個古老的 C 語言庫為例，多年來，無數(shù)人都在積極地試圖攻破它。在這個過程中，絕大多數(shù)潛在的漏洞都已經(jīng)被挖掘并修復(fù)了。只要這種對抗性的壓力持續(xù)存在，代碼就會隨著時間的推移變得越來越堅固。

漏洞出現(xiàn)在新代碼中的原因，實(shí)際上僅僅是因?yàn)檫@些代碼還沒有時間在那種對抗性壓力下經(jīng)過“歷練”。這完全是關(guān)于漏洞生存周期的問題。如果你看看舊的 Zlib 代碼剛出來的時候，它也有成噸的漏洞，那時候的“遺留代碼”在當(dāng)時也是“新代碼”。這似乎只是公共領(lǐng)域軟件的一種現(xiàn)象，因?yàn)槿藗兛偸窃谠噲D攻擊它。

因此，這主要是一個成熟度的問題：代碼越成熟，Bug 自然越少。

這種現(xiàn)象積極的一面是，我們不需要回頭去處理所有的代碼庫。如果你拿 Adobe Photoshop 來說，它有 6800 萬行代碼，我們無法回頭去修復(fù)所有那些舊代碼。但好消息是，我們其實(shí)不必像防范新代碼那樣去焦慮舊代碼。我們將防御重點(diǎn)集中在新引入的代碼上，這讓內(nèi)存安全問題從一個“不可能完成的任務(wù)”變成了一個“可控的工程問題”。

吳詠煒：我們知道，在 C 語言中，由于開發(fā)者通常需要直接管理定長數(shù)組和原始內(nèi)存，緩沖區(qū)溢出這類問題非常普遍。理論上，C++ 引入了許多現(xiàn)代特性，本應(yīng)大幅降低此類風(fēng)險。但現(xiàn)實(shí)數(shù)據(jù)卻表明，我們依然面臨著大量的內(nèi)存相關(guān)漏洞。為什么在機(jī)制更完善的 C++ 中，這類問題依然無法根除？

David Sankel：C++ 確實(shí)通過引入高級抽象降低了內(nèi)存安全漏洞的發(fā)生頻率，但這并不意味著它從根本上消除了隱患。

現(xiàn)實(shí)情況是，工程師仍然很容易寫出導(dǎo)致越界訪問的代碼。過去是對 C 風(fēng)格數(shù)組的越界，而現(xiàn)在的“現(xiàn)代版本”則是對 std::vector 的越界訪問——其本質(zhì)依然是相同的內(nèi)存安全問題。 再比如使用未初始化的變量，這種風(fēng)險在 C++ 中也并未消失。

歸根結(jié)底，C++ 繼承了 C 語言的底層內(nèi)存模型和許多“不安全”的基因。只要這些從 C 語言遺留下來的底層機(jī)制仍然被允許使用，或者現(xiàn)代容器的使用方式缺乏強(qiáng)制性的安全約束，內(nèi)存安全漏洞的溫床就依然存在。

吳詠煒： 相比十年前，我們現(xiàn)在擁有了強(qiáng)大得多的動態(tài)分析工具。比如 Memory Sanitizer (MSan)、Address Sanitizer (ASan)、Thread Sanitizer (TSan) 以及 Undefined Behavior Sanitizer (UBSan) 等等

David Sankel：你說得完全正確。問題是：這些工具是否在 C++ 生態(tài)系統(tǒng)中被普遍使用了？遺憾的是，我認(rèn)為答案是否定的。

阻礙工具普及的原因可以分為兩類。一類是主觀因素——比如開發(fā)者缺乏認(rèn)知，或者根本不在乎；但更關(guān)鍵的，是一類非?，F(xiàn)實(shí)的客觀門檻：這些工具的配置成本極高。

要想讓這套 Sanitizer 組合在構(gòu)建系統(tǒng)中完美運(yùn)行，需要付出巨大的工程代價。這往往要求你在項(xiàng)目啟動之初就具備極高的前瞻性，并投入資源去配置基礎(chǔ)設(shè)施。但在項(xiàng)目早期，你甚至不知道它能不能存活下去，往往無暇顧及這些。

這就導(dǎo)致了一個典型的“成功悖論”：等到你的開源庫大獲成功、被廣泛采用時，它可能一直是在沒有 Sanitizer 保護(hù)的“裸奔”狀態(tài)下開發(fā)的。突然之間，潛伏的漏洞隨著你的庫擴(kuò)散到了整個生態(tài)鏈。

更糟糕的是，即便你現(xiàn)在亡羊補(bǔ)牢加上了防護(hù)，下游用戶依然可能在使用你的舊版本代碼。為什么？因?yàn)樵?C++ 生 態(tài)中，依賴管理和版本升級是一項(xiàng)昂貴的工程活動。用戶往往因?yàn)樯壋杀具^高而停留在有漏洞的舊版本上，導(dǎo)致問題持續(xù)存在。

吳詠煒：但我認(rèn)為你的論點(diǎn)可能是我們不想用 C++ 寫新代碼。但其實(shí)，我們完全可以在新代碼中使用這些工具，而不是在舊代碼中，因?yàn)榕f代碼可能有更多的兼容性問題。在新代碼中，我們絕對可以使用新工具。

David Sankel：你的論點(diǎn)建立在一個關(guān)鍵假設(shè)之上：即只要使用了這些新工具，就能解決所有、或者至少絕大部分的內(nèi)存安全漏洞。 誠然，它們能大幅緩解問題，但現(xiàn)實(shí)數(shù)據(jù)卻給我們潑了一盆冷水。

讓我們看看 Google 的數(shù)據(jù)。在 Android 系統(tǒng)開發(fā)中，他們擁有世界頂級的工程師團(tuán)隊，并且在 C++ 開發(fā)流程中強(qiáng)制啟用了所有的 Sanitizer 和最佳實(shí)踐。即便武裝到了這種程度，他們依然持續(xù)發(fā)現(xiàn) C++ 代碼中的內(nèi)存漏洞。

更令人震驚的對比來自于他們引入 Rust 之后的數(shù)據(jù)：在同樣的嚴(yán)苛標(biāo)準(zhǔn)下，C++ 代碼產(chǎn)生的內(nèi)存安全漏洞數(shù)量幾乎是 Rust 代碼的 1000 倍。

這是一個非?！坝病钡臄?shù)據(jù)。它揭示了一個殘酷的現(xiàn)實(shí)：工具只能緩解癥狀，卻無法根治病灶。

如果單靠打開 Sanitizer 就能徹底解決問題，那么 Google 根本不需要大費(fèi)周章去引入新語言。既然連擁有最強(qiáng)技術(shù)實(shí)力的 Google 都無法在 C++ 中徹底封堵這些漏洞，這本身就證明了這是一個極其艱深、甚至可能是目前范式下無解的難題。

再舉個身邊的例子，我團(tuán)隊里的 Sean Parent——他是公認(rèn)的 C++ 泰斗級人物——依然會踩進(jìn)內(nèi)存安全的坑里。有一次他在處理復(fù)雜的模板元編程時，面對層層封裝的抽象，想要搞清楚一個深埋其中的 auto&& 到底推導(dǎo)出來的是一個右值引用還是一個指向局部變量的懸垂引用，簡直難如登天。

吳詠煒：是的，我認(rèn)為抽象是一個大問題，會讓測試 constexpr 函數(shù)變得很難……我認(rèn)為模板元編程還要更難。實(shí)際上，我最近也遇到了一個這樣的問題，也是在元編程中。我實(shí)際上立即發(fā)現(xiàn)了問題，因?yàn)槌绦虮赖袅恕５宄栴}到底在哪真的很難，因?yàn)閱栴}隱藏得很深，而且僅在某些特殊場景里才出現(xiàn)。

David Sankel：對，他的情況也是一模一樣的。

吳詠煒： 好的，讓我們轉(zhuǎn)向下一個關(guān)于 C++ 價值主張的問題。如今 Rust 憑借“內(nèi)存安全”特性迅速崛起，Python 在 AI 時代更是占據(jù)主導(dǎo)，也確實(shí)吸走了一部分原本依賴 C++ 的用戶。但在游戲引擎、系統(tǒng)底層、高性能計算等核心場景，C++ 依舊穩(wěn)固。在你看來，C++ 最核心、最不可替代的優(yōu)勢是什么？為什么這些優(yōu)勢至今仍難被其他語言取代？

David Sankel：我認(rèn)為 C++ 擁有一個任何人都奪不走的“利基市場”（Niche），其核心價值主張在于：它允許開發(fā)者通過承擔(dān)“未定義行為”（Undefined Behavior）的風(fēng)險，來換取絕對極致的性能。

讓我用一個最近看到的對比案例來說明。有一段 C++ 代碼執(zhí)行某種整數(shù)運(yùn)算，這其中可能隱含著溢出或除以零的風(fēng)險。但在編譯器的優(yōu)化下，這段代碼被極致精簡為一條匯編指令：一個移動加一個加法。

代價是： 如果輸入數(shù)據(jù)錯誤，程序行為完全不可控（未定義）。

收益是： 如果你能保證數(shù)據(jù)正確，它就是物理上能達(dá)到的最快速度。

當(dāng)開發(fā)者試圖在 Rust 中復(fù)刻這段代碼時，困難出現(xiàn)了。Rust 的安全機(jī)制強(qiáng)制要求檢查“除以零”和“整數(shù)溢出 panic”。為了讓 Rust 代碼達(dá)到和 C++ 一樣的指令級效率，開發(fā)者不得不使用大量的 unsafe 塊、特殊的編譯器提示（Hint）和注解。最終，性能確實(shí)追平了，但代碼量膨脹了四倍，且可讀性大打折扣。

這正是 C++ 的生存空間所在——當(dāng)你愿意接受這種激進(jìn)的權(quán)衡時：

• 如果你在搞高頻交易（HFT），那么程序因?yàn)闃O小概率的錯誤數(shù)據(jù)崩潰了，也許可以接受；但如果為了安全檢查拖慢了每一筆交易的速度，那就是不可接受的。開發(fā)者只要最純粹、最快的機(jī)器碼，任何額外的安全檢查都被視為累贅；

• 同樣在游戲開發(fā)方面，游戲如果出現(xiàn)了一個渲染錯誤，或者像素偏了一點(diǎn)，甚至偶爾崩潰重啟，玩家也許能忍受。但如果為了代碼安全導(dǎo)致幀率下降、開發(fā)效率變慢（因?yàn)橐獙懛爆嵉陌踩⒔猓?，那是開發(fā)商無法接受的。

除了這種對性能的極致追求，C++ 另一大支柱是歷史慣性。

以科學(xué)計算領(lǐng)域?yàn)槔珻++ 的地位并不完全因?yàn)樗Z言設(shè)計得多好，而是因?yàn)槟抢镆呀?jīng)沉淀了海量的成熟代碼。這就像 Fortran 一樣——至今像 LAPACK 這樣的 Fortran 庫仍是數(shù)值計算的基石。它們經(jīng)過了數(shù)十年的優(yōu)化，極其穩(wěn)定高效，沒有任何商業(yè)理由去重寫它們。

C++ 也是如此。只要這些龐大的遺留代碼庫（Legacy Codebase）還在運(yùn)行，只要沒人愿意支付天文數(shù)字般的重寫成本，C++ 就將繼續(xù)作為這些領(lǐng)域的中流砥柱存在下去。

吳詠煒：這引出了一個關(guān)于開發(fā)生產(chǎn)力（Productivity）的有趣悖論。剛才你提到，為了在 Rust 中追求極致性能（對齊 C++ 的匯編級優(yōu)化），代碼量可能會膨脹四倍，這意味著生產(chǎn)力大幅下降。但另一方面，業(yè)界許多報告又聲稱 Rust 程序員的生產(chǎn)力顯著高于 C++。

這兩個截然相反的結(jié)論同時存在，是否存在矛盾？也許，這是因?yàn)樗鼈儜?yīng)用于不同的領(lǐng)域（domain）？

David Sankel：這絕對是領(lǐng)域決定的，不存在矛盾。關(guān)鍵在于你是否在順應(yīng)語言的設(shè)計哲學(xué)。

如果你試圖逆著 Rust 的性子來——比如非要像寫 C++ 那樣去寫充斥著裸指針和極致微操的“不安全代碼”——那么是的，你會痛苦萬分，生產(chǎn)力會暴跌。

但如果你順勢而為，利用 Rust 擅長的領(lǐng)域——比如進(jìn)行高層邏輯組裝、編寫默認(rèn)安全的業(yè)務(wù)代碼，或者通過安全的接口調(diào)用底層高性能庫——你會感受到前所未有的生產(chǎn)力飛躍。

讓我舉一個讓我深受震撼的親身經(jīng)歷：

有一次我在寫 Rust 項(xiàng)目，突然覺得如果能嵌入一個 JavaScript 解釋器會很棒。在 Rust 里我是怎么做的？我只需要在 Cargo.toml 配置文件里加了一行代碼，引入一個現(xiàn)成的 Crate（庫）。幾秒鐘后，我就擁有了一個功能完備的 JS 解釋器。

試想一下，如果在 C++ 里做同樣的事，會是怎樣的噩夢？

我要找一個合適的 C++ JS 引擎庫。

我要搞定它復(fù)雜的依賴項(xiàng)。

我要想辦法讓它的構(gòu)建系統(tǒng)兼容我自己的構(gòu)建系統(tǒng)。

我還要處理鏈接、頭文件路徑等一堆瑣事。

在 C++ 里，這是一個天文數(shù)字級的工作量；而在 Rust 里，只是“加一行配置”的事。

所以，Rust 所謂的生產(chǎn)力優(yōu)勢，很大程度上并不在于語言語法本身，而在于其現(xiàn)代化的包管理生態(tài)系統(tǒng)。Cargo 對于 C++ 開發(fā)者來說，簡直是降維打擊般的體驗(yàn)提升。

吳詠煒：確實(shí)，C++ 的痛點(diǎn)不僅僅在于沒有統(tǒng)一的包管理器，更深層的原因在于底層的二進(jìn)制不兼容性。我們有 GCC、Clang、MSVC 等不同的編譯器，它們各自有一套不兼容的名稱修飾（Name Mangling）規(guī)則和調(diào)用約定（Calling Conventions）。這導(dǎo)致在 C++ 中分發(fā)預(yù)編譯庫（Pre-built Binaries）幾乎是不可能的任務(wù)，每個人都必須從源碼重新編譯。

David Sankel：沒錯，編譯器生態(tài)的碎片化是一個巨大的阻礙。在 C++ 中，哪怕僅僅是“打包一個庫”這樣看似簡單的動作，都充滿了技術(shù)挑戰(zhàn)。

這里有一個非常深刻的對比。Rust（以及幾乎所有現(xiàn)代語言）從誕生之初就吸取了一個教訓(xùn)：工具鏈必須是語言設(shè)計的一等公民。

C++ 只有語言本身（語法和標(biāo)準(zhǔn)庫）被 ISO 標(biāo)準(zhǔn)化了。至于如何構(gòu)建、如何管理依賴、如何生成文檔……所有這些工具鏈層面的東西，標(biāo)準(zhǔn)委員會采取了“放任自流”的態(tài)度。

這種差異導(dǎo)致了結(jié)果的天壤之別。以文檔為例：

在 Rust 生態(tài)中，官方直接提供了 rustdoc。因此，整個社區(qū)只有一種文檔標(biāo)準(zhǔn)，每個人都用同樣的方式編寫注釋，每個人都用同樣的工具生成頁面。這種同質(zhì)化（Homogeneity）帶來了極大的便利——對于任何一個第三方庫，我閉著眼睛都知道去哪里找文檔，也知道文檔結(jié)構(gòu)長什么樣。而在 C++ 中，這完全是混亂的。

吳詠煒：但我并不認(rèn)為在 C++ 現(xiàn)有的體系下這具有可行性。坦白說，我甚至反感由 ISO 這樣的機(jī)構(gòu)去強(qiáng)行標(biāo)準(zhǔn)化工具鏈或文檔工具。在我看來，這根本就是不可能完成的任務(wù)。

David Sankel：問題的關(guān)鍵其實(shí)不在于組織是否“正式”，而在于產(chǎn)出物的性質(zhì)。ISO 標(biāo)準(zhǔn)化流程的核心職能非常單一：發(fā)布規(guī)格說明書（Specification）。僅此而已。

反觀 Rust 的組織方式，它完全是另一種范式。Rust 不僅僅發(fā)布類似規(guī)格的 Rust Reference，它更核心的產(chǎn)出是軟件成品。所有這些軟件與文檔的集合體，才構(gòu)成了我們認(rèn)知中的“Rust”。它不僅僅是一紙標(biāo)準(zhǔn)，而是一個完整的產(chǎn)品交付。

這就是兩者最根本的區(qū)別。ISO 的設(shè)立初衷就不是為了開發(fā)和維護(hù)軟件產(chǎn)品。如果我們試圖強(qiáng)行通過 ISO 流程來構(gòu)建一套統(tǒng)一的 C++ 工具鏈，結(jié)果注定會是一場災(zāi)難。這不僅違背了 ISO 的基因，在實(shí)際操作層面上也完全不可行。

吳詠煒：另一件事是，C++ 的模板特化（Template Specialization），它讓 C++ 在某種程度上完美契合了“開閉原則”（Open-Closed Principle）：你可以在完全不修改現(xiàn)有通用模板代碼的前提下，為特定類型提供擴(kuò)展實(shí)現(xiàn)。

然而，Rust 似乎并沒有這種全功能的特化機(jī)制，卻依然發(fā)展得很好。這是否意味著，特化這個優(yōu)勢其實(shí)并沒有顯現(xiàn)出來？還是說 Rust 有其他的替代方案？

David Sankel：這一點(diǎn)非常有意思。當(dāng) Sean Parent 和我的團(tuán)隊開始集體學(xué)習(xí) Rust 時，他直接切入了最硬核的元編程部分。

幾乎是立刻，他就指出了這個痛點(diǎn)：“Rust 沒有特化。如果沒有特化，你就無法進(jìn)行真正的泛型編程。” 這對習(xí)慣了 C++ 強(qiáng)大元編程能力的專家來說，確實(shí)是一個巨大的沖擊。

吳詠煒：這就是我不喜歡 Rust 的地方。所以我想聽聽你的看法。也許那真的沒那么重要？或者怎么說？

David Sankel：我必須承認(rèn)，與 C++ 相比，這確實(shí)是 Rust 的一個顯著短板。不僅沒有特化，Rust 目前也缺乏可變參數(shù)模板。這就導(dǎo)致你經(jīng)常需要用笨辦法繞路——比如為了支持不同數(shù)量的參數(shù)，你得手動把一個函數(shù)復(fù)制粘貼寫很多個版本。

這種感覺讓我恍惚間回到了原始的 C++98 時代。但這并非設(shè)計者的疏忽，而是深層機(jī)制權(quán)衡的結(jié)果。Rust 引入了嚴(yán)格的借用檢查器，并且采用了受檢泛型（Checked Generics）模型。

在 C++ 中，即便你定義了 Concept，如果你在模板函數(shù)里偷偷用了一個 Concept 沒聲明的操作，只要實(shí)例化時的具體類型支持這個操作，C++ 編譯器通常也就睜一只眼閉一只眼放行了。

在 Rust 中（受檢泛型），編譯器極其嚴(yán)格。它強(qiáng)制要求泛型函數(shù)內(nèi)部只能使用 Trait（對應(yīng) C++ 的 Concept）中顯式聲明的接口。這雖然帶來了極佳的接口契約保證，但也使得實(shí)現(xiàn)“特化”和“可變參數(shù)”在理論上變得異常困難。

目前，Rust 社區(qū)雖然有一些關(guān)于如何實(shí)現(xiàn)這些特性的構(gòu)想，但尚未落地，這仍是一個未解的難題。

所以歸根結(jié)底，這就是一種取舍問題，你想要受檢泛型帶來的類型安全和清晰契約，就不得不暫時忍受特化能力的缺失。你得自己權(quán)衡這種交換是否劃算。

吳詠煒：那么在你和 Sean 的討論中，結(jié)論是什么？這個特性對 Adobe 或你的項(xiàng)目真的很重要嗎？從理論角度來看，要想在一種語言中完全實(shí)現(xiàn) Stepanov風(fēng)格的泛型編程，你真的需要那種特化。我實(shí)際上只是希望我的代碼在不修改現(xiàn)有代碼的情況下可擴(kuò)展。所以我想要符合開閉原則。

David Sankel：我認(rèn)為你在 Rust 里也能得到開閉原則。你可以先定義一個 Trait，聲明需要哪些函數(shù)， 然后再為 Trait 提供一個通用的默認(rèn)實(shí)現(xiàn)。當(dāng)一個新類型想要使用這個功能時，它必須顯式地為自己實(shí)現(xiàn)這個 Trait。

在 C++ 中，泛型函數(shù)（如 std::sort）是“即插 即用”的：只要你的類型滿足 Concept（或隱式接口）的要求，編譯器就會自動選用通用實(shí)現(xiàn)。而如果你需要更優(yōu)的路徑，還可以通過模板特化提供定制版本——整個過程無需修改原始泛型代碼，也無需顯式注冊。

但在 Rust 中，這兩種能力無法共存。你要么顯示地選擇加入，然后隨心所欲的進(jìn)行特化，要不你有一個自動實(shí)現(xiàn)，但不能特化它。

吳詠煒：好的，所以我們有辦法，但是是一種非常不同的方式。

David Sankel：是的，完全正確。C++ 中的 Concept，如果你的語法恰好符合 Concept 的要求，你就支持該 Concept。在 Rust 中，你必須顯式地說你支持一個 Trait（這相當(dāng)于 Concept），并說：“好的，這個特定的類型或這組類型支持這個 Trait，這是它所需的函數(shù)的實(shí)現(xiàn)?！?所以它是選擇加入（opt-in）的語法。

吳詠煒：好的，下一個問題是關(guān)于 AI 代碼的。隨著 AI 編碼助手的興起，許多開源社區(qū)正在禁止 AI 生成的貢獻(xiàn)。作為標(biāo)準(zhǔn)委員會的一員，你對此有何看法？委員會有沒有收到或接受過由 AI 生成的提案或措辭？你有親自在 C++ 開發(fā)中用過過 AI 工具嗎？如果有，體驗(yàn)如何？

David Sankel：關(guān)于 C++ 標(biāo)準(zhǔn)，確實(shí)有過由 AI 編寫的提案，而且非常明顯，也非常令人討厭。那樣寫的提案沒有任何進(jìn)展。當(dāng)然，這些是我們知道的。也許有人用 AI 寫了一個，而且寫得太好了以至于我們沒有注意到。但我還沒有真正看到過這種情況。

我認(rèn)為開源社區(qū)保護(hù)自己免受 AI 生成代碼貢獻(xiàn)的影響是有道理的。因?yàn)?AI 寫出的一段代碼只是完成了一半。另一半是逐行仔細(xì)審查，確保它實(shí)際上是正確的，并能完成所有需要做的事情。

所以當(dāng)你有一個開源項(xiàng)目，現(xiàn)在任何人都可以生成做某事的 Pull Request，這意味著該庫的維護(hù)者必須投入大量的精力，來應(yīng)對這些貢獻(xiàn)者投入的零精力。這里需要某種制衡。也許有人必須證明他們值得信任，并確認(rèn)一個真正的人類已經(jīng)花時間檢查了這個東西。

我確實(shí)有用過 AI 生成代碼。以我的經(jīng)驗(yàn)而言，AI 產(chǎn)生的錯誤足以讓我無法信任它生成的任何東西，除非我親自檢查。 任何將要發(fā)布或長期使用的東西，我都必須非常非常小心。

它基本上將我寫代碼的精力從“編寫代碼并迭代”轉(zhuǎn)變?yōu)椤癆I 生成代碼，我仔細(xì)審查”。這感覺不太好。你知道，相比于審查代碼，我更喜歡寫代碼，尤其是當(dāng)我審查 AI 的代碼而它在胡編亂造時，有時候真的很讓我惱火。但總的來說，我認(rèn)為它在大多數(shù)情況下節(jié)省了時間。所以這可能是值得的。

AI 會變得更好嗎？有些人認(rèn)為它將成為最神奇的東西，你再也不用看代碼了。我不相信。我認(rèn)為對于目前我看到的任何技術(shù)和進(jìn)步，人類都必須保持在循環(huán)中（Stay in the loop）。

吳詠煒： 具體來說，你在 C++ 和 Rust 代碼上使用 AI 工具的體驗(yàn)如何？

David Sankel：對于 C++：AI 傾向于生成更不安全的代碼。

學(xué)術(shù)研究數(shù)據(jù)表明，AI 生成的 C++ 代碼在客觀上比人類編寫的代碼更差，尤其是在內(nèi)存安全漏洞方面。

更令人擔(dān)憂的是一種心理學(xué)現(xiàn)象：開發(fā)者往往對 AI 生成代碼的正確性過度自信，其信心程度甚至超過對自己親手編寫代碼的信心。然而現(xiàn)實(shí)恰恰相反——AI 生成的代碼往往包含更多安全隱患。這是一個相當(dāng)令人不安的趨勢。

對于 Rust，當(dāng)涉及到內(nèi)存安全和 AI 生成的代碼時，如果 AI 生成的代碼不安全，它就不會通過編譯。

吳詠煒：對，它是強(qiáng)制性的。這就是區(qū)別。

David Sankel：目前 Rust 的語法和特性集比 C++ 小得多、也簡單得多，這使得 AI 更容易生成語法正確、看似合理的代碼。當(dāng)然，這不意味著絕對可靠——我確實(shí)也見過 Rust AI 產(chǎn)生一些非常瘋狂的“幻覺”。

總的來說，我認(rèn)為無論是 C++ 還是 Rust，現(xiàn)有的代碼語料庫都已足夠龐大，AI 能夠進(jìn)行有效的學(xué)習(xí)和代碼生成。

吳詠煒：我認(rèn)為至少作為一個輔助工具，AI 是非常有幫助的。順便說一句，幾天前我想讓 AI 重構(gòu)我的一些 C 代碼（其實(shí)不是 C++），它識別出了一個潛伏了 10 多年的 Bug，因?yàn)樗鼜奈幢挥|發(fā)過。但 AI 注意到我在那里有個拼寫錯誤，把一個變量誤寫成了另一個。它識別出來了。所以這非常有趣。

David Sankel：是的，我也遇到過這樣的時刻，它做了一些事情，你會想，“什么？它怎么……？太神了。”

吳詠煒：最后一個問題。我想談?wù)勎炊x行為（UB）。UB 是大多數(shù)內(nèi)存安全問題的根本原因。目前的標(biāo)準(zhǔn)流程中是否有積極的提案專門旨在減輕未定義行為或增強(qiáng)檢測？例如，通過更好的 Sanitizer 或編譯器診斷？

David Sankel：是的，一直有穩(wěn)定的提案流試圖解決未定義行為。我相信在 C++26 中，我們首次引入了“錯誤行為”（Erroneous Behavior）這個概念。這使得一些以前未定義的事情現(xiàn)在有了完整的定義。

還有 Profiles（配置）也被提出過，但這類提案目前還非常不成熟，更像是一些初步構(gòu)想，缺乏任何實(shí)現(xiàn)經(jīng)驗(yàn)。正因如此，它未能進(jìn)入 C++26。

讓我有點(diǎn)擔(dān)心的是……最近很多關(guān)于未定義行為和解決內(nèi)存安全漏洞的提案確實(shí)是一些“異想天開”的主意。你可以舉幾個例子說“這是可以被檢測到的”，但它們?nèi)狈θ魏嗡惴?，更不用說規(guī)范或?qū)崿F(xiàn)了。我擔(dān)心這會分散我們的注意力。人們可能會說，“哦，這個問題在未來某個時候會得到解決”，但實(shí)際上……那里并沒有實(shí)質(zhì)性的東西。

對我來說，目前最扎實(shí)、最有趣的努力，來自于 Timur Doumler 等人的一篇論文。他們沒有急于提出解決方案，而是做了一項(xiàng)極其重要的基礎(chǔ)工作：系統(tǒng)性地編目（Catalog）C++ 標(biāo)準(zhǔn)中每一個已知的 UB 實(shí)例，并對它們進(jìn)行分類。

他們本質(zhì)上是在用一種科學(xué)的方法，為每一個 UB 打上標(biāo)簽，然后問：“對于這一類 UB，我們到底能做些什么？”雖然他們目前還只是在編目階段，沒有提出具體的解決方案，但我認(rèn)為這才是正確的方向。它讓我們第一次有可能從宏觀上、系統(tǒng)性地去討論如何逐步消除 UB，而不是頭痛醫(yī)頭、腳痛醫(yī)腳。

吳詠煒：是的。我想在過去人們認(rèn)為未定義行為對優(yōu)化是一件好事。但現(xiàn)在，我認(rèn)為我們正在朝相反的方向發(fā)展。越來越多的人認(rèn)為未定義行為簡直是邪惡的。我們想盡可能地消除它們，對吧？

David Sankel：完全正確。促成這一觀念轉(zhuǎn)變的關(guān)鍵因素之一，是 CPU 架構(gòu)的演進(jìn)。

讓我們以向量（Vector）的索引訪問為例。如果你在訪問時強(qiáng)制加上邊界檢。在過去，這可能會帶來巨大的性能懲罰，甚至讓執(zhí)行時間變成原來的四倍。而現(xiàn)在，得益于現(xiàn)代超標(biāo)量架構(gòu)，配合指令預(yù)取和預(yù)執(zhí)行技術(shù)，CPU 的流水線能力極強(qiáng)。

這意味著，很多以前昂貴的檢查操作，現(xiàn)在被現(xiàn)代硬件的并行能力“消化”了。實(shí)際上，你現(xiàn)在基本上可以“免費(fèi)”（Free）獲得這些安全檢查，而無需付出明顯的性能代價。

吳詠煒：是很多，但不是全部。因?yàn)槲掖_實(shí)遇到過一個使用 gsl::span 測試的案例。在這個案例中，使用 gsl::span 配合 std::copy 會使復(fù)制代碼慢 20 倍以上。所以如果我們只做一次性檢查，那是可以的。但如果我們不小心做了重復(fù)檢查，那代價會非常高昂 。

David Sankel：是的。這也是 Rust 生態(tài)系統(tǒng)中存在的問題，因?yàn)樗麄兿胍浅８咝У拇a，但也想要安全。

如果你深入查看 Rust 標(biāo)準(zhǔn)庫的實(shí)現(xiàn)，你會發(fā)現(xiàn)一種非常巧妙的模式：雖然代碼本質(zhì)上是“安全”的（意味著理論上每次訪問都要檢查），但開發(fā)者會在循環(huán)開始前加入一條特定的前置斷言，比如“先檢查并確認(rèn)長度小于某個值”。

為什么要這么做？因?yàn)榫幾g器（優(yōu)化器）看到這條前置檢查后，就能推斷出后續(xù)操作是安全的，從而在函數(shù)主體的循環(huán)中自動消除（Elide）所有那些多余的重復(fù)檢查。

這就像是開發(fā)者與優(yōu)化器之間的一場“雙人舞”：你通過特定的代碼寫法去“引導(dǎo)”優(yōu)化器，從而在不犧牲任何安全性的前提下，獲得極高的性能。

我認(rèn)為在 C++ 領(lǐng)域，我們對這種優(yōu)化技巧討論得還遠(yuǎn)遠(yuǎn)不夠，因?yàn)槲覀冊趦?nèi)存安全這條路上才剛剛起步。但我相信，同樣的原理和機(jī)制在 C++ 中也是完全適用的。

吳詠煒：我認(rèn)為在這種情況下，有一個參考實(shí)現(xiàn)真的很有幫助，因?yàn)槲瘑T會知道他們可以讓編譯器基于靜態(tài)分析進(jìn)行這樣的優(yōu)化，對吧？

David Sankel：對。是的。

吳詠煒： 好的。非常感謝您接受今天的采訪。

David Sankel：謝謝。

《近匠》是 CSDN 推出的訪談欄目，其意思即為「走近工匠」，走近深耕于開源、云、AIoT、根技術(shù)、數(shù)字化轉(zhuǎn)型、前沿技術(shù)的工具創(chuàng)造者和技術(shù)管理者們，了解他們怎么看待現(xiàn)在的開發(fā)工作，分享自己精雕細(xì)琢出來的工具有何特點(diǎn)，剖析整個行業(yè)發(fā)展現(xiàn)狀及未來趨勢。

為此，基于 AI、開源、系統(tǒng)軟件、數(shù)字化轉(zhuǎn)型、前沿技術(shù)等領(lǐng)域，如果您及團(tuán)隊有報道需求，亦或者如果您有對技術(shù)趨勢的真知灼見，或是深度的應(yīng)用實(shí)踐、場景方案等的新見解，歡迎聯(lián)系 CSDN 投稿，聯(lián)系方式：微信（hanbb120，請備注投稿+姓名+公司職位）、郵箱（tumin@csdn.net)。

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點(diǎn)智能研究院聯(lián)合主辦「2026 奇點(diǎn)智能技術(shù)大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認(rèn)知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點(diǎn)智能技術(shù)大會上海站，我們不見不散！