面對生成式 AI（Generative AI）如 GitHub Copilot 或 ChatGPT 的普及，工程師在開發時越來越依賴 AI 輔助編寫程式碼。然而，當這些程式碼需要提交到大型開源專案時，是否被允許？近期 Oracle 旗下兩個重要的 Java 相關專案 OpenJDK 與 GraalVM 採取了截然不同的立場，這為我們提供了一個很好的案例，用來探討 AI 貢獻在工業級軟體中的風險管理。
OpenJDK 的嚴格禁令：為什麼不能用 AI？
OpenJDK 是 Java 平台的基準實作，其核心地位極其重要。該專案目前的臨時政策採取全面禁止（Broad Ban）的立場，規定任何提交的內容，無論是程式碼、文件還是 Issue 描述，只要包含部分或全部由大型語言模型（LLM）產生的內容，均不被允許。
對於初入行的工程師來說，可能會覺得這太過死板，但 OpenJDK 提出了三個關鍵的實務考量。首先是審核壓力（Reviewer Burden）。AI 產出的程式碼往往看起來很正確（Plausible），但實際上可能隱藏細微的錯誤或難以維護的邏輯。如果大量 AI 生成的 PR（Pull Request，合併請求）湧入，會嚴重耗盡核心維護者有限的審核時間。
其次是安全性與穩定性。JDK 是許多企業級關鍵任務系統的底層，任何微小的 Bug 都可能導致全球數百萬台伺服器崩潰，因此對程式碼品質的門檻要求極高。最後是知識產權（Intellectual Property, IP）的法律風險。貢獻者必須簽署 Oracle 貢獻者協議（OCA），保證自己擁有提交內容的完整權利。然而，AI 生成內容的版權歸屬在法律上仍有爭議，這對 Oracle 這樣的公司來說是不可接受的法律風險。
值得注意的是，OpenJDK 並非禁止你使用 AI 學習或除錯，而是禁止將 AI 的產出直接提交。即使你修改了 AI 生成的 100 行程式碼中的 10 行，只要其本質仍是 AI 生成，依然違規。
GraalVM 的開放態度：責任自負原則
與 OpenJDK 不同，同樣由 Oracle 支持的 GraalVM（一個高性能的多語言虛擬機）則允許使用 AI 編碼助手。GraalVM 的邏輯是將 AI 視為一種工具，而非替代者。
GraalVM 的核心原則是貢獻者問責制（Contributor Accountability）。簡單來說，AI 可以幫你寫草稿、轉換代碼或總結文件，但提交者必須對最終結果負全責。如果一名工程師無法解釋 AI 產生的邏輯、無法捍衛其設計意圖，或者無法維護該段程式碼，該提交將被直接拒絕。
在實務操作上，GraalVM 鼓勵但並不強制要求標記 AI 輔助（例如使用 Assisted-by 標籤），這比 Linux 核心的 AI 政策稍微寬鬆一些。但無論如何，AI 的使用並不代表程式碼被預設為正確，所有的 AI 產出必須經過與人類手寫程式碼相同、甚至更嚴格的審核流程。
兩種策略的對比與工程啟示
這兩個專案雖然都要求簽署相同的 OCA 協議，但對風險的容忍度完全不同。OpenJDK 將 AI 視為潛在的法律與品質威脅，因此選擇從源頭切斷；而 GraalVM 則將風險轉嫁給提交者，認為只要人類能完全掌控並對結果負責，AI 就可以作為生產力工具。
對於工程師而言，這帶來兩個重要的提醒。第一，在參與開源貢獻前，必須仔細閱讀該專案的貢獻指南（Contribution Guidelines）。在 OpenJDK 這種環境下，使用 AI 提交代碼可能會導致你的帳號被標記或提交被拒絕。第二，無論工具如何進化，理解每一行進入生產環境的程式碼是工程師的基本職責。AI 能提高速度，但不能替代對正確性與安全性負責的思考過程。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。