大模型系统性入门：从原理、提示词工程到微调与部署的完整路径

写给想做“大模型”的人：一份真正能照着走的系统性入门资料

这两年我经常在后台收到一类问题：“想学大模型，我应该买什么课？看哪本书？能不能直接甩我一份资料清单？”说实话，每次看到这种问法我都挺着急的。大模型这个领域跟传统软件开发不一样，它没有“标准教材”，因为技术迭代速度快到纸质书刚印刷完，里面的内容就被新的方法论覆盖了。但反过来说，它又比很多人想象的更有迹可循。我把过去这一年多从零带团队、做微调、搞部署踩出来的经验，整理成一份尽可能完整的系统性入门资料，既不堆术语，也不灌水，你想走应用路线也好，想往工程方向钻也罢，按这个路径走下来，至少能省掉三个月盲目试错的时间。

这份内容适合三类人：刚入行想找工作但不知道怎么学的新人；已经在用API写业务、想深入了解原理和本地部署的开发者；以及传统算法工程师想转大模型方向、需要快速建立体系化认知的人。老规矩，文章不长篇大论谈人生规划，只讲一个学习主线——从理解大模型原理，到掌握提示词工程，再往下到微调和部署，最后落到工程化框架选型，每一条都是能直接落地的。

1. 先想清楚：你到底想“会”大模型的哪一块

1.1 大模型从业者的四条典型路线

很多人在学习路径上纠结，本质是没有意识到这个领域已经被拆成了几个差异巨大的工种。我把身边接触到的真实从业者分成了四类。

第一类是“应用层开发”，主要工作是调用现成模型API，做AI Agent、智能客服、内容生成工具。这类人不需要懂模型内部有多复杂，但必须把提示词工程、上下文工程、函数调用、流式输出这些基本功练扎实。第二类是“开源模型工程化”，主要工作是本地部署开源模型、做量化压缩、搭推理服务，再用LoRA之类的方案微调领域模型。这需要你懂Linux、懂GPU显存管理、懂推理引擎配置，是纯正的工程岗。第三类是“预训练/后训练研究员”，工作涉及数据清洗、指令微调、对齐、强化学习，普通公司里这个岗位比例不大，但薪资门槛最高。第四类是“AI产品与解决方案”，不写太多代码，但对模型能力边界、成本估算、风险评估要有敏锐判断。

你会发现，这四类人对“大模型原理”的需求深度完全不同。应用层知道Transformer大概是“注意力机制处理序列关系”就够了；工程化路线则需要理解KV Cache是省显存还是省时间、量化为什么会导致精度下降；研究路线才需要死磕Attention计算公式和损失函数。所以第0步不是搜集资料，而是确定你属于哪一类。坦白讲，我见过最多的人，是拿着研究员的资料清单去学应用开发，最后一个月就放弃了——不是他们笨，是学习内容和目标错配。

1.2 我建议的入门顺序：先会用，再深挖

除非你有扎实的机器学习基础且目标明确就是做训练算法，否则我的建议永远是“先会用，再深挖”。这个顺序可能跟很多课程先讲数学原理不一样，但它是效率最高的。

先用ChatGPT、Claude这些成熟产品，或者直接用开源模型跑个本地对话，感受一下“大模型到底能做到什么程度”；然后学提示词工程，理解模型的交互习惯和局限性；接着开始看模型原理，重点不是数学推导，而是搞清楚“输入的文字是怎么变成向量、又是怎么一步一步生成文本的”；之后再谈微调、部署、Agent框架。

为什么这个顺序有效？因为大模型本身就是个“通过大量实践才能建立直觉”的东西。我见过一个从零开始非要把Transformer论文啃完再动手的人，啃了两个月还是云里雾里，后来先跑了一个微调demo，再回头看论文，反而一周就通了。原理需要实践来锚定，纯纸上谈兵很难真正理解。先跑通一条最小链路，后续的知识点才有附着点。

1.3 资料怎么选：不迷信口水课，也不硬啃论文

现在市面上的资料大体分三类。科普类内容，适合通勤时建立直观感受，但别指望学了就能干活；系统课程类内容，质量参差不齐，很多是“复读机式”地把文档念一遍；真正有价值的是一手资料——各大模型公司官方的技术博客、推理引擎的官方文档、Arxiv上的经典论文，以及GitHub上真实项目的README和Issues。

