企业官网建设流程全解析

简介：一份面向AI学习者与开发者的DeepSeek专题自学手册，共73页PDF，系统梳理V3与R1两大模型的起源、架构、性能对比与部署方法。手册从MoE专家混合、MLA注意力、多Token预测等底层设计讲起，逐步过渡到强化学习训练、模型蒸馏和13个官方示例，兼顾理论解释与动手实践，适合希望从入门到落地掌握DeepSeek的读者。资源为单个PDF文件，体积25.31MB，包含完整的目录、图表与代码片段，可离线阅读或配合本地部署操作。目前已有156人浏览学习，内容覆盖数学编程任务、中文问答、创意写作等场景，并给出在线与本地部署指南，尤其适合研究大模型架构的研究者、算法工程师以及准备将DeepSeek接入实际项目的技术团队。

1. 这份 DeepSeek 自学手册，到底值不值得从头读一遍

先给结论：如果你手里已经有一份「2025 DeepSeek自学手册：从理论到实践-73页.pdf」，它不是那种翻两页就吃灰的宣传册，而是一份把 DeepSeek V3 和 R1 从模型原理、训练路线，一路拆到提示词写法、部署方案的实操笔记。文档里最有价值的部分，不是架构图，而是第 4 章那 7 条提示词技巧——它直接告诉你哪些写法在 R1 上会失效，哪些写法能稳定拿到结构化结果。适合三类人：刚接触 DeepSeek、想搞懂 MoE 和推理模型区别的初学者；被 R1 的「玄学」输出折腾过的普通用户；以及准备把 DeepSeek 接入自己项目、需要明确边界和参数的开发者。

2. DeepSeek V3 的底子：MoE 架构、MLA 与 MTP 到底解决了什么问题

2.1 MoE 不是堆参数：专家路由与无损负载均衡

文档对 MoE（Mixture of Experts，混合专家模型）打了个比方：把模型想象成一个团队，每个专家各有专长，遇到问题不是全员上，而是根据问题类型挑合适的几个专家来解。这个比方基本准确，但要理解 V3 为什么强，得再往下看一层——MoE 真正解决的是「在不大幅增加计算量的前提下扩大参数量」。

传统密集模型（Dense Model）每个 token 都要激活全部参数，比如一个 70B 模型跑一次推理，所有 70B 参数都得参与计算。MoE 模型则不同，V3 的总参数量是 671B，但每个 token 只激活约 37B 参数。这意味着你可以拥有一个「看起来很大」的模型，实际推理成本却和一个中等模型差不多。文档里反复提到一个数据——V3 的训练成本约 600 万美元，这在同级别模型里是极低的，靠的就是 MoE 这种稀疏激活机制。

但 MoE 有个经典问题：负载不均衡。如果路由机制训练得不好，可能出现某些专家被反复调用、忙到过热，另一些专家长期闲置。V3 用了一个叫「无额外损耗的负载均衡」（Auxiliary-Loss-Free Load Balancing）的策略，简单说就是在训练过程中实时监测每个专家的工作量，动态调整路由偏好，避免「过劳」和「躺平」。文档里给的描述是「动态调整专家使用频率」，实际效果是训练更稳，不靠额外 loss 惩罚项来强行均衡，也就不会因为辅助损失干扰主任务的梯度。

这里要提醒一点：MoE 模型在推理时对显存的要求和密集模型不一样。你不需要把 671B 参数全部加载到显存，但需要足够空间容纳激活的专家参数和 KV Cache。文档后面讲本地部署时会涉及，先记着这个特性。

2.2 MLA 与 MTP：长文本场景下的两个关键设计

V3 架构里有三个关键词：MLA（Multi-Head Latent Attention，多头潜在注意力）、DeepSeekMoE、MTP（Multi-Token Prediction，多 Token 预测）。其中 MLA 和 MTP 是和推理效率直接相关的。

MLA 解决的是推理时的显存瓶颈。传统多头注意力在处理长文本时，每个 token 都要缓存完整的 Key 和 Value 向量，序列越长，KV Cache 占用越大，最终把显存吃满。MLA 的做法是把 Key 和 Value 压缩成一个低维潜在向量，推理时只需要缓存这个压缩后的向量，而不是原始的全量 K/V。文档的比喻是「精简笔记」，更准确的说法是「低秩压缩」。代价是注意力计算时需要先解压，但整体上显存占用大幅下降，长文本处理能力明显提升。

