企业官网建设流程全解析

这两年我经常被朋友问到：AI大模型这么火，我也想学，但该从哪里下手？每次我都会反问一句：你知道大模型为什么能回答你的问题吗？很多人会愣住，然后给我一个回答——“因为它训练过很多数据。”这个回答没错，但离“基础”还差得远。我见过不少追着热点跑的人，今天学提示词，明天看微调，后天折腾本地部署，折腾了几个月还是说不清transformer、上下文窗口、量化这些词之间的关系。问题不在于热点太多，而在于知识基础太薄。所以这篇文章我打算把“大模型知识基础”这件事掰开揉碎讲清楚，说说这个领域到底在学什么，为什么基础比追新更重要，以及我实操下来觉得最靠谱的补基础路线。

1. 先想清楚：大模型这个领域到底在学什么

很多人学大模型容易犯一个毛病：把“会用API”当成“懂大模型”。这就像开过几天车就觉得自己是汽车工程师，结果引擎盖一开，全是问号。大模型不是一款软件，而是一整套技术栈，从用户提问到模型吐字，中间隔着数据处理、模型训练、推理部署、应用封装好几个层次。不同的人在不同的层次上工作，需要的知识结构完全不同。

1.1 从“会聊天”到“会干活”：大模型分四个层面

我习惯把大模型的知识体系分成四个层面，方便刚入门的人对照定位。

第一个层面是应用层。这个层面做的事情是“调用现成的模型来解决问题”，比如用提示词让模型写文案、做翻译、整理资料，或者通过API把模型能力接进自己的产品里。这个层面不需要搞清楚模型内部怎么运行，但需要搞清楚怎么提问、怎么设置参数、怎么处理返回结果。

第二个层面是模型行为层。这个层面的人已经开始留意“模型为什么有时候胡说八道”“温度调高一点会怎么样”“上下文窗口满了怎么办”这类问题。你需要理解模型的输入输出机制、概率生成逻辑、局限性，甚至要会一点提示词工程和上下文工程。这个层面是绝大多数做应用的人需要长期待的地方。

第三个层面是训练与微调层。这个层面要做的是“让模型适应特定领域”，比如用公司内部的文档微调一个客服模型，或者用几千条数据做指令微调。你需要知道数据集长什么样、训练参数怎么设、过拟合怎么办、评估指标怎么看。

第四个层面是原理与研发层。这个层面涉及transformer架构、注意力机制、分布式训练、模型并行、量化推理等底层内容。这个层面不是人人都需要，但它会反过来帮你理解前三个层面里出现的各种现象。

我见过的人里，绝大多数都被卡在“想直接从应用跳到原理”这一步。这其实没必要。知识基础的作用不是让你一夜之间变成算法工程师，而是让你在任何一个层面都能站稳脚跟，往上走的时候脚下不踩空。

1.2 为什么知识基础比追热点更值钱

大模型领域的热点更新速度非常快。我自己关注过的关键词就有“提示词工程”“RAG”“Agent”“微调实战”“本地部署”“多模态大模型”“vLLM部署”等等。每过几个月就有新概念冒出来，看着很热闹，但如果你没有基础知识，这些热点对你来说就是一堆漂浮的碎片。

打个比方，热点是树叶，基础是树根。树叶每年换一批，树根却一直在土里吸收养分。你今天追“上下文工程”，明天追“Agent框架”，后天追“微调技术”，如果说不清预训练和微调的区别，不知道token是什么，不理解为什么显存不够，那你追再多热点也只是在背名词。真正出问题的时候——比如模型输出不稳定、部署环境报错、微调效果不理想——你连排查的入手点都找不到。

知识基础还决定了一个人能走多远。我见过很多人用提示词技巧把模型调得很听话，可一旦需要换模型、换场景，之前攒的“咒语”就失效了。原因很简单：他只记住了“怎么做”，没理解“为什么这么做”。而理解“为什么”靠的就是基础概念：模型是怎么训练的、上下文窗口怎么影响记忆、参数怎么改变生成风格。

所以我一直觉得，与其每天刷十篇“大模型最新进展”的文章，不如花半个月把“模型是什么、怎么来的、怎么跑起来、怎么改”这条主线捋一遍。磨刀不误砍柴工，这句话在大模型领域比在哪个领域都适用。

