LLM辅助Linux内核驱动代码审查：drivers/staging策略与实践

如果最近留意过 Linux 内核开发相关的邮件列表和技术讨论，会发现一个高频词正在从 AI 应用层渗透到内核开发圈：LLM。过去我们聊大语言模型，说的是 chat、Agent、RAG，但内核社区真正关心的不是让 LLM 写一个聊天机器人，而是一个很具体的问题：当 LLM 越来越多地参与驱动代码的生成、修改和审查时，drivers/staging 目录到底应该执行什么样的策略？

这篇文章不是从 AI 应用开发者的视角去讲“怎么调用大模型接口”，而是从内核维护和补丁评审的角度，拆解LLM policy for drivers/staging/ going forward这个主题。我会先解释这个策略为什么出现在 staging 目录，再说明一套可落地的策略应该包含哪些构成，最后给出一个最小可运行的“LLM 预审补丁”流程示例，包括配置、脚本、运行验证和常见排错。

如果你正在参与内核驱动开发，或者你在公司内部负责开源代码合入前的质量审查，这篇文章能帮你回答三个问题：LLM 在内核代码审查里到底能干什么、不能干什么；怎么设计一套安全边界清晰的接入策略；以及如何验证这套策略真的有效。

1. 为什么 staging 目录会成为 LLM 进入内核的第一站

先解释背景。drivers/staging 是 Linux 内核里一个特殊的目录，专门用来接收还没有达到主线质量标准的驱动代码。新驱动可以先合并进 staging，通过持续修复、清理、补测试，逐步满足内核社区的代码规范，再考虑移动到正式目录。对内核社区来说，这个目录是“新代码进入内核的前置等待区”；对很多硬件厂商和开源开发者来说，这是让驱动被内核接受的快速通道。

问题在于，staging 目录长期存在两个矛盾。

第一，补丁数量多且重复性问题高。代码风格不符合checkpatch规范、缺少必要的错误处理、注释不清晰、Kconfig 依赖配置错误、内存分配没有检查返回值，这些是非常典型的新驱动代码问题。维护者每天要花大量时间在“格式修正”和“基础健壮性检查”上，真正需要深度判断的架构问题反而被挤占了。

第二，很多提交者并不熟悉内核社区的规范化流程。硬件工程师、嵌入式开发者、芯片厂商的 BSP 工程师，擅长写驱动逻辑，但未必熟悉内核的补丁格式、提交信息规范、review 流程。一个经验丰富的维护者扫一眼补丁，能立刻发现十几处问题；但让新手自己反复自查，效率很低。

这就是 LLM 的切入点。

从当前技术能力来看，大语言模型非常适合做“高频、低判断成本、有明确规则可循”的代码初筛。格式问题、命名问题、遗漏的错误分支、明显的资源未释放，这些恰恰是 LLM 比较擅长的模式识别。而 staging 目录正好积累了海量同类补丁，构成了天然的训练和测试场景。

更关键的是，staging 目录的实验成本相对低。它本身就是“未达到最终标准”的代码聚集地，即使 LLM 建议有偏差，不会直接破坏内核核心模块。所以，如果要在内核社区中试验 LLM 辅助代码审查，drivers/staging 是最合理的切入点。这也是相关讨论中把位置限定在drivers/staging/ going forward的原因：范围先行，避免在核心目录做不可控实验。

但这里要给出一个明确判断：LLM 适合放在“入口预筛”这一层，而不是“出口决策”这一层。它可以帮维护者把 80% 的重复劳动消化掉，但不能让它决定“这个驱动是否合格”。策略设计的核心，不是让 LLM 变得更权威，而是给它的使用划出边界。

2. 所谓“LLM policy”到底在定义什么

“policy”这个词很容易被误解成“我们是否允许用 LLM”。实际上，允许或禁止只是一种最简单、最粗颗粒度的策略。真正有价值的 LLM 策略，是在回答下面四个问题：

1. 范围：LLM 被允许处理哪些代码和哪些任务？
2. 方式：LLM 的审查结果是作为“建议”还是作为“阻断条件”？
3. 责任：如果 LLM 的建议有误，谁负责最终判断？
4. 审计：LLM 给出的结果是否能被追溯、复现和评估？

这四个问题缺一不可。很多团队在引入 AI 辅助代码审查时只关注了“方式”，比如写一个提示词然后把 LLM 输出贴到 PR 里。但如果没有定义范围和责任，很快会出现两种极端：要么 LLM 的建议被盲目接受，引入隐性风险；要么 LLM 的建议被维护者全部忽略，工具形同虚设。