MTP 则是训练阶段的效率设计。传统语言模型一次预测一个 token，V3 的 MTP 模块让模型同时预测多个 token。文档的比喻是「预判下一步」，实际价值有两点：一是训练时每个样本能提供更多监督信号，数据利用效率提升；二是模型被迫学习更长期的依赖关系，生成时连贯性更好。需要明确的是，MTP 主要是训练期收益，推理时 V3 仍然是逐个 token 生成，只是生成质量受益于训练时的多 token 预测目标。

从实用角度看，这两个设计决定了两件事：V3 适合喂长文档做分析（比如整份 PDF、长代码文件），且部署时对显存的要求比同规模传统 Transformer 模型友好。上手 V3 时，不要一上来就追求「全量加载」，优先体验它的长上下文能力。

2.3 从预训练到强化学习：V3 的三阶段流水线

文档把 V3 的训练过程分成三个阶段：预训练（无监督学习）、精调（监督学习）、强化学习。重点在最后一步，文档明确写了 V3 用了基于 R1 生成的高质量推理数据来做强化学习，还提到 V2.5 生成数据、人工标注校验的细节。

这条路线值得注意：V3 是「通用模型」，但它的对齐过程用了推理模型（R1）产出的数据。这意味着 V3 在数学、代码、逻辑推理这类任务上的表现，实际上吸收了 R1 的推理能力——虽然它本身不是推理模型。理解了这一点，你就明白为什么文档在性能表里会特别强调 LiveCodeBench 榜首、MATH-500 达到开源模型最高水平这些数据。

在实际使用中，V3 和 R1 的分工应该是这样的：日常写作、翻译、角色扮演、通用问答，用 V3 更稳；数学证明、代码调试、复杂逻辑分析，R1 更强。文档第 6 章给了一个判断方法——如果任务涉及「多步推理」且「过程可以被验证」，优先选 R1；如果任务偏向「开放式生成」，V3 更合适。

性能方面文档给了一组基准数据：V3 在 MMLU（综合知识）、GPQA（博士级难题）上超过所有开源模型，接近 GPT-4o；在中文事实性问答 C-SimpleQA 上甚至超过 GPT-4o，英文略弱。这些数据来自 DeepSeek-V3 Technical Report，虽然不能完全代表真实用户体验，但至少能说明 V3 的通用能力不在第一梯队之下。

3. DeepSeek R1 的推理路线：从 R1-Zero 到多阶段训练

3.1 推理模型和非推理模型的本质区别

R1 的核心标签是「推理模型」（Reasoning Model）。文档里有个容易忽略的注释：推理模型（如 R1、OpenAI o3）会自己「画草稿纸分步骤思考」，生成的内容准确性和可解释性更高；非推理模型则按照预定指令直接生成内容，「你说啥它做啥」，可解释性较低。

这个区别直接决定了使用方法。对非推理模型，你需要把思考过程自己做完，在提示词里给出清晰指令；对推理模型，你可以只描述目标，它会内部展开推理链，然后再给出答案。这就是为什么文档会在第 4 章反复强调「R1 对提示词比较敏感，few-shot 会降低性能」——因为推理模型本来就不需要你教它怎么思考，给一两个示例反而可能把它带偏。

R1 的性能数据来自 DeepSeek-R1 技术报告：在 AIME 2024（美国数学邀请赛）、MATH-500、Codeforces 等任务上，与 OpenAI o1-1217 相媲美甚至超过；在 FRAMES（长上下文理解）上超过 V3；在 SimpleQA 事实基准上优于 V3。但也有一个反直觉的数据：在中文 SimpleQA 上，R1 不如 V3，原因是安全强化学习（Safety RL）倾向于拒绝回答某些查询，文档用了一个很形象的说法——R1 是「敏感肌」。

3.2 从 R1-Zero 到 R1：冷启动与多阶段强化学习

R1 的训练路线是文档里最值得读的部分之一，因为少见地公开了一条完整的强化学习训练路径。

第一步是 R1-Zero：在 V3 Base 模型上直接应用强化学习，跳过了监督微调（SFT）阶段。效果是模型「无师自通」涌现出推理能力，文档称之为「顿悟时刻」，但代价是输出的可读性差、语言混杂、内容不连贯。这一步的意义在于验证了「纯强化学习可以激发推理能力」这个假设。

第二步是 R1 正式版，团队用了两招解决 R1-Zero 的毛病：第一是冷启动数据，先给 V3 Base 模型喂几千条人工编写的高质量推理示例（比如详细的解题步骤），让它「开窍」；第二是多阶段训练，先用冷启动数据微调模型，再用强化学习进一步优化，最后结合写作、翻译等其他任务的数据再训练一遍，让模型「既聪明又会说人话」。

