大模型学习路线：从API调用到LoRA微调的完整实践指南

经常有人问我：能不能推荐一份 LLM 大模型系统学习路线。我一般不会急着甩链接，而是先反问两个问题：你现在手头有没有一个能独立跑起来的模型？最近一周写过几行调用大模型 API 的代码？如果两个答案都是否，那你大概率再过三个月，仍然停在“收藏了一堆资料却不知道从哪开始”的状态。

这不是打击人，而是我见过太多所谓“系统学习”的计划都死在了同一步：他们想先把理论学透再动手，结果在 Attention 公式那里就熄火了。大模型这个领域有一个反常识的事实——上手动手远比啃论文重要。你能把一个模型部署起来、调通一次对话、跑完一轮微调，你对它的理解会超过你看十篇解读文章。

这篇文章是我自己从零开始摸爬滚打踩出来的学习顺序，也是我后来带人时反复验证过的一套路径。它不是面面俱到的百科，而是一条能让你从“看着别人玩大模型”到“自己真正跑起来”的完整链路。内容覆盖原理补全、本地部署、API 调用、RAG 知识库、Agent 开发、LoRA 微调，以及信息源和知识管理。适合刚入门想系统掌握的学习者，也适合已经会用现成产品、但想进一步自己做应用和私有化部署的人。

1. 学习大模型一年还觉得没入门，问题出在哪

1.1 无差别刷论文是劝退率最高的路径

我见过太多人的学习路线的第一步是：找一篇经典论文，比如 Attention Is All You Need，然后开始读。读到了多头注意力机制里的 Q、K、V，觉得不行，得先补线性代数；补到矩阵乘法，又发现需要概率论基础；绕了一圈回到论文，发现还有残差连接和 LayerNorm 要理解。三个月以后，进度条还停在 0.1，心态已经崩了。

问题不在于“你不够聪明”，而是把研究型路线和工程应用型路线混在了一起。

我们可以把大模型领域的知识粗略分成三层：

• 应用层：调用 API、写提示词、搭 RAG、做 Agent、设计业务流、处理模型返回的结构化数据。绝大多数人最终的工作岗位落在这里。
• 原理层：Transformer 架构、Token 与 Embedding 的运行逻辑、预训练与对齐的本质、推理参数的直觉、量化与显存估算。这部分是选型、调参、排查问题时的“地图”。
• 底层实现层：自己设计模型结构、研究新的注意力变体、编写分布式训练框架、做内核级推理优化。这是少数科研和核心算法工程师需要做的事。

很多入门资料默认把第三层当成第一站，这是学习路线中最大的错位。如果你目标是做 AI 应用、企业落地、私有化知识库，那就应该先吃透应用层，再补充原理层里那些“不得不懂”的块。等你真的在业务里遇到性能瓶颈或模型能力上限，再往下钻也不迟。

1.2 先建立 LLM 的能力边界，再去动原理

在学任何细节之前，先搞清楚大模型到底是个什么东西。

用一句话概括：大模型是从海量文本中训练出来的“下一个词预测器”。它通过预测下一个词，学到了语言的统计规律，也把一部分世界知识压缩进了参数里。但它的本质不是数据库，也不是搜索引擎，更不是一套可以精确计算的逻辑系统。

它擅长什么？文本生成、摘要、改写、翻译、代码补全、情感分析、从非结构化文本中抽取字段。它不擅长什么？精确的数学运算、实时信息获取、需要长期记忆的复杂推理、不需要外部依据就能保证真实的陈述。

打个比方：大模型像一个知识面很广但偶尔会记混细节、被追问时还会硬着头皮圆场的同事。你对一位这样的同事会怎么用？交代任务时给一份清晰的需求文档，重要信息放在它“眼前”，让它查资料而不是凭印象回答。这个比喻能帮你理解后面非常重要的一对技术：RAG 是为了提供证据，Function Calling 是为了让它能调用工具。当你给模型接上检索和工具，它才从“一个会说话的脑子”变成“一个能干活的员工”。

1.3 学习路线里的“里程碑感”比什么都重要