从相关社区讨论来看，更稳的策略是“分层治理”。也就是说，不是一刀切地要求所有补丁都过 LLM，而是按任务类型和代码路径进行分流。比如：

• 针对 staging 新驱动代码，LLM 可以执行“格式与常见缺陷预筛”。
• 针对已进入 RC 阶段的修复补丁，LLM 不参与，因为这类补丁风险高、时间敏感。
• 针对安全相关修复，LLM 可以帮忙检查，但绝不能由 LLM 直接给出合入结论。

另外，策略必须有“人机分工”的描述。最合理的定位是把 LLM 视作“一个很勤奋但经验不足的初级审查员”。它可以快速找出可疑点，但每个可疑点都需要具备内核开发经验的维护者确认。这个定位可以帮助团队避免两个极端：过度信任和完全排斥。

还有一个容易忽略的点是数据边界。内核补丁涉及厂商未发布的硬件信息、内部接口设计以及潜在的安全漏洞描述。如果把补丁内容直接提交给第三方 LLM API，会带来信息泄露风险。因此，策略中应当包括“哪些代码不允许发送到外部 LLM 服务”以及“是否需要在本地部署模型”。这一条在后续落地时会直接影响脚本设计。

所以结论是：LLM policy 不是一纸禁令，也不是一份使用手册，而是给 LLM 参与代码审查这件事建立一套可执行、可回滚、可问责的流程规范。

3. staging 代码的典型特征与 LLM 适配性分析

要设计策略，先得知道 staging 代码里最常见的问题是什么。这里不做枚举式罗列，而是用一张表把“典型问题类型”和“LLM 适配度”对应起来。

从这张表可以得出一个清晰的结论：LLM 在 staging 目录的“初筛层”价值最大，在“架构评审层”价值有限。

很多新手在尝试用 LLM 做代码审查时犯的错误是：让 LLM 看一个完整的驱动文件，然后问“这个代码有什么问题”。输出结果往往非常笼统，甚至会给出错误的优化建议。正确做法是给 LLM 定义非常窄的任务，例如：

• 只检查本次补丁涉及的文件。
• 只查找某个特定类型的问题。
• 只输出符合规则列表的异常点。

换句话说，不是 LLM 本身能力不够，而是任务定义太宽泛。审查任务越具体，LLM 输出越可靠。这也是为什么策略中需要包含“任务清单”或“检查项列表”，而不是一句“让 AI 审查代码”就完事。

这里还要澄清一个常见误区：LLM 不是checkpatch的替代品。checkpatch.pl是内核自带的规则检查脚本，规则明确、执行稳定，这类工作根本不需要 LLM。LLM 的真正优势是处理“没有现成脚本规则，但又有明显模式”的问题，比如“函数过长且责任不单一”“错误处理路径可能遗漏了某个条件”“新增的配置文件没有在 Makefile 中引用”。

所以，在实际策略设计中，我更推荐的做法是：先用传统工具做硬性规则检查，再把 LLM 用在传统工具覆盖不到的地方。两者是接力关系，不是竞争关系。

4. 一套可落地的 LLM 审查策略设计

现在我们进入“怎么设计一套策略”的部分。这里不讨论复杂的官僚流程，只讲可执行的分层结构。我建议把整个流程设计成三层：

第一层：传统静态规则层

运行checkpatch.pl、编译检查、稀疏检查（sparse）、smatch等既有工具。这层不涉及 LLM，负责拦截所有可以通过硬规则识别的问题。这一层的优势是确定性高、问题可复现、误报率可控。

第二层：LLM 预审层

把通过第一层检查的补丁发给 LLM，按预定义的任务清单做“常识性缺陷”预审。LLM 输出结构化结果，格式是“问题位置 + 问题类型 + 可能原因 + 建议”。输出不直接标注“必须修改”，而是标明“建议人工确认”。

第三层：人工评审层

维护者查看第一层的工具输出和第二层的 LLM 建议，结合自己的经验做最终判断。只有这一层可以决定补丁是否进入下一阶段。LLM 在这个流程里承担的角色是“信息增强”，不是“决策替代”。

在这个三层结构里，策略要定义的关键点是：哪些补丁必须走第二层，哪些可以跳过。比如：

