AI Projects Self-Study Hub

这本书不是项目收藏夹，而是一个可执行的自学路线。

你给我的那批项目本身都不错，但如果只是把仓库链接堆在一起，基本学不会。真正需要的是三件事：

先做哪个，后做哪个
每个项目第一周到底该做什么
怎么验证自己不是“看懂了”，而是真的会了

这本 mdBook 就是为这个目的重做的。

这本书解决什么问题

很多 AI 项目自学最后都会卡在同一个地方：

README 看了，但不知道先跑哪一部分
notebook 跑通了，但说不清核心链路
项目做完了，但不知道自己到底学到了什么

所以这本书的结构不是“仓库介绍”，而是四层：

导学页：这个项目值不值得现在做
7-Day Plan：第一周每天具体做什么
自测题：检查你是否真的掌握
参考答案：用来核对理解，不是先看的

三条主线

1. RAG / Retrieval Systems

适合你如果现在最想做：

企业知识库问答
检索增强生成
deep research
多步搜索

入口：

RAG Systems Track

2. LLM From Scratch

适合你如果现在最想真正搞懂：

tokenizer
transformer
pretraining
小模型从零训练

入口：

LLM From Scratch Track

3. Alignment / Agent RL

适合你如果已经有一点模型基础，想进一步理解：

SFT
preference optimization
GRPO
agent reinforcement training

入口：

Alignment / Agent RL Track

4. FastAPI / Full Stack Web

适合你如果现在想真正补齐：

FastAPI 后端
前端调用 API
登录认证
数据库和 CRUD

入口：

FastAPI / Full Stack Web Track

先看什么最有用

如果你只准备开始一个项目，不要乱翻。

按这个顺序：

看怎么真正学会一个项目
选一条 track
打开对应项目导学页
接着做对应 7-Day Plan

如果你现在就想从最稳的入口开始，直接去：

rag-from-scratch

这本书里最值得你反复用的部分

项目导学

它回答的是：

这个项目最适合学什么
为什么现在做它
先看什么
第一周最小任务是什么

7-Day Plans

它回答的是：

今天具体做什么
今天结束时应该产出什么
哪些任务是第一轮必须完成的

自测题

它回答的是：

你会不会解释
你会不会比较
你能不能自己复盘一个系统

项目索引

最后一个提醒

这本书最核心的目标不是让你“知道更多名词”，而是让你真的能做到下面这几件事：

讲清一个项目的最小主链路
改一个局部模块并观察变化
比较两个相邻项目在架构上的差别
用自己的话复盘为什么某个设计有效

如果你做到了，这套资料才算有用。

怎么真正学会一个项目

这页不是资料导航，而是方法页。

很多人做项目学不会，不是因为资料不够，而是因为顺序错了。最常见的错误有三个：

一上来就试图看懂全部代码
只看 README，不跑最小链路
一直抄仓库，不做自己的小改动

你应该反过来。

正确顺序

第 1 步：先找到最小主链路

你先不要问“这个仓库全部做了什么”，先问：

最小输入是什么
中间经过哪几个关键步骤
最后输出是什么

如果你连这条主链路都讲不清，就还没开始真正理解。

第 2 步：先跑通，再观察

第一遍不求改代码，只求跑通。

你至少要确认：

代码真的能运行
你知道每一步的输入输出长什么样
你知道哪里最值得改

第 3 步：只改一个变量

不要第二天就改成“自己的大项目”。

第一轮最有价值的修改通常只有这些：

换一份小数据
改一个 prompt
改 retrieval 的 top-k
改 chunk size
改一个训练超参数

如果一个改动都没做过，你其实还是在“看别人做项目”。

第 4 步：写最短总结

做完一个项目后，你最少要写下这四件事：

这个项目在解决什么问题
它的最小可运行链路是什么
它最关键的两个设计选择是什么
如果你重写，第一层先改哪里

每种项目应该怎么学

RAG 项目

重点不是“会调 API”，而是：

你的检索内容对不对
召回出来的内容够不够
回答是不是被 context 真正约束住了

你必须盯这些中间产物：

query
retrieved chunks
reranked results
final prompt
final answer

LLM From Scratch 项目

重点不是“模型跑起来了”，而是：

tokenizer 在干什么
attention 输入输出怎么变
loss 是怎么下降的
数据、模型、训练循环之间怎么接起来

你至少要能解释：

一个 batch 怎么被送进模型
logits 是怎么来的
loss 是怎么算的

Alignment / Agent RL 项目

重点不是“训练名字记住了”，而是：

reward 或 preference 信号从哪里来
policy 为什么会朝某个方向更新
rollout 在 agent setting 里为什么更难

你至少要能说清：

SFT 和 preference optimization 的区别
为什么 agent RL 比单轮回答训练更不稳定

自学时最该做的三种笔记

1. 主链路图

写成一行就够：

input -> retrieve -> rerank -> build context -> generate -> evaluate

2. 实验记录

每次只记三件事：

改了什么
结果怎样
你觉得为什么

3. 失败记录

失败记录比成功总结更值钱。

你要记：

哪一步坏了
你原来以为会怎样
实际为什么不对

什么时候算“学会了”

不是你把仓库跑通了，而是你能做到下面至少两件：

不看仓库，自己复述最小架构
改一个关键参数并解释变化
用自己的小数据重跑
用自己的语言讲清这个项目和前一个项目的差别

如果做不到，说明你还在“浏览”，不是“掌握”。

学习主线

这部分按学习目标分三条线：

RAG Systems
LLM From Scratch
Alignment / Agent RL
FastAPI / Full Stack Web

RAG Systems

title: “Track 1: RAG Systems”

Track 1: RAG Systems

这条线解决的是：

怎么把外部知识接进 LLM
怎么让回答更 grounded
怎么从“简单问答”走到“复杂检索 + 推理 + 报告”

这不是按 star 排的，是按学习阻力排的。

每一站分别学什么

1. rag-from-scratch

你在这里学：

最基础的 RAG 主链路
retrieval 和 generation 怎么连起来
最小 notebook 级实验方式

做完应该能做到：

自己写一个最小检索问答 demo

2. complex-RAG-guide

你在这里学：

更复杂的 chunking
query rewriting
filtering
planning / execution
evaluation

做完应该能做到：

不再把 RAG 理解成“向量库 + prompt”这么简单

3. rag_techniques

你在这里学：

不同 RAG 技术点的横向比较
什么技术适合什么场景
怎么做实验而不是只会抄 pipeline

做完应该能做到：

你知道可以优化哪一层，而不是只会换模型

4. deep-searcher

你在这里学：

更产品化的 deep research 结构
private data search
更完整的配置、provider、vector DB 组合

做完应该能做到：

把 RAG 往“系统”而不是“demo”推进

这条线的核心知识图

从简单到复杂，可以理解成：

检索到上下文
把上下文喂给模型
判断上下文够不够
不够就改 query 或换 retrieval
对结果做过滤、校验、评估
最后做多步规划和报告生成

先别急着学的东西

如果你还没跑通第一个最小 RAG，不要急着碰这些：

agentic RAG
graph-based planning
很复杂的 reranking 组合
大而全的评估框架

先把主链路跑通。

这条线的完成标准

做到下面这些，才算真的学到：

你能解释 chunking 为什么会影响效果
你知道 retrieval quality 和 generation quality 不是一回事
你能比较简单 RAG 和复杂 RAG 的结构差别
你能自己做一个带引用或带 source attribution 的回答系统

建议产出

学这条线时，建议你最终自己做一个项目：

一个本地文档问答工具
一个课程笔记检索助手
一个 PDF / 网页混合检索问答器

要求不要大，但必须自己配数据、自己跑检索、自己看效果。

LLM From Scratch

title: “Track 2: LLM From Scratch”

Track 2: LLM From Scratch

这条线解决的是：

语言模型到底是怎么训练出来的
tokenizer、embedding、attention、loss、sampling 到底怎么串起来
为什么很多“会调 API”的人，其实并不真的理解模型本体

这条线的正确顺序

MiniMind
Stanford CS336

为什么先 MiniMind 再 CS336

因为：

MiniMind 更像低门槛实战入口
CS336 更像系统课程 + 工程作业路线

如果一上来就直接啃 CS336，容易被系统深度和工作量压住。

每一站分别学什么

1. MiniMind

你在这里学：

小模型从零训练的完整感
训练脚本、tokenizer、模型结构、推理脚本怎么配合
在个人机器资源有限的情况下，如何理解 LLM 训练流程

做完应该能做到：

你能讲清楚一个超小语言模型是怎么被训练和使用的

2. CS336

你在这里学：

language modeling 的系统知识
从 tokenizer 到 transformer 再到优化与系统层设计
真正课程级别的从零实现路径

做完应该能做到：

你不只是“知道 attention”，而是知道整条训练链路

这条线的重点

学这条线时，不要只看模型公式。

你要同时看三层：

数学和概念
代码实现
训练系统与工程代价

正确的学习顺序

建议按下面顺序啃：

tokenizer
embedding
self-attention
transformer block
language modeling loss
training loop
inference / generation
scaling 和系统问题

这条线的完成标准

做到下面这些，才算真的入门：

你能自己讲一遍 decoder-only LM 的主链路
你知道 pretraining 的输入输出到底是什么
你能读懂一个小模型训练脚本，不只会运行
你能指出 tokenizer、context length、batch、optimizer 在训练中的作用

建议产出

学完这条线，建议你自己做一个最小项目：

手写一个极小 decoder-only transformer
在小语料上训练
跑一个最简单的文本生成 demo

重点不是效果多强，而是你真的自己走过一遍。

Alignment / Agent RL

title: “Track 3: Alignment And Agent RL”

Track 3: Alignment And Agent RL

这条线解决的是：

预训练后的模型为什么还不够好用
怎么通过 SFT、偏好优化、RL 让模型更符合目标
多步 agent 为什么需要专门训练，而不是只靠 prompt

这条线的正确顺序

ModelAlignmentFromScratch
OpenPipe ART

为什么这样排

因为：

ModelAlignmentFromScratch 更像教学型、手写型 alignment 项目
ART 更像更现代、更框架化、面向 agent tasks 的训练工具

先理解单模型 alignment，再看 agent reinforcement，会稳很多。

每一站分别学什么

1. ModelAlignmentFromScratch

你在这里学：

SFT 在做什么
EI 在做什么
GRPO 在做什么
reward、sampling、training loop 怎么结合

做完应该能做到：

你知道“对齐”不是一句空话，而是一组具体训练方法

2. OpenPipe ART

你在这里学：