2. 绕不开的地基：大模型核心知识地图

如果让我给“大模型知识基础”画一张地图，核心节点不会太多。你别看外面炒作的概念满天飞，真正的地基其实就是几块：模型架构、训练方式、推理机制、工程化部署。把这几块搞明白，后面学什么都快。

2.1 Token、Transformer和注意力机制：从根上理解模型

很多人第一次接触大模型时会问：“为什么模型能写出通顺的句子？”这个问题如果追到根上，答案其实很朴素：大模型在做“下一个词预测”。你在对话框里输入“今天天气”，模型在内部把它拆成一小段一小段的token，然后根据前面这些token去预测下一个最可能的token，再把预测出来的token拼回去。它写几百个字，本质上是一遍一遍地重复这个“预测下一个词”的动作。

这里第一个基础概念就是token。token不是字，也不是单词，它是模型处理文本的最小单位。中文里一个标点可能是一个token，一个常见词可能是一个token，一个生僻字可能被拆成多个token。这个概念重要在对上下文窗口的估算：你告诉模型“可以处理128k上下文”，不是指128k个字，而是128k个token。

第二个基础概念是Transformer。今天的chat大模型几乎都是基于Transformer架构做的，这个架构里最核心的机制是自注意力。自注意力解决什么问题？它让模型在处理某个词的时候，能够同时“看到”同一段文本里的其他词，并自动判断谁跟谁关系更近。比如“小明把书放在桌上，然后他走了”，模型需要知道“他”指代的是小明，而不是书。自注意力机制就是用来捕捉这种长距离依赖关系的。

我知道很多人看到“注意力机制”就头疼，其实不用怕。你只需要建立一个粗浅的理解：模型在处理每个词时，会给同一个序列里的其他词分配不同的“注意力权重”，权重越高，说明这个词对当前词的影响越大。这个机制也是后来很多模型优化工作的基础，比如各种稀疏注意力、线性注意力，都是在“怎么让注意力更高效”上做文章。

2.2 预训练、微调、推理：三件事必须分清

“大模型”这个词本身特别容易让人误解，因为它既指那个训练好的模型文件，也指整个训练和使用的过程。我建议把三件事分开，否则很多讨论会越聊越乱。

第一件事是预训练。这是“烧钱”的阶段，用海量文本数据训练一个基座模型，让模型学会语言规律和世界知识。这个阶段需要几千张GPU、训练几个月，普通人不碰。但在知识基础上你需要理解一个点：预训练的目标就是“最大化地预测下一个token”，模型从这个目标里学到的是一种概率化的知识，而不是像人一样对世界有真正的理解。

第二件事是微调。微调是在预训练模型的基础上，用更小、更高质量的数据集继续训练，让模型学会特定风格或特定领域的任务。比如一个法律大模型，可能在通用模型基础上用法律文书做了继续训练。微调不是从零开始，它更像是让一个已经读过很多书的聪明人去读行业案例，然后学会在这个行业里说话办事。这个阶段的成本比预训练低很多，也是很多人实际接触的切入点。

第三件事是推理。模型训练完之后，真正“回答问题”的过程叫推理。推理也是有大讲究的：同样的模型，提示词不同，结果天差地别；同样的提示词，参数不同，结果也不一样。像温度（temperature，控制随机性）、top_p（控制候选词范围）、最大生成长度、上下文窗口大小，这些参数直接影响输出质量。我见过很多新手，连模型为什么总是重复一句话都搞不明白，其实多半就是温度设太低、top_p设太小导致的。

把这三件事分开之后，你会发现很多热点问题的讨论一下就清晰了。比如“微调好还是RAG好”这个问题，本质上是在问“你要改模型的参数，还是要在模型生成时额外给参考资料”。不懂底层机制的人，很容易被这种选择题绕晕。

2.3 提示词工程、上下文工程、RAG、Agent：一次理清关系

这几年“提示词工程”“上下文工程”“RAG”“Agent”这四个词频繁出现在热搜里，很多新手被搞得很焦虑，以为每出个新词就要学一套新知识。其实它们的核心都在回答同一个古老的问题：怎么让模型更好地完成实际任务？