• 新增文件超过 500 行的驱动补丁，必须走 LLM 预审。
• 只修改注释、文档、Kconfig 描述的补丁，可以跳过 LLM 预审。
• 涉及 DMA、中断、并发控制的补丁，LLM 预审结果只做参考，必须由指定维护者人工评审。
• 任何情况下，LLM 输出不得直接作为Acked-by或Reviewed-by的依据。

策略还要定义“回滚路径”。如果 LLM 预审服务出现故障，或者某个阶段的误报率明显升高，流程应该自动降级为“传统工具 + 人工评审”，不能因为工具故障阻塞补丁合入。

下面用一个最小可运行的示例来演示第二层怎么落地。

5. 配置示例与实现：最小 LLM 预审流程

这一节给出一个可以在本地跑通的最小示例。为了不依赖特定厂商的 API，代码中使用环境变量传入 API 地址和密钥，模型名称也通过配置指定。实际使用时要根据你选择的模型服务商调整地址和认证方式。

5.1 准备环境

建议准备一台 Linux 开发机，安装 Python 3.9+，并准备一个可以访问 LLM API 的环境。为了演示，我们将项目结构设计为：

llm-staging-review/ ├── config.yaml ├── prompt_template.md ├── review_diff.py └── run_review.sh

如果不想把配置放在代码里，可以把 API 地址和密钥写入环境变量，这是更安全的做法。后面示例会同时展示两种方式。

5.2 定义配置文件

配置文件用来切分任务范围。下面是一个config.yaml示例：

# 文件路径：llm-staging-review/config.yaml llm: api_url_env: "LLM_API_URL" api_key_env: "LLM_API_KEY" model: "your-model-name" # 以实际可用模型为准 temperature: 0.1 max_tokens: 1000 review: # 只检查本次 diff 中新增或被修改的 .c / .h 文件 file_extensions: - ".c" - ".h" # 检查项清单，每个检查项会写入提示词 check_items: - "kmalloc/kzalloc/devm_kzalloc 返回值是否检查" - "错误处理路径中是否有资源泄漏" - "是否存在明显变量未使用或类型不匹配" - "注释是否与实际代码逻辑一致" safety: # 超过该行数的文件不发送给外部 LLM，防止泄露过多代码 max_file_lines: 800 # 禁止发送到外部 LLM 的路径关键字 blocked_path_keywords: - "firmware" - "internal"

这里有两个安全设计值得解释。第一，max_file_lines用来限制单个文件发送规模，避免把整个大驱动文件一次性抛给外部模型。第二，blocked_path_keywords用于识别敏感路径，凡是路径包含firmware或internal的文件，直接跳过 LLM 预审，防止敏感代码外传。

5.3 编写提示词模板

提示词模板是整个预审流程的核心。模板越结构化，输出越容易解析。下面是一个最小模板：

# 文件路径：llm-staging-review/prompt_template.md 你是一名 Linux 内核驱动代码审查助手。你负责对以下补丁进行预审，目标不是做完整代码评审，而是只查找预定义检查项中可能存在的问题。 请严格按以下步骤执行： 1. 阅读补丁中涉及的每个文件。 2. 只检查下面列出的检查项，不要扩大审查范围。 3. 对每个发现的问题，按以下格式输出： - 文件路径 - 行号（如果可以从 diff 中判断） - 问题类型 - 可能原因 - 严重程度：高 / 中 / 低 - 人工确认建议：需要 / 可以忽略 检查项： {% for item in check_items %} - {{ item }} {% endfor %} 注意： - 如果某检查项没有发现问题，不要编造问题。 - 不要修改补丁，不要提供完整重写代码。 - 不要给出与检查项无关的优化建议。 - 不要输出 Markdown 表格，逐条列出即可。

模板中使用了简单的变量占位语法。在实际脚本中，将当前补丁的 diff 内容追加到模板之后，再发送给 LLM。这种“规则前置 + 问题后置”的结构，能显著减少 LLM 自由发挥的空间。

5.4 编写调用脚本

下面用一个 Python 脚本读取配置和 diff，然后调用 LLM API。这里仅演示流程，不绑定具体 SDK，使用标准库urllib发送 HTTP 请求，方便替换成任意 API 服务。

