企业官网建设流程全解析

很多人学大模型，第一步就是收藏几十个“学习路线图”，然后去下载一个几十GB的模型包，再然后就没有然后了。我接触过不少被“大模型”这三个字吸引进来的朋友，大家卡住的点惊人一致——不是不想学，而是不知道该先学什么、学到什么程度、学完能干嘛。今天这篇内容，就是想给打算系统性入门大模型的人一份真正能照着走的地图：把“学什么、按什么顺序学、每个阶段怎么验证自己学会了”这三件事一次说清楚。我不打算堆术语，也不会让你背公式，因为大模型入门阶段最需要的不是深度，而是建立正确的知识框架和动手节奏。

1. 入门最大的坑不是数学，而是目标模糊：先给自己定三条路线之一

1.1 大模型知识其实分三条主线，没人能同时迈大步

很多新手把“学大模型”当成一个单一任务，这是第一个误区。实际上，大模型领域的知识可以拆成三条相对独立的主线，每条主线的技能树、学习资料、最终产出完全不同。

• 算法原理线：关注模型内部怎么工作，包括Tokenization、Transformer架构、注意力机制、预训练目标、RLHF对齐、模型评估。走这条线的人，目标是成为算法研究员或模型训练工程师。
• 工程实践线：关注模型怎么跑起来、跑得快、跑得稳，包括推理加速、显存优化、量化、分布式部署、服务化封装。走这条线的人，目标是成为推理引擎开发或平台运维工程师。
• 应用范式线：关注怎么把模型用出价值，包括提示词设计、上下文工程、RAG（检索增强生成）、Agent（智能体）、微调策略、应用评测。走这条线的人，通常是产品经理、全栈开发或AI应用工程师。

这三条线不是互斥的，但入门阶段你必须选一条为主。我见过最典型的失败案例，是一个人同时啃Transformer源码、又学vLLM源码、还研究Agent框架，结果每样都看了个开头就放弃。原因很简单：每条线的学习曲线都很陡峭，同时开三条线，你的认知负荷和挫败感会成倍叠加。

1.2 用三个问题判断你最适合哪条主线

我不主张根据“哪个方向工资高”来选，而更建议你先回答三个问题：

1. 你过去最擅长且最有成就感的工作，是分析问题本质，还是解决具体故障，还是把东西组合起来做出产品？
2. 你手头有没有一个真实场景，比如公司的知识库想要AI化、某个流程想用自动化替代、某类数据分析想用模型提效？
3. 你能投入的连续学习时间，是每周固定十几小时，还是只有碎片时间？

回答完你大概就清楚了。擅长逻辑分析、看论文不头疼的人，选算法原理线；喜欢折腾环境、对性能数字敏感的人，选工程实践线；有业务场景、想快速看到产出的人，选应用范式线。三种选择没有高下之分，但投入产出比差别巨大——我见过很多“硬啃原理”的开发者，最后发现自己的兴趣其实在应用落地，白白绕了三个月弯路。

1.3 理论、代码、实践必须三条腿同步走

无论你选哪条主线，有一个总体原则是通用的：理论、代码、实践要同步推进，不要先攒三个月的理论再动手。比如你今天学到“量化可以把FP16权重变成4-bit整数”，当天就应该去找一个小模型实际跑一次量化；今天学到“注意力机制”，当天就该去读一份最小实现了的注意力代码。

原因是，大模型的知识链条特别长，任何一个概念如果只是“看懂了”而不“用过了”，两周后一定忘光。而且很多概念在看代码时会推翻你的理解，比如你以为batch size只是“一次处理多少条”，等你看到训练时显存突然爆掉，才会真正理解batch size背后是激活值的存储问题。这种“用出来的理解”是看再多文章都替代不了的。

2. 从原理上回答新手最常问的三个问题：Token、注意力、预训练到底在干嘛

2.1 Token与向量化：模型眼里根本没有“文字”

新手最容易困惑的点，就是“模型到底怎么理解自然语言的”。真相是：模型完全不理解文字，它只处理数字。你输入的任何一句话，会先被切分成一个个子词单元，这些子词单元就是Token。比如“大模型”可能被切成“大”“模型”两个Token，也可能被切成一个完整Token，取决于分词器的规则。

每个Token会通过一个查表操作映射成一个高维向量，这个向量叫做Embedding。一开始这些向量是随机初始化的，但在预训练过程中不断被调整，最终向量之间的距离和方向开始携带语义信息——意思相近的词，向量距离更近；某些词对之间的向量差值方向，可能代表着某种语义关系。