先看提示词工程。这是最底层、成本最低的手段：通过优化输入给模型的指令，引导模型输出想要的结果。比如你想让模型帮你总结会议纪要，直接问“帮我总结一下”效果可能很泛，改成“请提取发言人的结论、待办事项和风险点，用列表输出”之后，结果会规范很多。提示词工程的门槛低，但它解决不了所有问题，因为模型的知识是训练时候定的，提示词无法注入新知识。

再看上下文工程。这个概念比提示词工程更进一层，强调的不仅是“怎么写指令”，还包括“怎么组织给模型看的所有内容”。因为你发出去的每段对话、每个附件、每条历史消息，都会占用上下文窗口。有人在长对话里发现模型“忘了”最开始的要求，往往不是模型记忆差，而是上下文窗口里的内容被大量新信息冲淡了。上下文工程要解决的就是怎么在有限的窗口里，把最重要的信息放在合适的位置、用合适的格式表达。

接下来是RAG，检索增强生成。它解决的问题很实际：模型不懂你私有的文档，微调又太重，怎么办？那就查出来给它看。RAG的基本流程是：先把你的文档切块、做向量化存起来，用户提问时先从库里检索最相关的几段文本，再把“问题+检索出来的文本”一起灌给模型，让模型基于这些材料回答。虽然RAG在工程实现上要考虑切块大小、向量模型、召回策略、重排等问题，但它的核心思想不复杂：在生成之前给模型补知识。

最后是Agent，智能体。Agent不是单个技术，而是一种应用架构：让模型作为“大脑”，通过理解任务、拆解计划、调用外部工具（搜索、代码、数据库等）来完成更复杂的目标。它比单次问答多了一个“循环决策”的机制，所以你会看到现在很多Agent框架都在处理“记忆”“规划”“工具调用”这些模块。

把这四个词放在一条线上看，就清楚多了：提示词工程是管“怎么说话”，上下文工程是管“怎么安排记忆”，RAG是管“怎么补外挂知识”，Agent是管“怎么用工具干活”。它们不是互相替代的进阶关系，而是从简单到复杂的应用手段。如果你有这个框架，就不会被新概念带着跑了。

2.4 部署和硬件常识：本地部署最容易被劝退的地方

“本地部署大模型”这几年特别火，天天有人在社区里晒“我用个人电脑跑起了大模型”。但很多人一照做就翻车，因为缺的不是兴趣，是硬件常识。

首先要理解一个残酷的现实：模型文件有多大，推理就得有多少显存。一个7B参数的模型，如果用FP16精度加载，光模型权重就需要约14GB显存；13B模型约26GB；70B模型约140GB。这还只是把参数放进去，没算推理过程中的KV Cache等额外开销。所以有人说“我用CPU跑大模型”，不是不行，但速度会慢到怀疑人生。

为了解决“显存不够”的问题，就有了量化。简单说，量化就是把模型里的浮点数参数从16位压缩到8位、4位，以牺牲一点精度为代价换来更小的显存占用。4bit量化的7B模型可能只需要5GB左右显存，很多消费级显卡能跑动。量化的概念不复杂，但你必须知道：量化后模型尺寸变了，输出质量可能会有细微变化，而且有些算子对量化格式支持不好，会报错。

部署还涉及推理框架的选择。现在主流的推理框架有vLLM、nano-vLLM等，它们各自在吞吐、显存管理、兼容性上做了优化。vLLM的PagedAttention能减少显存浪费，所以同样是7B模型，换了推理框架之后并发能力会提升很多。这类框架虽然属于工程层面的知识，在我看来也是入门必修的基础——因为你不亲手部署一次模型，就永远体会不到“模型结构和推理框架是两回事”这句话什么意思。

还有一个经常被Windows用户踩到的点：TCC和WDDM。在Windows下配置NVIDIA显卡驱动时，会有这两种模式。WDDM是把GPU同时用于显示和计算，适合日常办公加偶尔跑模型；TCC则把GPU完全交给计算任务使用，显存管理更高效，适合有独立显卡专门跑计算的机器。如果你总是遇到“程序启动成功后黑屏”或者“显存明明够却无法分配”这类诡异问题，可以去查一下显卡模式。这种小常识虽然在书里找不到，但它就是典型的“知识基础”。

