當下，AI的崛起已成大勢。但是，當AI的觸角伸向開源操作系統時，一些社區(qū)陸續(xù)亮起了“紅燈”。

先是Linux發(fā)行版Gentoo 在四月中旬發(fā)布了一項理事會政策，禁止使用AI工具生成的代碼；隨后，類UNIX操作系統NetBSD也于五月通過更新其提交指南，添加了類似規(guī)定。

短短一個月間，Gentoo和NetBSD的明確表態(tài)引發(fā)了廣泛的討論：在AI的輔助下，我們真的能寫出更好的代碼嗎？這些禁令的發(fā)布僅僅是出于對代碼質量的擔憂嗎？禁令之下，真的能令行禁止嗎？細究起來，似乎并不那么簡單。

1.代碼質量是最不重要的一個原因

Gentoo 的政策指出了促使該決定的三個要點：代碼質量、版權問題和倫理問題。

其中，代碼質量是最容易理解的。盡管AI在代碼生成方面取得了一定進展，但由于上下文理解受限、依賴訓練數據、缺乏創(chuàng)造性、可維護性有待提高等因素，其生成的代碼質量在很多情況下并不盡如人意。

首先，沒有哪個項目愿意接受糟糕的代碼。其次，人們也不希望從那些識別不出爛代碼，或者自己寫不出好代碼，甚至不能改進 AI 生成代碼的程序員那里得到幫助。因此可以說，代碼質量肯定是禁令發(fā)布的考量因素之一，但也是其中最淺顯、最不重要的原因。

相較之下，版權問題和倫理問題則更為復雜，它們也是 NetBSD 項目作出決定的基礎。要理解這些標準的重要性，就必須了解所謂的“AI助手”到底是如何工作的。

所謂大語言模型（LLM）工具，是基于海量文本數據構建統計模型，以生成文本。它們借助包含萬億字節(jié)信息的龐大語料庫，運用Transformer算法自動學習詞語間的關聯、序列及結構。通過這種學習，不僅能預測單個詞匯，還能生成完整句子和段落，即“生成式”文本，源于對輸入文本模式的學習。

事實上，只要你能負擔得起足夠算力，并且有足夠的存儲和帶寬來處理數據，就能使模型產出極為逼真的內容。簡言之，LLM通過學習海量文本模式，憑借強大的計算能力，實現了從預測單詞到生成連貫文本的飛躍。如果在模型訓練所依據的語料庫中有與輸入查詢緊密匹配的文本，LLM就能夠生成優(yōu)質、連貫的答案。

2.生成式人工智能，還不那么智能

不過，能做到這一點的前提是，擁有足夠豐富的語料。因此，作為輸入的“語料庫”包含了創(chuàng)建模型的團隊能夠免費或低成本獲取的所有文本。比如社交網絡和在線論壇的內容，比如源代碼庫。

網上有大量的復雜軟件教程，這些內容已被納入到LLM機器人的索引中。這確實是這些工具的一個極佳應用場景：針對Git等復雜程序提供定制化的教程和使用指南。

但這并不意味著機器人本身理解Git。實際上，它并不理解：它只是能生成符合眾多Git教程文本模式的內容。LLM機器人能做到的是——當輸入的內容中包含與你想要的答案相似的文本，它們可以非常逼真地模仿思考和解決問題的過程。

任何被標榜為“人工智能”的工具實際上并不具備智能——因為真正的智能現在被稱為通用人工智能（AGI），而目前尚無人能夠實現這一目標。

任何現代通用操作系統的代碼庫對于單人來說，其體積都太過龐大，無法整體閱讀、理解和修改。以Debian項目為例，Debian 12 中有超過 1,341,564,204 行代碼。

大語言模型本質上比這大了好幾個數量級，并且它們不是人類可讀的代碼。它們是由大量機器計算出來的，這些模型無法被檢查、驗證或微調。正是基于這一原理，所以不可能調整它們以避免輸出不符合事實的文本。

