企业官网建设流程全解析

先说个实在话：大模型这个东西，热了大半年，“系统性入门资料”这种标题我见过不下几十次。点进去十有八九是网盘链接、课程广告、或者一堆论文列表。真正缺的不是资料，是“先做什么、再做什么、哪些能跳过”的判断力。

这篇文章想干的事很简单，把一条经过实测的入门路径完整摆出来：理论要学到什么程度、硬件要什么配置、本地部署怎么跑通、微调什么时候才需要、提示词和Agent到底是怎么回事。提到的大模型学习路线、本地部署、微调实战、提示词工程这些关键词，后面都会逐一落到可操作的具体步骤上，不是泛泛而谈。

适合谁看？想转岗做应用层开发的、刚入学的学生、以及只想把开源模型部署到个人电脑上玩一玩的人。不需要你推过公式，不需要你有A100集群，甚至不需要你先读完Transformer论文。跟着文章走，第一天就能把对话跑起来，后面再慢慢补理论。

1. 入门先别急着跑代码，先把三个核心认知建起来

很多人一上来就问“微调用什么框架”“LoRA的rank设多少”，这种问题问早了。在跑代码之前，有三件事如果没想清楚，后面每一步都会踩坑。哪三件？模型到底是什么、你是谁、你要去哪。

1.1 大模型的本质是一个概率补全器

大模型看起来能回答问题、能写代码、能总结文档，但本质上它做的一件事极其简单：根据已有的文本，预测下一个Token（可以粗略理解为一个词或半个词）。你输入“今天天气”，它预测“很好”的概率高，于是输出“很好”。整个对话逻辑、上下文记忆、甚至“思考过程”，全是这种逐Token预测堆出来的结果。

这个认知为什么重要？因为它决定了你对模型的基本态度。模型不是数据库，它不会“查”正确答案，它是“猜”一个合理答案。所以它天然会编造内容，这就是大家常说的幻觉。理解了这一点，你就不会在“为什么模型会答错”这种问题上纠结太久，而是会去想“我该怎么把答案引导到对的方向上”。

这也就引出了后面贯穿全程的两个核心手段：提示词工程和上下文工程。模型是死的，但输入你来定，同一个模型，给的输入不一样，输出质量天差地别。这玩意儿不是玄学，有方法论，后面专门讲。

1.2 “你是哪种工程师”决定了学习路线

大模型这条产业链上，主流岗位大概分两类。

一类是算法/模型方向，主要工作是训练模型、改进架构、研究新的对齐方法、做模型压缩。这类人需要扎实的数学底子、深度学习基础、分布式训练经验，Transformer论文得精读，进阶还得啃LLM相关的技术报告。

另一类是应用/工程方向，主要工作是调用模型、部署模型、写Agent、搭RAG、做微调、做评测。这个方向不需要从头训练模型，也不需要你能改进Attention架构，但你得懂模型怎么跑、怎么调、怎么限流、怎么控成本、怎么保证输出稳定。

绝大多数入门者，我建议走第二条路。原因很简单：第一条路门槛高、周期长、岗位数量少；第二条路边学边用，涨经验快，而且市场上需求量明显更大。更直白地说，哪怕以后想转算法方向，应用层的工程经验也不是白积累的——你对模型的脾气了解得越透，反过来做训练和调优的sense也会更好。

1.3 硬件没那么可怕，先算清楚这笔账

“本地部署大模型”是热搜词，但很多人被显卡劝退。这里给一个很实用的认知：8GB显存能玩3B以下模型，16GB能玩7B量化模型，24GB能比较舒服地跑7B和14B量化模型，48GB以上才谈得上跑34B级别。

怎么算的？很简单。7B模型就是70亿参数，以FP16半精度存储，每个参数占2字节，理论显存就是140亿字节，约13GB。加上推理过程中需要的KV Cache、中间激活值，实际峰值通常再预留30%~50%，所以24GB卡跑7B很从容，16GB也能通过量化勉强跑。

量化是什么概念？就是把模型权重从FP16压缩到INT8或INT4，就像把一张RAW照片压成JPG。INT8下7B模型大约只要7GB，INT4更少。代价是精度有轻微损失，但多数对话场景几乎感知不到。

硬件选型我后面在部署章节还会给具体建议。这里只强调一件事：如果手头只有CPU和16GB内存，也能跑，用llama.cpp跑3B模型完全可行，速度慢但能玩。不要因为硬件就把入门这件事搁置了。

