企业官网建设流程全解析

大模型这个词从2023年火到现在，热度不但没降，反而从“技术圈自嗨”变成了“全民都在聊”。但说实话，我接触过不少想入门的朋友，最大的痛点根本不是“不想学”，而是资料太多、太散、太杂——今天刷到一个讲Transformer的，明天看到一个讲微调的，后天又有人推荐某某部署工具，结果学了三个月，连一个能跑起来的完整项目都没有。我自己也是从这条路走过来的，踩过的坑不比谁少。所以这篇内容，我想把“大模型系统性入门”这件事彻底讲清楚，从知识框架怎么搭、学习路线怎么排、环境怎么配、模型怎么选、微调怎么做、部署怎么落地，到提示词工程和智能体开发怎么衔接，全部串成一条线。不管你是刚转行的开发者、想用大模型提效的产品经理，还是纯粹对AI好奇的技术爱好者，只要跟着这条线走，至少能少走半年的弯路。

1. 先把“大模型入门”这件事拆开看

1.1 为什么大多数人学大模型会半途而废

我观察到一个很普遍的现象：很多人学大模型，是从“看论文”或者“看科普视频”开始的。这本身没错，但问题在于，大模型这个领域的知识结构是“倒金字塔”型的——最底层的数学原理（注意力机制、梯度下降、概率建模）非常深，但最上层的应用开发（调API、写提示词、搭智能体）又非常浅。如果你从最底层开始啃，很容易在数学公式里迷失方向，学了两个月还在推导softmax，连一个能对话的Demo都没跑起来，挫败感极强，自然就放弃了。

正确的做法应该是“先跑通，再深入”。先用现成的工具和模型跑通一个完整流程，获得正反馈，然后再回头补原理。这就像学开车，你先得能把车开走，再去研究发动机原理，而不是一上来就拆发动机。

另一个导致半途而废的原因是“资料焦虑”。网上关于大模型的资料太多了，今天有人说Ollama好用，明天有人说vLLM才是正道，后天又有人推荐llama.cpp。你如果每个都追，最后就是每个都浅尝辄止。我的建议是：先锁定一条主线，把这条主线上的每个环节都跑通一遍，再考虑横向扩展。

1.2 大模型入门的知识框架应该怎么搭

我把大模型入门的知识体系分成五个层次，从下到上依次是：

这个框架的核心逻辑是：每一层都建立在前一层的基础上，但每一层都可以独立产出价值。你不需要等第一层完全学透再学第二层，而是可以并行推进，边用边学。

1.3 主流大模型的全景扫描：你该从哪个开始

目前市面上的大模型可以粗略分成几个梯队。第一梯队是闭源商业模型，比如GPT系列、Claude系列、Gemini系列，这些模型能力最强，但需要付费且数据不在自己手里。第二梯队是开源模型，比如Qwen系列、LLaMA系列、DeepSeek系列、Mistral系列，这些模型可以本地部署，适合学习和定制。第三梯队是垂直领域模型，比如专门做代码的、专门做医疗的、专门做金融的。

对于入门者，我的建议是：从开源模型入手，优先选Qwen系列或LLaMA系列。原因很简单：这两个系列的生态最完善，社区资料最多，遇到问题最容易找到答案。Qwen2.5-7B这个尺寸特别适合入门，7B参数在消费级显卡上就能跑起来，微调成本也不高。如果你显卡显存只有8GB，可以考虑Qwen2.5-3B或者用GGUF量化版本。

提示：不要一上来就追求最大的模型。7B模型能跑通的事情，70B模型不一定能跑通，因为你的硬件可能撑不住。先把小模型玩透，再考虑上大模型。

2. 学习路线怎么排才不浪费时间

2.1 第一阶段：用三天时间建立“手感”

很多人忽略了这个阶段，直接跳到看论文或者配环境，结果就是“知其然不知其所以然”。我的建议是，前三天不要碰任何代码，就做三件事：

第一，找几个主流大模型的网页版，挨个用一遍。ChatGPT、Claude、通义千问、Kimi、DeepSeek，每个都聊上半小时。重点感受不同模型在回答风格、推理能力、多轮对话上的差异。这个过程中你会自然形成对“大模型能做什么”的直觉。

