- Linux 核心要求採用統一且嚴格的程式設計風格，優先考慮可讀性，避免不必要的抽像或過度使用預處理器。
- 只要人類開發者對錯誤承擔全部責任，並且在整個過程中保持透明，就可以使用人工智慧輔助程式碼整合。
- 我們配備了自動化驗證工具和嚴格的人工審核流程，以防止系統退化並確保系統穩定性。
進入 Linux 核心開發領域並非易事。一行程式碼要想被主分支接受，僅僅「能運行」是不夠的；它必須遵循極其嚴謹的設計理念，優先考慮長期可維護性而非短期開發速度。
近來，爭論的焦點集中在人工智慧如何融入這個生態系統。最初幾乎完全的懷疑態度已經演變為一種務實和現實的態度，即人工智慧被視為一種工具，類似於鍵盤或整合開發環境（IDE），只要它不成為提交劣質程式碼的藉口。
黃金標準：程式碼的風格和質量
核心有著非常明確的程式碼風格指南，這並非建議，而是強制性要求。當開發者提交修補程式時，如果程式碼不符合指南，審核人員很可能會要求他們重新格式化整個程式碼，因為程式碼的統一性對於成千上萬的程式設計師快速理解系統的任何部分都至關重要。雖然像clang-format這樣的工具可以幫助自動化這個過程，但最終還是要依靠人的判斷。
新手常犯的一個錯誤是試圖清理舊檔案的格式，只是為了出現在變更日誌中。社群會將此視為無關緊要的噪音，通常會被拒絕；只有當格式變更帶來真正的功能改進時，才會被接受。此外，建議避免過早引入抽象層。在核心中，過度的靈活性會降低效能並模糊邏輯，因此只有在絕對必要時才應實現抽象。
內核程式設計的常見陷阱
使用 C 預處理器是另一個關鍵點。儘管 #ifdef 它們很有用，但程式碼充斥著條件編譯會使程式碼難以閱讀。一般原則是： 將預處理器限制在頭檔範圍內 或是可以留空以便編譯器進行最佳化的函數。類似地，宏也應該替換為 線上功能 盡可能採用後者，因為後者可以提供類型保證，避免危險的多次評估。
但是，這些功能不應過度使用。 inline如果程式碼充斥著這些元素，會導致最終二進位檔案體積膨脹，從而耗盡處理器快取。 減慢系統執行速度在現代硬體中，空間就是時間：更緊湊的程式碼通常效率更高。另一方面，併發性是不可妥協的。任何共享資源都必須可用。 由鎖保護 這是理所當然的，因為在開發程式碼時忽略多處理器系統無異於自取滅亡。
倒退與穩定的危險
在 Linux 生態系統中，導致功能回歸是絕對不允許的。功能回歸指的是，當一項改進破壞了其他用戶已經正常運作的功能時。 Linus Torvalds 對此態度堅決：任何破壞現有功能的變更通常都會立即回滾，無論這些變更帶來了多少新優勢。這一點在用戶空間 ABI中尤其重要，因為 ABI 必須無限期地保持完整，以避免破壞外部軟體。
驗證和文件工具
為了防止錯誤影響最終用戶，核心配備了一系列工具。從關注所有 GCC 警告到使用lockdep 偵測死鎖，整個工作流程必須嚴謹。其他值得注意的工具包括用於檢測記憶體位址混淆的sparse和允許大規模語義變更的Coccinelle 。
至於文檔，它不再是可有可無的，而是必不可少的。每個補丁都必須包含詳細的變更日誌，解釋解決方案背後的「原因」。新的使用者空間介面和啟動參數必須有完整的文件。此外，我們鼓勵使用kerneldoc，以確保任何加入專案的開發人員都能理解內部 API。
人工智慧的融合
目前對於LLM（郵件清單管理）的立場很明確：如果人工智慧能夠增加技術價值，我們歡迎它，但它不能取代人類的判斷。人們的關注點已經從將人工智慧視為純粹的行銷手段，轉向將其應用於分類和自動化審查任務，例如Sashiko系統，該系統有助於在人工幹預之前檢測漏洞和CVE（通用漏洞編號）。然而，真正的問題不在於人工智慧本身，而是大量未經任何預先過濾的自動化報告充斥著郵件清單。
對於人工智慧使用者而言，透明度和問責制至關重要。儘管關於「由…輔助」之類的標籤存在爭議，但其基本原則是，無論程式碼是否由機器人生成，提交程式碼的人都應對每一行程式碼承擔法律和技術責任。人工智慧輔助程式碼的標準並沒有降低；它必須達到與手寫程式碼完全相同的品質、測試和可維護性標準。
Linux 核心開發遵循一套嚴格的規範，最終程式碼的品質優先於開發方法。只要遵循標準風格，避免回歸錯誤，而人工智慧僅用於輔助問題分類和缺陷檢測（而非繞過人工審核），系統就能持續演進。我們尊重不使用人工智慧的自由，但技術效率和個人責任感才是確保作業系統核心保持健壯性和可擴展性的唯一支柱。