agent reinforcement training 的任务形式
多步任务、轨迹、奖励、优化之间的关系
为什么 agent RL 的难点和普通 SFT 不一样

做完应该能做到：

你能理解 agent 训练为什么要强调 interaction 和 trajectory

学这条线前你最好已经会

PyTorch 基础
transformer 基础
language model training loop 基础
最好已经做过一点小模型训练或至少认真看过 Track 2

这条线最容易误解的地方

误解 1

“SFT 就等于 alignment”

不对。

SFT 只是 alignment 里最基础的一层。

误解 2

“RLHF / GRPO 只是多一个 reward model”

也不对。

真正难的是：

样本怎么来
奖励怎么定义
训练稳定性怎么保证
多步任务怎么 credit assignment

误解 3

“agent 只要 prompt 写好就行”

不对。

多步 agent 在很多场景下确实会受训练方式影响。

这条线的完成标准

做到下面这些，才算真正入门：

你能说清 SFT、EI、GRPO 各自在优化什么
你知道 alignment 的目标不只是“让输出更像人”
你知道 agent RL 比普通 instruction tuning 多了什么难点
你能读懂一个最小的 alignment 训练脚本

建议产出

学完这条线，建议你写一篇自己的短总结：

pretraining 解决什么问题
SFT 解决什么问题
preference / policy optimization 解决什么问题
agent RL 为什么又是下一层

这篇总结会强迫你真的把概念区分开。

Track 4: FastAPI / Full Stack Web

这条线解决的是：

怎么把后端 API 真正做出来
怎么让前端和后端真实联动
怎么把认证、数据库、CRUD、部署这些基础能力接起来

如果你想从“会写一点 Python”走到“会做一个完整 Web 应用”，这条线很适合你。

为什么这条线对你现在很重要

你前面学的很多 AI 项目，本质上都需要产品外壳：

后端 API
用户系统
前端页面
数据存储
部署

如果这些不会，你就很容易一直停留在 notebook、脚本、demo。

而 FastAPI + 前端 这条线，会把你从“会跑 AI”推进到“会做产品”。

这条线最该学的东西

1. 后端结构

你要知道：

API router 怎么拆
schema 和 model 怎么分
service / crud / db session 怎么接

2. 前后端联动

你要知道：

前端怎么调后端 API
token 或 session 怎么传
表单提交以后数据怎么流到数据库

3. 用户系统

几乎所有真实产品都绕不开：

登录
注册
权限
用户数据隔离

4. 部署和环境

你要知道：

本地开发怎么跑
Docker 为什么存在
数据库和应用怎么一起启动

最小能力目标

学完这条线，你至少应该能自己做出一个很小但完整的 Web 应用，例如：

一个学习计划管理器
一个刷题笔记系统
一个文档问答前后端小产品

最小要求：

有前端页面
有 FastAPI 后端
有数据库
有至少一个真实的 CRUD 流程

第一轮不要急着做的事

先别急着追这些：

微服务
很复杂的权限系统
很重的前端状态管理
一堆第三方登录接入

第一轮重点是先把完整链路打通。

这条线的完成标准

做到下面这些，才算真正入门：

你能解释前端请求是怎么走到数据库的
你能自己加一个新 API 和对应页面
你能处理一个最基础的登录态
你能在本地把全栈系统跑起来

建议产出

学这条线时，最适合你的最终产出是：

一个给自己用的小产品

比如：

学习任务看板
AI 学习资料管理器
做题记录和复盘工具

这样你学到的不是“模板”，而是完整产品链路。

项目导学

从项目视角进入：

rag-from-scratch
Complex RAG Guide
RAG Techniques
DeepSearcher
MiniMind
Stanford CS336
ModelAlignmentFromScratch
OpenPipe ART
full-stack-fastapi-template

Project Guide: rag-from-scratch

原项目：

https://github.com/langchain-ai/rag-from-scratch

这页为什么值得看

rag-from-scratch 不是“RAG 仓库之一”，而是你最适合开始的那个。

原因很简单：

它足够轻
它的主链路清楚
你能很快把注意力放在真正重要的地方

如果你一开始就去做复杂 agent RAG，通常会学乱。你会看到很多组件，但不知道哪些才是第一性原理。

这个项目的价值就在于，它会逼你先把最小 RAG 想清楚。

你到底应该从它学到什么

不是“我会调一个 notebook”。

你真正应该从它学到的是：

一个最小 RAG 系统到底由哪些步骤组成
检索结果为什么比最终答案更值得先看
改 retrieval 参数时，回答为什么会跟着变
为什么 context grounding 是 RAG 的核心，不是可选项

最小主链路

你第一遍必须能自己复述这条链路：

user question
-> embed / retrieve relevant chunks
-> select context
-> build prompt with retrieved context
-> generate answer
-> inspect whether answer is actually grounded in context

如果你讲不出这条链路，就说明你还没有真的理解这个项目。

这项目最适合学的三个观察点

1. 检索出来了什么

大多数初学者只看最终回答，这是错的。

你应该先盯：

检索到了哪些 chunk
这些 chunk 和问题是否真的相关
是不是召回太少或太多

2. 最终 prompt 长什么样

你要知道模型不是“自动懂了”，而是被塞了一个包含上下文的 prompt。

你应该看：

原始问题是什么
被拼进去的 context 是什么
prompt 是否清楚地区分了“用户问题”和“可参考资料”

3. 改一个参数后发生了什么

真正的学习发生在你改动以后。

你最适合先改这三个变量：

chunk_size
top_k
prompt 里的回答约束

为什么它适合作为第一站

因为它把复杂度压低了。

你在这里不用先处理：

多步 query planning
reranker 组合
agent orchestration
复杂评估框架

这不是缺点，反而是优点。第一站就应该先把主链路和观察方法学会。

第一周不要做什么

第一周最容易把自己带偏的行为有这些：

一上来就换成自己的大数据集
一上来就加 UI
试图把 notebook 全看完
看到效果不好就立刻怀疑模型本身

第一周你只需要做“小而可解释”的实验。

第一周真正该做什么

Day 1

跑通最基础 notebook
记录最小输入和最小输出

Day 2

画出 retrieval -> context -> answer 主链路
把每一步写成一句人话

Day 3

看 retrieval 结果，而不是只看 final answer
记录“召回正确”和“召回错误”的例子

Day 4

修改 top_k
观察 context 变长之后回答有没有变稳

Day 5

修改 chunk_size
观察检索粒度变化带来的影响

Day 6

改 prompt 里的回答约束
比如要求“只能根据 context 回答”

Day 7

用自己的话复盘：
- 最小 RAG 是什么
- 这个仓库最关键的学习价值是什么
- 如果自己重写，你先做哪一层

更细的执行版在这里：

rag-from-scratch 7-Day Plan

你真正要产出的东西

别把“跑通 notebook”当成完成。

这一页最推荐你产出的是下面三样：

1. 一张主链路图

question -> retrieval -> context assembly -> generation -> inspection

2. 一份参数实验记录

至少记两组：

top_k 从小到大怎么变
chunk_size 从小到大怎么变

3. 一段自己的解释

你要能不看仓库，自己说：

“RAG 不是把 LLM 和向量库硬拼起来，而是通过检索到的外部上下文来约束回答。”

如果说不出来，就说明你还在“看”，不是“学会”。

常见误区

误区 1：只看最终回答

真正的问题通常出在检索阶段，不在生成阶段。

误区 2：一开始就追求复杂

你现在需要的是可解释性，不是复杂度。

误区 3：不做对照实验

不改参数，你学不到系统行为。

最小完成标准

你至少要满足下面三条中的两条：

能自己复述最小 RAG 主链路
能解释 top_k 或 chunk_size 改动后的结果变化
能用自己的小文档重跑一次并观察差异

做完它以后该去哪

下一站建议直接去：

Complex RAG Guide

理由是你会立刻看见“一个最小 RAG”和“一个更复杂 RAG”之间到底多出了哪些层：

query rewriting
reranking
routing
evaluation

这时你的学习就不是乱看，而是有参照系地升级。

Complex RAG Guide

title: “Project Guide: Complex RAG Guide”

Project Guide: Complex RAG Guide

原项目：

https://github.com/FareedKhan-dev/complex-RAG-guide

这个项目最适合你学什么

这个项目适合你在基础 RAG 之后，继续看“复杂 RAG 管线怎么长出来”。

它比最小 demo 多了很多真实系统里常见的部件，比如：

cleaning
chunking
filtering
query rewriting
planning / execution
evaluation

为什么应该在这个阶段做它

因为很多人学 RAG 会卡在这一步：

已经知道向量检索和 prompt 拼接
但不知道为什么真实系统会有那么多额外模块

这个仓库正好把这些模块串起来。

前置知识

基础 RAG 主链路
向量检索的基本概念
Notebook 式实验的习惯

先看什么

建议顺序：

README 里的 pipeline overview
RAG_pipeline.ipynb
helper functions
planner / re-planner / task handler 相关部分
evaluation 相关部分

第一周最小任务

看懂 pipeline 分成哪几层
跑通最小 notebook
只挑 1 个增强点认真看

推荐第一遍只挑下面三个之一：

query rewriting
relevance filtering
evaluation

不要第一次就想全部吃掉。

开做指南

环境要求

Jupyter Notebook
LangChain / LangGraph / 向量检索相关依赖
LLM API key

最小启动动作

安装依赖
打开 notebook
跑通一条最小问答流程
记录每一步输入输出

第一遍不要改什么

不要先改 planner prompt
不要先加自己的全部复杂数据
不要一开始就研究所有 sub-graph

第二遍建议你改什么

自己换一份语料
对比不同 chunking
只保留你认为最有用的两个增强模块

你做完后应该掌握什么

知道复杂 RAG 为什么会出现 planner / executor
知道 retrieval 后还会有过滤、重写、校验
知道 evaluation 不是附属品，而是关键环节

常见卡点

过早陷入 LangGraph 结构，而忽略主链路
同时改太多模块，不知道效果变化来自哪里
只看回答结果，不看中间状态

最小完成标准

你能画出这个 pipeline 的主要节点
你能解释 planner 和 retriever 分别负责什么
你能拿一个小实验说明某个增强模块是否值得保留

下一站

建议下一步去：

RAG Techniques
DeepSearcher

RAG Techniques

title: “Project Guide: RAG Techniques”

Project Guide: RAG Techniques

原项目：

https://github.com/NirDiamant/rag_techniques

这个项目最适合你学什么

这个仓库更像一套 RAG 技术实验库。

它非常适合你在已经懂基础 RAG 后，继续回答这类问题：