我的经验是：科普类内容控制在总学习时间的1/3以内，剩下2/3时间留给动手。你在网上看到的所有关于“注意力机制”的精美动图，都不如你亲手把一段文本跑进模型里、再看输入输出变化来得深刻。另外一个很多人忽视的信息源是“失效的报错信息”——部署或者微调时遇到奇奇怪怪的报错，去GitHub Issue里搜索，你会发现所有着急的人都在这里提问，而维护者的回答往往比文档更贴近真实场景。

2. 地基是大模型原理：别再只看科普动图了

2.1 从“预测下一个词”讲起：语言模型到底在学什么

很多人觉得大模型神秘，其实它的核心训练目标朴素得让人意外：给定前文，预测下一个词的概率。比如给你一句“今天天气真”，模型的任务是算“好”这个词出现的概率是多少，“糟”是多少。就这样一个目标，配上超大规模的文本数据和动辄上千亿的参数，一路迭代，就涌现出我们看到的推理、对话、写代码能力。

为什么要先想清楚这件事？因为后面所有概念都跟它挂钩。你给模型写提示词，本质是在构造前文条件，让模型在这个条件约束下生成它认为“最合理”的下一个词；你担心模型“胡说八道”，本质是因为下一个词是从概率分布里采样的，不是从数据库里检索出来的；你看到上下文长度限制，本质是模型处理前文信息时，Attention计算复杂度太高，没法无限延长。

作为学习者，不需要一上来就推导反向传播公式，但至少要建立“一切生成皆概率”的直觉。有了这个直觉，你才算真正开始理解模型。

2.2 避开死记硬背：用工程视角理解那几个关键组件

如果你去看大模型原理的文章，大概率会被这些词淹没：位置编码、多头注意力、归一化、激活函数、KV Cache、MoE。我建议你换个心态，不要把它们当数学公式去背，而是当成“一套解决特定问题的工程方案”。

位置编码解决的是“模型怎么知道词的前后顺序”的问题，因为Attention本身是不带顺序信息的，哪怕把一句话的词序打乱，计算结果也一样，所以必须额外加位置信息。多头注意力解决的是“一个模型能不能同时关注多个维度关系”的问题，分成多个头，每个头关注不同的关系子空间。KV Cache解决的是“推理时为什么显存消耗那么大”的问题，因为生成每个词时都要重新计算之前所有词的结果，缓存之后就能省掉重复计算。

MoE（混合专家）解决的是“模型很大但推理能不能便宜点”的问题，它让每个token只激活一小部分参数，相当于一个公司表面有几千人，但处理每个具体任务时只调用一个十来人的小组。工程视角的好处是，你在部署模型遇到显存不足时，能立刻反应过来可能是KV Cache占了太多空间；你在调参时看到上下文长度增加导致速度下降，也大概知道瓶颈在哪里。这些知识在真实工作里比推导公式有用得多。

2.3 训练和推理是两套逻辑，别搞混了

初学者最容易错乱的，是把训练和推理混在一起。训练阶段是“模型学习参数”的过程，需要计算梯度并更新权重，所以它既吃显存又吃算力，而且训练数据要批量喂入，显存占用远大于单条数据。推理阶段是“模型用已经训练好的参数来生成内容”的过程，不再计算梯度，但同样要占用显存，因为模型参数本身要加载进去，生成的上下文也要存起来。

用生活化的类比：训练就像学生备考，要刷大量习题、不断订正错题，费时间也费脑力；推理就像高考答题，要在一个有限时间内把学到的知识调用出来，但不用再重新听课。很多人在本地部署时犯的第一个错，就是用训练模型的显存标准去估推理需求，结果被OOM（显存不足）打到怀疑人生。后面聊部署时我会把具体数字列出来。

3. 提示词工程与上下文工程：性价比最高的一课

3.1 别再问“如何写提示词”，先分清楚两个概念

如果说大模型是引擎，提示词就是方向盘。但我想先给“提示词工程”和“上下文工程”画一条界限。前者的核心是“怎么跟模型对话”，会后者的核心是“怎么在上下文中组织信息，让模型更好地完成任务”。两者有关系，但侧重点不同。

提示词工程偏重的是指令设计：你怎么描述任务，模型才会生成符合预期的结果。上下文工程偏重的是信息编排：你把多少背景资料、多长示例、什么样的知识库检索结果放进上下文里，模型才能基于这些材料作答。举个场景，你在做客服机器人时，提示词工程负责写“你是一个专业客服，语气要耐心”这类角色指令；上下文工程负责决定“把用户历史订单信息放前面还是放后面、检索到的知识片段要给几条”。