第二，看几个高质量的科普视频或文章，了解Transformer的基本结构、注意力机制的核心思想、预训练和微调的区别。不需要看懂数学推导，只需要知道“大概是怎么回事”。

第三，注册一个免费的大模型API，比如硅基流动、智谱AI、百度千帆，这些平台通常都有免费额度。用Python写一个最简单的调用脚本，跑通一次对话。这一步的目的是让你知道“调用大模型”到底是怎么回事。

# 一个最简单的API调用示例（以OpenAI兼容接口为例） from openai import OpenAI client = OpenAI( api_key="你的API Key", base_url="https://api.example.com/v1" # 替换成实际的服务地址 ) response = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[ {"role": "system", "content": "你是一个 helpful 的助手。"}, {"role": "user", "content": "用三句话解释什么是大模型。"} ] ) print(response.choices[0].message.content)

这三件事做完，你对大模型的“手感”就建立起来了。接下来再深入任何方向，都不会觉得虚无缥缈。

2.2 第二阶段：本地部署，把模型“握在手里”

调用API虽然方便，但你会受限于网络、费用和隐私。本地部署大模型是入门路上必须跨过的一道坎。目前主流的本地部署方案有四种：

对于入门者，我强烈建议从Ollama开始。它的安装过程极其简单，Windows和Mac都是一键安装，Linux一条命令搞定。安装完之后，直接ollama run qwen2.5:7b就能跑起来。你不需要关心CUDA版本、不需要配置环境变量、不需要下载模型权重，Ollama全帮你搞定了。

但Ollama的缺点也很明显：它的推理性能不如vLLM，定制能力也不如直接使用Transformers。所以当你需要做微调或者高并发部署时，还是要回到vLLM或Transformers。

注意：本地部署大模型对硬件有硬性要求。7B模型在FP16精度下需要约14GB显存，4-bit量化后需要约4GB显存。如果你的显卡显存不够，可以考虑用CPU推理（速度慢但能跑）或者使用云GPU。

2.3 第三阶段：提示词工程与上下文工程

提示词工程这个词已经被说烂了，但很多人对它的理解还停留在“写一段好的指令”。实际上，提示词工程的核心是控制模型的输出空间。你写的每一句话，都是在缩小模型可能的输出范围，让它更可能生成你想要的结果。

我总结了一个提示词设计的“四要素框架”：

1. 角色定义：告诉模型它是谁。比如“你是一个资深Python工程师”。
2. 任务描述：告诉模型要做什么。比如“请帮我审查以下代码”。
3. 约束条件：告诉模型不能做什么。比如“不要使用第三方库”。
4. 输出格式：告诉模型怎么输出。比如“用JSON格式返回，包含问题列表和修复建议”。

这四个要素缺一不可。很多人只写了任务描述，结果模型输出一堆废话，就是因为没有约束输出格式。

上下文工程是提示词工程的延伸。当你的对话轮次变多，或者需要模型处理长文档时，上下文管理就变得至关重要。核心问题是：模型的上下文窗口是有限的，你怎么在有限的窗口里塞进最有用的信息？

常见的策略包括：滑动窗口（只保留最近N轮对话）、摘要压缩（把历史对话压缩成摘要）、检索增强（从外部知识库检索相关内容注入上下文）。这些策略在后面的RAG章节会详细展开。

2.4 第四阶段：微调，让模型“懂你的业务”

微调是大模型入门路上的一道分水岭。会调API的人很多，会微调的人就少了一大半。但微调其实没有想象中那么难，尤其是有了LoRA和QLoRA之后，消费级显卡也能微调7B模型。

微调的核心流程是：准备数据集 → 选择基座模型 → 配置训练参数 → 开始训练 → 评估效果 → 合并权重 → 部署推理。

数据集准备是最耗时的环节。你需要把业务数据整理成“指令-回答”对，格式通常是JSONL。数据质量比数量重要得多，1000条高质量数据往往比10000条低质量数据效果更好。

{"instruction": "请将以下文本分类为正面或负面情感", "input": "这个产品太好用了，强烈推荐！", "output": "正面"} {"instruction": "请将以下文本分类为正面或负面情感", "input": "质量很差，用了一次就坏了。", "output": "负面"}