2. 理论基础：Transformer不用啃完，但三块内容绕不开

理论这块很多人走极端，要么完全不看直接跑代码，要么抱着论文死磕三天。实际经验是：跑通一个对话模型之后再回来看理论，效率翻倍。往下这三块知识，算是理解大模型的“最小必要集”。

2.1 自注意力机制：模型怎么“看懂”一句话

Transformer最核心的东西，是以自注意力机制为根基。想理解它，不用看公式，先建立一个直觉：模型在处理每个词时，会给句子里的所有其他词分配一个“注意力权重”。比如处理“小明因为迟到被老师批评了，他很沮丧”这句，“他”这个词会重点关注“小明”，而不是“老师”或“批评”，因为上下文里“他”最可能指代小明。

自注意力让模型能够捕捉词与词之间的依赖关系，哪怕它们隔得很远。这也是RNN时代做不到的：RNN处理长句子时，靠的是逐个词传递状态，前面的信息经过多步传递后容易衰减，而注意力让模型能“跳过去”直接关注远处的关键词。这也是大模型上下文窗口能做大的基础原因之一。

这一块不用看得太深，看懂“Q、K、V是三种向量，Q问‘该关注谁’，K说‘我有什么信息’，V说‘我的内容是什么’”就够用了。后面跑推理框架时，你会在KV Cache这个词上再次遇到它们。

2.2 Token、上下文窗口和参数：沟通的基本单位

• Token：模型处理文本的基本单位，不是字，也不是词，而是子词。比如“人工智能”可能被拆成“人工”“智能”两个Token，中文里平均一个字大概对应1~1.5个Token。这个数字很重要，因为它直接决定了API成本——各家大模型API都是按Token计价的。
• 上下文窗口：模型单次能“看到”的Token数量上限，常见的有8K、32K、128K等。超出这个长度，要么截断，要么做摘要压缩。上下文窗口不是越大越好，越大显存开销越高，推理越慢。
• 参数：模型的权重，是训练阶段学出来的“知识仓库”。参数越多，模型理论上表达能力越强，但对应资源消耗也越大。同一个参数量级的模型，训练数据质量好坏，实际效果会差出好几个档次。

这三个概念是“大模型八股文”里被问烂的内容，面试也好、日常交流也好，必须做到张口就来。理解它们，也能帮你解释很多工程问题：比如为什么长文本对话会越聊越贵？因为每次请求都要重新处理历史Token。

2.3 预训练、微调与对齐：模型的三段人生

一个模型从出生到能用，经历三个阶段：

预训练阶段，读海量文本，学到语言规律和世界常识。这个阶段成本极高，动辄几千张卡跑几个月，普通人接触不到。

微调阶段，用特定格式的数据教模型学会某种行为。比如用“用户问、助手答”的对话数据微调，模型就从“续写文本”变成“回答问题”。这个阶段有资源门槛，但个人开发者用LoRA也能做，后面详细讲。

对齐阶段，让模型学会“什么该说什么不该说”、符合人类偏好。RLHF（人类反馈强化学习）是最出名的方法，底层逻辑是让模型在多个回答中选择人类更喜欢的那个。对大多数应用开发者，知道原理和存在即可，不需要会做。

重要性排序：预训练常识 > 微调行为 > 对齐价值观。你向开源模型提问时感觉“它很聪明”，大部分来自预训练；感觉“它很听话”，来自后两个阶段。理解这条线，看到“用GPT-4生成数据微调开源模型”这类操作就不会觉得奇怪——本质上是在用一个更强的模型当老师，教一个学生模型学会行为规范。

3. 本地部署实操：从下载模型到能对话的完整过程

前面说了那么多认知，到这里开始动真格。本地部署大模型是入门的第一个里程碑，跑通了，后面所有的事情都有了下手点。这一章所有操作都是基于一台单人单卡机器，不用分布式，不用K8s。

3.1 模型选型：第一台车买便宜的，别直接上旗舰

部署第一步是选模型。建议遵循一个原则：先用小参数模型跑通全流程，再试更大的。

以开源模型为例，Qwen系列和Llama系列是生态最成熟的两个。具体下来：

• 1.5B~3B级别：任何有8GB显存的卡甚至纯CPU都能跑。用来理解流程，熟悉API，足够。
• 7B~14B级别：入门最甜点位。24GB显卡可跑满血FP16，16GB卡可跑量化版本。对话质量已经能用，文档总结、代码生成都能干。
• 32B以上：要48GB以上的大显存，或者多卡。效果确实好，但部署复杂度上了一个台阶，不适合头一次部署。

