# Linus 说它"真能找到 bug"：1348 star 的 sashiko 把内核补丁审查拆成 7 个并发阶段，还规定"驳回必须附代码证据"

Linux 内核的补丁审查一直是人力瓶颈。一个补丁从邮件列表发出，到进入 mainline，中间要过维护者的眼睛、CI、以及无数轮 review。问题在于：**人看不过来**。

Linus Torvalds 在 LKML 上对 sashiko 的评价是："最近有相当比例的报告变得非常有效……有些报告真的很出色，深入且微妙，AI 100% 正确。任何认为 AI 全是垃圾的人，都在否认现状。" Andrew Morton 说得更直接："第一条规则当然是'不要引入 bug'。这东西能找到 bug。如果命中率有 50%，就足以证明人们值得花时间去检查它的输出。"

这个项目就是 `sashiko-dev/sashiko`，Linux Foundation 旗下，Rust 写的，1,348 star，Apache-2.0。名字取自日本刺子绣（刺し子），一种用补丁加固磨损处的缝补工艺——"用自动化审查加固内核"。

它不是又一个"把 diff 丢给 GPT"的脚本。整个仓库 115,628 行 Rust，核心是把审查拆成一条有明确状态机、有并发扇出、有程序化校验的多阶段流水线。

## 三种用法，一套引擎

| 形态 | 入口 | 说明 |
|---|---|---|
| 本地审查 | `sashiko review HEAD~3..HEAD` | 在你的内核 checkout 里跑，用临时 scratch clone 应用补丁，不动工作树 |
| 守护进程 | `sashiko`（默认） | 通过 NNTP 订阅 `lore.kernel.org` 邮件列表，自动摄取、审查、回信 |
| 单补丁服务 | `sashiko-cli` + Web UI | 向运行中的 daemon 提交补丁、查状态 |

三种形态共用同一条 workflow。代码里 `src/workflows/` 下有两套：`linux_patch_review.rs`（审内核补丁）和 `sashiko_patch_review.rs`（审 sashiko 自己）。后者不是玩具——`--project sashiko` 可以让它审自己的 PR，仓库里 `projects/sashiko/prompts/` 就是给它自己用的提示词。

## 流水线：先扇出，再收敛

README 把阶段列得很清楚，我在源码 `src/workflows/linux_patch_review.rs:1739` 里核对了 `ANALYSIS_STAGES` 的定义，一一对应：

**分析阶段（并发跑）**

- `goal` — 架构缺陷、UAPI 破坏、概念正确性（必跑）
- `implementation` — 代码是否匹配 commit message、未记录的副作用、API 契约违反（必跑）
- `execution-flow` — 逻辑错误、漏检返回值、未处理的错误路径、off-by-one（必跑）
- `resources` — 内存泄漏、UAF、double free、队列/定时器/workqueue 上的对象生命周期
- `locking` — 并发问题、死锁、RCU 规则违反、线程安全
- `security` — 缓冲区溢出、OOB 读写、TOCTOU 竞态、未初始化内存泄漏
- `hardware` — 寄存器访问、DMA 映射、内存屏障、状态机约束

**收敛阶段（串行跑）**

1. `verification` — 合并各分析阶段的 concerns 和 dismissed_concerns，直接产出有依据的 findings 与 dismissals，把有争议/推测性的候选路由到 `hard_cases`
2. `post-verification` — 按 finding 并行拆成最多 10 个 `post-verification-1..10`，带仓库工具去证实或推翻 `hard_cases`
3. `report` — 格式化成 LKML 风格的行内注释回复

关键设计在"谁来跑哪些阶段"。`goal`、`implementation`、`execution-flow` 是 `optional: false`，永远跑；其余四个由 planning 阶段根据补丁内容挑选。planner 的输出会被程序化过滤：`apply_planning_stage_output()` 只接受能查到定义、且确实是 optional 的阶段名，幻觉出来的名字直接 `tracing::warn!` 丢掉。

`ANALYSIS_STAGES` 里每个阶段还声明了 `guides`——比如 `locking` 带 `subsystem/locking.md`，`execution-flow` 带 `callstack.md` + `technical-patterns.md`。这些 guide 是 71 个按子系统拆分的提示词文件（`third_party/prompts/kernel/subsystem/`），来自 Chris Mason 的 review-prompts 项目，定期同步进来。

## 我实跑的证据