这个原理能直接解释两个非常常见的现象。第一，为什么模型有“上下文窗口”限制？因为每次输入都要切Token、转成向量、再进入注意力计算，Token越多，计算量和内存消耗越大，所以Token数量有上限。第二，为什么Token切分影响成本？很多商业API按Token计费，“我喜欢你”这种表达需要多个Token，而一个英文单词往往一个Token就搞定，所以中英文输入的单价差距很大。

2.2 注意力机制：读书做笔记的比喻和它的现实意义

Attention是Transformer的核心，也是大模型区别于旧式循环神经网络的关键。要理解它，可以用一个“读书做笔记”的类比：当你在阅读一段文字时，看到某个关键词，你会不自觉地回看前面提到的相关概念，把注意力集中到那些相关的位置上。Self-Attention做的事情就是这个，不过是让句子里的每一个词，都跟句子里的其他所有词算一次“关联度”，然后根据关联度加权汇总信息。

这个机制有两个直接后果。第一，它是全局的——不管两个词隔多远，只要语义相关，模型都能建立联系，这解决了老式RNN“长距离信息丢失”的问题。第二，它是O(n²)复杂度的——句子长度翻倍，计算量变成四倍，这就是为什么模型处理长文档时又慢又费显存，也是KV Cache、FlashAttention这些优化技术存在的最根本原因。

一个常见误解是“注意力机制让模型有逻辑推理能力”。实际上注意力只负责“关注”，不负责“推理”。真正让大模型表现出推理能力的，是它在预训练阶段见过的海量文本模式，以及后面要说的RLHF对齐。理解了这一点，你就不会对模型产生不切实际的期待——它本质上还是一个做模式匹配和概率预测的系统，只是匹配的模式足够复杂。

2.3 从预训练到RLHF：ChatGPT“听话”是怎么来的

大模型的能力不是一次训练出来的，而是分阶段“塑造”出来的。第一个阶段叫预训练，模型被丢进海量互联网文本里，任务是预测下一个Token是什么。这个阶段模型学会了语言结构、事实知识、常识推理——但它只是一个“接龙选手”，你问它问题，它只会顺着你的话往下续写。

第二个阶段叫监督微调（SFT），人类标注员写出大量“问题—理想回答”的配对样本，让模型学习“回答问题”的格式和风格。做完这一步，模型才像一个能对话的助手，但仍然可能说出冒犯性内容或不按你的指令执行。

第三个阶段叫RLHF（基于人类反馈的强化学习），模型先输出多个回答，人类对回答排序打分，再用这个偏好信号训练一个奖励模型，最后通过强化学习让模型学会追求高分回答。这一步是“价值观对齐”的关键，也是为什么模型普遍很“讲礼貌”、很“懂事”的原因。

这个分阶段理解特别重要。很多人天真地以为“微调一个模型就能让它变聪明”，实际上大多数微调只是在做第二阶段类似的事情——教模型特定的行为模式，而不是注入新知识。如果你想让模型知道某个私有知识库里的内容，靠微调是很低效的，正确做法是接下来要讲的RAG。

2.4 为什么原理知识能直接指导你的工程决策

我见过不少工程师，觉得“我是做应用的，原理不用懂”，然后在这条路上反复撞墙。最典型的一个例子，是不明白Token和上下文窗口的人，会把整本PDF直接塞给模型做问答，结果一道题都答不对。因为上下文窗口被无关内容占满，关键信息反而没放进去。

再比如，不理解KV Cache的人，会左调右调模型的max_tokens和并发数，却始终搞不明白推理速度为什么上不去。理解了KV Cache，你就知道回答长度和显存占用之间的关系，自然能解释为什么长对话越来越慢。

所以原理学习的目标不是让你去复现GPT，而是让你在使用模型时能建立起一个准确的“心智模型”——模型哪里强、哪里弱、为什么会失败、怎么针对性地补偿它的短板。这个心智模型，才是系统学习大模型最核心的资产。

3. 提示词工程和上下文工程：先学会跟模型高效协作，再谈其他

3.1 提示词不是“咒语”，而是接口设计

很多人把提示词工程当成“玄学咒语”，觉得某句话加上“请”字模型就变礼貌，加上“一步步思考”模型就变聪明。这些说法都有一定道理，但容易让人误入歧途。我更愿意把提示词理解成你跟模型之间的接口设计——一份高质量的提示词，本质上是一条清晰的、有约束的、带示例的需求文档。

