Linus Torvalds 很少亲自提交 Linux 图形驱动补丁，因此这次 Intel Xe 内核图形驱动提交格外引人注意。更值得关注的是 commit message：他把这次经历称为“一次地狱级的调试”，并明确表示 AI 帮他完成了大量粗活，提供了很大帮助，同时也让他多次接近放弃。
这段话的价值不在于证明“AI 已经会调试 Linux 内核”，而在于展示了一种更现实的协作模式：AI 可以持续处理搜索、整理、改写、尝试和对比，但真正决定问题是否解决的人，仍然需要理解代码、硬件行为和验证结果。
为什么内核图形问题特别难排查
内核图形驱动的问题往往同时跨越多个边界：用户空间图形栈、内核子系统、设备固件、GPU 硬件状态，以及电源管理和并发执行。一个表面上的“画面卡死”，可能对应完全不同的根因：
- 命令提交顺序不符合硬件要求；
- 中断或 fence 没有按预期触发；
- 电源状态切换改变了寄存器或设备上下文；
- 错误恢复路径没有正确重置设备；
- 补丁修复了一个竞态，却让另一个时序问题更容易出现。
这类问题很难通过单次代码阅读解决。调试者需要在大量日志、调用路径、补丁版本和测试结果之间建立联系。AI 在这里最适合做的是降低信息处理成本，而不是替代工程判断。
AI 能承担哪些“粗活”
可以把 AI 的作用拆成四类，而不是笼统地说“让 AI 调试”：
- 快速定位上下文：从较大的代码库中整理函数调用关系、相关结构体和错误路径。
- 批量生成候选修改：根据明确约束提出小范围补丁，帮助调试者快速验证假设。
- 整理实验结果：比较不同内核版本、启动参数和日志之间的差异。
- 保持排查节奏：当问题需要反复编译、启动、复现和回滚时，AI 可以持续处理机械性工作。
但这些工作都有一个前提：每一次候选修改都必须经过编译、测试和人工审查。AI 生成的补丁看起来合理，并不意味着它遵守了锁语义、内存屏障、硬件协议或内核社区的编码约束。
一个可复用的 AI 辅助调试流程
下面是一个面向内核回归问题的简化流程。它不是 Intel Xe 问题的复现脚本，而是一种可以改造到具体项目中的实践模板。假设你已经有一个能触发问题的测试命令，并希望比较基线版本与候选补丁。
先保存环境信息和关键日志：
#!/usr/bin/env bash
set -euo pipefail
OUT="debug-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"
uname -a > "$OUT/uname.txt"
git rev-parse HEAD > "$OUT/commit.txt"
lspci -nnk > "$OUT/lspci.txt"
dmesg --color=never > "$OUT/dmesg-before.txt"
# 按项目实际情况替换为最小复现命令
./run-reproducer.sh 2>&1 | tee "$OUT/reproducer.log"
dmesg --color=never > "$OUT/dmesg-after.txt"
diff -u "$OUT/dmesg-before.txt" "$OUT/dmesg-after.txt" > "$OUT/dmesg.diff" || true
echo "Collected logs in $OUT"
然后把上下文以结构化方式交给 AI。提示词可以这样写：
你是 Linux 内核代码审查助手。请只基于下面提供的代码、日志和实验结果分析问题。
目标：解释复现失败时最可能的状态转换，并提出最多 3 个最小候选修改。
约束：
- 不要假设未提供的硬件行为；
- 明确区分“日志直接证明的事实”和“待验证的推测”；
- 每个候选修改都说明可能影响的锁、并发、错误恢复和电源管理路径；
- 不要把重构、格式化或无关清理混入补丁；
- 给出一个可以证伪该假设的最小实验。
输入：
1. 内核提交：<commit-id>
2. 相关函数：<function-list>
3. 复现步骤：<commands>
4. 正常日志：<known-good-log>
5. 异常日志：<failure-log>
6. 已尝试补丁：<diff>
这个流程的关键不是提示词本身，而是要求 AI 逐项区分事实、推测和验证方式。对于内核调试，能否提出可证伪的假设，比能否生成一大段解释更重要。
小补丁比“大重写”更适合验证
当问题涉及复杂驱动时，第一轮 AI 输出很容易扩大修改范围。例如，它可能建议重新组织错误处理、抽象公共函数，或者同时调整多个状态变量。这些建议未必错误，但会让实验失去清晰的因果关系。
更稳妥的做法是把每轮实验限制在一个可解释变化内：
git switch -c debug/xe-repro
git apply candidate.patch
make -j"$(nproc)" LLVM=1 bzImage modules
# 根据测试环境替换安装和启动步骤
sudo make modules_install
sudo reboot
# 重启后再次运行最小复现，并保存日志
./run-reproducer.sh 2>&1 | tee /tmp/xe-repro.log
如果候选补丁改变了结果，还需要继续问三个问题：
- 它是否真正修复了根因，还是只改变了问题出现的时机？
- 它是否让某条错误路径不再触发，但留下资源泄漏或状态残留？
- 它是否只在当前硬件、当前固件或当前启动参数下有效？
可以用 git bisect、重复运行、不同电源状态和不同负载来扩大验证范围。AI 可以帮助整理这些实验矩阵，但实验设计和结果解释仍然需要工程师负责。
“不知疲倦”不等于“不会迷路”
AI 的优势是不会因为连续几个小时没有进展而停止生成候选方案。对于需要反复阅读日志、检查相似代码和尝试小补丁的问题，这种持续性非常有价值。
但它也有明显边界。AI 可能会：
- 把相关性误判为因果关系；
- 忽略硬件文档中没有出现在代码里的约束；
- 生成能够编译、却不满足并发语义的修改；
- 在错误方向上不断追加复杂度；
- 用看似完整的解释掩盖缺少实验依据这一事实。
因此，AI 最适合被安排在“调查员、记录员和补丁草稿员”的位置。工程师则需要掌握方向盘：定义问题、缩小变量、审查假设、决定实验，并对最终提交负责。
给内核开发者的采用建议
如果准备把 AI 引入低层系统调试，可以从以下边界开始：
- 先提供最小复现和经过筛选的日志，不要把整个代码库无差别地交给模型；
- 要求输出事实、推测、证据和下一步实验，而不是只要结论；
- 每轮只验证一个主要假设；
- 保留原始日志、内核提交号、编译选项和硬件环境；
- 对涉及锁、引用计数、DMA、内存屏障和设备状态机的修改进行人工审查；
- 把 AI 生成的补丁视为实验材料，不能视为已经完成的修复。
Linus 的这次经历传递出的信号很实际：AI 不需要完全理解整个 Linux 内核，才能在真实调试中产生价值。只要它能可靠地承担大量搜索、整理和重复尝试，就可能显著降低排障成本。但越接近硬件和并发边界，人类对证据的判断就越不可替代。