除了最基础 pipeline，还有哪些常见变体
各种技术点分别在优化哪一层
我应该在什么场景下选哪种方法

为什么应该在这个阶段做它

你做完基础 RAG 后，最容易出现的假象是：

以为 RAG 已经学完了

但其实后面还有很多技术变化：

retrieval strategy
reranking
chunking variations
query transformation
hybrid ideas

这个仓库适合帮你建立“技术地图”。

前置知识

已跑过一个最小 RAG demo
最好已看过 rag-from-scratch
最好已接触过 complex-RAG-guide

先看什么

不要打算一次性看完整仓库。

推荐做法：

先看目录，按主题分类
只挑 3 个你最关心的 technique
每个 technique 都回答“它在优化哪一层”

第一周最小任务

第一周建议你只选三类：

chunking 类
retrieval enhancement 类
evaluation / reranking 类

每类只看一个代表性 notebook 或文档。

开做指南

环境要求

Notebook 环境
基础 RAG 运行经验

最小启动动作

克隆仓库
浏览整体结构
选 3 个 technique
对每个 technique 做一页笔记

第一遍不要改什么

不要想“全部学完”
不要每个 notebook 都跑
不要在没分类的情况下碎片化吸收

第二遍建议你改什么

选择一个 technique 拿自己的数据做实验
和基础 RAG 做一次对照

你做完后应该掌握什么

知道 RAG 不是单一技术，而是一组可组合策略
知道什么是“问题在哪一层，就改哪一层”
知道如何系统比较不同 technique

常见卡点

把仓库当成百科全书，结果什么都没真正做
看了很多 technique，但没有对照实验
不区分“值得学”和“适合当前阶段”

最小完成标准

你能说出 3 到 5 种 RAG enhancement technique
你能解释它们分别在解决什么问题
你能选出 1 到 2 个最值得自己复现的技巧

下一站

做完后建议去：

DeepSearcher

这样你会更容易把 techniques 映射到真实系统里。

Project Guide: DeepSearcher

原项目：

https://github.com/zilliztech/deep-searcher

这页为什么重要

DeepSearcher 不是最小教学 demo，而是更接近“可以拿来搭系统”的那类项目。

如果 rag-from-scratch 教你的是最小主链路，那么 DeepSearcher 教你的就是：

一个 RAG 系统怎么开始有工程分层
provider、数据加载、查询流程怎么拆开
为什么 deep research / private data search 不只是“再接一个向量库”

这页的重点不是让你一下子全看懂，而是让你知道第一遍到底该盯哪里。

你应该从它学到什么

不是“我会跑一个更复杂的 RAG”。

你真正应该学到的是：

数据加载和查询不是同一阶段
可配置 provider 层为什么重要
从 demo 走向系统时，会多出哪些工程层
为什么 private data search 更像产品问题，而不只是模型问题

最小系统链路

第一遍你至少要能自己复述这条链路：

collect documents
-> ingest / parse / chunk
-> embed and index
-> receive user query
-> retrieve relevant context
-> generate answer or report

如果连“加载阶段”和“查询阶段”都没分清，你其实还没开始理解这个项目。

它和基础 RAG 的关键差别

你做完 rag-from-scratch 再来看这个项目，应该主动比较：

1. 入口更多了

最小 RAG 一般只有 notebook 或单脚本。

这里你会开始遇到：

Python API
CLI
多种配置方式

2. 配置面更宽了

最小 demo 往往默认很多东西。

这里你要开始面对：

LLM provider
embedding provider
vector store
data source

3. 工程边界更清楚了

你要学会把系统拆成：

数据准备
索引构建
查询执行
结果组织

这一步很重要，因为从这里开始，你学的不是“RAG 例子”，而是“RAG 系统”。

第一遍最该观察的三件事

1. 文档是怎么进入系统的

不要先盯最终回答。

先看：

输入文档格式是什么
ingestion 的入口在哪里
索引建立发生在什么阶段

2. query 执行路径是什么

你要知道一个 query 进入后经历了哪些层：

query 输入
检索
上下文组织
回答或报告生成

3. 配置如何影响行为

第一轮不要换一堆 provider。

但你至少要看懂：

哪些参数决定模型侧行为
哪些参数决定检索侧行为
哪些参数只是工程接入层

第一周不要做什么

这类项目最容易把人带偏，因为它“看起来很完整”。

第一周不要做这些事：

一上来就换三种 provider 对比
一上来就想部署成服务
一上来就抓网页、接私有知识库、做报告自动化
ingestion 还没跑通，就开始讨论 answer quality

第一周你只需要先跑通最小系统路径。

第一周真正该做什么

Day 1

按 README 跑通最小环境
确认依赖、provider、配置项都能工作

Day 2

只看最小 ingestion 流程
记录一份文档是怎么被加载进去的

Day 3

跑一个最小 query
画出 query 的执行路径

Day 4

换一小份自己的本地文档
确认不是只会跑示例数据

Day 5

看一个 provider 配置点
解释这个配置改的是“模型层”还是“系统层”

Day 6

比较它和基础 RAG demo 的结构差别
写出多出来的 3 个工程层

Day 7

用自己的话复盘：
- 这个项目到底在系统上比最小 RAG 多了什么
- 如果你自己重写，先保留哪些层
- 哪些层先不要做

你最该产出的东西

1. 系统分层图

data source -> ingestion -> indexing -> query -> retrieval -> answer/report

2. 一份最小配置说明

你至少要能写清：

LLM 用什么
embedding 用什么
数据从哪里来
query 从哪里发起

3. 一个对比结论

你要能讲清：

“这个项目和最小 RAG demo 的差别，不是只是功能更多，而是开始出现系统边界和配置边界。”

常见误区

误区 1：把复杂度误当成学习价值

复杂不等于更适合第一轮。

误区 2：provider 没配通就开始讨论架构

基础环境没跑通时，所有分析都很虚。

误区 3：只看回答，不看 ingestion

很多质量问题其实在数据进入系统的时候就已经决定了。

最小完成标准

你至少要做到下面三条中的两条：

能解释数据加载阶段和查询阶段的分工
能对自己的本地文档跑一条 query
能说清这个项目比基础 RAG demo 多出来的工程层

做完它以后该去哪

如果你想补模型本体理解，下一站去：

MiniMind

如果你想继续往更复杂的训练和 agent 方向走，后面再去：

OpenPipe ART

Project Guide: MiniMind

原项目：

https://github.com/jingyaogong/minimind

这页为什么重要

MiniMind 很适合做“模型本体第一站”。

如果你前面做了不少应用层项目，但总觉得自己对模型内部还是模糊的，这个项目的价值就会非常高。

它不是为了追求最强结果，而是为了让你第一次把这些东西连起来：

tokenizer
model
training loop
generation

这四个环节一旦连起来，你对 LLM 的理解会稳定很多。

你应该从它学到什么

不是“我也跑过一个小模型”。

你真正应该学到的是：

文本是怎么变成 token 的
token 是怎么进模型的
logits 和 loss 是怎么来的
训练脚本和推理脚本到底有什么不同

最小模型链路

第一遍你必须能自己复述这条链路：

raw text
-> tokenizer
-> token ids
-> model forward
-> logits
-> loss
-> backward / optimizer step

如果这条链路讲不出来，就说明你还在“看代码”，不是“理解模型”。

为什么它适合作为第一站

它比完整课程项目更轻，但又不是纯概念材料。

这意味着：

你能真的跑起来
你能看到训练和推理的真实代码
你不会一开始就淹死在大规模系统复杂度里

对第一次学“LLM from scratch”的人来说，这个平衡非常好。

第一遍最该观察的四件事

1. tokenizer 在干什么

很多人只盯 attention，这是不够的。

你要先看：

文本怎么被切分
vocab 在哪里定义
token ids 是怎么送进模型的

2. model forward 输入输出是什么

你应该明确：

输入 tensor 的 shape 是什么
输出 logits 的 shape 是什么
为什么最后能算出 loss

3. training loop 由哪些部件组成

你至少要找出来：

data loader
optimizer
loss calculation
backward
parameter update

4. generation 和 training 的差别

你要分清：

训练是在学参数
generation 是在已有参数上做 token 采样

这是很多初学者一开始最模糊的地方。

第一周不要做什么

这类项目最常见的偏航方式有这些：

一上来就想训更大模型
一上来就追求结果好不好看
一上来就换复杂数据集
没搞清训练 loop，就直接研究 attention 细节

第一周重点不是“训得强”，而是“链路讲得清”。

第一周真正该做什么

Day 1

跑通环境
记录仓库里最小训练或推理入口

Day 2

看 tokenizer 流程
画出 text -> token ids 的过程

Day 3

看 model forward
记录输入输出 tensor 的含义

Day 4

看 training loop
写出 loss、backward、optimizer 的顺序

Day 5

跑一次最小训练或最小推理
确认你不是只看代码

Day 6

改一个小超参数
比如层数、hidden size、context length 或 batch 相关参数

Day 7

用自己的话复盘：
- tokenizer、model、loss、generation 的关系
- 训练脚本和推理脚本的分工
- 如果自己重写，先保留哪几个核心模块

你最该产出的东西

1. 一张训练链路图

text -> tokenizer -> ids -> model -> logits -> loss -> backward -> optimizer

2. 一个模块说明表

至少列清：

tokenizer
model
training script
inference / generation script

3. 一个小实验记录

改一个小超参数，然后记：

改了什么
结果有什么变化
你猜为什么

常见误区

误区 1：只盯 attention

attention 很重要，但不是模型链路的全部。

误区 2：会运行就以为看懂了

真正的理解标准是你能解释数据怎么流过系统。

误区 3：一开始就想做“大训练”

第一次最重要的是可解释性，不是规模。

最小完成标准

你至少要做到下面三条中的两条：

能自己复述 text -> token -> logits -> loss 的主链路
能指出训练入口和推理入口分别在哪里
能改一个小超参数并解释变化

做完它以后该去哪

下一站建议去：

Stanford CS336

因为这时你已经有了最小模型训练的直觉，再去看系统课程内容会更稳，不会只剩一堆抽象概念。

Project Guide: Stanford CS336

课程主页：

https://cs336.stanford.edu/spring2025/

这页为什么重要

CS336 不是单个仓库，而是一条真正系统化的 Language Modeling from Scratch 路线。

如果 MiniMind 给你的是“我第一次把小模型跑起来了”的直觉，那么 CS336 给你的应该是：

知识结构
实现边界
工程脉络

也就是把“会跑一个项目”升级成“知道整个领域是怎么接起来的”。

你应该从它学到什么

不是“我看过一门课”。

你真正应该学到的是：