一份结构化的提示词通常包含五个要素：

• 角色设定：告诉模型它应该以什么身份工作，相当于给它一个岗位说明书。
• 任务描述：明确它要完成什么，尽量用“输出”“分析”“判断”这类动作词，而不是模糊的“看看”。
• 约束条件：长度限制、格式要求、禁止事项，这能大幅减少无效输出。
• 示例：给一个或几个输入输出样例，往往比描述一百句“应该怎么做”都有效。
• 输出格式：要求模型按Markdown表格、JSON结构或列表输出，便于后续程序化处理。

这五个要素不是每次都全用，但当你发现模型输出不符合预期时，优先检查这五个维度，而不是去“念咒语”。

3.2 上下文工程：比“一句话指令”更大的舞台

提示词工程解决的是“一句话怎么组织”，而上下文工程解决的是“送进模型窗口里的所有内容怎么设计”。后者在真实项目中重要得多。

最典型的场景是RAG。你要让模型基于某份文档回答，需要把文档切块、向量化、存储，然后根据用户问题检索最相关的几个块，再把它们组合进上下文一起发给模型。这个流程里的上下文设计，直接决定了回答质量。

上下文工程里还有两个容易被忽略的细节。第一个是内容顺序：模型对上下文不同位置的“注意力”是不均匀的，往往是开头和结尾记得更清楚，中间容易被忽略，所以关键指令放在系统提示词里，关键信息尽量放在上下文的两端。第二个是上下文压缩：当对话变长，不可能把所有历史都塞进窗口，要么让模型做总结摘要，要么直接丢弃不重要的轮次。这些策略的好坏，会比“提示词写得好不好”更显著地影响应用效果。

3.3 一个提示词从能用变好用的完整演化示例

我拿一个真实场景演示：给模型布置“合同风险审查”任务。

第一版提示词可能是这样：

帮我看看这个合同有什么问题。

这个版本能让模型输出一些泛泛而谈的内容，比如“注意违约责任条款”“注意付款方式”，但没有实际价值，因为所有合同都适用这些话。

第二版加上角色和输出格式：

你是一名资深合同法务顾问。请审查这份租赁合同，指出其中的风险点。输出格式：按条款编号列出风险，注明风险等级（高/中/低），同时给出修改建议。

这一版明显更好，模型会按条款逐条分析，风险等级让后续处理变得可排序。但还有一个问题：它不知道你的“风险偏好”。有些条款在标准商业合同里是常态，但在你公司的风控标准里不可接受。

第三版加上约束和示例：

你是一名资深合同法务顾问，服务对象是一家初创公司，风险偏好偏向保守。请审查这份租赁合同，指出风险点。输出格式：按条款编号列出风险，注明风险等级、原因和修改建议。示例： 条款3.2：租金每年上浮10%，风险等级：高；原因：上浮比例高于市场平均水平，且未设上限；建议：改为上浮比例不高于5%或与CPI挂钩。

这样改完之后，模型的输出稳定性和贴合度会大幅提升。整个过程并不神秘，就是把自己代入“项目负责人给外包团队派活”的场景，把需求说透，把标准讲清楚，把例子给够。这就是提示词工程的全部秘密。

4. 微调：绝大部分场景根本不需要，需要时你该知道这几件事

4.1 先判断该不该微调：RAG、提示词和微调的分工

现在市面上的“大模型微调培训”铺天盖地，但我要先泼一盆冷水：绝大多数业务场景根本不需要微调。原因很简单，微调解决的是“改变模型行为模式”的问题，而不是“补充新知识”的问题。

• 想让模型了解你公司的私有文档？用RAG。文档放在外部检索库里，随取随用，不用改模型本身。
• 想让模型从一种风格变成另一种风格？先试提示词。比如让它写“周报”风格，一个角色设定就能解决。
• 想让模型稳定按你的格式输出？先做结构化提示词和输出约束，大多数开源模型都能胜任。

那什么情况下才需要微调？答案是：当你已经试过提示词、RAG、调参都不行，且问题出在“行为层”时。比如你要模型用特定文风写小说，这种风格无法通过几段描述固化；或者你有一批标注好的问卷数据，需要模型学会一套固定的判断规则，且判断标准比较复杂，提示词表达不清。这两种情况，微调才真正有价值。

