最近 Linux 内核社区出现了一个有趣的分裂：Greg Kroah-Hartman 对 AI 工具赞不绝口，Linus Torvalds 却气得直吐槽。表面上看两人立场对立，细读之下你会发现——他们的表述并不矛盾。内核社区作为一个整体也许扛得住这波冲击，但安全邮件列表（security mailing list）这个特定工作流，已经接近崩溃边缘。
两位大佬到底在说什么
Greg 的态度很明确：AI 工具帮他更快地完成重复性审查工作，尤其是对补丁格式的初步检查、常见错误的快速定位。对于维护稳定树、处理海量补丁的 Greg 来说，AI 是加速器。
Linus 的愤怒指向另一个方向：他看到的是质量低劣的 AI 生成补丁批量涌入，提交者自己都不理解代码的含义，只是让 AI 糊出一堆"看起来像补丁"的东西然后群发。这不是加速，这是噪音。
两人说的其实是同一件事的两个面——AI 放大了已有的压力。对经验丰富的维护者，AI 是工具；对缺乏经验的提交者，AI 是批量制造垃圾的流水线。问题不在 AI 本身，而在 AI 把一个已经脆弱的工作流彻底推过了临界点。
安全邮件列表：最先断裂的那根线
内核社区有多个子系统邮件列表，各由对应维护者过滤。安全邮件列表不同——它的处理流程更严格、更敏感，涉及漏洞披露和修复协调，本身就需要更高的审慎度。
当 AI 生成补丁开始批量涌向这个列表时，几个具体问题同时爆发：
- 数量激增：AI 让生成补丁的成本降到几乎为零，一个人一天可以"提交"几十个补丁，而每个补丁都需要人工审查。
- 质量塌陷：AI 生成的补丁经常在语法层面正确，但逻辑层面错误——修了症状没修病因，或者引入新问题。审查者需要花更多时间才能判断一个补丁是否值得采纳。
- 责任模糊：提交者对补丁的理解深度下降，当审查者追问"为什么这样改"时，得到的回复往往是 AI 式的泛泛解释，而非基于对内核代码路径的真实理解。
这三者叠加，安全列表的审查带宽被彻底耗尽。
内核社区为什么"整体扛得住"
内核社区不是只有安全列表。大多数子系统维护者面对的补丁量虽然在增长，但仍在可处理范围内。原因有几层：
- 子系统维护者对各自领域有深度认知，AI 生成的低质量补丁在他们眼中一眼可辨。
- 社区有成熟的补丁分级流程——从
scripts/checkpatch.pl的格式检查到逐层审查，过滤机制是多级的。 - 大量补丁来自长期贡献者，他们的提交质量本身就有保障，AI 只是帮他们更快完成格式调整等琐碎工作。
换句话说，内核社区的整体韧性来自人的专业判断和多层过滤机制。但安全列表恰好是过滤机制最敏感、人工判断负担最重的环节——AI 洪流找到的就是这个最薄弱的点。
实践：给内核补丁审查加一层 AI 噪音过滤
面对 AI 生成补丁的涌入，维护者需要更高效的初筛手段。下面是一个可以直接使用的脚本，结合 notmuch（内核社区常用的邮件索引工具）和简单的文本特征检测，帮你从邮件列表中快速标记可疑的 AI 生成补丁：
#!/usr/bash
# ai_patch_filter.sh — 从内核安全邮件列表中标记可疑 AI 生成补丁
# 依赖: notmuch (邮件索引), git (补丁解析)
LIST_TAG="linux-kernel-security"
SUSPECT_DIR="./suspect_patches"
CLEAN_DIR="./clean_patches"
mkdir -p "$SUSPECT_DIR" "$CLEAN_DIR"
# 特征关键词 — AI 生成补丁的常见措辞模式
AI_KEYWORDS=(
"this patch fixes an issue"
"the above change ensures"
"this modification addresses"
"in order to improve"
"it is important to note"
"this commit introduces"
"the following changes have been made"
)
# 1. 用 notmuch 拉取最近7天的安全列表补丁邮件
notmuch search --output=files "tag:${LIST_TAG} and date:7d..today and subject:/\\[PATCH/" | while read -r mail_file; do
patch_id=$(basename "$mail_file" .mail)
subject=$(notmuch show --format=raw "id:${patch_id}" | head -1 | sed 's/^Subject: //')
# 2. 提取补丁正文（去掉邮件头和签名）
body=$(notmuch show --format=raw "id:${patch_id}" | \
sed '/^---$/,$!d' | \
sed '/^-- $/,$d')
# 3. 检测 AI 特征词密度
ai_hit_count=0
for kw in "${AI_KEYWORDS[@]}"; do
if echo "$body" | grep -qi "$kw"; then
ai_hit_count=$((ai_hit_count + 1))
fi
done
# 4. 检测补丁是否有实质性代码变更（纯文档/注释变更更容易是 AI 糊出来的）
code_lines=$(echo "$body" | grep -cE '^\+[^+]' || echo 0)
comment_lines=$(echo "$body" | grep -cE '^\+\s*(//|/\*|\*|#)' || echo 0)
# 5. 综合判定
if [ "$ai_hit_count" -ge 2 ] || [ "$comment_lines" -gt "$code_lines" ]; then
echo "[SUSPECT] $subject (AI特征命中: ${ai_hit_count}, 代码/注释比: ${code_lines}/${comment_lines})"
cp "$mail_file" "$SUSPECT_DIR/"
else
echo "[CLEAN] $subject"
cp "$mail_file" "$CLEAN_DIR/"
fi
done
echo "完成。可疑补丁在 ${SUSPECT_DIR}/，正常补丁在 ${CLEAN_DIR}/"
echo "建议优先审查 ${CLEAN_DIR} 中的补丁，对 ${SUSPECT_DIR} 中的补丁要求提交者补充人工解释。"
使用前需要做的事：
- 安装
notmuch并配置好邮件索引：notmuch setup，指向你的 Maildir。 - 给安全列表邮件打标签：
notmuch tag +linux-kernel-security -- from:security@kernel.org or list:linux-kernel-security.vger.kernel.org - 根据你观察到的实际 AI 补丁措辞，调整
AI_KEYWORDS数组——不同模型生成的补丁有不同的语言习惯。
这个脚本不是最终判断工具，而是初筛加速器——把明显可疑的补丁分到单独目录，让你优先审查高质量提交，对可疑补丁要求提交者给出更详细的解释。
更根本的问题：工作流需要进化
脚本只是应急手段。内核安全列表的危机暴露了一个更深层的问题：当生成成本趋近于零时，基于人工逐条审查的工作流必然崩溃。 这不是内核社区独有的困境——任何依赖邮件列表 + 人工审查的开源项目都会遇到同样的冲击。
可能的演进方向：
- 分级提交机制：首次提交者需要通过一个自动化质量门槛（类似 CI），才能向安全列表发送补丁。门槛不判断补丁是否正确，只判断提交者是否理解了自己提交的内容——比如要求附带一段人工撰写的分析说明。
- 补丁溯源标记：要求提交者声明补丁是否由 AI 辅助生成，以及具体用了哪些工具。这不是惩罚，而是让审查者调整审查深度——对 AI 辅助补丁做更细致的逻辑验证。
- 审查带宽管理：对单个提交者设定周期性提交上限，超出部分自动排队。这不是限制贡献，而是保护审查者的注意力。
这些方向各有取舍。分级机制可能阻挡有价值的首次贡献；溯源标记可能被隐瞒；提交上限可能降低修复速度。但什么都不做的代价更明确——安全列表继续崩溃，真正重要的安全补丁淹没在噪音中。
检查清单
如果你在维护一个依赖人工审查的开源项目，现在就该评估以下几项：
- [ ] 你的项目是否有补丁提交格式门槛（如
checkpatch）？如果没有，先加上最基本的自动化格式检查。 - [ ] 你的审查流程中，是否区分了"格式合规"和"逻辑正确"两个层级？AI 补丁经常通过前者但失败于后者。
- [ ] 是否有机制让提交者证明自己理解了补丁的含义？比如要求在 commit message 中描述"为什么这样改"而非"改了什么"。
- [ ] 你的邮件列表或 PR 流程是否有速率限制？如果没有，一个 AI 批量提交者可以在几小时内耗尽你的审查带宽。
- [ ] 你是否已经开始观察和记录 AI 生成补丁的语言特征？积累这些特征是构建自动化初筛的基础。
内核社区的这场争论不是"AI 好还是坏"的口水战——它是一个具体工作流在真实压力下断裂的现场报告。其他开源项目要么已经在经历同样的压力，要么很快就会。