从 tokenizer 到 transformer 到训练系统的完整链路
哪些部分属于概念层，哪些部分属于实现层
为什么语言模型训练不只是模型代码，还包括数据、优化、系统和评估
学完整门课后，你该自己重写哪几个模块

最小知识链路

第一遍你至少要能自己复述这条链路：

raw text
-> tokenization
-> dataset / batching
-> transformer forward
-> loss
-> optimization
-> evaluation
-> systems / scaling considerations

如果你学完还只能说“这门课讲 transformer”，那说明你并没有真正建立体系。

为什么它适合放在 MiniMind 后面

因为这门课最适合在你已经有一点模型直觉之后再进入。

你先通过 MiniMind 知道：

一个小模型如何被组织起来
训练 loop 长什么样
token 到 logits 的链路是什么

然后再来 CS336，你才会知道课程里每一块知识落在系统的哪一层。

否则它很容易变成“收藏了一堆讲义和作业，但脑子里没有图”。

第一遍最该观察的四件事

1. 课程在分哪些层

第一遍不要急着细读每个 lecture。

先看课程结构到底把内容拆成了哪些大块，例如：

tokenization
model architecture
optimization / training
evaluation
systems / scaling

2. 每个模块是在回答什么问题

比如：

tokenizer 回答“文本怎么变成模型能吃的形式”
transformer 回答“模型如何建模上下文”
optimization 回答“参数如何被更新”
systems 回答“训练如何在现实资源上跑起来”

3. 哪些部分值得你自己重写

不是所有内容都要第一轮实现。

第一遍最值得重写的通常是：

tokenizer 的一个最小版本
transformer block 的最小实现
一个最小训练循环

4. 课程和项目的关系

你要明确：

MiniMind 更像一个落地实现入口
CS336 更像全景地图

这门课的价值不是替代项目，而是给项目提供结构化坐标。

第一周不要做什么

做课程类内容最常见的错误有这些：

一上来就想“学完整门课”
每看到术语就开一堆额外资料
不做知识图，只做零散摘录
先做最难的作业或系统部分

第一周最重要的是先把地图搭起来。

第一周真正该做什么

Day 1

浏览课程主页
写出课程的 4 到 6 个核心模块

Day 2

选 tokenizer / transformer / training 这三块
每块各写一句“它在回答什么问题”

Day 3

把课程结构和 MiniMind 对照
标出哪些知识你已经碰过，哪些还没有

Day 4

选一个最小模块准备自己实现
推荐优先 tokenizer 或一个最小 transformer block

Day 5

看实现相关材料
记录输入、输出、关键中间量

Day 6

写一张自己的知识图
把整门课压缩成一页结构图

Day 7

用自己的话复盘：
- 这门课到底比单个项目多给了你什么
- 你现在最该先补的 2 到 3 个模块是什么
- 哪一个模块你准备自己动手重写

你最该产出的东西

1. 一张课程知识图

最少要包括：

tokenizer
model
training
evaluation
systems

2. 一个“先学什么”的决策表

你要写清：

哪些内容你已经有直觉
哪些内容你还完全空白
哪些最值得现在补

3. 一个最小实现目标

例如：

自己写一个最小 tokenizer
自己写一个 transformer block
自己写一个最小训练 loop

常见误区

误区 1：把课程当资源收藏页

不压成自己的结构图，学完很容易散。

误区 2：只读不做

这门课真正有价值的部分，是它能指导你自己实现。

误区 3：顺着网页一直看，但没有主线

第一轮先抓主干，不要先钻局部细节。

最小完成标准

你至少要做到下面三条中的两条：

能画出这门课的核心知识图
能说出自己最该先补的 2 到 3 个模块
能把其中一个模块变成自己的最小实现任务

做完它以后该去哪

如果你完成得比较扎实，下一站建议去：

ModelAlignmentFromScratch

因为那时你已经有足够稳定的训练基础，能真正理解“预训练之后，为什么还要 alignment”。

Project Guide: ModelAlignmentFromScratch

原项目：

https://github.com/Sherlock1956/ModelAlignmentFromScratch

这页为什么重要

这个项目的价值不在“又一个训练仓库”，而在于它让你第一次真正面对这个问题：

预训练之后，模型为什么还需要对齐？

如果你已经学过一点模型训练，但对下面这些词还是有点飘，这页就很重要：

SFT
Expert Iteration
GRPO

它把这些东西从概念拉回到实现层。

你应该从它学到什么

不是“我知道几种 alignment 方法名字”。

你真正应该学到的是：

SFT、EI、GRPO 各自在优化什么
alignment 比 pretraining 多出来哪些部件
reward / grading / sampling 在训练里分别扮演什么角色
为什么越往 agent 或 RL 方向走，系统越不稳定

最小认知链路

第一遍你应该能自己复述这条链路：

prompt
-> model response
-> reward / grading / preference signal
-> objective based on that signal
-> parameter update

和普通预训练相比，多出来的关键不是“换了个 loss 名字”，而是训练信号来源变了。

为什么它值得在这个阶段做

这类项目最适合放在你已经有模型基础之后。

因为你必须先知道：

普通语言模型训练在干什么
logits 和 loss 是怎么来的
一个标准 training loop 长什么样

否则你一看 alignment，只会觉得“它又多了一堆脚本”，但不知道本质差异是什么。

第一遍最该观察的四件事

1. 先看 SFT，不要先啃 GRPO

顺序很重要。

第一遍建议：

sft.py
expert_iteration.py
GRPO.py
reward / grader 相关文件

如果你一开始直接看 GRPO.py，大概率只会被流程复杂度淹没。

2. 每种方法的训练信号来自哪里

你至少要分清：

SFT 是监督信号
EI 是专家迭代式改进
GRPO 更接近基于组内比较或奖励的优化

3. response sampling 在哪里发生

alignment 项目里，一个关键新增复杂度就是：

不是只算一次 forward 就结束
可能需要采样多个 response
然后再打分或比较

4. reward / grading 逻辑在哪里

第一遍必须定位到：

reward 是怎么来的
grader 在哪里
它如何反馈回训练目标

第一周不要做什么

这类项目最容易被“高级名词”带偏。

第一周不要做这些：

一上来就改 reward 设计
一上来就追训练效果
一上来就把 GRPO 当黑盒神技
SFT 还没看懂，就硬看 RL 部分

第一周重点是建立对比框架，不是做优化。

第一周真正该做什么

Day 1

跑通环境
看 README 和目录结构

Day 2

精读 sft.py
写出 SFT 的输入、输出、loss

Day 3

看 expert_iteration.py
记录它比 SFT 多了哪一层流程

Day 4

看 GRPO.py
先画流程，不急着逐行深挖

Day 5

找 reward / grader 相关逻辑
确认训练信号是怎么回到更新目标里的

Day 6

写一张对比表：
- SFT 优化什么
- EI 优化什么
- GRPO 优化什么

Day 7

用自己的话复盘：
- alignment 比 pretraining 多了什么
- 为什么 response sampling 会让系统更复杂
- 为什么 agent RL 往往更不稳定

你最该产出的东西

1. 一张方法对比表

最少包含三列：

训练信号来源
目标函数直觉
比 SFT 多出来的复杂度

2. 一条训练信号链路

prompt -> sampled response -> reward / grading -> optimization objective -> update

3. 一段自己的解释

你要能说清：

“alignment 的核心不是把模型再训一遍，而是改变模型收到的训练信号，让它朝更符合任务目标或偏好的方向更新。”

常见误区

误区 1：把 GRPO 当成高级版 SFT

它们的训练信号和优化逻辑不是一回事。

误区 2：只看结果，不看 reward 来源

对齐训练里，reward 来源就是系统灵魂。

误区 3：没理解 baseline 就看高级方法

如果 SFT 都没讲清，后面的比较基本都不稳。

最小完成标准

你至少要做到下面三条中的两条：

能解释 SFT、EI、GRPO 各自在优化什么
能指出 reward / grader 相关逻辑的位置
能说清 alignment 相比 pretraining 多出来的关键部件

做完它以后该去哪

下一站建议去：

OpenPipe ART

因为这时你已经有单模型 alignment 的基本框架，再去看更偏 agent RL 的训练系统，思路会顺很多。

Project Guide: OpenPipe ART

原项目：

https://github.com/OpenPipe/ART

这页为什么重要

ART 不是普通微调框架，而是一个更接近 agent reinforcement training 的入口。

如果前面那些项目教你的是：

最小 RAG
小模型训练
单模型 alignment

那么这个项目开始逼你面对另外一种复杂度：

多步任务
trajectory
reward over interaction
rollout-driven training

这就是它真正值得学的地方。

你应该从它学到什么

不是“又一个训练仓库怎么跑”。

你真正应该学到的是：

agent RL 和单轮回答训练的本质差别
rollout / trajectory 为什么会让训练复杂很多
reward 设计为什么直接决定 agent 行为
一个框架到底在帮你管理哪些复杂度

最小 agent 训练链路

第一遍你至少要能自己复述这条链路：

task
-> agent interacts over multiple steps
-> collect trajectory / rollout
-> compute reward or success signal
-> optimize policy based on that signal

和 SFT 最大的不同，不是“loss 名字变了”，而是训练对象从单次回答变成了多步行为。

为什么它必须放在后面

这个项目不适合当第一站。

因为你至少需要先理解这些东西：

一个标准语言模型训练 loop
alignment 的基本训练信号
reward / rollout / policy update 的基本直觉

否则你一看 agent RL，只会觉得“多了很多流程”，但抓不到本质。

第一遍最该观察的四件事

1. 任务是怎么定义的

先不要急着看训练结果。

你要先看：

agent 在解决什么类型的任务
一次 episode 包含几步
成功或失败是怎么定义的

2. trajectory 是什么样子

这一步很关键。

你要知道：

每一步记录了什么
什么时候结束 rollout
哪些中间行为会影响最终 reward

3. reward 是怎么来的

agent 系统里，reward 不是装饰，它直接塑造行为。

你至少要定位到：

reward 定义在哪里
reward 是 sparse 还是 dense
reward 和目标行为之间有什么映射

4. 框架帮你省掉了哪些事

这一类框架最值得学的，不只是 API，而是 abstraction。

你要看懂：

哪些是 task 层
哪些是 rollout 层
哪些是 optimization 层

第一周不要做什么

这类项目很容易让人误判复杂度。

第一周不要做这些：

一上来就追 benchmark
一上来就魔改 reward
一上来就扩大任务规模
还没看懂 trajectory，就开始调超参

第一周重点不是训出强 agent，而是把多步训练结构讲清楚。

第一周真正该做什么

Day 1

