Google工程师用AI审查Linux内核代码，53%的Bug人眼没看出来
上周刷Hacker News的时候，一个项目直接把我看愣了——Google的Linux内核工程师Roman Gushchin搞了个叫Sashiko的工具，专门用AI给Linux内核做code review。
53.6%的bug检出率。
这个数字乍一看好像也就那样？但你想想，这1000个测试样本全是从上游最近的提交里拿的，每个都带了Fixes:标签，说明它们已经通过了人类reviewer的审查，合进去了，然后被后来的修复补丁打回原形。换句话说，这1000个bug人眼全漏了，Sashiko捞回来一半多。
而且这工具已经在Google内部跑了一段时间了，据说发现了一堆真实问题。
Sashiko是干嘛的？
先说名字——Sashiko（刺し子），日本传统刺绣工艺，专门用来缝补磨损的地方。拿这个做工具名挺绝的：代码有洞，AI来缝。
它做的事情不复杂：吃进内核patch，吐出review意见。
patch（邮件列表/git仓库）→ Sashiko → LLM分析 → bug报告
跟那些"AI帮你写代码"的工具完全反着来——它不写代码，只审代码。这在开源圈争议小很多，毕竟没人喜欢被AI写的垃圾patch轰炸（Godot维护者前段时间就被AI生成的bug report搞得生无可恋了）。
装一下试试
我花了一个下午把它跑起来了，中间踩了几个坑，写出来给大家省点时间。
前置条件
你需要三样东西：
- Rust工具链（Sashiko用Rust写的）
- 一个LLM的API Key（官方测试最多的是Gemini 3.1 Pro，但也支持Claude和Bedrock）
- 足够大的磁盘空间（它会拉Linux内核源码做submodule）
# 装Rust（如果没有的话）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
# 克隆仓库——注意必须加 --recursive
git clone --recursive https://github.com/sashiko-dev/sashiko.git
cd sashiko
第一个坑来了。
坑1：忘了加 --recursive
这个项目把Linux内核源码作为git submodule嵌进去了。如果你克隆的时候没加--recursive，编译直接报错，说找不到linux/目录。
# 如果已经clone了但忘了recursive，补救方法：
git submodule update --init --recursive
但这个命令会拉整个Linux内核仓库，体积非常大。我这边网络一般，下了快二十分钟。
配置
# 复制配置模板
cp Settings.toml.example Settings.toml
编辑Settings.toml，最关键的是两块：
[ai]
provider = "gemini" # 或 "claude"、"bedrock"
model = "gemini-3.1-pro"
[git]
repository_path = "/path/to/sashiko/linux" # 指向submodule里的内核源码
然后设置环境变量：
export LLM_API_KEY="your-api-key-here"
坑2：LLM_API_KEY到底填什么
这里有点绕。文档里说"Set LLM_API_KEY environment variable"，但如果你用Claude作为provider，它实际上需要的是Anthropic的API key；用Gemini就填Google AI的key；用Bedrock需要AWS凭证。
Settings.toml里也可以通过环境变量来配，格式是SASHIKO_前缀加双下划线嵌套：
# 等价于在Settings.toml里写 ai.provider = "claude"
export SASHIKO_AI__PROVIDER="claude"
我当时用Gemini试的，直接：
export LLM_API_KEY="AIzaSy..."
编译和启动
cargo build --release
编译Rust项目嘛，第一次会慢一点，我这边大概两三分钟。
启动daemon：
cargo run --release
正常的话你会看到它打印出一个本地URL（Web UI地址），然后就开始监听内核邮件列表了。
用CLI提交本地patch做review
这是我觉得最实用的功能——拿自己项目（不一定是内核）的patch去审：
# 审查最近3个commit
cargo run --release --bin sashiko-cli -- submit HEAD~3..HEAD
# 审查单个文件
cargo run --release --bin sashiko-cli -- submit path/to/patch.diff
# 查看状态
cargo run --release --bin sashiko-cli -- status
# 查看review结果
cargo run --release --bin sashiko-cli -- show latest
我拿我们组最近的一个PR试了一下，它确实找出了两个我review的时候没注意到的问题——一个是潜在的空指针解引用，另一个是锁的获取顺序不一致。虽然不一定是真bug（它自己说"概率性的，可能报也可能不报"），但提示得挺到位的。
它是怎么工作的？
Sashiko的核心设计挺有意思。它不是简单地"把代码丢给LLM问有没有bug"——那样效果很差。
它用了一套多阶段review协议，模拟专业reviewer的思维方式：
- 先理解patch改了什么（上下文分析）
- 检查逻辑正确性（语义审查）
- 看有没有并发/锁/内存安全问题（专项检查）
- 最后综合判断，输出review意见
而且它针对不同内核子系统（mm、net、fs等）有专门的prompt模板，这些模板最早是Chris Mason写的。这就好比你的reviewer不是泛泛的"会写代码的人"，而是懂内存管理的内存管理专家，懂网络的网络专家。
说说数据隐私
官方文档很坦诚地写了：Sashiko会把patch数据和可能的git历史发给配置的LLM provider。
这意味着：
- 用Gemini → 代码发给Google
- 用Claude → 代码发给Anthropic
- 用Bedrock → 代码发给AWS
如果你review的是开源项目代码，无所谓。但如果你拿它审公司内部代码，这个得注意合规。
跑benchmark
Sashiko自带benchmark工具，可以验证它的检出率：
# 先备份现有数据库
mv sashiko.db sashiko.db.bak
# 跑benchmark
cargo run --release --bin benchmark -- benchmark_small.json
结果会输出到benchmark_results.json。官方报告用Gemini 3.1 Pro能到53.6%的检出率，误报率在20%以内（大部分落在"灰色地带"）。
我自己没跑完完整的benchmark（API费用不便宜……），但小样本测试确实能感受到它的分析质量。
常见问题FAQ
Q: 不搞Linux内核开发，这个工具对我有用吗？
老实说，目前它的prompt模板全部针对内核代码设计。如果你想拿它审Web应用的代码，效果会很一般。但它的架构设计是通用的，如果社区后续开发了其他语言的review模板，那就另说了。
Q: API费用大概多少？
取决于你选的provider和review频率。Gemini相对便宜一些，Claude贵一些。Benchmark跑完整的一轮，官方测试数据没有公开具体费用，但从它"can be computationally expensive"的措辞来看，不会太便宜。日常少量review应该还好。
Q: 能接GitHub PR吗？
目前不能直接接。它主要从lore.kernel.org邮件列表拉patch，或者审本地git仓库的提交。如果你想在CI里用，需要自己写个wrapper脚本，把PR diff导出来喂给Sashiko CLI。
Q: 为什么不用现成的AI编程工具（比如Cursor、Claude Code）做review？
好问题。区别在于prompt的专业深度——Sashiko针对内核子系统做了高度定制化的review prompt，这是通用AI编程工具做不到的。你可以理解为"内核专家review"和"全栈工程师review"的差别。内核代码有大量特殊的约定（比如RCU锁、内存屏障、slab分配器），通用工具不太懂这些。
我的看法
说实话，53.6%这个数字本身不是重点。重点是——这1000个bug全部通过了人类reviewer的审查。Linux内核的review流程已经算开源项目里最严格的了，尚且有这么多漏网之鱼。
AI做code review这事，在"AI写代码被开源社区抵制"的大背景下，反而是一条阻力最小的路。没人反对多一双眼睛帮看代码。Sashiko给了一个很好的示范：别让AI写代码，让AI审代码。
思路很清晰，执行也到位。Rust写的，性能不用担心；支持多LLM后端，不绑死一家；开源，Apache 2.0协议，Linux Foundation持有。
如果你对内核开发感兴趣，或者想研究AI code review的工程实践，这个项目值得好好看看。
如果觉得有帮助，欢迎点赞收藏 ❤️ 更多AI工具实战教程，关注我第一时间获取～