训练参数方面，LoRA的秩（rank）、学习率、批次大小是最关键的三个参数。秩越大，微调能力越强，但显存占用也越大。学习率通常设在1e-4到5e-5之间。批次大小根据显存调整，可以用梯度累积来模拟更大的批次。

微调完之后，一定要做评估。评估不能只看loss曲线，要看实际输出。我通常会准备一个包含50-100条测试样本的评估集，人工检查模型的输出是否符合预期。

2.5 第五阶段：应用开发与智能体

当你能够熟练调用模型、部署模型、微调模型之后，就可以进入应用开发阶段了。这个阶段的核心是把大模型的能力封装成产品。

应用开发涉及几个关键技术点：

流式输出：大模型的推理是逐token生成的，如果等全部生成完再返回，用户会等很久。流式输出（SSE）可以让用户看到文字一个一个蹦出来，体验好很多。实现方式是在API调用时设置stream=True，然后逐块读取响应。

RAG（检索增强生成）：当模型的知识不够用时，从外部知识库检索相关内容注入上下文。RAG的核心是向量数据库和检索策略。常用的向量数据库有Chroma、Milvus、Qdrant，检索策略包括相似度检索、关键词检索、混合检索。

Agent框架：Agent是让大模型自主决策、调用工具、完成复杂任务的框架。目前主流的Agent框架有LangChain、LlamaIndex、AutoGPT、CrewAI。Agent的核心是“思考-行动-观察”的循环，模型根据当前状态决定下一步做什么。

多模态：除了文本，大模型还可以处理图像、音频、视频。多模态模型如GPT-4V、Qwen-VL可以理解图片内容，这在很多场景下非常有用。

3. 环境配置：那些教程不会告诉你的坑

3.1 显卡驱动的版本匹配问题

这是新手最容易踩的坑，没有之一。CUDA版本、显卡驱动版本、PyTorch版本、Python版本，这四个东西必须严格匹配，否则就是各种报错。

我遇到过最典型的情况是：PyTorch安装的是CUDA 12.1版本，但显卡驱动只支持到CUDA 11.8，结果torch.cuda.is_available()一直返回False。排查了半天才发现是驱动版本不够。

正确的做法是：先查显卡驱动支持的CUDA版本（用nvidia-smi命令），然后根据这个版本去PyTorch官网找对应的安装命令。不要直接pip install torch，那样装的是CPU版本。

# 查看显卡驱动和CUDA版本 nvidia-smi # 输出示例 # CUDA Version: 12.4 # 根据CUDA版本安装PyTorch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

注意：nvidia-smi显示的CUDA版本是驱动支持的最高版本，不是当前安装的CUDA版本。实际安装的CUDA版本用nvcc --version查看。

3.2 显存不够用的几种解决方案

显存不够是大模型入门路上最常见的硬件问题。7B模型FP16需要14GB，4-bit量化需要4GB，但很多人显卡只有8GB或12GB。这时候有几种解决方案：

第一，使用量化模型。GGUF格式的模型可以在CPU上运行，4-bit量化后7B模型只需要4GB左右内存。llama.cpp和Ollama都支持GGUF格式。

第二，使用QLoRA微调。QLoRA把基座模型量化到4-bit，然后在此基础上训练LoRA适配器，大幅降低显存需求。7B模型QLoRA微调只需要6-8GB显存。

第三，使用梯度累积和梯度检查点。梯度累积用小批次模拟大批次，梯度检查点用时间换空间，都能降低显存占用。

第四，使用云GPU。如果本地硬件实在不够，可以租用云GPU，按小时计费，成本可控。

3.3 Python环境管理的正确姿势

我见过太多人因为Python环境混乱而放弃学习。不同项目依赖不同的库版本，全局安装必然冲突。正确的做法是：每个项目一个独立的虚拟环境。

推荐使用conda或venv。conda的优势是可以管理CUDA版本，venv更轻量。我个人的习惯是用conda创建环境，然后在环境内用pip安装包。

# 创建conda环境 conda create -n llm python=3.10 conda activate llm # 安装PyTorch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124 # 安装其他依赖 pip install transformers datasets peft accelerate

提示：Python版本建议选3.10或3.11，这两个版本兼容性最好。3.12虽然新，但有些库还没适配。

4. 模型选择：不同场景下该用哪个模型

4.1 按任务类型选模型

