Part 7. 项目¶

Section ID: P7-index Version: v2026.07.20

Part 7 是把前面介绍过的内容放进真实输入、代码执行、输出比较和错误解释里来实作的区段。这里不会继续拉长新的理论，而是把已经学过的问题设定、比较、结构选择、执行记录判断放进同一个项目里一起执行并解释出来。

这个 Part 尤其适合下面这些读者。

已经能读 AI 说明，但还没怎么亲手改输入、比较结果的读者
跟过示例代码，却仍然不清楚 为什么会出现这个输出、应该先检查什么 的读者
知道 LLM、RAG、agent，但想把执行日志和质量复核的读法整理清楚的读者

项目必须留下的执行证据¶

Part 7 的目的不是完成一个庞大的服务，也不是停在形式化地照着做一遍。它更明确地把 亲手运行并重新阅读，从而把理解固定下来 这件事放在中心。

用一句话收束问题，并把输入单位写清楚
先运行基准点（baseline），给比较留下地板线
真正执行代码，并把输出表、预测结果、错误案例一起读
不把结果停在 对了/错了，而是继续解释为什么会这样
把失败和局限整理成下一轮实验要改的事项
在需要时连同执行记录、评估笔记、运营日志一起复核

也就是说，Part 7 的核心是 把已经理解的内容变成可执行的实作和可重读的复核记录。

这里重要的一点是，不要让一句 我做过项目了 被单个代码文件或短暂的成功画面取代。在 Part 7 里，尽可能要把下面这些执行证据和复核记录真实地一起整理进项目文档。

执行与复核要素	为什么需要
问题与输入定义	因为要在执行前先固定到底要解决什么、什么算一条输入单位。
基准点结果	因为要为“变好了”留下可以解释的地板线。
比较表与错误案例	因为要重新阅读单一分数看不见的失败结构。
检索依据与选择依据	因为要先验证回答之前到底用了什么依据。
执行记录与权限状态	因为要追踪 agent 按什么顺序行动、又在哪一步停下。
故障记录与下一步动作	因为要把部署后的失败与下一轮修改动作分开留下。

换句话说，Part 7 更严格追问的不是 你是不是做出了模型，而是 你到底亲手运行了什么、确认了什么、接下来哪里要再改。

Part 7 的综合训练结构¶

Part 7 会把同一个项目按 问题、baseline、比较、结构、依据、执行记录、运营回顾 这些判断轴重新阅读。各节会从不同角度把同一份项目文档里必须一起留下的内容显出来。

综合训练轴	这里要一起读什么
问题与输入定义	什么算一条单位、baseline 怎样设、回顾第一句会在哪里变化
比较与错误解释	比较表、错误案例、下一问题怎样作为同一束留下
结构与学习解释	输入结构、学习曲线、失败拆解怎样连起来
依据与执行记录	检索依据、工具调用、审批状态、blocked 状态怎样一起阅读
运营与迭代改进	部署确认、故障记录、下一步动作怎样回到下一轮实验

先把这套结构抓住，Part 7 就会更像 把同一个项目按多个判断轴重新阅读的 Part，而不是 示例很多而分散的 Part。

一旦缺失就会马上摇晃的轴	为什么重要
问题与输入单位	因为如果“一条样本”本身不稳，后面的比较也会一起摇晃。
baseline 与比较表	因为“变好了”只能放在明确的比较上解释。
执行记录与失败记录	因为这样能避免 LLM、agent、部署实作最后只剩答案示例或成功画面。

实作轴与代表位置¶

实作轴	这里要重新抓住的感觉	在 Part 7 里直接执行的代表位置
问题与比较实作	问题设定、baseline、预处理、比较实验	`P7-1.1` 到 `P7-2.3`
结构与学习解释	输入结构选择、学习结果解释、错误阅读	`P7-3.1` 到 `P7-4.3`
RAG 与 agent 实作	依据、权限、执行记录	`P7-5.1` 到 `P7-6.3`
部署与运营检查	部署确认、故障记录、下一步动作优先级	`P7-7.1` 到 `P7-7.3`

这张对应表之所以重要，是因为 Part 7 不是额外拉出一大段新理论的 Part，而是把 问题设定 -> 比较 -> 结构解释 -> 执行记录 -> 运营回顾 绑成一条实作流程的 Part。只要把当前卡住的点分成比较设计问题、结构或学习解释问题、或者依据、工具、运营问题，项目记录本身就会更快收束到真正该检查的地方。

实作记录的共同要素¶

即使每一节的代码块不同，Part 7 的执行记录大体上也会留下相近的要素。

