大模型系统性入门：从本地部署到微调实战全解析

聊大模型的资料，网上已经多到刷不完了。但多数人卡住的从来不是“没资料”，而是“资料太碎”：今天刷到一篇讲Prompt，明天看到一段微调代码，后天又收藏一个部署教程，最后的结果往往是收藏夹吃灰，脑子里还是一团浆糊。

我做了几年大模型相关的工程化落地，反复带过不少新人，也踩过不少自己挖的坑。这篇东西不打算堆链接，也不做什么“X天入门到精通”的路线图，而是想把“大模型的系统性入门”这件事拆开揉碎：从模型是怎么来的，到你电脑上怎么跑起来，再到怎么做微调、怎么接进业务、怎么评估效果，一条线讲清楚。每个环节我会给出实际可执行的步骤、参数和避坑经验，不是那种“你装一下就知道”的敷衍话术。

如果你属于下面任何一种情况：刚接触大模型、准备转行做AI应用开发、想用自己的电脑跑私有模型、或者正在给业务找落地场景，这篇内容值得你花时间读完。看完你会发现，大模型入门并没有想象中那么玄，它更像一条组装流水线——把每个环节都搞清楚，剩下的就是体力活。

1. 先建立全局认知：大模型不是魔法，是一条完整的生产链路

很多人第一次接触大模型，被各种术语砸晕：预训练、SFT、RLHF、LoRA、量化、推理加速、Agent、RAG……每个词单独看都有解释，串起来就懵。这是因为大家缺少一张“全景图”。

1.1 从“概率生成器”到“产品化”的四步走

大模型本质上就是一个超级复杂的概率函数。给它一串文字，它预测下一个词的概率分布，然后不断重复，生成一段看起来像“人话”的回答。所谓“7B”“13B”“70B”，指的是模型里的参数数量（Billion），参数越多，通常能力越强，但需要的算力和显存也越大。

从模型到产品，至少要经历四个环节，这也是系统性学习必须掌握的主线：

• 预训练：在海量通用文本上训练基础模型，让模型学会语言、知识和推理。这个环节普通人和中小企业基本不用碰，成本太高（动辄几百万美元算力）。
• 微调：在基础模型上用特定领域数据做二次训练，让模型“懂行”。比如拿医疗问答数据微调一个通用模型，让它变成“医疗助手”。这是工程师最常接触的环节。
• 部署与推理：把训练好的模型跑起来，对外提供接口服务。涉及显存管理、量化压缩、并发优化等工程问题。
• 应用集成：把模型接进业务流程，做成聊天助手、智能客服、内容分析工具等，配合提示词、工具调用、检索增强等上层技术。

我用一个类比帮助新人理解：预训练好比是“通识教育”，一个人读完小学到大学，知识面广但不专业；微调像是“职业培训”，毕业后进医院实习，逐渐变成专科医生；部署推理是“安排门诊排班”，让医生能接诊；应用集成则是“你通过挂号平台找到合适的医生看病”。

1.2 学习路线的两条分叉：应用派和工程派

结合我这些年带人的经验，入门大模型首先要明确方向，不然会在岔路口反复横跳：

• 应用开发路线：重点是会在API层做产品。你需要学好提示词工程、上下文管理、函数调用（Function Calling）、RAG、Agent框架，甚至不需要懂Transformer的数学原理。适合前端、后端、产品背景的人。
• 模型工程路线：重点是让模型在受限资源下跑起来、训练得更懂领域。你需要掌握深度学习基础、PyTorch、GPU优化、微调框架、量化原理。适合算法、基础设施背景的人。

当然两条线有交叉：做应用的人如果懂一点部署，调接口时不会被“模型加载慢”“显存不够”这类问题卡住；做工程的人如果懂一点应用，微调出来的模型不会“跑分高但产品上没法用”。所以我下面讲的内容，两条线都会覆盖，但整体偏实操，目标是让你先跑通一条最小闭环。

1.3 系统性学习的关键原则：先跑通，再优化

我见过太多人入门失败，不是因为笨，而是因为想一步到位。昨天刚装好环境，今天就想着要微调一个媲美GPT-4的行业大模型，中途任何一个环节报错就心态崩了。