学习顺序上，先掌握提示词工程，因为它门槛低、见效快，能在几小时内看到明显效果；但如果你想做严肃的落地应用，上下文工程才是决定业务上限的关键——同样的模型，上下文组织得好不好，效果能差出一大截。

3.2 几个实战中真正有用的模式

我在实际项目里反复用到的提示词技巧，其实就那么几个，并不玄乎。第一个是“角色设定+任务描述+输出格式约束”的三段式结构。角色设定给模型一个视角，任务描述告诉它做什么，输出格式约束让结果直接能进下游程序。

第二个是Few-shot，也就是给模型展示几个输入输出对。它的作用不是“教”模型新知识，而是告诉模型“我期望的输出长什么样、风格是什么、结构怎么组织”。这个模式在解析非结构化文本时特别管用，用两个例子就能让模型从“自由发挥”变成“照着样例来”。

第三个是“让模型先思考再回答”。你可以直接要求“先在内部推理，再给出最终结论”，也可以用追问的方式引导。对复杂推理任务，这招的效果是立竿见影的，但代价是增加输出tokens和延迟，实际项目中要做平衡。

第四个是结构化输出。让模型直接输出JSON，前提是你把JSON字段的含义、取值范围都定义清楚。注意，很多时候你需要要求模型“除了JSON不要输出任何其他内容”，否则一道解释性文字会让JSON解析当场爆炸。

3.3 实操模板：一套我的通用提示词底稿

我平时在工作里沉淀了一套通用提示词框架，不算秘密，分享出来供你套用：

“你是一个[专业角色]，擅长[领域描述]。你的任务是[具体任务描述]，约束条件是[不能做什么或者必须怎么做]。在回答时，请遵循以下要求：1. 先给出结论，再补充细节；2. 输出格式必须是[JSON/Markdown/表格]；3. 如果信息不足，请明确说“信息不足”并列出缺少的部分；4. 语气保持[风格要求]。”

直接复制这个框架，把方括号里的内容替换成你的场景，大多数基础对话任务都能应付。但要注意“上下文工程”的配套操作：如果你提供参考资料，要明确告诉模型“仅基于以下材料回答，不要使用超出材料的先验知识”。我做过对比实验，加不加这一句，事实准确性差别很大，尤其在专业领域问答里。

这套东西看起来简单，真落地时所有人都容易犯同一个毛病：提示词又长又绕，塞了一堆自相矛盾的指令。我后来学乖了，每次改提示词都做变量控制，一次只改一个元素，用同样的测试集对比输出质量。也别觉得这个环节low，OpenAI官方提示词工程指南的开篇建议就是“要具体、要迭代、要测试”，朴素到让人怀疑自己学了个寂寞。

4. 微调实战：从LoRA到全量微调的避坑指南

4.1 先说结论：不是所有场景都需要微调

我见过最冲动的决策，是业务效果不好就立刻想做微调，其实八成场景的根本问题不在模型本身。你要先自查：你已经把提示词和上下文工程做到极致了吗？如果业务需要的是实时变化的私有知识库，你该优先做检索增强（RAG），而不是动模型权重。如果只是希望模型说话风格更贴近品牌调性，那提示词也能解决一大半。

微调真正适合的场景，通常是这几类：模型始终学不会某个固定格式（比如解析特定报表）；你希望模型能输出某个领域的高度专业化表达（比如医疗诊断建议的措辞）；你有大量人工标注好的数据，希望模型从这些样本中学到某种判断倾向。判断标准就一句话：如果通过改提示词就能达到80分，先别急着微调；只有提示词天花板挡住了你，微调才是下一个选择。

4.2 LoRA为什么是首选：原理、数据、训练

LoRA（Low-Rank Adaptation）是目前微调性价比最高的方案，没有之一。它的思路简单说就是：模型本身的参数冻结不动，在注意力层的权重矩阵旁边挂一个低秩的增量矩阵，只训练这个增量参数。举个例子，原始权重矩阵可能是2048x2048，LoRA用两个小矩阵的乘积近似增量，比如2048x16再乘以16x2048，训练参数量直接少了两三个数量级，显存压力骤降。