3. 从零开始补基础：一份能落地的学习路线

每次有人问我“大模型怎么学”，我都推荐一套很朴实的学习路线：先补底子，再会用，再拆开看，最后动手改。这条路没有捷径，但也不需要你变成数学博士，只要按顺序走，大多数人两三个月就能把基础盘得很扎实。

3.1 先别急着学框架，把数学和代码底子补齐

很多新手会被“基础”两个字吓到，以为要把线性代数、概率论、微积分全部学完才能碰大模型。其实不用。你只需要补跟模型直接相关的两小块。

第一块是线性代数。不需要会证明定理，但你需要知道矩阵是什么、向量乘法怎么回事、为什么参数可以看作一个巨大的矩阵。因为大模型里的“参数”本质上就是一堆数值，模型处理输入做的运算，大部分可以被理解为矩阵乘法和非线性激活。当你看到“模型参数量7B”时，能想象出那是70亿个数字组成的矩阵，就够了。

第二块是概率统计。大模型生成文本的底层是概率分布：模型会为每个可能的token算出一个概率，然后按概率采样。理解了条件概率，你就能理解为什么同一个提示词会得到不同答案，为什么温度参数能影响随机性，为什么模型有时候“一本正经地胡说八道”。

代码方面至少要会Python。不一定非要成为Python高手，但得能看懂别人的推理脚本，能改参数量、换模型路径、处理数据格式。我经常建议新手先跑一个最简单的加载模型的Python脚本，哪怕只是“加载模型后生成一句话”，这个经验比读十篇原理文章都有用。因为你会亲眼看到“模型怎么被加载”，这个环节比任何解释都直观。

3.2 用起来：先会调用，再会部署

基础知识的检验标准不是“能不能说出概念”，而是“能不能让模型跑起来”。我建议按下面这个顺序来。

第一步，先通过API调用一个商用大模型，或者在一个网页对话平台上玩熟。这一阶段不需要写代码，主要目的是感受模型的强项和弱点。你要刻意测几个场景：让模型总结长文本、让模型推理数学题、让模型处理中文俗语、连续对话二十轮看它会不会忘记前文。把这些现象记录下来，后面学概念时你会突然“啊，原来就是这个原因”。

第二步，用Python代码调API。写一个最简脚本，把文本发给模型，再接收返回结果。这个练习会让你明白“输入”和“输出”到底是什么格式，以及temperature、max_tokens这些参数怎么影响输出。你可以试着把temperature调到接近0，看输出是不是变得稳定，再调到1.5，看输出是不是开始发散。这种对比实验，比背参数表有用得多。

第三步，本地部署一个开源小模型。你可以去下载量化后的7B模型，用vLLM或nano-vLLM这类框架跑起来。之所以建议本地部署，是因为你能更直接地看到模型推理的全过程：从加载权重到构建KV cache，再到流式输出。这一步会遇到无数坑，比如显存不足、依赖库版本冲突、模型路径写错，但每个坑都能逼着你多了解一点底层原理。

3.3 微调实战：从最小的例子开始

别一上来就去微调一个庞大的模型。我见过很多人拿着几百条数据就想微调7B模型，结果显存爆了、Loss不降、效果还不如提示词调优，心态直接崩了。

我的建议是先用一个非常小的模型来练习，比如参数量在1B以内的开源模型。你可以在它的基础上做一个极简的文本分类任务，或者一个“让模型学会特定回复格式”的指令微调。这一步的核心目的不是追求效果，而是把数据格式、训练脚本、损失曲线、评估流程全部跑通。

数据格式是最容易卡人的地方。指令微调的数据通常要整理成“instruction、input、output”这样的结构，稍有不慎就会出现序列长度不匹配、tokenizer截断、标签错位之类的问题。我第一次做微调时，就是因为有一条数据里input为空字符串，而大部分样本里input都有内容，导致数据整理函数报错，排查了一个多小时才找到原因。这种事情只有亲手做一遍才会长记性。

微调跑起来之后，也别急着开心。你要对比微调前后的模型输出，看看真的变了吗，变好还是变坏。如果微调后模型在通用能力上明显下降，这说明过拟合了；如果训练集上表现好、验证集上表现差，这说明泛化能力不行。能读懂这些现象背后的含义，你的基础就算真过关了。