系统入门的正确姿势是“最小闭环”：先用最小的成本让一个模型在本地跑起来，然后调通API调用，再逐步叠加微调、RAG、Agent这些复杂度。每走一步，你都能看到实实在在的输出，信心和认知是同步增长的。后面第三章到第五章，我就是按照这个闭环顺序来组织的。

2. 环境与硬件选型：不要让配置问题卡住你的学习进度

“我电脑能不能跑大模型”是新人问得最多的问题。先说结论：入门阶段，一台普通电脑完全够用了，关键是选对模型的尺寸和量化方式。

2.1 显存、内存与算力：决定你能跑多大的模型

大模型推理时，模型参数要完整加载到内存或显存里，所以显存（显卡）或统一内存（苹果M系列）的容量是第一瓶颈。

一个粗略的估算公式：模型显存占用约等于参数量 × 每个参数的字节数。FP16（半精度）下，每个参数占2字节，所以：

• 7B模型：约14GB显存
• 13B模型：约26GB显存
• 70B模型：约140GB显存

这个数字对大多数人来说是劝退级的，所以实际部署时几乎都会用量化压缩。把参数变成4-bit（Q4）或8-bit（Q8），7B模型可以压缩到4-6GB，普通游戏显卡甚至部分集成显卡都能跑起来。这也是为什么GGUF格式这么流行——它把模型量化打包成单文件，配合llama.cpp这类纯C++推理引擎，把大模型的本地部署门槛拉到了极低。

我用一张表说明不同配置的可行方案：

这里特别说一下AMD显卡。热搜里“rx6750gre训练大模型”说明AMD用户不少，但我在PyTorch、llama.cpp、Ollama等生态里实际试下来：RX 6750 GRE 12GB跑推理完全可行（llama.cpp支持ROCm和OpenCL后端，Ollama也有AMD支持），但微调训练建议绕道——PyTorch的ROCm生态比CUDA差一大截，很多框架（比如unsloth、部分微调脚本）对A卡支持不完善，你会花大量时间在环境排错上，而不是学习本身。如果你想认真搞模型工程，NVIDIA显卡依然是首选；如果只是本地推理和应用开发，A卡完全能胜任。

2.2 除了显卡，还要准备什么

• 内存：建议16GB起步，32GB更稳。加载模型、预处理数据、跑Web应用，内存是隐形瓶颈。我见过很多人显卡不错，但内存只有8GB，加载7B模型时系统直接卡死。
• 硬盘：模型文件动辄几个GB甚至几十GB，建议预留至少40GB空间，最好用NVMe固态，加载模型速度差很多。
• 操作系统：Linux（Ubuntu/CentOS）是首选，绝大多数AI生态工具链原生支持；Windows下WSL2也行；macOS适合开发和体验，但做训练会被统一内存带宽限制。

2.3 云GPU还是本地？我的建议

如果你手头没有合适的显卡，但急着学，不用先花钱买卡。国内主流的云GPU平台（AutoDL、恒源云等）按小时计费，一张RTX 4090也就两三块钱一小时，首次体验微调和部署，几十块钱足够了。本地环境适合反复调试和学习，云上适合跑一次性的大任务，两条腿走路最划算。

3. 动手入门三条线：模型下载、本地部署、API调用

理论说再多，不如动手跑一个模型。这一章我给出三条实操线，你按顺序走一遍，整个人对大模型的体感就完全不一样了。

3.1 模型从哪来：主流下载平台和热门模型

大模型的下载平台，主要就是两个：Hugging Face（HF）和魔搭ModelScope。

Hugging Face是全球最大的模型社区，几乎所有开源模型的原始权重都在上面。国内直连不稳定，建议配置HF镜像站（hf-mirror.com）来加速下载，具体做法是设置环境变量HF_ENDPOINT=https://hf-mirror.com再用huggingface-cli download下载。魔搭是阿里出品的国内社区，中文生态好，下载速度快，很多国产模型（Qwen系列、DeepSeek系列）同步发布在这里，网络条件一般的优先用魔搭。

新手应该从哪些模型入手？我给一个选型表：

我的经验：中文场景凡是犹豫不决，首选Qwen系列准没错。它的中文语料和指令遵从度在开源模型里属于第一梯队，社区讨论多，遇到问题容易搜到解决方案。

