OpenJDK 把 AI 生成的程式碼擋在門外：地基級軟體的一次表態

（事件日期：2026 年 9 月初，OpenJDK 官網更新貢獻政策。以下以回顧角度重新梳理這件事為何值得繼續討論。）

2026 年 9 月，Oracle 針對 OpenJDK 發布了一份措辭相當強硬的貢獻政策：禁止提交任何 AI 生成的內容。這件事在 Java 社羣裡吵了一輪，有人叫好，有人嘲諷，熱度過去之後，值得回頭把它放進更大的脈絡裡看清楚。因為這不只是一個專案的規則變更，而是基礎軟體在 AI 時代第一次這麼明確地說：AI 可以當你的學習助手，但不能當你的共同作者。

這道禁令到底禁了什麼

先看規則本身。OpenJDK 的政策並非「建議」或「盡量避免」，而是硬性要求。範圍也遠比一般人想像的寬：原始碼、文件文字、圖片、郵件、Wiki、Pull Request，只要內容全部或部分由 AI 生成，一律不得提交。

官方 FAQ 裡有一個很有代表性的問答。有人問：如果我用 AI 生成了 100 行程式碼，自己動手改了其中 10 行，這樣算不算合格的人類貢獻？官方的回答乾脆俐落：不行。判斷標準不是你改了多少，而是內容裡有沒有 AI 的成分。有，就擋。

唯一的例外空間在私底下。你可以用 AI 來理解既有程式碼、除錯、學習，這些都不管。紅線畫在「提交」這個動作上：AI 生成物不能進到專案的版本庫裡。

用一個日常比喻來說，這就像一間老字號餐廳規定：你可以在家裡用料理包練習、研究食譜，但端上店的菜，每一道都必須是你自己從頭做的。餐廳不在乎你怎麼學，只在乎送上桌的東西由誰負責、能不能追溯。

為什麼 OpenJDK 敢這樣選

很多人第一反應是：放著免費的生產力不用，太保守了。但要理解這個決定，得先看 OpenJDK 在軟體世界裡的位置。

OpenJDK 不是普通的開源專案。它是整個 Java 生態的地基，全球大量金融系統、政務系統、企業後端都跑在它上面。這個等級的軟體，穩定性和可追溯性壓倒一切，跟一個週末 side project 的考量完全不在同一個層級。

官方給出的理由有三個層面。第一是審查負擔。AI 生成程式碼的速度極快，一天產出幾十個語法正確、看起來合理的 PR 毫無難度，但這些程式碼常藏著細微錯誤、邊界缺陷，或根本沒考慮長期維護性。OpenJDK 的維護者人數有限，一旦 AI 產物大量湧入，審查者會被淹沒在「看起來沒問題但很難維護」的程式碼海裡，最終受傷的是整個專案的品質。

第二是安全風險。AI 模型有幻覺是眾所周知的事，它可能自信滿滿地寫出一段看似修好 Bug、實則引入新漏洞的程式碼。在一般應用裡，這可能是一次線上事故；在 JDK 這種等級的基礎軟體裡，影響範圍是全球性的。

第三個最棘手：智慧財產權。AI 的訓練資料來自海量網路內容，生成物存在無意複製他人程式碼的風險，而 AI 產出的版權歸屬至今沒有定論。一段帶有版權隱患的程式碼一旦被合入 OpenJDK，未來可能面對的是漫長的法律糾紛。對 Oracle 這種對智財極其敏感的公司來說，這是不能碰的紅線。

這裡可以對照另一個脈絡。Twitch 因為未經同意使用主播內容訓練生成式 AI 而面臨集體訴訟，那場官司問的正是同一個問題：拿別人的內容餵 AI，責任算誰的。OpenJDK 的禁令本質上是用最保守的方式提前迴避了這個還沒有答案的問題，相關討論可以參考我們先前的Twitch AI 訓練集體訴訟分析。

同一家公司，兩套規則

這件事最有意思的地方，其實是 Oracle 自己內部的矛盾。

Oracle 旗下另一個知名開源專案 GraalVM，對 AI 工具的態度完全相反：明確允許 AI 輔助貢獻。但前提是，提交者必須對內容負全責，能解釋、能維護自己提交的程式碼，做不到就可能被拒絕。在署名方面，GraalVM 鼓勵貢獻者主動揭露 AI 參與的程度，但不強制。

同一個老闆，兩個專案，一個全面禁止，一個有條件開放。表面看是雙標，細看其實是兩個專案的風險結構不同。兩個專案都要求貢獻者簽署 OCA（Oracle 貢獻者協議），但 OpenJDK 的政策聚焦在智財風險的源頭阻絕，GraalVM 則聚焦在貢獻者的責任歸屬。一個選擇把閘門關死，一個選擇把責任壓到人身上。

這就像同一家銀行，對分行櫃檯交易和手機轉帳採取不同等級的驗證。不是原則不一致，而是兩邊出事的成本不一樣。

對一般開發者的實際意義

把視角拉回一般工程師的日常工作，這道禁令至少傳遞了三個訊號。

第一，「誰能解釋這段程式碼」正在變成新的責任標準。即使你所在的團隊沒有禁 AI，GraalVM 式的邏輯也值得借鏡：提交的每一行，你都得能講清楚為什麼這樣寫。AI 幫你寫的東西，出了事還是算你的。這與伯克利教授批評學生的文章被驗出 AI 痕跡的風波，本質上是同一個命題，工具可以用，但署名的後果由人承擔，相關討論可見伯克利 AI 寫作風波分析。

第二，基礎軟體和應用軟體會走上不同的 AI 政策。越是多人生產的程式碼，越可能出現 OpenJDK 式的硬禁令；越是快速迭代、出錯成本可控的專案，越可能採用 GraalVM 式的責任制。工程師在選擇貢獻開源專案時，先看 AI 政策會變成基本功。

第三，AI 的角色正在被重新定位。OpenJDK 的劃法很清楚：AI 是學習與理解的加速器，而非產出的代理人。對於正在大量用 AI 補齊陌生領域知識的開發者來說，這條線並不會妨礙你成長，它只是要求你在把成果交出去之前，先把它真正變成自己的東西。

下一步值得觀察的訊號

OpenJDK 這一步不會是終點。接下來可以留意幾個方向：Linux 核心等其他地基級專案會不會跟進類似政策；各國法院對 AI 生成物版權歸屬的判決會怎麼發展；以及開發者工具鏈會不會出現「AI 成分檢測」這類新的基礎設施需求。

至於「AI 會不會取代程式設計師」這個老問題，OpenJDK 的政策其實給了一個務實的答案：在地基級的軟體世界裡，能對程式碼負責的人暫時還是稀缺資源。AI 讓寫程式變容易了，但讓程式碼值得信賴這件事，依然要靠人，而且越來越靠人。