学习大模型遇到困难时，绝大多数人无法判断“自己是哪里没懂”。这是因为学习内容太宽泛，缺少可验证的反馈节点。所以我强烈建议：不要按“读完全部理论再开始实践”的方式安排学习，而要把每个阶段都设计成能拿出一个成果的里程碑。

我的建议是设置四个里程碑：

1. 用 API 跑通至少 10 个不同任务，比如摘要、翻译、情感分析、JSON 抽取。
2. 在本地成功跑起一个开源模型，并完成一次带参数的推理调用。
3. 做一个基于私有文档的知识库问答系统，哪怕只是几百个 markdown 文件。
4. 用几百条数据完成一次 LoRA 微调，并对比微调前后的效果差异。

这样安排最大的好处是：每当你卡住，你面临的都是“某个具体功能不工作”的问题，而不是“我是不是还没有入门”的虚无感。问题一旦具体，解决路径就清晰了。

2. 理论不是背公式：用“够用”原则吃掉原理门槛

2.1 四个必须懂的概念：Token、Embedding、Attention、训练阶段

很多零基础的朋友是被公式吓退的。但做工程应用，你不需要手推反向传播，也不需要证明注意力公式收敛性。有几个概念是绕不开的，因为它们直接决定你写代码时的思路。

先来说 Token。模型读文本的最小单位是 token，不是一个字或一个词。一段中文可能被切分成很多个 token，有些汉字会被切得更碎。你调用大模型时要清楚：上下文窗口按 token 数计算，计费也按 token 数计算，返回结果可能因为超出窗口而被截断。很多人碰到“模型回答到一半停了”，第一反应是换模型，实际原因是 token 预算没规划好。

再是 Embedding，也就是把文本映射成高维向量。语义相近的两个句子，在向量空间里的距离也相近。这一步是检索的基础，你在做知识库问答时，靠的就是“把问题和知识片段都转成向量，再计算距离找相近内容”。注意，负责向量化的 Embedding 模型和你聊天的生成大模型是两类不同的模型，各有各的模型文件。

然后是 Attention，这是让模型能真正理解上下文的关键。可以把它理解成：模型生成下一个词时，会重新“回看”前面所有内容，并给每个位置打分，决定哪些词更重要。这解决了早期循环神经网络记不住长距离信息、无法并行训练的问题。今天的模型几乎是围绕 Attention 机制构建的，所以了解它的直觉就够了。

最后理解大模型的 训练流程。预训练阶段，用海量语料教模型预测下一个词，让它获取知识和语言能力；指令微调阶段，用“指令-回答”配对让它学会问答形式；对齐阶段，再用人类偏好反馈（RLHF/DPO 一类方法）让回答更符合人的预期。你在推理时调 temperature 影响的是随机性，跟模型“理不理智”关系不大。这些不用深究细节，但有了这个框架，你看任何大模型新闻都能快速归类——它在描述哪个阶段的能力。

2.2 经典论文这样读，才不会被劝退

如果你想在原理上再进一步，论文肯定绕不开。但不建议从原文第一页开始精读，顺序和读法都很有讲究。我推荐的顺序是：

1. 先看 3Blue1Brown 关于 Transformer 的视觉化视频，建立一个“注意力”的几何直觉。
2. 再看一份入门级课程，比如吴恩达的提示词工程专项，先明白模型能干什么。
3. 然后按时间线叠读论文：Attention Is All You Need（看框架图和结论）→ GPT-2 和 GPT-3（看 few-shot 现象的发现）→ InstructGPT（看人类反馈如何引入）→ Llama 系列技术报告（看开源生态成熟的过程）。
4. 最后有余力再啃 Chinchilla Scaling Laws，了解模型参数和训练数据量之间该保持什么比例。

每篇论文第一遍只读摘要、导论、结论和框架图就够了，不需要逐行理解实验细节。真正需要精读的时刻，是你自己跑完 nanoGPT 这类项目、对训练和生成有了感性认识之后。到那时回头再看论文，很多“看不懂的地方”会自己消散。

