1. 先想清楚：你要用大模型做什么，再决定怎么学
最近几个月，陆陆续续有十几个朋友来找我，开口第一句都是"我想学大模型，从哪开始？"。有人给我甩过来一份网上流传几百KB的PDF，有人收藏了一堆"大模型学习路线"的长图，还有人上来就问"微调要多少张显卡"。说实话，问的人越多我越发现，大部分人卡住不是因为资料不够，而是因为目标太模糊。
大模型不是一个单一的技术点，它是一条从模型原理、训练方法、部署工程到应用开发的完整链路。同一个词"学大模型"，在小红书博主的理解里是"学会用ChatGPT写文案"，在大厂算法工程师那里是"能从零训练一个LLM"，在运维同事那里是"能把模型在V100上跑起来并接上业务接口"。这三类人需要的资料和学习路径，几乎没有交集。所以系统性入门的第一件事，不是找资料，而是确定你属于哪个角色。
我见过太多人被"大模型八股文"带偏。所谓八股文，就是网上流传的那些高频面试题，什么"讲一下Transformer的结构""RoPE和ALiBi的区别""什么是MoE"，背得滚瓜烂熟，但真让他用LangChain写一个带工具调用的Agent，他连API参数都填不对。这说明知识没有形成体系，只是碎片化地塞进了脑子里。
从我的经验看，入门大模型最有效的路径，是围绕"你要解决的问题类型"来组织知识。把你自己的角色先归类：你是想做应用（用现成模型做出产品），做模型（训练/微调/推理优化），还是做理论（研究模型机制）？绝大多数读者想做的是第一类，其次是第二类。本文我尽量把四条线都覆盖到，但主线会放在应用开发和模型工程这两块，因为它们的落地性最强，也最符合大众实际需求。
如果你现在只知道"大模型能聊天、能写代码"这一个事实，除此之外脑子里一片空白，不用担心，下面每一节我都会从一个真实工作场景切入来讲，尽量做到零基础也能跟得上。
2. 基础概念补课：从Transformer到Token，把术语变成常识
我们常说"底层原理不重要，会用就行"，这句话在别处可能成立，但在大模型这里不太行。因为大模型的使用方式和传统软件完全不同：传统软件的行为是确定性的，你点哪个按钮它就执行哪个逻辑；大模型的行为是概率性的，同样是"帮我写一段年终总结"，不同模型、不同提示词、不同温度参数，出来的结果可能天差地别。你不理解它内部的概率机制，出了问题都不知道从哪排查。
2.1 模型本质就是一套超大的词语接龙系统
如果你没读过任何论文，也没关系。我最早给传统程序员讲大模型时，用的最有效的一个类比是：大模型本质上是一个极度智能的"词语接龙"系统。你喂给它一段文字，它根据这段文字预测下一个最可能出现的词是什么；预测出一个词之后，这个新词和原来的文字拼在一起，继续预测下一个词，这样循环往复，直到凑出一段完整的回复。
ChatGPT出来那年，网上老有人惊呼AI怎么这么"懂"我，其实剥开来看，它做的事情和手机输入法联想下个词本质是同一个逻辑，只不过规模大了无数倍，训练数据多了无数倍，从"输入法级别"跃迁到了"几乎能以假乱真的人类写作水平"。Transformer架构的真正突破在于，它用一种叫"自注意力"的机制在预测每个词时，能同步考虑这个句子中所有其他词的影响——不问距离远近都能"彼此看见"，所以能把长句子、复杂逻辑关系处理得比较连贯。
2.2 Token、上下文窗口和参数规模，这三个术语先搞明白
接下来这三个词，是你后面看任何资料都会高频碰到的底座概念，我建议你先把它们焊死在脑子里。
Token，你可以理解成模型处理文本的最小单位。它不是一个字也不是一个词，而是通过分词器"切"出来的片段。中文通常一个字到几个字算一个Token，英文一个单词可能拆成几个Token。为什么重要？因为大模型的计费、上下文限制、生成速度，全部以Token为计量单位。你调API时看到的价格，都是"每百万Token多少块钱"，而不是"每次请求多少钱"。所以同样的内容，用简洁的提示词能大幅降低token消耗，这就是省钱能力。
上下文窗口，指的是模型一次能"看到"的Token上限，可以类比成一个人的短期记忆容量。GPT-3时代是2048个Token，现在很多模型已经做到128K甚至200K。它直接决定了你能往一个Prompt里塞多少材料。非常多人第一次用大模型做文档分析时翻车，就是把10万字直接丢进去，结果模型只读了前几千字就断片了。理解上下文窗口，你才知道为什么"分段喂入再汇总"是刚需操作。
参数规模，就是模型的"神经连接"数量，单位是B（Billion，十亿）。70B参数模型和7B参数模型，知识量、推理能力差出好几个数量级，但同时推理速度、显存消耗也差出好几个数量级。现在大量的应用场景都在做"用小模型干大事"，比如量化到7B甚至3B的模型，已经能胜任一部分分类、抽取、改写任务。要不要为了效果上大模型？往往得先在成本和场景之间做一次权衡。
这三个概念理解到位之后，你再看任何一篇模型介绍、任何一次API文档，都能快速定位重点。别一上来就去啃注意力机制的数学推导，先建立"词接龙+Token计量+记忆上限+规模效应"这四个常识，后面学什么都顺了。
3. 一条可复制的学习路线：理论、工具、实战三线并行
我这些年带过一些实习生，也带过零基础的转行同事。大家从"完全不懂"到"能独立完成一个用大模型做的项目"，快的半个月，慢的两个月。差别不在智商，而在学习顺序。有人先啃了一个月的Transformer原版论文才开始动手，理论没吃透，热情先磨没了；有人一上来就抱着LangChain文档撸Demo，连模型返回的JSON都解析不明白，遇到报错完全无从下手。两者都是因为"理论和实战"脱节了。
3.1 第一条线：理论线，只学你用得上的
我给入门者划定的理论红线只有三条。
第一，把Transformer主干结构大致看懂。不用会推公式，只要知道它有自注意力、前馈网络、层归一化这三块核心组件，每一块各干什么，就赢了大多数人——因为很多人根本连这个都不知道。
第二，把"预训练+微调"这套范式搞清楚。早期深度学习是每个任务单独训练一个模型，现在的大模型是先在一个超大语料上做通用预训练，学完语言规律和世界常识；然后在下游任务上做微调，把它从一个"通才"变成一个"专家"。这套范式的意义在于，你不需要几万张卡就能得到一个好模型——基座模型已经帮你把老底打好了，你要做的就是在这个基础上做小幅调整。
第三，理解"是否模型越大越好"。常见直觉是"更大=更好"，但真实工程里：大模型效果好但贵、慢、部署难；小模型便宜、快、容易私有化，但能力有限。所以在任何场景中，最佳选择往往是一个折中，而不是盲目上最大的那个。
理论到什么程度算够？有一个检验标准：能跟别人把上述三件事解释清楚，并且让对方听明白。这在大模型面试里能过最基础的一轮，在实战里也基本够用了。再往里钻，比如手推反向传播公式、研究位置编码的变体，真不是大多数人一开始该做的事。
3.2 第二条线：工具线，用烂一个主力工具链
工具这东西，学十套不如用烂一套。大模型应用开发的"主力工具链"，我按大多数实际项目的使用频率帮你们排一下优先级。
第一优先级，Python基础库（requests、json、openai/各模型厂家SDK）。调用API怎么做请求、怎么传参、怎么解析返回，这是所有应用的基础。很多人第一步就栽在这儿，因为大模型API返回的结构和普通HTTP接口还不一样，通常嵌套在choices/message/content这种层级里。
第二优先级，LangChain或LlamaIndex，二选一。它们解决的核心问题是：多轮对话、工具调用、数据索引、RAG（检索增强生成）流程编排。我新手期感觉最难的不是写代码，而是"不知道代码应该承担什么职责"。一个对话应用写下来，哪里该调模型、哪里该管理记忆、哪里该查数据库，没有框架的时候全是自由发挥，改两轮就一团乱麻。用框架能强制你的项目有一个清晰结构。
第三优先级，向量数据库（如Milvus、Weaviate、Chroma）至少了解一个。只要你想让模型基于你自己的私有知识库回答问题，就离不开向量检索——把文档切成切片，映射成向量，在库里做相似度检索，把命中片段拼进Prompt喂给模型。步骤本身不难，难的是理解为什么检索质量直接决定了回答质量。模型只是"嘴巴"，检索是"找资料的手"，手没找对，嘴再会说是白搭的。
工具线不要贪多，选一套主流组合直接从官方文档啃下来、跑通最小Demo就行。"收藏了100个用不上的教程"远不如"亲手跑通一个能回答你自定义问题的ChatBot"更真材实料。
3.3 第三条线：实战线，从三个最经典的小项目做起
实战是最容易被忽略的一步。很多人Applications学了十几天，始终处于"在API文档里打转"的状态，没产出过任何东西。我建议做项目，不做练习题——直接做能解决你身边真实问题的东西。
第一个项目：做一个人知识库问答机器人。把你自己常用的文档、笔记、Excel导出的CSV丢进去，让模型基于这些材料回答问题。它会逼你走完切分、向量化、存储、检索、拼接提示词、调用生成、流式输出全流程。
第二个项目：做一个提示词实验台。把各种提示词技巧（后面会专门讲）做成一个Web小页面，你输入同样的需求，快速对比不同写法带来的输出差异。不要小看这个工具，它会让你对模型行为有非常直观的体感。
第三个项目：做一个内容批处理脚本。让模型把几十篇纯文本文章批量打标、改写、提取关键词，然后导出成结构化JSON。这个项目会逼你面对"模型输出不稳定"这个铁一般的事实，学会写重试、写异常处理、校验输出格式。
这三个项目做下来，你对大模型应用开发的技能树基本就点亮了一大半。剩下的，遇到具体需求再去学，学得飞快。
4. 提示词工程与上下文工程：普通人最值得投入的技能
如果你想在不写一行训练代码的前提下，让大模型的输出质量提升一个档次，那提示词工程和上下文工程就是你花的每一分钟都值得的投资。这两个概念经常被混在一起说，其实它们是两码事。
4.1 提示词工程：用"讲人话"的方式给模型下需求
提示词工程的核心是：模型没有读心术，它的输出质量直接受你输入质量影响。同样一个"帮我写邮件"的需求，"帮我写一封催老板批假条的邮件"和"帮我写一封邮件，语气礼貌但坚定，说明我已经连续加了10天班，身体快撑不住了，希望下周请两天假休息，并承诺休假期间保持手机畅通处理紧急事务"，后者的输出质量会好出十倍。这不是玄学，是模型概率机制的直接体现——更具体的约束条件能把它采样时的搜索空间大幅收窄。
再往深一层，有四个技巧值得反复练习：
- 角色设定法：开头一句话给模型一个身份，"你是一名有10年经验的Linux运维工程师"，输出会比默认身份专业得多。
- Few-shot示例法：给模型"看两三个输入-输出示例"，它就有样学样。这本质上是让模型从你的示例里学习"格式锚点"。
- 思维链提示：要求"先逐步分析，再给出结论"，模型从端到端的瞎猜变成有条理的推断，数学和逻辑题正确率提升明显，这是当前学术界公认效果最好的技巧之一。
- 输出约束法：明确指定输出格式、长度、语气、禁用语。别怕啰嗦，把要求写够细，模型的表现才会稳定。
我自己最受益的一个习惯是：每次模型输出质量不佳，我第一反应不是怀疑模型笨，而是反思"我是不是没说清楚"。这个归因习惯，可以帮你省下大量瞎试的时间。
4.2 上下文工程：比提示词更上层的一层
如果说提示词工程是在"单个问题的问法"上下功夫，那么上下文工程就是在"说什么、不说什么是该被删掉的"这一层面做文章。它的核心是管理好喂给模型的那段上下文——既包括用户当前输入，也包括历史对话、检索到的外部知识、系统预设信息。
一个最典型的场景是：你在做一个企业知识库问答机器人，用户提了个问题，你如果把整本手册都塞进上下文，上下文窗口爆掉不谈，模型收到的冗余信息太多，真正的答案反而被淹没了。正确的上下文工程做法是：先做向量检索，只把最相关的三段原文切片拉进来，再辅以一句简短的"你是内部客服助手，基于资料回答，遇到不清楚的直接说不知道，不编造"。这个"检索-过滤-组装-约束"的过程，就是上下文工程的核心。它和提示词工程配合，能显著降低错误率、幻觉率和Token成本。
上下文工程里还有一个常见误区：上下文越长越好吗？答案是否定的。上下文窗口变大，带来了更多信息，但也会引入更多噪音。研究中有一类"迷失在中间"现象，模型对长上下文中间部分的内容关注度明显低于开头和结尾。所以做上下文工程要克制，能用三个段落说明白的事，绝不塞三十个段落进去。
提示词工程和上下文工程是应用层最稳的两块基石，值得你用大量时间去打磨手感。它们不需要懂硬核算法，但对逻辑能力、语言表达能力和产品理解力的要求都很高，这也正是开发者从"调API的人"升级为"会用AI的人"的关键一步。
5. 模型部署与API调用：从本地推理到线上服务的完整链路
上面几条线主要面向"用现成模型"做应用的人。但你如果想真正掌握大模型工程，自己动手部署一个模型、哪怕在个人电脑上让它跑起来，那种能力提升是截然不同的。而且"本地部署大模型让个人电脑智能化"是很多开发者的梦想，它带来的可控性、隐私保护和极低成本，是云端API无法替代的。
5.1 本地部署：先摸清你的硬件底牌
要部署一个模型，第一步永远是算显存。有个很粗暴的经验公式：大约每10亿参数，FP16精度下约占2GB显存。所以一个7B模型，FP16大概需要14GB显存；70B模型就需要140GB。这还不算KV Cache（推理时缓存中间计算的显存开销）和输入输出的缓冲，实际占用通常比这个基准值高20%-30%。
如果你手上只有一张24GB的消费级显卡（比如RTX 3090/4090），想跑14B模型就很吃紧，更别说70B了。这时候有两个常用解法——量化和CPU offload。
量化是让模型用更少的位宽来存储权重，常见的有INT8、INT4。模型会变得更小更快，但精度会有一定损失。这就是为什么你在看模型下载页时常常见到Q4_K_M、Q5_K_S这种后缀——它们代表不同的量化等级。实践里，Q4量化后的7B模型能把整体占用压到5-6GB，跑在消费级显卡上完全没问题，输出质量在对话任务里依然可用。
CPU offload则是把一部分层放在内存里，让CPU和GPU协同计算，能用但偏慢。我的真实体验是：7B模型在纯CPU上生成一个Token大约需要1-2秒，只能当玩具或低并发后台任务用，扛不住生产流量。
5.2 推理框架：选一个合适的"运行引擎"
模型文件下载下来之后，你不能直接运行，还需要一个推理框架。框架的作用是把训练好的权重文件加载起来，并在推理时做一系列相关运算。现在最主流的几个开源推理框架是：
| 框架 | 核心特点 | 适合场景 |
|---|---|---|
| llama.cpp | 纯C/C++实现，支持CPU/GPU混合推理，单文件部署轻便 | 个人电脑、边缘设备、嵌入式 |
| vLLM | 高性能推理引擎，主打高吞吐、支持连续批处理和PagedAttention | 生产环境、高并发API服务 |
| Ollama | 基于llama.cpp做了封装，一条命令下载模型、运行模型、暴露API | 本地快速体验、个人开发环境 |
| Hugging Face Transformers | 最经典的老牌库，生态完善，方便跑训练/微调 | 研究调试、微调训练、动手玩模型 |
我自己做本地实验时最常用Ollama，因为真的就是一条命令的事；做线上API服务时必用vLLM，因为它对吞吐量的提升非常明显，可以支撑实际业务负载。新手入门建议从Ollama开始，跑通一个7B模型，体验"个人电脑上有一个自己专属的大模型"的感觉。
5.3 云端API：学会设计一个封装层
然而，部署一粒本地模型只是学习路径的一半，更多生产环境用的是云端API。云端API的好处是开箱即用、模型能力强、免运维，缺点是隐私敏感性、费用和网络问题。但"免费大模型API"这个话题，在很多案例里已经有非常成熟的公益项目可以提供基础调用额度，对入门学习完全够用。
调用云端API时，我强烈建议你在项目里设计一个"模型封装层"。不要让业务代码到处直接调API，而是统一封装一个函数或类，把模型接入、错误重试、接口参数、日志记录全部收口。这样做的好处是：当你需要把模型A换成模型B时，只需要改封装层内部，业务代码一行不动。这个习惯在被依赖方频繁变化的时候，真的能救你一命。
调用API时最容易踩的坑有三个。一是超时和重试策略缺位，大模型是个慢接口，一次对话可能几十秒才返回，不设置合理的超时和重试，你的整个服务会被拖垮；二是流式输出没用起来，很多场景要求边生成边打字，得把stream=True打开；三是模型返回格式不稳定，你要写一大堆"解析模型输出的反序列化代码"，稍微不严谨就会连不上JSON字段。我的建议永远是：让模型输出受控的、结构化的内容，而不是自由文本。提示词里把格式限定好，再用正则/JSON解析双保险，输出稳定性会好很多。
6. 进阶方向与避坑指南：微调、多模态、Agent，先别急着全都要
当你把上述应用开发和模型部署都跑通之后，自然会开始心动一些热词：微调、多模态、Agent、知识抽取框架。这些都是真实的大方向，但也是新手最容易白白消耗热情的地方。我在这里把每个方向的及格线画清楚，再说说哪些是坑。
6.1 微调：明确你的应用场景是不是真的需要
大模型微调，指的是在预训练基座模型的基础上，用你自有标注数据继续训练，让模型更贴合特定风格或任务。对外行来说，一听"微调"就觉得很高端。但我想泼一盆冷水：绝大多数应用场景根本不值得微调。你只需要配合上下文工程就能解决80%的问题，而微调一次的成本，从数据准备、算力租赁到调参验证，轻易烧掉几万块钱，效果还不一定可控。
什么情况才真的需要微调？我倾向于三类：一是要让模型稳定输出某种特定格式，比如医疗报告；二是要让模型掌握某种专有领域术语与知识，比如行业黑话；三是需要降低推理成本，用微调把小模型训练到接近大模型的水平，从而省下大量Token费用。如果这三类你都不沾边，请按住钱包，继续把提示词和检索做好就行。
如果你确实要微调，那也需要分清两条路线：一条是全参数微调，你需要较高的算力资源，效果好但很贵；另一条是LoRA这类参数高效微调，只训练千分之一的参数，一个普通显卡就能举起，是目前个人开发者的首选。我个人的经验是：优先走LoRA，跑一个、验证一遍，觉得有效果再往大了做。
6.2 多模态大模型：别只盯着"看图说话"这一个能力
热搜词里的"多模态大模型"主要指能同时处理文本、图像、音频、视频输入的模型。很多人以为多模态就是"识别图片"，实际的价值大得多。比如让模型直接读取一张架构图、一张报表截图，然后基于其中的内容回答业务问题；或者让它抽取出扫描件里的结构化信息。这类能力的门槛，已经下降到普通开发者可以直接通过API使用知名多模态模型或部署开源多模态模型的程度。
如果你要做多模态应用，我的建议是从"图文结合"场景起步，比如拍照识别菜单并推荐搭配、读化验单给出指标解读。技术链路比纯文本多了一层"图片预处理"和"多模态Token解析"，核心思想仍然是把图片切成小块和文本一起拼成序列喂给模型。这一步不需要太多数学功底，但能把API的参数吃透。
6.3 Agent框架：从"问答机器人"进化到"自动完成任务"
现在主流的Agent框架，解决的核心问题是：让大模型不只是"回答问题"，而是"做事情"。比如让它自己调研行业信息、规划步骤、调用搜索工具确认结果、最终生成一份报告。这个概念对应的进阶栈是：模型 + 工具调用 + 规划与反思 + 记忆管理。每个环节都烧脑，但确确实实是未来最有价值的落地方向之一。
对新手来说，我的建议是从"一个函数调用"做起，先让模型学会调用一个自定义函数，比如它返回什么样的JSON结构来表示"我要调用某个工具、传什么参数"，然后一步步扩展成"多个工具+循环决策"。不要一上来就搭建一个拥有几十个节点的Agent编排图，复杂度会指数级上升。我自己见过太多人用LangGraph搭了一个花哨的Agent流程图，最后调试时每个节点都在报错。从小处着手，一层一层往上垒，才是真正的捷径。
6.4 学习避坑：别被"大模型八股文"和"SOTA焦虑"绑架
最后说说心理建设。大模型这个领域更新速度快，每天都有新模型发布，每天都有新的开源项目冒出来。如果你误把"持续不断吸收热点"当成了学习的核心，就会陷入一种永不满足的知识焦虑。想系统做下来，一个很重要的心态是：抓住底层中稳定的部分。Transformer架构十年前提出的，至今仍是绝大多数模型的主干；提示词的能量这么大，核心技巧两三年前就逐渐定型了；部署栈虽然演变，但"显存算力、量化、推理框架"这套知识体系一直是稳定底座。底层的东西是可以沉下心来花几个月掌握的，热点只是浮云，稳定学习远优于无限追新。
还有一个要提醒的是，大模型领域的"八股文"式准备不要做太多，不需要把每个最新模型的技术报告都背下来，也不需要在没有实践的情况下硬记Agent评估指标。遇到要用的新技术，去读官方文档，去跑官方Demo，遇到坑再去查资料，这个流程比囤一堆文档高效得多。
我个人实际做这行做到现在，最大的体会是：大模型入门资料多如牛毛，但关键的只有围绕"原理、工具、实践"三个支点反复打磨形成自己的闭环。身边就有太多人是推销式的"学了一百个概念"却写不出一个能扛住满负荷的接口服务。如果你能从今天开始，把第一行调用API的代码跑通，把第一个本地模型部署起来，踏踏实实过完我上面说的这几关，你在这个行业的底气会和只会收藏资料的人完全不同。后续再往Agent、微调、多模态方向探索，你会发现那些曾经望而生畏的"进阶热词"，其实都只是你这套基本功的延伸而已。
