1. 先想清楚：大模型是个什么东西

这两年"大模型"三个字几乎被说烂了，朋友圈、技术群、招聘网站、甚至家里长辈聊天都能蹦出来几句。但说实话，我见过太多人一上来就急着跑代码、下模型、看论文，结果折腾两三个月还在原地打转——不是不努力，是没找对入口。这篇东西就是写给那些准备系统性入坑大模型的人，我会按照自己带过团队、做过项目、踩过坑的实际经验，把整条学习路径拆开揉碎讲清楚。

先给一句话定义：大模型（LLM）本质上是一个基于Transformer架构的超大规模神经网络，通过在海量文本上做自监督学习，学会了语言的统计规律和知识分布。它"大"在参数规模——从几十亿到几千亿不等，也"大"在训练数据的体量——动不动就是几个TB的文本。这玩意儿能做对话、写代码、总结文档、抽取信息，核心原因是它在训练阶段看过足够多的"人类语言样本"，从而学会了next token prediction（下一个词预测）这个看似简单但威力巨大的任务。

但初学者最容易犯的认知错误是：把大模型当成一个"知识库"或者"搜索引擎"。实际上大模型不存储任何确定性的"事实"，它存储的是参数化的概率分布。你问它"北京是哪个国家的首都"，它并不是检索到一条记录然后告诉你答案，而是根据上下文逐词生成"中""国""的""首""都"这些token的概率序列。理解这一点非常关键，因为它直接决定了你后面怎么设计提示词、怎么判断模型输出、怎么排查幻觉问题。

另一个绕不开的概念是"训练三阶段"。第一个阶段是预训练（Pre-training），在海量无标注文本上做自监督学习，目标是让模型掌握语言规律和世界知识，这个阶段成本极高，动辄几百万美元的算力开销；第二个阶段是有监督微调（SFT），用人工标注好的指令数据教模型学会"听指令"，比如"帮我写一封请假邮件"这样的任务；第三个阶段是对齐（RLHF/DPO），让模型的回答符合人类偏好——不说废话、不乱编、不碰红线。你日常接触到的ChatGPT、Claude、通义千问这些产品，走的就是这套完整流程。搞清楚这三阶段，你才能理解为什么有些模型"知识面广但不会对话"，有些模型"很听话但知识量有限"——因为它们卡在了不同的训练阶段。

2. 系统性学习路线：别再做无头苍蝇

2.1 入门阶段的基础准备

很多人问我：大模型学习需要什么前置基础？我的回答是：Python语法熟练、PyTorch能看懂基本张量操作、线性代数和概率论知道"那回事"，这三样就够了。是的，不需要你是算法天才，也不需要你把《深度学习》花书从头啃到尾——那本书更适合作为案头参考，而不是入门教材。

Python方面，你至少得会写类、会用列表推导式、能读懂装饰器，因为后面看开源项目源码时这些东西到处都是。PyTorch方面，不需要你会手写训练循环，但你必须看得懂model.forward()、loss.backward()、optimizer.step()这三板斧在干什么。数学方面，注意力机制里的QKV矩阵相乘、softmax归一化、概率分布采样，搞清楚这三个就足够应付大部分阅读场景。

至于学习资源，我的建议是三条腿走路。第一条腿是论文阅读，核心就三篇：Attention Is All You Need（Transformer原始论文）、BERT论文、GPT-3论文。这三篇看完，你对大模型的"骨架"就有概念了。第二条腿是视频课程，推荐李宏毅的机器学习课程中Transformer和Self-Attention相关的章节，讲得通俗，配合动画演示，新手友好度极高。第三条腿是动手实验，直接在Hugging Face上找一个小模型跑起来，比如bert-base-chinese或者gpt2，用现成pipeline做一次文本分类或续写——代码就几行，但能让你把"模型到底是怎么工作的"从抽象概念变成具体体验。

2.2 进阶阶段的结构化学习

过了入门关，就需要系统性地建立知识体系。我建议按"模型架构 → 训练方法 → 推理优化 → 应用开发"四条线并行推进，而不是一条道走到黑。