很多科普文章动不动就抛出“模型的本质是压缩”“涌现能力”“思维链”之类的概念，这些词对入门者是有害的——你还没有足够的上下文去校验它们对不对。先把手上的技术链路打通，再用工程实践去验证抽象概念。

2.3 数学和代码，究竟要补到什么程度

被问得最多的是：“我数学不好，能学大模型吗？”

看目标。如果只做应用开发，你只需要线代里“两个向量做内积”的直觉、知道矩阵乘法表示变换就够了。看到 Q、K、V 不要慌，说白了就是把同一段文本用三个不同的矩阵投影成三份向量，然后做相似度计算。真正需要认真补数学的时刻，是你开始看损失函数、梯度下降、学习率调度的时候，那基本发生在你想自己训练模型或调优训练策略之后。那时你已经有强烈动机，学起来效率会高很多。

代码方面也一样。搭 API 和跑开源模型，你需要的是 Python 基础、会读 JSON、会发 HTTP 请求、能调试报错。不需要从零实现反向传播。如果连 DataFrame 都还没用过，先花一周把 Python 基础过一遍即可。很多人卡在没有启动环境，被各种依赖冲突劝退，这个在部署章节我会展开讲。

3. 把模型跑起来的三种方式：API、本地量化、高性能推理

3.1 第一周就先调 API，别碰本地部署

我不理解为什么很多教程教人第一天就去下载几个 GB 的模型。本地部署这条路的坑太多，环境冲突、模型权重下载速度慢、显存不足、量化参数选错，任何一个都会让新手一天时间清零。

第一周的正确姿势是：注册一个开放平台的账号，获取 API Key，把第一次联网调用跑通。目标不是省钱，而是快速体验“模型是怎么响应你的”以及“Prompt 参数如何影响输出”。

你在代码里要做的事很简单：

1. 安装官方或兼容的 SDK。
2. 在环境变量里配置 key，而不是硬编码到项目里。
3. 发送一段 system prompt 和 user message，拿到回复。
4. 再试着让模型输出 JSON，比如提取一段文本里的姓名、日期、金额，并展示如何解析。

这里有一个很容易被忽略的工程习惯：不要把你的密钥提交到 git 仓库里，用 .env 文件配合 python-dotenv 管理。泄露密钥带来的损失远比你想的严重。API 调用调试时，多关注三个参数：temperature 控制随机性，max_tokens 控制最长输出，response_format 控制是否输出结构化内容。

3.2 本地部署的硬件账：显存决定你能跑多大模型

当你有了 API 的体感，下一步是本地跑开源模型。这事的核心约束只有一个：显存决定上限，其他配置都是次要的。

从公式说起。一个 7B 参数模型，如果用 FP16 精度存储权重，大约需要 14GB 显存（7 × 10^9 × 2 字节 ≈ 14GB）。但这只是权重文件的体积，实际推理时还要留出 KV Cache、激活值的空间，所以一张 16GB 显存的显卡，跑 FP16 的 7B 模型是比较勉强的。

因此量化成了本地部署的关键。量化就是降低每个权重占用的比特数，精度略有损失，但显存压力大幅减小。按照社区约定俗成的做法：

• 7B 模型 Q8 量化大约需要 7-8GB 显存，Q4 量化大约 5-6GB；
• 14B 模型 Q4 大约需要 10-12GB；
• 32B 模型 Q4 大概需要 20GB 左右；
• 70B 模型 Q4 想跑得流畅，单张 48GB 的显卡很勉强，最好上多卡。

粗算公式是“参数 × 每权重比特 / 8”，但建议再留 30%-40% 的余量给 KV Cache。这也是为什么很多人在 8GB 老显卡上跑 7B 模型会报“CUDA Out of Memory”，不是模型文件装不下，而是推理过程产生的中间变量爆了。

