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