这本书写给应用层 AI 工程师——你的工作是把大模型接进真实系统：调 API 或自托管模型、设计检索、搭 agent、控制成本、在半夜被 on-call 叫醒。你需要知道模型底下发生了什么，但你不需要自己写 CUDA kernel，也不打算从零预训练一个基座模型。
因此，本书不写这些内容：Transformer 架构的逐层数学推导、预训练的分布式并行策略、CUDA kernel 优化、模型架构创新的研究前沿。这些是好东西，但它们属于另一本书；把它们塞进来只会稀释你真正每天要做的决策。
本书想让你获得的是判断力而不是操作手册：面对一个需求，能判断瓶颈在哪、该动哪个旋钮、什么方案是过度设计、成本会落在什么量级。所以每一章都围绕同一组问题展开——这个东西为什么存在？它解决了什么问题？什么时候它不是答案？
前置知识。假设你知道什么是 Transformer 和 attention（概念层面即可）、写过调用 LLM API 的代码、了解基本的服务端工程概念（延迟、吞吐、缓存、队列）。不假设你读过任何一篇本书引用的论文。
AI 工程的知识有一个恼人的特点：它过期得非常快。今天记住的最佳实践，明年可能连工具名都换了。但并非所有知识都以同样的速度腐坏——把它们混在一起写，是大多数技术文档很快失去价值的原因。
所以本书把每一条知识按一个简单的问题分层：
看到虚线框（右上角带「截至 YYYY-MM」日期戳）时，请把它当作一份会过期的快照——正文的论证从不依赖侧栏内容，你完全可以跳过全部侧栏读完整本书而不损失任何逻辑。反过来，如果你正在解决一个具体问题，侧栏和附录 A 才是你要找的地方。
这个分层还有一个实际好处：本书更新时，绝大部分改动集中在侧栏和附录 A，正文可以长期稳定。如果你读到某个侧栏的日期戳已经很旧，请默认它已经过期——日期戳存在的意义就是让你有理由怀疑它。
| 区块 | 作用 |
|---|---|
| 核心概念 | 这个东西为什么存在、解决什么问题（原理层） |
| 真实案例 | 论文、公开 postmortem 或匿名化的工程实践，尽量带数字 |
| 图表 | 每章至少一张原创示意图，均为本书重绘并标注来源 |
| 工具层侧栏 | 当前生态的具体做法，带截至日期 |
| 章末自测 | 估算 / 场景判断 / 决策 / 架构评审 / 面试题改编，答案默认折叠 |
关于术语：技术术语首次出现时给出英文原文，后接中文解释，如 KV cache（键值缓存）；此后同章内直接使用英文。业界没有通用中文译名的术语一律保持英文，本书不生造译名。全部术语汇总在附录 B 术语表，每条带首次出现章节的锚点链接。
关于数字的诚实声明。凡引用论文或公开报告的数字，案例区块底部都给出可溯源的出处，并保留原始实验条件（哪个模型、什么基线、什么负载）——脱离条件的「快 N 倍」是没有意义的。凡本书自己推导的估算，都会写出计算方法与假设，你可以换成自己的数字重算。价格类内容一律属于工具层，不作任何「当前价格」的承诺。
Part 1 到 Part 4 各章相对独立，你可以按需跳读。Part 5（Training / Fine-tuning）不一样：它的四章共享一个连续的工程故事，连读构成一次完整的项目叙事。
把一个任务从前沿大模型 API 蒸馏到自托管小模型。一个已经跑在生产环境、由前沿模型 API 支撑的高频任务，成本和延迟都开始变得难以接受。团队要回答：该不该自己训一个小模型接手？如果训，用什么方法、数据从哪来、怎么证明它真的能用？
5.1 要不要蒸馏——先证明所有更便宜的手段都试过了 · 5.2 选 LoRA 配置——rank 和 alpha 到底怎么定 · 5.3 造数据——项目真正的瓶颈 · 5.4 验证效果——怎么证明它没有偷偷变笨
每章开头都有这样一个橙色的「故事线」区块交代该阶段剧情，正文则讲述这一步背后的原理。这个案例是综合多个真实项目的匿名化叙事，其中的模型规模、数据量与成本数字均为便于推演而设定的示例假设，计算过程全部写出——重点是决策链条，不是具体数值。
此外 4.5 节 会围绕一个私有 AI 助理平台的架构演进（同样匿名化）展开，Part 6 的多章则使用公开可查的 postmortem 与安全事件。