模型架构线：重点搞懂Transformer的Encoder和Decoder区别、注意力机制的几种变体（多头注意力、因果掩码、交叉注意力）、位置编码（RoPE是目前主流）、归一化层的演进（Post-LN到Pre-LN）。这些知识点不需要会推导，但必须知道"为什么这么做"。

训练方法线：预训练的数据处理（去重、过滤、配比）、SFT数据的标注规范、RLHF的奖励模型怎么训、DPO为什么能替代RLHF。这条线偏工程，重点看业界公开的技术报告，比如Llama系列论文里详细写了数据配比和训练细节，比看纯理论教材有用得多。

推理优化线：了解KV Cache是什么、量化（INT8/INT4）的原理和代价、批处理（Continuous Batching）为什么能提升吞吐、张量并行和流水线并行各解决什么问题。这条线是后面做部署的底层支撑。

应用开发线：提示词工程技巧、RAG（检索增强生成）架构、Function Calling / Tool Use、Agent框架的原理。这条线最贴近业务，也最容易出成果，建议早期就开始接触——它能反过来倒逼你理解模型的"脾气"。

2.3 推荐的学习顺序和周期

如果每周能投入10小时以上，我建议按下面这个节奏来安排：

第一周到第三周：打基础。Python和PyTorch查漏补缺，精读Transformer论文，配合李宏毅的视频，完成一次BERT微调小实验（文本分类就可以）。

第四周到第六周：深入Transformer。自己从头实现一个极简版GPT（不需要多好，能跑通就行），用nanoGPT这类开源项目做参照。这个阶段会逼你去查大量资料，但收获极大——我常说，你无法真正理解一个东西，直到你亲手实现过它。

第七周到第十周：学习部署和推理。用Ollama在本地部署一个7B的量化模型，调用它做对话；再用vLLM部署一遍，对比二者的吞吐差异。同时把Hugging Face的transformers库吃透，至少能写推理脚本和简单的微调脚本。

第十一周到第十四周：微调和应用。用LoRA对开源模型做一次领域微调，比如让模型学会回答你所在行业的问题；同时学习RAG和Agent，做一个完整的项目——比如"基于本地知识库的文档问答机器人"。

这个周期看起来长，但递进关系非常清晰：先懂原理→再会部署→然后能微调→最后做应用。每一层都踩实了再往上走，比囫囵吞枣看十篇技术博客管用。

3. 本地部署实战：从Ollama到vLLM

3.1 硬件选型：先看你手里有什么

本地部署的第一个拦路虎是硬件。很多人在知乎上看完一堆帖子，兴冲冲去租了GPU服务器，结果发现自己根本用不满——这是典型的链路浪费。我建议先评估需求再选配置。

如果只是"让个人电脑智能化"，比如做个本地私人助理、跑跑文档总结，那么7B~14B的量化模型（Q4量化）就够用。这类模型在消费级显卡上就能跑：一块RTX 3060 12G显存就能流畅运行Qwen2.5-7B-Instruct的4bit量化版，生成速度在20~40 token/s之间，体验接近网页版对话。如果显存只有8G，可以考虑4B或3B的小模型，或者用CPU+内存跑（速度会慢一些，但能跑）。

如果要做偏专业的推理任务，比如代码生成、复杂逻辑推理，建议直接上20B以上模型，这时候显存至少需要24G——对应RTX 3090/4090，或者两块显卡张量并行。再往上，70B级模型做Q4量化后需要约40G显存，基本就是A100/H100或者多卡部署的场景了。

有一个经验法则可以记住：模型参数量（B）× 每个参数的字节数（精度）× 1.2的安全余量 ≈ 需要的最小显存。FP16精度下，7B模型约14G显存，INT4量化下约7G×1.2≈8.4G。用这个公式，你在选购硬件或选择模型大小时就不会抓瞎。

3.2 Ollama：五分钟上手本地大模型

Ollama目前是个人本地部署的首选方案，原因很简单：够傻瓜、够快、生态够好。它把模型权重下载、量化格式转换、推理服务、命令行交互全封装好了，你只需要执行一条命令就能把模型跑起来。

以在Windows/Linux/macOS上部署Qwen2.5-7B为例，流程是这样的：