记录要素	应该留下什么
问题	用一句话固定这次执行要确认什么。
输入	留下读取的是哪个 CSV、文档、日志或工具状态。
执行	留下实际运行了什么，例如 Python 示例、比较表、检索步骤或工具调用。
输出	留下要解释的对象，例如执行摘要、预测结果、错误案例或失败记录。
解释	说明这个输出支持什么判断。
再检查	留下下一次要改的值、要重看的样本、保留或失败状态。

关键不在于停在 代码跑起来了。Part 7 更重视的是 结果该在哪里读、接下来该重新检查什么。

如果缩到仓库层面，开始动作甚至可以短到下面这样。

1	`.venv/bin/python`

而且，各节代码块里使用的 CSV 和记录文件都集中在 docs/assets/part-07/ 下，只要先确认读的是哪一个文件，实作上下文就会清楚很多。

打开项目的问题¶

项目应该从哪里开始？
真实输入应该怎样切成一个样本单位？
baseline 和改进应该怎样比较？
在深度学习项目里，什么需要用眼睛确认？
在 RAG 和 agent 项目里，什么应该算质量标准？
在部署与运营里，需要留下什么样的失败记录？

如果把这些问题换成真实项目文档的标准，就会变成下面这样。

项目阶段	最小文档元素
问题设置	一句话目标、要确认的标准
输入整理	数据、文档、工具、约束条件
基准点	最简单的比较标准及其结果
执行	代码、输出、中间产出物
评估	自动检查、人工复核、比较笔记
运营回顾	失败记录、下一步改进顺序

如果再把这些最小文档元素改写成 Part 7 的真实项目轴，也可以读成下面这样。

项目轴	代表执行场景	这一阶段必须确认什么
分析起点	看表、做摘要计算、基准线比较	输入单位怎样被分组、先出现了什么差异
基准点比较	运行基准模型、读比较表、看错误案例	“变好了”这句话在实际比较里是不是真的成立
结构选择	比较输入结构、选择模型结构、读学习曲线	为什么选这个结构、它又是在哪里摇晃的
RAG	比较检索候选、选择依据、复核回答	能不能先读依据和检索失败，再去看回答
agent	计划、工具调用、审批、blocked 状态复核	执行路径和失败处理规则是否可见
部署与运营	部署确认、状态检查、故障回顾	服务是否真的稳定、下一步动作是什么

如果把每个轴先抓住的核心问题再写短一点，可以变成下面这样。

项目轴	最先要确认的问题	为什么需要这个问题
分析起点	`什么被当成了一条单位？`	因为样本单位一旦摇晃，后面的比较也会一起摇晃。
基准点比较	`最简单的标准能走到哪里？`	因为要解释“变好了”，必须先有地板线。
结构选择	`为什么这个输入要选这个结构？`	因为应该先看见选择理由，而不是只看模型名字。
RAG	`用了哪一份文档当依据？`	因为要能之后再验证，必须先留下依据而不是只留回答。
agent	`按什么顺序用了哪些工具？`	因为在解释成败之前，必须先看见执行路径。
部署与运营	`发生了什么失败，接下来改什么？`	因为在运营里，下一步动作比完成报告更重要。

小型项目必须收住的执行边界¶

这个 Part 会处理下面这些范围。

怎样设定项目目标
输入与输出定义
baseline 与比较
结果与局限记录
RAG、agent、部署项目的基本文档结构

这个 Part 不会把 实战的全部 一次讲完，但会明确覆盖 进入实战前必须亲手运行并重新阅读的场景。这一 Part 的正文主轴是 问题与输入定义、基准点与比较、错误案例与复核、RAG 与 agent 执行记录、部署与失败回顾。权限、运营、失败应对的大图景，则会继续在正文里的 P7-6.2 权限与日志复核、P7-7.1 部署确认与状态检查、P7-7.2 故障记录与下一轮计划中展开。

特别是，这个 Part 会一直维持下面这些区分。

分析项目：问题、输入单位、摘要值、比较表是中心
模型项目：baseline、预测结果、错误案例、修改优先级是中心
RAG 与 agent 项目：依据文档、工具结果、执行记录、失败日志是中心

这个区分不只是类型分类，也是决定应该先整理什么记录的标准。

在分析项目里，问题与输入单位 先于摘要值。
在模型项目里，比较行 与 错误样本 先于 accuracy。
在 RAG 项目里，检索依据 与 回答状态 先于回答本身。
在 agent 项目里，审批状态 与 下一步动作 先于成功/失败。
在部署项目里，故障记录 与 下一步动作 先于部署完成。

Part 7 会把这些例子保留在各轴正文的执行场景里。更重要的是，要直接留下 怎样阅读真实执行结果。比起照着敲完就结束的示例，输入一变、输出与解释也跟着变化的实作更重要。

