1.9萬行Claude Code代碼引發(fā)百人聯(lián)名“封殺”，Node.js核心成員請愿：項目里應禁止AI輔助開發(fā)

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

在 AI 寫代碼這件事上，爭議從來沒有真正停過。但這一次，戰(zhàn)火燒到了最核心的基礎設施之一——Node.js。

近日，一份致 Node.js 技術委員會（TSC）的請愿書引起了廣泛關注。短短幾天，已有超過百名開源開發(fā)者、前端工程師和程序員簽署，他們呼吁“Node.js 社區(qū)應禁止 AI 生成的代碼進入核心倉庫”，將社區(qū)內部的分歧徹底擺上臺面。

對于這場爭議，有人認為這是對代碼質量的堅守，也有人認為這是對技術進步的恐慌式反應。

一份由 Claude Code 生成的 1.9 萬行代碼 PR

回看事件始末，一切要從 2026 年 1 月的一次代碼提交說起。

Node.js 技術指導委員會（TSC）成員、Fastify 框架維護者 Matteo Collina，彼時 Node.js 技術指導委員會（TSC）成員、Fastify 框架維護者 Matteo Collina，為了給 Node.js 添加社區(qū)期待已久的虛擬文件系統(tǒng)（VFS）功能，提交了一份包含約 19,000 行代碼的 PR，覆蓋約 80 個文件。

為此，他還專門發(fā)布了一篇長文《為什么 Node.js 需要 VFS》，詳細說明了 Node.js 在缺乏虛擬文件系統(tǒng)時的痛點問題，如應用打包為單一可執(zhí)行文件時需附帶大量額外資源、測試中無法獲得與模塊系統(tǒng)一致的內存文件系統(tǒng)、多租戶環(huán)境中依賴易錯路徑校驗實現(xiàn)隔離，以及運行時動態(tài)加載生成代碼只能依賴臨時文件等問題。

當前，現(xiàn)有方案如 memfs、unionfs 只能“打補丁”式模擬 fs，無法真正接入模塊解析流程，導致 import() 等調用繞過 VFS。

在 Matteo Collina 看來，社區(qū)早已明確提出這一需求，但始終缺乏一個真正落地的實現(xiàn)。

在這樣的背景下，他從去年圣誕節(jié)期間開始著手開發(fā) VFS 實現(xiàn)，并在今年 1 月提交了這份包含 1.9 萬行代碼的 PR。

按理來說，這本該是件皆大歡喜的事，可他在 PR 描述里添加了一句免責聲明，點燃了爭議的導火索：

我使用了大量 Claude Code token 來創(chuàng)建此 PR。所有更改均由我本人審核。

另外，Matteo Collina 也在博客中寫道：

原本只是一次假期實驗，卻最終變成了 PR ：一個面向 Node.js 的 node:vfs 模塊，涵蓋 66 個文件，代碼量接近 14,000 行。

說實話，這么大的 PR 通常需要幾個月的全職工作才能完成。而這次之所以能在假期完成，是因為我使用了 Claude Code。我讓 AI 處理那些枯燥重復的部分——正是這些工作讓 14,000 行的 PR 成為可能，但沒人愿意手動寫：實現(xiàn)每一個 fs 方法的不同變體（同步、回調、Promise）、接入測試覆蓋、生成文檔。而我專注于架構設計、API 設計，并審查每一行代碼。

沒有 AI，這個假期側項目根本不可能完成——簡直不會發(fā)生。

眾所周知，Claude Code 是 Anthropic 推出的 AI 編程工具，擁有 200K token 的超大上下文窗口，能生成跨文件復雜邏輯甚至完成代碼重構。但在 Node.js 這個運行在全球數(shù)百萬服務器上的核心項目中，AI 生成代碼顯然觸碰了許多老開發(fā)者的底線。

在很多開發(fā)者看來，問題不只是 Matteo Collina“用了 AI”，而是這份 PR 體量巨大、修改核心模塊、生成方式不透明，還有代碼版權歸屬問題。