# 安装Ollama（以Linux为例） curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行模型 ollama run qwen2.5:7b

首次运行会自动下载模型文件（约4.7G，4bit量化版），之后就会进入一个类似ChatGPT的交互界面。如果你想通过API调用，Ollama默认在11434端口提供OpenAI兼容接口：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "讲一个程序员的笑话"}] }'

这个API兼容性很关键——意味着你之前写的OpenAI SDK代码，只需要把base_url改成本地地址就能无缝切换，不用改任何业务逻辑。我用Python跑过一个小测试：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话解释什么是数据库索引"}] ) print(response.choices[0].message.content)

跑通这个脚本，"本地部署大模型让个人电脑智能化"就算正式入门了。接下来你可以把模型接到微信机器人、飞书机器人、语音助手等任何侧载应用上。

Ollama的优势是零门槛，但它也有天花板：并发能力弱、高级推理参数不灵活、不适合做复杂的服务化部署。当你的需求从"自己玩"变成"给团队用"时，就需要换到vLLM。

3.3 vLLM：服务化部署的正确姿势

vLLM是目前开源社区最主流的LLM推理服务框架，核心卖点是PagedAttention和Continuous Batching——前者通过分页管理KV Cache，解决了显存碎片化问题；后者允许不同请求在同一个批次里动态进出，大幅提升了GPU利用率。实测下来，vLLM的吞吐量是朴素Hugging Face推理的数倍，尤其是在多并发场景下。

部署流程也很简单，以Qwen2.5-7B原始精度（非量化）为例：

pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9

启动后，/v1/chat/completions接口就是OpenAI兼容的，同样可以直接用OpenAI SDK对接。我自己在生产环境里就是把vLLM跑在GPU服务器上，前面挂一层Nginx做负载均衡和鉴权，后面通过统一的API网关暴露给各个业务线调用。

vLLM有几个值得花时间研究的参数：

• --max-model-len：控制最大上下文长度。默认值通常按模型训练长度走，但如果你的显存紧张，调低这个值可以显著节省KV Cache显存。
• --quantization：支持awq、gptq、fp8等量化方式。如果你用的是量化模型权重，必须在这里指定对应格式，否则报错。
• --enforce-eager：在某些GPU驱动版本下，图模式（CUDA Graph）可能编译失败，加上这个参数强制切到eager模式可以快速排查是模型问题还是推理框架问题。

注意：不要在生产环境直接用--tensor-parallel-size 4配4张低端卡来跑一个大模型。张量并行的通信开销在PCIe环境下非常高，实测吞吐增益远低于预期，除非你的机器是NVLink连接的服务器级GPU，否则单卡跑小模型往往更高效。

3.4 部署中的显存与速度平衡

本地部署新手最常见的翻车现场是"模型能加载但生成速度慢到怀疑人生"。问题通常出在三个地方：一是没有用量化版本——全精度FP16的13B模型在12G显存上根本放不下，触发了CPU offload，速度暴跌到1 token/s；二是上下文长度设置过大——模型虽然能设置8K甚至32K的上下文，但实际对话只有几百token，白白占用了大量KV Cache显存；三是没有调对批处理参数——单请求时--max-num-seqs这个参数基本不影响单用户延迟，但会显著影响并发吞吐。

我给个人用户的建议是：追求响应速度优先考虑7B量化模型；追求答案质量优先考虑14B量化模型；只有"能跑就行"堂的需求，才选择20B以上大模型。另外，部署脚本里务必加上--max-model-len 8192这样的限制，不要迷信长上下文，多数真实需求上下文也就几百到几千token。

4. 微调实战：让模型听懂你的领域

4.1 什么时候才需要微调，什么时候不需要

这个问题的答案直接决定你是否要进入微调这条深水区。我的建议很直白：如果你的任务通过提示词工程、RAG、或者结构化输出已经能解决，那就别微调。微调是最后的手段，成本高、周期长、还有灾难性遗忘的风险。