我建议新手第一把微调就从LoRA开始。原因很简单：显存门槛低，用一张24GB的消费级显卡就能微调7B~13B模型；速度快，同样的数据量，比全量微调快得多；可控性好，训练失败或者效果不好，权重文件换掉就行，原始模型参数没被污染。

数据准备是最容易翻车的环节。质量要求其实就三条：格式统一、覆盖目标场景、去重去噪。比如你要微调一个“客服话术模型”，数据就该是“用户问题+标准答复”的对话pair，别混入带歧义或者错误的标注。数量上，几十条高质量样本也可能见效，而几万条低质量噪声反而会把模型带偏。我第一次做微调时用了两万条网爬数据，结果模型学会了废话连篇；后来精心清洗了两百条真实客服会话，效果反而脱胎换骨。数据清洗这件事的重要性，怎么强调都不为过。

4.3 训练参数、评估与灾难性遗忘

LoRA训练需要关心的参数不多：秩rank（一般8到64之间，越大表示增量矩阵容量越大，但显存占用也更高）、学习率（常见1e-4到5e-4，太大直接学飞）、训练轮数（看验证集表现，通常1到3轮就够）、上下文长度（别超过模型限制）。我的经验是，先用小秩小学习率跑一个短实验，看loss曲线有没有下降趋势，确认数据没问题再放大规模。别上来就开大max_length大batch，你只会得到一张黑屏的显卡和一条报错日志。

评估是很多人偷懒的环节。我强烈建议每次微调后都准备一份固定的评测集，里面包含你没参加训练的样本，且要有明确的评分标准。评分维度和是否相关、是否覆盖要点、是否格式正确等等。要注意“灾难性遗忘”这个问题：模型在学新知识时可能会遗忘原本泛化能力，表现就是微调前能回答的常识问题，微调后反而不会了。应对办法是训练时混入一部分通用语料，或者在评测里专门保留一个基础能力测试集，时刻盯住。

5. 本地部署大模型：让个人电脑真正跑起来

5.1 显存与硬件门槛：先算账再动手

本地部署这个话题的热度高，但很多人的期望值是不切实际的。先讲常识：模型文件加载进显存，大体上参数量每10亿参数大约需要2GB的显存（以FP16计算）。一个7B模型，FP16权重约14GB，实际上再算上KV Cache和推理中间变量，24GB显存是起步配置。如果你是消费级显卡，几档配置我列个参考：

这个表里的INT4（4位量化）是本地部署的关键词。量化就是将模型权重从16位压缩到4位或8位，文件大小和显存占用随之下降，虽然会带来一定精度损失，但对多数场景影响不大。新手不用把量化原理背下来，只需要知道：优先用已经量化好的模型权重文件GGUF格式，比你自己动手转换省心得多。

5.2 部署工具怎么选：Ollama、LM Studio、vLLM

现在本地部署工具已经非常成熟，不需要自己写推理代码。我选工具的标准是看场景。纯个人学习、玩一玩，Ollama是最好的选择，安装一条命令搞定，模型下载也方便，自带OpenAI兼容的API，改一行base_url就能让很多框架接上它。LM Studio适合喜欢图形界面的用户，你可以在界面上直接跟模型对话，也可以加载GGUF模型文件，对新人零门槛。

vLLM则是生产环境的主角。它主打高吞吐量和PagedAttention，简单解释就是：它能更好地管理显存，支持多个并发请求，适合做服务端部署。如果你是正经要做企业应用，哪怕先不精通信原理，也应该学会用vLLM把模型启动成一个服务，让上游业务通过API来调用。

我的建议是本地学习装Ollama，跑Demo和生产系统评估用vLLM，两个都别落下。

5.3 一个最小可用的部署流程

我拿Ollama举例，给你一个完整的从下载到调用的流程。

第一步，安装Ollama。官网下载对应系统版本，Windows端是exe，Linux是脚本安装，macOS是pkg。第二步，拉取模型。如果想用中文表现好的7B模型，可以试试最新的量化版千问系列，执行ollama pull qwen2.5:7b之类的命令，等进度条走完。第三步，启动服务。Ollama默认会在后台起一个服务，监听本地11434端口，你不需要手动启动终端阻塞服务。第四步，测试对话。终端直接执行ollama run qwen2.5:7b就能进入自动对话界面；也可以调API，用curl发一个POST请求到http://localhost:11434/v1/chat/completions，Body里带model和messages字段，格式和OpenAI兼容。第五步，接入应用。把你自己写的Python脚本里OpenAI客户端的base_url改成本地地址，就完成了“本地版大模型”的接入。