所以在接下來的短短兩個月里，這份 PR 就經(jīng)歷了 128 次審查嘗試和 108 條評論，其龐大的體量幾乎讓常規(guī)的同行評審流程陷入停滯。

截至 2026 年 3 月 26 日，該 PR 仍未被合并進主分支。

從一個 PR，演變?yōu)橐粓觥笆欠窠?AI”的討論

這場爭議的升級源于 Node.js TLS 模塊主要作者、前 TSC 成員 Fedor Indutny 在 GitHub 上發(fā)起的公開請愿：《致 Node.js TSC 的請愿：禁止在核心代碼中使用 AI》。

短時間內，包括 YDKJS 作者 Kyle Simpson、Zig 軟件基金會主席 Andrew Kelley 在內的 100 多位核心開發(fā)者紛紛簽署支持。

這份請愿書指出：

Node.js 是全球數(shù)百萬服務器上關鍵基礎設施，同時支撐著開發(fā)者日常使用的命令行工具。用 AI 生成的代碼稀釋多年精心打磨的核心代碼，違背項目使命與價值觀，可能破壞公共貢獻建立的聲譽基石，而正是這一基石讓 Node.js 擁有今天的地位和社會價值。

與此同時，此請愿書還列出了反對 AI 生成代碼的三大核心理由：

• 倫理：主流大語言模型公司在訓練過程中使用了來源不合倫理的數(shù)據(jù)，其中包括受版權保護的作品，以及不同許可證下、未注明來源的開源代碼。

• 教育：有證據(jù)表明，大語言模型的使用會阻礙學習過程。由于開源項目經(jīng)常吸納新貢獻者，如果降低代碼質量門檻，可能會削弱人們對 Node.js 核心的理解，進而影響項目的長期可持續(xù)性。

  此外，代碼評審不僅是為了發(fā)現(xiàn) bug、修復安全問題、確保代碼符合項目風格和架構規(guī)范，也是幫助提交者學習成長的重要環(huán)節(jié)。然而，大語言模型本身并不會學習，這意味著評審所投入的時間無法轉化為貢獻者能力的提升，從而被反復“浪費”。

• 特權：使用大語言模型通常需要付費訂閱，或投入大量硬件資源在本地運行（且輸出質量往往更低）。因此，提交的生成代碼應當能夠被評審者復現(xiàn)，而不應要求他們跨越付費訂閱等門檻才能驗證相關結果。

觀點對立，各執(zhí)一詞

這份請愿書一經(jīng)發(fā)布，許多網(wǎng)友表示支持：“1.9 萬行代碼的人工評審壓力巨大，AI 輔助可能導致 PR 數(shù)量和規(guī)模膨脹，最終壓垮依賴志愿者的評審體系。”

同樣持反對意見的開發(fā)者也不在少數(shù)。其中，TSC 成員 James Snell 表示：評判代碼的唯一標準應該是質量，而不是開發(fā)工具。

作為當事人的 Matteo Collina，更是在博客里寫了一篇長文硬核回應，其用了“壓面機”理論反駁道：我祖母曾用一臺叫“Nonna Papera”的壓面機做意大利面——幾乎每個意大利家庭都有一臺。但沒有人會因此說，那不是她做的面。她選擇面粉、雞蛋，決定厚度和形狀，工具只是幫助她完成制作。同樣，我決定架構、設計 API，并審查每一行代碼，這些代碼屬于我。

他進一步強調：DCO（開發(fā)者原產(chǎn)地證明）從未關心代碼如何寫，只關心貢獻者是否有權提交并承擔責任。這一點，與接受任何開源貢獻并無不同。

對于下一步，Matteo Collina 稱，「Node.js TSC 即將就 AI 輔助貢獻的披露與署名規(guī)范進行投票。社區(qū)共識是：負責任地接納 AI 輔助貢獻，可以加速開源項目發(fā)展；一味禁止 AI 工具，只會限制貢獻者來源。軟件開發(fā)最重要的角色，從未改變——不是寫代碼的人或工具，而是理解、審查并為代碼負責的人。」

