老牌開源項目該不該接受 AI 代碼？

對于是否接受由 AI 生成的代碼，開源界的 OG 們似乎分成了兩大派別。

上個月底，Wayland 生態核心貢獻者、知名開源老兵 Drew DeVault 在自己的博客上發表了一篇文章，標題叫《Vim 的悼文》。他在文中寫道：自己所信任的那個 Vim 已經死了。矛頭直指 Vim 社區中不斷新增的 AI 生成代碼，他認為這些代碼對 Vim 造成了“污染”。

對 AI 零容忍

Vim 在開源界是毫無疑問的元老級項目，它的前身 vi 誕生于 1976 年，由 Bill Joy 在加州大學伯克利分校開發。Vim 本身發布于 1991 年，在開源編輯器戰爭里，Vim 和 Emacs 是兩大陣營，程序員為此爭論了幾十年，寫出了無數篇文章和段子。在老一輩程序員群體中，某種程度上用什么編輯器已經不只是工具問題，而是一種身份認同。

Vim 的創始人 Bram Moolenaar 在 2023 年 8 月去世，他曾在荷蘭獨自維護這個項目三十多年。在此之后，Vim 的維護工作主要由以 Christian Brabandt 為代表的一批長期貢獻者接手，而 Drew DeVault 并不在此列。

DeVault 長期使用 Vim 進行創作和寫代碼，對 Vim 有深厚情感，多次發文評論 Vim 發展，直接影響了社區對 Vim9 的討論。他認為如今的 Vim 和 NeoVim 都在開發過程中使用了 LLM 生成代碼，并抨擊這些代碼都是“slop” —— 這個詞他用了不止一次，原意是泔水、剩飯剩菜，在開源社區里被廣泛用來形容 AI 生成的、缺乏質量下限的內容。

他對于 AI 的厭惡是全方位的，DeVault 對 AI 的批評不止于技術質量，還延伸到了環境、人權和政治三個維度：數據中心消耗了全球約 1.5% 的能源；芯片需求推高了非洲礦工的死亡風險；AI 生成的虛假信息正在喂養全球法西斯主義。

“生成式 AI 的本質，是為少數人斂財、集中權力、減少競爭，并支撐一個巨大的泡沫。”這是他對當下全球爆火的 AI 最大的指控。因此，他在發布“悼文”的同時建立了一個 Vim 分支，這個版本被命名為 Vim Classic，基于 Vim 8.2.0148 —— Vim9 Script 之前的最后一個版本。DeVault 沒有時間去分辨現任維護者的工作哪些來自已故創始人 Bram Moolenaar，哪些不是，所以他選擇徹底不要 Vim9 Script。項目托管在他自己做的 SourceHut，代碼倉庫里已經回移植了若干 CVE 補丁和小 bug 修復。DeVault 歡迎所有人貢獻補丁，但有一條鐵律寫在 CONTRIBUTING.md 里：不接受任何 AI 生成的代碼。

DeVault 的反應不是孤例。2026 年 3 月，用 Rust 編寫的微內核操作系統 Redox OS 正式宣布禁止 LLM 生成代碼，同時引入 DCO（開發者來源證書）機制。項目在公告里說了一句很直接的話：歷史上，動手寫PR本身就是一個隱性的質量過濾機制 —— 現在這個門檻被 AI 抹掉了，維護者的審查負擔變得完全不可控。

4 月 15 日，跨平臺多媒體開發庫 SDL（Simple DirectMedia Layer）也更新了貢獻政策，明確拒絕 LLM 生成的代碼。SDL 維護者給出的理由很實際：AI 生成代碼的可追溯性不足、許可證歸屬不明、審查成本不可控。

再往前數，NetBSD、GIMP、Zig、QEMU 等項目都在更早時候各自宣布了類似的“禁 AI 政策”。

實用主義至上

與這些堅決反對 AI 代碼參與開源的“保守派”們不同，更多的知名老牌開源項目對 AI 參與社區貢獻持開放態度。

研究員 Phil Eaton 在 2026 年 3 月調查了 112 個主要開源項目，結果是：約 63% 已接受明確標注的 AI 輔助貢獻，包括 Linux、Chromium、Kubernetes 等。其中，Linux 內核社區在接受 AI 這件事上經歷了很大的內部斗爭才達成統一。

2025 年底，Nvidia 工程師 Sasha Levin 向 Linux 6.15 內核提交了一個補丁：代碼是 AI 寫的，更新日志是 AI 寫的，測試用例也是 AI 寫的。Levin 本人做了審查和測試，但提交時沒有告訴維護者這件事。維護者發現后，Linux 內核郵件列表（LKML）炸了鍋。

這不是 Linux 內核第一次面對 AI 生成的代碼，但從來沒有一次如此徹底 —— 連提交信息都沒有人類寫的痕跡，這件事直接推動了內核社區正式制定規則。

2026 年 1 月，爭論在 LKML 上達到頂峰。Intel 的 Dave Hansen 與 Oracle 的 Lorenzo Stoakes 就內核應該如何監管 AI 工具爆發了激烈沖突。核心分歧不只是“允不允許用”，而是一個更棘手的法律問題：DCO（Developer Certificate of Origin，開發者原產地證書）要求提交者法律認證自己有權提交這段代碼，但 LLM 的訓練數據里包含了大量帶有許可證限制的開源代碼 —— 這意味著一個使用 Copilot 寫代碼的開發者，實際上無法完全保證提交代碼的來源是否干凈。

Red Hat 在同期發布的一份分析報告中指出：如果繼續忽視這個問題，內核社區可能無意中違反開源許可證，并徹底瓦解整個 DCO 框架。

