学前导读：综合项目这一章到底该怎么学
这一章不是继续堆术语，而是把前面学过的大模型概览、预训练、Prompt、微调、对齐和评估真正放进一个具体项目。
大模型项目最重要的能力，不是看到问题就直接微调，也不是所有任务都靠 Prompt 硬写，而是能判断：这个问题到底是任务表达不清、领域知识不足、行为风格不稳定，还是评估标准缺失。不同问题对应不同方案。
这一章在整个课程里的位置
第八 A 阶段的主题是理解大模型能力从哪里来，以及如何通过 Prompt、微调和对齐影响模型行为。综合项目是这一阶段的出口，要让你把这些概念变成可验证的工程判断。
你需要证明自己能围绕一个明确领域任务，设计 baseline，比较 Prompt、RAG 或微调方案，准备样本，记录效果，并说明为什么选择某条路线。
这一章真正要解决的问题
这一章要回答五个问题：如何把一个大模型项目收窄成明确领域和任务；如何先做 Prompt baseline，而不是直接上复杂方案；如何判断该用 Prompt、RAG 还是微调；如何准备数据和评估集；如何展示模型效果、失败案例和方案取舍。
新人最容易犯的错误，是把“模型答得不好”直接理解成“需要微调”。真实项目里，很多问题是资料缺失、Prompt 表达不清、输出格式没约束、评估样例不足或应用流程设计不合理。
新人推荐学习顺序
建议先选一个小而明确的领域任务，例如课程问答分类、章节摘要结构化、客服意图识别、合同条款分类或学习建议生成。然后写 Prompt baseline，收集一组测试样例，记录成功和失败。接着判断失败类型：如果是上下文资料不足，考虑 RAG；如果是固定格式和风格不稳定，考虑微调；如果是任务本身模糊，先重写任务定义和评估标准。
学这一章时要抓住的主线
这一章的主线可以概括为：大模型项目不是“选最强模型”，而是围绕任务、数据、方法和评估做取舍。
看懂这条线后，你会知道为什么项目报告里要写“为什么不用另一种方案”。这类取舍说明会比单纯展示效果更能体现你的大模型工程能力。
这个项目真正要练什么
这个项目真正训练四件事：把任务收窄成明确领域，先建立 Prompt baseline，判断是该继续优化 Prompt、接 RAG 还是做微调，最后用评估集和失败案例证明方案有效。
如果选择领域微调项目，需要特别关注数据质量、训练/验证切分、格式稳定性和与 baseline 的对比。如果选择 RAG 方案，需要关注资料来源、切分、检索、引用和无答案处理。如果选择 Prompt 方案，需要关注结构化输出、示例设计和版本迭代。
这一章和后面阶段的关系
这一章会直接连接第八 B 阶段的 LLM 应用开发与 RAG。你在这里建立的方案选择能力，会在后面扩展成知识库问答、智能助 手、工具调用和 Agent 系统。
如果这一章没学稳，后面常见的问题是：看到问题就堆框架；把微调、RAG 和 Prompt 混成一类；没有评估集；无法解释方案为什么有效；项目展示只有最终答案，没有失败分析和取舍过程。
新人和进阶学习者怎么读
新人第一次学这一章时，先抓住主线和最小可运行例子。你不需要一次理解所有细节，只要能说清楚这一章解决什么问题、输入输出是什么、最小项目怎么跑起来，就可以继续往后走。
有经验的学习者可以把这一章当成查漏补缺和工程化练习：关注边界条件、失败案例、评估方式、代码可复现性，以及它和前后阶段的连接。读完后最好能把本章内容沉淀到自己的作品 README 或实验记录里。
学习时间与难度建议
| 学习方式 | 建议投入 | 目标 |
|---|---|---|
| 快速浏览 | 20～30 分钟 | 看懂本章解决什么问题，知道后面会用到哪里 |
| 最小通关 | 1～2 小时 | 跑通一个最小例子，完成本章小项目出口 |
| 深入练习 | 半天～1 天 | 补充错误分析、对比实验或项目 README 记录 |
本章自测问题
| 自测问题 | 通过标准 |
|---|---|
| 这一章解决什么问题？ | 能用一句话说明它在整门课里的位置 |
| 最小输入输出是什么？ | 能说清楚例子需要什么输入，会产生什么结果 |
| 常见失败点在哪里？ | 能列出至少一个报错、效果差或理解偏差的原因 |
| 学完后能沉淀什么？ | 能把本章产出写进项目 README、实验记录或作品集 |
本章小项目出口
学完这一章后，建议完成一个“领域任务大模型方案对比项目”。项目至少包含任务定义、样例数据、Prompt baseline、失败分析、改进方案、评估结果和结论说明。
最小版本可以只比较两个 Prompt 版本；进阶版本可以比较 Prompt、RAG 和小规模微调；作品集版本需要把方法取舍、评估指标、失败案例和下一步计划写清楚。
Debug 侦探案件
| 案件 | 内容 |
|---|---|
| 案件名 | JSON 漂移事件 |
| 案发现场 | LLM 输出有时少字段、有时多解释，结构化结果无法稳定解析。 |
| 侦查步骤 | 固定 10 个输入，保存原始输出，用 schema 校验并比较 Prompt 版本。 |
| 结案证据 | prompt_eval_cases.csv、Prompt 版本表、schema 通过率。 |
项目练习不要只保留成功截图。至少挑一个真实失败样本，按“现象、线索、嫌疑原因、侦查步骤、修复动作、回归检查”写进 reports/failure_cases.md，这样项目会更像真实工程作品。
项目交付物标准
每个大模型综合项目都建议按同一套作品集标准交付，而不是只展示一次模型回答。最小交付物应该包括：一份 README、一条可复现运行命令、一组示例输入输出、Prompt 版本记录、一次失败样本分析，以及下一步改进计划。
| 交付物 | 最低要求 | 进阶要求 |
|---|---|---|
| README | 写清项目目标、运行方式、模型和示例 | 增加方案取舍、成本估算、评估和复盘 |
| 示例输入输出 | 至少保留 1 个固定测试样本 | 保留 Prompt、RAG、微调或规则方案对比样本 |
| 评估记录 | 写清用什么标准判断输出好坏 | 加入固定评估集、人工评分和失败类型统计 |
| Prompt/数据记录 | 保存 Prompt 版本或训练样本格式 | 增加 schema、校验、数据质量和安全边界说明 |
| 展示材料 | 截图或短 GIF 证明能运行 | 做成可讲解的大模型方案选择案例 |
做大模型项目时最重要的不是“模型答得像不像”，而是能讲清楚：问题到底来自任务表达、知识缺口、格式稳定性还是评估缺失，以及为什么选择当前技术路线。
过关标准
这一章结束时，你应该能围绕一个领域任务建立 baseline，能判断 Prompt、RAG 和微调各自适合解决什么问题，能准备小型评估集，能用失败案例解释模型局限，能把技术方案取舍写成项目报告。
如果你能清楚说明“为什么这里不直接微调”“为什么这里需要 RAG”“为什么这个 Prompt 改动有效”，就达到了大模型原理与微调阶段的作品集出口标准。
版本路线建议
| 版本 | 目标 | 交付重点 |
|---|---|---|
| 基础版 | 跑通最小闭环 | 能输入、能处理、能输出，并保留一组示例 |
| 标准版 | 形成可展示项目 | 增加配置、日志、错误处理、README 和截图 |
| 挑战版 | 接近作品集质量 | 增加评估、对比实验、失败样本分析和下一步路线 |
建议先完成基础版，不要一开始就追求大而全。每提升一个版本，都要把“新增了什么能力、怎么验证、还有什么问题”写进 README。