4. 一个实操记录：我如何用两周补齐大模型知识短板

我不想只讲理论，也分享一段我自己的实操经历。有段时间我需要给团队做一次大模型应用方案，发现自己很多基础概念讲不透，于是定了一个两周的“补课计划”。后来这个计划被我总结成一套流程，谁想补知识基础都可以参考。

4.1 先做能力盘点，把目标拆成小任务

第一周开始前，我花了半天时间做能力盘点，把所有觉得“知道但讲不清”的概念写出来：token、上下文窗口、注意力、预训练、微调、量化、KV cache、RAG、Agent。每个概念旁边标一个自评分数，1分是完全不懂，5分是能给别人讲明白。这一盘点让我很尴尬，好多东西都只在3分左右。

然后我把大目标拆成小任务。两周时间不可能把原理吃透，所以我只定了三个任务：第一，能不看资料解释Transformer的基本流程；第二，能用代码完成一次本地模型加载和推理；第三，能用微调框架跑通一次最小规模的指令微调。这三个任务分别对应“理解”“部署”“修改”三个环节，既有知识输入，也有动手输出。

事实证明，先明确“这个阶段不需要学什么”也很重要。我主动放弃了深入推导注意力公式、学习分布式训练框架这些看起来诱人但暂时用不上的内容。守住边界，才保证了两周内能推进得下去。

4.2 我筛选资料的原则：官方文档优先，论文看摘要，代码要跑通

现在网上的大模型资料太多了，要是不会筛选，会越学越乱。我用了三条很笨但很有效的方法。

第一条，凡是概念解释，优先看官方文档和技术博客里带图的那类，少看营销号总结贴。官方文档虽然有时候不够通俗，但它准确；二手转述可能有错误，尤其是中文互联网上的“翻译式解读”，经常把术语搞得似是而非。第二条，论文不追正文，先看摘要和结论。要理解一个模型的基本思路，摘要和图表通常就够了；真正需要精读正文的时候，反而是你已经对模型有初步了解之后。第三条，看到任何代码示例，都尽量复制下来跑一遍。代码跑不通，说明理解有遗漏；跑通了，你才敢说这个知识点真的“会了”。

我那一周还给自己定了个纪律：不收藏超过十篇的“学习资料”。因为收藏夹里的东西绝大多数永远不会再看。真正有价值的资料，应该是一边学一边做笔记，甚至转写成自己的话，这样才变成了你自己的知识基础。

4.3 踩过的坑：不是模型难，是工程细节折磨人

两周里我踩了不少坑，最典型的三个现在写出来，给正要补基础的人打个预防针。

第一个坑是显存估算错误。我一开始打算用一台16GB显存的消费级显卡跑一个13B模型。当时以为13B模型FP16也就需要26GB，量化成8bit后差不多13GB，够用。但真跑起来发现一部分显存被操作系统和桌面环境占用了，可用显存只剩12GB左右，模型刚加载进去就报OOM。后来我换成了7B模型加4bit量化，显存占用瞬间降到6GB以下。这个教训让我意识到：看显存占用不能只看“模型权重大小”，还得看环境开销和推理框架的额外占用。

第二个坑是上下文被截断。我在做长文本总结时，塞了一段几万字的资料给模型，结果模型只总结了开头几百字。后来查日志发现，我计算的上下文长度时把token数估计少了，输入已经超过了模型的上下文窗口上限，后面的内容被直接截断。从此我学到一个习惯：调用模型或构建数据时，要先算token数，别拿字数去衡量。

第三个坑是微调数据tokenizer不统一。当时我找了一个开源的微调脚本，默认使用模型自带的tokenizer，但我手工构造的数据里有些字段没走tokenizer预处理。训练过程没有报错，可生成的文本里出现了很多奇怪的换行符。这是最磨人的一类问题，不报错但效果差。从那以后，我坚持在训练前用一小批数据跑一次推理，直接看一眼tokenize后的输出，很多数据格式问题一眼就暴露了。

这些坑本身都不难，但如果没有基础知识，你甚至不知道报错信息里的“OOM”代表什么，也不知道context window怎么调。正因为之前花时间补了基础，我才能在踩坑后快速定位问题。