这个训练路线的启示是：R1 的推理能力来自强化学习，但可读性来自监督微调。如果你要在自己的场景里构建一个推理模型，不要在纯 RL 路线上死磕，冷启动 SFT 是工程上更稳的选择。

参数层面有一个关键点需要理解：R1 的强化学习阶段分为基于规则（Rule-Based）的奖励模型和基于模型（Model-Based）的奖励模型。数学题、编程题这类有确定答案的任务，用规则验证即可；开放式问答、创意写作这类无法用规则判断的任务，则用模型打分。文档里列了 V3 的训练数据配比：数学和编程文本比例提高、多语言覆盖范围扩展，这些细节对想复现类似训练流程的团队有直接参考价值。

3.3 模型蒸馏：把 671B 的推理能力压缩到小模型

蒸馏（Distillation）是 R1 章节里最有工程价值的主题。DeepSeek 团队选了约 800K 条 R1 生成的推理数据，对 Qwen 和 Llama 系列的小模型进行微调。文档给了一个让人意外的结果：蒸馏后的 7B 小模型在数学任务上可以「吊打」一些大模型，32B 版本甚至接近 GPT-4o / o1-mini。

蒸馏对做实际项目的人意义重大：你不需要跑 671B 的 R1 满血版，一个 7B 或 32B 的蒸馏版就可能在你的任务上表现够用，而部署成本和延迟会低一个数量级。文档特别提醒了一句话：「蒸馏版系列和满血版后面会遇到 671B 数据」——意思是小模型虽然在特定任务（数学、代码）上接近满血版，但通用能力、复杂推理的边界仍然有限，尤其是在处理长上下文和复杂多步任务时。

实际选型时，我的建议是遵循这样的路径：先在满血版 R1 上验证你的任务能达到什么效果，确认方向可行；然后尝试相应的蒸馏小模型；最后评估性能损失是否能接受。不要一上来就在小模型上反复调提示词，那是用错误的基础设施解决提示词问题。

4. 提示词的七个关键技巧：R1 上哪些写法有效，哪些会翻车

4.1 明确具体 vs. 模糊请求

文档第一条技巧看起来老生常谈，但在 R1 上特别明显：模糊提示词的效果很差，具体提示词的效果明显提升。对比一下文档里的例子：

• 模糊：「写一篇关于时间管理的文章。」
• 具体：「写一篇关于如何提高个人时间管理能力的文章，要求包含三个具体的方法，并详细解释每个方法的实施步骤。」

为什么对 R1 差别这么大？因为 R1 作为推理模型，遇到模糊任务时会自己脑补目标函数，而它补出来的目标不一定是你想要的。具体提示词相当于帮它缩小了搜索空间，让推理链朝你期望的方向走。注意这里的差别不是「字数多少」，而是「约束是否明确」——你给出了结构（三个方法）和粒度（详细解释实施步骤），R1 的推理过程就有边可依。

4.2 提供背景与规则：从裸需求到完整上下文

第二条技巧和第一条相关，但更进一步：不仅要具体，还要给背景和规则。文档给的例子是写一篇新型望远镜的产品文案：

• 无背景：「帮写一篇新型望远镜的文章。」
• 有背景：「用英文帮我写一篇产品发布文案。这个产品是一款配备 AI 系统的新型望远镜，可以识别观察到的生物，补充更多信息。文案要让人兴奋、体现前沿科技，字数控制在 800 字左右。」

观察这个提示词的结构：身份（产品发布文案）、功能（AI 识别生物、补充信息）、情感目标（让人兴奋、体现前沿科技）、硬约束（英文、800 字左右）。每个信息点都在削减 R1 推理过程中的不确定性。如果你的任务输出总是不对，先检查一下提示词里这四个要素缺了哪个。

4.3 使用示例的边界：R1 是个反直觉的特例

第三条技巧是文档里最有信息量的一条。一般大模型教程都会教 you 用 few-shot（给示例）来约束输出风格，但 R1 对 few-shot 特别敏感，示例反而容易限制它的发挥，效果更差。

文档给的例子是「参考种草文风格生成小红书文案」，它明确说：R1 比用户更懂小红书文案风格，你给示例反而让它放不开。但文档没有一刀切说「R1 不能用示例」，它的表述是「视情况而定」——如果输出格式是严格规定的（比如摘要格式），那就不要用示例，直接描述格式要求；如果示例的价值在于「无法用规则描述的偏好」，可以尝试。