4.2 全参、LoRA、QLoRA：三种路线怎么选

如果你确认需要微调，接下来面对的就是技术选型。目前主流的方案有三种，我用一张表说清楚差异：

对于初学者，我通常直接建议从QLoRA入手。它把基座模型的权重先量化成4-bit，训练时只更新一小部分注入的低秩矩阵参数，显存占用能降到适合个人电脑的水平。比如微调一个7B量级的开源模型，全参数微调可能需要40GB以上的显存，QLoRA则可能只需要12-16GB左右。

选择基座模型也有讲究。中文场景我优先推荐国产开源模型家族，比如阿里的千问系列，社区活跃度高、中文语料训练充分、周边工具链齐全。其他开源社区的大模型如Llama系列也很优秀，但中文支持需要额外适配。总原则是：选一个你社区里资料最多、踩坑分享最充分的模型，而不是选一个Benchmark分数最高的模型。

4.3 用QLoRA跑通一次微调的最短路径

我整理了最少步骤的参考流程，你在本地实践时可以直接套用：

1. 准备数据。格式一般是JSON，每条包含instruction（指令）、input（可选输入）、output（期望输出）。这里是简化示例：

[ { "instruction": "判断用户评论的情感倾向", "input": "到货很快，但包装破损了，客服处理也不及时。", "output": "负面" }, { "instruction": "判断用户评论的情感倾向", "input": "价格实惠，物流也快，五星好评。", "output": "正面" } ]

数据质量永远比数据量重要。我见过有人喂了两万条抓来的低质量数据，结果模型学会了重复句式和网络口水话；我也见过只用八百条精心标注的数据，就把一个小型分类任务做到业务可用的团队。

2. 选择微调框架。开源社区常用的有LLaMA Factory这类工具，它把数据加载、训练、导出封装成相对简单的配置流程，对新手友好得多。

3. 配置训练参数。重点关注这几个：LoRA的秩（一般从8、16、32开始试）、学习率（常见范围1e-4到5e-5）、训练轮数（epoch，数据量小时不宜太大，否则容易过拟合）、上下文长度（根据数据最长样本设定，不是越大越好，越大越费显存）。

4. 训练并观察。loss曲线是一个参考指标，但更重要的指标是“验证集上的真实表现”。你需要在训练前从数据里留出一部分不参与训练，用来测试微调后的模型效果。

5. 导出与合并。LoRA训练得到的是一个小补丁文件，使用时要跟基座模型合并或者动态加载。合并后建议做一轮回归测试，确认模型原有的一般对话能力没有被严重破坏。

4.4 微调翻车高发区：数据质量、过拟合与灾难性遗忘

微调最常见的三个坑，我一个个说。第一个是数据噪声。模型会忠实地学习你喂给它的全部模式，包括错误的、低质量的、前后矛盾的。所以数据清洗不是可选动作，是微调前必须做的一步。你需要去重、修正错别字、剔除偏激内容、统一格式。

第二个是过拟合。微调数据集通常不大，模型很容易把训练样本“背下来”，却无法泛化到新输入。表现就是训练集上的任务效果“完美”，一换新样本就崩。避免方法是：数据集要覆盖足够多的衍生变体，训练轮数不要贪多，也可以用早停法（验证集指标不再上升就停止）。

第三个是灾难性遗忘。模型在学习新任务时有可能会把原有的通用能力抹掉，表现为：原来会写代码，微调后只会写合同了；原来能正常对话，微调后只会机械地按格式输出。解决思路通常是：数据集中掺入一部分通用语料，或者在微调时选择更低的学习率——这也是LoRA类方法受欢迎的原因之一，因为更新的参数少，对原有知识的破坏也更小。

5. 本地部署不是“下载完就结束”，显存、量化、推理框架才是真相

5.1 一个公式说清楚显存需求

本地部署是新手最容易“下载即失败”的环节，因为大家对显存需求完全没有概念。其实有一个估算公式：

模型权重显存约等于 参数量 × 每个参数占用的字节数。

FP16精度下，每个参数占2字节，所以一个7B参数量的模型，仅权重就需要约14GB显存。FP32翻倍到28GB，4-bit量化则压缩到约4GB左右。但这还只是权重，推理过程中还要算上KV Cache和激活值，实际占用往往是权重的一倍以上。所以7B模型要在消费级显卡上舒服地跑，几乎必须用4-bit量化。