很多人第一次就想着跑32B，结果环境搭了三天，最后因为显存不够放弃。我见过太多这种案例。老老实实选一个7B或14B模型，把流程走通，比什么都强。哪怕你最终要部署大模型服务，也建议先在7B上练手，因为推理框架的坑和模型大小无关，而七成框架问题在7B上就能暴露出来。

3.2 推理框架选型：为什么大家都在聊vLLM

模型下载好之后，怎么把它跑起来？有几种主流选择，各有用武之地。

原生Transformers库推理，代码最简单，适合调试和理解原理，但速度慢、显存占用高，达不到生产标准。

llama.cpp，主打CPU和Apple Silicon推理，量化支持极好，个人电脑轻量部署首选，单文件方便。

vLLM，当前最热门的生产级推理框架。它的核心优势是两项技术：PagedAttention和Continuous Batching。PagedAttention解决显存碎片问题，让显存利用率大幅提升；Continuous Batching允许同时处理多个请求，而不是等一个请求结束再处理下一个。懂一点操作系统的人听到“Paging”就会心一笑：这是把虚拟内存的分页换页机制搬到了GPU显存管理上。正是这两个设计，让vLLM的吞吐量可以做到原生Transformers的好几倍。

还有nano-vLLM之类面向教学和轻量硬件的变体，适合想看明白推理全流程的人。我的建议是：跑通阶段用Transformers，生产型部署直接上vLLM。

部署vLLM的过程，用一台24GB显卡的机器举例，大致是这样：

# 1. 创建虚拟环境，避免污染系统环境 conda create -n vllm python=3.10 -y conda activate vllm # 2. 安装vLLM，带CUDA的版本 pip install vllm # 3. 启动OpenAI兼容的API服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192

参数说明：--tensor-parallel-size 1表示单卡不切分；--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存，预留一点给其他操作，别设1.0，容易OOM；--max-model-len控制上下文上限，8K已经够日常使用。

启动成功后，服务默认跑在8000端口。这时候拿curl测一下，确认服务可用：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [{"role": "user", "content": "用一句话解释什么是大模型"}] }'

能返回一段正常回答，恭喜，你的本地大模型已经上线了。这一步完成之后再去看任何模型架构文档，你都会觉得那些名词变得具体了，因为KVCache、显存利用、请求调度这些东西，你在部署时已经亲手和它们打过照面。

需要注意的是，用OpenAI API的格式启动本地模型有个隐藏福利：你写的调用代码，未来可以直接改个base_url就切到任何一家云厂商的API服务。接口格式统一，迁移成本约等于零。这也意味着你之前为“本地模型”写的所有调用逻辑，放在商用模型上一样成立。

3.3 量化：显存不够时的救命稻草和它的代价

如果显卡没那么好，比如只有16GB，直接跑7B的FP16权重会爆显存。量化就是这时候上的。

量化本质上是降低模型权重的存储精度。一个7B模型，FP16需要约13GB，INT8大约7GB，INT4大约4GB。代价是精度损失，但具体损失多少，取决于量化的方式。

主流量化方式分两条路线：

• 在线量化（GPTQ、AWQ）：加载前先把权重从16位压到8位或4位。这类模型适合GPU推理，配合vLLM、Transformers使用。AWQ在某些场景下精度保持比GPTQ好一点，但两者的差距远没有吹得那么大，选哪个都行。
• 离线量化（GGUF）：主要配合llama.cpp使用。GGUF不只是量化，还打包了模型结构和分词器，把整个模型封装成一个文件，方便管理和分发。这也是Apple Silicon机器和CPU跑模型的最佳选择。

从实操经验看，能用INT8就别用INT4。很多中文任务，INT4的7B模型已经能感觉到明显的“笨”，而INT8的损失几乎可以忽略。显存实在紧张时，甚至可以考虑把模型降到3B级别，而不是硬上INT4的7B——效果未必差。

4. 微调实战：先搞清楚什么时候根本不需要微调

大模型微调是热搜词，也是被神话得最严重的一个概念。很多初学者把微调当成“让模型更好用”的万能钥匙。实际上，多数场景根本不需要微调。

4.1 这些情况先别微调，省下大量时间金钱

先对其他手段进行排查，一个都不行再考虑微调。