实际使用时，我的判断标准是：如果你能用语言清晰描述想要的风格，就不给示例；只有当你描述不清楚、只能靠「给个样子」传达意图时，才用示例，且要准备接受性能波动。这条建议同样适用于其他推理模型。

4.4 设定角色：对 R1 来说大部分是无效动作

第四条技巧比较反常规。很多教程会教「你是精通 XX 的高级工程师，拥有 10 年经验」这类角色设定，但文档指出：对 R1 来说，这类角色设定基本无效。原因也很直接——R1 比用户更了解一个「精通 Web 开发的高级工程师」应该熟悉哪些技术栈，你写「熟悉 HTML/CSS/JavaScript/Vue.js/Node.js/Webpack/TypeScript」，对它来说只是冗余信息，甚至可能干扰真实需求。

但文档同时指出有一种角色设定是有效的：人格模仿。比如「扮演一个刚从美国留学回来的人，说话时中英文夹杂，对话中总是带有很强的优越感」——这类角色设定提供了风格样本，R1 可以执行。区别在于：前者试图定义「专家能力」，后者定义「语言风格」。R1 的能力是训练出来的，你不需要描述它应该会什么；但风格是输出层的属性，描述「怎么说话」是有效的。

4.5 输出符号化：用 JSON 格式约束结构化输出

第五条技巧是工程上最实用的：R1 对「输出格式符号化」依然有效。文档的例子是让模型总结文件内容：

自然语言格式：总结文件中的内容，需要包含故事主题、故事类型、故事梗概、角色、故事背景或场景。

JSON 格式： { "title": "{{ 故事主题 }}", "genre": "{{ 故事类型 }}", "plot": "{{ 故事梗概 }}", "characters": ["{{ 角色1 }}", "{{ 角色2 }}"], "settings": "{{ 故事背景或场景 }}" }

这里说明一下用 JSON 约束的要点：一是字段名要贴合你的业务语义，比如用title而不是t；二是值的格式要明确，比如用列表["角色1", "角色2"]而不仅是「角色」；三是如果模型输出不严格，可以在提示词里加一句「只输出 JSON，不要其他内容」。对做自动化流程的人来说，JSON 输出意味着你可以直接json.loads()解析结果，不用写正则去抠文本。

4.6 COT 提示词已失效：不要教 R1 思考

第六条技巧对熟悉老式提示词技巧的人是个提醒：像「请一步步思考」「think step by step」这类引导思维链（COT）的提示词，在 R1 上已经失效。原因是 R1 本身就是推理模型，它内部已经在做分步推理，你再要求它「逐步思考」不会提升效果，反而可能干扰它原有的推理模式。

文档说得很直接：「请帮我一步步思考」这类提示词在 R1 中依然有效吗？答案基本是负面的。用 R1 不需要显式 COT，直接陈述问题即可。如果你是从 ChatGPT 时代转过来的用户，这条最容易踩坑——你可能会习惯性地加上「think step by step」，但在 R1 上这属于多余操作。

4.7 分解任务：复杂问题逐层追问优于一口气问完

第七条技巧是「分解任务」。文档给的场景是一个软件系统出现性能瓶颈：不要直接问「我的软件系统出现性能瓶颈，请帮我分析瓶颈可能出在哪些细节、怎么定位和解决、解决后怎么验证性能是否提升」，而是要分步追问：

1. 先问「常见的软件性能瓶颈可能出现在哪些环节？」
2. 再问「如何通过工具或方法定位是数据、代码逻辑还是网络问题？」
3. 继续问「如果是数据库瓶颈，如何优化数据库性能？」
4. 最后问「优化后如何验证性能是否提升？」

这条技巧的原理是：R1 虽然擅长推理，但一次推理链过长时容易在某个环节走偏，把问题拆成多个来回，每轮推理链更短，准确率更高，而且你可以在每轮之间检查输出是否正确，及时纠偏。这本质上是一种「人在回路」的交互方式，适合复杂诊断和分析场景。

5. 避坑与常见问题：R1 使用中的五个典型翻车现场

5.1 现象：加了 few-shot 示例后，R1 输出质量反而下降

原因：R1 是推理模型，它内部已经具备强大的推理和风格理解能力。few-shot 示例会把它限制在示例的框架里，相当于「你教一个专家按菜鸟的思路干活」，反而压制了它的发挥。

解决：默认使用零样本（zero-shot）提示词，直接描述任务需求和输出格式。只有当任务风格极度特殊、文字无法描述时，才考虑给示例，并做好性能波动的心理准备。如果任务有严格的输出格式要求，就用 JSON 或其他结构化描述，不要用示例来暗示格式。