这个公式能帮你避免大量无效操作。很多人拿到一个13B的模型就往8GB显存的笔记本上硬塞，然后抱怨“为什么这么慢”，其实第一步就已经注定失败了。选模型之前先算账，永远优先于选模型。

5.2 量化：把模型塞进普通显卡的关键操作

量化的本质，是把原来用2字节表示的权重，压缩成1字节甚至4比特表示，以牺牲少量精度换取显存和速度的大幅改善。常见的量化格式有GPTQ、GGUF、AWQ等，各有侧重。GGUF格式对CPU推理场景更友好，也是Ollama等工具默认使用的格式。

量化级别也有学问。比如GGUF有Q2_K、Q4_K_M、Q5_K_M、Q8_0等档次，不同档次的压缩比和效果损失不一样。根据我的实践经验，Q4_K_M是个甜点位：显存占用可控，效果损失在多数场景下几乎感知不到；再往下降到Q2，模型会明显“变笨”，能感觉到回答质量滑坡。

实操中另一个常见误区是“量化后效果一定变差”。实际上，对于7B以上的模型，4-bit量化带来的困惑度损失通常很小，但换来的显存节省非常可观。反过来，某些跑不动的模型你硬跑，因为OOM反复重启，体验反而更差。所以对入门者，我的建议是：先量化，能跑起来再说。

5.3 推理框架：从Ollama到vLLM的选择逻辑

本地部署的软件选择，很多人会纠结“用哪个框架好”。其实关键是想清楚你的需求。

• 如果你想快速在个人电脑上跑起来，体验一下模型效果，Ollama是最好的选择。它把模型下载、量化、启动封装得非常简单，几乎不需要写代码。
• 如果要做高并发的服务化部署，比如给公司内部做一个AI问答服务，那就要上vLLM这类推理引擎。vLLM的两个核心优化值得了解一下：PagedAttention把KV Cache按页管理，大幅减少了显存碎片；Continuous Batching允许不同请求在同一个批次里动态进出，显著提升了吞吐量。
• 如果是Windows环境，建议优先考虑用WSL2跑Linux环境，很多推理框架对Linux的支持比Windows原生好得多，可以省掉大量折腾时间。

不要一开始就纠结“Ollama不够高级”这件事。先用最简单的方式把模型跑通，理解整个链路，再根据瓶颈去换更复杂的框架，这个顺序不会错。

5.4 本地部署的三个高频翻车现场

第一个翻车现场是“模型下载好了，但一直用CPU跑”。很多工具默认不会自动启用GPU，需要手动配置。如果发现回答速度慢得离谱，先去任务管理器看GPU占用率，而不是怀疑模型太大。

第二个翻车现场是上下文长度没调。本地部署时，默认的max_tokens（最大生成长度）往往很低，你会发现模型说一半就停了。这不是模型笨，是生成长度的上限被设死了。

第三个翻车现场是并发问题。有些框架默认单请求模式，两个用户同时访问就会排队卡死。如果你要上线一个给同事们用的服务，一定要确认部署框架的并发配置，或者在应用层做好请求排队。

这三个问题都不是技术难题，但几乎每个人都会踩到。我的建议是，踩到坑时不要急着改东改西，先把部署日志打开，一步步看错误信息，80%的问题都能通过日志定位。

6. RAG、Agent、多模态：基础之后的三条进阶方向怎么选

6.1 RAG：让模型学会“查资料”再回答

等你掌握了API调用、提示词和本地部署，下一步最值得投入的方向是RAG。它的核心逻辑非常简单：大模型的知识截止到训练时刻，也不可能装下你公司的全部私有文档，那就在用户提问时，先从外部检索出相关内容，拼进上下文再回答。

一个完整的RAG系统包含几个环节：文档加载、文本切块、向量化、向量检索、重排、组装提示词、生成回答。入门者最常见的误区，是把所有精力放在“向量化”和“向量库”上，觉得这是RAG的灵魂。但实际上，文本切块策略和重排环节往往对最终效果影响更大。

切块太大会导致检索命中不精准，切块太小又会丢失上下文关联。重排则是把检索到的Top 50个片段重新排序，挑出最相关的Top 5喂给模型——这一步能显著抑制幻觉。我的建议是，先用LangChain或LlamaIndex这类框架把全流程跑通，再分别替换每个环节看效果差异，通过对比实验来加深理解，这比从头手写一个RAG系统要高效得多。

6.2 Agent：从“问答机器”到“干活助手”

