Day 14：Week 2 复盘与考试
学习目标
过去六天你学了大量的工程技能：API 调用、结构化输出、Function Calling、Prompt 模板管理、后端架构设计、完整 Demo 的搭建。今天是 Week 2 的最后一天，要把这些散落的知识点整合成一个完整的知识体系，并通过一个综合实战来检验你真正掌握了多少。
复盘不是简单的回顾。它要求你站在更高的视角，看清各个知识点之间的关联，发现自己理解薄弱的地方，为 Week 3 的学习做好准备。
今天的学习目标有三个：通过复盘建立 Week 2 的完整知识框架，通过综合实战验证你能否独立完成一个完整的 AI 应用模块，通过总结明确 Week 3 需要重点关注的领域。
核心概念
一、API 调用复盘
Day 8 的核心是”怎么可靠地调用大模型 API”。这个问题看起来简单，实际上涉及密钥管理、请求构造、流式输出、参数调优、错误处理、重试策略、速率限制、日志记录等多个工程问题。
复盘时要问自己的关键问题：
你能不能不看资料，完整描述一次 API 调用的流程？从构造请求到处理响应，中间经过了哪些环节？
如果 API 调用突然失败，你能根据错误信息快速定位问题吗？401 是什么错误？429 是什么错误？5xx 是什么错误？每种错误应该怎么处理？
你的 LLM Client 封装是否考虑了扩展性？如果要支持 OpenAI 以外的模型（比如 Claude、DeepSeek），需要改多少代码？
API 调用的工程本质是”为不确定的模型服务建立确定性的调用边界”。模型可能慢、可能出错、可能拒绝服务，但你的调用层应该是稳定的——有超时保护、有重试兜底、有日志可查、有降级可用。
需要特别回顾的知识点：
指数退避重试的原理和参数选择。为什么每次等待时间要翻倍？为什么加抖动？最大重试次数怎么定？
Token 统计的意义。为什么每次调用都要记录 Token 消耗？Token 统计数据能用来做什么？
Streaming 的实现细节。SSE 协议的工作方式、首 Token 时间的计算、流式输出下的 Token 统计。
二、结构化输出复盘
Day 9 的核心是”让模型输出能被程序可靠处理的数据格式”。
结构化输出的工程本质是”在模型的概率生成和程序的确定性要求之间建立桥梁”。模型生成的是概率性的自然语言，程序需要的是确定性的结构化数据。JSON Mode、JSON Schema、Pydantic 校验、格式修复、自动重试——这些机制共同构成了这座桥梁。
复盘时要问自己的关键问题：
JSON Mode 和 JSON Schema 的区别是什么？一个保证格式合法，一个保证内容合规。两者为什么需要配合使用？
你设计 JSON Schema 的策略是什么？是从简单版本开始逐步增加复杂度，还是一开始就设计完整结构？哪种方式成功率更高？
当模型输出的 JSON 校验失败时，你的重试策略是什么？为什么”带反馈的重试”比无脑重试有效？
Pydantic 在结构化输出流程中扮演了什么角色？它和 JSON Schema 是什么关系？
一个需要深刻理解的点：结构化输出的成功率不是 100%。即使你的 Schema 设计得很好、Prompt 写得很清楚，模型偶尔还是会输出不符合要求的结果。你的系统需要能处理这种情况——格式修复、带反馈重试、降级返回。这些兜底机制才是结构化输出”工程实践”的核心。
需要特别回顾的知识点：
字段约束的设计策略。必填与选填的权衡、枚举值的设计原则、嵌套深度的控制。
格式修复的边界。哪些格式问题可以自动修复，哪些不能？格式修复只处理”形式”不处理”内容”的原则。
入库策略。为什么建议同时保存原始 JSON 和解析后的数据？
三、Function Calling 复盘
Day 10 的核心是”让模型能使用外部工具”。
Function Calling 的工程本质是”扩展模型的能力边界”。模型本身只能生成文字，但通过函数调用，它可以查询数据库、搜索网络、计算结果、执行操作。模型从”只会说话”进化为”能使用工具的助手”。
复盘时要问自己的关键问题：
Function Calling 中，模型的角色和你的代码的角色分别是什么？为什么不让模型直接执行函数？
Tool Schema 的 description 字段为什么如此重要？描述写得好和写得差，对模型的工具选择准确率有什么影响？
如果一个工具执行失败了，你应该怎么处理？为什么要把错误信息返回给模型？
函数执行的注册表机制是怎么工作的？为什么要用注册表而不是直接在代码里调用函数？
Function Calling 是后续 Agent 系统的基础。Week 4 你会基于 Function Calling 构建完整的 Agent。如果你对今天的内容还有模糊的地方，现在就是搞清楚的时候。
需要特别回顾的知识点：
工具选择的准确性受哪些因素影响。工具描述的质量、工具数量、工具之间的区分度。
参数验证的重要性。模型传入的参数不一定合法，你的代码需要在执行前做验证。
工具调用日志的价值。调试、优化、成本分析都依赖这些日志。
四、Prompt 模板库复盘
Day 11 的核心是”把 Prompt 从散装状态变成系统化管理”。
Prompt 模板库的工程本质是”把非结构化的 Prompt 转化为可管理、可测试、可迭代的资产”。没有模板库，Prompt 散落在代码各处，无法复用、无法评估、无法追溯。有了模板库，每个 Prompt 都有分类、命名、版本、参数、测试、评分。
复盘时要问自己的关键问题：
你的 Prompt 分类体系是否合理？找一个 Prompt 需要多长时间？
你的 Prompt 命名是否一致？不看文档能猜到 Prompt 的用途吗？
Prompt 的版本管理中，每次变更是否都记录了变更内容、变更原因和效果对比？
评分体系是否真的在用？还是设计好了但从来没给 Prompt 打过分？
Prompt 模板库的核心价值不在于工具本身（文件系统或数据库都可以），而在于”管理的纪律”。每次新建 Prompt 都走标准流程（命名、分类、参数定义、测试、评分），每次修改 Prompt 都记录变更历史。这种纪律让 Prompt 资产随时间增值而不是贬值。
需要特别回顾的知识点：
参数化模板的设计。参数要少而精，每个参数有类型和约束。
测试样例的覆盖度。典型场景和边界场景都要覆盖。
评分维度的选择。格式合规、内容准确、信息完整、可操作性、稳定性。
五、后端接口复盘
Day 12 和 Day 13 的核心是”把 AI 能力封装成可交付的后端服务”。
后端架构的工程本质是”把零散的 AI 能力组织成结构化的服务”。没有后端架构，你的 AI 能力只是一堆脚本——能跑但不能给别人用。有了后端架构，你的 AI 能力变成了 API 接口——别人可以通过 HTTP 调用来使用。
复盘时要问自己的关键问题：
你的项目目录结构是否清晰？新增一个功能需要修改几个文件？
路由层、服务层、客户端层的职责是否分明？路由层里有没有业务逻辑？
请求体和响应体的设计是否规范？有没有统一的错误返回格式？
配置管理是否到位？API Key 是不是还在代码里？
后端架构还有一个容易被忽略的价值：它迫使你思考”用户怎么使用你的 AI 能力”。当你设计请求体时，你在思考”用户需要提供什么信息”。当你设计响应体时，你在思考”用户需要看到什么结果”。这个思考过程本身就是产品设计的过程。
需要特别回顾的知识点：
FastAPI 的基本用法。路由定义、请求体校验、响应模型、中间件。
服务层的设计原则。单一职责、依赖注入、层间解耦。
错误处理的统一规范。错误码体系、错误信息脱敏、日志记录。
概念关系图
+===================================================================+
| Week 2 知识体系全景图 |
+===================================================================+
| |
| +-------------------+ +-------------------+ |
| | Day 8: API 调用 | | Day 9: 结构化输出 | |
| | - API Key 管理 | | - JSON Mode | |
| | - Chat/Stream | | - JSON Schema | |
| | - 错误处理/重试 | | - Pydantic 校验 | |
| | - Token 统计 | | - 格式修复/重试 | |
| +--------+----------+ +--------+----------+ |
| | | |
| v v |
| +-----------------------------------------------+ |
| | 模型调用基础设施层 | |
| | LLMClient + 结构化输出 + 日志 + 重试 | |
| +-----------------------------------------------+ |
| | | |
| v v |
| +-------------------+ +-------------------+ |
| | Day 10: 工具调用 | | Day 11: Prompt 模板 | |
| | - Tool Schema | | - 分类/命名 | |
| | - 函数选择/执行 | | - 版本/参数 | |
| | - 结果返回 | | - 测试/评分 | |
| | - 失败处理 | | - 迭代记录 | |
| +--------+----------+ +--------+----------+ |
| | | |
| v v |
| +-----------------------------------------------+ |
| | 能力封装层 | |
| | Function Calling + Prompt 模板库 | |
| +-----------------------------------------------+ |
| | |
| v |
| +-----------------------------------------------+ |
| | Day 12-13: 后端服务 + Demo | |
| | - FastAPI 项目结构 | |
| | - 路由/服务/客户端分层 | |
| | - 行业分析 API Demo | |
| +-----------------------------------------------+ |
| | |
| v |
| +-----------------------------------------------+ |
| | 交付层 | |
| | 可调用的 API + 文档 + 测试报告 | |
| +-----------------------------------------------+ |
| |
+===================================================================+
实战分析
综合实战：4 小时完成小型行业分析系统
指南要求用 4 小时完成一个小型行业分析系统。这个系统要包含：输入行业名称、输出 JSON 结果、输出 Markdown 报告、保存日志、生成接口文档。
4 小时的时间分配建议
第一个小时：搭建项目骨架。创建 FastAPI 项目、设计目录结构、实现 LLM Client 封装、配置管理。这个阶段不要追求完美，能用就行。
第二个小时：实现核心分析流程。定义行业分析的 Prompt 模板、定义输出的 Pydantic 模型、实现分析接口的路由和服务层。这个阶段是核心——确保从输入到输出的链路能跑通。
第三个小时：完善功能。加入结构化输出校验和重试、加入结果保存、加入 Markdown 报告生成、处理常见的错误场景。这个阶段把”能用”变成”好用”。
第四个小时：测试和文档。测试 3-5 个行业、记录测试结果、生成 API 文档、修复发现的 bug。这个阶段确保系统的质量。
关键决策点
在 4 小时的约束下，你需要做一些取舍：
功能范围。不要试图实现所有功能。优先保证核心链路（输入→分析→输出），有剩余时间再加增强功能（报告生成、历史查询）。
代码质量。4 小时写不出完美的代码，但可以写出结构清晰的代码。哪怕服务层的实现是简化版的，目录结构和分层设计也要按规范来。代码结构比代码细节重要。
测试深度。不要在单个行业上反复测试。快速测 3-5 个不同类型的行业，发现明显问题就修，不明显的问题记录下来。有限时间内覆盖广度比深度更有价值。
容易踩的坑
第一个坑：花太多时间在项目骨架上。搭了两个小时的项目结构，写配置管理、日志中间件，留给核心功能的开发时间不够。建议骨架最多 1 小时，核心功能至少 2 小时。
第二个坑：Prompt 设计花太长时间。行业分析的 Prompt 写了又改，改了又写，花了一个小时还没定稿。建议先用一个基本能用的 Prompt，跑通整个链路后再优化 Prompt。
第三个坑：过度优化错误处理。每种错误场景都想得很完善，写了很多异常处理代码。在 Demo 阶段，只处理最常见的 3-5 种错误就够了。其他错误统一兜底处理。
系统的验收标准
完成后，你的系统应该满足以下条件：
基本功能。能通过 HTTP 接口输入行业名称，返回结构化的 JSON 分析结果。
输出质量。分析结果包含至少 5 个维度（行业概况、市场数据、竞争格局、AI 机会、风险）。字段格式正确、内容合理。
报告生成。能基于分析结果生成 Markdown 格式的报告。
日志记录。每次分析都有日志记录，包含输入、输出、Token 消耗、耗时。
错误处理。对常见错误输入（空输入、无效输入）能返回友好的错误信息。
接口文档。有可用的 API 文档（FastAPI 自动生成的即可）。
当日产物说明
Week 2 学习总结
一份完整的学习总结文档。包含以下内容：
知识图谱。用文字或图示描述 Week 2 学到的所有知识点及其关系。不是简单的列表，而是一个有逻辑的体系。
能力清单。列出你通过 Week 2 掌握的具体能力。每项能力用”能做什么”来描述，而不是”学过什么”。比如”能设计 JSON Schema 并通过 Pydantic 校验模型输出”而不是”学过 Pydantic”。
薄弱点识别。列出你觉得还不够扎实的知识点。这些是后续需要重点复习的内容。
行业分析系统 v1
4 小时综合实战的产物。一个可以运行的完整系统。包含：
后端服务。FastAPI 项目，包含行业分析接口。
Prompt 模板。至少一个经过测试的行业分析 Prompt 模板。
数据模型。Pydantic 定义的行业分析输入输出模型。
测试结果。3-5 个行业的测试记录。
API 文档
系统接口的完整文档。包含所有接口的 URL、方法、参数、返回值、示例。FastAPI 自动生成的 /docs 页面加上必要的补充说明。
Prompt 模板库 v1
经过一周迭代的 Prompt 模板库。包含至少 10 个可用的 Prompt 模板，每个模板有分类、命名、版本、参数定义、至少一个测试样例。
补充：Week 2 知识点速查表
下面是 Week 2 所有核心知识点的浓缩速查表。如果你能对每个知识点不看资料讲出核心内容，说明你真正掌握了。
Day 8 速查。API Key 管理四原则（不硬编码、分环境、定期轮换、分项目）。Chat API 的消息角色（system 设规则、user 提问题、assistant 存历史）。Streaming 用 SSE 协议逐 Token 发送。Temperature 控制随机性（低=确定、高=创意）。Max Tokens 控制输出长度。Token 统计三项数据（prompt_tokens、completion_tokens、total_tokens）。错误分两类（可重试和不可重试）。重试用指数退避加抖动。速率限制用请求队列或多 Key 轮询应对。日志记录请求、响应、Token、耗时。
Day 9 速查。JSON Mode 保证格式合法但不保证内容正确。JSON Schema 定义字段、类型、约束。Pydantic 用类型注解做校验。枚举值约束选项范围。必填字段不要超过 7 个。格式修复只处理形式不处理内容。重试要带错误反馈。入库要全量保存原始数据。
Day 10 速查。模型只决定调用什么函数，你的代码负责执行。Tool Schema 的 description 决定模型选择的准确率。参数设计要精简（不超过 5 个）。函数注册表映射函数名到实现。执行失败要把错误信息返回给模型。工具数量建议 5-8 个。工具调用日志记录完整的调用链路。
Day 11 速查。分类按用途不按技术。命名用前缀_核心_后缀。版本记录变更内容和效果对比。参数化模板支持复用和测试。输出格式定义 JSON Schema。测试样例覆盖典型和边界场景。评分维度包括格式、准确、完整、可操作、稳定。迭代记录追踪演进历史。
Day 12 速查。FastAPI 适合 AI 应用后端（异步、自动文档）。路由设计要版本化。请求体用 Pydantic 定义和校验。响应体结构统一（code/message/data）。服务层拆分（路由/业务/客户端/数据）。配置管理用分层覆盖。日志中间件全局记录。错误返回格式统一。目录结构按职责分层。
Day 13 速查。输入规范化包括同义词映射和格式校验。任务解析把模糊请求拆成子任务。模板选择根据任务类型和深度。模型调用可以分步也可以一次完成。结构化校验不通过要重试。结果全量保存。Markdown 报告用模板加模型润色。API 文档用 FastAPI 自动生成加补充说明。
补充：Week 2 的三个核心工程模式
回顾这一周，有三个工程模式反复出现在不同的知识点中。识别这三个模式，能帮助你更好地理解 Week 2 的设计哲学。
第一个模式：校验-重试-降级。这个模式出现在结构化输出（Day 9）、Function Calling（Day 10）、模型调用（Day 8）中。基本流程是：先校验结果是否合格，不合格就重试（带反馈），重试耗尽就降级处理。这个模式的核心思想是”不要期望一次成功，但要保证最终有结果”。在 AI 应用中，因为模型输出的不确定性，一次成功的概率不可能达到 100%。但通过校验、重试和降级的组合，可以把可用率提升到 95% 以上。
第二个模式：分层-解耦-封装。这个模式出现在后端架构（Day 12）、LLM Client（Day 8）、Prompt 管理（Day 11）中。基本思路是：把不同的职责分到不同的层，层与层之间通过接口交互，每层封装自己的实现细节。上层不需要知道下层怎么做，只需要知道下层提供什么。这个模式的好处是：修改一层不影响其他层，测试一层不需要其他层真的在工作。
第三个模式：参数化-模板化-版本化。这个模式出现在 Prompt 模板库（Day 11）、JSON Schema 设计（Day 9）、后端配置（Day 12）中。核心思想是：把可变的部分抽象为参数，把固定的部分做成模板，把变化的过程记录为版本。参数化让你复用而不是重写，模板化让你标准化而不是随意，版本化让你可追溯而不是遗忘。
这三个模式不只适用于 Week 2 的内容，在后续的 RAG 系统、Agent 系统、工程化阶段同样适用。掌握这些模式，你就掌握了 AI 应用开发的方法论基础。
常见误区与避坑
误区一：复盘就是重新看一遍笔记
把 Day 8 到 Day 13 的笔记从头到尾看一遍，觉得自己都看懂了就完事。这不是复盘，这是重读。真正的复盘要回答一个问题：“不看笔记，我能把这些知识讲给别人听吗？“如果讲不清楚，说明理解还不够深。
误区二：综合实战追求完美
4 小时的综合实战，花太多时间打磨某个细节，导致整体链路没跑通。一个能端到端运行的简单系统，比一个某个环节很精美但整体不通的系统更有价值。
误区三：只关注技术不关注思考
复盘时只回顾了技术知识（API 怎么调、Pydantic 怎么用），没有回顾思维方式。Week 2 最重要的思维转变是什么？从”用 AI”到”工程化地用 AI”。从”写 Prompt”到”管理系统”。从”跑通一次”到”稳定可靠”。这些思维层面的收获比具体的技术知识点更重要。
误区四：没有识别薄弱点
复盘时觉得自己”都掌握了”，没有识别出还不扎实的知识点。一个简单的检测方法：对每个知识点，你能不看书、不看笔记，完整讲 5 分钟吗？讲不出来或者讲到一半卡住的地方，就是薄弱点。
误区五：和 Week 1 割裂
复盘 Week 2 时没有回顾 Week 1 的内容。Week 2 的很多知识点建立在 Week 1 的概念基础上——结构化输出建立在”大模型的概率生成”理解之上，Function Calling 建立在”AI 应用九大模块”的认知之上。把两周的知识连起来看，才能形成完整的认知框架。
延伸思考
Week 2 的主题是”API、结构化输出与 Prompt 工程化”。回头看这六天的学习，你可以把 Week 2 的收获分为三个层次：
工具层。你学会了具体的工具和技术的使用——FastAPI、Pydantic、JSON Schema、Function Calling。这些是硬技能，可以直接应用到项目中。
方法层。你学会了系统化的方法——LLM Client 的封装模式、结构化输出的校验流程、Prompt 模板库的管理体系、后端服务的分层架构。这些方法可以迁移到不同的项目中。
思维层。你建立了一种工程化的思维——不是”能用就行”，而是”稳定、可维护、可扩展”。不是”写一次就完了”，而是”可测试、可评估、可迭代”。这种思维会贯穿你后续所有的学习和工作。
Week 3 的主题是”RAG 知识库系统”。RAG 解决的核心问题是”大模型不知道你的数据”。在 Week 2 中，你已经学会了怎么调用模型、怎么处理输出、怎么设计接口。Week 3 要在这些基础上增加一个新的维度：怎么把外部知识接入模型。
Week 2 的知识和 Week 3 的知识是怎么衔接的？
LLM Client 是 Week 3 RAG 系统的基础组件。RAG 的每一步（文档解析、切块、向量化、检索、生成回答）都可能调用模型，都需要通过 LLM Client。
结构化输出在 RAG 中无处不在。文档解析的结果是结构化的、检索的结果是结构化的、最终生成的回答也可以是结构化的。
Prompt 模板库在 RAG 中有新的用途。文档切块的 Prompt、问题改写的 Prompt、答案生成的 Prompt，都需要模板化管理。
后端架构在 RAG 系统中直接复用。RAG 服务是后端架构中的一个新服务层，和行业分析服务并列。
所以 Week 2 不是孤立的一周，而是后续所有周的基础。地基打好了，上面盖什么楼都方便。地基不牢，后续每周都会感觉吃力。
自测问题
- 请不看任何资料，完整描述一次 API 调用的流程——从构造请求到处理响应，中间经过哪些环节？
- JSON Mode 保证的是什么？JSON Schema 保证的是什么？为什么两者需要配合使用？
- Function Calling 中，模型不直接执行函数，而是输出一个调用指令。这种设计的优势是什么？
- 你的 Prompt 模板库中，Prompt 是按什么维度分类的？为什么按用途分类比按技术分类好？
- 后端架构的分层设计中，路由层和服务层各自的职责是什么？为什么路由层不应该包含业务逻辑？
- 如果你要为 Week 2 的知识画一张体系图，中心节点是什么？哪些知识点是核心依赖？
- 在 4 小时的综合实战中，你认为最关键的环节是什么？如果时间不够只能保证一个环节做好，你选哪个？
- Week 2 的学习中，你觉得哪个知识点最有挑战？为什么？
- Week 2 的哪个知识点在实际工作中会被最频繁地使用？
- 如果有人问你”Week 2 到底学了什么”，你会用一段话怎么概括？
关键词
- Week 2 复盘：对六天学习内容的系统性回顾和整合
- 知识框架：将散落的知识点组织成有逻辑关系的体系
- 综合实战：4 小时内完成一个完整的行业分析系统
- 能力验证：通过独立完成项目来确认真正掌握了哪些技能
- 薄弱点识别：发现理解不够深入的知识点，明确后续复习重点
- Week 2 到 Week 3 衔接：理解 RAG 系统如何建立在 API 调用和结构化输出的基础之上
- 工程化思维：从”能用就行”到”稳定、可维护、可扩展”的思维转变
- 工具层/方法层/思维层：学习收获的三个层次
- 系统验收标准：判断综合实战产出的系统是否合格的标准
- 时间分配策略：在有限时间内高效完成项目的优先级排序方法