Part 7 收尾：项目整理¶
Section ID:
P7-summaryVersion:v2026.07.20
Part 7 是把前面介绍过的内容放进真实项目执行与解释里来实作的区段。这个 Part 的核心，不是完成大型服务，而是把问题设定、比较、结构解释、执行记录、运营判断放进同一个项目里一起整理，并能解释 为什么会得到这样的结果。
这个项目 Part 尤其会同时确认两件事。
- 能不能解释这个概念？
- 能不能通过真实输入和输出变化来确认这个概念？
也就是说，这个 Part 是把 我知道了 变成 我亲手跑过、比较过，也读过失败 的区段。
绑成可以反复执行的项目记录¶
Part 7 的目的，是把整本书里学到的概念重新绑进真实项目执行与复核结果里，让下一轮学习变成读者自己也能反复进行的形式。
- 问题设定、baseline、预处理、比较实验，应该一起留在同一份文档里。
- 输入结构、学习结果解释、依据确认、执行日志，应该连成同一条判断链。
- 部署与运营判断也不该被放到最后当附录，而应该直接作为项目记录的一部分留下。
应该留下的说明能力¶
完成这个 Part 之后，你应该能解释：怎样把问题定义、baseline、结果、失败记录、下一步改进计划，留成一组真实的执行与比较结果。
这一 Part 处理的核心结构¶
Part 7 的整体结构，是按 同一个项目里哪些判断要素必须一起留下 来组织的。
| 要一起阅读的结构 | 为什么要绑成一束 |
|---|---|
| 问题、样本单位、baseline、比较实验 | 因为比较了什么、为什么算改进，必须在同一处关上。 |
| 输入结构、学习曲线、错误案例 | 因为结构选择理由与失败原因属于同一个解释束。 |
| 检索依据、执行日志、审批策略 | 因为 RAG 与 agent 的质量，只有把回答、依据、执行路径一起看才会显出来。 |
| 部署、日志、失败应对、回顾文档 | 因为运营记录不是项目解释之外的附录，而是判断标准本身。 |
如果按 执行与复核 的标准重新绑这条流程，就会变成下面这样。
| 项目轴 | 必须留下的核心执行与复核要素 | 为什么需要这个要素 |
|---|---|---|
| 分析起点 | 输入单位定义、摘要表、比较表 | 只有把什么算一条单位、读到了什么差异留下来，下一轮探索才接得上。 |
| 基准点比较 | 执行摘要、逐样本比较表、错误案例列表 | 只有把执行结果和错误案例一起留下，改进才解释得起来。 |
| 结构选择与学习复核 | 学习曲线、评估记录、错误样本 | 因为必须重新读为什么这个结构摇晃了，而不只是看分数表。 |
| RAG | 检索记录、选择依据、依据回答记录 | 因为必须先检查检索依据与连接方式，再去看答案本身。 |
| agent | 计划列表、执行记录、审批状态、blocked 状态 | 只有把计划和真实执行路径分开看，卡住点才追得出来。 |
| 部署与运营 | 故障记录、状态检查、改进计划 | 只有把失败留下并把下一步动作分开，运营回顾才会累积。 |
如果再把这张表压到最短，各轴最先不能丢掉的记录就是下面这些。
| 项目轴 | 最先不能丢掉的执行证据 |
|---|---|
| 分析起点 | 一句问题与输入单位定义 |
| 基准点比较 | 最简单的基准结果 |
| 结构选择与学习复核 | 代表性错误样本与学习/评估记录 |
| RAG | 依据文档与回答状态 |
| agent | 工具顺序与审批状态 |
| 部署与运营 | 失败类别与下一步动作 |
虽然项目主题不同，但必须留下来的问题其实是一样的。
- 想解决什么？
- 输入与输出是什么？
- 数据是怎样准备的？
- baseline 是什么？
- 结果是怎样确认的？
- 失败与局限是什么？
- 下一步改进应该从哪里开始？
必须记住的概念¶
Part 7 里一定要带走的视角如下。
| 区分 | 要记住的视角 |
|---|---|
| 问题定义 | 项目应当先把问题说清，再谈实现。 |
| 基准点 | 没有 baseline，就连“变好了”这句话也会变弱。 |
| 数据 | 必须把输入、输出、切分标准写清，比较与解释才成立。 |
| 评估 | 项目结果必须同时通过数字与案例来读。 |
| 回顾 | 把失败、遗漏、模糊处留下来，本身就是项目文档的核心。 |
| 可复现性 | 必须留下输入、代码、输出记录，项目才能再次运行。 |
| 服务视角 | 在 LLM 项目里，不只是回答质量，检索失败、权限、延迟、日志也要一起看。 |
如果把这个视角再往实务方向推一步，会看到很多时候 用了什么输入、做了什么比较、失败发生在哪里 比 最后结果数字是多少 更重要。
- 在基准点比较项目里，不只是
accuracy，还必须留下哪些样本错了。也就是说，像错误案例列表这样的记录必须存在，下一轮比较才活得起来。 - 在文本项目里，不只是
对/错，token 列表、token coverage、词表外 token 也必须留下。你必须看见什么输入被切开了、什么词没进来，才能把预处理问题再找回来。 - 在 RAG 项目里，不只是
回答，还必须留下检索候选、回答状态、被选中的依据文档。因为质量复核的起点不是答案本身，而是依据选择过程。 - 在 agent 项目里，不只是
成功/失败，还必须留下权限、审批状态、下一步动作。只有知道出现过什么审批与阻断，执行路径才能被重新设计。 - 在部署项目里，不只是
部署完成，还必须留下故障记录、优先级、下一步动作。因为运营记录里，下一步动作顺序比完成声明更重要。
这些例子轴已经在 Part 7 里被充分展开。更重要的是，让各节正文示例直接呈现出 问题 -> 执行 -> 比较 -> 解释 -> 回顾 这条流。
容易误解的地方¶
这个 Part 里尤其要小心下面这些误解。
- 很容易以为项目只需要留下
成功案例。 - 很容易误以为一个结果数字高了，项目就算做得好。
- 运行过一次示例，并不等于立刻理解了真实结构。
- 代码执行过了，与问题定义本身合理，不是同一回事。
- 在 LLM 项目里，一两次回答看起来不错，并不代表评估已经结束。
- 如果不记录运营失败，下一轮改进会很困难。
也就是说，项目不应该只证明 它曾经成功一次，而应该证明 下一轮是可能继续的。
项目回顾要重新确认的执行边界¶
Part 7 把重点放在解释项目入门结构上。因此，目标设定、实现、评估、回顾、运营记录会处理，但不会在这里把大规模基础设施与长期运营体系全部讲完。
这一 Part 不会直接收束的扩展课题¶
Part 7 不会在这里直接收束下面这些课题。
- 下一个真实项目要扩展什么主题？
- 评估与失败记录要怎样长成团队级文档？
- 运营与部署要自动化到什么程度，人工复核又放在哪里？
也就是说，Part 7 与其说是这本书的终点，不如说更接近后续自主项目的起点。
而且这些问题其实已经在 Part 7 里以很小的形式被预告过了。
- 基准点比较可以长成更大的实验追踪系统。
- token coverage 与 OOV 记录可以连到更精细的 tokenizer 实验。
- RAG 中的依据不足状态记录，可以长成更严格的评估流水线。
- agent 里的运营保留与需要审批的工具记录，可以扩成真实运营策略文档。
- 部署失败记录，会成为团队级故障回顾文档的种子。
进入下一阶段学习前要确认的问题¶
- 能不能用一句话解释每个项目的问题定义与输出标准？
- 有没有把 baseline 与改进项分开记录？
- 数据准备与切分过程能不能再次执行？
- 结果有没有同时通过数字、比较表、案例来读？
- 有没有留下失败案例与改进计划？
- 如果是 LLM 项目，有没有同时检查检索、工具调用、权限、日志、失败应对？
真正再次检查项目文档时，下面这些产出物检查也应当一起确认。
- 有没有执行摘要或回顾摘要？
- 有没有比较表、测试记录、评估记录这类逐样本记录？
- 有没有选择依据、检索候选这类依据记录？
- 有没有执行记录与故障记录这类运营流程记录？
如果把这个检查再压短一点，就会变成下面这样。
| 先检查什么 | 为什么重要 |
|---|---|
| 问题还在不在 | 为了重新找回项目当时想验证什么 |
| baseline 还在不在 | 为了重新找回解释改进时的地板线 |
| 错误或失败还在不在 | 为了给下一轮建立出发点 |
| 依据与执行路径还在不在 | 为了重新验证 RAG 与 agent 的结果 |
| 下一步动作还在不在 | 为了避免回顾只停成一条备忘 |
会留在项目文档里的最小步骤¶
Part 7 里反复执行过的实作，在下一次真实项目里大多也会以几乎相同的最小步骤再次出现。
- 用一句话写下问题。
- 先固定输入文件或输入单位。
- 先运行 baseline。
- 在同一输入上比较改进项或后续结构。
- 确认执行摘要、比较表、错误案例、失败记录里到底留下了什么。
- 按
事实 -> 解释 -> 下一问题或失败类别 -> 下一步动作的形式留下回顾。
就算只守住这六行，Part 7 的核心也大多能重新活起来。
如果把同一套步骤重新连回 Part 7 里的代表位置，可以读成下面这样。
| 执行阶段 | 代表 Section |
|---|---|
| 固定问题与输入单位 | P7-1.1 |
| 把 baseline 与比较表放在一起阅读 | P7-1.2, P7-2.2 |
| 把结构与失败原因放在一起解释 | P7-3.2, P7-4.2 |
| 把依据与执行日志放在一起留下 | P7-5.2, P7-6.2 |
| 把运营失败重新送回下一轮实验 | P7-7.2 |
换句话说，当前卡住的阶段可以直接去对照承担相同角色的代表节。尤其把练习节也一起看时，回到的就不只是读说明，而是直接回到改值和重写结果的层级。
收尾¶
项目 Part 的目的，不是做出一个很大的产出物。相反，它更重要的作用，是通过真实执行与比较把 我已经理解了什么、什么地方还不稳定 显露出来。
完成这个 Part 之后，读者应该能够自己设计下一步。
- 扩展到更大的数据集
- 接上更合适的评估指标
- 对 RAG 质量做比较实验
- 更精细地整理 agent 权限与日志策略
- 把运营成本与失败应对拆成独立文档
也就是说，Part 7 不是结束，而是通向 从现在开始自己做项目、再通过项目重新学习 的起点。
最短地说，Part 7 的结论可以收成下面这一句。
好的项目文档，不是先留下跑过一次的代码，而是先留下能让人重新读懂为什么会得到这个结果的比较与记录。
这份总结里留下的再检查标准¶
当一个项目做完之后，如果开始弄不清究竟该留下什么，就足够重新看看下面这些标准是否真的作为记录留下来了。
- 做了实现，但已经不确定问题、baseline、失败记录是否一起留下
- 想重新整理 RAG、agent、部署项目之间共同的记录要素
- 想在进入下一个真实项目之前，先整理应该留下什么样的回顾句
这时，与其先重新散回各个细节节，不如先确认 解决了什么、留下了什么记录、下一步要改什么。
如果把这份总结先压成三行，最先要确认的标准就是下面这些。
- 我当前的项目里还留着一句问题和输入单位吗？
- baseline 和比较结果还留在同一份输入上吗？
- 错误案例或失败记录有没有和下一步动作一起留下？
检查清单¶
- 能不能把各个项目轴最先应该留下的记录，再各自写成一句？
- 能不能解释为什么 baseline、比较表、失败记录是 Part 7 全体工作的共同标准？
- 能不能重新说清为什么 RAG、agent、部署工作都需要运营视角记录？
- 能不能整理出会立刻带进下一个真实项目的回顾格式？
来源与参考资料¶
这个文档是对 Part 7 全部内容的内部总结，不直接引用外部资料。