对新手最友好的本地部署工具是 Ollama。它把 llama.cpp 的底层推理能力和模型下载、运行管理都封装好了，你用一条 ollama run qwen2.5:7b 就能把模型跑起来。它背后用的是经过量化的 GGUF 系列模型文件，把这些文件放入显存/内存进行高效推理。对比之下，vLLM 是面向高并发生产环境的推理框架，吞吐量很高，但对显存和 Linux 环境要求也更严格，不适合个人入门阶段用。等你的应用真正有了相当量级的并发请求再迁移过去也不迟。

3.3 我踩过的本地部署坑：镜像、并发与量化选型

给所有走本地路线的读者几个实战提醒，这些我全都亲自吃过亏：

首先，模型下载慢不要蛮等，先看源。 Ollama 和 Hugging Face 在部分地区直连速度不理想，可以提前配置镜像源。Ollama 修改模型仓库地址，Hugging Face 则设置 HF_ENDPOINT 环境变量指向镜像地址，不敏感的网络环境下速度能提升很多。这是配置常识，不是技术难题。

其次，本地模型不是拉下来就能满负荷跑。 默认情况下 Ollama 对并发请求是排队处理的，如果一个请求没结束，第二个请求会等着。要支持多个用户同时访问，需要设置并发处理参数，比如 OLLAMA_NUM_PARALLEL。这类环境变量你在部署到服务器前先想清楚，不然前端应用一接入立刻变“假死”。

再次，量化版本选择不要太贪。 同一款 7B 模型会提供 Q2_K、Q4_K_M、Q5_K_M、Q8_0 等一堆量化文件名。新手入门别选 Q2，虽然体积小，但回答质量已经变形了；也别盲目上 Q8，体积大但换来的是边际收益。一般选 Q4_K_M，这是社区反复验证过的质量和体积平衡点。

注意：本地模型效果明显“变笨”时，先检查自己加载的是什么量化版本，不要一上来怀疑硬件或平台。

本地跑通 7B 模型后，建议你再试一个 14B 或 32B 模型，感受一下不同参数量之间存在的能力差异。这种感知比读任何技术报告都直观。

4. 从回答问题到完成任务：RAG、Function Calling 与 Agent 是怎么串起来的

4.1 RAG 知识库：本质是给模型“开卷考试”

模型训练好之后，它的知识停留在某个时间点，同时也可能缺少你业务里的私有信息。你要么重新训练它，要么——更聪明的做法——每次提问时，把相关资料放在它眼前。

这就像你公司里新来一位能力很强的实习生。你问它公司内部的报销流程，它答不上来，但这不怪它，因为它的培训资料里没有这部分内容。最有效的方法不是把它送回培训中心重学一遍，而是直接递上一份《公司报销制度手册》，告诉它：答案都在里面，照着答。

RAG（检索增强生成）就是这套思路。一个最简单的 RAG 管线长这样：

1. 把文档按合理尺寸切分成片段（chunk），比如每 500 字左右一段，部分重叠；
2. 用 Embedding 模型把每个片段转成向量，存入向量数据库；
3. 用户提问时，把问题也向量化，在库里做相似度检索，找出最相关的 Top-K 片段；
4. 把这些片段和用户问题一起拼进 Prompt，要求模型只依据片段回答，并标注来源。

实际跑通之后你会发现，真正的工程难点全在细节里。切得太碎，语义散了，检索定位不准；切得太长，片段里噪音太多，模型抓不住重点。向量库选型也要考虑规模：几千个片段的个人项目用 Chroma 或 FAISS 完全够用；到了企业级百万级向量，再考虑 Milvus、Qdrant 这类分布式方案。

顺便推荐一个能快速验证 RAG 价值的现成方案：AnythingLLM 这类开源工具，它会帮你处理文档上传、向量化、检索问答的整个流程，甚至支持多人通过网页访问。不想写代码的时候，用它把你的 Markdown 笔记丢进去，马上就能得到一个针对自己知识库的问答机器人。我最初理解“RAG 到底比直接塞 Prompt 好在哪”，就是通过这类工具快速感知到的。

4.2 Function Calling：让模型学会“调工具干活”

大模型终究只是“会生成文本”，它没有能力去查天气、执行代码、查询数据库、触发支付。但你可以给它一套说明书，让它决定什么时候需要这些外部能力。这就是 Function Calling（函数调用）存在的意义。