鮮明對比：Linux 內核的 AI 逆襲，“垃圾”報告一夜變“黃金”

值得一提的是，就在 Node.js 為 AI 代碼吵翻的同時，Linux 內核社區(qū)正經(jīng)歷著 AI 的“真香時刻”。

據(jù)外媒 The Register 報道，Linux 內核核心維護者 Greg Kroah-Hartman 在 KubeCon Europe 上透露，AI 在 Linux 內核的應用，完成了從“垃圾”到“黃金”的一夜逆襲。

時間拉回 2026 年 2 月前，Linux 內核社區(qū)還在為“AI Slop”（AI 垃圾）頭疼 ——AI 生成的安全報告全是明顯的錯誤，毫無參考價值，用 Greg 的話說，“有點搞笑，根本不用擔心”。

這也是彼時整個開源圈的常態(tài)：cURL 創(chuàng)始人 Daniel Stenberg 曾吐槽，AI Slop 讓漏洞賞金計劃的有效率暴跌，最終在 2026 年 1 月直接喊停了這項運行 6 年的計劃；Ghostty 項目更是在同月推出零容忍政策，提交 AI 垃圾代碼將被永久封禁。

但2026 年 2 月成為了 AI 的關鍵拐點，Greg 坦言自己并“不知道發(fā)生了什么，世界突然變了”：曾經(jīng)的 AI 垃圾報告一夜之間變成了高質量有效報告，不僅 Linux 內核，所有開源項目都在收獲 AI 生成的“真 bug、真建議”。

更驚人的是，這一變化并非個例，各大開源項目的安全團隊私下溝通后發(fā)現(xiàn)，所有人都在經(jīng)歷同樣的 AI 升級，只是沒人能說清原因——是 AI 工具突然進化，還是開發(fā)者掌握了更高效的使用方法？

Greg 自己的實驗更是印證了 AI 的實力：他用一個簡單的提示詞讓 AI 分析內核代碼，AI 瞬間輸出 60 個問題及修復方案，三分之二的補丁直接可用，剩下三分之一雖有錯誤，卻也指出了真實問題。這些補丁只需簡單的人工優(yōu)化，就能融入內核開發(fā)流程，效率提升肉眼可見。

如今，AI 在 Linux 內核社區(qū)早已不是“要不要用”的問題，而是“怎么用得更好”。目前 AI 主要承擔代碼審查助手的角色，還未成為核心代碼的主要作者，但二者的界限正在模糊：社區(qū)已經(jīng)推出了“co-develop”標簽，用于標注 AI 輔助生成的補丁；簡單的錯誤檢測、條件判斷等場景，AI 已經(jīng)能生成數(shù)十個可用補丁，完全勝任基礎開發(fā)工作。

Node.js 的核心開發(fā)者是否有一天會像 Greg Kroah-Hartman 那樣，對 AI 的產(chǎn)出感到驚訝，目前尚難預測。

可以肯定的是，幾乎所有成熟開源項目遲早都會面臨同樣的挑戰(zhàn)：AI 不會停下，代碼產(chǎn)出只會越來越快。當前，單純禁止 AI 并不可行，關鍵在于把控代碼質量，確保每一行代碼都有可靠的人工審核。

最后，你現(xiàn)在寫的代碼，又有多少真正是“你自己寫的”？歡迎在評論區(qū)分享你對 AI 生成代碼的看法。

參考：

https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/?td=rt-4a

https://www.reddit.com/r/javascript/comments/1rz2pc6/petition_no_ai_code_in_nodejs_core/

https://github.com/indutny/no-ai-in-nodejs-core

https://github.com/nodejs/node/pull/61478

https://adventures.nodeland.dev/archive/who-is-responsible-for-ai-generated-code/

110 萬美金懸賞！

AMD 2026 線上黑客松大賽來襲

從 MXFP4 MoE 算子爆改，到真實千倍并發(fā)下的吞吐量極限拉扯

不看資歷，只看絕對速度

挑戰(zhàn)DeepSeek?R1/KimiK2.5極致并發(fā)

入圍即能拿 1 萬美金