举个例子：你想让模型帮你解析公司内部的PDF合同，提取关键字段。这种任务更适合RAG——把合同文档切块、向量化、检索相关片段，再塞给模型做提取。它每次都能基于最新的文档内容回答，不需要更新模型权重。但如果你想让模型在"语气风格"上贴近你的客服团队——比如答复投诉时"先共情、再确认、后提出方案"——这种稳定的、结构化的行为模式，提示词很难稳定约束，微调才真正派上用场。

判断标准就三条：一是任务模式是否稳定且长期存在；二是是否能通过提示/RAG解决；三是你是否拥有足够的领域数据。三条都指向"需要微调"，才动手。

4.2 LoRA与QLoRA：普通人用得起的高效微调

全参数微调意味着更新模型的所有权重，以7B模型为例，FP16下光保存一份梯度就是14G显存，再叠加优化器状态，没有80G显存根本跑不动。对个人开发者来说，这几乎不可行。

LoRA（Low-Rank Adaptation）的思路是：冻结原始权重，在每层线性变换的旁边插入一个低秩矩阵，只训练这个矩阵。好比一本《新华字典》你不需要重写所有词条，只需要在特殊用途的页面贴上几个便签，便签就是LoRA矩阵。实际训练参数量通常只有全参数量的1%~2%，一张24G显卡跑7B模型的LoRA微调毫无压力。

QLoRA更进一步，先把原始权重量化到4bit，再用LoRA微调。这样一张24G的卡可以微调13B甚至更大的模型。代价是训练速度略慢，但相比动辄几十万的硬件门槛，这点速度损失完全可以接受。

我用QLoRA微调过一个法律咨询场景的7B模型，整体流程大致如下：

# 用 LLaMA-Factory 这个开源工具，一站式搞定 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e ".[torch]"

数据准备成JSON格式，每条包含instruction、input、output三个字段：

[ { "instruction": "用户咨询：房屋租赁合同到期后，房东不退押金怎么办？", "input": "", "output": "根据《民法典》第七百一十四条，租赁期满后……（以下为专业回答）" } ]

启动训练也很简单：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --dataset law_dataset \ --template qwen \ --output_dir ./law_agent_lora \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 5e-5 \ --max_length 2048

这里的几个参数值得说清楚。per_device_train_batch_size是单卡一次训练的样本数，QLoRA场景下通常设2到4即可，超过容易OOM；gradient_accumulation_steps是梯度累积步数，它和batch size相乘得到"等效批大小"，决定训练的稳定性——我一般把等效批大小控制在16到32之间；learning_rate非常敏感，LoRA微调一般在1e-5到5e-5之间，太大了模型直接学飞，太小了学不动。

训练完成后合并权重做推理：

from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") model = PeftModel.from_pretrained(base_model, "./law_agent_lora") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") response = model.generate( tokenizer("用户咨询：房东不退押金怎么办？", return_tensors="pt")["input_ids"], max_new_tokens=512 )

4.3 微调数据质量：成也数据，败也数据

我见过太多人把微调做完之后效果反而变差了。排查到最后，几乎都是数据问题。微调数据不是越多越好，网络上流传的那些"清洗过的通用指令数据集"，拿来微调垂直领域往往水土不服——因为行业术语、回答节奏、输出格式都不一样。

做行业微调，正确做法是：找5到10个真正专业的人，让他们手写100到500条高质的种子数据（seed data），然后配合模型生成的合成数据进行扩充。OpenAI在早期指令微调中就采用了类似方法，人工写的种子数据决定了回答的"上限风格"，模型合成的数据负责撑起"数量下限"。

数据质量审查时，我习惯检查三个雷区：

第一是重复与冗余。100条数据里有30条是同一个问题的不同措辞，模型学到的是"偷懒"而不是"泛化"。第二是输入输出不匹配。有些数据的input字段是废话，模型会误以为所有输入都是废话。第三是毒性数据和无害数据混杂。微调时无害数据的指令可能被模型当成"正确的拒绝方式"，结果正常问题也被拒答。

还有一个经验之谈：微调后的模型如果连训练集里的问题都答不好，大概率不是数据问题，而是超参问题——最优先检查学习率是否过大、是否过拟合（epoch数过多）。一般来说，LoRA微调2到3个epoch就够了，再多就开始记住训练集、丢掉通用能力。