跑通最小环境
确认最小 example 能工作

Day 2

看任务定义
写出 agent 一次 episode 的开始、过程、结束

Day 3

看 rollout / trajectory 结构
画出 agent 交互路径

Day 4

找 reward 定义
写出 reward 在什么时刻产生、如何反馈

Day 5

看 optimization 主流程
明确训练更新用到了哪些 rollout 信息

Day 6

用自己的话比较：
- agent RL 和 SFT 有什么不同
- agent RL 和单模型 alignment 有什么不同

Day 7

设计一个非常小的实验：
- 一个简单任务
- 一个朴素 reward
- 一个你预期 agent 会改进的行为

你最该产出的东西

1. 一张 agent 训练流程图

task -> rollout -> trajectory -> reward -> update

2. 一份抽象层说明

你至少要能分清：

task abstraction
rollout abstraction
optimization abstraction

3. 一个小 reward 设计草稿

不一定要马上训练，但你要能写出：

目标行为是什么
什么信号说明它做对了
reward 如何编码这个信号

常见误区

误区 1：把它当普通微调框架

多步行为训练的单位不是单条样本，而是 trajectory。

误区 2：只看结果，不看 reward

agent 学成什么样，通常先看 reward 定义，再看模型本身。

误区 3：任务结构都没讲清，就开始调参

这会让你永远不知道问题出在任务、reward 还是优化。

最小完成标准

你至少要做到下面三条中的两条：

能说清 agent RL 和单步 alignment 的区别
能解释 rollout / trajectory / reward 的关系
能指出这个框架最核心的两个到三个抽象层

做完它以后该做什么

这个项目更像这条线的高阶实践点。

做完它以后，最值得做的不是继续看更大框架，而是自己做一个极小实验：

设计一个简单多步任务
定义一个很朴素的 reward
看 agent 是否能学到更稳定的行为

到这一步，你才算真正开始把 agent RL 变成自己的东西。

Project Guide: full-stack-fastapi-template

原项目：

https://github.com/fastapi/full-stack-fastapi-template

补充官方文档：

https://fastapi.tiangolo.com/fa/tutorial/bigger-applications/

这页为什么重要

如果你要学 FastAPI + 前端 + 数据库 + 认证 + 部署，这个项目是非常合适的第一站。

它不是单个 FastAPI demo，而是一个完整的全栈模板。你可以在一个项目里同时看到：

FastAPI 后端
前端应用
数据库
用户认证
Docker / 环境配置

这正好能帮你建立“真实 Web 应用”的整体直觉。

你应该从它学到什么

不是“我把一个模板跑起来了”。

你真正应该学到的是：

一个完整 Web 产品的最小结构有哪些层
FastAPI 后端如何组织 router、schema、model、db
前端如何真正调用后端并展示数据
登录态、数据库、部署为什么会把项目复杂度拉上来

最小全栈链路

第一遍你至少要能自己复述这条链路：

user action in frontend
-> frontend sends request
-> FastAPI route receives request
-> backend logic talks to database
-> response returns to frontend
-> UI updates

如果你不能把这条链路讲清楚，你就还没有真正理解“前后端联动”。

为什么它适合作为第一站

因为它的学习价值很集中：

不是只有后端
不是只有前端
不是只有一个小 CRUD 脚本

它会让你在同一套代码里看到产品开发最常见的几层结构。

而且它来自 FastAPI 官方组织，这意味着它更适合拿来建立基础判断，不容易一上来就学到一堆个人风格很重的写法。

第一遍最该观察的五件事

1. 后端目录怎么拆

你要先看：

入口文件在哪里
router 在哪里
model / schema / crud 在哪里
配置和环境变量在哪里

2. 前端目录怎么拆

你要知道：

页面在哪里
API 调用在哪里
登录相关逻辑在哪里
数据如何进入 UI

3. 用户认证怎么走

这是全栈项目里非常关键的一层。

你至少要搞清：

登录请求发到哪里
token 或认证信息怎么保存
后端怎么识别当前用户

4. 数据库在系统里扮演什么角色

你要分清：

model 是什么
migration 或建表逻辑在哪里
一次新增 / 查询 / 更新是怎么走的

5. Docker 和环境配置为什么存在

第一遍不需要精通部署，但你至少要知道：

为什么要有环境变量
为什么数据库和应用经常一起启动
Docker 帮你解决了什么问题

第一周不要做什么

第一周最容易带偏自己的做法有这些：

一上来就换技术栈
一上来就重构全部目录
一上来就加很多复杂页面
登录和数据库还没跑通，就急着做 UI 美化

第一周重点是先把完整链路跑通。

第一周真正该做什么

Day 1

按项目说明跑通本地环境
确认前端、后端、数据库都能启动

Day 2

画出前端到后端再到数据库的链路
标记核心目录

Day 3

看一个最基础的 API
记录请求、响应、数据库读写分别发生在哪里

Day 4

看登录流程
记录认证信息在前后端怎么流动

Day 5

加一个最小字段或最小资源
比如新增一个简单的 notes / tasks / tags 字段

Day 6

给前端加一个最小页面或表单联动
让你新增的数据能被看到

Day 7

用自己的话复盘：
- 这个模板的后端结构是什么
- 前后端是怎么联动的
- 如果自己做一个小产品，你保留哪几层

更细执行版在这里：

full-stack-fastapi-template 7-Day Plan

你最该产出的东西

1. 一张全栈数据流图

frontend event -> API request -> FastAPI route -> db operation -> API response -> UI update

2. 一份目录说明

你至少要能解释：

后端入口
API 路由
数据模型
前端页面
前端 API 调用层

3. 一个小功能改动

第一轮最推荐的，不是大改，而是：

增加一个字段
增加一个简单资源
新增一个很小的表单流

只要你做过一次，你就不再只是“跑模板”。

常见误区

误区 1：把它当纯后端项目

这项目最大的价值恰恰是全链路，不是只看 API。

误区 2：前后端都能启动，就以为学会了

真正的理解标准是你能加一个小功能并让它贯通。

误区 3：一上来就做复杂业务

第一轮先学结构，不先追产品复杂度。

最小完成标准

你至少要做到下面三条中的两条：

能解释前端请求是如何走到数据库再回到页面的
能自己加一个小 API 或小字段并连到前端
能说清认证、数据库、前端页面这三层是怎么接起来的

做完它以后该去哪

做完这页之后，你最值得做的不是再找第二个模板，而是做一个自己的小产品。

最适合你的方向：

学习任务管理器
AI 学习资料管理器
刷题复盘系统

这时模板才真正变成你的能力，而不是你的依赖。

7-Day Plans

如果你已经决定开做，直接进入对应的一周执行页：

rag-from-scratch 7-Day Plan
Complex RAG Guide 7-Day Plan
RAG Techniques 7-Day Plan
DeepSearcher 7-Day Plan
MiniMind 7-Day Plan
Stanford CS336 7-Day Plan
ModelAlignmentFromScratch 7-Day Plan
OpenPipe ART 7-Day Plan
full-stack-fastapi-template 7-Day Plan

rag-from-scratch 7-Day Plan

title: “7-Day Plan: rag-from-scratch”

7-Day Plan: rag-from-scratch

对应项目：

项目导学页
原仓库: https://github.com/langchain-ai/rag-from-scratch

目标

7 天后你应该能：

跑通一个最小 RAG notebook
解释 retrieval -> context -> answer 主链路
自己改一个小参数并观察结果

Day 1

任务：

读 README
浏览仓库结构
记录这个项目在教什么

产出：

一段 5 句以内总结

Day 2

任务：

安装依赖
打开最基础 notebook
跑通到第一次生成答案

产出：

一张截图或一段运行记录

Day 3

任务：

只盯 retrieval 部分
看输入 query 如何变成检索结果
记录 top-k、chunk、embedding 的角色

产出：

一张最小流程图

Day 4

任务：

只盯 generation 部分
看上下文如何进 prompt
看回答为什么依赖检索结果

产出：

一段自己的中文解释

Day 5

任务：

改一个小参数
比如 chunk 大小、top-k、prompt 模板中的一句话
重新运行并比较变化

产出：

一张“改动前后对比表”

Day 6

任务：

换成你自己的一个小文档
跑一个最小自定义例子

产出：

一个你自己的 query + answer 示例

Day 7

任务：

回头总结整个项目
写出这个仓库最值得你保留的 3 个点
写出你下一步最想补的一层

产出：

一页复盘笔记

完成标准

你不再把 RAG 理解成黑盒
你能解释最小链路
你手上已经有一个自己的最小例子

Complex RAG Guide 7-Day Plan

title: “7-Day Plan: Complex RAG Guide”

7-Day Plan: Complex RAG Guide

对应项目：

项目导学页
原仓库: https://github.com/FareedKhan-dev/complex-RAG-guide

目标

7 天后你应该能：

说清复杂 RAG 比基础 RAG 多了哪些层
理解 planner / filter / evaluation 的作用
选出最值得自己复现的 1 到 2 个增强模块

Day 1

任务：

重读 README
只整理 pipeline 目录
把出现的模块列成清单

产出：

一张模块清单

Day 2

任务：

跑通 notebook 或最小流程
不求全懂，先看整体跑起来

产出：

一段运行成功记录

Day 3

任务：

重点看 chunking / cleaning / restructuring
思考这些步骤为什么不属于“可有可无”

产出：

一页关于“数据准备为什么重要”的笔记

Day 4

任务：

重点看 filtering / relevance check / query rewrite
记录每一层在修什么问题

产出：

一个三列表：模块 / 解决的问题 / 代价

Day 5

任务：

重点看 planner / re-planner / task handler
不用先研究 prompt 细节
先理解状态机或图结构

产出：

一张主流程图

Day 6

任务：

重点看 evaluation
看系统如何判断 answer 是否 grounded / useful

产出：

一段你自己的 evaluation 理解

Day 7

任务：

选 1 到 2 个你最想保留的增强模块
写出如果你自己做一个 RAG，会保留什么

产出：

一页“我的复杂 RAG v1 方案”

完成标准

你知道复杂 RAG 不是堆功能，而是逐层补漏洞
你能说清 2 个以上增强模块的意义
你能把复杂 RAG 缩成自己的版本

RAG Techniques 7-Day Plan

title: “7-Day Plan: RAG Techniques”

7-Day Plan: RAG Techniques

对应项目：

项目导学页
原仓库: https://github.com/NirDiamant/rag_techniques

目标

7 天后你应该能：

说出多个 RAG enhancement technique
区分它们分别在改哪一层
选出最值得自己实验的方向

Day 1

任务：