• 模型回复格式不对？用提示词工程解决。在system prompt里写清格式要求，或者给一个few-shot示例，大多数模型立刻变得“守规矩”。
• 模型不了解你的业务数据？上RAG（检索增强生成），把知识库内容切段、向量化、存到向量数据库，提问时先检索相关资料，再喂给模型加工答案。这比微调快、省，而且知识可实时更新。
• 模型的通用能力不行？换更大的模型，或者换更强的模型。7B干不了的事，14B可能能干；开源模型不擅长中文写作，可能换一个擅长中文的模型就解决了。

微调真正的用武之地是什么？一是学习特定行为模式，比如“用固定格式输出病例报告”；二是使模型适配特定领域表达习惯，比如法律文书、代码风格；三是在基座模型推理能力不足的前提下，通过示范数据把模型“教”向特定任务。总之，不是让模型“变聪明”，而是让模型“懂规矩”。

4.2 LoRA微调：显存不够也能玩的低秩适应法

传统全参数微调，7B模型也要几十GB显存起步，个人玩不起。LoRA的出现改变了局面。

LoRA的核心思想很巧妙：冻结原来的模型权重，不动它；在每一层网络旁边额外添加一组小矩阵，只训练这组小矩阵。这组小矩阵的参数量只有原模型的千分之一甚至更少，但因为它插在原模型的线性层旁边，能以“加法”的方式影响原模型的输出，相当于用极低的成本调整整个模型的行为。

类比一下：原模型是一个已经练好内功的人，LoRA是在这个人的手臂上加了一副可调节的护臂，只调整护臂来改变出拳方式，不需要重新练一遍内功。最后的结果是：显存需求从几十GB降到10GB多，7B模型用LoRA微调，一张24GB显卡完全够用。

实用层面，LoRA微调全家桶以PEFT库为主。我用一个通用流程演示一下。先准备训练数据，对话微调通常用JSON格式：

[ { "messages": [ {"role": "system", "content": "你是某公司智能客服，回答简短专业。"}, {"role": "user", "content": "退货退款流程是什么？"}, {"role": "assistant", "content": "您好，退货需要先在订单页申请，审核通过后寄回商品，我们会在签收后3个工作日内退款。"} ] } ]

数据格式最好是messages这种多轮对话结构，因为真实场景里用户和模型交互往往是多轮的，而不仅仅是单轮问答。如果只有单轮问答数据，你可以自己加一个空system或者固定system来统一格式，但训练出来的模型在长上下文对话中的表现会差一些。

接着用transformers结合peft训练，这里给关键片段：

from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") lora_config = LoraConfig( r=8, # 低秩矩阵的秩，越大适配能力越强，但也越容易过拟合 lora_alpha=32, # 缩放系数，控制LoRA层影响的强度 target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() # 参数量通常只有原始模型的1%左右

训练参数的经验值：r从8起步，不要一上来就64；学习率常见范围是2e-4到5e-4；batch_size按显存来，24GB卡跑7B模型，1~4都行，用梯度累积补足；max_seq_len不要强行拉太高，训练数据里多长就设多长，128到2048之间最常见。训练数据的数量更值得注意，质量比数量重要得多：500条高质量数据的效果经常秒杀5000条胡乱爬来的低质量数据。

4.3 微调完了怎么评估：Loss降了不代表模型能用了

这是新手最容易栽的坑。训练过程中loss一直在降，就以为模型学好了。实际上loss下降只能说明模型对训练数据的拟合程度在提高，不代表它对真实问题的回答质量变好了。

靠谱的做法是留出一部分评测集，训练完后在评测集上看实际回答。比如你是做客服场景的，微调前准备50个真实客户问题，微调后逐个问一遍，人工看回答质量；看格式是否符合要求、是否使用了业务黑话、是否胡编乱造。这种“用例回归”比任何训练指标都实在。

另外一个实操中常遇到的问题是“微调后模型变笨了”，表现为通用能力下降。这往往是学习率过高、训练轮数过多导致灾难性遗忘。解决方案：loRA的alpha不要拉太高，训练轮数控制在2~3个epoch以内，同时混合一些通用数据。如果发现变笨，优先降低学习率重训，而不是加大数据。

微调产出的LoRA权重是一组适配器文件。使用时要先加载基座模型，再加载adapter，不能直接拿adapter当独立模型跑：

from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") model = PeftModel.from_pretrained(base_model, "./lora-output-ckpt")

