懶人包
五點看懂：
一、Linux 核心準備取消人工智慧輔助開發須在提交紀錄加註的規定，相關修訂案已經正式提交。
二、提案由核心開發者於十月十三日提出，文件維護者隔日接受修改，後續將整合進核心主線。
三、過去開發者使用大型語言模型協助製作修補程式，必須在提交紀錄加註標記，供審查者辨識是否使用人工智慧。
四、提案者指出，實際使用人工智慧的情況遠比有標註的多，規定已經難以達到原本協助辨識的目的。
五、核心發起人反對以使用何種工具判斷開發者的能力，強調重點在於開發者是否真正理解自己提交的程式碼。
這項修訂案由核心開發者在十月十三日提交，內容是移除開發者使用人工智慧協助撰寫程式碼時，必須在提交紀錄加入標註的規定。文件維護者已於十四日接受修改，接下來仍須整合至 Linux 主線才算定案。
回顧過去的規定，開發者使用大型語言模型協助製作核心修補程式時，必須在提交紀錄加入特定的標註，讓負責審查程式碼的維護者能夠辨識該次修改是否借助了人工智慧。這項要求的初衷，是在人工智慧輔助寫程式逐漸普及的背景下，為審查流程保留一道識別機制。
事實上，今年七月就曾有開發者提議取消這項標註，但當時的維護者認為仍有保留的必要。直到十月舉行的核心維護者高峰會，多數與會者才轉而支持移除規定，不過現場仍存在不同意見，顯示社群對此並非一面倒。
提案者提出了一項關鍵數據：在 Linux 7.3 第七個候選版本的一萬八千五百三十三筆非合併提交紀錄中，只有約一成附有人工智慧輔助標註。他認為，實際使用人工智慧的情況遠比這個比例更高，部分開發者根本不知道有這項規定，也有人刻意省略不寫，而維護者很少主動追問。
他的結論是，既然沒有標註不代表沒有使用人工智慧，這項規定就已經難以達到原本協助辨識的目的，形同具文。與其維持一個執行不徹底的規則，不如直接移除，把審查的重點放回程式碼本身的品質。
這次的修改提案將刪除開發文件以及程式碼檢查工具中對該標註的要求。不過，既有的工具生成內容揭露指引仍然適用，並未一併廢除。
原有的指引要求提交者交代內容的來源，並建議說明使用了哪些工具、修改了哪些部分，以及如何進行測試。開發者也必須親自檢查程式碼、確認授權符合規定，並在提交紀錄加入署名，對修改內容負責。特別的是，人工智慧代理不得代替人類署名，責任歸屬依然明確落在開發者身上。
在討論過程中，開發者 Laurent Pinchart 主張提交說明應該由人類親自撰寫，藉此確認開發者確實理解並參與了修改內容，而不是把思考過程完全外包給機器。
核心發起人 Linus Torvalds 則持不同看法。他反駁說，如果要以使用工具與否來判斷開發者的能力，那甚至可以禁止使用編譯器，要求開發者直接撰寫組合語言。他直言，這類限制工具使用的規定愚蠢至極，強調應該關注的是開發者是否理解自己的工作，而不是他用了什麼工具。
Torvalds 在討論中也表明反對限制人工智慧工具的使用。他的立場一貫明確：工具只是工具，重點永遠是提交者對程式碼的掌握程度。
從制度面來看，這次修訂反映的是開源社群在人工智慧時代的調適。當初設立標註要求時，人工智慧輔助寫程式還是新鮮事；如今它已經成為日常，硬性標註的邊際效益遞減，社群選擇把信任放回開發者的專業自律。
對一般開發者而言，最直接的影響是提交流程簡化了一道手續。但責任並沒有減輕：揭露指引、親自檢查、署名負責的要求都還在，人工智慧可以幫忙寫程式，但不能幫忙負責。
後續值得關注的是，這項修訂整合進主線之後，其他開源專案是否會跟進類似的鬆綁。人工智慧輔助開發的治理方式，正在從「標示與區隔」走向「融入與究責」，這可能是整個軟體產業的共同趨勢。
可以確定的是，無論工具如何演進，開源社群對程式碼品質與責任歸屬的要求不會打折。標註可以取消，但開發者對自己提交的每一行程式碼負責，這條底線沒有改變。
