当大语言模型开始批量产出安全漏洞报告，一个意想不到的副作用正在 Linux 内核社区显现：维护者正借助这些自动化报告加速清理遗留代码。根据 Hacker News 近期热点和 LWN.net 报道，内核社区正在评估移除多个长期缺乏维护的子系统，包括 AX.25 业余无线电协议、ATM 信令驱动以及 ISDN 相关代码块。这一趋势既展示了 AI 辅助安全的效率潜力，也暴露了自动化决策的深层风险。
LLM 安全报告的激增背景
过去一年内，基于大语言模型的代码安全分析工具经历了爆发式增长。这些工具能够快速扫描海量代码库，识别潜在的漏洞模式、内存不安全操作和过时的 API 使用。Linux 内核作为全球最复杂的开源项目之一，自然成为这类工具的重点分析对象。然而，LLM 的高频扫描产生了数量惊人的安全报告，其中相当比例指向了内核中那些很少被现代代码审查覆盖的遗留模块。
这些遗留代码通常具有以下特征：维护者已经长期未提交更新、缺乏单元测试覆盖、使用的 API 已在新版内核中标记为废弃，以及代码路径在实际系统中几乎不会被触发。典型例子包括对古老硬件架构的支持代码、已经退出市场的网络协议实现，以及仅在特定历史配置下才会激活的驱动模块。当 LLM 扫描工具以自动化方式对这些代码进行安全审计时，它会发现大量潜在问题，其中既有真实的安全缺陷，也有因代码上下文缺失而产生的误报。
驱动代码移除的直接原因
LWN.net 报道指出，内核社区正在讨论的代码移除并非单纯的 “清理项目”，而是直接回应 LLM 生成的安全报告潮。具体而言，以下几类代码正在被评估或已经列入移除计划：
网络协议子系统是重灾区之一。AX.25 业余无线电协议栈、ATM 信令驱动以及古老 ISDN 相关代码的维护负担正在被重新评估。这些协议在当代网络环境中几乎不再使用，但其代码路径仍然存在于内核树中，持续产生安全分析噪声。维护者指出，继续保留这些代码的安全审查负担已经超过了其实际价值。
PCMCIA 和古老以太网驱动同样面临类似处境。这些驱动对应的硬件设备早已退出主流市场，相关硬件在生产环境中几乎不复存在。然而，这些驱动代码仍然需要通过内核的安全审查流程，包括定期的 CVE 扫描和模糊测试。当 LLM 工具将这些代码标记为潜在风险时，维护者必须投入大量时间进行逐个确认，而确认结果往往是 “该代码路径在实际部署中不可达”。
ISA 和古老 PCI 驱动也在清理名单之列。这些驱动支持的是上世纪九十年代和本世纪初的硬件设备，现代服务器和工作站已经完全不再使用。保留这些代码的唯一理由是 “可能有人还在用”，但实际维护成本已经无法忽视。
值得注意的是，这种由 LLM 报告驱动的代码移除与传统的内核清理存在本质区别。传统清理通常由维护者主动发起，基于 “代码无人维护” 的事实做出决策。而 LLM 驱动的清理则引入了新的变量：自动化工具发现的安全问题成为了推动清理的催化剂。这使得一些原本可以 “勉强维持” 的代码被迫进入审查流程，因为 “不修复这些 LLM 报告的问题” 本身成为了一个需要解释的问题。
自动化清理的效率收益
从积极角度看，LLM 驱动的代码移除为内核社区带来了显著的效率提升。首先是暴露长期技术债务：一些内核模块虽然名义上有维护者，但实际上已经多年未经任何代码审查。LLM 的自动化扫描首次系统性地对这些 “被遗忘的角落” 进行了安全审计，迫使社区正视这些技术债务的真实成本。
其次是加速决策流程。过去，移除一个内核子系统需要漫长的讨论和理由说明，移除提案往往因为 “可能还有用户在用” 的理由被搁置。LLM 报告提供了一个量化视角：当某个模块在安全扫描中持续产生风险标记，而确认修复的工作量远超保留价值时，移除的正当性变得显而易见。
第三是改善安全覆盖质量。传统安全扫描依赖已知漏洞签名和规则，对遗留代码的覆盖往往不足。LLM 的上下文理解能力使其能够发现一些传统工具会遗漏的潜在问题，例如不当的权限检查、竞态条件窗口以及错误处理缺失。当这些发现被系统性地汇总时，它们为代码移除决策提供了更充分的依据。
隐藏的风险与局限性
然而，将 LLM 生成的安全报告作为代码移除的主要驱动力存在不可忽视的风险。误报率问题首当其冲。Hacker News 讨论中多位开发者指出，LLM 容易产生 “幻觉” 式的安全发现，将完全不构成风险的代码模式误判为漏洞。在内核代码这种对正确性要求极高的环境中，任何基于自动化报告的移除决策都必须经过严格的人工复核。问题是，当 LLM 报告的数量达到一定规模时，人工复核本身就成为了瓶颈，这形成了与初衷相悖的悖论。
上下文丢失是另一个核心问题。LLM 在分析单个文件或函数时可能表现出色，但它难以完整理解内核代码的调用层级和配置依赖。一个被标记为 “危险” 的函数可能在所有实际配置下都不可达，或者仅在特定的废弃编译选项下才会激活。缺乏这种上下文理解的 LLM 报告可能导致两种后果：要么产生大量需要人工排除的噪声，要么在未经充分验证的情况下推动代码移除，进而可能影响极少数仍然依赖这些特性的用户。
维护者社区的应对能力也值得审视。LLM 报告驱动的清理意味着内核社区需要持续处理自动化工具输出的 “待办事项”。如果每个 LLM 安全发现都需要人工评估，那么维护者的工作量可能不降反增。更关键的是，当 LLM 报告的质量参差不齐时，维护者可能会产生 “报告疲劳”，对真实的严重漏洞失去敏感度。
工程实践中的关键参数
对于希望在工程实践中引入 LLM 驱动代码清理的团队，以下参数和监控点值得参考。
报告分级阈值应作为第一道防线。建议设置明确的严重性分级标准，仅针对高严重性发现启动代码移除评估流程。例如，可以将 LLM 报告分为四级，仅当报告涉及可利用的内存安全问题、权限提升向量或拒绝服务触发条件时，才将其纳入清理候选。这种分级过滤可以显著减少低质量报告对维护带宽的消耗。
人工复核覆盖率是质量保证的核心指标。建议对所有触发代码移除决策的 LLM 报告实施 100% 人工复核，复核内容包括：确认漏洞在目标配置下确实可达、评估利用条件和影响范围、验证移除不会破坏向后兼容性。复核应由熟悉相关子系统代码的维护者执行，而非交由通用安全团队代为判断。
回归测试覆盖在代码移除场景下尤为关键。与功能修改不同，代码移除的影响难以通过增量测试完全覆盖。建议为每个待移除模块构建最小化测试集，确保移除后内核在默认配置和主流配置下仍然能够正常编译和运行。对于可能影响少数用户的特性，应提供可加载模块或内核参数作为过渡方案。
回滚策略同样不可或缺。建议在代码移除合并前确认以下条件：存在可验证的构建产物用于回滚比较、邮件列表中有明确的移除通知且过了合理反对期、至少有一个人承诺在移除后一段时间内响应回归报告。当出现未预见到的兼容性问题时，应能在下一个内核发布周期内恢复被移除的代码。
监控指标与持续改进
引入 LLM 驱动的代码清理机制后，建议持续监控以下指标以评估系统效果和识别问题。
LLM 报告转清除率衡量自动化报告经过人工复核后被确认为真实问题的比例。该指标过低说明 LLM 误报率较高，需要调整提示词或引入额外的过滤层；过高则可能说明阈值设置过于宽松，存在遗漏真实问题的风险。
从报告到移除的平均周期反映清理效率。如果周期过长，可能说明人工复核或讨论流程存在瓶颈；如果周期过短，可能说明评估不够充分，存在草率决策的风险。
移除代码的回归报告数量是最终的质量验证指标。理想情况下，经过充分评估的代码移除不应产生可观测的回归。如果出现回归，说明移除前的评估存在遗漏，需要回溯改进评估流程。
维护者满意度是软性但重要的指标。可以通过定期调查或邮件列表情感分析来评估维护者对 LLM 驱动清理机制的接受程度。当维护者普遍感到这一机制增加了而非减轻了他们的工作负担时，机制本身需要重新设计。
走向人机协作的平衡点
LLM 安全报告驱动内核代码移除的现象，折射出软件开发领域人机协作的深层张力。一方面，自动化工具确实能够以人类无法企及的规模发现问题，打破人工审查的盲区；另一方面，将自动化发现直接转化为代码决策存在明确的边界和风险。
对于 Linux 内核这样的关键基础设施而言，合适的路径可能是将 LLM 定位为 “增强而非替代” 人类判断的助手。LLM 负责提供安全发现的初筛和上下文摘要，而最终是否移除代码仍由维护者基于经验和对用户生态的理解做出判断。在这一模式中，LLM 的价值不在于自动产生决策，而在于将人类从海量低质量噪声中解放出来，使其能够专注于真正需要专业判断的决策节点。
这场由 LLM 驱动的内核代码清理实验，无论最终被证明是成功范例还是需要回调的教训，都为整个软件工程行业提供了宝贵的实践经验：当自动化工具开始参与关键的代码治理决策时，如何设计机制以确保效率提升不会以决策质量为代价，是每个技术团队都需要面对的问题。
资料来源
- Hacker News 讨论："Kernel code removals driven by LLM-created security reports"，https://news.ycombinator.com/item?id=47862230
- LWN.net 相关报道，https://lwn.net/Kernel/