看仓库整体结构
按主题给 techniques 分组

产出：

你的分组表

Day 2

任务：

选一个 chunking / indexing 类 technique
只理解它在改什么

产出：

一段中文摘要

Day 3

任务：

选一个 retrieval enhancement 类 technique
记录适用场景

产出：

一张“什么时候用它”的卡片

Day 4

任务：

选一个 reranking / filtering 类 technique
比较它和基础 retrieval 的差别

产出：

一张对比表

Day 5

任务：

选一个 query transformation 类 technique
思考它到底在弥补什么弱点

产出：

一段你的判断

Day 6

任务：

从前 4 天看过的内容里选 3 个 technique
做一个横向对比

产出：

一个三选三对比表

Day 7

任务：

选 1 个你要真正复现的 technique
写出你自己的最小实验计划

产出：

一页实验计划

完成标准

你不再把 RAG technique 看成杂乱点子
你能知道问题出在哪一层
你有一个明确的下一个实验方向

DeepSearcher 7-Day Plan

title: “7-Day Plan: DeepSearcher”

7-Day Plan: DeepSearcher

对应项目：

项目导学页
原仓库: https://github.com/zilliztech/deep-searcher

目标

7 天后你应该能：

跑通一次本地文档加载和查询
理解 provider 配置和模块化结构
说清它为什么更像系统而不是 demo

Day 1

任务：

读 README 的 quick start 和 feature 部分
标出它支持的模块

产出：

一张模块地图

Day 2

任务：

搭环境
选择一个最简单 provider 组合

产出：

环境准备记录

Day 3

任务：

用一份最小本地文件做 loading
理解 data ingestion 在哪里发生

产出：

你自己的数据加载说明

Day 4

任务：

跑一次 query
观察系统输出和配置关系

产出：

一个最小 query 示例

Day 5

任务：

重点看 config / provider 配置方式
记录 LLM、embedding、vector DB 怎么解耦

产出：

一张配置结构图

Day 6

任务：

看 CLI 和 Python API 两种用法
比较它们的适用场景

产出：

一张 CLI vs API 对比表

Day 7

任务：

用自己的语言总结这个系统
写出它和 notebook 式 RAG 的差别

产出：

一页复盘

完成标准

你能加载自己的数据并提问
你能解释模块化 provider 的意义
你能识别系统级 RAG 的工程结构

MiniMind 7-Day Plan

title: “7-Day Plan: MiniMind”

7-Day Plan: MiniMind

对应项目：

项目导学页
原仓库: https://github.com/jingyaogong/minimind

目标

7 天后你应该能：

理解一个超小语言模型的基本部件
跑通一次最小训练或推理
画出 tokenizer -> model -> loss -> generation 主链路

Day 1

任务：

读 README
写下项目的目标和定位

产出：

一段项目摘要

Day 2

任务：

看仓库结构
找 tokenizer、model、train、infer 分别在哪里

产出：

Day 3

任务：

重点看 tokenizer 或数据处理部分
记录文本怎样变成模型输入

产出：

一张输入流转图

Day 4

任务：

重点看模型结构
记录主要模块

产出：

一张模型结构草图

Day 5

任务：

重点看训练脚本
关注 loss、optimizer、batch 流程

产出：

一段训练流程说明

Day 6

任务：

跑最小推理或训练示例
记录输入输出

产出：

一个最小运行记录

Day 7

任务：

总结整个项目
写出你现在终于理解了什么

产出：

一页复盘

完成标准

你能说清一个小语言模型主链路
你能找到训练与推理入口
你能继续进入更系统的课程内容

Stanford CS336 7-Day Plan

title: “7-Day Plan: Stanford CS336”

7-Day Plan: Stanford CS336

对应项目：

项目导学页
课程主页: https://cs336.stanford.edu/spring2025/

目标

7 天后你应该能：

建立课程级知识地图
明确你最该先补的模块
把课程变成你自己的实现清单

Day 1

任务：

浏览课程主页
记录课程主题结构

产出：

一张课程主题表

Day 2

任务：

只看 tokenizer 相关内容
记录它在整门课里的位置

产出：

一页 tokenizer 笔记

Day 3

任务：

只看 transformer / attention 相关内容

产出：

一页结构理解笔记

Day 4

任务：

看 training / optimization 相关内容

产出：

一段训练链路总结

Day 5

任务：

看 systems / scaling / efficiency 相关内容
先抓大意，不要求吃透

产出：

一张“系统层问题”清单

Day 6

任务：

把前 5 天内容整理成一张知识图

产出：

一张总图

Day 7

任务：

写出你自己的实现优先级
决定哪些部分你要自己真正实现

产出：

一页“我的 CS336 执行计划”

完成标准

你不再把课程当资源堆
你知道自己先补什么
你能把课程内容落成行动计划

ModelAlignmentFromScratch 7-Day Plan

title: “7-Day Plan: ModelAlignmentFromScratch”

7-Day Plan: ModelAlignmentFromScratch

对应项目：

项目导学页
原仓库: https://github.com/Sherlock1956/ModelAlignmentFromScratch

目标

7 天后你应该能：

说清 SFT、EI、GRPO 的差别
找到仓库里对应实现
跑通至少一种方法的最小流程

Day 1

任务：

读 README
记录三种方法分别是什么

产出：

一张三方法总览表

Day 2

任务：

浏览 cs336_alignment/ 目录
定位各脚本职责

产出：

一张文件职责表

Day 3

任务：

精读 sft.py
把它看成 baseline

产出：

一页 SFT 流程笔记

Day 4

任务：

看 expert_iteration.py
记录它比 SFT 多出的循环逻辑

产出：

一张 SFT vs EI 对比表

Day 5

任务：

看 GRPO.py
重点理解 reward 和组内比较

产出：

一页 GRPO 笔记

Day 6

任务：

看 grader / reward 相关代码
记录回答是怎么被评估的

产出：

一张 reward 流程图

Day 7

任务：

做整体复盘
写出这三种方法在你心里的分工

产出：

一页 alignment 总结

完成标准

你能区分三种训练方式
你能指出核心实现位置
你能继续进入 agent RL 方向

OpenPipe ART 7-Day Plan

title: “7-Day Plan: OpenPipe ART”

7-Day Plan: OpenPipe ART

对应项目：

项目导学页
原仓库: https://github.com/OpenPipe/ART

目标

7 天后你应该能：

说清 agent RL 在训练什么
理解任务、轨迹、奖励、优化的关系
跑一个最小示例或至少看懂其主流程

Day 1

任务：

读 README
写下 agent reinforcement training 的一句话解释

产出：

一段项目定位总结

Day 2

任务：

浏览项目结构
找 example、task、trainer、reward 相关部分

产出：

Day 3

任务：

看最小示例
理解一个任务是怎么定义的

产出：

一页任务定义笔记

Day 4

任务：

看 rollout 或 trajectory 相关流程

产出：

一张 agent interaction 流程图

Day 5

任务：

看 reward / optimization 部分
只抓主逻辑

产出：

一张 reward -> update 关系图

Day 6

任务：

跑一个最小 demo 或至少跑最小配置
记录结果

产出：

一条运行记录

Day 7

任务：

总结 ART 和普通 alignment 的差别
写出你想尝试的一个简单 agent 任务

产出：

一页复盘

完成标准

你能解释 agent RL 的核心对象
你能指出任务和 reward 的关键位置
你有一个自己的小实验想法

7-Day Plan: full-stack-fastapi-template

原项目：

https://github.com/fastapi/full-stack-fastapi-template

目标：

用 7 天建立你对全栈 Web 应用的最小直觉
不只会启动项目，还能加一个很小的真实功能

Day 1: 跑通全栈环境

今天只做一件事：

把前端、后端、数据库都跑起来

完成标准：

你能看到前端页面
你能打开 FastAPI docs
你知道数据库服务也在运行

Day 2: 认目录，不乱看

今天目标：

至少标出来：

后端入口
API routes
models / schemas
前端 pages / components
前端 API 调用层

完成标准：

Day 3: 跟一条 API 请求

今天目标：

从前端操作跟踪一条真实请求

记录：

请求从哪个页面发出
后端哪个 route 接收
哪个数据库操作被调用
响应怎么回到 UI

完成标准：

你能口头讲清一条请求链路

Day 4: 看认证

今天目标：

搞清登录态怎么工作

你要回答：

登录请求发到哪里
认证信息存在哪里
后端怎么知道当前用户是谁

完成标准：

你能解释认证链路

Day 5: 加一个小字段

今天目标：

对已有资源加一个很小的字段

例如：

note 的 summary
task 的 priority
item 的 tag

完成标准：

后端能处理这个字段
数据库能保存这个字段

Day 6: 把新字段连到前端

今天目标：

让前端页面能新增或展示这个字段

完成标准：

你能在 UI 上看到 Day 5 的改动

Day 7: 做一次自己的复盘

今天目标：

不看代码，自己讲清完整链路

至少回答这四个问题：

前后端请求是怎么流动的
数据库在这个系统里的位置是什么
认证层起什么作用
如果自己做一个小产品，你会保留哪些层

完成标准：

写一页自己的总结

这一周结束后你应该会什么

知道一个真实全栈项目最小结构
知道前后端和数据库如何联动
做过一次从后端到前端的最小改动

如果这些都没做到，就不要急着换第二个项目。

自测题

不看原文档，先自己答：

RAG 自测
LLM From Scratch 自测
Alignment / Agent RL 自测
FastAPI / Full Stack Web 自测
综合项目自测

RAG 自测

title: “自测题：RAG Systems”

自测题：RAG Systems

这份题不是面试题库，而是检查你自己有没有真的学会。

建议规则：

先闭卷做
每题先口头讲，再写
如果一题只能写定义，说明还没学会

Part 1: 基础判断

1.

不用术语，直接用自己的话解释：

什么是 RAG
它和“把问题直接发给大模型”有什么本质区别

2.

最小 RAG 主链路里，至少有哪些步骤？

要求：

不要写成“调用 API”
要写出信息流怎么走

3.

为什么检索质量差时，模型回答也容易差？

4.

chunking 为什么会影响最终效果？

至少回答：

chunk 太大有什么问题
chunk 太小有什么问题

5.

retrieval 和 generation 分别在解决什么问题？

Part 2: 结构理解

6.

如果一个 RAG 系统回答不准，你会先检查哪三层？

要求：

不要回答“换更强模型”

7.

query rewriting 在什么情况下有帮助？

8.

filtering 或 reranking 为什么值得加？

9.

为什么复杂 RAG 里会出现 planner / executor 这种结构？

10.

source attribution 或引用来源，除了“好看”，还有什么实际意义？