如果说RAG让模型能“查资料”，Agent则让模型能“动手干活”。Agent的核心思路是：把大模型当作处理问题的“大脑”，让它可以调用外部工具（比如搜索引擎、计算器、代码执行环境、数据库），把一个复杂任务拆解成多个步骤，并且循环迭代直到完成。

目前主流的Agent框架有几个方向：有的偏重对话流程编排，有的偏重复杂的图状工作流，有的偏重多智能体协作。对于入门者，我建议先不要沉迷框架的选择，而是先理解Agent的三个核心机制：任务规划（把目标拆成子步骤）、工具调用（决定每一步用哪个工具、传什么参数）、结果确认（判断当前结果是否足够好，决定继续还是停止）。

一个非常容易踩的坑是，很多新手直接照着框架的示例代码做一个“超级Agent”，结果发现它反复调用错误工具、陷入死循环、成本飙升。Agent的工程化远比Demo困难，因为真实世界的任务边界模糊，工具的返回结果不可控。入门时先从“带一个工具的聊天助手”开始，比如让模型学会调用一个天气查询API，再逐步增加工具数量，这是最平滑的路径。

6.3 多模态：从文本模型到感知世界

第三条进阶方向是多模态大模型。多模态模型不再只处理文字，还能理解图像、音频、视频。实现思路并不神秘，核心是把不同模态的数据都映射到同一个表示空间里，再让模型学习它们之间的对齐关系。

对应用开发者来说，多模态带来的直接能力是：图片问答、截图理解、文档OCR+分析、语音交互等。我最常用到的场景是把多模态模型接到工单系统里，用户直接截图描述问题，模型自动识别界面元素并给出排查建议，这比让用户打字描述问题高效得多。

入门多模态，不需要重新学一遍深度学习。你完全可以先通过API调用来熟悉多模态模型的输入输出习惯，比如给它一张图片和一句提问，看它怎么组合视觉与文本信息。之后再考虑本地部署开源多模态模型。

6.4 三条路线的推荐顺序

我的个人建议是：先RAG，再Agent，多模态作为按需补充。原因是RAG的门槛最低、技术成熟度最高、业务价值最直接，而且它能帮你深入理解“上下文工程”这个核心技能。Agent的难度要高一个台阶，因为它引入了不确定性、工具生态和错误恢复这些工程问题，建议在你对提示词和上下文把控比较熟练之后再进行。多模态则取决于你手头有没有真实的多模态数据需求，没有的话可以先缓一缓。

7. 一份可执行的学习时间表与资料筛选原则

7.1 16周节奏参考表

学习这件事，最怕的不是慢，而是没有截止点和验证标准。我整理了一份16周的可执行节奏表，你可以在自己身上做适应性调整：

这个节奏表的关键不是时间本身，而是每个阶段的自检项。如果你一个阶段卡住了，不要急着往下赶，因为后面的内容大概率会建在前面未打牢的地基上。

7.2 资料筛选的三条原则

最后聊聊资料选择。现在“大模型学习资料”泛滥，付费课、免费文档、开源项目应有尽有，反而让人无从下手。我自己筛选资料有三条原则：

第一条，优先看官方文档和官方示例，而不是二手解读。开源模型的官方GitHub仓库、官方API文档、官方技术博客，是最权威的信息源。二手文章可以作为入门引导，但遇到细节问题，一定要回到官方文档确认。

第二条，不迷恋“热门视频课”，多动手跑开源项目。视频能帮你快速建立整体印象，但看完就忘。真正沉淀下来的是你亲手跑过的项目、修过的bug、调通的服务。

第三条，建立自己的实验笔记。每学一个概念，就做一个最小实验去验证它。比如学了temperature参数，就去API里实际调不同温度对比输出差异；学了上下文窗口，就故意塞入超长文本观察模型怎么“失忆”。这些实验笔记会逐渐积累成你自己的大模型直觉，这比任何别人的“经验总结”都有用。

最后再分享一个我自己的体会：大模型入门这件事，最难的不是某个技术点，而是“持续动手”的习惯。资料可以随时刷，但如果你每周都能留出一段完整的时间，真刀真枪地跑一遍模型、调一次接口、修一个部署报错，三个月后你对大模型的理解会超过很多“看过几百篇文章”的人。系统学习的本质，不是把资料收集齐，而是把知识在手里过一遍。你不需要一次学完所有内容，只需要确保今天学的东西，今天用了一下——这已经比绝大多数人做得更好了。