学前导读：工程化这一章到底在学什么

这一章解决的是：

一个能跑的 LLM 应用，怎样变成一个能上线、能排障、能维护的系统。

这一章的主线

LLM 应用上线后，最大的风险不是“某一次调用失败”，而是 Prompt 改了、模型版本变了、文档更新了、用户问题变了、成本突然升高了，却没有人知道是哪一层出了问题。LLMOps 要解决的就是可评估、可观测、可回滚、可持续改进。

方向	解决的问题	本章关注点
Prompt 版本管理	Prompt 改动后效果无法比较	记录版本、变更原因、适用任务和失败样本
评估集	优化只能凭感觉	固定测试问题、理想答案、评分标准和回归测试
LLM-as-Judge	人工评审成本高	用模型辅助评分，但保留人工抽查和标准答案
Trace	链路错误难复盘	记录输入、检索、Prompt、模型输出、工具结果和最终答案
成本监控	Token、重排、Embedding 和工具调用成本不透明	记录调用次数、Token、耗时和单次任务成本
Guardrails	输出格式、安全边界和权限容易失控	输入校验、输出校验、敏感信息处理和人工确认
Drift Monitoring	系统长期运行后质量变化	关注模型版本、文档版本和用户问题分布变化
AI CI/CD	更新应用后不知道是否退化	把评估集、格式检查和关键链路测试放进发布流程

学这一章时，可以把目标设成“我能不能解释一次失败”。如果系统答错了，应该能查到：用户问了什么、检索到了什么、Prompt 是哪个版本、模型返回了什么、工具有没有失败、耗时和成本是多少、最终为什么输出这个结果。

新人第一次学这一章时，先抓住异步、API、日志监控和部署这条主线。你不需要一次掌握完整 LLMOps 平台，只要能为最小应用加入错误处理、请求日志、成本记录和部署说明，就可以继续往后走。

有经验的学习者可以把这一章当成查漏补缺和工程化练习：关注边界条件、失败案例、评估方式、代码可复现性，以及它和前后阶段的连接。读完后最好能把本章内容沉淀到自己的作品 README 或实验记录里。

学完这一章后，建议完成一个最小练习：选择一个本章最核心的概念或工具，做出一个可以运行、可以截图、可以写进 README 的小成果。它不需要复杂，但要能说明输入是什么、处理过程是什么、输出结果是什么。

这一章结束时，你应该能用自己的话说明本章解决什么问题、它和前后学习站有什么关系，并能完成本章小项目出口的最小版本。

如果你还能记录一次常见错误、一次调试过程或一次结果改进，就说明你已经不只是“看过内容”，而是在把这一章变成自己的项目经验。