Linux 無線子系統維護者對 AI 生成的補丁公開表達過明確的拒絕態度這件事在內核開發社區里引發了不小的討論。很多人以為維護者是在否定 AI 寫代碼這件事實際上他們否定的是一類被稱為“AI Slop”的補丁看起來結構完整實際上缺少上下文、缺少理由、缺少驗證甚至可能連編譯都沒有通過。真正讓維護者疲憊的不是“補丁由誰生成”而是“提交者有沒有對補丁負責”。這篇文章會圍繞這條主線展開先說明維護者為什么對低質量 AI 補丁如此敏感再梳理 Linux 無線補丁從生成到合入經歷的完整鏈路然后給出“用 AI 輔助生成補丁、但由人來保證質量”的可行工作流最后提供一套提交前自查清單和常見拒絕原因速查表。適合三類讀者閱讀準備給內核社區提交補丁的開發者、使用 Realtek 等無線網卡驅動并需要維護補丁的嵌入式工程師、以及希望在團隊內部引入 AI 輔助代碼開發但擔心代碼質量失控的技術負責人。1. 維護者真正不滿的不是 AI而是“AI Slop”補丁1.1 事件結論需要先拆開看Linux 無線子系統維護者每天要處理大量補丁覆蓋 mac80211/cfg80211 框架、各類無線網卡驅動、以及和藍牙共存、電源管理、固件加載等底層邏輯。這些代碼直接運行在用戶的網卡上補丁一旦出錯輕則掉線重則內核崩潰。維護者在公開討論中表達對 AI 生成補丁的不滿本質上是在表達對“提交質量”的不滿。AI 本身不會提交補丁補丁最終由開發者發送開發者必須為補丁的正確性負責。如果開發者把 AI 生成的代碼未經檢查就發到內核郵件列表維護者就會把它當作“垃圾補丁”處理而不是花時間逐行猜測提交者想做什么。這里要區分兩個概念AI 輔助開發和 AI 自動生成補丁。前者是使用工具提高效率后者是把工具當作“自動提交器”。維護者反對的一直是后者。1.2 什么是“AI Slop”補丁“Slop”在英文網絡社區里常用來形容大量、廉價、未經篩選的 AI 輸出內容?！癆I Slop”補丁就是指那些帶有明顯 AI 生成痕跡、但缺少工程驗證的補丁。這類補丁通常有下面幾個特征只修改了代碼但沒有說明“為什么改”。commit message 寫得很長卻沒有一句能解釋實際問題。補丁上下文是從別的驅動里復制來的函數名和調用路徑對不上。缺少 Signed-off-by、Reported-by、Tested-by 等必要標簽。沒有經過編譯驗證甚至格式錯誤導致 patch 無法應用。這些補丁最危險的地方在于“看起來合理”。AI 生成的代碼通常語法正確、命名規范但它并不理解真實硬件的行為。無線驅動中常見的固件版本判斷、寄存器讀寫、中斷處理邏輯一旦“看著像那么回事”的代碼進入主線排查問題的時間成本會非常高。1.3 維護者的時間成本是根本問題內核維護者大多是志愿工作或者公司支持的開發者他們不可能替每個提交者做完整測試。維護者審查一個補丁時真正在看三件事這個改動是否解決了真實問題。改動是否影響了其他路徑。提交者是否理解自己的代碼。AI 生成的補丁往往只能回應第一點而且經常是“看起來回應了”。一個補丁如果無法讓維護者快速理解“為什么會有這個改動”就會被要求重寫或者直接拒絕。維護者的時間非常有限。一個高質量的補丁應該把“審查成本”降到最低而不是增加審查負擔。這是理解所有拒絕反饋的底層邏輯。2. Linux 無線補丁從生成到合入要過哪些關卡2.1 無線子系統與驅動開發現狀Linux 內核的無線子系統主要由 cfg80211 和 mac80211 組成。cfg80211 負責向上層提供配置接口mac80211 負責管理無線協議狀態機具體的驅動則接入這兩個框架。常見的無線驅動包括 Intel 的 iwlwifi、Qualcomm Atheros 的 ath 系列、MediaTek 的 mt76、Realtek 的 rtw88/rtw89 等。很多 Realtek 網卡型號最初只有廠商驅動的 out-of-tree 版本后來才逐步被社區整合進主線。因為這個過程涉及大量驅動移植工作很多人會嘗試用 AI 工具幫忙寫代碼、生成補丁、補 commit message。這也解釋了為什么“Realtek 8821CE”“Realtek 8852BE”“Realtek 8812BU”這些關鍵詞經常和“Linux 補丁”一起出現。需要注意的是out-of-tree 驅動和內核主線驅動對補丁的要求并不完全相同。out-of-tree 驅動可以由廠商維護者決定合并規則主線內核則必須遵守內核社區的統一流程。下面重點講主線補丁的標準鏈路。2.2 一次補丁提交的完整鏈路一個補丁從開始編寫到被維護者合入至少經歷下面這些環節準備內核源碼明確當前分支基線。修改代碼確保可以編譯。本地測試功能至少驗證正常路徑。運行scripts/checkpatch.pl檢查代碼風格。使用git commit -s提交并寫清楚提交信息。使用get_maintainer.pl找到正確的維護者和郵件列表。使用git format-patch生成補丁文件。發送補丁給維護者和相關列表。收到 review 意見后修改發送 v2、v3。維護者合入補丁進入 next 或 merge window。AI 工具可以參與前四步中的一部分但第 5 步到第 8 步必須由人來確認。很多“AI Slop”補丁恰恰在第 8 步被攔下來因為維護者一看提交信息就知道補丁沒有被認真對待。2.3 工具鏈對齊format-patch、checkpatch、get_maintainer無論補丁是不是 AI 生成的工具鏈對齊都是基本要求。先看維護者查詢命令./scripts/get_maintainer.pl --separator , --nokeywords 0001-wifi-sample-fix-description.patch這個命令會列出該補丁涉及的維護者、子系統、郵件列表。發送補丁前一定要運行不能只發給一個看起來相關的維護者。再看代碼風格檢查./scripts/checkpatch.pl --no-tree --strict 0001-wifi-sample-fix-description.patch--strict會開啟更嚴格的檢查包括注釋風格、行長度、括號位置等。對于首次提交建議提前用--fix參數自動修復部分風格問題./scripts/checkpatch.pl --no-tree --strict --fix 0001-wifi-sample-fix-description.patch注意--fix會修改原始文件不是直接修改 patch所以運行前先確認工作區是干凈狀態。最后是生成補丁git format-patch -1 -o patches/-1表示生成最近一次提交的補丁-o patches/指定輸出目錄。生成后要打開補丁文件重點檢查補丁頭和 diff 內容是否完整。補丁不是一段代碼片段而是提交者寫給維護者的一封說明信。代碼只回答問題“改了什么”提交信息必須回答問題“為什么改”。3. 用 AI 輔助補丁開發正確的工作流3.1 AI 適合做“草稿”而不是“成品”AI 在補丁開發流程里能幫上忙但只適合產出草稿不適合產出最終提交物。具體來說下面這些環節很值得用 AI根據代碼 diff 生成 commit message 的初始草稿。解釋一個陌生函數調用鏈的作用幫助提交者理解代碼。把某種風格的代碼轉換成內核風格。整理編譯錯誤日志協助快速定位問題。這些環節的共同點是“結果會被人工再次確認”而“AI 生成一個可以直接發給維護者的補丁”并不符合這個條件。差異在于commit message 草稿可以改錯誤日志理解可以幫助排查但補丁 diff 是最終交付物一旦發送維護者看到的每一行都必須由提交者負責。3.2 AI 生成補丁的典型問題和識別方式AI 補丁雖然語法正確但在內核審查里經常會暴露出一批規律性問題。下面這張表總結了常見情形典型問題現象本質原因正確做法上下文不對補丁改的是 A 驅動卻引用了 B 驅動的結構體模型缺乏內核代碼庫上下文先完整閱讀驅動文件再讓 AI 生成參考提交信息空洞“Fix issue”或“Improve code”沒有任何細節沒有把真實調試過程寫進提示詞用真實日志、錯誤現象、測試結果重寫提交信息缺少合法標簽沒有 Signed-off-by、Fixes、Reported-by提交者不了解內核補丁規范人工補充不能只依賴 AI未驗證代碼代碼依賴某宏或函數但實際不存在模型基于概率生成不是真實編譯本地編譯至少一次性通過風格不一致使用 tab 與空格混用、非內核注釋風格沒有指定內核風格先跑 checkpatch再讓 AI 修改格式問題這五個問題的共同點是AI 只能基于訓練數據推測無法感知當前內核倉庫的真實狀態。因此審查補丁的人必須能回答“這段代碼引用的函數在哪里定義”這個問題。如果回答不了就不應該發送。3.3 推薦工作流與腳本示例一個可靠的工作流可以定義為五步人工定位問題收集現象、日志、復現環境。讓 AI 根據這些信息生成補丁或 commit message 草稿。人工閱讀草稿對照源碼確認每一行 diff 是否有效。本地編譯、運行測試、跑 checkpatch。確認無問題后發送補丁。為了減少人為疏漏可以在倉庫里放一個提交前檢查腳本。下面是一個簡單的 shell 示例#!/usr/bin/env bash set -euo pipefail PATCH${1:-} if [[ -z $PATCH ]]; then echo usage: $0 patch-file exit 1 fi echo [1/3] checkpatch ./scripts/checkpatch.pl --no-tree --strict $PATCH || true echo [2/3] required tags for tag in Subject: Signed-off-by:; do if grep -q $tag $PATCH; then echo OK - $tag else echo MISS - $tag exit 1 fi done echo [3/3] patch stat git apply --stat $PATCH腳本的作用不是判斷補丁是否“正確”而是強制提交者在發送前至少思考三件事代碼風格、必要標簽、改動范圍。如果 AI 生成的補丁連這三步都過不了就不應該進入人工 review。這個腳本適合放在內核倉庫之外比如個人開發目錄下避免污染內核源碼樹。生產環境還可以把它接入 CI任何未通過靜態檢查的補丁都不能進入合并隊列。4. 一個可審查補丁的教學示例4.1 示例目標修正驅動模塊參數說明為了把上面流程串起來下面用一個教學示例演示。假設某個無線網卡驅動中有一個模塊參數disable_msi原本用于控制是否禁用 MSI 中斷但注釋寫得不清楚用戶無法理解默認行為。我們要修改描述讓它更易讀。這是一個很小的改動但足以展示補丁格式、commit message 和 checkpatch 檢查的完整過程。下面的代碼片段只是示例實際驅動中的函數和參數名以你的代碼為準。修改前static bool disable_msi; module_param(disable_msi, bool, 0644); MODULE_PARM_DESC(disable_msi, Disable MSI interrupts (0 enable MSI, 1 disable MSI));修改后static bool disable_msi; module_param(disable_msi, bool, 0644); MODULE_PARM_DESC(disable_msi, Force legacy interrupts instead of MSI (default: false));這個修改看起來簡單但它真正在改的是“接口文檔”。用戶模塊參數時描述會影響加載時的提示信息。如果描述只寫“Disable MSI interrupts”用戶無法知道默認值是什么也不知道是否應該主動打開。4.2 修改代碼和提交信息提交信息是補丁的一部分不能只寫“Update description”。要說明為什么原來的描述不夠好以及新的描述想解決什么問題。示例提交信息wifi: sample: make module parameter description clearer The previous description only mentioned Disable MSI interrupts without explaining the default value or why a user would want to disable MSI. Reword it to describe the effect and the default. Signed-off-by: Your Name youexample.com注意格式第一行是標題使用“子系統: 模塊: 簡短描述”的格式?？找恍泻髮懻?。最后是Signed-off-by。這個標簽不是口頭承諾而是表示提交者熟悉開發者來源證書并同意代碼被合入內核。如果修改是為了修復某個具體的 bug還需要加入Fixes:標簽指向第一次引入問題的提交哈希。AI 很難自己準確判斷該寫哪個提交所以這個標簽通常需要人工補充。4.3 生成補丁、自查并輸出 diff修改完成后按下面順序操作git add drivers/net/wireless/sample/sample.c git commit -s git format-patch -1 -o patches/git commit -s會自動添加Signed-off-by。如果之前用git commit提交沒有加-s補丁會缺少必要標簽維護者會直接要求重新提交。生成的補丁文件大致長這樣From 1234567890abcdef1234567890abcdef1234567 Mon Sep 17 00:00:00 2001 From: Your Name youexample.com Date: Mon, 1 Jan 2024 10:00:00 0800 Subject: [PATCH] wifi: sample: make module parameter description clearer The previous description only mentioned Disable MSI interrupts without explaining the default value or why a user would want to disable MSI. Reword it to describe the effect and the default. Signed-off-by: Your Name youexample.com --- drivers/net/wireless/sample/sample.c | 2 - 1 file changed, 1 insertion(), 1 deletion(-) diff --git a/drivers/net/wireless/sample/sample.c b/drivers/net/wireless/sample/sample.c index aabbccdd..eeff0011 100644 --- a/drivers/net/wireless/sample/sample.c b/drivers/net/wireless/sample/sample.c -123,7 123,7 static bool disable_msi; module_param(disable_msi, bool, 0644); MODULE_PARM_DESC(disable_msi, - Disable MSI interrupts (0 enable MSI, 1 disable MSI)); Force legacy interrupts instead of MSI (default: false));發送前再運行一次 checkpatch./scripts/checkpatch.pl --no-tree --strict patches/0001-wifi-sample-make-module-parameter-description-clearer.patch正常輸出應為total: 0 errors, 0 warnings, 0 checks此時才可以把補丁發送給維護者。這個過程無論有沒有 AI 參與都不能省略。如果 AI 生成的是完整補丁必須把它還原成上面的檢查路徑而不是直接發送。5. 提交前自查清單與維護者拒絕原因速查表5.1 提交前 10 項自查發送補丁前可以對照這份清單逐項確認。任何一項不通過都不要發送。補丁是否基于最新的上游分支生成而不是基于本地隨意改過的基線。是否使用git format-patch生成而不是手動復制 diff。補丁頭部是否包含Subject: [PATCH]且標題符合“子系統: 模塊: 描述”格式。是否有Signed-off-by且填寫的郵箱與提交郵箱一致。是否用checkpatch.pl檢查并清零關鍵錯誤。是否在真實環境中編譯過編譯日志中是否有與補丁相關的 warning。是否運行過基本功能測試至少驗證正常路徑。是否正確使用get_maintainer.pl找到維護者和郵件列表。是否在補丁正文里說明了“為什么改動”而不只是“改了什么”。如果這是第 2 版或第 3 版補丁是否在標題中標注[PATCH v2]并在正文中說明相對上一版的變化。這份清單并不復雜但幾乎所有的“AI Slop”補丁都會在某一項上失敗。5.2 常見拒絕原因速查表維護者拒絕補丁時通常會給出原因有時只是簡單回復 “NACK” 或者 “Please fix”。不要看到拒絕就灰心把原因對照下表處理拒絕反饋或現象常見原因檢查方式處理建議缺少 Signed-off-by提交時沒有加-sgrep 補丁文件重新生成補丁并補充標簽無法應用補丁基線不對或上下文偏移git apply --checkrebase 到最新上游checkpatch 報錯風格不符合內核規范運行 checkpatch用--fix自動修正或手動修改提交信息沒有解釋為什么AI 生成的空洞描述閱讀 commit message重寫正文加入實際調試信息發送給了錯誤維護者沒有運行 get_maintainer查看補丁頭重新發送到正確列表缺少 Fixes 標簽修復 bug 但沒有關聯提交查找引入 bug 的 commit用git log -S定位并補充改動太寬泛一個補丁混入多個不相關問題查看 diff stat拆分成多個獨立補丁疑似 AI 生成且未驗證代碼引用不存在的符號嘗試編譯并檢查符號逐行審查補充測試這張表也可以作為 patch review 的工具清單。無論是送審前還是收到反饋后按表操作都能降低來回次數。5.3 維護者反饋后如何復盤收到 review 意見后不要只修改代碼還要檢查反饋背后暴露的流程問題。如果維護者說“這段代碼沒有錯誤處理”除了補上錯誤處理還要反思為什么第一次提交漏掉了。如果維護者說“提交信息太模糊”應該回去收集當時的實際日志而不是把 AI 生成的內容再潤色一遍。對于 AI 輔助開發的團隊建議把每次 review 意見記錄下來。積累一段時間后就能形成團隊的“review 缺陷庫”再把缺陷庫寫進 AI 提示詞中讓下一次生成避免同類問題。這個過程才是 AI 輔助開發的正確閉環不是讓 AI 直接產出最終結果而是讓 AI 在人類反饋中逐步逼近社區可接受的質量。6. 在開源協作與生產內核維護中的實踐建議6.1 開源補丁協作的底層契約內核補丁的提交本質上是一個協作契約提交者承諾補丁是自己的工作或有權提交維護者承諾會認真審查。Signed-off-by是這個契約的憑證它不只是格式要求而是開發者證書的一部分。AI 工具無法承擔這個承諾它只是一個生成器真正的責任主體永遠是提交者。這也是維護者對 AI 生成補丁保持警惕的重要原因。社區可以接受你“用了工具”但無法接受你用工具替代“理解”。即使補丁被拒絕只要你愿意解釋背景、補充測試維護者通常會給機會。最差的處理方式是發了一堆補丁然后說“這是 AI 寫的我不太清楚為什么這么改”。6.2 生產內核維護如何引入 AI 工具如果你不是給上游社區貢獻代碼而是在公司內部維護嵌入式 Linux 內核或驅動AI 工具的使用尺度可以更靈活但質量門禁不能放松。生產內核維護中建議把 AI 工具限制在三個場景生成 backport 補丁的初稿例如把上游修復移植到老內核。根據編譯失敗日志生成排查建議。自動整理內部補丁的 commit message 草稿。這三個場景都要求最終結果經過同一套質量門禁編譯通過、檢查清單通過、至少一個人 review。生產環境還應該額外關注補丁對應的產品驗證包括固件版本、硬件型號、無線吞吐、功耗、穩定性測試。不要因為補丁來自 AI 就降低驗證標準也不要因為補丁來自資深工程師就跳過驗證。6.3 長期價值讓“被審查過的代碼”成為你的訓練語料如果團隊正在訓練或微調內部的代碼輔助模型最有價值的數據不是互聯網上的通用代碼而是“被維護者接受過”的歷史補丁和對應 review 對話。這些數據包含了大量上下文為什么這個改動是必要的、reviewer 關注什么、哪些寫法會被拒絕。實際落地時可以把歷史補丁整理成規范化的記錄包括問題現象、補丁 diff、review 反饋、最終合入版本。用這些記錄去校準 AI 提示詞模型會逐漸學會“如何寫一個可審查的補丁”。這個工作比讓 AI 直接生成代碼更值得投入因為它解決的是補丁最難的部分上下文理解。內核無線子系統的特殊之處在于驅動代碼需要貼近硬件行為AI 很難從訓練數據里獲得真實硬件寄存器、固件交互的完整知識。因此這個領域尤其適合“AI 出草稿、人做驗證”的模式。使用 AI 補丁開發工具時應當把提示詞寫得足夠具體給出實際驅動路徑、函數名、錯誤日志、硬件型號而不是泛泛地要求“幫我寫個修復補丁”。維護者的立場不是要拒絕效率工具而是要求每個人對自己發出的補丁負責。對開發者來說最好的應對方式不是放棄 AI而是把 AI 當成一面能快速生成初稿的鏡子然后再用編譯、測試、代碼審查這面更可靠的鏡子去照出問題。