AI 编程时代的架构认知：书籍推荐与快速补齐路径
当 AI 能写出语法正确、单测通过的代码之后，人的价值就从"会写"转移到了"知道该写什么、为什么这样写、以及什么时候不写"。架构认知就是这一层的护城河。
一、为什么架构认知必须在 AI 之上
AI 擅长的是局部最优——在给定上下文里生成合理的代码片段。它天然薄弱的是：
- 跨模块权衡：一个改动对三个月后的迁移成本影响几何？
- 领域建模：业务里"订单"和"履约单"到底是不是一个东西？
- 演化路径：先单体再拆分，还是一开始就微服务？
- 非功能性：一致性 vs 可用性、延迟 vs 吞吐量、人力成本 vs 机器成本。
这些问题的答案不在代码里，而在业务约束、组织结构、历史包袱和未来假设里。你给 AI 的 Prompt 质量，取决于你能否把这些抽象清楚。换句话说：你是架构师，AI 是施工队。你画不出图纸，再好的施工队也只能盖出违章建筑。
二、分层书单（按优先级排序）
Layer 1：思维基座（必读，决定上限）
| 书籍 | 作者 | 为什么读 |
|---|---|---|
| A Philosophy of Software Design | John Ousterhout | 最薄却最高信噪比的设计书。"Deep Module""Strategic vs Tactical"是和 AI 对话的核心词汇。 |
| The Pragmatic Programmer (20th Anniv.) | Hunt & Thomas | 工程师心智模型的最大公约数。DRY、正交性、可逆性——这些是你判断 AI 输出好坏的尺子。 |
| Code Complete 2 | Steve McConnell | 厚但值得翻。用来校准"什么叫好代码"的直觉。 |
Layer 2：系统设计与分布式（中期战场）
| 书籍 | 用途 |
|---|---|
| Designing Data-Intensive Applications（DDIA） | 这本是分水岭。读完之后，你看 AI 生成的任何存储/一致性方案都会自动起疑。 |
| Database Internals | 理解 B-Tree、LSM、WAL，才知道 AI 推荐的数据库选型靠不靠谱。 |
| Release It! | 稳定性模式：熔断、舱壁、超时。AI 很少主动给你加这些。 |
| Site Reliability Engineering（Google SRE） | 运维视角反推架构。 |
Layer 3：领域建模与演化（长期壁垒）
| 书籍 | 用途 |
|---|---|
| Domain-Driven Design（Evans 蓝书） | 核心是"统一语言"。你能把业务讲清楚，AI 才能帮你写对。 |
| Implementing Domain-Driven Design（Vernon 红书） | 蓝书的工程化落地。 |
| Patterns of Enterprise Application Architecture（Fowler） | 所有"业务系统套路"的原始出处。Repository、Unit of Work、Service Layer——AI 张口就来的术语，你得知道它们从哪来、适用边界在哪。 |
| Monolith to Microservices（Sam Newman） | 不是教你拆，是教你什么时候不拆。 |
Layer 4：方法论与决策（锋利的刀）
| 书籍 | 用途 |
|---|---|
| Thinking in Systems | Donella Meadows。系统思维的入门，帮你看到反馈回路和杠杆点。 |
| The Mythical Man-Month | 老但不过时。关于组织与软件同构（康威定律）的原始论证。 |
| Accelerate | 用数据告诉你什么样的工程实践真的能提高组织效能。 |
| Fundamentals of Software Architecture | Mark Richards。架构师的决策框架与 trade-off 清单。 |
Layer 5：语言与范式底层（可选，但看你的技术栈）
- Structure and Interpretation of Computer Programs（SICP）— 抽象能力的内功
- Crafting Interpreters — 理解一门语言是怎么工作的
- Operating Systems: Three Easy Pieces — 免费，讲得清楚
三、快速补齐策略：不要读完，要读透
读书的陷阱是"为了读完而读完"。对抗 AI 的认知优势来自深度而非广度。推荐以下路径：
阶段 1：建立词汇表（2–4 周）
只读两本：A Philosophy of Software Design + DDIA 前四章。
目的不是记住细节，而是让你拥有描述问题的词汇——模块深度、接口复杂度、复制延迟、线性一致性。没有词汇，你连 AI 输出的问题都描述不出来。
阶段 2：刻意练习 Trade-off（持续）
每次 AI 给你方案，强制自己回答三个问题：
- 它假设了什么？（流量规模？一致性要求？失败模式？）
- 反面方案是什么？（如果不用缓存/消息队列/微服务，会怎样？）
- 三个月后哪里会崩？（schema 改动？团队规模变化？边界情况？）
这个练习比读十本书都有效。AI 给你的是答案，而架构师的职业是问问题。
阶段 3：读源码验证直觉（长期）
挑一个你在用的工具（Redis、Postgres、Kafka、Kubernetes），读它的设计文档（不是全部代码）。你会发现课本上的抽象在真实系统里长什么样，以及真实系统怎么在理想模型上做妥协。
阶段 4：写作倒逼理解
把你读到的概念用自己的话写出来、讲给别人（或 AI）听。AI 是个完美的陪练——让它扮演初级工程师提问，你来解释。能讲清楚就是懂了，讲不清楚就是还没懂。
四、和 AI 协作的具体姿势
有了认知基座，协作方式自然会变：
- 先画边界，再写代码：让 AI 帮你枚举方案、列出 trade-off，但选型由你拍板。
- Prompt 里夹带约束：一致性要求、QPS、团队规模、预算。AI 默认写"玩具代码"，约束越具体，输出越像工程代码。
- 代码评审看结构不看语法：语法错 AI 基本不会犯；结构错它天天犯——职责分散、抽象泄漏、隐式耦合。
- 不要让 AI 做领域建模：业务概念的命名与边界必须由懂业务的人定。AI 只能在你给的本体论里干活。
五、一个务实的起点
如果只能选三本，就是：
- A Philosophy of Software Design — 一周读完，立刻可用
- DDIA — 慢慢啃，半年受益十年
- Domain-Driven Design（Evans） — 当你开始做有业务复杂度的系统时
读这三本 + 坚持"Trade-off 三问"练习半年，你对 AI 输出的判断力会有质变。
一句话总结：AI 让"实现"变得廉价，于是"决策"变得昂贵。书不是用来超过 AI 的——书是用来让你有资格使用 AI 的。
