AI 能设计系统，但你能否识别它的错误

上个月，一个 AI 助手给我推荐了一套架构：API 网关、队列、缓存、Worker 进程，应有尽有。看起来非常棒。但它同时隐藏着一个问题——一旦真正遭遇流量高峰，整套系统都会垮掉。

这个 AI 并不差。它几乎所有地方都说对了——而恰恰是这一点让那个错误的地方变得危险。自信满满却不承担任何责任，是我们使用的每一个 AI 工具的共同风格。

这篇文章要讲的是一项能够发现这类问题的技能：系统设计判断力。它是什么，为什么它突然成了工程领域最有杠杆效应的技能，以及如何真正建立起这种能力。

为什么这项技能突然更值钱了，而不是贬值

有一种普遍的焦虑认为 AI 会让工程基础知识变得过时。我认为实际情况恰恰相反。

当 AI 写代码时，人类的工作上升了一个层级：决定构建什么以及方案是否可行。每个 AI 建议现在都是你正在进行的设计评审，不管你是否意识到。如果你无法评估这个建议，你就不是在使用工具——而是在听从某个从未在凌晨 2 点被叫醒处理问题的实体的指令。

在这个时代蓬勃发展的工程师并不是最擅长写 Prompt 的人。写 Prompt 是一项临时技能；模型越来越容易对话。知道答案什么时候是错的才是永恒的技能。

自信地错误的架构剖析

我在 AI 的架构建议中见过的真实错误类别：

看不见的单点故障。 图表上到处都有负载均衡器和副本——但只有一个 Redis 实例，一切都偷偷依赖着它。提议中没有任何内容是假的；风险只存在于没有说出来的部分。

在错误规模下的正确组件。 "添加消息队列"对十分之一的系统来说是正确的建议。对其余九个来说，它只是一个额外的网络跳数、运营负担和新的故障模式——解决了一个你根本没有的吞吐量问题。

一致性问题的含糊其辞。 AI 喜欢说"最终一致性"，就像餐厅说"时价"一样。当用户写入后立即读取时会发生什么？在面试中——或者事故复盘中——"最终"是问题的开始，而不是答案。

缺失的故障故事。 让 AI 设计一个系统，你会得到 Happy Path。问它"当缓存崩溃时会发生什么？"，它会兴高采烈地重新设计它刚才告诉你的一半内容。重新设计本应就是最初的设计。

注意这个模式：这些都不是通过更仔细地阅读建议就能发现的。它们是通过质询来发现的——而质询需要基础知识。

如何真正建立判断力

对我有效的，以及我见过的对他人有效的方法：

1. 掌握大约 20 个构建块，而不是 200 种架构。 负载均衡、缓存与淘汰策略、复制 vs 分片、消息队列、CAP 实际应用、限流、CDN、一致性哈希，以及它们的同类。每个大型系统都是这些组件的组合。不了解这些基础就记住"如何设计 Twitter"，就像不知道棋子怎么走就记住棋局开局一样。

2. 第二天凭记忆画出所有东西。 "我见过这个图表"和"我能画出这个图表"之间有巨大的鸿沟。只有第二种才是知识。如果你画不出来，那只是看过——而不是学会了。

3. 永远不要在没有质疑的情况下设计。 设计不是练习；为之辩护才是。为什么是那个数据库？10 倍规模时会坏什么？你刚刚制造了什么样的单点故障？让一个人或一个工具来挑战每一个选择。在没有质疑的情况下设计就像做 LeetCode 但不运行测试一样。

4. 在 AI 输出上练习。 这里有免费的、无限的练习材料：让任何 AI 设计一个系统，然后找出缺陷。通常至少有一个。这既是最现实的练习，也是你工作现在需要的精确技能。

因为我想要这个练习循环——视觉优先的基础知识、绘图和质疑——但找不到一个地方能满足，我构建了它：Architecto，一个 AI 老师，在白板上一笔一划地绘制系统设计图，同时讲解，然后测验你，让你捍卫你的设计。也没有固定的课程大纲——搜索任何 topic，如果不在目录中，课程会当场生成；职业路径模式也是如此（当前角色 → 目标角色 → 个性化课程）。Learn 模式是免费的。

是的——这是一个教你挑战 AI 的 AI。当它犯错而你抓住它时，那不是 bug。那是课程在起作用。

无论如何：读 DDIA，画图多于阅读，永远不要接受一个架构——无论来自人还是机器——而不先问什么会崩溃。