3.2 最小可用部署：Ollama和llama.cpp

部署方案我推荐从Ollama开始，它是最没有门槛的一条路：装好之后，两条命令就能把一个7B模型跑起来。

# 安装完成后，拉取模型 ollama pull qwen2.5:7b # 运行模型，进入交互界面 ollama run qwen2.5:7b

Ollama会自动完成量化、加载、硬件加速等复杂环节，对新手极其友好。更重要的是，Ollama启动后默认在本地开了一个API服务（http://localhost:11434），这意味着你可以直接通过HTTP接口调用模型，后面做应用开发时非常方便，所以它不是玩具，而是能真正集成进产品的工具。

如果你想过一把“硬核部署”的瘾，就上llama.cpp。它是完全基于C/C++实现的推理引擎，对CPU和各类显卡的支持非常灵活，也是Android等端侧设备集成大模型的基础。用llama.cpp跑一个量化模型的典型命令是：

# 下载GGUF格式模型后 ./llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf -p "你好，请自我介绍" -n 256

GGUF格式的文件需要去Hugging Face或魔搭搜索，一般会有多个量化档位（q2_k、q4_k_m、q8_0等）。档位越低文件越小，速度越快，但效果损失越大；q4_k_m是公认的综合平衡点。

Android端集成GGUF模型，就是靠llama.cpp的Android接口或各类封装库实现的，把量化后的GGUF文件放进App资产目录，运行时加载并做对话。这个方向门槛稍高，但如果你有移动端背景，这会是一个很好的差异化技能点。

3.3 服务化部署：vLLM与生产环境衔接

Ollama和llama.cpp解决的是“单机用起来”的问题，但真实业务场景需要高并发、低延迟的服务化部署，这时候就要上vLLM。

vLLM是一个高性能推理引擎，核心优势是PagedAttention和Continuous Batching两项技术：前者把KV Cache分页管理，提高显存利用率；后者让多个请求在GPU上动态拼接批处理，吞吐量能比朴素方案高好几倍。

启动一个OpenAI兼容的服务，只需要一条命令：

vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000

启动后，它会监听http://localhost:8000/v1，完全兼容OpenAI的接口格式。换句话说，你之前写过的任何OpenAI SDK代码，只要把base_url改成http://localhost:8000/v1，就能无缝切换到本地模型。这也是很多工具（比如一些代码编辑器插件）能“接入”非OpenAI模型的原理——它们支持自定义OpenAI兼容接口地址，本质上是接口格式的统一，跟模型专不专属无关。

实际操作中，vLLM的显存管理也带来了一个新手坑：默认会预占大量显存作为KV Cache，如果模型加载后报OOM，可以调低--max-model-len（限制最大上下文长度）和--gpu-memory-utilization（设为0.85左右），给后续请求留出余量。

3.4 用API接进你的程序：SSE流式输出与中断

模型服务跑起来后，接下来就是编程层面的“最后一公里”：把模型的回复渲染到界面上。

如果只是简单调用，发一个POST请求拿完整回复就够了。但真实产品（聊天助手、Copilot）几乎都会用SSE（Server-Sent Events）做流式输出——模型吐一个字，界面就渲染一个字，这就是你为什么能看到AI“打字机效果”的原因。相比等全部生成完再显示，SSE的体验好得多，用户等待的心理感知时间也短得多。

在前端，一个配合AbortController实现“停止生成”的SSE处理逻辑可以这样写：