5. 应用层面：提示词工程、RAG与Agent

5.1 提示词工程：和模型正确说话的艺术

提示词工程是当前性价比最高的技能——不需要GPU，不需要训练数据，只要你会"和模型沟通"，就能大幅提升输出质量。很多人以为提示词工程就是"说清楚需求"，实际上远不止于此。

一个好的提示词至少包含四层信息：角色设定、任务描述、输出约束、参考示例。举个例子：

你是一位资深的Python后端工程师（角色设定）。 请审查下面这段代码，指出性能问题和安全隐患（任务描述）。 输出格式：每个问题单独一段，按"严重级别 - 问题描述 - 修复建议"排列（输出约束）。 示例：高 - 未使用连接池，建议改用SQLAlchemy的pool_pre_ping参数（参考示例）。 （以下为待审查代码）

这套结构在绝大多数场景下都有效。角色设定让模型进入正确的"知识激活状态"；任务描述明确目标；输出约束让结果可解析；参考示例则像给了模型一个"答题模板"，比单纯说"请专业一点"有用得多。

另一个容易被忽视的原则是"给模型退路"。当你问一个超出知识范围的冷门问题时，模型倾向于编造一个听起来合理的答案。如果你在提示词里补一句"如果信息不足，请明确回答'不知道'，不要猜测"，幻觉率能明显下降。这看起来微不足道，但在RAG等需要高可信度的场景里，是救命级别的细节。

5.2 RAG：给大模型接上外部知识库

大模型的参数知识截止于训练时间，新知识、私有文档、实时信息它一概不知。RAG的思路非常朴素：每次问答前，先从外部知识库检索相关片段，拼进提示词，再让模型基于这些片段作答。用生活化的话说，就是"考试时允许翻书"。

一个完整的RAG系统包含三个环节：文档解析与切块、向量化与检索、生成与引用。工具链我推荐：用LangChain或LlamaIndex做流程编排，用Chroma或FAISS做向量存储，用BGE系列Embedding模型做文本向量化，用你本地部署的大模型做最终生成。

实操中的关键参数是切块长度。切太大了，检索出来的一大段里只有一小段有用，浪费模型上下文且稀释注意力；切太小了，上下文语义不完整，检索效果差。我的经验值是从300到500个字符起步，配合10%到20%的重叠（chunk overlap）。你在"如何用大模型分析股票K线图"这类场景里，本质也是RAG——把历史K线数据转成文本特征，检索出相关时段的行情描述，再让模型做趋势判断和总结。

RAG最常见的坑是"检索结果和问题无关"。这时候先不要怀疑模型，优先检查Embedding模型是否匹配领域——通用Embedding对法律、医疗等专业文本的效果非常差，建议尝试领域微调过的Embedding模型（比如BGE系列针对中文优化的版本）。其次是重排序，用bge-reranker做第二轮精排，比单纯用向量相似度靠谱得多。

5.3 Agent框架：从"问答"到"干活"

如果说RAG解决的是"信息供给"，那Agent解决的就是"行动能力"。Agent的核心思想是让模型不只输出文本，而是输出"动作序列"——调用工具、执行代码、访问API、操作浏览器，再根据动作结果决定下一步。

目前主流的开源Agent框架有LangGraph、AutoGen、MetaGPT、Dify、Coze等。我的个人建议是：如果你刚入门，先用Dify或Coze这类低代码平台理解Agent的Node编排逻辑；如果你要深度做生产级项目，再学LangGraph——它用图结构表达状态流转，可调试性远好于LangChain原生的链式调用。

一个最小可用的Agent流程是：用户输入 → 模型判断是否需要调用工具 → 如果调用工具则输出结构化参数 → 代码执行工具并返回结果 → 模型基于结果生成最终回答。这个"工具调用"能力在开源模型里通过Function Calling实现，Qwen系列、GLM系列都支持得很完善。

用LangGraph写一个人力资源小助手，核心代码其实不长：

