夜雨聆风从昨天晚上到今天上午，我的 Codex 一直处于崩溃状态，只要启动就会进入卡顿状态，无奈卸载或者删除长对话似乎都没有效果。
不是那种“慢一点”的卡，而是打开后像被什么东西按住了喉咙：窗口还在，进程还在，日志也在刷，但交互迟迟回不来。最讽刺的是，我原本想让 AI 帮我做事，结果第一件事变成了：先救 AI。
我一开始的时候没有先重装，也没有上来就删缓存。
一开始是找另一个AI 排查，AI 的问题就交给AI 去解决，我用的是claude code。
claude 告诉我codex 相关进程一共有 17 个，合计工作集大约 3.6GB；node 相关进程 24 个，合计约 1.36GB。
也就是说，这不是一个单窗口假死，而是一整套桌面端、插件、REPL、Node 服务开始拥堵起来。
随后继续查 CLI 路径：系统里的 codex 默认指向 WindowsApps 里的桌面应用资源路径，而本机还有一个可直接调用的二进制文件：
C:/Users/Zero/AppData/Local/OpenAI/Codex/bin/fb2111b91430cb17/codex.exe
直接跑版本号能返回 codex-cli 0.137.0-alpha.4。
第二步查工作区。当前目录不是干净的代码仓库，而是一个混合素材工程：62,069 个文件，总量约 9.15GB，其中图片 4,400 个，视频和音频 136 个，还有压缩包、临时下载、生成结果、网页项目。
Codex 如果把这种目录当成上下文入口，就很容易在文件枚举、索引、工具准备阶段被拖住。
第三步查本地状态。logs_2.sqlite 加上 WAL 文件约 343MB，活跃会话和归档会话也都不小。再跑 keep-codex-fast 技能，结果显示它已经安装并且和远端一致；按规则先做只读报告，千万别随便删东西。
之前一次大还原基本上是浪费了几亿的token。
效果算不上“满血复活”，更像“勉强救回来”：Codex 可以继续响应，卡顿原因也从玄学变成了清单。
进程重、插件多、日志大、素材目录过深、入口路径混乱，这些因素叠在一起，就足以让一个聪明工具变得笨拙。
但这件小事让我想到头部 AI 工作室最近反复提到的“AI 危机”。
很多讨论默认有一个终点：完全自主的 AI 会一路进化，最后摆脱人类，形成近乎神明的系统。
今天的故障反而给了我一个相反的直觉：完全自主的 AI 不一定真的成立，因为它的进化路线、工具链、记忆方式、恢复机制，很可能仍然深深继承了人类工作流里的缺陷。
我们会堆文件，AI 也会被上下文淹没。
我们会把工具链接得太复杂，AI 也会在插件、日志、会话和权限之间互相牵制。
我们会在系统变慢时先拍脑袋重启，AI 也可能在自我修复时选择错误入口、扩大错误范围，甚至把“修复”变成新的负担。
AI有很多基石来源于碳基后天的认知，于是这种基石极有可能让AI 在未来的自进化中毁灭。
这不代表风险变小。恰恰相反，如果最强大的 AI 不是完美理性的神，而是一个继承了人类缺陷、又拥有巨大执行能力的系统，那么它的自我崩解可能更危险。
一个普通工具崩了，只是无响应；一个连接生产环境、金融、舆论、代码仓库和自动化系统的 AI 崩了，可能会把错误扩散成连锁反应。
它不需要“有恶意”，只需要在错误的自信里继续执行。
所以真正的安全感，不来自“让 AI 完全自主”，而来自让 AI 可观察、可中断、可回滚、可被另一个系统交叉检查。
今天用另一个 AI 工具救 Codex，本质上就是一次小型演练：当一个智能系统失灵时，必须有旁路、有日志、有人工闸门，有能把它从神坛拉回工程现场的办法。
AI 的危机也许不是它终于变得不像人，而是它在最强大的时候，仍然太像人。