不同的任务对模型能力的要求不同。我整理了一个简单的选型参考：

对于入门者，我建议从Qwen2.5-7B-Instruct开始。这个模型在中文任务上表现优秀，社区资料丰富，微调教程也多。等你熟悉了整个流程，再根据具体需求换其他模型。

4.2 按硬件条件选模型

硬件条件是选模型的硬约束。我按显存大小给一个参考：

• 8GB显存：Qwen2.5-3B（FP16）、Qwen2.5-7B（4-bit量化）
• 12GB显存：Qwen2.5-7B（FP16）、Qwen2.5-14B（4-bit量化）
• 24GB显存：Qwen2.5-14B（FP16）、Qwen2.5-32B（4-bit量化）
• 48GB显存：Qwen2.5-32B（FP16）、Qwen2.5-72B（4-bit量化）
• 80GB显存：Qwen2.5-72B（FP16）

如果显存不够，优先考虑量化而不是换更小的模型。4-bit量化的7B模型通常比FP16的3B模型效果好。

4.3 微调场景下的基座模型选择

微调场景下，基座模型的选择要考虑三个因素：任务类型、数据量、硬件条件。

如果数据量少于1000条，建议用LoRA微调，基座模型选7B左右。如果数据量在1000-10000条，可以用QLoRA微调14B模型。如果数据量超过10000条，可以考虑全量微调，但硬件要求很高。

任务类型也很关键。如果是分类任务，小模型就够了。如果是生成任务，需要更大的模型。如果是领域知识注入，LoRA通常足够。如果是风格迁移，可能需要更大的秩。

5. 微调实战：从数据准备到效果评估

5.1 数据集构建的“三要三不要”

数据集质量直接决定微调效果。我总结了“三要三不要”：

三要：

• 要多样性：同一个任务的不同表达方式都要覆盖
• 要准确性：输出必须是正确的，不能有错误
• 要一致性：格式统一，风格统一

三不要：

• 不要重复：重复数据会导致模型过拟合
• 不要噪声：错误标注比没有标注更糟糕
• 不要失衡：各类别的样本数量要均衡

数据集构建完之后，一定要做数据清洗。常见的清洗操作包括：去除空值、去除重复、去除过长或过短的样本、统一标点符号。

5.2 LoRA微调的关键参数解析

LoRA的核心思想是在预训练模型的权重矩阵旁边加一个低秩分解矩阵，只训练这个低秩矩阵，不动原始权重。这样可训练参数从几十亿降到几百万，显存需求大幅降低。

关键参数包括：

• r（秩）：低秩矩阵的秩，通常取8、16、32、64。秩越大，微调能力越强，但参数量也越大。入门建议从16开始。
• lora_alpha：缩放因子，通常设为r的2倍。
• lora_dropout：Dropout率，防止过拟合，通常设0.05-0.1。
• target_modules：哪些层应用LoRA，通常是q_proj、v_proj、k_proj、o_proj。
• learning_rate：学习率，通常设1e-4到5e-5。
• num_train_epochs：训练轮数，通常3-5轮。
• per_device_train_batch_size：批次大小，根据显存调整。
• gradient_accumulation_steps：梯度累积步数，模拟更大批次。

from peft import LoraConfig lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["q_proj", "v_proj", "k_proj", "o_proj"], bias="none", task_type="CAUSAL_LM" )

5.3 训练过程中的loss曲线怎么看

Loss曲线是训练过程中最重要的监控指标。正常的loss曲线应该是先快速下降，然后逐渐趋于平缓。如果loss一直不降，说明学习率太小或者数据有问题。如果loss震荡剧烈，说明学习率太大。如果loss先降后升，说明过拟合了。

但loss低不代表效果好。我见过loss降到0.1但实际输出一塌糊涂的情况，原因是数据集中有大量重复样本，模型只是记住了答案。所以一定要用独立的评估集来验证效果。

评估集应该包含训练集中没有出现过的样本，覆盖各种边界情况。评估方式可以是人工评估，也可以用另一个模型来打分。

5.4 微调后的模型合并与部署

LoRA训练完之后，适配器权重和基座模型是分开的。部署时有两种方式：一种是加载基座模型后再加载适配器，另一种是把适配器合并到基座模型里。