光读 README 不算验证。以下都是本机跑出来的。

**编译**：`cargo build --bin sashiko`，rust-toolchain 锁定 1.90.0，dev profile 1m14s 通过，产出 `sashiko 0.6.2`。

**测试**：

```
cargo test  →  961 passed; 1 failed; 2 ignored
```

失败的是 `ai::backoff_provider::tests::deadline_budget_credit_wait_deduplicates_overlapping_sleeps`，断言两个 `Instant` 相差 1.4 微秒。单独重跑三次全部通过——这是并行负载下的时序 flaky，不是逻辑错误。我把它算进"未通过"，不粉饰。

```
cargo test --test integration_tests  →  23 passed
```

集成测试覆盖的是补丁系列合并的真实痛点：同一作者不同 series 不该合并、版本号不同的 series 该失败、cover letter 晚到要能并进已有 patchset、quilt 的 Message-Id 合并、loose patch 数量不一致的边界。

**本地审查**：我造了一个两 commit 的小仓库（`drivers/demo/demo_core.c`，第二个 commit 在 probe 的错误路径上漏了 `kfree(ctx)`），跑：

```
sashiko review HEAD --no-ai --format json
```

输出：

```json
{
  "baseline": "7230db689b2d8e9930b7ccf1183369cdd7a1a620^",
  "patches": [
    { "index": 1, "method": "current-tree", "status": "present",
      "subject": "demo: add read path for the demo driver" }
  ]
}
```

补丁提取、基线推导、应用校验这条链路是通的。

**完整流水线**：没有 API key，我写了一个假 OpenAI 兼容端点（返回预设 JSON），让 sashiko 对着它跑真实编排。这不是测模型能力，是测**编排本身**——阶段顺序、并发、校验、重试、早退。

跑通的一轮，9 次 LLM 调用，顺序完全可复现：

```
1  pre-screen        (无工具)
2  planning          (无工具)
3  goal              (带工具)
4  implementation    (带工具)
5  resources         (带工具)
6  locking           (带工具)
7  execution-flow    (带工具)
8  verification      (带工具)
9  report            (带工具)
```

注意第 1、2 步 `has_tools=false`。预筛和规划不碰仓库工具，只有拿到补丁内容之后的分析与收敛阶段才被授予 `git_read_files`、`git_grep`、`git_blame`、`git_show` 这些能力。工具面收窄在攻击面上是有意义的。

最终输出：

```
Findings:
  Critical: 0  High: 0  Medium: 1  Low: 0
  [Medium] demo_probe() leaks the kzalloc'ed demo_ctx when the buffer allocation fails

Inline Review:
commit 7230db689b2d8e9930b7ccf1183369cdd7a1a620
Author: Demo <demo@example.com>
...
```

**更有价值的是被拦下的四次。** 我的假响应一开始是错的，sashiko 的校验层每次都精确告诉我错在哪：

1. `missing field 'relevant_stages'` — planner 输出必须带阶段列表
2. `findings[0] must include a non-empty 'source_ids' array referencing input item ID(s) (C1, C2, C3, C4, C5)` — finding 必须指回它来自哪条上游 concern
3. `Verification output failed to account for input ID(s): C2, C3, C4, C5. Every input concern (C*) and dismissed_concern (D*) ID must appear in 'source_ids'` — 完备性约束
4. `The output is missing the 'commit <hash>' header` — 报告格式不符合 `inline-template.md`

每次失败都重试 3 轮，3 轮不过就整条 patch 判 `Incomplete` 并报错退出，不会把半成品当结果吐出来。

另外，当分析阶段没有提出任何 concern 时，引擎会早退：

```
Workflow 'linux_patch_review' early exit: No concerns or dismissed concerns raised in initial analysis stages
```

跳过 verification、post-verification、report 三个阶段。干净补丁不该为一次"没问题"付三次模型调用。

## 三个我认为值得抄的设计

### 1. 驳回必须附代码证据，且被程序校验

大部分 AI review 工具最大的问题是"嘴上说没问题"。sashiko 把这件事做成了硬约束。提示词里写着：

> NO DISMISSAL WITHOUT VERIFIED PROOF: To place a candidate issue in 'dismissed_concerns' ... you MUST find concrete proof in the code ('file', 'function_or_symbol', 'line', and verbatim 'code_snippet' in 'locations') that explicitly invalidates the concern's reasoning.

