Godot Engine 禁止 AI 撰寫的程式碼貢獻

The Godot Engine 基金會已正式宣布，將不再接受由人工智慧撰寫的程式碼貢獻。這項政策變更的主要目標是確保貢獻者能夠在提交程式碼後進行後續維護，並保護維護者有限的空閒時間，使其免於審查低品質、AI 生成內容的負擔。

維護者倦怠與「審查者的負擔」

開源維護者通常是在晚上或正職工作之餘自願投入時間。基金會的政策是對日益增加的、難以審查且缺乏長期專案健康所需的深度理解之貢獻所做出的回應。

正如一位社群成員所指出的，AI 撰寫的程式碼湧入往往表現為「冗長、AI 撰寫的文字牆」，這對於負責審查 Pull Request (PR) 的人來說，可能構成一種「對人類心智的阻斷服務攻擊 (denial-of-service attack)".

開源專案中的導師制缺口

除了程式碼的即時技術品質外，Godot 基金會也強調了開源專案中導師制 (mentorship) 的重要性。當維護者對 PR 提供回饋時，他們是在投資於一位潛在的未來維護者。

基金會表示：

"如果妳對 PR 的回饋只是被機器吸收，而不是用於指導一位潛在的未來維護者，那麼要證明花費空閒時間進行 PR 審查是合理的將會變得更加困難。"

這突顯了關注點的轉移：從利用 AI 輔助快速推進，轉向專案內人類人才庫的可持續成長。

技術債與「AI 宿醉」

雖然 AI 工具可以加速初始功能的開發，但它們經常會引入細微的不一致性與「裂痕」，這些問題往往在稍後才會顯現。這會產生技術債，維護者最終必須清理這些債務。

社群討論指出，AI 工具感覺就像是「吸毒」——提供即時的力量感與生產力，但一旦引入了細微的錯誤，隨後就會陷入「對混亂的絕望」。這導致了對 AI 在編碼中角色的分析：它在有嚴格護欄的規劃、除錯與狹窄範圍的重構方面更有效，而非進行大規模的功能開發。

執行與偵測的挑戰

該政策在如何偵測 AI 撰寫的程式碼方面提出了挑戰。一些貢獻者認為，如果使用者提示 AI 遵循特定的風格指南並避免過多的註解，AI 生成的程式碼可能變得與人類撰寫的程式碼無法區分。

然而，其他社群成員建議，程式碼是否由 AI 撰寫並非主要問題，而是缺乏理解能力的「氣味 (smells)". 這類指標，例如違反命名慣例、錯誤地更改 API 或犯下業餘的語言錯誤，都是作者——無論是否使用 AI——不理解其提交內容的跡象。核心要求是作者必須展現出「品味與觀點」，並能夠用自己的語言解釋邏輯以及專案的其他架構。