简介：《DeepSeek从入门到精通》是一份面向AI初学者、产品与研发人员的PDF学习资料，聚焦国产大模型DeepSeek的能力认知与实际使用，帮助读者从“知道是什么”推进到“能在任务中选对模型、写好提示语”。内容围绕DeepSeek是什么、能做什么、如何使用展开，覆盖智能对话、文本生成、语义理解、计算推理、代码生成补全等场景，并系统比较推理大模型与非推理大模型的优势边界，讲解“快思慢想”、CoT链式思维及提示语策略差异，还给出数学证明、创意写作、代码生成等任务中的模型选择与提示设计原则，便于读者把方法落到写作、办公与编程实践。压缩包共1个PDF文件，大小约5.36MB，结构紧凑、便于检索。已有1011人学习，适合希望系统入门DeepSeek并提升提示工程与推理模型应用能力的学习者。
1. 从一份讲稿说起：DeepSeek 从入门到精通，精通的其实不是功能
一个做电商运营的朋友把这份材料发给我，说看完了，还是不知道该怎么让模型把 30 页的季度报告压成 800 字、还得保留关键数据。我翻了一遍，材料本身没问题——它把 DeepSeek 从入门到精通的路线拆得很实在：能做什么、两类模型怎么分、提示语怎么设计、需求怎么表达，一条线下来是有骨架的。缺的是把骨架落到自己业务上的那一步。
这份资源本质上是一份方法论讲稿，不是功能说明书。它最有价值的地方不在于“支持联网搜索”“支持文件上传”这些条目——这些谁都会点——而在于把推理模型和通用模型分开讲、把提示语按任务类型给策略这件事。已经在用但输出忽好忽坏的人，和要把 AIGC 能力嵌进业务流程的开发者，都能从里面找到可直接复用的东西。下面按我自己的拆解顺序走一遍。
2. 推理模型与通用模型：选错一次，后面全是无用功
2.1 推理模型（ReasoningModels）与通用模型的分野不在强弱
先把定义摆清楚。推理大模型是在传统大语言模型的基础上，强化推理、逻辑分析和决策能力的模型，通常叠加了强化学习、神经符号推理、元学习这类技术手段，目标是把“一步一步想”这件事内化进模型本身。DeepSeek-R1 就属于这一类，开源、可免费商用，擅长处理复杂任务。通用大模型走的是另一条路：靠海量文本数据训练掌握语言规律，侧重语言生成、上下文理解和自然语言处理（NaturalLanguageProcessing），不强调深度推理链路。
这两类模型的差别，用一张表能说清，但真正要记住的是最后一行的判断：
| 维度 | 推理模型 | 通用模型 |
|---|---|---|
| 优势领域 | 数学推导、逻辑分析、代码生成、复杂问题拆解 | 文本生成、创意写作、多轮对话、开放性问答 |
| 劣势领域 | 发散性任务（如诗歌创作） | 需要严格逻辑链的任务（如数学证明） |
| 性能本质 | 专精于逻辑密度高的任务 | 擅长多样性高的任务 |
| 强弱判断 | 并非全面更强，仅在其训练目标领域显著优于通用模型 | 通用场景更灵活，但专项任务需依赖提示语补偿能力 |
最常见的误判，是把“更新的那个”当成“更强的那个”。我见过不少团队，一上来所有请求全打到推理模型上，结果写商品文案、起标题、编活动 slogan 这类活儿，出来的东西工整得像八股，读着没味道。反过来，拿通用模型去做多步数学证明，它会一本正经地把中间步骤编圆——看起来推完了，其实第三步就错了。模型选型这件事，坑不在技术，在预期。
2.2 快思慢想的工程含义：响应速度和算力成本要一起算
链式思维（CoT）出现之后，大模型实际上被分成了两类：一类是基于概率预测的“快速反应”模型，靠大量数据训练快速预测可能的答案；另一类是基于链式推理的“慢速思考”模型，逐步推演问题的每个步骤再给结论。这个划分在论文里是概念，在工程上是账单。
| 维度 | 概率预测（快速反应） | 链式推理（慢速思考） |
|---|---|---|
| 性能表现 | 响应速度快，算力成本低 | 慢速思考，算力成本高 |
| 运算原理 | 基于概率预测，通过大量数据训练快速预测答案 | 基于链式思维，逐步推理每个步骤得到答案 |
| 决策能力 | 依赖预设算法和规则进行决策 | 能自主分析情况，实时做出决策 |
| 创造力 | 限于模式识别和优化，缺乏真正创新能力 | 能生成新创意和新方案，具备创新能力 |
| 人机互动 | 按预设脚本响应，较难理解人类情感和意图 | 更自然地与人互动，理解复杂情感和意图 |
| 问题解决 | 擅长解决结构化和定义明确的问题 | 能处理多维度和非结构化问题，提供创造性解法 |
| 伦理问题 | 作为受控工具，几乎没有伦理问题 | 引发自主性和控制问题的伦理讨论 |
落到实操上，慢思考模型在输出阶段会产生大量中间推理 token，同一个问题，消耗可能是快模型的几倍甚至十几倍。我一般的做法是给推理类请求单独开一条通道，设三样东西：单次输出上限、超时时间、以及一个明确的降级策略——超时或超预算就切到快模型先给个可用版本。批处理任务（比如几千条评论的情感打标）尤其要注意，这种活儿本来就不需要推理链，用慢模型纯属浪费。
有人会问，那是不是慢模型就只能在数学题上用？不是。复杂业务决策、多约束条件下的方案比较、带歧义的需求拆解，这些都属于“逻辑密度高”的任务，慢模型确实更容易给出能落地的东西。判断标准不是任务看起来难不难，而是它需不需要多步推理且步骤之间有依赖。
2.3 选型决策：拿任务类型去对，别拿模型热度去对
讲稿里给了一条关键原则：优先根据任务类型而非模型热度选择模型。我把常见任务整理成了一张可以直接贴到团队文档里的对照表：
| 任务 | 建议模型 | 理由 |
|---|---|---|
| 数学推导、公式证明 | 推理模型 | 需要严格逻辑链，中途断一步就全错 |
| 代码生成与调试 | 推理模型 | 要考虑边界条件和执行路径 |
| 复杂业务决策（多方案比较） | 推理模型 | 需要权衡多个约束并给出依据 |
| 创意写作、诗歌、slogan | 通用模型 | 发散性任务，逻辑链反而限制发挥 |
| 多轮客服对话 | 通用模型 | 响应速度优先，上下文连贯即可 |
| 长文摘要、翻译本地化 | 通用模型（可加结构化提示） | 语言任务为主，推理链收益低 |
| 结构化抽取（表格、清单） | 通用模型 + 格式约束 | 关键是输出格式稳定 |
这张表不是铁律，但它能挡掉 80% 的选型错误。真正难的是混合任务——比如“分析这份销售数据并给出三条可执行建议”，前半段是分析（偏推理），后半段是表达（偏通用）。处理方式是拆成两段调用，而不是指望一个模型一次做完。
2.4 同一个问题两种问法：一次直接对照
这块最容易讲糊涂，直接上对照。以“证明勾股定理”为例：
# 问法 A：对推理模型，简洁直接 证明勾股定理。 # 问法 B：对推理模型，强行拆解步骤 先画一个直角三角形，设两条直角边为 a 和 b，斜边为 c， 然后写出面积关系式，再展开化简，最后得到 a²+b²=c²。A 会让模型自己生成结构化的推理链，中间步骤是它内化的逻辑；B 看起来“更详细”，实际上是把模型的推理路径锁死在我预设的框架里，一旦我预设的那条路不是最优路径，输出质量就掉下来了。这是很多人踩过的坑：以为给得越细越好，结果对推理模型是负优化。
换成通用模型，情况完全反过来：
# 对通用模型，必须显式补步骤 请分三步推导勾股定理： 1. 画一个直角三角形，标注直角边 a、b 和斜边 c； 2. 用面积法写出等式（大正方形 = 四个三角形 + 中间小正方形）； 3. 化简等式，得出 a² + b² = c²，并说明每一步的依据。这里的参数不是“写给模型看的”，是“写给我自己检查用的”：分几步、每步产出什么、最后要什么格式。通用模型不会自己补这些，你不写它就跳过关键逻辑，而且跳得毫无提示。
3. 提示语工程：从“下达指令”到“表达需求”的三级跳
3.1 提示语（PromptEngineering）的本质是三个部件
提示语是用户输入给 AI 系统的指令或信息，用于引导 AI 生成特定输出或执行特定任务。它可以是一个简单的问题、一段详细的指令，也可以是一个复杂的任务描述。讲稿把它拆成三个基本部件，这个拆法我认为是对的：
| 部件 | 作用 | 示例 |
|---|---|---|
| 指令（Instruction） | 明确告诉 AI 要执行什么任务 | “将以下内容翻译为法语” |
| 上下文（Context） | 提供背景信息，帮助准确理解任务 | “假设你是一位 19 世纪的历史学家，评论拿破仑的崛起” |
| 期望（Expectation） | 明确或隐含表达对输出的要求和预期 | “为一篇关于气候变化的文章写一个引言，长度 200 字” |
除了这三个部件，讲稿还给了五种功能定位：沟通桥梁（连接人类意图和 AI 理解）、上下文提供者、任务定义器、输出塑造器、AI 能力引导器。这五个定位听起来抽象，实操中很实用——当你写出来的提示语效果不好时，可以逐个对照：是任务没说清（任务定义器失效），还是输出形态没约束（输出塑造器失效），还是根本没让模型调用它擅长的能力（能力引导器失效）。
我自己的经验是，输出塑造器最容易被漏掉。绝大多数人写提示语只写到“帮我分析一下这份数据”，没写“输出成三列表格，第一列是结论，第二列是依据，第三列是置信度”。结果模型给你一大段散文，你还得自己整理。
3.2 六类提示语与它们各自的失效边界
讲稿列了六种提示语类型，每一类都有它擅长的地方，也都有明确的失效场景：
| 类型 | 做法 | 典型失效 |
|---|---|---|
| 指令型 | 直接告诉 AI 需要执行的任务 | 任务本身有歧义时，模型只能猜 |
| 问答型 | 向 AI 提问，期望得到答案 | 开放式问题容易得到泛泛而谈的回答 |
| 角色扮演型 | 要求 AI 扮演特定角色，模拟特定场景 | 对推理模型可能干扰其逻辑主线 |
| 创意型 | 引导 AI 进行创意写作或内容生成 | 约束不足时输出发散、不可用 |
| 分析型 | 要求 AI 对给定信息进行分析和推理 | 没给分析框架时容易停在表层 |
| 多模态型 | 结合文本、图像等多种形式的输入 | 图像信息密度低时，模型会自行脑补 |
角色扮演这一条值得单独拎出来说。它在通用模型上是利器——“假设你是一位有十年经验的运维工程师，审查下面这份部署方案”——但在推理模型上，角色设定可能把模型从“解题者”变成“表演者”，输出的逻辑严谨度反而下降。这是两类模型提示语策略分叉的一个典型表现。
3.3 提示语策略的分叉：推理模型要少说，通用模型要补课
讲稿给了一张策略差异表，我把它翻译成操作口径：
| 推理模型 | 通用模型 | |
|---|---|---|
| 提示语长度 | 更简洁，只明确任务目标和需求 | 需显式引导推理步骤 |
| 是否分步指导 | 无需逐步指导，模型自动生成结构化推理过程 | 依赖提示语补偿能力短板 |
| 强行拆解的后果 | 可能限制模型能力 | 不拆就会跳过关键逻辑 |
对应三条关键原则：模型选择优先看任务类型；提示语设计上，推理模型简洁指令、聚焦目标、信任其内化能力，也就是“要什么直接说”；通用模型结构化、补偿性引导，也就是“缺什么补什么”。
要避免的误区有两条，都是血泪经验。第一条，不要对推理模型使用启发式提示，比如角色扮演、“你觉得为什么”，这类引导可能干扰它的逻辑主线。第二条，不要对通用模型过度信任，直接抛复杂推理问题，它答得流畅但未必对，必须分步验证结果。
3.4 三套可以直接抄的模式
讲稿给了三种策略模式，我把示例改成了更贴近日常工作的版本，可以直接拿去用：
# 模式一：指令驱动（简单任务、需快速执行） 用 Python 编写快速排序函数，输出需包含注释， 并说明时间复杂度和最坏情况。 # 模式二：需求导向（复杂问题、需模型自主推理） 我需要优化用户登录流程，请分析当前瓶颈并提出 3 种方案， 每种方案需给出改造成本和风险点。 # 模式三：混合模式（兼顾目标与细节约束） 设计一个三日出差行程，包含客户拜访和技术交流， 且总预算控制在 3000 元以内。三者的差别在约束的位置。指令驱动把约束放在“输出格式”上，过程完全交给模型；需求导向只给背景和目标，路径由模型规划，适合推理模型；混合模式既给目标又给关键约束，是通用模型上最稳的一种写法。风险也写在对应位置：指令驱动限制模型自主优化空间，需求导向需要清晰定义需求边界，否则容易跑偏，混合模式则要防止约束过度导致输出僵硬。
参数怎么调？我的习惯是给每次调用留三个可调项：约束数量（一般 2 到 4 条，超过 5 条模型容易顾此失彼）、输出长度上限（明确写“不超过 N 字”，比事后裁剪省事）、以及格式要求（表格、列表还是分段，越具体越好）。
4. 五类需求表达公式：把“帮我写个方案”拆成可执行输入
4.1 决策需求与分析需求：评估标准必须写进去
决策需求的特点是需要在多个选项之间权衡，评估风险，选出最优解。公式是“目标 + 选项 + 评估标准”，对推理模型的适配策略是要求逻辑推演和量化分析，对通用模型则是直接建议、依赖其经验归纳。
为降低物流成本，现有两种方案： ① 自建区域仓库（初期投入高，长期成本低） ② 与第三方合作（按需付费，灵活性高） 请根据 ROI 计算模型，对比 5 年内的总成本并推荐最优选择， 计算过程需列出每年的成本构成。这段提示语里最关键的不是两个方案，是“ROI 计算模型”和“5 年”这两个约束。没有它们，模型给你的就是“各有优劣，建议结合实际情况”这种正确但没用的话。我见过太多人抱怨模型回答空泛，其实问题在于自己没给评估标准。
分析需求的公式是“问题 + 数据/信息 + 分析方法”，适配策略是触发因果链推导和假设验证。
分析近三年新能源汽车销量数据（见附件 CSV），说明： ① 增长趋势与政策的关联性； ② 预测下一年的市占率，需使用 ARIMA 模型并解释参数选择依据。这里“ARIMA 模型”就是分析方法约束。你不指定方法，模型可能用线性回归糊过去；指定了方法，它会解释参数，你才有得验。
4.2 创造性需求：约束创新方向，别约束过程
创造性需求的特点是生成新颖内容，公式是“主题 + 风格/约束 + 创新方向”。推理模型适配策略是结合逻辑框架生成结构化创意，通用模型则是自由发散、依赖示例引导。
设计一款智能家居产品，要求： ① 解决独居老人安全问题； ② 结合传感器网络和 AI 预警； ③ 提供三种不同技术路线的原型草图说明。注意这里的三条要求全部是“方向性约束”，没有一条规定“先做什么再做什么”。这就是创造类需求的关键：约束边界，放开路径。反过来，如果你的提示语写成“第一步调研市场，第二步设计功能，第三步画草图”，出来的东西大概率是一份模板化的方案，因为路径被锁死了。
顺带说一句，纯发散任务（写诗、起名、编故事）我基本都放通用模型上跑。推理模型在这类任务上会不自觉地追求“合理”，而好的创意往往来自不合理。
4.3 验证需求：让模型自己设计验证路径
验证需求的公式是“结论/方案 + 验证方法 + 风险点”，这一类比前面几类更容易被写废。大多数人的写法是“你看这个对不对”，模型顺着你说“基本正确，建议补充细节”，等于没验。
以下是某论文结论：'神经网络模型 A 优于传统方法 B'。请验证： ① 实验数据是否支持该结论； ② 检查对照组设置是否存在偏差； ③ 重新计算 p 值并判断显著性。三条验证要求，每一条都指向一个具体的可执行动作。模型没法含糊过去，因为“重新计算 p 值”这个动作要么做了要么没做，你一眼看得出来。这是验证类提示语的通用技巧：把“评价”换成“执行一个能暴露问题的动作”。
对推理模型的适配策略是让它自主设计验证路径并排查矛盾；对通用模型则要给具体方法，否则它只会做表层确认。
4.4 执行需求：步骤约束和输出格式必须显式
执行需求的公式是“任务 + 步骤约束 + 输出格式”，特点是严格按指令执行、不需要模型自主优化。
将以下 C 语言代码转换为 Python，要求： ① 保持时间复杂度不变； ② 使用 numpy 优化数组操作； ③ 输出带时间测试案例的完整代码。三条约束分别对应语义等价、性能等价和可验证性。这类需求最忌讳“你自己看着办”，因为执行类任务的价值就在于确定性。参数上我一般会额外加一条“如果某条要求无法满足，单独列出来并说明原因”，防止模型为了满足格式而硬编。
4.5 任务类型与提示语侧重点：一张对照表收口
| 任务类型 | 适用模型 | 提示语侧重点 | 有效提示示例 | 要避免的写法 |
|---|---|---|---|---|
| 数学证明 | 推理模型 | 直接提问，无需分步引导 | “证明勾股定理” | 冗余拆解（“先画图再列公式”） |
| 数学证明 | 通用模型 | 显式要求分步思考，提供示例 | “请分三步推导，参考：1. 画直角三角形…” | 直接提问（易跳过关键步骤） |
| 创意写作 | 推理模型 | 鼓励发散，设定角色/风格 | “以海明威的风格写一个冒险故事” | 过度约束逻辑（“按时间顺序列出”） |
| 创意写作 | 通用模型 | 明确约束目标，避免自由发挥 | “写一个包含‘量子’和‘沙漠’的短篇，不超过 200 字” | 开放式指令（“自由创作”） |
| 代码生成 | 推理模型 | 简洁需求，信任模型逻辑 | “用 Python 实现快速排序” | 分步指导（“先写递归函数”） |
| 代码生成 | 通用模型 | 细化步骤，明确输入输出格式 | “先解释原理，再写代码并测试示例” | 模糊需求（“写个排序代码”） |
| 多轮对话 | 通用模型 | 自然交互，无需结构化指令 | “你觉得人工智能的未来会怎样？” | 强制逻辑链（“分三点回答”） |
| 多轮对话 | 推理模型 | 明确对话目标，避免开放发散 | “从技术、伦理、经济三方面分析 AI 的未来” | 情感化提问 |
| 逻辑分析 | 推理模型 | 直接抛出复杂问题 | “分析‘电车难题’中的功利主义与道德主义冲突” | 添加主观引导 |
| 逻辑分析 | 通用模型 | 需拆分问题，逐步追问 | “先解释定义，再对比两种伦理观的差异” | 一次性提问复杂逻辑 |
这张表用久了会发现一个规律：模型越强，提示语越短；模型越通用，提示语越像一份需求文档。很多人把这件事搞反了，对强模型写长篇大论，对通用模型一句话打发，然后抱怨“模型不行”。
5. 避坑与排查：五个反复翻车的提示语现场
5.1 对推理模型套角色扮演，输出反而变浅
现象：给推理模型加了一句“你是一位资深架构师，请审查这份设计”，结果它给了一段泛泛的架构评价，具体到代码层面的问题一个没提。把角色设定去掉、直接问“这份设计在高并发写入场景下有哪些风险点”，回答立刻变具体。
原因：角色扮演会把模型的输出重心从“解题”拉到“表演一个资深架构师会怎么说话”，逻辑链被打断，剩下的就是话术。推理模型的内化推理过程对提示语的“纯净度”很敏感。
解决：推理模型上删掉所有角色设定和情感化引导，只保留任务目标和约束条件。确实需要角色视角的，放到通用模型上跑，或者把角色信息改写进上下文（“以下是某电商系统的订单模块设计，日均写入 200 万次”），而不是写成身份指令。
5.2 对通用模型直接抛复杂推理题，答案看着对其实错
现象：问一道多步概率题，通用模型给了完整解答，格式漂亮，结论也像个答案。但把中间步骤逐步核对，第二步就用错了条件概率公式。
原因：通用模型缺乏推理模型那样的复杂推理和决策能力，它靠语言规律补全“看起来像解题过程”的文本，流畅度和正确性在这里是解耦的。
解决：两步走。第一步，能换推理模型就换；第二步，换不了就在提示语里显式要求分步并每步给依据，同时对关键结论做反向验证——追问“如果某个条件不成立，结论会怎么变”，看它能否自洽地推下去。答不上来的，多半是编的。
5.3 需求边界没写，输出“全面但没用”
现象：让模型“分析一下用户流失原因”，回来的是一份五千字的行业综述，从宏观环境讲到竞品动态，就是没有一条能落到自己产品上。
原因：需求表达只给了主题，没给边界。模型无法判断你要的是行业视角还是产品视角、要几条、要多深，只能按最安全的方式铺开写。
解决：补齐三样东西——数据范围（“基于附件中近 90 天的用户行为表”）、输出粒度（“列出 5 条，每条不超过 60 字”）、判断标准（“按影响用户数排序”）。这三样齐了，输出长度通常会缩到原来的三分之一，可用率翻几倍。
5.4 文件上传后不问定位，摘要丢关键数据
现象：把一份几十页的报告传上去做摘要，模型给了一段流畅的概述，但你要的几个核心数字全没了。
原因：长文档摘要属于典型的“压缩”任务，模型会优先保留叙事主线，数字和表格这类非叙事信息在压缩过程中最先被牺牲。
解决：摘要类请求要显式指定保留项。我的固定写法是“摘要需保留：所有金额数字、所有时间节点、所有责任主体；其余内容可压缩到 300 字内”，再追加一句“如某项信息原文未提及，写‘未提及’，不要推测”。最后这句很重要，它把模型编数字的路堵住了。
5.5 验证需求写成“你看对不对”，模型只会顺着你说
现象：把自己写的方案丢给模型问“这个方案有问题吗”，回答是“方案整体思路清晰，建议在细节上进一步完善”，等于没提意见。
原因：开放式肯定型提问会触发模型的顺从倾向，尤其当输入本身带有明显的立场和完成度时，模型倾向于给出低冲突的回应。
解决：把验证改成对抗式。不要问“有没有问题”，而是指定攻击角度：“请从成本、合规、可维护性三个角度，分别指出这个方案最可能被否决的一条理由，每条给出反例场景。”指定角度和数量之后，模型就没法用套话糊弄。
6. 交付前的一次卡点：用对抗式复问把输出按住
前面几章讲的都是“怎么问”，最后说一个我每次交付前都会走的动作：对抗式复问。做法很简单，拿到第一版输出后，不要直接改，先切一个新会话，把输出原样贴进去，附上三条固定的追问。
以下是一份 AI 生成的方案，请做三件事： 1. 找出其中三条最可能站不住的论断，并说明缺什么证据； 2. 假设你是评审方，写出你最想追问的一个问题； 3. 指出文中哪些数字或结论是"看起来合理但无法溯源"的。这三问的价值在于切断上下文依赖。同一个会话里追问，模型会顺着前面的立场走；换一个干净会话重新输入，它才更像个外部评审。第 1 条查的是逻辑漏洞，第 2 条查的是说服力缺口，第 3 条专治 AIGC 内容里最常见的那种“数字很具体但查无出处”的毛病。
配合这个动作，我还有一个三行自检表，放在交付清单里，逐条打勾：
| 检查项 | 判断标准 | 不通过怎么办 |
|---|---|---|
| 模型选对了吗 | 任务是逻辑密集型还是发散型 | 逻辑密集换推理模型，发散型换通用模型 |
| 边界写清了吗 | 数据范围、输出粒度、判断标准三样齐不齐 | 缺哪样补哪样，别指望模型猜 |
| 结论可溯源吗 | 每个关键数字能否指回原始材料 | 指不回去的一律删掉或标注“待核” |
这套流程听起来繁琐，但真跑几次就成肌肉记忆了。我最早做 AIGC 内容交付的时候，图省事跳过验证，结果一份对外材料里三个数据全错，被业务方当场问住，那次之后我把这三问写进了模板，不走完不发。模型能力再强，也只是把“生成”这一步的成本压到了接近零，判断和兜底还是得自己来。希望帮到你。
本文还有配套的精品资源，点击获取