# 文件路径：llm-staging-review/review_diff.py import json import os import subprocess import sys import urllib.request import yaml def load_config(path="config.yaml"): with open(path, "r", encoding="utf-8") as f: return yaml.safe_load(f) def get_diff(base_commit, head_commit): cmd = ["git", "diff", base_commit, head_commit] result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print("git diff 执行失败：", result.stderr) sys.exit(1) return result.stdout def filter_diff_by_extensions(diff, extensions): """ 简单过滤：这里为了演示，只检查 diff 文本中出现的文件扩展名。 更严谨的做法是用 git diff --name-only 获取文件列表后逐文件读取。 """ lines = diff.splitlines() filtered = [] for line in lines: if line.startswith("+++ b/") or line.startswith("--- a/"): if any(line.endswith(ext) for ext in extensions): filtered.append(line) else: filtered.append(line) else: filtered.append(line) return "\n".join(filtered) def build_prompt(config, diff_text): with open("prompt_template.md", "r", encoding="utf-8") as f: template = f.read() check_items = "\n".join(f"- {item}" for item in config["review"]["check_items"]) template = template.replace("{% for item in check_items %}", "") template = template.replace("{% endfor %}", "") template = template.replace("{{ item }}", check_items) prompt = template + "\n\n以下是补丁内容：\n```diff\n" + diff_text + "\n```\n" return prompt def call_llm(config, prompt): api_url = os.environ.get(config["llm"]["api_url_env"]) api_key = os.environ.get(config["llm"]["api_key_env"]) if not api_url or not api_key: print("请先设置环境变量 LLM_API_URL 和 LLM_API_KEY") sys.exit(1) payload = { "model": config["llm"]["model"], "messages": [{"role": "user", "content": prompt}], "temperature": config["llm"]["temperature"], "max_tokens": config["llm"]["max_tokens"], } req = urllib.request.Request( api_url, data=json.dumps(payload).encode("utf-8"), headers={ "Content-Type": "application/json", "Authorization": f"Bearer {api_key}", }, method="POST", ) with urllib.request.urlopen(req, timeout=120) as resp: body = json.loads(resp.read().decode("utf-8")) return body["choices"][0]["message"]["content"] def main(): if len(sys.argv) < 3: print("用法：python review_diff.py <base_commit> <head_commit>") sys.exit(1) base_commit = sys.argv[1] head_commit = sys.argv[2] cfg = load_config() diff_text = get_diff(base_commit, head_commit) filtered = filter_diff_by_extensions(diff_text, cfg["review"]["file_extensions"]) prompt = build_prompt(cfg, filtered) result = call_llm(cfg, prompt) print(result) if __name__ == "__main__": main()

再提供一个简单的 shell 包装脚本，方便设置环境变量并运行：

# 文件路径：llm-staging-review/run_review.sh #!/usr/bin/env bash set -euo pipefail export LLM_API_URL="${LLM_API_URL:-https://api.example.com/v1/chat/completions}" export LLM_API_KEY="${LLM_API_KEY:-}" if [ -z "$LLM_API_KEY" ]; then echo "请设置 LLM_API_KEY 环境变量" exit 1 fi python3 review_diff.py "$1" "$2"

执行前需要给脚本添加执行权限：

chmod +x run_review.sh

5.5 运行与验证

假设你的代码仓库里有一个本次要审查的补丁，运行方式如下：

export LLM_API_URL="https://api.example.com/v1/chat/completions" export LLM_API_KEY="your-secret-key" ./run_review.sh HEAD~1 HEAD

正常输出应该是结构化的“问题清单”，每一条包含文件路径、行号、问题类型、严重程度和人工确认建议。

判断运行是否成功，可以从三个方面看：

• 脚本退出码为 0。
• 输出内容不等于空。
• 输出条目都是预定义检查项相关的问题，而不是泛泛的“代码质量建议”。

如果输出为空，可能有两种情况：本次补丁确实没有命中检查项，或者提示词被模型误解。可以手动把构建好的 prompt 打印出来检查一次。

6. 如何评估 LLM 预审的效果

部署一个流程不等于流程有效。真正困难的是评估“LLM 预审到底带来了多少价值”。我的建议是不要凭感觉判断，而是搭建一个简单的回测机制。

第一步，收集历史数据。从 staging 目录的 git 历史中抽取最近 50 到 100 个补丁，这些补丁已经被维护者评审并合入，相当于有了一份经过人工确认的“标准答案”。

第二步，对这些历史补丁运行 LLM 预审。把 LLM 输出中标记为“高严重程度”的问题，与维护者实际提出的修改意见做对比。

第三步，计算两个关键指标：

