LWN：LLM 用在 patch review 上！

关注了就能看到更多这么棒的文章哦～

Large language models for patch review

By Jonathan Corbet
October 16, 2025
Gemini flash translation
https://lwn.net/Articles/1041694/

在自由软件社区中，关于大型语言模型 (LLMs) 在软件开发中所扮演的角色，已经有过许多讨论。然而，这些讨论大多集中于项目是否应该接受这些模型输出的代码，以及在何种条件下接受。但这些系统参与开发过程的方式还有很多。Chris Mason 最近在内核峰会讨论邮件列表上 发起了一场讨论，探讨如何利用这些模型来评审补丁，而不是生成补丁。

Mason 的重点是 LLMs 如何通过在错误到达邮件列表之前将其捕获，并帮助贡献者提高提交内容的质量，从而减轻内核维护者的负担。为此，他整理了一组 提示词，这些提示词能够生成维护者所习惯的评审格式：“这些评审旨在看起来像 lkml 上的邮件，即使它们错得离谱，也确实达到了这个目的。”他附上了一长串示例评审，其中一些击中了要害，另一些则不然。

这些提示词本身就很有趣；它们可以被视为构成了一套全面的补丁评审文档，而这样的文档从未有人为人类用户编写过。这或许反映出人们对 LLM 确实会 阅读 所有这些材料抱有更高的信心。这些提示词加起来有数千行，从像以下这样的 核心指南 开始：

结构体变更 → 验证所有使用者是否正确使用了新结构体

公共API变更 → 验证文档更新 […]

语气要求:

• 对话式

  : 面向内核专家，而非初学者
  

• 事实性

  : 没有夸张，只有技术观察
  

• 提问式

  : 以对代码的提问形式呈现，而非指责
  

大多数提示词包含针对 锁机制（"你还不够聪明，无法理解 smp_mb()、smp_rmb() 或 smp_wmb() 错误"）和 网络（"Socket 的生命周期可能超出其文件描述符的生命周期"）等子系统的具体指导。总而言之，它类似于上世纪 80 年代 曾被认为将接管世界 的专家系统中的规则集合。正如 README 文件 中所指出，"目前的误报率相当高，约为 50%"，因此仍有改进空间。

在随后的讨论中，似乎没有人认为以这种方式使用 LLMs 是一个坏主意。Sasha Levin 称其为 "一个非常值得讨论的话题"，并表示，在 之前关于内核开发者使用 LLM 的讨论 中，对 LLM 提出的担忧盖过了任何寻找其潜在有用之处的尝试。Paul McKenney 评论说，使用这项技术评审他人编写的代码 "似乎比用它来生成实际代码要安全得多"。Krzysztof Kozlowski 指出，Qualcomm（高通）已创建了一个类似的系统并已投入使用。

人们对这些系统的专有性质提出了一些担忧；Konstantin Ryabitsev 只是少数几位将此事与 BitKeeper 经历 相提并论的人之一，那段经历在 20 多年前曾短暂地导致内核开发停滞。Laurent Pinchart 明确指出，专有工具的使用或强制要求是有限制的：

强制贡献者付费使用专有工具是不可接受的。甚至强制贡献者运行专有工具也是不可接受的。

他还表达了担忧，认为 LLM 背后的公司会免费向开发者提供这些工具以鼓励采纳——直到社区被深度锁定，届时访问可能会迅速变得昂贵。然而，Mason 对此并不担心，他说这些提示词足够通用，可以适应任何系统。James Bottomley 认为 LLM 不会永远是专有的，但 Pinchart 反驳道，不应寄希望于最终出现免费替代方案而依赖专有软件。

关于 LLM 评审工具应为谁创建，存在一些意见分歧。Mason 的目标是维护者，但 Andrew Lunn 认为 计划应该是开发者在提交代码评审之前自行运行这些工具。他表示，这将进一步减轻维护者的工作量，维护者只需运行 LLM 评审来验证提交者是否已完成此操作。

Pinchart 和其他人 指出，让开发者使用现在已有的工具（例如 `checkpatch.pl`）是很困难的；他想知道如何鼓励提交者运行任何新工具。Tim Bird 建议 在补丁上标注已运行过的工具列表，以便维护者可以看到这些历史记录。Bottomley 则 表示，这些工具应该像 0day 机器人 现在对已提交补丁进行的检查一样，对发送到邮件列表的补丁自动运行。然而，Bird 说，应该期望提交者运行这些工具。"这样成本就由贡献者而非上游社区承担，这会更好地扩展。"

Mason 明确表示，他相信 LLM 生成的评审应作为提交过程的一部分公开进行：

我认为记住人工智能有时会错得离谱也很重要。让评审出现在邮件列表上，资深开发者可以指出其中的谬误，这肯定有助于避免浪费人们的时间。

Linus Torvalds 在 他对讨论的唯一贡献 中也表示赞同。他是少数几个对这项技术表达担忧的人之一，他说："我想我们都看到了人工智能的垃圾一面，以及它如何制造更多工作而非减少工作。"Mason 同意 Torvalds 的担忧是切合实际的，他根据自己的经验说道：

我最初的提示是让 AI 假设补丁存在 Bug，结果它总是凭空捏造 Bug。这并不是世界末日，但解释总是足够令人信服，以至于你会浪费大量时间去追查。

Torvalds 也提到了 抓取器问题。尽管有这些担忧，他仍然相信这项技术将证明是有益的，但他认为其初步采纳必须旨在让维护者的生活更轻松。"所以，我认为只有当任何人工智能工具真正在日常工作中帮助维护者时，人们才应该 考虑 让非维护者使用它们。"

讨论在此之后不久结束。然而，一个明确的结论是，这些工具注定会在内核开发过程中扮演越来越重要的角色。在某个时候，我们很可能会开始看到机器生成的评审出现在邮件列表上；届时，基于 LLM 的补丁评审工具的真正价值或许就会开始显现。我们将拭目以待，看看今年 12 月 2025 年维护者峰会 上不可避免的相关讨论将如何发展。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～