AI精神病是真实存在的——MitchellH的警告，每个开发者都应该读一读

"我强烈认为，有些公司现在全员处于严重的AI精神病状态，你根本没办法跟它们进行理性对话。"

这不是某个路人的推特暴论。说这话的是 Mitchell Hashimoto——Vagrant、Packer、Terraform的创造者，HashiCorp联合创始人——一个拥有二十年基础设施工程经验的人。

他的帖子在Hacker News上冲到了658分，24小时内获得了25.4万+的展示量。之所以引发如此强烈的共鸣，是因为这件事以前发生过。

我们早就学过的MTBF vs MTTR教训

Mitchell直接拿云基础设施迁移做类比：

"我亲身经历过云迁移时代的MTBF vs MTTR大辩论。现在这些争论换了一张皮又回来了。"

MTBF（平均故障间隔时间）——构建几乎不会出错的系统。 MTTR（平均恢复时间）——构建出错了能快速恢复的系统。

在云迁移的过程中，整个行业猛扑向MTTR。"系统出点问题没关系——我们能用自动化快速修复。"这个逻辑一度很管用——直到它不再管用。很多公司把自己自动化成了一个局部指标健全、全局理解崩溃的系统。

今天的AI版本犯了一模一样的错误

今天的"AI精神病"采取了同样的形式：

"出点bug没关系，因为AI Agent修复速度极快，而且规模是人类无法企及的！"

这听起来耳熟吗？就是把MTTR心态套用在了代码质量上。Mitchell试图提出担忧时，听到的回应是：

• ❌ "不，测试覆盖很全面"
• ❌ "Bug报告在下降"
• ❌ "我们的交付速度从未这么高过"

这些都是用局部指标掩盖全局衰退的典型信号。

真正会发生什么

Mitchell的警告值得全文引用：

"我们在基础设施领域已经学过这一课：你可以用自动化把自己变成一个弹性极好的灾难机器。系统在局部指标上看起来完全健康，但全局正在变得不可理解。Bug报告可以下降，但潜在风险在爆炸性增长。测试覆盖率可以上升，但语义理解在下降。变化发生得太快，没人注意到底层的架构正在腐烂。"

这就是AI在软件开发中的真正危险。不是AI写出烂代码——而是AI让你更快地写出烂代码，而速度掩盖了腐烂。

如何在使用AI的同时保持工程纪律

答案不是"别用AI"。答案是用你对待任何工程工具同样的纪律来使用AI。

✅ 应该这样做

1. 把AI生成的代码当作初级开发者的初稿来审 GitHub Copilot和Cursor是不可思议的加速器。但把它们的输出当作初稿，不是成品。每一行都需要人工审查。

2. 保持语义理解 用Claude或ChatGPT来解释代码为什么这样工作，而不仅仅是生成代码。如果你不能解释架构，你就没有真正理解它——这就是腐烂开始的方式。

3. 保持监控和可观测性 AI Agent捕获不到的问题，让Sentry和SonarCloud来捕捉。别让"Bug报告在下降"骗了你——确保你在衡量正确的指标。

4. 让AI做它擅长的事

• 样板代码 → ✅ AI
• 测试生成 → ✅ AI（需要审阅）
• 架构决策 → ❌ 人类
• 生产环境调试 → ❌ 人类（辅以AI）

❌ 别这样做

• 未经审阅就直接发布AI生成的代码
• 让AI Agent自动修复生产环境的bug
• 仅用交付速度来衡量成功
• 认为测试覆盖率=代码质量

总结

MitchellH的警告不是反AI。它是支持工程纪律。我们在基础设施领域学到的教训同样适用于AI辅助开发：

没有理解的速度不是进步。只是加速腐烂。

最终，那些能赢的公司不会是AI用得最猛的公司。而是那些用得最负责任的公司——带着和AI时代之前同样严格的纪律、审阅和架构思维。

---

浏览我们精选的 AI开发工具合集——从代码助手到监控和测试工具。