Theo 谈 Linus Torvalds、AI 审查与开源维护者

我先用反讽的方式假装 Linux 和 Linus Torvalds 必然反对 AI。他最近在邮件列表中的回应恰恰相反：内核项目并不一概反对 AI。我想讨论这种立场对维护者、代码审查和整个软件开发行业意味着什么。

直接背景是 Sashiko：一个用于审查 Linux 内核补丁的开源 agent 系统。它可以读取邮件列表或本地 Git 中的补丁，也支持多个模型提供方。项目报告了针对近期带修复标记的上游提交进行的特定测试结果。

在报告的测试中，Sashiko 使用 Gemini 3.1 Pro 找到了所选集合中 53.6% 的错误。作者表示误报更难量化，相关估计依赖有限的人工审查。这些数字只描述该项评估，不能证明 AI 审查在所有代码上都优于人类。

作者还指出模型输出具有概率性：同一输入在不同运行中可能产生不同发现。这个限定很重要。我认为额外的审查者和测试能帮助维护者评估补丁，但模型的回答不能直接当作最终判决。

当我主张用 AI 审查代码和构建验证工具时，并不是说合并前不应该有人读补丁。对许多项目来说，人工审查仍是好主意。机会在于围绕改动增加检查，包括不一定要合入仓库的临时测试。

Theo 讨论了一篇采访内核维护者 Greg Kroah-Hartman 的报道。Greg 表示，在此前出现一波明显低质量的内容后，AI 辅助安全报告的质量有所改善。这是该维护者所述的经历，并不能证明所有生成报告如今都可靠。

我的猜测是，更好的模型接触到更多开发者，随后人们逐渐学会围绕它们构建工作流。这只是推测，并非 Greg 所观察变化的已证实原因。实际关键在于报告是否给维护者提供可复现的证据，而不是又一条自信却未经验证的断言。

即便报告发现了真实问题，数量本身也会产生工作。大型、分布式的内核团队比小型开源项目有更多处理能力。快速自动反馈可以帮助提交者在人工审查前修改补丁，但维护者仍需花时间分拣并验证结果。

我提到大量 Linux CVE 记录，借此说明安全工作的规模，并认为防守方和攻击方都可能使用自动化工具。CVE 记录数量不等于新发现漏洞数量，也不等于正在被利用的漏洞数量，不能仅凭它推断这两者。

邮件列表上的分歧从 Sashiko 开始，后来扩展为对大语言模型的总体反对。Torvalds 回应说 Linux 并非反 AI 项目，不认同的人可以选择其他项目或自行 fork。Theo 赞同他根据工具实际价值来判断的立场。

Torvalds 也承认 AI 的经济问题，以及它可能给维护者带来的痛苦，包括源源不断暴露令人尴尬的错误。他提出的方向是让工具帮助维护者，而不是加重负担。这并不等于要求每个贡献者都使用 AI。

我认为模型提供商本应更早帮助开源维护者，尤其考虑到开源代码对整个生态的重要性。有用的支持可以是直接资助、提供工具、私下开展安全工作，以及在提交前认真核实贡献。

Torvalds 主张内核决策应着重技术价值，并表示个人可以选择是否使用 AI。另一位参与者 Laurent 从伦理角度提出反对。Theo 赞同 Torvalds，但这场分歧也表明，贡献者可能从不同的技术和伦理角度评价同一工具。

随着编程模型改进，我对它们的期待也发生了变化：从小幅编辑转向更大胆的任务。我预计更多开发者会找到有用的场景，但这是我的预测，并不能证明每位维护者都必须采用同样的工作流或得出相同结论。

我把这场分歧与早期围绕 TypeScript 的争论作比较。小团队中经验丰富的 JavaScript 开发者，未必像需要协调众多贡献者的大团队那样觉得它必要。不同工具解决不同问题，一类人的收益不意味着每个人都得到同样的提升。

Theo 将 TypeScript 描述为帮助大型团队发现跨代码库破坏性改动的方式，并提到 Anders Hejlsberg 与 Microsoft 的规模化需求。类型定义可能把工作转移给库维护者，但同时让其他人更容易使用这些库。

我回忆起与 SolidJS 创作者 Ryan Carniato 的讨论。他说自己使用 TypeScript 多年，仍未确信它提高了自己的生产力。他举例说，一个直观的 API 很快就能做出来，但为它编写合适的类型却很困难。我认为这是实际成本，不能忽视他的体验。

我的示意图认为，TypeScript 能提高许多开发者的下限，同时可能对部分顶尖工作形成约束。这是概念模型，并不是经过测量的分布。我用它解释自己为何受益，以及为什么另一位经验丰富的开发者也可能合理地持不同看法。

我认为 AI 也可能出现类似情况：内核专家在自己的领域可能比模型写得更好，而来自其他专业领域的优秀开发者可能从辅助中受益。这不意味着生成代码就是正确的，领域审查和验证仍然必要。

我提到 Torvalds 在自己通常的专业领域之外使用模型制作可视化，作为工具帮助人在陌生领域更快工作的例子。我自己使用 TypeScript、如今又使用 AI 的经历，也让我更愿意尝试超出既有习惯的工作。

除了提交生成代码，还有很多有用场景：审查开放的 pull request、构建针对性测试，或调查已有改动是否按预期工作。我仍然不是说人们应该停止阅读代码。我希望团队利用低成本生成的工作加强验证。

我对模型未来的进步持乐观态度，但没有人必须立刻采用每一种工具。可以在对自己有帮助的地方尝试，考虑给维护者增加的负担，并根据结果作判断，而不是假定生成内容越多就越好。