很多人在第四步开始犯迷糊：为什么我调用API返回的是404？大概率是因为版本更新后接口路径变了，去官方文档确认一下/v1前缀是否存在就好。另一个高频坑是模型拉取到一半网络中断——没关系，ollama支持断点续传，重新执行拉取命令即可，不需要删除重来。

5.4 部署进阶：上下文长度、并发与显存优化

跑通之后，你会遇到一堆初始“能用就好”的问题。最常见的是上下文长度。默认配置下，很多框架只分配4k或8k的上下文，一旦输入长文档就直接爆显存或报错。你可以通过环境变量调整，比如Ollama的OLLAMA_CONTEXT_LENGTH，或者vLLM启动参数里的--max-model-len。但要注意：上下文从4k翻到32k，KV Cache占用接近线性增长，显存不够的情况下会大幅影响速度。

并发也是一道坎。个人本地部署默认串行处理没问题，但如果你想让几个应用同时调用，就需要上vLLM这类专业推理框架。它内部做Continuous Batching，能在一个batch里塞进不同长度和进度的请求，吞吐量远高于逐一处理。调优时还有一个隐藏参数叫前缀缓存，如果多个请求开头都带着同样的知识库资料，开这个开关能省掉很大一部分重复计算，响应速度会明显提升。

我个人的经验法则是：先让单请求丝滑运行，再去折腾并发；先解决“能不能算”，再谈“算得快不快”。本地部署的乐趣在于“看到自己电脑上真的跑起了一个智能体”，但生产成本优化是个无底洞，别一头扎进去出不来。

6. 工程化进阶：从“能用”到“像一个产品”

6.1 Agent框架怎么选：LangChain、MetaGPT、自主搭建

聊完原理和部署，几乎所有入门者都会自然问到一个问题：怎么把模型变成能干活的东西？这就是Agent的领域了。Agent的概念被讲得太玄，简化来说，就是让模型具备“规划、调用工具、观察结果、迭代执行”的能力，而不只是单纯地回答问题。

主流的Agent框架我重点提几个。LangChain是最广为人知的，生态成熟、组件多，但学习曲线较陡，有时候组件之间的隐式约定让人头疼。LlamaIndex在检索增强这块做得很深，适合做知识库问答类应用。MetaGPT走的是“多智能体协作”路线，模拟一个公司里产品经理、架构师、工程师的角色分工协作。如果你已经有工程功底，也可以不依赖框架，自己定义工具函数，用模型做决策循环，自由度最高，但代码量也最大。

我的建议是：新手先用LangChain跑通一个带工具调用的Demo，感受一下Agent的运转逻辑；真正做业务时再审视是否需要框架，还是自己撸一个更简单可控的编排层。要记住，框架是干活的，不是供着的，别本末倒置。

6.2 RAG是外挂知识库，但没有银弹

RAG（检索增强生成）几乎是企业落地绕不开的方案。它的核心思路：在用户提问时，先从你的文档库里检索出相关片段，把它们拼进Prompt的上下文里，再让模型基于这些片段作答。这样模型不需要记住你的每份内部资料，也不需要在每次业务更新时重新微调，只需要维护好向量数据库。

整理RAG系统的关键工序有三个。第一是文档切分，PDF、Word、网页各有各的污染，切分成小块时需要考虑语义完整性。第二是向量化，选择Embedding模型，将文本映射为向量，检索时算向量相似度。第三是重排序，第一轮的TopK候选未必是用户最需要的，用重排序模型再精排一遍，效果提升明显。

然后我得泼点冷水：RAG不是银弹。检索链路一旦有环节做得糙，比如切分文本把一句话切成两半、Embedding模型对专业术语理解差、TopK设置太小，模型就会直接抓瞎。解决思路就是工程调优，一点点排查。本地部署刚上手时想做一个简单的本地知识库问答，两三周时间做出来很常见，别找那种“一键搭建”的模板，真业务里迟早要把原理弄清。

6.3 多模态模型是怎么一回事

如果你走到这步，大模型对你已经不是“文字游戏”了。多模态模型是另一个需要了解的进阶方向：给模型喂图片，它能看懂并用文字描述；喂一段音频，它能转写；喂视频，它也能抽取关键信息。技术上，它是把不同模态的信息统一映射到同一个表示空间，再交给语言模型去理解。