合并的好处是部署简单，只需要一个模型文件。合并的代码如下：

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, "./lora_adapter") merged_model = model.merge_and_unload() merged_model.save_pretrained("./merged_model") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") tokenizer.save_pretrained("./merged_model")

合并后的模型可以用vLLM或Ollama部署。vLLM的吞吐量更高，适合生产环境。Ollama更简单，适合个人使用。

6. 部署方案：从个人电脑到生产环境

6.1 Ollama：个人电脑智能化的最快路径

Ollama是目前最简单的本地部署方案。安装完之后，一条命令就能跑模型。它还提供了REST API，可以方便地集成到其他应用里。

# 安装Ollama（Linux） curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行模型 ollama run qwen2.5:7b # 查看已下载的模型 ollama list # 启动API服务 ollama serve

Ollama的API兼容OpenAI格式，所以你可以用OpenAI的SDK来调用它。这意味着你可以在本地开发，然后无缝切换到云端API。

注意：Ollama默认只监听本地端口，如果需要局域网访问，需要设置OLLAMA_HOST=0.0.0.0。

6.2 vLLM：生产环境的高吞吐推理

vLLM的核心优势是PagedAttention技术，它把注意力机制的KV缓存分成块来管理，大幅提高了显存利用率和吞吐量。在高并发场景下，vLLM的吞吐量可以是Transformers的10倍以上。

# 安装vLLM pip install vllm # 启动API服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

vLLM的配置参数比较多，关键的是max-model-len（最大上下文长度）和gpu-memory-utilization（显存利用率）。显存利用率设太高会导致OOM，设太低会浪费显存。通常设0.85-0.9比较合适。

6.3 llama.cpp：CPU也能跑大模型

llama.cpp是用C++重写的大模型推理框架，支持CPU推理和多种量化格式。它的优势是硬件要求低，MacBook、树莓派都能跑。

# 克隆并编译 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make # 下载GGUF模型并运行 ./main -m qwen2.5-7b-q4_k_m.gguf -p "你好" -n 128

GGUF格式的量化等级很多，从Q2到Q8，数字越大精度越高，文件也越大。Q4_K_M是性价比最高的选择，精度损失小，文件大小适中。

6.4 流式输出与实时渲染的实现

流式输出是提升用户体验的关键技术。大模型生成一个完整回答可能需要几秒到几十秒，如果等全部生成完再显示，用户会以为程序卡死了。流式输出让文字逐字出现，体验好很多。

实现流式输出的核心是SSE（Server-Sent Events）。服务端逐块发送数据，客户端逐块接收并渲染。

# 服务端：FastAPI实现SSE流式输出 from fastapi import FastAPI from fastapi.responses import StreamingResponse from openai import OpenAI app = FastAPI() client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy") @app.get("/chat") async def chat(query: str): def generate(): stream = client.chat.completions.create( model="qwen2.5-7b", messages=[{"role": "user", "content": query}], stream=True ) for chunk in stream: if chunk.choices[0].delta.content: yield f"data: {chunk.choices[0].delta.content}\n\n" yield "data: [DONE]\n\n" return StreamingResponse(generate(), media_type="text/event-stream")

前端用EventSource接收数据，逐块追加到页面上。同时要支持abort操作，让用户可以中途取消生成。

7. 提示词工程与上下文工程的实战技巧

7.1 结构化输出的三种实现方式

让大模型输出结构化数据（JSON、XML、YAML）是应用开发中的常见需求。有三种实现方式：

第一种是提示词约束。在提示词里明确要求输出JSON格式，并给出示例。这种方式最简单，但模型不一定每次都遵守。

第二种是JSON模式。OpenAI和部分模型支持response_format={"type": "json_object"}参数，强制模型输出合法JSON。这种方式最可靠，但需要模型支持。

第三种是函数调用。把输出格式定义成函数参数，模型会按照函数签名输出。这种方式最灵活，适合复杂结构。

# 使用JSON模式 response = client.chat.completions.create( model="qwen2.5-7b", messages=[ {"role": "system", "content": "你是一个信息抽取助手，请以JSON格式输出。"}, {"role": "user", "content": "从以下文本中抽取人名和公司名：张三在阿里巴巴工作。"} ], response_format={"type": "json_object"} )