• 检出率：维护者提出的问题中，有多少比例被 LLM 提前发现。这个指标衡量 LLM 的“覆盖能力”。
• 误报率：LLM 输出中被维护者判定为“错误或不适用”的问题占全部输出的比例。这个指标衡量 LLM 的“信任成本”。

一个比较合理的目标是：检出率高于 60%，误报率低于 30%。如果误报率偏高，说明检查项定义不够准确，或者提示词边界不够清晰，需要调整。

这里提醒一点：不要追求 100% 检出率。LLM 预审的目标是过滤重复性劳动，不是替代人工评审。即使检出率只有 50%，如果能帮维护者节省一半的“格式修正”时间，策略依然有效。

还可以在流程中引入“打标反馈”。维护者在人工评审时，可以对 LLM 的建议标记“有用 / 无用 / 误报”，这些标记可以积累成下一轮策略优化的数据。这一步听起来麻烦，但它是让策略持续有效的核心。

7. 常见问题与排查方法

在实际落地过程中，团队会遇到不少问题。下面列几个典型场景，并给出排查路径。

还有一个很容易被忽略的问题：diff 解析不完整。很多初学者直接把git diff的全量输出发给 LLM，结果模型只能看到部分文件，或把上下文理解错。更稳妥的做法是先用git diff --name-only获取文件列表，再逐个文件构建 diff 文本，最后把文件路径和具体 diff 段一起发给模型。这样可以显著降低误报。

8. 工程建议与安全边界

最后这一节，我给出团队落地这套策略时的工程建议。这些建议不只在 staging 目录适用，对任何想在内核开发流程中引入 LLM 的团队都有参考价值。

第一，坚持“传统工具优先”。能用脚本解决的问题不要用 LLM。格式检查、编译错误、明显的未使用变量，都应该交给确定性工具。LLM 只处理规则难以覆盖的语义问题。这样既能保证准确率，也能减少对模型服务的依赖。

第二，严格限制外部数据流。不要把整个仓库或敏感驱动文件发送给第三方 API。建议在本地部署模型，或者只发送必要的 diff 片段。对涉及未发布硬件信息和潜在安全漏洞的补丁，宁可跳过 LLM 预审，也不要把数据泄露出去。

第三，保留完整的审计链路。每次 LLM 预审的输入、输出、模型版本、配置参数都应该记录下来。这样当某个建议被证明是错误时，可以回溯是模型问题、提示词问题还是检查项定义问题。

第四，最小权限原则。执行 LLM 预审的账号，只应该拥有读取代码仓库的权限，不拥有合入权限。脚本运行环境和 API 密钥要分开管理，密钥不能硬编码在代码仓库中。

第五，策略要可回滚。在引入 LLM 预审的初期，建议采用“影子模式”：LLM 的结果只展示给维护者，不影响合入门禁。运行两到四周后，根据检出率和误报率再决定是否把 LLM 预审作为正式合入流程的一环。

第六，不要在夜间自动化合入。即使以后流程越来越成熟，也不建议让 LLM 预审结果直接驱动自动化合入。内核代码的合入决定应该始终由有责任意识的人来做。

这些原则其实不复杂，但执行中很容易变形。最容易犯的错误是：初期尝到甜头后，不断扩大 LLM 的权限范围。等到某个错误建议被自动合入，才发现边界已经被突破。所以，策略的价值不在于写得多严密，而在于边界是否能被长期坚持。

9. 总结与后续方向

回到最初的问题：LLM policy for drivers/staging/ going forward 应该是什么样？

从当前技术成熟度和内核社区的工作方式来看，更合理的策略不是全面拥抱，也不是完全排斥，而是把 LLM 定位成 staging 目录补丁的“预审助手”。它帮助维护者过滤重复性问题，提高补丁初筛效率，但所有决策权仍然保留在人工评审环节。策略的边界、数据安全、审计链路和降级路径，比模型本身的能力更值得花时间设计。

如果你接下来想继续研究，可以沿着三个方向深入。第一，用历史补丁数据对 LLM 预审做量化回测，建立自己团队的评价指标。第二，尝试在本地部署一个开源模型，把数据安全边界彻底控制在自己手里。第三，把这条流程从 drivers/staging 逐步扩展到团队负责的其他模块，但每一步都要先定义好范围、责任和回滚方案。

内核开发的严谨性来自流程，而不是来自某一个工具。LLM 可以成为这个流程的一部分，但前提是它待在适合自己的位置上。