它的工作方式和大多数人想象的不一样。并不是“模型去调用函数”，而是模型在生成结果时，会输出一段“我想调用哪个工具、传什么参数”的结构化信息，由你的代码接收后真正执行对应函数，再把执行结果返回给模型，让模型基于真实结果继续生成回答。

举个例子：用户问“帮我查一下北京的天气，如果下雨就提醒我带伞”。你不需要在代码里做 if 判断，而是把 get_weather(city: string) 这个工具连同参数说明一起发给模型。模型自己会判断“这需要调用天气工具”，然后返回一个 tool_call。你的代码调完天气 API，再把“北京，小雨，23℃”作为消息发回给模型，模型最终生成“北京今天有小雨，出门记得带伞”。

这就是 Agent 的最小闭环：模型负责做判断和规划，工具负责做执行，代码负责把它们串联起来。把 LLM 理解成一台“路由器和调度器”会更准确——真正的计算和动作，发生在你给它外接的工具里。所以要做 Agent，不需要让模型变聪明，而要给模型更多趁手的工具。

我在做这类功能时踩过一个大坑：当强制要求模型输出特定 JSON Schema 时，有些模型会频繁报格式错误，尤其在字段很多、嵌套很深的情况下。解决办法有两个，一是降低强制约束的复杂度，拆成多个小任务；二是在代码里增加重试和校正机制，不要假设模型第一次输出就规范。

4.3 应用框架的取舍：别被框架绑架，先用原生代码跑通

做 RAG 和 Agent 时，很多人第一反应是上 LangChain 或 LlamaIndex。我个人的建议恰恰相反：先别碰框架，用原生代码手写一遍流程。一条完整的 RAG 链路，在 Python 里实现不过几百行代码。你会发现 Embedding、向量检索、拼 Prompt 这一套逻辑其实不复杂，困难在于业务数据的多样性。

框架当然有价值。LangChain 生态最大，抽象最全，但它的抽象层级很多，出了问题排查链路很长。LlamaIndex 更偏向文档索引和检索场景，如果核心需求是“喂一堆文件进去做问答”，它会很顺手。但不管哪个框架，都建议在理解了底层原理之后再去用。

对于非开发向的朋友或者想快速验证想法的场景，图形化方案则友好得多。AnythingLLM 或是 ccgui 这类工具能让你在图形界面里完成模型接入、知识库配置、文档上传和共享。它们适合快速看效果，但不适合作为严肃产品的基座，因为业务定制会受限于界面提供的能力。

近几年还有一个趋势值得关注：把 LLM 接进命令行工具，比如 Codex CLI，让大模型协助你完成代码任务。这本质上也是 Function Calling 的一种应用形态——模型生成命令和参数，本机工具执行并反馈结果。这不一定是学习阶段的必修内容，但它能帮你打开思路：大模型的应用边界远远不止“聊天窗口”。

5. 微调实践的真正价值与最低成本路径

5.1 微调前先问自己三个问题

很多同学学到 RAG 之后就觉得自己懂了大模型应用的半壁江山，下一步就开始想：“我要不要微调一个属于自己的模型？”我的回答通常是：先等一下，理由还没找够之前别动手。

微调并不是“让模型学会新知识”的灵药。打个比方，RAG 像考试时给你一本参考书翻，微调像在考前给这个人做长期特训。特训当然有用，但如果只是为了一次考试里的几个知识点，发参考书就够了。

那么什么情况下需要微调？我总结为三种：

1. 稳定地复现一种格式。你希望模型每次回答都严格遵守某种企业级输出格式，反复用提示词约束仍然不稳定，或者不希望每次请求都携带超长指令。
2. 特定风格和语气。比如你是一个小说创作平台，要求模型输出固定的角色语气和文章脉络，提示词只能做到“模仿”，微调才能做到“内化”。
3. 稳定改善某些任务能力。比如你希望模型只做医疗报告的字段抽取，字段之间还有很细的逻辑依赖。