2026 年 4 月 12 日，Linus Torvalds 以他標志性的直率終結了爭論，Linux 內核正式合并了史上第一份 AI 代碼貢獻政策文檔coding-assistants.rst，三條核心規則落地：

Signed-off-by 必須由人類簽署：AI 代理不得使用這個具有法律約束力的標簽 必須標注 Assisted-by：注明使用的模型和工具，格式示例： Assisted-by: Claude:claude-3-opus sparse 人類承擔全部法律責任：包括審查義務、許可合規，以及未來出現的一切 bug 和安全漏洞

Linus 在 LKML 上的原話：“我不希望內核開發文檔也卷入這種站隊。因此我堅持文檔中對 AI 的唯一定位，就是「工具」。”他做了一個類比：禁止特定的 AI 工具，就像禁止某個特定品牌的鍵盤一樣毫無意義。

至此，Linux 內核社區正式明確了 “AI 僅作為工具、拒絕無意義的限制、強調人類提交者責任” 的核心原則。

政策實驗的意外結論

就在這套框架確立之后不久，發生了一件有意思的事。

Anthropic 研究員 Nicholas Carlini 用 Claude Code 做了一次漏洞挖掘實驗：他寫了一個簡單的 bash 腳本，遍歷 Linux 內核源代碼樹中的每一個文件，讓 AI 逐個檢查（腳本限制了 AI 在同一文件內重復尋找同一個漏洞）。

結果在 90 分鐘里，5 個可遠程利用的內核漏洞被發現，其中 4 個此前未知。最古老的一個于 2003 年 3 月引入，距今 23 年，比 git 誕生還早兩年。

漏洞位于 Linux 內核 NFS v4.0 驅動中。攻擊原理很直接：NFS 拒絕消息中的 Owner ID 字段最大可達 1024 字節，但內核用于構建這個響應包的靜態緩沖區只有 112 字節 —— 當兩個 NFS 客戶端對同一文件加鎖產生沖突時，內核試圖把 1056 字節的數據寫入 112 字節的緩沖區，造成堆緩沖區溢出，可被遠程利用。

Carlini 的做法，其實恰好是 Linux 新政策所要求的理想模板： **AI 出力，人類把關，Assisted-by 標注，責任歸屬清晰。**但這個發現本身，卻讓政策的目的變得耐人尋味：如果 AI 能在 90 分鐘內挖出人類維護者 23 年都沒發現的漏洞，那么“人類審查 AI 代碼”這個機制，在實踐中究竟能提供多少保護？

答案也許令人不安：人類審查的價值，可能不在于發現漏洞，而在于承擔漏洞被發現之后的責任。

Carlini 稱其已經鎖定了“數百個潛在漏洞”正在逐一確認。這意味著，未來也會有大量由 AI 發現、人類尚未驗證的漏洞躺在某個列表里，等著被分配到具體的人頭上。Linux 內核社區的新政策在邏輯上完全自洽：AI 負責找，人負責認責。但這個邏輯的代價是，一旦大規模漏洞由 AI 發現成為常態，人類維護者的“審查”將越來越像一種儀式，而非實質性的安全屏障。

規模越大 責任越大

Linux 內核社區不是不想拒絕 AI。Linus 在 LKML 上說得很清楚：“我們不會去買一個 AI 檢測軟件來識別誰用了 AI 寫代碼卻沒標注。”他沒有這個義務，也沒有這個意愿。內核社區有數以萬計的活躍提交者，代碼庫規模以千萬行計，維護者靠的是深厚的技術經驗、模式識別和同行審查維持項目健康迭代 —— 不是靠工具掃描。

DeVault 能完全“封殺”AI，是因為 Vim Classic 項目小到他一個人扛得住。沒有數以萬計的 PR，沒有多架構、多版本并行維護的壓力，沒有商業公司的 SLA 要求。他的“純凈版”是有代價的 —— 代價是放棄成長，放棄新功能，放棄大多數可能來幫忙的貢獻者。

這就是為什么 Linux 內核和 Vim Classic 的選擇其實都合理。Redox 能禁，SDL 能禁，因為這些項目的規模和治理結構允許這種選擇；Linux 不行，Chromium 不行，Kubernetes 不行，它們如今的規模在面對席卷全球的 AI 浪潮時已無法調轉船頭。

開源社區在 AI 問題上的分裂，本質上是一個規模問題，也是一個你想在多大程度上為你的項目負責的問題。Linus 選擇了負責到底，DeVault 選擇了眼不見為凈。

1. Drew DeVault 悼文原文: https://drewdevault.com/2026/03/25/2026-03-25-Forking-vim.html
2. Vim Classic 官網: https://vim-classic.org/
3. LKML 關于 AI 政策的討論: https://lore.kernel.org/lkml/CAHk-=wg0sdh_OF8zgFD-f6o9yFRK=tDOXhB1JAxfs11W9bX--Q@mail.gmail.com/
4. Claude Code 發現 Linux 內核 23 年漏洞: https://mtlynch.io/claude-code-found-linux-vulnerability/
5. 主要開源社區 AI 貢獻情況調查報告: https://theconsensus.dev/p/2026/03/02/source-available-projects-and-their-ai-contribution-policies.html

4月24日，OSC源創會 × FAIR plus 2026
【具身智能工程化實戰沙龍】
深圳福田會展中心9號館4號會議室
聚焦具身智能從技術研發到工程落地的核心痛點
現場還能體驗模力方舟“口袋龍蝦”PocketClaw

?一線項目復盤
失敗案例拆解
AI硬件資源對接

免費報名 oschina.net/event/8598188