3.所有權的爭議

想象一下，你正在一個基于Electron的在線編輯器里寫代碼。當你在敲代碼時，這個聰明的工具可以把你的碼字實時送到一個AI助手那里……這就像是超級加強版的自動完成功能：它能在你打字的瞬間，把你敲的代碼和它語料庫中數百萬個模式進行匹配，然后立即給出一段幾乎為你量身定制，能直接用的代碼建議。

問題來了，要是你寫的代碼碰巧和AI學過的某個例子很像，它就可能給你吐出個匹配項。按理說，它給的建議不該和學的樣本一模一樣，但有時候區(qū)別就僅僅是變量名不同而已，其他部分像極了復制粘貼。

對于開源軟件項目來說，這意味著如果訓練數據中包含了諸如許多操作系統共有的C語言功能代碼，那么由LLM驅動的編程助手生成的代碼將與它們語料庫中的代碼極為相似。如果代碼相似到足以讓一個熟練的程序員識別出來，就存在違反許可的風險。機器人從其他項目中獲取的代碼可能會被無意中整合到其他項目中，即使沒有任何人故意復制任何內容。

這就是Gentoo所指出的版權和倫理擔憂的核心所在。如果LLM助手提供的代碼可以追溯到其他項目，這將使Linux發(fā)行版面臨所有權問題。如果意外復制的代碼中包含漏洞，誰應該負責？是貢獻代碼的程序員——即便他們自己并沒有編寫這段代碼？還是原創(chuàng)作者，他們從未貢獻過這段代碼，甚至不知道有機器人在復述它？

對于NetBSD而言，由于許可問題，所有這些問題都適用，甚至更為嚴重。雖然在線代碼倉庫被Linux開發(fā)者大量使用，意味著其中充滿了GPL代碼，但NetBSD并非采用GPL許可，而是采用BSD許可。不小心將GPL代碼納入BSD代碼庫是個問題：這意味著要么重新許可現有代碼，要么完全替換它——這兩者他們都缺乏人力去執(zhí)行。

還有一個值得注意的點在于：GitHub的所有者微軟并未將其任何自有操作系統的源代碼輸入到其LLM訓練語料庫中。這間接表明了即使是科技巨頭也意識到了潛在的風險和挑戰(zhàn)。

4.真的能禁止嗎

如今我們已經清楚地了解了這些開源社區(qū)對AI生成代碼說“不”的理由。但問題又出現了：禁令雖然發(fā)了，但真的能禁止嗎？

在相關話題的討論中，有開發(fā)者一針見血地指出了這一點：“我不清楚Gentoo或NetBSD如何能阻止包含由LLM生成的代碼，因為他們依賴上游提供的修復。”

“除非每個主要發(fā)行版乃至內核，都預先對超過700家LLM公司發(fā)出警告，否則似乎沒有方法能阻止這種情況，但沒有任何發(fā)行版甚至內核有資金去做這件事，而且GPL許可證可能也不兼容這樣的威脅（所有LLM公司只需托管用于訓練數據的GPL代碼副本，讓人們可以下載，就可以輕松應對）。”

Debian的政策似乎就意識到了這一點。他們沒有選擇全面禁止，可能是因為認識到在當前開源生態(tài)系統和法律框架下，徹底阻止LLM生成代碼的流入幾乎是不可能的任務，而且可能還會牽涉到復雜的法律和社區(qū)合作問題。因此，Debian可能更傾向于采取靈活的管理策略，關注代碼的質量控制、版權合規(guī)性以及透明度，而不是簡單地設立禁令。

當前技術進步帶來了前所未有的自動化水平，但同時也不斷開辟出需要人類創(chuàng)造性思維的新領域。盡管降本增效是推動技術進步的重要動力，但如何在這一進程中平衡環(huán)境影響和社會責任，成為了不可回避的議題。在這個由人工智能日益主導的世界里，如何找到人與技術和諧共生的方式，是我們之后將長久面臨的議題。