Part 3: 项目对应题

11.

rag-from-scratch 最适合帮你学会什么？

12.

complex-RAG-guide 相比基础 RAG，多补了哪些关键层？

13.

rag_techniques 这类仓库最适合怎么学，才不会变成“看了很多但没学会”？

14.

deep-searcher 和 notebook 式 RAG demo 的差别是什么？

Part 4: 动手题

15.

请你自己画一个最小 RAG 架构图。

至少要包含：

文档
embedding / index
retrieval
prompt / context
answer

16.

请你设计一个最小实验，验证下面这个问题：

top-k 从 3 改成 8，会不会让回答更好？

你需要写：

实验输入
对照方式
观察指标

17.

如果让你自己做一个课程笔记问答器，你会保留哪 3 个模块，为什么？

18.

如果让你删掉复杂 RAG 里的 2 个模块做 v1，你会删什么，为什么？

自评分标准

18 分以上

说明你已经不只是“看过”，而是理解了大部分主线。

12 到 17 分

说明你有框架，但还不够稳，需要做一次自己的最小项目。

11 分及以下

说明你大概率还是在“识别术语”，没有真正内化。

打分方式

每题按下面标准给自己打分：

2 分：能清楚解释，还能举例
1 分：知道大概，但讲不清
0 分：不会，或者只能复读术语

LLM From Scratch 自测

title: “自测题：LLM From Scratch”

自测题：LLM From Scratch

这份题是检查你有没有真正开始理解“模型本体”。

Part 1: 主链路理解

1.

一个 decoder-only language model，从输入文本到输出下一个 token，中间大致发生了什么？

2.

tokenizer 在整个系统里到底负责什么？

3.

为什么 tokenizer 不是“可有可无的小细节”？

4.

embedding 层在做什么？

5.

self-attention 为什么是 transformer 的核心？

Part 2: 训练理解

6.

language model training 里的训练目标是什么？

7.

为什么 pretraining 本质上是一个“预测下一个 token”的问题？

8.

训练脚本里通常至少会有哪几个核心部件？

9.

为什么 batch size、sequence length、learning rate 都会影响训练？

10.

训练和推理的代码入口，通常有什么不同？

Part 3: 项目对应题

11.

MiniMind 最适合帮你建立什么直觉？

12.

CS336 和一个普通教程最大的区别是什么？

13.

如果你已经跑通 MiniMind，为什么接着看 CS336 会更稳？

Part 4: 动手题

14.

请你画一个最小 decoder-only LM 的结构图。

至少要有：

tokenizer
embeddings
transformer blocks
logits
sampling / generation

15.

如果让你自己写一个极小语言模型实验，你会按什么顺序实现？

16.

如果模型训练不收敛，你会优先检查哪三类问题？

17.

请你解释：

pretraining 学到了什么
它没有解决什么

自评分标准

每题：

2 分：能自己解释，还能连接到代码
1 分：知道概念，但和代码连不起来
0 分：不会

总分：

14 分以上：说明你已经有模型主链路意识
9 到 13 分：说明概念有了，但实现层还不够稳
8 分以下：建议回到 MiniMind 和 CS336 的基础部分

Alignment / Agent RL 自测

title: “自测题：Alignment / Agent RL”

自测题：Alignment / Agent RL

这份题主要检查你有没有把：

pretraining
SFT
preference optimization
agent RL

区分开。

Part 1: 基础区分

1.

为什么模型完成 pretraining 后，通常还不够“好用”？

2.

SFT 在解决什么问题？

3.

SFT 没有解决什么问题？

4.

为什么 alignment 不能简单理解成“让模型更像人说话”？

Part 2: 方法理解

5.

Expert Iteration 的核心想法是什么？

6.

GRPO 和普通 supervised fine-tuning 的区别是什么？

7.

reward 在 alignment 里扮演什么角色？

8.

为什么 sampling 会影响 alignment 的训练结果？

9.

为什么多步 agent 任务会比单步问答更难训练？

10.

trajectory 在 agent RL 里为什么重要？

Part 3: 项目对应题

11.

ModelAlignmentFromScratch 最值得你学的是什么？

12.

这个项目里为什么建议先读 sft.py，不要一开始就冲 GRPO.py？

13.

OpenPipe ART 和普通对齐项目相比，更强调什么？

Part 4: 动手题

14.

请你自己写一张表，对比：

pretraining
SFT
EI
GRPO
agent RL

字段至少包含：

输入数据
优化目标
输出能力

15.

如果一个 agent 在多步任务里表现不稳定，你会怀疑哪几类问题？

16.

如果让你自己设计一个最小 agent RL 任务，你会怎么定义：

task
reward
success criterion

自评分标准

每题：

2 分：能说清楚，还能和项目代码联系起来
1 分：概念知道，但边界模糊
0 分：不会

总分：

13 分以上：说明你已经开始真正理解 alignment
8 到 12 分：说明概念初步建立，但还需要再看实现
7 分以下：建议先回到 ModelAlignmentFromScratch

自测题：FastAPI / Full Stack Web

这份题不是背概念，而是检查你有没有真的理解一个全栈 Web 应用是怎么工作的。

建议规则：

先闭卷做
每题先口头讲，再写
如果只能写术语，说明还没真正掌握

Part 1: 基础判断

1.

不用术语，直接用自己的话解释：

什么叫前后端分离
前端和后端分别负责什么

2.

一个最小全栈 Web 应用至少包括哪些层？

要求：

不要只写“前端后端数据库”
要写出信息怎么流动

3.

为什么 FastAPI 这种后端框架在全栈应用里有价值？

4.

前端点一次按钮，到页面显示最新数据，中间最少经过哪些步骤？

5.

为什么“前端能打开页面”不等于“前后端已经打通”？

Part 2: 结构理解

6.

如果你打开一个 FastAPI 全栈模板，你会先看哪四个位置？

7.

route、schema、model、database 分别在解决什么问题？

8.

为什么认证是全栈项目里非常关键的一层？

9.

前端拿到 token 以后，通常还要解决什么问题？

10.

为什么 Docker 和环境变量在全栈项目里经常出现？

Part 3: 项目对应题

11.

full-stack-fastapi-template 最适合帮你学会什么？

12.

它和“只写一个 FastAPI hello world”最大的差别是什么？

13.

如果你看这个模板时只盯后端，不看前端，你会漏掉什么？

14.

如果你只会跑通模板，但不会加一个小字段或小页面，说明你还差哪一步？

Part 4: 动手题

15.

请你自己画一个最小全栈数据流图。

至少包含：

前端事件
API 请求
FastAPI route
数据库操作
页面更新

16.

如果让你给一个现有资源加一个新字段，你最少需要检查哪几层？

17.

如果让你做一个“学习任务管理器”，你会保留哪 4 个模块，为什么？

18.

如果你要做 v1，你会刻意先不做哪 2 件事，为什么？

自评分标准

18 分以上

说明你已经不只是“知道目录里有什么”，而是理解了整条链路。

12 到 17 分

说明你知道结构，但还缺少一次自己动手改功能的经验。

11 分及以下

说明你大概率还停留在“会启动项目”，没有真正理解全栈联动。

打分方式

每题按下面标准给自己打分：

2 分：能清楚解释，还能举例
1 分：知道大概，但讲不清
0 分：不会，或者只能复读术语

综合项目自测

title: “综合项目自测”

综合项目自测

这份是最后做的。

如果你能把这份答得比较完整，说明你已经不是“看过项目”，而是真的在形成自己的体系。

综合题 1

如果现在让你自己做一个 AI 学习项目，你会在下面三条线里先选哪一条，为什么？

RAG
LLM from scratch
Alignment / Agent RL

要求：

结合你当前基础
结合投入成本
结合可见产出

综合题 2

请你解释这三条线之间的关系：

为什么很多人先从 RAG 做起
为什么只会 RAG 还不够
为什么理解模型本体后再学 alignment 会更顺

综合题 3

如果让你在 4 周内做一个自学计划，你会怎么排？

要求：

每周有主任务
每周有一个明确产出

综合题 4

如果让你做一个最小 capstone，你会选哪种？

本地文档 RAG
极小语言模型训练 demo
最小 alignment 实验

并说明：

为什么选它
你预计最难的点是什么
你的验收标准是什么

综合题 5

请你写一段自己的学习原则，至少回答：

你以后怎么避免“收藏一堆 repo 但不动手”
你准备怎么记录项目笔记
你怎么判断自己是真的学会，而不是只会复述

完成标准

如果你能把这份写完整，并且不是空话，说明你已经开始进入“自己驱动项目学习”的状态了。

参考答案

做完题再看：

RAG 参考答案
LLM From Scratch 参考答案
Alignment / Agent RL 参考答案
FastAPI / Full Stack Web 参考答案
综合项目参考答案

RAG 参考答案

title: “参考答案：RAG Systems”

参考答案：RAG Systems

对应题目：

RAG 自测题

这不是标准唯一答案，而是“合格答案长什么样”。

1.

RAG 可以理解成：

先去外部知识里找相关材料
再把找到的材料一起给模型
让模型基于这些材料回答

它和直接问大模型的区别是：

直接问更依赖模型参数里原本记住的知识
RAG 更依赖当前检索到的上下文
所以 RAG 更适合接私有知识、最新知识、特定文档

2.

最小 RAG 主链路通常是：

准备文档
把文档切块
为每个 chunk 建 embedding / index
用户提问
用 query 去检索相关 chunk
把检索结果拼进 prompt
让模型基于这些上下文回答

3.

因为生成阶段依赖检索阶段给的材料。

如果检索错了、漏了、噪声太大：

模型就可能缺少关键事实
或被无关内容干扰
最后即使语言流畅，答案也可能不准

4.

chunk 太大：

一次塞入的信息太杂
检索粒度太粗
容易检到包含目标但噪声很多的内容

chunk 太小：

上下文被切碎
检索到的片段可能缺少完整语义
需要更多拼接才能回答

5.

retrieval 负责：

找相关材料

generation 负责：

基于材料组织成自然语言回答

6.

优先检查三层：

数据和 chunk 层
retrieval 层
prompt / answer synthesis 层

如果这三层都没问题，再去看模型选择和更复杂增强。

7.

当用户问题本身不够适合检索时，query rewriting 有帮助。

比如：

问题太模糊
关键词不完整
用户表达方式和文档表达方式不一致

8.

因为初始检索经常会带来噪声。

filtering / reranking 的价值是：

留下更相关内容
去掉明显无关的 chunk
提高最终上下文质量

9.

因为复杂问题不一定一次检索就能回答。