from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI llm = ChatOpenAI(base_url="http://localhost:8000/v1", model="Qwen2.5-7B-Instruct") def call_llm(state): response = llm.invoke(state["messages"]) return {"messages": [response]} graph = StateGraph(MessagesState) graph.add_node("llm", call_llm) graph.set_entry_point("llm") graph.add_edge("llm", END) app = graph.compile()

这里只是把Agent的骨架搭起来，真正的复杂之处在于工具注册、错误重试、状态持久化、多轮记忆管理。我的建议是：先跑通一个单工具的闭环，再去碰多Agent协作的复杂玩法，否则调试起来会非常痛苦。

5.4 从API到大模型应用开发：写得快远比写得炫重要

现在免费的或者廉价的模型API非常多，大厂的开放平台、开源社区的公益API、甚至本地vLLM起的自建服务，都可以作为开发底座。对于想做"大模型应用"的人来说，我强烈建议主线用代理API快速迭代业务逻辑，等到方案验证成功了，再考虑私有化部署或微调来做成本优化。

应用开发的最佳实践顺序是：先不写任何代码，用现成的ChatGPT或通义千问把完整的产品交互流程模拟一遍；跑通了，再用API把流程固化下来；再之后，才去考虑RAG、Agent这些进阶能力。很多新手一上来就铺开LangChain搭了一大堆组件，实际效果还不如一段几百行的普通代码调用API来得稳。

一个容易踩的坑是上下文管理。对话类的应用，每次请求都要把历史消息拼进messages数组，如果无脑把整段对话历史全塞进去，很快就把context window撑爆了，而且token费用也会成倍上涨。解决方案是维护一个定长的滑动窗口，只保留最近N轮对话；更高级一点的做法是对历史消息做摘要压缩，把老的对话语义浓缩成一段话继续带着走。这个"上下文工程"看似不起眼，却是生产级应用和Demo之间的分水岭。

6. 常见问题速查与避坑心得

6.1 高频问题清单

我把过去一年带新人、帮读者排障时遇到的典型问题整理成一张表，按出现频率排序：

6.2 硬件受限环境下的替代方案

很多读者一台笔记本、没有GPU，也想学大模型。这条路完全走得通，我的建议是：用免费或低价的API来完成"应用开发"学习；用Google Colab的免费T4 GPU（约15G显存）来完成小模型的微调实验；用CPU推理跑1B~3B的小模型来理解"部署"概念。等这些技能都上手之后，再根据自己的实际预算决定要不要购置GPU设备。

在CPU上跑模型确实慢，但有一个技巧：让模型在CPU上生成时，尽量缩短输入上下文长度，并且使用llama.cpp这类针对CPU优化过的推理后端。实测7B模型在M2 MacBook上能跑到8~12 token/s，体验已经接近可用了。

6.3 学习过程中的三个心态建议

最后说点学习方法论的体会。

一是"先跑通，再优化"。很多人卡在概念理解上迟迟不进入实操，总觉得"理论没学完不敢动手"。我在实际带人中发现，先跑通一个Demo再回头学理论，效率高得多——带着问题去看文档，视野完全不同。比如你亲手部署过Ollama之后，再去看显存、上下文、量化这些概念，完全是两种理解深度。

二是"带着项目学"。纯学技术没有锚点，今天看Transformer明天看LoRA，一周后就忘了。但如果你定了一个明确目标，比如"我要用本地大模型做一个自己的工作日报助手"，那么部署、API调用、提示词优化、甚至微调，都会在项目推进中逐个用到，学习动力和留存率都不可同日而语。

三是"学会看一手资料"。二手博客和视频固然友好，但信息滞后和误传问题严重。当你需要精进某个具体方向时，直接去看官方文档、技术报告、源码——大模型的文档更新速度远超任何教材，跟着官方走永远不会落伍。代码仓库的issue区也是一个被严重低估的宝库，很多疑难杂症在上面的讨论比任何教程都精彩。

我个人在实际带团队时最大的感受是：大模型这个领域，三个月前学的东西可能三个月后就过时了，但学习的方法论是永远不过时的——快速验证、小步迭代、以项目为锚、以一手资料为准。这套思路在你未来的任何一次技术转型中都还能反复用到。