AI 能画架构图，但看不出它错在哪
设想一个很日常的场景：你让 AI 设计一个短网址服务。几分钟后，它给你一份完整方案：Base62 编码、Redis 缓存热点链接、MySQL 分库分表、Kafka 异步记录点击日志，还附带一张漂亮的架构图。
每个组件都有名有姓，每条线都画得通。你扫一眼，觉得挺全。
这时候有三个问题：
- 这套方案里，哪一个组件现在其实不该上？
- 哪一个风险它根本没提？
- 它为了”看起来完整”，替你做了哪些你没批准的取舍？
答不上来的话，这份方案对你来说就是一份”看起来对”的东西，而你要为它负责。
这篇想写的就是这件事：AI 越能写，工程师手里的基础专业能力越不能丢。下面我拿系统设计这个领域，把这个判断拆开说。
先说结论
AI 降低的是把方案翻译成产出的成本，没有降低判断方案好不好的成本。后者靠的是基础：你得知道存在哪些权衡，才看得出方案替你选了哪一个。
这不是我一个人的看法。Andrew Ng 团队今年 8 月发布过一份”AI 工程能力地图”，把”软件工程基础”单列为四项能力之一，理由写得很具体：工程的本质是在成本、可扩展性、可靠性、速度之间做权衡，懂基础的价值在于能意识到有哪些权衡存在，这决定了选什么技术栈、定什么架构、怎么设计数据存储。没经验的人 vibe code 出一个方案，却不知道 agent 正在替他做哪些权衡，通常还做得不好，因为他不知道该给 agent 什么上下文。
这里需要交代两点：这份地图基于 1 万多条招聘启事加访谈，样本不小，但 Ng 本人做课程，地图同时也是课程路线图，有利益关联，我只当作旁证，不当结论。另外，上面是我通过自己的整理笔记转述的，没有逐字核对原文。
AI 的方案里，权衡藏在哪
我把系统设计里最常见的几个概念，对照”AI 方案里它长什么样”和”你该追问什么”列了一张表。这是我自己的归纳，不是权威清单：
| 概念 | 在 AI 方案里的样子 | 你该问的 |
|---|---|---|
| 单点故障 | 架构图上一个叫”ID 生成器”或”配置中心”的方框 | 它挂了，整条链路还能不能工作？ |
| 一致性 | “先更新数据库，再删缓存” | 两步之间失败或并发，读到的是新值还是旧值？能接受多久的不一致？ |
| 容量估算 | 通篇没有一个数字 | 读写比是多少？峰值 QPS 多少？这个数量级需要分库吗？ |
| 消息队列 | “异步解耦，削峰填谷” | 重复消费怎么办？顺序要不要保证？积压了谁发现？ |
| 限流与降级 | 一句”加网关限流” | 限谁？限多少？被限的请求用户看到什么？ |
| 延迟与吞吐 | “性能优秀”“高并发” | 优化的是哪一个？以什么为代价？ |
这张表里没有一个问题是 AI 时代新出现的。它们都是十年前的老问题。区别在于，以前方案是你自己一笔一笔画出来的，画的时候被迫想过这些；现在方案是”生成”出来的，你可以一个都没想就拿到手。
一个小例子：短网址里藏着的几个判断
接着开头的场景，往下走几步，看看基础怎么派上用场。下面都是系统设计里的常规知识，我只是把它放回具体场景。
第一，要不要分库分表。 短网址是典型的读多写少，读写比往往能到几十比一甚至更高。这种场景下，往往缓存先于分库见效。方案一上来就分库分表，多半是在为一个还没出现的问题付复杂度。能不能看出这一点，取决于你有没有做过粗略的容量估算。
第二，ID 怎么来。 如果方案用一个全局自增 ID 再转 Base62，那个”发号器”就是单点：它挂了，所有新链接都生成不了。想到这一层，才会追问是做号段预取、多实例分段，还是换一种不依赖中心发号的方式。
第三，301 还是 302。 这是个很小的选择，后果却不小。301 是永久重定向，浏览器会缓存，之后点击不再经过你的服务，点击统计就丢了；302 每次都回源，统计准，代价是流量全打到你这里。AI 给的方案选哪个，取决于它默认的偏好，而不是你的业务是否需要统计。
第四，热点。 某条短链被大范围转发时，单个缓存 key 会被打爆。方案里没提，不代表不存在。
这四条都不深，但如果一条也问不出来，你就只能接受那份方案，或者全盘否定它。两种结果都不是判断。
这跟”认知投降”是同一件事
我在之前的文章里写过一个实验：借助 AI 和自己动手的两组人，完成任务一样快，事后理解测验却差了 17 个百分点。亏掉的不是代码，是做这件事的人对它的理解。
系统设计是这个现象的高发区，原因是它的产出形态：一张图、一段文字。图画得好不好看，和设计对不对，几乎没有关系，而人又天然容易被”完整”和”自信的语气”说服。
我之前写过《AI 时代的竞争力：从执行者到判断者的蜕变》，说判断力是护城河。现在补一句更具体的：架构判断力不是天赋，是一堆具体概念和踩坑记忆的总和。 概念不熟，判断就是空的。
基础能力怎么养：把 AI 放到评审席
我自己的想法是，别用”让 AI 出方案”来学系统设计，换个顺序：
- 先自己画一版。 哪怕很粗，写下读写比、峰值估算、两三个核心组件和你最担心的一个风险。
- 再让 AI 出一版。 把两版放在一起，看差在哪。
- 最后让 AI 挑你的刺。 让它专门找你方案里的单点、一致性问题和容量盲区。
这样 AI 是评审，不是作者。你始终是先开口的那个人，问题的形状由你来定。需要说明：这个流程是我的推演，没有做过对照，不要当成经过验证的方法。
至于学什么，GitHub 上有个很受欢迎的清单可以当目录用：
据 X 上的推荐帖介绍，它大致分四块：核心概念（可扩展、可用、可靠，单点故障，CAP，一致性哈希，延迟与吞吐）、四大基石（网络与 API、数据库与缓存、消息队列与微服务）、经典案例（短网址、Twitter、限流器等）、延伸阅读（大厂工程博客和分布式论文）。我没有逐章读过仓库，star 数和具体内容请以仓库为准。
读它的方式，我建议：
- 先概念，后案例。 案例题是概念的组合练习，概念不稳就做案例，只会背答案。
- 按手头的问题挑章节读。 正在被缓存一致性困扰，就读缓存那一块；不用从头线性刷。
- 案例题先自己画，再看答案。 直接看答案几乎学不到东西，这和上面的流程是一回事。
- 工程博客和论文当”校准”用。 它们告诉你真实系统在哪里做了妥协，补的是教科书答案和线上现实的差距。
几点保留
这不是让你回去手写所有东西。 AI 写样板、查资料、出初稿都很好用，该用就用。我说的是别让它替你判断。
不用把整份清单背下来。 目标是”看得出有权衡存在”，不是”所有答案都在脑子里”。看不懂 AI 方案的某一处，多半就是该补的那一块。
基础不能替代领域理解。 做得好和做得对是两个维度：架构基础管前者，对业务的理解管后者。一个架构再漂亮，业务规则错了照样白搭。这个话题值得单独写，这篇先不展开。
导航型清单的局限。 那类仓库内容靠外链，质量参差，偏英文、偏面试。如果你的目标是把线上系统做稳，面试框架那部分可以跳过。
结语
AI 把”画出一份架构方案”这件事的成本降到了几分钟，于是方案的数量不再稀缺，稀缺的是能说出”这份方案的第三条在我们的场景下不成立”的人。
这句话需要的恰好是最基础的东西：知道有哪些权衡，估得出一个数量级，记得住几次踩过的坑。它们不会因为 AI 变强而过时，只会因为你不再练而生锈，而且生锈得悄无声息。
最后留一个本周就能做的动作：挑一个你手头系统里最近 AI 参与设计的部分，不看原方案，先用五分钟写下”如果它挂了会怎样、数据会不会不一致、峰值来了撑得住吗”三个答案。 然后再对照方案。答不上来的地方，就是这周该补的课。