原文：https://www.oreilly.com/radar/if-youve-never-broken-it-you-dont-really-know-it/
学习新技术时，你可能会有一种虚假的自信。你看几个视频，浏览一些文档，让一个简单的示例运行起来，然后告诉自己：“耶，我搞定了。”我也曾这样做过。但这种自信从来都持续不了多久。真正有价值的经验往往伴随着艰难的教训。
失败是学习的艺术——跌倒在地，看着眼前的惨状，然后找出失败的原因。如果某件事感觉太容易？那很可能就是太容易了，你最终也没能从中学到任何有价值的东西。
询问失败：失败 === 经验
当我招聘声称拥有关系数据库专业知识的人时，我会问一个“陷阱”问题：
请告诉我你曾经设计过的最糟糕的数据库模式。它让你吸取了哪些教训，应该避免哪些错误？
这其实算不上什么技巧。任何深入研究过关系型数据库的人都知道，没有完美的模式。各种相互冲突的使用场景总是相互影响。你设计时考虑的是事务处理工作负载，但不可避免地，总会有人尝试用它来做报表，然后大家就纳闷为什么查询速度慢得像蜗牛爬。团队里的另一个开发人员（通常是几年之后）无意中为了报表用途优化了模式，结果却导致事务处理工作负载无法正常工作。
正确答案通常听起来是这样的：
我们最初是为事务吞吐量而构建的——公司的一位创始人甚至认为 MySQL 是一个数据库，这是我们的第一个错误。之后，公司将其用于报表用途。在几年时间里，这套系统几经易手。连接操作变得异常复杂，索引与访问模式不匹配，夜间作业开始干扰用户流量。我们不得不拆分只读副本，最终引入数据仓库，并在 5-6 年后，简化了事务并将其迁移到 Cassandra。
这样的人才能真正体会到其中的利弊权衡。他们经历过与数据库运维相关的漫长而又令人沮丧的失败。虽然他们可能不擅长解答那些在面试中越来越常见的愚蠢逻辑题，但这种经验对我来说更有分量。
差点让我崩溃的模式
我曾经发布过一个事务模式，从纸面上看似乎没问题：规范化、整齐，一切都井然有序。
然后分析工具出现了，只提供了“几个简单的仪表盘”。结果没过多久，我精心构建的 3NF 模型，如今已连接到美国每一间小学教室，却被当作一个百万行 Excel 表格来用来汇总会计报告。几个月来一切正常，直到后来出了问题，数据库因为 80% 的时间都花在了更新索引上而彻底崩溃。我根本无力修复，因为这意味着几天的停机时间，而且还要重写代码，而项目合同马上就要到期了。
我们当时是怎么尝试解决这个问题的呢？如果你也曾经历过这种情况，你就会明白，我接下来要写的，标志着你已经陷入了绝望的深渊。我们没有考虑用理性的方法来改进架构，或者将 2007 年就已经发展成“Web 规模”的工作负载从 NoSQL 数据库中分离出来，而是忙着想办法购买速度更快、IOPS 更高的硬盘。
我学到了很多东西：
- 我发现，升级硬件（购买更快的机器或花费一百万美元购买硬盘）只会延缓危机的发生。真正的解决之道是不可避免的——大规模横向扩展与关系型数据库不兼容。
- 我真正体会到了“地狱般的查询计划”的含义。我们用物化视图和只读副本勉强解决了这个问题。然后，我们做了从一开始就应该做的事情：搭建一个真正的报表路径。
- 如果你每周都需要优化查询计划？你的数据库正在向你发出一个重要的信号，你应该将其解读为：“是时候寻找替代方案了。”
深刻的教训：设计时要考虑实际的使用场景，而不是你希望的使用场景——并且要假设使用场景会发生变化。
这和光标和副驾驶有什么关系？
我看到很多人在 LinkedIn 和其他网站上写文章，盛赞 Vibe Coding（氛围编程）有多么神奇。这些赞美之词其实更多地暴露了发帖者自身的问题，因为他们很少正视这个过程的现实——它并非全是轻松愉快的事情。虽然一天或一周内取得的进步令人惊叹，但我们这些真正使用这些工具编写代码的人会告诉你，我们也从中吸取了很多宝贵的经验教训。
这并不“容易”。这个过程一点也不“轻松愉快”，如果你做得对，你甚至会在提示语里开始使用脏话。例如，昨天我回复 Cursor（光标）代理时的一些提示语是：“你在开玩笑吧，我明明规定过你绝对不能这么做，你居然无视了？”
每当我看到人们对最新最潮、最热门的、正在改变世界的潮流产品兴奋不已时，我也会第一时间注意到，他们可能并没有充分利用这些产品。如果他们真的充分利用了，就会明白这并非像他们所描述的那样“容易”。
你在数据库开发中培养的“失败肌”与你在人工智能编码工具开发中需要的“失败肌”是相同的。你不能小心翼翼地试探，而必须不断尝试，直到出现问题。然后，你才能以专业人士的身份去理解和运用这项新技术。
- 请代理人重构一个文件——太好了。
- 要求它协调 20 个文件中的更改，重新思考错误处理，并保持测试通过——现在我们才真正开始学习。
- 注意它在哪里出了问题，并学会调整工作方式，以便下次能够成功。
- 因为你那自作聪明的程序员完全无视了你的 Cursor 规则，结果白白浪费了一个周末。← 这代价不菲，但这就是学习之道。
关键不在于避免失败，而在于以可控的、可逆的方式失败。
如果你从未失败过，你就无法真正了解它。这适用于编程、预算、管理、烹饪和滑雪。如果你从未失败过，你就无法真正了解它。而大多数谈论“氛围编程”的人都没有经历过失败。
我最信任的工程师们能告诉我为什么某个环节出了问题，以及他们如何调整了方法。这就是人工智能编码工具的全部意义所在。循环（尝试 → 失败 → 检查 → 改进）运行得越快，效果就越好。
## 解读：5 问 5 答 ### 1）这篇文章最想纠正的“学习幻觉”是什么？ 它要纠正的是一种常见的“入门即掌握”的幻觉：看了教程、跑通 demo、读了几页文档，就以为自己已经会了。作者认为这种自信维持不了多久，因为它只证明了你能复现“顺利路径”，却没有经历真实工作里必然出现的**冲突场景、负载变化和边界条件**。 文章的核心判断是：**真正的理解往往来自失败后的排查与修复，而不是第一次跑通。** --- ### 2）为什么作者用“最糟糕的数据库模式”当面试问题？它在筛选什么能力？ 因为关系型数据库领域没有“完美模式”，只有在不同使用场景之间反复权衡。作者用这个问题筛选的是：候选人是否经历过真实复杂系统的代价，以及是否能把失败转化为结构化经验。 他期待的不是“教科书式正确”，而是能讲清楚： - 当初为什么那么设计（目标与假设是什么） - 后来发生了什么变化（报表/分析需求、访问模式、增长） - 症状如何出现（连接爆炸、索引不匹配、夜间任务干扰） - 团队如何演进方案（只读副本、物化视图、数据仓库、迁移） 这本质上是在筛选一种能力：**把系统性失败复盘成可迁移的原则**。 --- ### 3）“差点让我崩溃的模式”这一段，到底在说一个什么典型错误？ 典型错误是：**用为事务吞吐优化的 3NF 规范化模型，硬扛后来出现的分析/报表工作负载**，并且默许系统被当成“超大 Excel”来做汇总查询。短期看能跑，长期一定炸。 爆炸机制写得很直白：当查询模式与索引/连接结构不匹配时，系统会把大量时间耗在更新索引、执行复杂查询计划上，最终出现性能崩溃；而此时修复的代价巨大（停机、重写代码、合同期限逼近），导致团队转向“买更快硬盘”这种**延迟危机**的手段。 --- ### 4）作者对“硬件升级”“物化视图/只读副本”等手段的态度是什么？真正的解法是什么？ 态度可以概括为三层： - 对硬件升级：它只是**把痛点往后推**，无法改变架构与负载不匹配的事实。 - 对物化视图/只读副本：它们能止血，但更像临时补丁；作者称之为“勉强解决”。 - 真正的解法：从一开始就应该构建**真正的报表路径**，也就是把事务系统和分析系统（或分析路径）进行拆分，承认工作负载差异，并为之设计独立的存储、建模与查询方式。 最终抽象成一句原则：**设计要面向真实使用场景，而不是你希望的使用场景；并且要假设场景会变。** --- ### 5）把数据库的“失败肌肉”迁移到 AI 编码工具（Cursor/副驾驶、Vibe Coding）上，作者想表达什么？ 作者并不否认 AI 编码工具带来的效率提升，但反对“轻松愉快、像宣传那样简单”的叙事。他认为：真正学会使用这些工具，恰恰需要同一种“失败肌肉”——你必须把工具推到会出错的地方，观察它如何出错，然后调整你的工作方式。 他给出的学习路径其实是一种工程化迭代： - 让代理改一个文件很容易（学习价值有限） - 让它协调多文件改动、重构错误处理、保持测试通过，才会暴露真实问题 - 关键不在于避免失败，而是**以可控、可逆的方式失败**（比如在可回滚的范围内试错、快速检查、快速修正） 结论是：AI 编码的意义不在“永不出错”，而在于把“尝试 → 失败 → 检查 → 改进”的循环变快；成熟工程师的价值在于能说清**为什么错**以及**怎么改**。