5. 常见问题速查：新手最容易被卡住的几个问题

最后整理几个我经常被问到的入门问题，这些问题看起来很小，不解决却很影响学习节奏。

5.1 要不要先学机器学习？

看你的目标。如果你只想做应用层面的事，比如写提示词、调API、做RAG流程、用Agent框架，那你不一定非得学完机器学习课程。但几个基础概念要补：什么是分类、什么是回归、什么是过拟合、什么是训练集和测试集。因为微调和评估模型时会反复用到这些词，不懂的话连别人的经验帖都看不懂。

如果想往算法方向走，那就老老实实补机器学习基础。建议按经典教材的前几章看，特别是线性模型、决策树、神经网络基础这几个部分，能帮你建立“模型是什么”的整体感觉。顺序上，先有一些机器学习概念，再学大模型原理，会比直接啃Transformer论文轻松很多。

5.2 提示词工程和上下文工程有什么区别？

这是一个特别好的问题，因为它能检验一个人是不是真懂模型机制。

提示词工程的面更窄一些，关注的是“怎么写出更好的指令”。你给它一个角色设定、要求它使用某种格式、规定它必须从某几个角度回答，这是在优化“话语”。

上下文工程的面更宽一些，关注的是“你在上下文窗口里给模型喂了什么、以什么顺序喂”。它不只包括你的指令，还包括背景资料、对话历史、检索到的RAG结果，甚至包括这些内容的先后顺序和格式标记。因为模型无法记住上下文窗口之外的内容，所以你“怎么安排它能看到的东西”本身就是一种工程能力。

所以我自己的理解是：提示词工程是上下文工程里最核心的一环，但上下文工程还要处理更多内外部信息的组织和调度。

5.3 本地部署到底需要什么配置？

这个问题没有标准答案，但我可以给一个参考下限：如果你只想跑7B模型并且用4bit量化，显存8GB的显卡有机会跑起来；如果要顺畅地跑13B模型，建议至少16GB显存；想跑70B级别模型，基本就要考虑多卡或者高显存工作站了。这还不考虑CPU、内存和推理框架的选择。

另一个因素是速度。显存够用只是前提，每秒能生成多少token也是关键。我自己在低端配置上跑过模型，生成速度慢到像老式打字机，这种体验对学习影响很大。所以我不建议完全零预算硬蹭本地部署，有条件就组一台显存大于16GB的机器，体验会好很多。

如果你还没有任何硬件，又想学部署，可以先在云服务器上租GPU跑几次。按小时付费，跑通一次流程就关掉，成本比冲动买卡低得多。我见过很多人买了一堆显卡，结果发现根本没时间折腾，这就没必要了。

5.4 API派和开源派怎么选？

这不是一个谁优谁劣的问题，而是两条目的不同的路线。

API派的核心价值是效率。你用别人已经部署好的模型，把精力集中在产品逻辑、提示词优化、业务数据整合上。如果你的目标是做应用、做产品，那API是刚需，你不必关心部署细节。但缺点也很明显：数据要发给第三方，隐私合规上有风险；模型能力受限于提供商；一旦涉及敏感场景，可能连用都不能用。

开源派的核心价值是灵活和可控。你可以把模型下载到本地，数据不出内网，也可以针对业务场景做微调、换推理框架、改采样参数。缺点是必须自己负责环境、硬件、性能优化，学习成本高不少。

绝大多数人的现实选择是两条腿走路：刚入门时用API熟悉模型行为，等有了明确需求，再基于开源模型做本地部署和微调。这条路把成本和性价比平衡得比较好，也是我自己验证过的路径。

补基础这件事确实不酷，它没有“三天学会大模型”那种刺激感，但它给你的是持续迭代的底子。我以前也喜欢收藏各种新概念、新框架，后来发现收藏夹里吃灰的东西，远不如亲手把一个Demo跑起来的那十分钟有价值。如果你现在正被大模型的各种名词绕得头晕，别急着背新词，先回到那几个最老、最基础、看起来最不性感的概念上。把Transformer、token、预训练、微调、推理、上下文窗口这些词变成你真正用得上的工具，你会发现自己突然能看懂几乎所有大模型相关的文章了。