Sashiko AI代码审查报告深度解析：一份真实内核补丁是怎么被“审“的？

Sashiko是一个用 AI 对 Linux 内核补丁做自动化代码审查的开源项目。很多人好奇：它给出的 AI 代码审查报告到底长什么样？这一篇就带你拆开一份真实风格的内核补丁审查报告，看看 Sashiko 的报告里有什么、为什么这样设计，以及每个部分背后对应的审查流水线阶段。

先跑一遍：报告从哪里来

如果你只是想在本地看一眼报告长什么样，最简单的方式是在自己的内核源码树里执行本地审查（无需 daemon 和数据库）：

sashiko review # 审查最近一次提交 sashiko review HEAD~3..HEAD

Sashiko 支持两种使用形态：本地执行sashiko review直接在你的 git 检出上审查；或者部署 daemon 自动从邮件列表（lore.kernel.org）和 GitHub/GitLab 拉取补丁审查，并把结果以回复邮件的形式发回 LKML。无论哪种形态，最终产出的报告结构是一样的：一段摘要（summary）加一份LKML 风格的行内审查报告（review_inline）。

报告背后的流水线：7个分析阶段 + 3个整合阶段

报告不是"一次性生成"的，而是 src/workflows/linux_patch_review.rs 中一条声明式流水线跑出来的，整体流程分三步：

几个关键设计：

• 早期退出：如果分析阶段一个疑点都没提出，流程直接终止，不会产生任何报告——所以"无报告"本身就是一种信号。
• 对称举证：要推翻一条疑点，必须给出具体反证代码（守卫、锁、清理路径），不能靠"假设调用者会处理"这种猜测。规则写在 src/workflows/linux_patch_review.rs 的验证阶段指令里。
• 每份 finding 带位置锚点：精确到file、function_or_symbol、line、code_snippet，报告阶段的行内评论就靠这些锚点贴着代码生成。

报告里的四级严重度：Critical / High / Medium / Low

报告中的每条发现都会带一个严重度标签。分级标准定义在 projects/sashiko/prompts/severity.md，要求先写出"定级理由"再贴标签（severity_explanation），核心思路是看爆炸半径 + 触发概率：

还有一个细节：如果某条问题不是这个补丁引入的（"preexisting": true），报告里会明确标注"这个问题不是由本补丁引入的，但……"，避免误导作者。

报告到底长什么样：逐段拆解一个真实案例

report阶段的格式规则完全由 third_party/prompts/kernel/inline-template.md 定义。下面这份样本就来自该模板（一个 mm 子系统的真实风格审查）：

commit 06e4fcc91a224c6b7119e87fc1ecc7c533af5aed Author: Kairui Song <kasong@tencent.com> mm, swap: only scan one cluster in fragment list <commit 摘要，最多 3 句> > diff --git a/mm/swapfile.c b/mm/swapfile.c > @@ -926,32 +926,25 @@ static unsigned long cluster_alloc_swap_entry(...) > if (order < PMD_ORDER) { > - frags_existing = atomic_long_read(&si->frag_cluster_nr[order]); > - while (frags < frags_existing && > - (ci = isolate_lock_cluster(si, &si->frag_clusters[order]))) { > - atomic_long_dec(&si->frag_cluster_nr[order]); ^^^^ [Severity: High] Is it ok to remove this atomic_long_dec()? It looks like the counter updates are getting lost. > + /* > + * Scan only one fragment cluster is good enough. ... ^^^^^^^^ [Severity: Low] this isn't a bug, but you've duplicated this line > + ci = isolate_lock_cluster(si, &si->frag_clusters[order]);

对照着看，一份 Sashiko 报告由这几个部分构成：

1. 头部元信息（报告骨架）

• commit SHA与Author行：直接取自被审查的提交；
• 主题行 + 摘要：commit 内容的一句话概述；
• >引用的 unified diff：报告本质上是一封"邮件回复"，所以 diff 以引用形式出现，不相关的 hunk 会被[ ... ]激进裁剪，只保留与疑点相关的片段。

2. 行内评论：贴着代码提问，而不是指责

这是 Sashiko 报告最有辨识度的一点。模板对语气有严格规定：

• 用提问代替断言：不说"你在这里损坏了内存"，而说"Can this corrupt memory?"；
• 不出现行号：行号只在审查环境里有意义，邮件列表上的读者不知道你看的是哪个代码库，所以一律用"文件名 + 函数名 + 小段代码"来定位；
• 具体到变量名：不说"这个循环有越界问题吗"，而说"Does this code overflow xyz[]?"；
• 禁止全大写字母、禁止 markdown、禁止夸张措辞，纯 78 列换行的纯文本。

3. 严重度标签

每条行内评论上方单独一行[Severity: <级别>]，取 Critical / High / Medium / Low 四级。主观建议类问题则不带标签，用一句"this isn't a bug, but……"轻轻带过。

4. 摘要与修复建议

除行内报告外，结果 JSON 里还有summary（一段话概括本次变更）和fixes（修复建议）。当一次提交审查多个 commit 时，各 patch 的摘要会按编号合并输出。

报告有多可靠：48 条真实审查的数据统计

仓库自带了一份对 48 条真实内核审查线程的抽样统计（third_party/prompts/kernel/examples/review-stat.txt），数据很有说服力：

• 34 条完全正确，其中13 条在补丁后续版本中真的被修复；
• 13 条不正确——错因大多是"只看了单个补丁，没理解多补丁系列上下文"或"不理解 RCU 语义"这类边界问题；
• 错误类别分布上，内存问题（泄漏、未初始化）命中率最高，其次是指令错误和竞态。

维护者对错误报告也有明确的态度，比如 BPF 维护者 Alexei Starovoitov 在 LKML 上的评价（收录于 PRESS.md）："我读过了 AI 的调试日志。它推理出这个 fix 是正确的过程说服了我，Applied。"README 中也给出了整体基准：在带Fixes:标签的上游提交上，Sashiko 检出了约53.6%曾逃过人工审查的 bug，误报率低于20%。

上手清单：如何看到这样一份报告

1. cargo install sashiko安装，配置LLM_API_KEY（默认 Gemini，也支持 Claude、OpenAI 兼容端点等，见 docs/llm-providers.md）；
2. 在内核源码树中执行sashiko review，终端里即可看到上述格式的纯文本报告；
3. 想深入自动化场景，可阅读 MAINTAINERS_GUIDE.md（邮件列表跟踪、邮件策略）和 docs/daemon.md（daemon 部署与 Web UI）。

一句话总结：Sashiko 的报告 = 邮件回复格式的 diff 骨架 + 贴着代码的行内提问 + 可审计的四级严重度。它的可信度不来自"AI 说了算"，而来自多阶段验证流水线里那条"没有具体反证代码就不许剔除疑点"的对称举证规则。