AI 寫的程式測試全過，為什麼專案還是不收？別把「15 行」當通行證

你花了半天修好問題，測試也過了，準備把 AI 協助寫的程式送出去，卻發現專案可能根本不收這類貢獻。卡住的未必是技術，而是你把「能運作」和「能被接受」當成同一件事。

先把結論講清楚：別等寫完，才讀貢獻規則。測試、內容來源、投稿責任，要分開確認。

GCC 不是今天才突然下禁令

GCC 是 GNU 編譯器集合。其 AI 政策在 2026 年 7 月 29 日已有正式公告；本文於 2026 年 10 月 18 日重新查核，不是新禁令快訊。GCC 公告

現行政策暫不接受具有法律重要性、包含或衍生自 LLM 生成內容的貢獻。但不是所有 AI 使用都被禁止：非重要且明確標示的貢獻可由維護者接受，測試案例另有例外；不把輸出納入貢獻的分析、除錯等用途，也沒有一概禁止。從其他專案匯入的程式另有範圍規定。這是 GCC 自身的接收政策，不是對全世界程式碼的法律判決。GCC AI 政策

這個差別很實際：問 AI「這段為什麼壞掉」，與直接把它產生的實作送進專案，不該只用一句「有用 AI」混在一起。

「15 行」不是可以鑽的自動准收額度

GNU 維護者指引提到約 15 行，是在解釋著作權上重要的變更與文件要求；它同時提醒，同一人多次小修改可能累積成重要貢獻，規律重複的修改則不能只按行數理解。GNU 指引 6.2

因此，把程式壓成十四行、拆成很多小補丁，都不能靠這個數字直接推論「現在一定能收」。也不能反過來宣稱，超過十五行就違反台灣法律。那不是這份指引正在回答的問題。

實務上遇到邊界不清，先問專案維護者怎麼判定；不要讓 AI 替你宣布符合規則，更不要改寫內容後隱藏它的來源。

測試回答的是功能，不是所有接收條件

GCC 的貢獻說明要求驗證修改目的、做回歸測試，並測試實際打算提交的那份變更。提交時也要交代問題與測試平台、結果。GCC 貢獻說明

這些證據很重要，但「測試通過」不能替另外兩個問題作答：目標專案是否接受這類內容？你是否理解並願意負責這份修改？

Linux 的工具生成內容指引也要求提交者理解整份貢獻，說明工具如何參與、影響哪些部分、如何測試；維護者仍可拒收或要求更多檢查。透明不是免審通行證，也不是另一個專案的規則能直接搬過來用。Linux 指引

投稿前，先填得出這張表

下表是本文整理的工作建議，不是任一專案官方的統一驗收協定。

對 GCC 而言，政策中的人類提交與揭露要求，也不是把原本不接受的內容變成可接受的捷徑。不要只做表格最後一列，忘了第一列。

一個假想情境：省下的不是寫字時間，而是白做的時間

假設你要修某專案的字串處理錯誤，AI 幫你產生新函式，手邊幾個例子都過了。以下純為假想，不是 GCC 或 Linux 的真實補丁。

如果先送出再說，可能直到審查才發現規則不接受這類生成內容，或測試根本沒涵蓋空字串和不同編碼。此時多寫一段漂亮說明，也沒有補上缺口。

更好的順序，是開工前先看規則；確定方法適用後保留參與範圍，針對原問題測試，再列未測情境。如果規則不清，先停下來問，而不是先要求模型把來源洗掉。

我的立場是：AI 可以讓你更快提出修改，不能替你決定專案該不該接受。真正值得收藏的，不是哪個行數門檻，而是下一次投稿前，能不能把內容、證據與責任講清楚。

你用 AI 改過的程式，最難向別人解釋的是哪一段？