想系统入门多模态，不必一上来学各种眼花缭乱的模型架构。你只需要理解四类任务：图片理解、图片生成、音频理解、视频理解。然后逐个跑一遍开源的Demo，感受一下不同模态之间的信息转换有什么坑。大部分人涉足多模态是为了做“图片内容审核”或者“多模态客服”——用户发一张截图，系统要能提取出关键信息。这类任务当前的成熟度已经不低，但门槛全在于数据处理，标注一套好的多模态数据，比选模型架构更花时间。

7. 常见问题与排查技巧实录

7.1 学习过程里，大家最容易卡住的地方

很多自学的人卡住，不是因为知识点难，而是因为他们没有“一个能跑通的最小系统”。举个反复出现的场景：你看了两周Transformer原理，觉得自己懂了，可是让你去部署一个模型，却连命令行都不知道敲什么。这是典型的“知识和操作断层”。

破解方法特别朴素：不管学什么概念，都逼自己在一个周末内跑通最小Demo。学原理就跑本地对话，学微调就找一个公开数据集做一次LoRA训练，学Agent就搭一个能调用查询天气的机器人。把“知道”变成“做过”，这二三十个小时的投入会换来后面几百个小时的高效学习。

第二个高频卡点是“选择困难”。想学微调，不知道该用中文数据集还是英文数据集；想部署，不知道该选哪个模型。我的建议是别纠结，挑最主流的组合直接上手。中文场景千问系列模型和相关数据集生态最稳，英文场景Llama系列资料最多，选这两条主流路线，遇到问题的时候能搜到大量现成答案。

7.2 部署与微调场的报错排查速查表

我把这半年遇到的重复问题整理成了一张速查表，实战价值极高：

这张表覆盖了新手前三个月能踩到的七成坑。如果你遇到一个不在这张表里的错误，我的建议是：看日志、分解步骤、GitHub搜索。大模型项目的报错信息往往比传统软件更精准，至少能告诉你到底是GPU驱动、显存、版本还是数据格式的问题。切记别盲猜，盲猜就是关机重启。

7.3 关于资料、社区与“八股文”的一点私货

现在大模型圈子出了个词叫“大模型八股文”，指的是那些面试造火箭、工作拧螺丝的题目。我不建议你把时间花在背这些题目上，但你确实要掌握一套框架性的表达能力。比如被问到“为什么Transformer用多头注意力”，你不是把公式背出来，而是说出“让模型从不同子空间捕捉关系，再综合起来，效果比单头更稳”。这需要你真正理解原理，而不是背题库。

资料方面，我推荐一个高效的组合：官方技术博客作为主线（OpenAI System Card、Anthropic的工程博客、Meta的Llama技术报告、DeepSeek的技术论文，还有千问官方仓库里写得很清楚的技术说明），经典论文作为支线（Attention Is All You Need入门，LoRA论文必读），开源项目代码作为落点（vLLM、Ollama、transformers、peft，读它们的文档和Issue）。

社区的选择上，不用贪多。GitHub热门仓库的Discussions、Hugging Face的论坛、几个高质量的中文技术写作平台，已经足够覆盖日常。那些“全网最全资料合集”的网盘链接，收藏了基本只会在网盘里吃灰，真正有效的学习永远是“开一个终端，跑一个模型，改一段代码，再看一篇文档”这种循环。

7.4 我的个人经验：先完成，再完美

写到这里，这篇入门资料已经覆盖了原理、提示词、微调、部署、Agent、多模态六条线，最后分享一点做技术内容的态度。我刚入门时总想在动手前把所有背景知识补齐，把每篇论文都读透，结果是连续三个月只输入不产出。后来强制自己选一条最小的真实需求——比如“本地跑一个能回答我文档问题的助手”——所有知识都围绕这个目标展开，边做边查边学，进度反而突飞猛进。

大模型这个领域，资料永远看不完，版本永远在更新，但基本功是稳定的：概率视角理解生成、工程思维理解显存与并发、实践验证理解提示词与微调。你不需要成为所有子领域的专家，只要在一条线上做到能落地，就已经具备价值。希望这份实际经验整理出的资料，能帮你少走一点弯路，把更多时间留给真正有意思的事情——亲手做出一个能跑起来的模型应用。