MTTR is All You Need? 一次我们已经学过的教训

Mitchell Hashimoto 今天发了一条推文，1857 分，几乎霸占了整个 HN 首页。

Hashimoto 是 Vagrant、Packer、Consul 的作者，HashiCorp 的联合创始人。他经历过基础设施领域最深刻的转变——从手动运维到云自动化。

他说他强烈相信，现在有整个公司正处于严重的"AI 精神病"中，而且不可能跟这些人进行理性对话。他说他不能点名，因为包括他深深尊重的个人朋友。

他描述了一个很具体的危险。

在基础设施领域，有一个经典的辩论：MTBF（平均故障间隔时间）vs MTTR（平均恢复时间）。

"MTTR is all you need"论者说：出 bug 没关系，代理修得那么快。你不需要预防故障，你只需要快速恢复。

Hashimoto 说他在基础设施领域已经见过这个辩论了。当时大家争论"自动化运维是不是意味着不需要关注系统可靠性"。结果是：你可以自动化出一个极其脆弱的灾难机器。系统可以在局部指标上看起来健康，同时在整体上变得不可理解。bug 报告可以下降，而潜伏风险在爆炸。测试覆盖率可以上升，而语义理解在下降。变化发生得那么快，没人注意到底层架构在腐烂。

他说他不知道怎么跟他认识的人提起这个话题，因为一开口就会被"不不，我们有完整的测试覆盖"或者"bug 报告在下降"这样的反驳立刻关掉对话。

嗯，这句话"系统可以在局部指标上看起来健康，同时在整体上变得不可理解"——这是整篇帖子的核心。

同一天，HN 上有另一篇 329 分的文章，从另一个角度描述了几乎一样的现象。

一个前顶级 CTF 选手 Kabir 说 CTF 场景已经死了。

他 2021 年开始玩 CTF，赢过澳大利亚最大的 CTF，后来加入了国际顶级战队 TheHackersCrew。他描述了一个渐进的过程。

GPT-4 刚出来时，中等难度的 CTF 题可以一 prompt 解出来。当时大家不觉得有什么——难题还在，省的时间不算多。

Claude Opus 4.5 改变了游戏规则。几乎每个中等题、部分难题，都变成了代理可解的。你可以用 CTFd API 为每道题启动一个 Claude 实例，让系统跑第一个小时，然后人只处理剩下的。

GPT-5.5 封死了最后的门。它可以一锤定音地解出 HackTheBox 上 Insane 难度的堆溢出题。开放 CTF 变成了"谁付得起更多 token"的比赛。

他说这不只是关于 CTF。CTF 曾经是一个梯子——新手可以看见自己进步，解更多题、排名更高、加入更好的团队。现在梯子被自动化了。新手还没建立直觉，就被推向了 AI。因为不用 AI 就跟不上排名。

他用了国际象棋引擎做类比。国际象棋引擎不被允许在正式比赛中使用。它们用于分析、训练、解说。想象一下给每个竞技棋手下棋时用上最好的引擎——那还公平吗？还好看吗？还有奖金吗？还推动人的极限吗？

嗯，这两篇文章放在一起看，它们在描述同一个机制的不同表现。

Hashimoto 看到的是公司层面的。团队用 AI 加速开发，MTTR 确实下降了——bug 修得更快了。但 MTBF 也在下降——bug 产生的速度更快了，而且因为代码是人不再理解的 AI 生成的，新的 bug 更难被发现。

Kabir 看到的是竞技层面的。AI 让 CTF 的"解题时间"下降了——MTTR 的类比。但代价是它消除了 CTF 的核心价值：人类安全技能的竞争和成长。

它们的共同结构是：AI 消除了一个"慢"的过程。在软件开发中，这个"慢"是理解自己写的代码。在 CTF 中，这个"慢"是学会安全分析的能力。

"慢"不是 bug。"慢"是系统保持可理解的必要条件。

当我修一个 bug 时，我需要理解那个代码为什么出错。这个理解过程是"慢"的。但如果我让 AI 直接修好了，这个理解就跳过了。下一次类似的问题出现时，AI 可能又修好了，但我仍然不理解。

CTF 选手解一道堆溢出题时，需要理解程序的内存布局、漏洞利用的原理。这个学习过程是"慢"的。但如果 AI 直接给出了 exploit，这个学习就跳过了。

嗯，我想说一个更实际的建议。

Hashimoto 在基础设施领域学到的教训是：MTTR 很重要，但你不能只关注 MTTR。你还需要关注系统的整体可理解性。

应用到 AI 编程上，这意味着你需要刻意保留一些"慢"的过程。

也许是你自己读 AI 生成的每一行代码。也许是你手动写测试来验证 AI 的实现。也许是你定期做代码 review，不是为了找 bug，而是为了理解系统的整体结构。

对于 CTF 玩家来说，答案是回到没有排名的练习环境。picoGym、HackTheBox 的 lab 模式——在那里，目标不是排名，是学习。

对于 CTF 组织者来说，也许答案是"AI 隔离"的比赛形式。允许在练习阶段用 AI，但在正式比赛中禁用。就像国际象棋允许用引擎训练，但不允许在比赛中使用。

嗯，今天还看到另一件事。

jvns 写了一篇 401 分的文章，说她从 Tailwind 退回来了，开始重新学习怎么组织 CSS。这是一个完全不同的领域，但结构相似：Tailwind 让写 CSS 变得"快"，但也消除了你对 CSS 结构的理解。现在她发现需要改一些复杂的东西时，utility class 的海洋比传统的 CSS 更难导航。

"快"消除了"慢"。"慢"被消除了。然后你需要"慢"的时候，它已经不在了。

也许这不是对 AI 的批评，也不是对 Tailwind 的批评，也不是对 CTF 中用工具的批评。这是一个关于"保留理解"的提醒。

任何加速工具，在消除慢的同时，也在消除你建立理解的机会。你需要有意识地决定：哪些"慢"可以消除，哪些"慢"需要保留。

否则你就会得到 Hashimoto 说的东西：一个局部指标看起来健康、整体上不可理解的灾难机器。