# AI 时代的精神病：当 MTTR 狂热撞上系统韧性


<!-- more -->

我有一种强烈的直觉：现在的科技行业里，有些公司正在经历一场深度 AI 精神病（AI psychosis），而且在那些公司里，你根本没办法进行理性对话。我说的不是陌生人——是我深深尊重的个人朋友。这让我很担心事情会怎么收场。

这恐惧有具体的来源。我亲历过基础设施从传统运维向云和云自动化转型时，MTBF（平均故障间隔时间）和 MTTR（平均恢复时间）之间那场大辩论。现在那些一模一样的论点换了个壳重新冒了出来，只是范围从基础设施扩大到了——整个软件开发行业，甚至可能扩展到整个世界。

## 从基础设施到软件开发：同一堂课，更大的赌桌

云计算转型的核心争论之一是：应该优先追求 MTBF（系统多久不出故障）还是 MTTR（出了故障多久能修好）。

传统运维文化强调 MTBF——通过严格的变更审批、冗余设计、完善的测试来防止故障发生。云原生文化则倾向于 MTTR——接受故障不可避免，把精力放在快速检测和快速恢复上。Netflix 的 Chaos Monkey 就是 MTTR 哲学的极端实践：主动注入故障，证明你的恢复能力够强。

这个争论最终达成了一个微妙的平衡：MTTR 确实是衡量运维成熟度的好指标，但你不能因此放弃对 MTBF 的关注。Charity Majors（Honeycomb CEO）多次强调过这一点——快速恢复是好事，但如果你的系统每五分钟就崩一次然后五秒修好，你的用户仍然在受苦。

DORA（DevOps Research and Assessment）团队在 Google 赞助下做了十年以上的研究，他们的 2025 年报告得出了一个关键结论：AI 扮演的是放大器的角色，但最大的回报来自于底层的社会技术系统（sociotechnical systems）的完善。工具不能替代系统性的工程实践。

现在，这场争论从基础设施领域蔓延到了整个软件开发领域。AI 编程工具的拥护者们几乎一致采取了极端的 MTTR 立场：「出 bug 没关系，因为 agent 能以人类无法企及的速度和规模来修复它们！」

## MTTR 狂热：表面健康的灾难机器

这种「修得快就行」的心态有一个致命盲区。

在基础设施领域我们学到的关键教训是：你可以把自己自动化成一台极具韧性的灾难机器。系统可以通过所有局部健康检查，同时在全局层面变得完全不可理解。这不是理论推演——这是 AWS、Google Cloud、Azure 都曾用惨痛的事后分析报告验证过的现实。

