📍 真實場景
陳品睿,34歲,竹科韌體工程師,晚上義務維護一個中型開源輸入法函式庫
最近三個月收到的Pull Request數量暴增,他熬夜一件件審查,想把品質顧好
😖 卡住的地方：上週有一份程式碼寫得漂漂亮亮、測試也全過的PR,合併後才發現邊界條件悄悄壞掉——貢獻者事後坦承,那是AI生成的,他自己也沒看懂就送出來了。陳品睿發現自己花在「確認這段程式碼有沒有人真的懂」的時間,已經比自己重寫一遍還久
💡 這堂課會告訴他,為什麼Linux kernel、GCC、QEMU這些重量級專案,已經不再用道德勸說,而是直接用白紙黑字的政策處理這個問題——以及這些政策設計的邏輯,能怎麼搬回他自己的審查流程裡用
🧭 這到底是什麼（白話版）
這篇文章在講一件事:號稱能大幅提升生產力的AI,在真正最懂程式碼的一群人——開源專案原始碼公開、任何人都能看、能參與貢獻程式碼的軟體專案的維護者——眼中,卻越來越不受歡迎。研究者Rakshit Yadav調查了120個開源專案的AI政策,發現有37個(約三成)已經全面禁止使用AI協助貢獻,包含GCC、QEMU、SDL、Gentoo、Zig、Ghostty這些你可能沒聽過、但幾乎每天都在間接用到的底層工具。
這不是單純的「守舊派怕新科技」。LLM大型語言模型,也就是像ChatGPT、Claude這類會讀懂並生成文字的AI寫出來的程式碼,常常「看起來」非常專業、格式漂亮、邏輯完整,但這正是危險的地方——文章指出,人類長期演化出來判斷資訊真假的直覺(例如「寫得工整就代表懂」),對AI生成的內容常常會失靈,反而更容易被表面的專業感騙過去。
於是不同專案發展出不同對策。Linux kernel走中間路線:允許AI協助,但貢獻者必須署名(attribution)標示這段內容是不是AI協助生成、用了哪個AI模型,方便事後追查責任,讓每一份Pull Request(PR)貢獻者想把自己寫的程式碼合併進專案時,提交的一份「請求審查」的申請都能追溯來源。Codeberg、Sourcehut、Flathub這些平台則更嚴格,直接禁止AI產出任何「給人看」的內容——不只程式碼,連文件、bug回報、審查留言都在禁止之列,目的是防堵AI slopAI生成但品質低落、沒有人好好把關就丟出來的內容,讓別人得花額外力氣去驗證真假的擴散。
目前最受矚目的戰場是Debian——這個支撐了無數伺服器、甚至AI資料中心本身的Linux發行版,正在讓全體開發者投票表決,其中一項提案是全面禁止AI用於程式碼、文件、翻譯、bug回報等所有貢獻類型。這場投票的結果,某種程度上會定調軟體工程界接下來要怎麼與AI共存。
🎯 為什麼值得你花時間
數字比想像中硬120個專案裡有37個(約三成)選擇全面禁止AI,這不是零星個案,而是相當比例的核心開發者社群已經用白紙黑字的政策、而非道德勸說來畫線,值得任何準備導入AI輔助開發的團隊正視。
政策光譜裡藏著風險管理邏輯從「全面禁止」到「允許+署名」到「允許+人類把關」,不同專案的選擇其實對應著各自能承受的風險、以及既有審查機制的強弱,不是單純的「挺AI vs 反AI」立場之爭。
Debian投票是一場活的治理實驗一個撐起全球伺服器與AI基礎設施的作業系統,正在用民主投票、而非執行長一聲令下的方式決定AI政策,這個過程本身就是觀察大型技術社群如何應對顛覆性工具的第一手案例。
⚙️ 它是怎麼運作的
1
全面禁止型GCC、QEMU、SDL、Gentoo、Zig、Ghostty等專案直接在貢獻規範上寫明:拒收任何AI輔助產出的程式碼,理由通常是無法確認品質與授權來源。
▼
2
允許但要署名型Linux kernel的作法是不禁止,但要求貢獻者在提交紀錄裡標明用了哪個LLM,讓AI協助這件事透明化、可追溯,出包時能查到源頭。
▼
3
允許但人類要把關型部分允許AI的專案要求貢獻者做到human-in-the-loop要求人類全程參與把關的流程,AI只是輔助工具,人類要先讀懂、篩選過才能把內容交給下一個人看——先自己讀懂、驗證過AI的輸出,再送去給審查者看,扮演的是「編輯」而不是「轉發者」的角色。
▼
4
平台級全面禁止型Codeberg、Sourcehut、Flathub這類代管平台把禁令範圍拉到最大,不只程式碼,連文件、bug回報、審查留言等一切寫給人看的內容都不准用AI生成。
各專案/平台對AI貢獻的政策比較
| 專案/平台 | 政策 | 核心考量 |
|---|
| Linux kernel | 允許AI協助,但需標示使用的LLM(署名) | 透明度優先,搭配既有的多層維護者審查機制 |
| GCC / QEMU / SDL / Gentoo / Zig / Ghostty | 全面禁止AI輔助貢獻 | 核心工具鏈風險高,直接消滅風險入口 |
| Codeberg / Sourcehut / Flathub | 禁止AI生成任何給人看的內容(程式碼、文件、bug回報、審查留言) | 防堵AI slop擴散,保護審查者的驗證成本 |
| Debian | 由全體開發者投票表決中(其中一案為全面禁止) | 政策正當性優先於決策效率 |
🤔 這則沒有適合的實作——改用三個問題帶你想深
- 如果你是陳品睿那種義務維護開源專案的人,面對AI輔助的Pull Request,你會選擇「完全禁止」、「允許但需署名」還是「允許但需人類先讀懂再送出」?哪一種最符合你專案的審查人力與風險承受度?
- 文章提到一個弔詭:AI資料中心本身跑在Linux/Debian這類系統上,而這些系統的原始碼也曾被拿去訓練LLM,但維護者卻對AI的貢獻回饋越來越不歡迎。這說明了什麼——是AI還沒準備好,還是「生成」與「被信任」根本是兩件不同的事?
- 如果連打造LLM工具的開源社群自己都在立政策防範AI濫用,這對「正打算導入AI輔助開發」的你的公司或團隊,有什麼可以提早借鏡的地方?
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼Linux kernel選擇「允許+署名」,而不是像GCC一樣直接全面禁止?
這其實是一個風險管理的工程判斷。Linux kernel本來就有全世界數一數二嚴格的多層維護者審查文化,AI混入的風險相對可控;署名要求的作用,是把「究責鏈」顯性化——一旦出包,能追溯是哪個貢獻者、用了哪個模型送出的,這比一刀切禁止更貼合它原本就存在的治理機制。反觀QEMU、GCC這類核心工具鏈專案,一旦出錯影響是全球性的編譯器或虛擬機層級,他們選擇用政策直接消滅風險入口,而不是仰賴署名事後究責——同樣是「風險管理」,但因為兩者能承受的下游影響不同,選了不同的解法。
🔭 為什麼Codeberg、Sourcehut這些平台,連bug回報、審查留言都要一起禁,而不只是程式碼?
這揭露了一個常被忽略的成本:AI生成內容最貴的地方不是「生成」,而是「別人得花時間驗證它是不是胡說」。一份AI寫的bug回報,如果內容看起來專業、格式完整卻沒有實質內容,維護者還是得花力氣去確認、回覆、解釋為什麼這不是真的問題——這個驗證成本被轉嫁給了審查者。所以這些平台把「防AI垃圾」的範圍擴大到所有「給人看的內容」,而不只是程式碼本身,抓到的其實是問題的本質:信任成本,不是產出速度。
🔭 Debian用「全體開發者投票」而不是「核心維護者拍板」來決定AI政策,這代表什麼設計思維?
這反映了大型去中心化專案的治理哲學:政策的正當性比效率更重要。如果由少數核心維護者直接拍板,遇到像AI政策這種牽涉到每個貢獻者工作方式的爭議議題,很容易引發社群分裂甚至出走。透過全體開發者投票,即使結果是「有條件允許」而不是「全禁」,大家也比較願意遵守,因為那是集體決定而非單方強加。這跟企業內部要不要用AI是同樣的權衡:由上而下宣佈執行成本低但阻力大,花時間凝聚共識執行成本高但後續阻力小,兩者是一種取捨,沒有絕對的對錯。
📝 隨堂考（點選答案，立即回饋）
Q1. 根據Rakshit Yadav的調查,120個開源專案中,選擇「全面禁止AI」的比例大約是多少?
✅ 文章指出120個專案中有37個選擇全面禁止AI貢獻,37/120約為三成。
Q2. Linux kernel對AI輔助貢獻採取的政策是?
✅ Linux kernel並未全面禁止AI協助,而是要求貢獻者標明用了哪個LLM,以維持透明度與可追溯性。
Q3. Codeberg、Sourcehut、Flathub這類平台,禁止AI生成內容的範圍涵蓋什麼?
✅ 文章明確指出這些平台禁止AI用於生成軟體、文件、bug回報、審查留言等基本上任何要給人閱讀的內容。
Q4. 文章認為維護者不信任AI貢獻的核心原因,與下列何者最相關?
✅ 文章提到人類演化出的信任判斷直覺,面對「看起來很專業」的AI輸出時容易失效,這正是問題核心。
Q5. 文章提到,Debian目前對AI政策的處理方式是?
✅ 文章指出Debian正在進行開發者投票,其中一項提案是全面禁止AI用於程式碼、文件、翻譯、bug回報等貢獻。
🃏 翻牌記憶卡（先想答案，再點開對答）
AI slop點我翻面
AI生成但品質低落、沒有人好好把關就丟出來的內容(程式碼、文件、bug回報等),讓別人得花額外力氣驗證真偽。
human-in-the-loop點我翻面
要求人類全程參與把關的流程設計——AI只是輔助,提交者要先讀懂、篩選過AI的輸出,才能讓下一個人看到。
署名(attribution)點我翻面
要求標示內容是否經AI輔助生成、用了哪個模型,讓事後究責與品質追蹤有跡可循。
三成禁令點我翻面
Rakshit Yadav調查120個開源專案,發現37個(約三成)已全面禁止AI貢獻。
Debian的AI政策投票點我翻面
大型去中心化開源社群用全體開發者投票決定重大政策,正當性優先於效率,其中一項提案是全面禁止AI貢獻。