Linus Torvalds 谈 AI：不会让程序员失业，但别指望它替你写内核

在 Open Source Summit North America 2025 上，Linus Torvalds 与 Dirk Hohndel 的对谈把一个老问题又翻了出来——AI 会不会让程序员失业？Linus 的回答既不是硅谷式的狂热，也不是悲观主义者的哀嚎，而是一种更接地气的判断：AI 是工具，不是替代品，尤其在内核开发这种对正确性有极端要求的领域。

内核发布流程：20 年来首次中断

对话中提到一个容易被忽略但意义重大的细节：Linux 内核自 2002 年转向 Git 之后的发布流程，整整 20 年几乎没出过岔子。直到最近，这个流程才出现了首次中断。

这听起来只是运维层面的小事，但它折射出一个事实——内核开发对流程稳定性的依赖程度极高。每周一个 rc，两周一个合并窗口，节奏像钟表一样精确。任何"智能自动化"想插手这个流程，必须先证明自己不会打破这套已经运转了 20 年的齿轮。

下面是内核开发者日常使用的 Git 提交与补丁流程，这套流程本身就是"人主导、工具辅助"的典范：

# 1. 从主线拉取最新代码
git fetch origin
git checkout origin/master

# 2. 基于当前主线创建特性分支
git checkout -b my-feature-branch

# 3. 修改代码后，按内核规范提交
#    --signoff 是必须的，表示你声明该补丁的版权合规
git add drivers/staging/my_driver.c
git commit --signoff -m "staging: my_driver: fix NULL pointer dereference in probe"

# 4. 生成符合内核提交规范的纯文本补丁
git format-patch -1 --cover-letter --subject-prefix="PATCH v2"

# 5. 用 checkpatch.pl 检查补丁是否符合内核编码规范
scripts/checkpatch.pl 0001-*.patch

# 6. 通过邮件列表提交（内核不接受 GitHub PR）
git send-email --to=linux-kernel@vger.kernel.org \
               --cc=maintainer@kernel.org \
               0001-*.patch

注意第 5 步的 checkpatch.pl——这是内核社区自己写的静态检查脚本，跑了几十年，远比任何 AI 代码审查更可靠。AI 可以辅助你理解 checkpatch 的报错，但最终决定补丁能不能进主线的是人，不是模型。

Linus 对 AI 的真实态度

Linus 用了一个很精确的词来形容自己："love-hate"。他不是反 AI，但也不觉得 AI 能解决内核开发的核心难题。

原因很具体：

• 内核代码的正确性要求极高。一个 NULL pointer dereference 可能导致整个系统崩溃，这种 bug 不是靠"AI 写得更快"就能避免的，反而速度越快，出错概率越高。
• AI 生成的代码缺乏可追溯的责任链。内核社区要求每个补丁有明确的 --signoff，有人对这段代码负责。AI 不能签 off，也不能在邮件列表上回应 review。
• AI 更适合做辅助而非替代。比如帮你读懂一段陌生的子系统代码、解释 checkpatch 报错、生成 commit message 的初稿——这些是"体力活"，AI 干得不错。但架构决策和边界条件判断，目前还是人的领地。

Linus 的核心观点可以浓缩成一句话：AI 不会让程序员失业，但会让只会写模板代码的程序员变得不那么重要。 真正有价值的开发者，是那些能判断"这段代码该不该存在"的人。

安全披露的边界问题

对话还触及了另一个争议话题：安全漏洞披露的边界。内核社区长期面临一个矛盾——提前公开漏洞细节可以帮助修复，但也可能被攻击者利用；延迟公开则可能让已知的漏洞在野外被利用更久。

Linus 的立场一贯偏向透明：补丁本身就是公开的，试图通过保密来"保护"用户往往适得其反。但他也承认，在某些涉及关键基础设施的场景下，给下游厂商一个短暂的预披露窗口是合理的。

这个问题和 AI 有间接关联——AI 可以更快地分析补丁推断出漏洞模式，这意味着"补丁公开即漏洞公开"的时间差正在缩短。防御方需要更快的响应速度，而这恰恰是 AI 可以发挥正面作用的地方。

实践：用 AI 辅助内核补丁审查

既然 Linus 认为 AI 适合做辅助工作，下面给出一个可运行的示例——用本地 LLM（通过 Ollama）自动解读 checkpatch.pl 的输出，帮你快速理解补丁问题所在：

# 先安装 Ollama 并拉取一个代码理解能力较好的模型
ollama pull codellama:7b

# 运行 checkpatch 并将输出保存
scripts/checkpatch.pl 0001-staging-my_driver-fix-NULL-deref.patch > checkpatch_output.txt

# 将 checkpatch 输出喂给本地 LLM，让它逐条解释
ollama run codellama:7b "你是一位 Linux 内核开发者。请逐条解释以下 checkpatch.pl 报错，并给出修复建议：

$(cat checkpatch_output.txt)"

如果你更习惯 Python，可以写一个更结构化的脚本：

#!/usr/bin/env python3
"""用本地 LLM 辅助解读内核 checkpatch 报错"""

import subprocess
import sys

PATCH_FILE = sys.argv[1] if len(sys.argv) > 1 else "0001-*.patch"

# 1. 运行 checkpatch
result = subprocess.run(
    ["scripts/checkpatch.pl", PATCH_FILE],
    capture_output=True, text=True
)
checkpatch_output = result.stdout + result.stderr

if not checkpatch_output.strip():
    print("✅ checkpatch 没有报错，补丁格式合规。")
    sys.exit(0)

# 2. 调用 Ollama API 解读报错
import requests

prompt = f"""你是 Linux 内核补丁审查助手。以下是 checkpatch.pl 的输出：
{checkpatch_output}

请：
1. 逐条列出每个 WARNING/ERROR
2. 解释每条报错的含义
3. 给出具体的修复代码建议
"""

response = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "codellama:7b",
        "prompt": prompt,
        "stream": False
    }
)

print(response.json().get("response", "LLM 调用失败，请检查 Ollama 是否运行"))

# 运行方式
python3 ai_checkpatch_reviewer.py 0001-staging-my_driver-fix-NULL-deref.patch

关键提醒：LLM 的解读只是参考，最终你必须自己确认每条修复是否正确。AI 在这里扮演的是"快速翻译器"——把 checkpatch 的晦涩输出翻译成你能快速理解的建议，而不是替你做决定。

采纳建议与风险清单

如果你正在考虑在开发流程中引入 AI，以下是几条来自内核社区实践（以及 Linus 态度）的启发：

风险边界：

1. 责任归属——AI 生成的代码没有 signoff，在要求版权声明的项目中是法律风险。
2. 幻觉问题——LLM 可能"修复"一个根本不存在的 bug，或引入新的边界条件错误。在内核中，这种错误的代价是系统崩溃。
3. 流程惯性——内核的 Git + 邮件列表流程跑了 20 年，任何自动化改动都需要证明它不会破坏这套已经验证过的机制。先在小范围试验，再逐步推广。

Linus 的态度本质上是一种工程理性：不因为恐惧而拒绝，也不因为 hype 而盲从。AI 是锤子，不是建筑师。程序员的价值从来不在"写代码的速度"，而在"判断代码该不该写、该怎么写"——这部分，AI 目前还帮不上忙。