Richard Cook，知名的安全工程研究者，在 [How Complex Systems Fail](https://how.complexsystems.fail/) 中写了一系列精炼的观察。其中有几条和当前的 AI 编程狂热形成了令人不安的对应：

- **灾难需要多个小故障的巧合，单点故障不够。** 每个小故障单独看都无害，只有它们的组合才足以引发灾难。这意味着有大量未被察觉的故障轨迹比真正的事故多得多。
- **复杂系统永远运行在降级模式下。** 系统从来不是完全健康的，只是故障还没积累到临界点。
- **事后分析对决策过程的重建几乎不可能准确。** 人们会无意识地调整叙述，使过去的决策看起来合理。

把这些观察搬到 AI 辅助编程的场景里：

AI agent 生成的代码每次引入一个微小的不一致——一个边界条件遗漏、一个不恰当的抽象、一个和既有架构不兼容的设计选择——每个单独看都可以被快速修复。但它们在系统深处叠加积累，而没有人拥有全局视图来发现这条故障轨迹。

## 四个绿色指标背后的红色警报

和行业里朋友的对话让我格外不安。当我试图提出这些担忧时，得到的回应几乎是一套标准化的反驳话术：

**「测试覆盖率是 100%」**

测试覆盖率是一个被广泛误解的指标。Martin Fowler 在 [Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html) 一文中指出，软件系统天然倾向于积累 cruft（内部质量的退化），而技术债务的利息体现在「添加新功能所需的额外努力」上。AI 工具可以让覆盖率数字飙升，但如果测试本身是 AI 生成的、只验证了代码的行为而不是业务意图的正确性，那你得到的是一套精确验证了错误行为的测试套件。

Stack Overflow 2025 年开发者调查的数据佐证了这个担忧：**46% 的开发者不信任 AI 工具输出的准确性**，只有 3% 表示「高度信任」。更有意思的是，经验越丰富的开发者越不信任——资深开发者的「高度不信任」比例达到 20%，是所有群体中最高的。

**「Bug 报告数量在下降」**

Bug 报告数量下降可以说明两件完全相反的事：代码质量提升了，或者用户放弃了报告。更可能的现实是第三种——AI 生成代码引入的 bug 类型变了。它们不再是明显的崩溃或界面错误，而是更深层的架构腐化：性能退化、数据一致性风险、安全边界模糊。这些 bug 不会出现在 issue tracker 里，因为它们需要理解系统全局才能被发现。

**「我们的 agent 修复 bug 的速度比人类快 10 倍」**

这正是 MTTR 狂热的核心论点。但修复速度的提升有一个前提假设：修复不会引入新的问题。在 AI 辅助的开发流程中，每个修复本身也是 AI 生成的代码，也可能引入新的隐性缺陷。这形成了一个正反馈循环：bug 越多 → 修复越多 → 新的隐性 bug 越多 → 更多修复。

**「我们的代码变更量是去年的 3 倍」**

变更速度的提升可能是最危险的健康指标。Richard Cook 的观察再次适用：变化发生得如此之快，以至于没有人注意到底层架构在腐烂。当系统的变更速度超过了任何个人理解这些变更的能力时，系统的可理解性就不可逆地下降了。

{{< image src="/pictures/note/ai-mttr-mtbf-metrics-illusion.svg" alt="指标幻觉：Bug 数量下降、测试覆盖率上升、变更速度提升，但系统全局风险在积累" caption="局部指标全部绿灯时，没有人注意到架构在腐烂" >}}

## Ward Cunningham 的债务比喻在 AI 时代有了新含义

技术债务这个概念是 Ward Cunningham 在 1992 年的 OOPSLA 会议上提出的。他用金融债务做比喻：如果你写了不够干净的代码，之后每次在上面添加新功能时都要多付出的额外时间，就是这笔债务的利息。

Martin Fowler 后来扩展了这个概念，将技术债务分为四个象限：谨慎且有意（Prudent & Deliberate）、谨慎且无意（Prudent & Inadvertent）、鲁莽且有意（Reckless & Deliberate）、鲁莽且无意（Reckless & Inadvertent）。

AI 辅助编程正在大量制造一种新型债务——我称之为「不可审计的债务」（Unauditable Debt）。传统技术债务至少有一个优点：它是人类写的，另一个人类可以通过阅读代码来理解当时的决策逻辑。AI 生成的代码没有这个属性。当代码的作者不是任何一个有上下文的人类时，代码的「为什么」就丢失了。

DORA 2025 年的研究用更精确的语言描述了这个问题：AI 作为放大器，如果你底层的工程实践是好的，它会让你更好；如果你的工程实践有缺陷，它会放大那些缺陷。这不是线性放大——在一个复杂系统里，缺陷的放大是非线性的。

## 为什么这场对话如此困难

这可能是最让我沮丧的部分。提出这些担忧时，面对的往往是有理有据的反驳——更接近条件反射式的否认。

我能理解为什么。如果一个人或一个公司在 AI 编程工具上投入了大量时间、金钱和叙事（narrative），承认这些工具可能正在系统性地引入隐性风险，就等于承认这些投入可能是在错误的方向上。这在心理上很难接受。

而且 AI 工具确实带来了真实的效率提升。Stack Overflow 2025 调查显示 84% 的开发者已经在使用 AI 工具，其中 69% 的 AI agent 用户认为 agent 提高了他们的生产力。我自己也写过 [Coding Agent 使用指南]({{< ref "posts/2026-05-16-pi-coding-agent-complete-guide.md" >}})，深知这些工具在日常开发中的价值。这些数字是真的。问题是它们描述的是局部效率，不是全局健康。

这就像一个城市里每辆车都开得更快了（局部效率提升），但交通事故率也在上升，同时路网的整体吞吐量在下降（全局效率恶化）。每辆车的司机都觉得自己在受益——因为他们能感知到自己的速度——但没有人能感知到路网级别的拥堵。

## 反的不是 AI，是放弃工程纪律

让我明确立场：我不是在反对 AI 编程工具。我自己每天都在用它们。比如在之前的 [AI 编程实践]({{< ref "posts/2026-05-17-ui-first-ai-programming.md" >}})中，我探索过用 UI 原型倒推 PRD 的方法来减少需求偏差，这本质上也是一种用结构化流程对抗 AI 编程中"随意性"的尝试。

我自己每天都在用 AI 编程工具。比如在之前的 [AI 编程实践]({{< ref "posts/2026-05-17-ui-first-ai-programming.md" >}})中，我探索过用 UI 原型倒推 PRD 的方法来减少需求偏差，这本质上也是一种用结构化流程对抗 AI 编程中"随意性"的尝试。

但有一类用法让我很不安：把 AI 当成可以跳过工程纪律的通行证。具体来说——

- 用 AI 生成的测试覆盖率来替代对代码正确性的深度审查
- 用 bug 修复速度来替代对 bug 根因的系统性分析
- 用代码变更量来替代对系统架构演化的有意识设计
- 用 AI agent 的产出效率来替代对产出质量的评估

从基础设施工程的经验看，健康的做法是同时关注 MTBF 和 MTTR：

- **MTBF 层面**：投入精力理解你的系统架构、建立深度防御（defense in depth）、保持代码的可审计性、确保每个变更都有人类可以解释的「为什么」
- **MTTR 层面**：使用 AI 工具加速故障发现和修复、自动化重复性工作、扩大个体工程师的产出范围

两个都要做。只做后者然后假装前者不重要，迟早出事。

## 一个更诚实的对话框架

如果你也在为类似的问题困扰——身边的朋友或同事陷入了 AI 狂热，你不知道怎么开口——我试过最有效的方式是跳过具体技术指标，直接问一个更根本的问题：

**你的系统里有没有任何人能够完整地解释它为什么能正常工作？**

如果答案是「没有，但它有测试和监控」，那问题就已经存在了。测试验证的是系统曾经正确过的行为，监控反映的是系统当前的行为。但理解系统为什么能正常工作——以及在什么条件下它会停止正常工作——需要的是人的心智模型（mental model），这个模型是无法被测试或监控替代的。

Richard Cook 说的好：「复杂系统的运行总是接近其性能边界。系统在正常运行时并不安全——它只是还没有遇到触发灾难的事件组合。」

走得快不是问题。问题是走得快到没人理解系统为什么还能跑——等到跑不动的那天，也没人知道该修哪里。