AI 精神错乱：为什么快速恢复无法取代系统韧性

在最近一次具有启发性的观察中，Mitchell Hashimoto 警告说，一种他称之为“AI 精神错乱”的现象正在渗透到整个公司。这种心态的特征是对 AI agent 的非理性过度依赖，以维护软件系统，从而导致了基本工程原则的危险侵蚀。

其核心在于，这不仅仅是一场关于工具采用的辩论，而是一场关于我们如何确保运行现代世界的软件可靠性的根本分歧。随着公司竞相将 AI 集成到开发生命周期的每一个阶段，它们面临着重复云基础设施早期阶段代价高昂错误风险。

MTBF 与 MTTR 的权衡

为了说明当前的危险，Hashimoto 将其与向云自动化转型期间 Mean Time Between Failures (MTBF) 与 Mean Time To Recovery (MTTR) 之间的历史紧张关系进行了类比。

MTBF 关注韧性——构建从一开始就不会失败的系统。MTTR 关注恢复——构建在发生故障后可以快速恢复的系统。虽然云时代教会了我们快速恢复至关重要，但它也揭示了一个关键事实：你不能为了恢复而完全放弃韧性。

Hashimoto 认为，行业现在正将一种扭曲的“仅限 MTTR”心态应用于整个软件开发过程。其推行的逻辑是，发布带有 bug 的代码是可接受的，因为 AI agent 可以以远超人类能力的效率和规模来识别并修复它们。然而，这种方法忽略了当焦点从预防故障转向应对故障时所积累的系统性风险。

健康的幻象

这种“精神错乱”最阴险的方面之一是，它通常隐藏在表面上看起来积极的指标背后。Hashimoto 指出，系统在整体衰退的同时，可能在以下几个方面看起来很健康：

• 测试覆盖率： 一个项目可能显示 100% 的测试覆盖率，但如果 AI 既编写代码又编写测试，那么系统的语义理解就会下降。测试可能会通过，但它们可能在测试错误的东西，或者在镜像代码中存在的相同幻觉。
• Bug 报告： Bug 报告数量的减少通常被视为成功的标志。然而，这可能是一个滞后指标；潜在的风险可能正在表面之下爆发，等待特定的条件触发灾难性的故障。
• 架构衰退： 当变更以 AI 加速的速度发生时，底层架构可能会在不经意间衰退。系统变成了一台“灾难机器”——高度自动化，但对于负责监督它的工程师来说，在根本上是无法理解的。

“囚犯在管理疯人院”

围绕 Hashimoto 的警告进行的社区讨论突显了对 AI 生成“闭环”日益增长的担忧。正如一些观察者所指出的，当 AI 被用于流程的每一个步骤时，危险性会增加：编写初始代码、生成测试、以及进行代码审查。

"It would make sense to use AI for writing code, but human code review. Or, human code, but AI test cases... once it gets used for everything, people have lost the plot, it's the inmates running the asylum."

当人类从验证环节中被移除时，系统就失去了与现实的联系。防止系统性崩溃的交叉检查机制被一个反映 AI 自身偏见和错误的镜像所取代。

经济与文化压力

为什么会发生这种情况？有人认为，这不仅仅是技术压力，更是财务压力。随着大量风险投资流入 AI 商业化，公司感到有一种生存性的需求，必须完全转向 AI 驱动的工作流。在这种环境下，对于那些与融资船紧密相连的人来说，接受失败的可能性不是一个选项，这导致了一种近乎妄想的强迫性乐观。

结论：对形式化验证的需求

虽然有些人认为这只是另一种企业跟风或“货物崇拜”现象，最终会将会自我修正，但其中的利害关系比以往任何时候都要高。AI 部署的速度意味着“学习经验”可能会是灾难性的。

未来的道路可能需要回归严谨。随着生成式 AI 的狂热消退，行业可能会发现自己渴望进入一个新的软件工程时代——在这个时代，AI 的输出不再被盲目信任，而是基于精妙的架构和严格的标准进行形式化验证。在此之前，工程师的挑战是在一个过度关注恢复的自动化时代，就韧性保持理性的对话。