光写在提示词里没用。`linux_patch_review.rs:has_valid_proof_location()` 会检查每条 dismissal 的 `locations` 里是否真的有非空的 `file`、`function_or_symbol`、`code_snippet`；缺一个就报错：

```
dismissed_concerns[0] must include at least one entry in 'locations' with non-empty
'file', 'function_or_symbol', and verbatim disproving 'code_snippet' ... If you do not
have concrete code proof, move the candidate issue to 'concerns' instead.
```

提示词还专门堵了几类"看起来合理其实不成立"的驳回理由：拿单个调用方证明没有 NULL 解引用（必须遍历所有调用方，含 suspend/resume、sysfs、外部模块 `W=`/`M=` 路径）；说"编译器会拦住"所以类型/对齐不匹配不算 bug（编译失败本身就是 bug）；说"清掉状态位是无害 no-op"。

这是把 review 的方法论从"请模型注意"变成了"不满足就拒绝"。

### 2. 不许悄悄丢 concern

`source_ids` 那两次拦截暴露了一个更硬的约束：每条上游 concern（C1、C2……）和 dismissal（D1、D2……）都必须在最终输出的某处被引用。少一条就整体失败。

这个设计防的是"合并阶段偷偷把不想处理的意见扔掉"。多阶段 LLM 流水线里，信息在收敛时丢失是最难发现的一类失效——你只看到最终报告，看不到被吞掉的中间结论。sashiko 用 ID 台账把这件事变成了可校验的不变量。

### 3. 模板分段渲染，防补丁里的提示注入

`projects/sashiko/prompts/prompt-injection.md` 把这个威胁模型写得很直白：

> Sashiko reviews code it did not write, submitted by people it does not trust, and feeds that content to a model whose output then drives file reads and tool calls.

任何人只要能往公开邮件列表发帖，就能往补丁里塞任意文本——diff、文件名、commit message、邮件头、PR 描述、webhook 字段，全是攻击者可控的。而且**模型的输出也不可信**，因为它的输出会被拿去拼路径、拼命令。

实现上的关键在 `src/workflow/prompt.rs`。渲染结果被拆成两种段：

```rust
enum Segment {
    Template(String),
    Included(String),
}
```

`@include(...)` 指令只在 `Segment::Template` 里匹配。变量替换进来的内容进的是 `Included` 段，永远不会被重新扫描指令。所以一个 diff 里写着 `@include("/etc/passwd")`，它到模型面前就是一段普通文本，不可能变成一次文件读取。

