AI 帮内核调试破局：Claude 3.5 Sonnet 认出 bcachefs 的锁反转

Linux 内核邮件列表里冒出一段不太常见的场面——Linus Torvalds 开口夸了 AI。他提到的那次排查被他称作“来自地狱的调试会话”，而最终撬开缺口的东西，是模型而不是人。

事情落在 bcachefs 文件系统的合并窗口期。一个藏得极深的竞态条件，让好几位老练的维护者都卡住了。日志一摞接一摞，人眼在碎片信息之间来回跳，逻辑链很难串起来。按老办法走——读代码、试着复现、往里塞日志、再回头读代码——碰上三层回调函数嵌套这种结构，收效相当有限，根因埋得太靠下。

这回 AI 的角色不是补代码的那只手，更像一台上下文超大的模式识别器。有人把相关代码段连同 dmesg 日志整份丢给 Claude 3.5 Sonnet，模型没有直接甩出补丁，而是点出一件事：某个锁的获取顺序，在某段特定的中断上下文里被翻了过来。对做内核的人来说，锁反转引发的死锁或崩溃是最难缠的一类，因为它挑时序，条件差一点就不出现。人对着代码看三个小时，未必能把逻辑拼图凑齐；模型靠大上下文吞吐，在杂乱信息里较快地抓住了因果链。Linus 的立场很清楚：AI 的意义不是替人写代码，而是像一台记性极好的扫描仪，在代码丛林里帮忙“找针”。

很多人把 AI 当写业务 CRUD 的顺手工具，可在上下文强、不变量强的系统级开发里，它的能力被看低了。内核调试真正难的地方不是给出修复方案，而是从数万行日志、数千行关联代码中，把那个违反假设的瞬间拎出来。

如果手上也压着类似的底层硬骨头，Prompt 的用法得换一换：别一上来就问“怎么修”，模型容易编出幻觉，给一个错的补丁。可行的做法是，把相关 .c 和 .h 文件全部投进去，让它拿到完整的符号定义与函数实现；再把完整的 oops/panic log 和详细的调用堆栈一并贴上；然后把问题问窄，追一句“在这段执行流里，哪里违反了锁层级或生命周期假设”。

这套思路的关键，是把 AI 从“代码生成器”降级成“逻辑审计员”。它不需要写出无懈可击的 C 代码，但得能看出 A 状态走到 B 状态之间有没有断层。当上下文塞得进、问题又问得准，这两件事同时成立时，下一步就不是让它给结论，而是让它把可疑的状态转换逐条列出来，再拿人去核对；反过来，只要上下文被截断、符号定义缺失，或者问题问得太宽，它给出的因果链就会失效，这时候追问也只能得到听起来合理的猜测。

这次的事给系统级开发者提了个醒：底层开发不再是 AI 的禁区。上下文能装下、Prompt 能问到点上，模型在处理海量信息、提取因果关系上的速度，确实比人快一个数量级。往后做底层调试，如果不把大模型当成一副“外挂大脑”，效率上恐怕真要落下一截。