这里有个极易踩的坑：训练时的基座模型版本和推理时的基座模型版本必须完全一致。如果基座是Qwen2.5-7B-Instruct，推理时不要换成Qwen2.5-7B（不带Instruct），两者的词表和对话头不同，加载LoRA会直接报错或产生乱码输出。

5. Agent、RAG与生态：入门工程师真正干活的地方

聊完部署和微调，你已经能跑一个大模型并微调它的行为了。但在实际项目中，模型只是发动机，真正把发动机装进车里的，是Agent和RAG这套外挂系统。

5.1 主流Agent框架：从LangChain到轻量化方案

Agent的核心机制是让模型能够“调用工具”。什么意思？给模型定义一组函数，模型根据用户请求判断该调用哪个函数，拿到函数结果后再组织回答。比如用户问“北京今天气温多少”，模型不直接回答，而是先调用一个天气查询函数，拿到数据后再说。

这个“先决定调用什么工具，拿到结果再生成回答”的循环，就是Agent的基本工作形态。实现这一能力的底层依赖叫Function Calling，几乎所有主流模型都支持。

目前主流的Agent框架分几派：

• LangChain生态：最老牌、最全面，但抽象层多，学习曲线陡，很多封装对新手并不友好。用它写Agent，你会发现大半时间在Debug框架本身的魔法操作。
• 轻量方案：直接调用模型API的Function Calling能力，自己管理循环逻辑。代码量不大，但可控性极强，出了问题一查到底。
• 工作流平台：Dify、FastGPT这类开源平台，主打拖拽式工作流编排，把Agent、RAG、工具调用都可视化。对初学者特别友好，是把概念落地的捷径。

我给入门者的建议很直接：先用工作流平台把“Agent = 多轮推理 + 工具调用”跑明白，再用代码手写一个极简Agent循环，理解内部机制，最后再去看LangChain之类的框架。顺序反了的话，框架的抽象层会把你绕晕。

5.2 RAG和知识抽取：让模型用上你的私有数据

RAG这几年从热门概念变成了工程标配，因为它精准解决了两个痛点：模型知识有截止日期，以及模型会胡编乱造。RAG的思路是把大模型当成一个阅读理解引擎，而不是知识库：先根据用户问题去你的知识库里检索相关内容，再把检索到的内容连同问题一起交给模型，让模型基于这些材料作答。

整体流程可以拆成四步：

1. 文档解析与知识抽取：把PDF、Word、网页转成纯文本，按语义切分成块。这一步的质量直接影响检索效果，光“切块”就有很多讲究：按固定长度切容易把语义切碎，按标题结构切又依赖文档本身格式规范。很多项目会引入专门的知识抽取框架来做结构化清洗，把表格、段落、层级关系都整理好再向量化。
2. 文本向量化：用Embedding模型把文本块转成向量，存进向量数据库。
3. 相似度检索：用户提问时，把问题也转成向量，在库里找最相似的N段文本。
4. 生成回答：检索结果和问题拼装成Prompt，交给大模型生成最终回答。

RAG对应用开发者的核心考验在于：Embedding模型选得合不合适、切块粒度合不合理、检索到的内容是否准确。大模型本身的参数量反而没那么关键——7B模型配合一个优秀的RAG管道，往往比裸奔的70B模型更可靠。

5.3 免费API与开放平台：低成本起步的正确姿势

本地部署有门槛，但现阶段还有另一条路可以走：直接申请各大厂商的开放API。很多云厂商提供免费额度，个人开发者用来学习和验证想法完全够用。这些平台接口大多兼容OpenAI格式，所以很推荐在初期直接用API把应用逻辑写起来，不要一开始就被本地部署的环境问题绊住精力。把应用跑通之后，再回来部署开源模型替代，会顺畅许多。

顺带提一嘴怎么写调用代码。用OpenAI的Python库是最省事的选择，指定base_url就能切换到任意兼容服务：

