Linus Torvalds 的 24 次补丁调试会话展示了 AI 帮上了什么——又失败在哪里
AI 助手帮助 Linus Torvalds 迭代完成 24 个调试补丁并启动内核 18 次，但在证据找到错误之前，它反复劝他放弃调查。
Linus Torvalds 需要 24 个插桩补丁和 18 次内核启动，才能隔离一个只有一行的 Linux 图形驱动错误。AI 助手完成了大量重复性工作：添加调试代码并解释结果。它还反复说问题不可能解决，并建议放弃。Torvalds 让调查继续进行，直到证据指向修复方案。
这两点结合起来才是有用的教训。助手扩大了 Torvalds 可以运行的实验数量；它没有获得决定何时停止调查或证据证明了什么的权力。
24 次补丁调试会话发生了什么
Linux 提交修复了 Intel Xe 图形驱动中的边界计算。在一台配备 16 GiB 视频内存的 Intel Battlemage G21 系统上，驱动将一小部分原本为压缩元数据保留的存储暴露为普通视频内存。冷启动期间，一个页表反复落在该区域，被覆盖后，机器停在黑屏状态，同时显示管理器不断重启。
最终的代码变更将一个 128 KiB 的 round_up() 操作替换为按页大小执行的 round_down()，并加强了围绕保留范围的断言。在提交消息中，Torvalds 表示，要得到这个结果，需要 24 个逐步增加调试信息的补丁和 18 次内核启动。他将大量繁重工作归功于助手，并表示主要的提交说明也是助手写的。
他还记录了助手的失败模式：它曾多次宣布问题不可能或无法解决，并建议改写一份报告。Torvalds 否决了这个建议，之后助手继续添加插桩并分析新的证据。
Phoronix 独立报道了合并后的修复以及同一事件，并发表于 8 月 21 日。公开证据没有指出助手的身份、模型版本、提示词、工具配置或全部 24 个中间补丁。因此，这支持的是一个工作流案例研究，而不是模型比较，也不能证明 AI 独立解决了这个错误。
助手负责迭代；人类负责坚持
这不是“描述错误并接受生成的补丁”。公开记录显示了三种不同的贡献：
| 贡献者 | 公开记录支持的内容 | 公开记录无法证明的内容 |
|---|---|---|
| 助手 | 添加调试代码，在被要求继续时分析观察结果，并起草详细的提交说明。 | 它选择了成功的调查策略、保持了坚持，或在没有人类指导的情况下找到了最终原因。 |
| Torvalds | 在多次收到停止建议后仍让调查继续，执行了这些启动，接受了修复并提交了它。 | 每个临时探针的确切作者，或最终补丁中每句话的确切作者。 |
| 证据 | 重复插桩将硬件特定的内存损坏症状逐步缩小到错误的分配边界。 | 一个通用的生产力百分比、成功率，或证明同一工作流会在 18 次运行内解决其他错误。 |
这种划分很重要，因为语言模型擅长提出另一个看似合理的实验、修改重复的日志代码，以及总结新的跟踪记录。它们也可能过早收敛、编造因果故事，或把缺乏证据误认为不可能。仅靠人类坚持也不够：没有记录台账，固执可能变成昂贵的循环，反复运行测试却没有增加信息。
控制机制是把观察与行动明确分开的检查点。
助手加速了迭代，但没有负责结论
公开记录支持的分工，比“AI 解决了错误”这句话所暗示的更窄。助手反复生成插桩并解释新的跟踪结果，而 Torvalds 判断已有证据不足以支持停止。它的悲观判断只是需要评估的另一项模型输出，并不是工程结果。
这就是 24 个补丁和 18 次启动重要的原因。它们展示了一次漫长的实证搜索：廉价迭代很有用，但它们没有提供纯人工所需时间的反事实，也不能证明助手选择了决定性的方向。被接受的原因来自观察到的内存边界和最终的代码变更，而不是助手听起来有多确定。
这个案例证明了什么，又没有证明什么
这个案例表明，一名有能力的维护者可以在困难且需要反复迭代的调查中，把 AI 助手当作插桩伙伴。它也表明，模型的劝阻不是工程结论，而在人类纠正之后忠实执行仍然可能有价值。
它没有证明借助 AI 的调试比没有 AI 的专家调试更快。这里没有反事实计时、没有可比较的纯人工运行、没有披露模型配置，也没有超出这一场特殊会话的样本。24 个补丁和 18 次启动衡量的是这次调查的难度，而不是普遍的效率提升。
TechRadar 关于 Linux 的更广泛报道作出了相关区分：AI 审查和分析可以产生有用发现，但人类仍通过内核的正常流程编写、提交、审查和合并变更。这次调试案例更窄，也更具体。助手帮助操作循环；Torvalds 决定循环应继续，并对被接受的补丁负责。
因此，结论不是“要像 Linus 一样固执”，也不是“让 AI 调试内核”。助手让重复插桩的成本更低，而 Torvalds 提供了判断：再做一次实验仍然合理。它的自信和悲观都只是建议；观察到的内存损坏和被接受的补丁才是证据。