5.2 现象：R1 在中文事实类问题上不如 V3 稳定，经常拒绝回答

原因：文档明说了，R1 在安全强化学习阶段倾向于拒绝回答某些查询，导致中文 SimpleQA 基准表现不如 V3。这是模型的「敏感肌」特性，不是提示词写错了。

解决：如果是开放域事实问答，优先用 V3；如果是复杂推理任务，用 R1。如果必须用 R1 做事实问答，可以尝试在提示词里加「基于公开知识回答，如果无法确定请说明」，但这不能保证 100% 解禁——有些查询模型本身就不愿意回答。生产环境建议做模型路由：事实类任务走 V3，推理类任务走 R1。

5.3 现象：给 R1 设定「资深专家」角色后，输出反而更空泛

原因：角色设定对 R1 基本无效。你写「你是精通 XX 的 10 年经验工程师」，对 R1 来说只是噪音，它把注意力放在「扮演角色」上，而不是「解决你的问题」。文档的表述是「R1 比我们都更懂精通 XX 的工程师熟悉哪些技术栈」，多余的角色描述不会增加效果。

解决：直接陈述需求。想扮演角色也可以，但要有具体的语言风格描述（比如「说话中英文夹杂」「语气带有优越感」），而不是抽象的能力标签。能力标签是模型已经拥有或不需要的东西，语言风格才是需要你给定的输出约束。

5.4 现象：R1 在处理非中英文任务时出现语言混合，内容不连贯

原因：R1 的训练数据以中文和英文为主，遇到其他语言时，推理链可能在多个语言之间切换，导致输出混杂。这是文档明确列出的 R1 已知局限之一。

解决：非中英文场景先评估再定。如果目标语言覆盖好（比如常见欧洲语言），可以要求 R1 先中文推理再翻译；如果目标语言很小众，建议用 V3 或蒸馏模型，效果可能更稳定。和生产相关的一个教训是：不要假设一个在中文/英文上表现优异的模型，在其他语言上也同样可靠，先跑几个小样本验证。

5.5 现象：一次请求包含多步任务，R1 最终输出出现逻辑断裂

原因：推理链过长时，模型可能在中间某一步走偏，而后续所有步骤都基于错误前提继续推导，最终输出整体垮掉。这是推理模型的常见失效模式。

解决：把大任务拆成多个小任务，逐轮追问。文档给的性能瓶颈排查案例就是一个标准范本——先问瓶颈在哪，再问定位方法，再问优化方案，最后问验证方法。每轮都检查输出是否符合预期，再决定下一步怎么问。这个习惯同样适用于代码调试、数据分析、方案设计等复杂任务。

6. 从文档到实战：示例库的用法与一条能一直用的提示词习惯

开头说这份文档最有价值的是第 4 章提示词技巧，但完整读下来，真正拉开差距的部分在第 5 章的应用场景和第 6 章的部署方案。文档里整理了 13 个官方提示词示例，覆盖代码编写、数学解题、创意写作、角色扮演、事实问答等场景。这些示例直接复制粘贴就能用，但我的建议是不要照搬，而是从中提炼模板思维。

比如代码场景的提示词结构一般是「语言 + 任务描述 + 约束条件 + 验证方式」；创意写作则是「风格 + 主题 + 结构要求 + 字数限制」。把 13 个示例按这个思路拆一遍，你就能在自定义任务时自己组合出有效的提示词。

部署方面，文档给了在线使用和本地部署两条路径。在线使用是最快捷的方案，适合快速验证和日常对话；本地部署则要面对 671B 满血版和蒸馏小模型之间的取舍。从工程角度看，本地部署先确认硬件条件——显存大小决定你能跑多大的量化版本。一个经验值：7B 蒸馏版配合 4-bit 量化可以在消费级显卡上跑起来，32B 需要更高显存，671B 满血版基本需要在多卡集群上运行。先用蒸馏版验证效果，再决定要不要上更大版本，这是最省钱的路径。

我自己现在处理任何 R1 任务，都强制走一遍这个流程：先确认任务类型（推理类 vs 生成类）→ 推理类直接零样本描述需求 → 生成类按「背景 + 规则 + 格式 + 约束」四要素写提示词 → 如果任务有多步，拆成多轮追问 → 拿到结果后先检查逻辑是否连贯，再决定是否追问。自从用这套流程之后，R1 的输出稳定性提升了一个档次，翻车率明显下降。这篇文档的 7 条技巧本质上都是在帮你建立这个习惯，希望你也能在下次和 R1 对话时少踩几个坑。

本文还有配套的精品资源，点击获取