planner / executor 结构适合：

先拆问题
再按步骤查
中间根据结果调整下一步

这更像多步搜索，而不是一次性问答。

10.

source attribution 的意义包括：

方便人工核验
增强用户信任
帮助定位错误来源
让系统更适合知识工作流

11.

rag-from-scratch 最适合帮你学：

最小 RAG 主链路
notebook 式实验
检索和生成是如何连起来的

12.

complex-RAG-guide 相比基础 RAG，多补了这些关键层：

cleaning
filtering
query rewriting
planner / re-planner
evaluation

13.

正确学法不是全看，而是：

按 technique 分类
每次只挑少量技术点
问“它在优化哪一层”
最后做对照实验

14.

deep-searcher 更像系统：

支持更多 provider 组合
有更完整配置层
有数据加载、查询、CLI、服务化思路

而 notebook demo 更偏教学和原型验证。

15.

合格答案应该能画出：

文档
chunk / index
query
retrieval
context assembly
generation
answer

16.

一个合格实验应该包含：

固定问题集
只改 top-k
比较回答准确性、相关性、噪声
最好记录 source 质量变化

17.

合理答案示例：

文档切块
检索
带来源的回答生成

理由：

这是最小可用系统
先把主链路做稳，比一开始上 planner 更重要

18.

合理删法示例：

先删 planner
先删复杂 evaluation

原因：

v1 最重要的是跑通主链路
复杂模块应该在问题真实存在后再引入

LLM From Scratch 参考答案

title: “参考答案：LLM From Scratch”

参考答案：LLM From Scratch

对应题目：

LLM From Scratch 自测题

1.

最粗的主链路是：

文本先被 tokenizer 切成 token
token 变成 embedding
embedding 经过多层 transformer block
输出每个位置对应的 logits
根据 logits 预测下一个 token

2.

tokenizer 负责把原始文本变成模型可处理的离散 token 序列。

它本质上定义了：

模型看世界的最小单位是什么

3.

因为 tokenizer 会影响：

序列长度
词片切分方式
稀有词处理
训练和推理效率

它不是边角料，而是输入表示的一部分。

4.

embedding 层负责把离散 token id 映射到连续向量空间。

这样模型才能在向量空间里学习模式。

5.

self-attention 的核心价值是：

每个 token 在计算表示时，可以动态参考其他 token

这让模型能建模长距离依赖。

6.

训练目标通常是：

根据前面的 token，预测下一个 token

7.

因为 language model 的训练数据天然可以转成：

输入前缀
目标下一个 token

这使得预训练能在海量文本上自监督进行。

8.

核心部件通常包括：

数据加载
tokenizer
model
loss
optimizer
training loop
checkpoint / logging

9.

因为这些超参会影响：

梯度估计稳定性
有效上下文长度
收敛速度
显存消耗

10.

训练入口更关注：

前向
loss
反向传播
参数更新

推理入口更关注：

给定 prompt
逐步采样生成 token

11.

MiniMind 最适合帮你建立：

小模型完整链路的直觉

12.

CS336 和普通教程的区别是：

它更系统
更接近课程和作业驱动
不只讲概念，也强调实现和工程视角

13.

因为你先有了一个小模型的整体感，再去看系统课程时，不会只剩抽象名词。

14.

合格图里至少要包括：

tokenizer
embeddings
transformer blocks
logits
sampling

15.

一个合理实现顺序可以是：

tokenizer
dataset / dataloader
embeddings
transformer block
LM head
loss
training loop
generation

16.

训练不收敛时，优先怀疑：

数据 / tokenizer 问题
学习率 / optimizer / batch 问题
实现 bug

17.

pretraining 学到的是：

语言模式
统计共现
一般性的文本建模能力

它没有直接解决：

指令服从
人类偏好
多步 agent 行为稳定性

Alignment / Agent RL 参考答案

title: “参考答案：Alignment / Agent RL”

参考答案：Alignment / Agent RL

对应题目：

Alignment / Agent RL 自测题

1.

因为 pretraining 主要学的是：

语言模式
下一个 token 预测

但这不自动等于：

听话
符合偏好
稳定完成多步任务

2.

SFT 主要解决：

让模型学会按示例格式和目标行为输出

3.

SFT 没完全解决：

长期偏好优化
多候选之间的相对优劣
多步行为稳定性

4.

因为 alignment 不只是“更像人类说话”。

它更关心：

是否符合任务目标
是否更符合偏好
是否减少不想要的行为

5.

Expert Iteration 的核心想法是：

先生成候选
筛掉高质量样本
再用这些更好的样本继续训练

6.

GRPO 和 SFT 的区别在于：

SFT 直接在给定 target 上监督学习
GRPO 更强调基于奖励或相对优劣来优化策略

7.

reward 负责把“什么更好”变成可优化的训练信号。

8.

因为训练要基于采样到的响应来估计好坏。

如果采样分布变了：

奖励分布会变
更新方向也会变

9.

多步 agent 更难，因为它涉及：

长轨迹
中间步骤误差累积
奖励分配更复杂

10.

trajectory 重要，因为 agent 的质量不只在最后一句话，而在整段交互过程。

11.

ModelAlignmentFromScratch 最值得学的是：

把 SFT、EI、GRPO 具体落到实现层

12.

因为 SFT 是最基础 baseline。

先看它，才能看懂后面的高级方法到底多了什么。

13.

OpenPipe ART 更强调：

agent task
多步 interaction
rollout / reward / training 的结合

14.

合格表至少能区分：

pretraining：学语言模式
SFT：学示例行为
EI：筛高质量样本后迭代提升
GRPO：基于相对奖励优化策略
agent RL：优化多步任务行为

15.

优先怀疑：

reward 设计不合理
任务定义不清
rollout 质量差
credit assignment 难

16.

一个最小 agent RL 任务可以这样定义：

task：完成一个简单多步查询或工具调用
reward：任务是否成功、步骤是否合理
success criterion：成功率是否提升、轨迹是否更稳定

参考答案：FastAPI / Full Stack Web

对应题目：

FastAPI / Full Stack Web 自测题

这不是唯一标准答案，而是“合格答案至少应该讲到什么”。

1.

前后端分离可以理解成：

前端负责页面、交互、展示
后端负责数据、业务逻辑、权限、数据库访问

它们通过 API 通信，而不是把所有逻辑都塞在一个页面里。

2.

一个最小全栈 Web 应用通常至少有：

前端页面
用户操作触发请求
后端 API 接收请求
后端逻辑读写数据库
返回响应给前端
前端更新 UI

3.

FastAPI 的价值包括：

定义 API 很直接
请求 / 响应结构清楚
自动文档很适合调试
很适合做现代 Web 产品后端

4.

最小流程通常是：

用户点击按钮
前端发送请求
FastAPI route 接收请求
后端执行业务逻辑
数据库被查询或更新
后端返回响应
前端根据响应更新页面

5.

因为页面能打开只说明前端资源加载成功。

不代表：

API 可用
认证正常
数据库连通
页面展示的是实时数据

6.

建议先看四个位置：

后端入口和 router
schema / model
数据库配置或 CRUD 逻辑
前端页面和 API 调用层

7.

route：

接收请求、返回响应

schema：

定义请求和响应的数据结构

model：

定义数据库里的数据对象

database：

真正存取数据

8.

因为认证决定：

谁能访问接口
谁能看到哪些数据
系统怎么识别当前用户

没有认证，大多数真实产品都不完整。

9.

前端拿到 token 后，通常还要处理：

token 存在哪里
请求时怎么带上 token
token 失效后怎么办
用户刷新页面后登录态是否保留

10.

因为全栈项目通常不只一个进程或服务。

Docker 和环境变量主要解决：

服务一起启动
环境配置隔离
数据库地址、密钥等配置管理

11.

full-stack-fastapi-template 最适合帮你学：

FastAPI 后端结构
前后端联动
认证
数据库 CRUD
一个真实全栈模板如何组织

12.

和 hello world 的最大差别是：

不只是一个接口能返回字符串
而是有真实的前端、数据库、认证和应用结构

也就是从“单点演示”变成“完整系统骨架”。

13.

你会漏掉：

前端如何发请求
登录态如何在 UI 侧处理
数据返回后怎么展示
一个功能怎样真正贯通到用户界面

14.

说明你还缺“贯通一次真实改动”的经验。

也就是：

从后端到数据库
从数据库到 API
从 API 到前端页面

这条链路还没真正走过。

15.

合格图至少要包括：

frontend event
API request
FastAPI route
backend logic
db operation
API response
UI update

16.

最少要检查这些层：

数据模型
schema
route 或业务逻辑
数据库存储
前端展示或表单提交

17.

合理答案示例：

用户登录
任务列表
创建 / 更新任务
数据库存储

理由：

这是最小可用产品链路
能把前端、后端、认证、数据库一起练到

18.

合理不做的事情示例：

先不做复杂权限系统
先不做很重的 UI 美化

原因：

v1 最重要的是主链路打通
复杂度应该在真实需求出现后再加

综合项目参考答案

title: “参考答案：综合项目自测”

参考答案：综合项目自测

对应题目：

综合项目自测

这份答案更像参考思路，不是唯一答案。

综合题 1

一个合理回答通常会体现：

先看自己当前基础
再看投入成本
再看可见产出

比如：

想快速做出作品，先选 RAG
想补根基，先选 LLM from scratch
已经有训练基础，再选 alignment

综合题 2

合理逻辑是：

很多人先做 RAG，因为更容易出应用成果
但只会 RAG，不代表理解模型内部
理解模型本体后，再学 alignment 才知道“后训练”在补什么

综合题 3

一个合格的 4 周计划，应该做到：

每周只有一个主轴
每周有明确产出
不是“看很多”，而是“做成一点”

例如：

第 1 周：最小 RAG
第 2 周：复杂 RAG 增强
第 3 周：小模型主链路
第 4 周：alignment 入门

综合题 4

一个合理选择通常取决于你的当前阶段：

初学者最适合本地文档 RAG
对模型内部有兴趣的人适合小模型训练 demo
已有训练基础的人适合最小 alignment 实验

关键是你要写清：

为什么选
最难点是什么
什么算完成

综合题 5

合格答案通常会包含这些学习原则：

每次只推进一个 repo
每个项目必须有运行结果或笔记产出
先最小复现，再做改动
用“能否解释 + 能否修改 + 能否设计实验”判断自己是否学会

最重要的一点

如果你的回答越来越具体，说明你真的在学习。

如果你的回答总是停留在“多看、多练、多理解”，说明你还没有把项目变成行动。

Keyboard shortcuts

AI Projects Self-Study Hub