const controller = new AbortController(); const response = await fetch('http://localhost:8000/v1/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ model: 'qwen2.5-7b', messages: [{ role: 'user', content: '讲一个关于冬天的小故事' }], stream: true }), signal: controller.signal }); // 读取流式数据 const reader = response.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value); // 解析chunk中的data字段并渲染 } // 用户点击“停止”按钮时调用 controller.abort();

后端方面，如果你用Python FastAPI，可以用sse-starlette库，把模型每次生成的增量通过EventSource推给前端。如果你用Java，Spring AI已经封装好了一套SSE接口，配上一个合适的模型适配器，一个完整的前后端对话链路很快就能搭起来。

4. 微调实战：如何让通用模型变成你的领域专家

微调是“大模型入门”热搜里频率最高的词之一，也是很多人最感兴趣、也最容易翻车的环节。先说一个扎心的真相：微调不是万能的。如果你的诉求是“让模型知道某个领域的知识”，优先尝试RAG（检索增强），也就是把知识放到外部数据库，检索后拼进上下文。只有当你需要“改变模型的输出风格、遵循特定指令格式、做特定任务”时，微调才是正确的选择。

4.1 微调的全家桶：全参微调、LoRA、QLoRA

从训练方式看，微调主要分三类：

• 全参微调（Full Fine-tuning）：更新模型所有权重，效果上限最高，但显存需求巨大。哪怕是7B模型，全参微调也需要至少60-80GB显存，普通人的电脑基本跑不动。
• LoRA（Low-Rank Adaptation）：冻结原模型，只训练一小部分低秩矩阵（相当于在模型旁边加了一个小型旋钮）。7B模型做LoRA微调，12-24GB显存就能跑起来，效果接近全参微调。这是目前最主流的方式。
• QLoRA（量化LoRA）：把底座模型先量化到4-bit，再做LoRA训练。8GB显存就能微调7B模型，门槛更低，细节上会有一点点效果损失。

实操中我建议直接学QLoRA：它把微调的门槛拉到了消费级显卡的水平，而且现在主流框架（LLaMA-Factory、unsloth）已经把整个过程封装得很傻瓜了。

4.2 数据准备：微调成败的第一关键

微调不是“多多益善”，而是“精而准”。我见过太多人拿几万条爬来的对话数据喂给模型，结果越训越笨。高质量微调数据有三个特征：

• 格式统一：通常用JSONL格式，每行一条样本，包含instruction（指令）、input（输入）、output（期望输出）三个字段。
• 目标明确：每条数据对应一个你希望模型学会的行为。比如客服场景，数据就应该是“用户问→客服得体回答”的配对，不要混入不相关的闲聊。
• 覆盖边界：除了正向例子，也要包含模型不该做什么的边界样本，比如“这个问题我无法回答，请补充更多信息”。

我处理数据时必做的几个清洗步骤：去重（重复样本超过3遍会让模型死记硬背）、过滤低质量（长度过短、带广告、含乱码）、统一全半角标点、校验JSON格式。这一步没有太高技术含量，但恰恰是最影响最终效果的。数据质量差，后面对话效果差，甚至可能出现“复读机”式的灾难。

4.3 基于LLaMA-Factory的一次完整微调实操

LLaMA-Factory是目前最友好的微调工具，它把底模加载、LoRA配置、训练、导出封装得非常干净。以下是本地微调Qwen2.5-7B的典型流程：

# 1. 安装 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e . # 2. 准备数据（example.jsonl） # {"instruction": "根据产品描述生成广告文案", "input": "这是一款智能手环...", "output": "..."} # 3. 启动微调 llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --dataset example \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --lora_rank 16 \ --lora_alpha 32 \ --output_dir ./qwen-sft-lora \ --quantization_bit 4 \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 16 \ --max_source_length 1024

这几个关键参数的取值逻辑我说明一下：

• lora_rank（秩）：决定LoRA矩阵的大小，通常8-64之间。秩越大可学习容量越大，但也更容易过拟合和吃显存，7B模型从16开始是比较稳的。
• learning_rate（学习率）：LoRA的常用范围是1e-4到2e-5。太高会导致模型“疯掉”，太低则训不动。如果发现loss震荡，直接降到2e-5。
• per_device_train_batch_size配合gradient_accumulation_steps：单卡显存有限，先设batch为1，再通过梯度累积凑一个等效大batch，训练更稳定。
• max_source_length：限制输入长度，显存不够时优先从这里压缩。

训练完成后，加载LoRA权重做测试可以用相同的框架，最终导出合并模型用llamafactory-cli export。整个链路跑通后，你才算真正摸到了“行业大模型定制化”的门槛。

4.4 微调翻车现场和排查心得

我在微调上踩过的坑，几乎可以写一本书。这里挑几个最典型的，帮你排雷：

• Loss降了但效果变差：这是过拟合的典型症状。优先检查是不是数据重复太多、epoch太多。我见过有人跑10个epoch，导致模型只会背答案，一到新问题就胡言乱语。所以微调不要无脑追求低loss，一般2-3个epoch足够，训完必须用没见过的数据测。
• Loss全程不降：先查学习率是不是太小，再查数据是否全是同一答案（模型没有可学的东西），最后查是不是特殊token或格式放错了位置。
• 显存OOM：把per_device_train_batch_size调到1，打开gradient_checkpointing，再不行就降低max_source_length，或换更小的底模。OOM的本质就是资源不够，降低某一项指标总能解决。

5. 提示词工程、RAG与Agent：把模型能力用到极致

微调和部署完成，模型本身已经能干活了。但要做成一个真正好用的产品，还需要一层“控制层”，这就是提示词工程、上下文工程、RAG和Agent框架的用武之地。这些技术本质上都是在不动模型权重的前提下，通过输入和组织方式去引导模型输出。

5.1 提示词工程和上下文工程：不是“玄学”，是结构化沟通

很多人以为提示词工程就是“说话技巧”，其实它在工程化之后已经相当系统化了。一个高质量的System Prompt至少包含五类信息：角色定义、任务目标、输入格式、输出约束、边界兜底。比如：

你是一名资深数据分析师。请根据用户提供的销售数据回答问题。 要求： 1. 只分析数据中出现的事实，不要编造数据 2. 使用表格输出结果 3. 如果数据不足，明确告知缺少哪些信息

上下文工程比提示词工程更底层：模型能用的上下文窗口是有限的，怎么在这个窗口里塞入最有效的信息？比如历史对话怎么压缩、工具返回结果怎么格式化、知识库片段怎么排序。实际操作中，上下文工程的思路是：先量化每个组件大概占多少token，再按优先级分配，保证核心指令和最新用户内容不被挤出窗口。这一块的技术含量完全不亚于微调，很多大厂团队把它当作独立工程方向在做。

5.2 RAG：让大模型拥有“实时知识”

大模型的知识截止到训练数据为止，而且容易幻觉。RAG（检索增强生成）的解法非常朴素：用户提问时，先从外部知识库（如公司的产品文档、商品库）里检索相关片段，跟问题一起拼进Prompt，让模型基于这些片段回答。

一个最小RAG流程包含：

1. 把文档切分成小块（chunk），用Embedding模型转成向量，存入向量数据库（如Milvus、Chroma、pgvector）。
2. 用户提问时，把问题转成向量，在库里做相似度检索，取Top-K相关片段。
3. 把“用户问题+检索片段”拼成Prompt，发给大模型生成回答。

这种方案最大的优势是灵活：文档更新了，只改数据库，不用重新微调模型。我在实际操作中度业务类的内容，首选RAG，只有当格式和风格需要固定时，才考虑上微调。Embedding模型的选型，中文场景推荐BGE系列（比如bge-m3），搭配Qwen这类中文生成模型，效果比较稳。

5.3 Agent框架：让模型学会调用工具

Agent（智能体）是大模型应用最近最火的形态，热搜词里“大模型智能体旅游推荐”“主流agent框架有哪些”也证明了大家对这个方向的兴趣。Agent的本质是：不再是“一问一答”，而是让模型理解“任务”，自主拆解步骤，调用外部工具（搜索、订票、写代码、跑SQL），最终完成任务。

主流的Agent框架我大概梳理一下：

选框架时我的原则很简单：团队用什么语言就选什么生态，不要为了“技术时髦”引入一堆没人维护的依赖。模型本身的能力在快速迭代，Agent框架只是粘合剂，别让粘合剂反过来成为项目的复杂度来源。

6. 大模型的评测、安全与合规：别只看跑分和Loss

越深入大模型，越要面对一个扎心问题：模型效果到底怎么评价？很多新人对“效果好不好”的判断只有主观试聊，这远远不够。系统性的评估至少包含三个层面：能力评测、安全评测、业务效果评测。

6.1 怎么客观评估模型效果

• 标准评测集：CEval（中文综合能力）、MMLU（英文多学科）、GSM8K（数学）、HumanEval（代码）。这些评测集有标准答案，可以横向对比不同模型的分数。跑评测集可以在vLLM部署后用脚本批量调用，也可以直接用lm-evaluation-harness这类工具。
• 文本生成指标：ROUGE、BLEU等。它们衡量生成文本和参考文本的重合度，适合摘要、翻译这类任务，但对开放对话的参考价值有限，别太依赖。
• 人工/大模型对比评测：让多个模型回答同一批测试问题，人工（或者用GPT-4等强模型）打分对比。这是实际业务中最常用的方法，胜率能直观反映哪个模型更贴合需求。

关键认知：微调时Loss降了不代表效果变好。Loss是训练集上的拟合程度，而你要的往往是真实场景的泛化能力。所以微调后必须做一轮与训练数据不重叠的业务测试，读过用户真实输入和真实预期输出，统计击中率，这才叫真正评估。

6.2 投毒测试与对抗攻击

“大模型投毒测试”这个词值得单独拎出来聊。所谓投毒（Poisoning），指攻击者在训练数据里塞入恶意样本，让模型在某些触发条件下输出有害或错误内容。这种攻击在开源数据集、公开爬虫语料、甚至微调数据集里都可能存在。我在实际工程中遇到过的案例是：某开源数据集里隐藏了特定触发词，模型只要见到该词就输出违规广告。

做投毒测试的常用手段包括：在测试集中加入触发样例，观察模型是否出现异常输出；用红队（Red Team）方式反复对抗测试边界场景；对模型输出做安全过滤层，兜底不可信内容。作为个人开发者，最实际的防范手段很简单：不要下载来源不明的数据集，不要用不可信渠道拿到的底模，微调数据自己清洗三遍以上。

6.3 合规底线和幻觉控制

这部分我不想讲得太套话，但必须强调：做任何大模型应用，第一原则是“知道模型会胡说八道”，因此所有面向用户的产品都必须加免责声明、敏感内容过滤、可溯源机制。另外，从训练数据收集到用户隐私处理，都要守住合法合规的底线。在技术层面，控制幻觉有几个有效手段：强制要求模型引用上下文原文、设置拒绝回答的兜底话术、用温度参数（temperature）降低随机性，以及RAG里加置信度阈值——检索得分太低就回答“不知道”。

7. 主流大模型全景：国内外知名模型与选型建议

热搜词里“世界有哪些知名的大模型”，我一并给你梳理清楚。现在的大模型生态主要分两大阵营：闭源API模型和开源权重模型。

7.1 闭源API模型

这些模型不公开权重，只能通过厂商API调用，胜在能力强、省心，按量付费：

7.2 开源权重模型

开源模型可以自行部署、微调，是学习和私有化部署的主力：

选型建议就三条：中文优先Qwen；英文/全球场景优先Llama；预算敏感的API调用优先DeepSeek或豆包。多模态需求（图片、视频理解）优先闭源（Gemini、GPT-4o）或Qwen-VL这一类的开源视觉模型。

8. 常见问题速查：大模型入门避坑清单

最后把我这些年实操中被问过最多的问题整理成一张速查表，方便你随时翻。

再补几个容易忽略的细节：API密钥不要硬编码在前端，一定走后端代理转发；SSE长连接要设置合理的超时和重连机制；本地模型虽然免费，但长期运行的电费和硬件损耗也要算进成本，对比一下按量付费API，很多时候直接用API更划算。

结尾：我自己的一点体会

说实话，“大模型的系统性入门”这件事，最大的敌人不是硬件的门槛，也不是资料的稀缺，而是碎片化带来的焦虑感。今天刷到一个知识点觉得懂了，明天看到新词又觉得自己落伍了，时间就在这种“既懂又不完全懂”的状态里耗掉了。

我自己的经验是：不要追求“每天学新东西”，而是盯住一条最小闭环反复把它跑精。你先把一个模型在本地跑起来，然后接API、做界面、加流式；再把数据整理成微调格式，跑一次LoRA训练；最后加上RAG和一个Agent框架。这条链路全部走完，你的能力已经覆盖了大模型落地80%的工程环节，剩下遇到任何新词、新框架，都只是在已有能力树上添枝叶。

最后分享一个小技巧：开始学习前，给自己建一个“实验记录本”，每次改了什么参数、什么数据，效果是好是坏，都记下来。大模型工程最大的特点就是玄学参数多、环境差异大，你的实验记录就是最宝贵的私人手册，比任何教程都靠谱。希望这篇长文能帮你缩短从“知道”到“做到”的距离，剩下的路，动手往前走就对了。