配套的 `src/workflows/guard.rs` 再做一层：LLM 预筛阶段返回的 guide 文件名必须是不含 `/`、`\`、`..` 的纯文件名（`sanitize_guide_name`）；`read_prompt` 的路径必须是 `.md`、非绝对路径、无 `..`，且只允许一层 `subsystem/` 或 `patterns/` 子目录。注释写得很清楚："Since patches from untrusted sources can influence LLM selection"。

## 基准：它自己公开了 446 条漏报

README 的说法是：对着最近 1,000 个未过滤的、带 `Fixes:` 标签的上游 commit 做基准，sashiko（Gemini 4 Argon）检出了 **62.1%** 那些"曾经通过人工 review 并合入 mainline"的 bug；人工抽样估计误报率低于 **20%**，且多数是灰区问题。

仓库里确实有对应的数据集：`benchmarks/benchmark.json` 999 条，`benchmark_small.json` 99 条，`benchmark_tiny.json` 9 条，CI 用的 `benchmark_smoke.json` 3 条。

真正让我意外的是 `benchmarks/benchmark_missed.json`——**446 条**，描述是"公开上线后被 sashiko 漏掉、后来被上游修掉的 bug"。条目长这样：

```json
{
  "Commit": "712da38d134b6681946368dd5c9400b43eb772b0",
  "Fixed-by": "bcec7fc2e224088daf94448d663b02e0d0b9c717",
  "subsystem": "fs/9p",
  "problem_description": "Use-after-free of the 9p session structure during RCU
   pathwalk because v9fs_kill_super frees it without an RCU grace period while
   v9fs_vfs_get_link_dotl accesses it."
}
```

一个 AI 审查工具，把自己漏掉的 bug 逐条列出来当回归集。这比任何"准确率 XX%"的宣传都更有说服力——它把失败样本变成了可复现的测试用例。

`docs/benchmarking.md` 里还定义了 miss 诊断分类、precision/noise 指标、阶段归因（哪个阶段该发现却没发现）、以及去重后的 mean/p50/p90/max 资源分布。`--analyze-only` 可以只重打分不重跑审查。

## 诚实边界

必须说清楚我验证到哪一步：

- **审查质量本身没验证。** 我没有真实的 LLM API key，全链路跑的是假端点。所以"9 次调用、阶段顺序、并发、校验、早退"这些编排行为是真的；"它能不能真的找出 UAF"这件事，我无法用自己写的假响应证明。README 的 62.1% / <20% 是项目自报，我没独立复现（复现需要跑 999 条基准 × 每次 7~9 次模型调用，成本极高）。
- **daemon 模式没跑。** NNTP 摄取、邮件回信、Web UI、forge webhook 都需要真实网络与凭据，我只跑了本地 `review`。
- **一个 flaky 测试。** `cargo test` 全量并发时 1 个时序断言失败，隔离重跑 3/3 通过。不影响结论，但它是真实存在的。
- **成本提示是项目自己写的。** README 明确警告多阶段审查会产生显著 API 费用，并要求使用者确认有权把代码发给所选 provider。默认 planning 会给可选阶段做取舍，就是为了控制扇出。
- **默认配置很宽。** `sashiko init` 生成的 `~/.config/sashiko.toml` 默认 provider 是 gemini、model 是 `gemini-4-argon`、review concurrency 4。daemon 的 `Settings.toml` 扇出更大。自己部署时要按机器和预算调。

## 结语

sashiko 值得看的地方不在"用 LLM 审代码"这个想法——这个想法已经不新鲜了。它值得看的是**把审查当成一个有不变量的分布式系统来建**：

阶段有明确的必跑/可选划分，扇出有上限（post-verification 最多 10 路），合并阶段有 ID 台账保证不丢件，驳回必须有可校验的代码证据，报告格式有硬性模板，失败会整条判 incomplete 而不是降级输出。再加上对"补丁是敌意输入"的清醒认识——模板分段渲染、路径消毒、工具面收窄。

这些都不是模型能力问题，是工程问题。而内核社区愿意认真对待它，恰恰是因为这些工程约束让它**可被质疑**：每条结论都能追到出处，每次驳回都要给出代码，每个漏报都进了回归集。

1348 star 不算多，但 Linus 和 Andrew Morton 在邮件列表里认真讨论它——对一个才创建九个多月的项目来说，这比 star 数更有分量。

---

**仓库**：https://github.com/sashiko-dev/sashiko
**版本**：v0.6.2（commit `780530c`，2026-10-21）
**许可**：Apache-2.0，Copyright The Linux Foundation


Linux 内核的补丁审查一直是人力瓶颈。一个补丁从邮件列表发出，到进入 mainline，中间要过维护者的眼睛、CI、以及无数轮 review。问题在于：人看不过来。

Linus 说它“真能找到 bug”：1348 star 的 sashiko 把内核补丁审查拆成 7 个并发阶段，还规定“驳回必须附代码证据”

Linux 内核的补丁审查一直是人力瓶颈。一个补丁从邮件列表发出，到进入 mainline，中间要过维护者的眼睛、CI、以及无数轮 review。问题在于：人看不过来。 Linus Torvalds 在 LKML 上对 sashiko 的…

软件研发

前端

sashiko将Linux内核补丁审查拆分为7个并发阶段，以状态机驱动、程序化校验与ID台账约束，强制驳回附代码证据且防信息丢失。它基于Rust实现，获Linus与Andrew Morton认可，能有效检出补丁缺陷，并公开446条漏报作为回归集，工程严谨性远超简单AI脚本。

集成测试

代码解释

编译器

路由

GitHub

Kernel

Linux

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Linus 说它“真能找到 bug”：1348 star 的 sashiko 把内核补丁审查拆成 7 个并发阶段，还规定“驳回必须附代码证据”-腾讯云开发者社区-腾讯云

Linus 说它“真能找到 bug”：1348 star 的 sashiko 把内核补丁审查拆成 7 个并发阶段，还规定“驳回必须附代码证据”

Linus 说它“真能找到 bug”：1348 star 的 sashiko 把内核补丁审查拆成 7 个并发阶段，还规定“驳回必须附代码证据”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