这一 Part 不会直接收束的扩展课题¶

Part 7 把重点放在项目入门与综合训练上，因此不会在这里直接收束下面这些课题。

团队级协作文档与实验追踪系统应该怎样设计？
更大的数据集与更长的运营日志，应该按什么标准管理？
部署自动化与权限复核应当记录到什么阶段？

换句话说，Part 7 闭合的是 如何开始并回顾一个项目的最小结构，而不是把所有实务系统都讲完。

读完这一 Part 后应该留下的理解¶

读完 Part 7 之后，读者应该留下大致下面这些感觉。

项目应该在实现之前先定好问题与基准点。
如果输入单位和地板线摇晃，后面的结果解释也会一起摇晃。
没有 baseline 比较与改进比较的模型结果，解释会很弱。
在 LLM 项目里，不只是回答示例，检索失败、工具失败、权限、日志也都要一起读。
项目回顾不是隐藏失败的文档，而是为下一轮准备的文档。

如果把这五行压成最短形式，就会变成下面这一句。

项目不是把代码跑一次，而是留下能让人重新读懂为什么会得到这个结果的记录。

项目记录的共同标准¶

Part 7 里的各个项目，尽可能都按下面这条流程来整理。

问题定义
数据或输入
方法
实现
结果
局限与改进点
来源与参考资料

这个格式不是机械模板，而是让项目可以被再次执行、再次阅读的最小共同结构。不过在实际正文里，应该先看到 执行场景，再看到格式名称。比如结果部分里，比起单独一行分数，更应该先看到比较表和错误案例；实现部分里，比起一大段代码，更应该先看到输入和输出是怎样变化的。

在生成式 AI 相关项目里，下面这些项目也会经常额外出现。

依据文档或检索结果
工具调用结果或执行日志
自动评估结果
人工复核笔记
失败时的执行记录或替代动作记录

如果把这个共同标准重新读成真实记录，就会变成下面这样。

文档问题	要看的记录	为什么要看这个记录
想做什么？	目标句、计划步骤、项目笔记	因为如果没有问题与计划，就只会剩下执行日志，目的会消失。
放进去了什么？	数据表、文档片段、工具列表	因为输入缺失时，同一个项目就无法再次执行。
怎样比较的？	基准点、比较表、评估记录	因为“变好了”的说法必须通过同一标准来解释。
依据是什么？	选择依据、检索候选	因为 RAG 与 agent 的结果之后还要能重新验证。
停在了哪里？	卡住状态、依据不足状态、失败状态	因为只有留下失败点，下一轮才有出发点。
下次要改什么？	回顾摘要、改进计划	因为回顾不能停成备忘，而要通向下一步动作。

如果再把这些问题缩成更实战的检查，也可以变成下面这样。

项目轴	薄弱实作最容易漏掉什么	好的实作会先留下什么
分析	只有结果数字	问题、输入单位、比较表
模型	只有 accuracy	baseline、错误样本、比较理由
RAG	只有答案	依据文档、回答状态、缺失依据
agent	只有成功/失败	工具顺序、审批状态、卡住点
部署	只有发生过故障	故障类别、优先级、下一步动作

完成标准¶

能把项目整理成问题、输入、实现、结果、回顾的流程。
能通过真实比较结果说明 baseline 与改进模型的差别。
能在 RAG 与 agent 项目里把质量视角和运营视角一起读出来。
能把失败记录与下一步改进计划留在项目结果里。

如果压到最短，Part 7 的完成标准可以收成下面这一句。

应该能把自己真正跑过的项目留下可再次执行、可再次解释的记录。

这一 Part 读完后应该留下的判断标准¶

如果读完 Part 7 之后，下面这些标准还没有真实地留在记录里，说明这一 Part 的实作主轴还没有闭合得足够好。

结果数字留下了，但 baseline、错误案例、回顾笔记没有一起留下
说明 RAG 或 agent 时，依据记录、执行记录、权限记录没有一起留下
部署后该检查什么、什么应当算故障记录，这个标准开始摇晃

这时，比起继续往上堆新功能，更应该先把 问题 -> 执行 -> 评估 -> 回顾 这条结构重新固定回来。

检查清单¶

能不能把项目目标再用一句话写出来？
能不能立刻说出 baseline、比较表、错误案例、失败记录里缺了哪一个？
能不能在 RAG 与 agent 项目里分开阅读依据、工具、权限记录？
能不能在每个项目轴里留下给下一轮用的回顾句？

来源与参考资料¶

这个文档是整理 Part 7 目的与学习路径的内部概览，不直接引用外部资料。