7.2 上下文窗口管理：滑动窗口与摘要压缩

上下文窗口是有限的，当对话轮次变多时，必须管理上下文。常见的策略有：

滑动窗口：只保留最近N轮对话，丢弃更早的。这种方式简单，但会丢失早期的重要信息。

摘要压缩：把历史对话压缩成摘要，保留关键信息。这种方式能保留更多信息，但摘要本身也会消耗token。

检索增强：把历史对话存入向量数据库，每次根据当前问题检索相关历史。这种方式最灵活，但实现复杂。

我通常的做法是：前几轮对话保留原文，超过阈值后开始摘要压缩，同时把关键信息（如用户偏好、已确认的事实）单独存到一个“记忆”字段里，每次对话都注入。

7.3 提示词注入攻击与防御

提示词注入是应用开发中必须考虑的安全问题。攻击者可以通过精心构造的输入，让模型忽略原有指令，执行攻击者的指令。

防御措施包括：输入过滤（检测并过滤可疑的指令性语句）、指令隔离（把用户输入和系统指令用特殊标记隔开）、输出审查（检查模型输出是否包含敏感信息）。

注意：提示词注入没有完美的防御方案，只能提高攻击成本。在涉及敏感操作时，一定要加人工审核或二次确认。

8. 智能体与RAG：大模型应用的进阶方向

8.1 RAG的核心流程与常见坑

RAG（检索增强生成）是解决大模型知识不足和幻觉问题的主流方案。核心流程是：文档切分 → 向量化 → 存储 → 检索 → 注入上下文 → 生成回答。

每个环节都有坑。文档切分太粗，检索精度低；切分太细，上下文不完整。向量化模型选不好，检索效果差。检索策略单一，召回率低。注入上下文太长，超出窗口限制。

我的经验是：文档切分用递归切分，块大小512-1024个token，重叠128个token。向量化模型用BGE或M3E，中文效果好。检索用混合检索（向量+关键词），召回率更高。

8.2 Agent框架选型：LangChain还是自己写

Agent框架的选择取决于你的需求。LangChain生态完善，组件丰富，但抽象层多，调试困难。LlamaIndex专注于RAG，检索功能强。AutoGPT适合探索性任务。CrewAI适合多Agent协作。

我的建议是：入门阶段用LangChain快速搭建原型，理解Agent的工作原理。生产环境可以考虑自己写，因为框架的抽象层会限制灵活性，而且调试成本高。

Agent的核心是“思考-行动-观察”循环。模型根据当前状态决定调用哪个工具，工具返回结果后，模型再决定下一步。这个循环直到任务完成或达到最大轮次。

8.3 多模态与联网搜索的集成思路

多模态和联网搜索是扩展大模型能力的重要方向。多模态让模型能理解图像、音频、视频。联网搜索让模型能获取实时信息。

多模态的集成方式是：用多模态模型（如Qwen-VL）处理图像输入，把图像编码成向量，和文本向量一起注入上下文。

联网搜索的集成方式是：把搜索工具封装成Agent的一个工具，模型判断需要搜索时调用搜索API，把搜索结果注入上下文。

提示：联网搜索要注意信息来源的可靠性，最好用多个来源交叉验证。

9. 一些踩坑之后的真心话

学大模型这件事，最怕的就是“贪多嚼不烂”。我见过太多人今天学微调，明天学Agent，后天又去搞多模态，结果每个都只懂皮毛。我的建议是：先深挖一个方向，把它做到能拿出手的程度，再横向扩展。

另外，不要迷信“最新最强”的模型和工具。今天出的新模型，可能下个月就被超越了。与其追新，不如把基础打牢。Transformer的原理、微调的核心逻辑、部署的关键参数，这些东西不会因为模型更新而失效。

还有一点很重要：一定要动手。看一百篇教程，不如自己跑通一个项目。你会在动手过程中遇到各种教程里没写的问题，解决这些问题的过程才是真正成长的过程。

最后分享一个我个人的学习习惯：我会维护一个“踩坑笔记”，每次遇到问题就记下来，包括问题现象、排查过程、解决方案。这个笔记现在已经有几百条了，每次遇到新问题，先翻笔记，往往能找到类似的解决方案。这个习惯帮我节省了大量时间，也让我对很多问题的理解更加深入。