from openai import OpenAI client = OpenAI( base_url="http://你的服务地址/v1/", # 换成你本地vLLM或云端API的地址 api_key="sk-xxx" # 本地部署时任意填即可 ) resp = client.chat.completions.create( model="Qwen/Qwen2.5-7B-Instruct", messages=[{"role": "user", "content": "你好"}] ) print(resp.choices[0].message.content)

这个代码段推荐所有入门者收藏。只要你理解了这段代码，你就同时理解了大模型API调用中90%的套路。

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

到这里，该讲的硬知识都讲完了。最后把我在实际部署和微调过程中踩过的坑、帮别人排查过的问题整理成一张速查表。这些内容常规文档里很难一次性看到，建议直接收藏。

6.1 部署与推理阶段的典型问题

• 显存不足，OOM。优先检查模型权重精度和量化参数，FP16换INT8、INT8换INT4是最直接的；其次检查推理框架的显存利用率设置，vLLM的gpu-memory-utilization默认只设到0.9，如果同时跑别的程序还会更高；最后检查上下文窗口长度设置，max-model-len开得越大，KV Cache占显存越多，一个8K的涨到32K，显存占用往往翻好几倍。
• 模型加载特别慢。常见原因是CPU加载时模型太大，或者磁盘IO是瓶颈。如果机械硬盘在跑几十GB的模型，加载十几二十分钟正常。解决方式：换成SSD、加载时关闭其他吃IO的程序；实在不行优先用GGUF格式，它支持mmap内存映射，加载快得多。
• 推理速度太慢，每秒只有几个Token。先确认是不是量化过狠了，INT4在小模型上速度不一定比INT8快多少，但能力下降明显。再确认是否用了CPU推理：如果是，这个速度就正常，别指望能跑出GPU的效果。最后看看是不是框架没吃满GPU，vLLM在单请求场景下优势不大，大并发时才有明显优势。
• 请求返回乱码。多半是模型权重与分词器版本不匹配，比如Llama系模型用了别的库的解码逻辑。提醒一下：升级transformers版本后，老模型可能偶发不兼容，锁版本是一种妥善做法。

6.2 微调与数据阶段的典型问题

• 微调后回答全是空行或重复循环。这大概率是训练数据质量差，尤其是目标输出中有大量重复标点、换行、无意义字符。模型学到的是“输出模式”而不是“回答内容”。先清洗数据，再做训练。
• loss很低但通用能力几乎丧失。这就是前面说的灾难性遗忘。降低学习率，控制训练轮数，加一点通用语料混合训练。
• LoRA矩阵加载后模型回答没变化。先确认推理时是否确实加载了adapter路径，再确认target_modules是否与你推理模型的架构匹配。不同模型家族各层名称不一样，Llama是q_proj、k_proj这一套，但某些架构可能叫self_attn.q_proj，对不上就等于没训进去。
• 数据量太少，几百条行不行？行。但尽量做数据增强：改写、同义替换、补充多条system风格，把小数据集的分布扩得广一点。几百条高质量数据训练出的模型，在特定任务上已经能感受到明显差异。

6.3 提示词与上下文工程阶段的典型问题

• 模型经常不听话，不按格式输出。这里的核心秘诀是“给格式示例比给规则描述更有效”。你说“请用JSON输出”，不如直接在提示词里放一个JSON示例。模型本质是遵循模式的，示例比指令更接近它的训练分布。
• 上下文一长，模型就忘事。这是上下文窗口的物理限制，建一个摘要机制，早轮对话先压缩成摘要，再连同最近对话一起发给模型。如果用了Agent框架，还要注意工具返回的长文本会迅速消耗上下文空间，先做截断或者用结构化摘要再送进模型。
• 模型说出来的内容有幻觉。如果是知识时效性问题，上RAG；如果只是偶尔胡说，调低temperature，减少随机性；如果频繁胡说，先评估自己用的模型是不是太小了。7B以下模型本身可信度就有限。

6.4 绕不开的最后提醒

用模型处理用户输入时，永远记得：模型输出你无法完全控制，所以凡是涉及决策建议、数据分析、安全相关的内容，都要做输出侧校验，不能让模型的原始输出直接流向用户。这句话对个人项目影响不明显，一旦做成了生产系统，它可能是你最后悔没早一点知道的一条经验。

聊到这儿，这套内容其实已经把“系统性入门”该覆盖的骨架都拉出来了。我个人在实际操作中的体会是：入门大模型最快的路，不是把以上所有章节都学完再动手，而是先花一个晚上把7B模型部署起来，让它跟你对话；遇到问题，再回来查这篇文章对应的章节。先跑通，再补原理，效率远高于单向灌输。最后再分享一个小技巧：如果你的电脑性能有限，就从3B模型开始，一样能走通全流程，后面换大模型只是换个文件的事。这个领域迭代确实快，但底层逻辑这几年一直相对稳定，把上面这些基本功打扎实了，不管新框架怎么出，你都有能力在半天内接住。