AI探案记：软件卡了两分钟，罪魁祸首竟是我家娃

本文系用户投稿，不代表机核网观点

本文含有AI生成，请注意甄别

前几天，我准备打开 Godot，继续做一个游戏 Demo。
Godot 是一款开源游戏引擎。可这一次，程序明明已经启动，窗口却迟迟没有反应。
起初我以为是工程太大。后来发现，即使不打开任何工程，只启动空白的项目管理器，它也会卡上一两分钟。
Windows 很诚实地送上四个字：未响应。
以往碰到这种没有明确报错的卡顿，我会先看日志，再从驱动、缓存、版本兼容和外设等常见方向逐项排查。麻烦不在于想不到可能性，而是每一种可能都要做对照、等结果，再一点点缩小范围。
这次我把问题直接扔给了 Codex：
Godot 进程开启之后卡住了，你检查一下。
就这样，这场 AI 探案开始了。
AI 的第一个判断，就错了
AI 先检查了正在运行的 Godot 进程。
卡住时，有一个 CPU 核心接近满载。但同一个工程用无窗口模式启动，只要一秒钟。
这至少说明，工程脚本和资源本身没有把 Godot 卡死，问题更可能出在窗口或显卡初始化阶段。
我的电脑是一台只有 900 克的超轻薄本，用的是 Intel 集成显卡。第一位嫌疑人顺理成章地出现了：
是不是电脑太弱，显卡驱动卡住了？
这个推断听起来很合理：轻薄本配集成显卡，带不动开发工具似乎也不奇怪。
可惜，猜错了。
后来有一次，Godot 启动足足等了 115 秒，CPU 真正干活的时间却只有 4 秒。
它不是算得慢，而是在等什么。可那个东西一直没有回应。
案情变了。
电脑里的嫌疑人越来越多
接下来，显卡、网络、系统证书、蓝牙、手柄和触摸屏轮流被拉来问话，甚至连平时毫无存在感的智能卡读卡器都没能幸免。
AI 一度发现，关闭部分手柄检测后，启动时间从八十多秒降到了四十多秒。这个变化让输入设备看起来非常可疑。
于是，AI 让我关掉蓝牙，断开鼠标和 Xbox 手柄。无效。
我又授权 AI 临时禁用触摸屏、热键设备和读卡器。为了避免修好 Godot 却把电脑修残，每次动手前，AI 都会先写好自动恢复脚本。无论测试成功、超时还是报错，设备都会重新启用，结束后再核对状态。
我一遍遍点击 UAC 的“是”，看着电脑里的硬件挨个接受审讯。
Godot 的启动时间没有任何改善。
等查到智能卡读卡器时，画风已经很像刑侦剧：主线迟迟没有突破，只好把路人也拉来挨个问话。
但每次判断错了，AI 都会留下测试结果，然后划掉刚才的假设。它不会因为前一个答案是自己给的，就硬着头皮证明它正确。
嫌疑名单越来越长，排查范围却在一点点收紧。
AI 开始往底层查
设备排查没有得到答案。AI 没有再围着设备继续试，而是顺着 --verbose 日志停下的位置，去 GitHub 翻 Godot 的源代码、Issue 和修复记录，分析卡顿前后会走到哪些代码。
它先找到一个与现象高度相似的 Windows 输入设备枚举问题，又逐段对照 Godot 4.7.1 的相关实现和修复记录，确认还有哪些设备可能触发等待。
每次卡顿结束后，日志紧接着出现的第一行，恰好与系统证书有关。于是它继续沿着源码追查，又写了一个最小测试，调用相同的 Windows 接口。证书读取只用了几毫秒，这条线索也被排除了。
源码能告诉它该查哪些方向，却仍然回答不了最具体的问题：Godot 此刻究竟在等什么？
继续切换设置已经没有意义。AI 决定趁 Godot 卡住时，直接检查进程内部正在发生什么。
电脑上没有安装专业调试器。它便调用 Windows 自带的系统组件，抓了一份只有几百 KB 的轻量转储，又临时写了一个小工具，分析主线程、寄存器和等待状态。
这套流程通常需要先准备调试器、抓取转储，再手动分析线程和调用栈。
结果显示，Godot 并没有忙着计算，也不是线程死锁。它的主线程正在等待 Windows 打开某个对象。
随后，AI 继续从转储数据里还原调用参数，最终解出了那条路径：
    
    
    
  NtOpenFile → Z:\
翻译成人话：Godot 卡住时，正在尝试打开 Z 盘。
看到这里，画风突然变了。
这跟 Godot 有什么关系？
AI 接着只读查询 Z 盘。连 Windows 自己访问它，也卡了 34 秒。为避免再次触发等待，AI 绕开磁盘访问，直接查映射记录。答案终于出现：
    
    
    
  Z: → 家里的 NAS
状态：正在重新连接
NAS 可以简单理解成家里的一台小型文件服务器。我的电脑把它映射成了 Z 盘，平时看起来和本地硬盘差不多。
原来，NAS 关机了。
Windows 还保留着这个映射。Godot 启动时访问了 Z 盘，等于去敲 NAS 的门。门后没人，Windows 又不肯立刻承认，只好让 Godot 站在门口等上几十秒，直到网络超时。
破案了。🕵️
问题原来不在电脑里
可 NAS 为什么会关机？
我过去一看，终于补上了 AI 看不到的最后一块拼图。
Nintendo Switch 是任天堂的一款游戏主机，既能拿在手里玩，也能插进底座连接电视。我家娃取放主机时，不小心碰掉了旁边 NAS 的电源。
就这样，一只小手在现实里偏了几厘米，影响顺着 NAS、网络映射和 Windows 磁盘访问一路传下去，最终让另一个房间里的 Godot 卡了快两分钟。
我本来只是想让 Godot 快点启动，没想到 AI 从一个“未响应”的窗口查起，先后排查显卡、证书和一屋子的硬件，最后钻进 Windows 的进程转储，拎出了一个 Z 盘。
最后的解决办法却简单得离谱：
把 NAS 电源插回去。 🔌
科技发展到今天，重新插好电源依然是最有效的运维手段之一。
回头看，AI 并没有一开始就知道答案。
它先怀疑显卡，中途也走过几条弯路。不同的是，它没有停在“可能是驱动，建议重装”这种听起来永远不会错、实际上也没什么用的答案上。
我只说了一句“你检查一下”，它就一直留在现场：读取状态、做对照测试、推翻自己的判断；现成工具不够，就临时搭一个，再把一个模糊的“软件卡住了”追成具体的 Z: 盘。
追到这里，它停下了。
AI 不知道 Z 盘旁边放着一台 Switch，更不知道当天有个小朋友在那里取放主机。另一边，我也不用亲自逐行分析那份进程转储，更不用从 Windows 的系统调用里徒手找盘符。
AI 把线索追到 Z 盘，我知道 Z 盘通向家里的哪个角落。两边的信息一接上，整条因果链就闭合了。
案子结束后，AI 把临时改过的设置和设备全部恢复，又清理了诊断文件。Godot 恢复正常，NAS 也重新亮了起来。
至于我家娃？不予追责。真
正需要整改的，是那根一碰就掉的 NAS 电源线。😅
老林Roc | 游戏创作 × AI进化
我正在用20年开发经验，去验证AI到底是不是“人工智障”。
关注我，如果我做成了，你也能行；如果我搞砸了，你就当看个乐子。