同时问自己三个现实问题：你有几百条以上高质量任务数据吗？你接受用这部分数据覆盖模型原有的部分行为吗？训练失败的坏结果你能接受吗？如果某个问题的答案是否定的，那大概率应该回到提示词工程和 RAG 路线。

5.2 LoRA、QLoRA 与全参微调：用一张表说清成本差异

决定要微调了，下一步是选方案。主流选择是三种：

全参微调为什么贵？因为训练要同时保存模型参数、梯度、优化器状态，这比单纯做推理时占显存大好几倍。别说消费级显卡，个人开发者租用 A100 的月成本也谈不上便宜。相比之下，LoRA 只训练插入在模型里的低秩矩阵，冻结原始权重，训练参数量可能连总数的 1% 都不到。QLoRA 则更进一步，把基座模型量化成 4bit 再去挂 LoRA 层，让 8GB 级别的消费卡也能跑起 7B 微调。

我个人的态度很明确：个人学习阶段，直接从 QLoRA 开始。它不是最好的方案，但它是让你最快跑通完整流程、花最小的钱的方案。等理解训练流程之后，再根据业务情况判断要不要升级到纯 LoRA 或全参微调。

训练结束之后，LoRA 适配器要合并回原模型再保存，否则单独存一个适配器文件，部署时每次都要先加载基座再挂适配器，非常麻烦。合并量化后的模型可以直接用 Ollama 部署，微调就能顺畅地拼接到你前面已经搭好的推理链路里。

5.3 数据集构建与效果评估：决定微调质量的不是数量

微调的数据集是整条链路里最容易被低估的部分。很多人觉得“我拉几万条数据扔进去跑一夜，肯定比几百条强”。实际效果往往相反：数据质量和一致性对微调结果的影响，远大于数量。

我建议第一次尝试时准备 500 到 1000 条“system, user, assistant”三段式对话数据。每条数据都意味着一个场景，而不是把同一句话换个主语重复好多遍。数据样本之间的差异越大，模型越不容易过拟合，效果越稳定。

数据覆盖哪些方面？首先决定模型输入触发场景，然后覆盖你希望它学会的输出规律。比如要做抽取任务，就要覆盖各种异常输入：字段缺失怎么回答，有歧义怎么回答，实在没有信息时怎么拒答。这些边界案例价值在于让模型掌握“什么情况下不能胡说”。

训练时会遇到一个容易误判的点：loss 值下降并不代表模型能力提升。你堆更多训练步数，loss 一定会降，原因是模型“背”住了这批数据，但遇到没见过的同类问题可能依然不行。所以要留出一部分数据完全不参与训练，作为验证集。每次训练完，在验证集上检查模型是否学到了“规则”，而不是“背下了答案”。我更习惯再找一份别人做的同领域公开评测集跑一遍，用数据对比微调前后的准确率变化。

另一个常见的坑是数据污染。如果你微调后做评测，用的数据恰好也在训练集里，那结果不具备任何参考意义。做知识库问答场景，尤其容易发生这种问题——许多评测问答其实来自原始文档，而原始文档恰恰已经被切进训练集。评估时务必留一条干净数据做手工测试。

6. 信息源过滤与我的四阶段学习路线

6.1 资源越来越杂，筛选信息源比收集更重要

大模型圈子的更新节奏极快，一个周末不上网就会出现新工具、新模型、新概念。收集信息并不难，难的是判断哪些信息值得看。我的信息源筛选标准大概有这几条：

官方文档永远排在第一位。 模型厂商的官方文档讲提示词技巧、参数含义、接口约定，信息密度高，且不会过时。很多人宁愿看二手短视频也不愿读文档，这是最不划算的学习方式。

顶级研究者的教学内容优先。 Andrej Karpathy 的资源是我的第一推荐。他的视频课 Neural Networks: Zero to Hero 以及他维护的 LLM 学习仓库里的 nanoGPT 项目，深入浅出程度至今无人能出其右。你不需要完全实现它，哪怕只把 nanoGPT 的代码读通，再看整个领域的新闻都会觉得亲切不少。

开源社区的实践经验排在论文前面。 很多论文讲的是理想情况下的能力，但社区里那些报错记录和实测对比才更接近真实世界。比如“哪个量化版本最适合 8GB 显卡”“这个 Embedding 模型在中文长文档里是不是不如那个”，这些都是实践积累，论文里不会写。

6.2 用 Obsidian 这类工具，把知识管理做成长期资产

大模型知识不像教科书那样稳定，三个月前的结论可能三个月后就被推翻。与其依赖“收藏夹吃灰”，不如建立一个自己的知识库工作流。我自己用的是 Obsidian，原因很简单：它支持本地 Markdown，所有笔记都是纯文本文件，后续想把这些内容喂给我自己的 RAG 应用也毫无障碍。

我的记法不算复杂：

• 每学一个新的技术点，就单独建一篇笔记，比如“量化（GGUF）”“KV Cache”“VLLM 部署参数”；
• 笔记里记录三个部分：这个概念的直觉解释、我实际用过的命令和参数、以及踩坑记录；
• 利用双链把相关概念串起来，比如“量化”笔记链接到“Ollama”“vLLM”“显存估算”。

这样做一段时间后，你会发现自己积累了一个可检索、可关联的第二大脑。如果觉得自己的笔记已经足够多，还可以用 AnythingLLM 或自己手写 RAG，把整份 Obsidian 笔记变成可对话的本地知识库。到这一步，你学的知识就不仅是被动记录，还成了你练习 RAG 的试验场。一个初学者最容易犯的错误是“只存不写”，看到资料就收藏，第二天问他昨天看了什么，答不上来。有意识地用输出和管理去倒逼输入，效率翻倍。

6.3 直接可抄的四阶段执行路线

最后给一条可以直接照着执行的路线，每一阶段都有明确的产物，做完一个阶段再进入下一个阶段。

阶段一：API 实验期（预计 1-2 周）。注册平台账号，写代码调用对话接口。要求自己完成 10 个小任务：总结长文本、翻译、情感分析、代码解释、生成 JSON 抽取、角色扮演对话、多轮上下文问答、改写风格等。这阶段产出的核心能力是：理解 system/user/assistant 的角色逻辑，能控制输出格式，能读懂报错信息。没有完成这些任务之前，不要进入下一步。

阶段二：本地部署期（预计 1-2 周）。用 Ollama 跑起一个 7B 量级模型，再换成一个 14B 或更大的模型，手动比较速度和生成质量的差异。学会通过环境变量调整并发，设置模型下载目录，查看推理日志。这阶段的意义是建立“模型文件、上下文窗口、显存占用”这些底层资源的体感，否则你后面做应用会遇到很多“不知道为什么这么慢”的玄学问题。

阶段三：应用集成期（预计 2-3 周）。做一个私有知识库问答系统，或者一个带 Function Calling 的轻量 Agent。开始时可以用现成项目改造，但至少理解整个链路的每一步。完成后要求自己能从头写一遍不带框架的 RAG 流程。

阶段四：微调探索期（预计 2-3 周）。用 QLoRA 在 7B 模型上微调，数据量控制在 1000 条以内。重点不是追求指标提升，而是跑通从数据准备、训练、合并权重到本地部署的完整闭环，然后比较微调前后的输出在格式和风格上的差异。

如果每周能投入 8 小时左右，零基础的人大致需要 2-3 个月走完这四阶段。其中至少有一半时间会花在环境配置和报错调试上，这非常正常——我当初第一次跑微调光解决 CUDA 版本冲突就花了一个周末。不要因此怀疑自己的学习能力，这些问题本质上都是“经验问题”，踩过一次之后，下次就再也不怕了。

从动手的那一刻起，你学到的每一个概念都会自动找到它的坐标：部署时你理解了量化，写 RAG 时你明白了 Embedding 和相似度检索，跑微调时你看懂了训练集为什么不能拿去评估。知识是在解决具体问题的过程中成体系的，不是靠收藏一堆资料堆出来的。 先跑通一版，跑通了，你自然会知道下一步该学什么。