简介《清华大学 DeepSeek从入门到精通》是一份面向AI初学者、产品与技术人员及高校师生的PDF课程材料围绕DeepSeek公司与DeepSeek-R1开源推理模型展开帮助读者建立从基础认知到实际应用的完整知识框架。内容系统梳理DeepSeek是什么、能做什么、如何使用并延伸到文本生成、语义理解、计算推理、代码生成补全等典型场景同时对比推理模型与非推理模型在优势领域、性能本质和适用任务上的差异。材料还讨论链式思维下的“快思慢想”、提示语策略差异、任务需求与提示语匹配以及从“下达指令”到“表达需求”的转变并给出指令驱动、需求导向、混合模式与启发式提问等策略示例。资源包为1个PDF文件大小约4.79MB结构紧凑便于通读与检索目前已有175人学习。读者可借此理解DeepSeek-R1的能力边界掌握面向不同任务的模型选择与提示语设计思路形成可复用的AI应用方法。1. 大多数人第一次用推理模型都会本能地把提示语写长加角色、加步骤、加示例生怕模型漏掉什么。结果常常相反输出的推理链条反而变短、变浅甚至绕开了真正难的那一步。这不是玄学。DeepSeek 这类推理模型在训练阶段就把「怎么想」内化了你从外面再塞一套思考模板等于在它已经铺好的推理轨道上横插一段岔路。反过来同一个问题丢给通用模型如果只写一句「帮我分析一下」它大概率会跳步——因为你没有替它把推理的台阶搭出来。同一个动作两种模型给出相反的结果背后是「推理是否被展开成显式步骤」这个根本差异。搞懂这条分界线提示语该怎么写、模型该怎么选就都有了判断依据而不是靠反复试错攒经验。2. 快思与慢想CoT 究竟把大模型劈成了哪两类链式思维Chain-of-Thought出现之后大模型不再是一个笼统的概念。按「推理过程是否外化为 token」这条线切至少分成两类一类是概率预测型的快速反应模型一类是链式推理型的慢速思考模型。这两者的差别不是参数多少、也不是版本新旧而是计算路径不一样。2.1 概率预测与链式推理同一个问题两条计算路径给定一个问题 q概率预测模型的典型行为是一次前向计算直接对答案 y 的 token 分布做采样。链式推理模型则不同它在给出最终答案之前会先生成一串中间推理 token再把「问题 这串中间结果」一起作为上下文去生成下一段推理或最终答案。把这条路径写成伪代码差异一目了然。# 路径 A概率预测快速反应 # 一次前向直接得到答案分布 answer sample(P(y | q)) # 路径 B链式推理慢速思考 # 推理过程本身被展开成 token逐步累积进上下文 chain [] for step in range(max_steps): r sample(P(r | q, *chain)) # 第 n 步依赖前 n-1 步 if is_conclusive(r): # 模型自行判断推理是否收敛 break chain.append(r) answer sample(P(y | q, *chain)) # 答案建立在整条推理链之上这段伪代码里有三个值得盯住的点。第一chain是一个显式的、可被外部读取的中间结构它既带来了可解释性也带来了可纠错性——推理链错了人能看见错在哪一步。第二循环次数max_steps直接决定了延迟和算力成本这就是「慢」的来源它不是工程缺陷而是用延迟换正确率的主动取舍。第三第 n 步的采样依赖前 n-1 步的全部输出任何一个中间步骤跑偏误差都会沿着链条往后传所以这类模型对「第一步」的质量极其敏感。is_conclusive是模型自己学出来的终止判断不是外部脚本控制的开关。这一点很关键意味着你无法通过外部指令精确规定它「想几步」只能通过需求描述的清晰度去影响它的推理收敛速度。2.2 优势领域的错位为什么擅长写诗的模型算不好数学题能力边界是由训练目标塑造的不是由参数量塑造的。文本生成类模型的优化目标是「下一个 token 的似然」这个目标对开放式、多样性高的任务是友好的——写诗、写文案、多轮闲聊本来就没有唯一正确答案多样性是优点而不是噪声。但数学证明、逻辑推演、复杂问题拆解属于逻辑密度极高的任务它们的特征是「某一步错了整条链就废了」需要的是每一步的局部正确性校验而不是整体语言流畅度。推理模型在这类任务上显著更强是因为「生成正确的推理链」本身成了优化目标的一部分。常见的实现思路是引入强化学习等手段让模型在大量可验证的问题上反复练习「怎么一步步推」这件事而不是只练「怎么把话说顺」。反过来的错位同样成立在发散性任务上推理模型并不占优。它被训练成收敛到一条正确路径而创意写作恰恰需要不收敛。用推理模型写诗经常得到一个结构工整但没什么惊喜的结果原因就在这里。把这个差异整理成一张对照表选型时的判断会更立体维度推理模型通用模型优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作需要严格逻辑链的任务如数学证明性能本质专精于逻辑密度高的任务擅长多样性高的任务强弱判断仅在训练目标领域显著优于通用模型通用场景更灵活专项任务需提示语补偿响应速度与成本慢速思考算力成本高快速反应算力成本低决策能力能自主分析情况实时调整路径按预设脚本响应依赖规则创造力偏向收敛缺乏真正发散模式识别与组合创新有限但更自由人机互动能理解复杂情感与意图较难理解隐含意图表格里最容易被忽略的是「强弱判断」那一行推理模型并非全面更强。这个判断的价值在于它直接否定了「新模型一定碾压旧模型」的直觉也顺带解释了为什么按热度选型是个坏习惯。2.3 从训练目标反推能力边界选型的判断依据理解了上面这条因果链选型就不再是玄学。判断顺序应该是先看任务有没有唯一正确答案。有唯一答案、且需要多步推导数学、代码、逻辑分析交给推理模型没有唯一答案、或者答案的开放性本身就是价值文案、故事、头脑风暴交给通用模型。再看任务对延迟的容忍度。链式推理的算力成本高、响应慢交互式的即时补全场景里快速反应模型反而更合适。最后看任务是否需要人复核中间过程。需要看推理链的场景推理模型的显式链条本身就是可审计的资产只关心最终结果的场景链条长反而增加了阅读负担。这条判断依据之所以重要是因为它把「模型选择」放在了「提示语设计」之前。提示语是补偿手段不是能力来源。选错模型提示语写得再精巧也只是在错误的地基上做装修。3. 提示语策略的分叉同一句话两种模型收到的是不同信号很多提示语技巧的失效不是因为写得不好而是因为用错了对象。推理模型和通用模型对同一段提示语的「吸收方式」不一样前者读的是任务目标和需求边界后者读的是步骤和示例。写给谁决定了该写什么。3.1 内化逻辑与「少即是多」推理模型已经通过训练把推理逻辑内化了所以提示语只需要明确任务目标和需求剩下的交给它自己规划。常见的写法是「用 Python 实现快速排序输出需包含注释」一句话就够了步骤怎么拆、递归怎么写模型自己会处理。这时候如果你强行拆解步骤比如先要求它「定义递归函数」再要求「写分区逻辑」反而可能限制它的能力——因为它本来有一条更优的路径被你用外部模板锁死了。这就是「少即是多」的真实含义不是提示语越短越好而是不要把模型的自主规划空间提前压缩掉。你可以给足上下文和边界条件但不要给推理过程本身派活。需要特别提醒的是「启发式提示」的干扰。角色扮演这类手法本质是在给模型注入一个人格化的先验它对通用模型的发散输出有帮助但对推理模型可能干扰逻辑主线——模型会花算力去维持角色一致性而不是解题。提示判断一条提示语是否越界标准是它有没有替模型规定「先想什么再想什么」。规定了就是越界。3.2 补偿性引导通用模型缺什么补什么通用模型的短板恰好是推理模型的默认能力所以对它的提示语需要做补偿性设计显式要求分步思考提供示例明确输入输出格式。这一整套动作本质上是在外部用提示语模拟出一个 CoT 过程——模型自己没有内化推理你就用语言把台阶一级一级搭出来。关键在于「显式」二字。对通用模型直接问一个复杂推理问题它可能跳过关键逻辑直接给结论而且这个结论听上去还挺像回事。这种输出最难排查因为它看起来完整。解决办法是把「分步」写进要求里比如要求「先列出已知条件再逐步推导最后给结论」把推理过程变成必须产出的中间产物。同时也要避免另一个极端对通用模型过度信任。涉及数字、逻辑链、事实核验的任务拿到结果之后要分步验证而不是整段照收。3.3 提示语的三层结构与五种型态不管写给哪类模型提示语的结构是稳定的由三层组成指令明确告诉模型要执行什么任务是核心上下文提供必要的背景信息帮助它更准确地理解任务期望则明确或隐含地表达对输出的要求和预期。三层缺一输出要么跑偏要么飘。按功能再往下分提示语可以归成几种型态指令型直接下达任务问答型抛出问题等待答案角色扮演型要求模拟特定场景创意型引导内容生成分析型要求对给定信息做推理多模态型则结合文本与图像等多种输入。每种型态的适用场景不同混用容易失效——比如把分析型任务写成角色扮演型模型会花力气「演」而不是「算」。从机制角度理解提示语扮演的是五个角色连接人类意图与模型理解的沟通桥梁、提供背景的上下文提供者、明确任务的任务定义器、影响输出形式的输出塑造器以及引导模型调用特定能力的引导器。把一段提示语拆到这几个角色上逐一检查通常能定位出它为什么不好用——是桥梁没搭上意图不清还是塑造器缺位输出格式没定。def build_prompt(task, context, expectation, model_type): 按三层结构组装提示语并按模型类型调整引导强度 parts [task] # 指令任务核心必填 if context: parts.append(f背景{context}) # 上下文帮模型准确理解 if expectation: parts.append(f要求{expectation}) # 期望输出形式与质量标准 if model_type general: # 通用模型显式补上推理步骤要求外部模拟 CoT parts.append(请先列出关键条件再逐步推导最后给出结论。) # 推理模型不加步骤指令保留自主规划空间 return \n.join(parts)这个模板里task是不能省的那一层context和expectation按需补。真正体现设计取舍的是末尾那个分支只对通用模型追加步骤要求对推理模型保持沉默。一个if分支就把两类模型的提示语策略差异固化进了代码避免每次手写时凭感觉决定加不加步骤。4. 需求表达的三种策略与五类形态从「下达指令」到「表达需求」是提示语设计的一次视角切换。指令驱动关心的是「你按我说的做」需求导向关心的是「我要解决什么问题」。前者可控但上限低后者上限高但需要把需求边界说清楚。4.1 指令驱动、需求导向与混合模式指令驱动适合简单任务和需要快速执行的场景写法是直接给出明确步骤或格式要求比如「用 Python 编写快速排序函数输出需包含注释」。优势是结果精准高效风险是限制了模型的自主优化空间——它只能在你划的圈里走。需求导向适合复杂问题、需要模型自主推理的场景写法是描述问题背景与目标比如「我需要优化用户登录流程请分析当前瓶颈并提出 3 种方案」。优势是能激发深层推理风险是需求边界不清时输出会发散。混合模式是两者的折中给目标和关键约束但不规定路径。比如「设计一个三日行程包含某两个指定地点且预算控制在 2000 元内」。它兼顾了灵活性与可控性真正的难点在于「约束不能过度」——约束太多就退化成指令驱动约束太少就变成纯需求导向。这三种策略的选择本质是在「可控性」和「模型自主性」之间调一个比例。任务越标准化越往指令驱动偏问题越新颖、越需要模型的判断力越往需求导向偏。4.2 五类需求的表达公式与适配矩阵把需求按目的分类会得到五种形态每种都有相对稳定的表达公式和适配策略。这张矩阵是把「感觉怎么写都行」变成「知道该写哪几段」的关键。需求类型特点表达公式推理模型适配通用模型适配决策需求需权衡选项、评估风险、选最优解目标 选项 评估标准要求逻辑推演和量化分析直接建议依赖经验归纳分析需求需深度理解数据、发现模式或因果问题 数据/信息 分析方法触发因果链推导与假设验证表层总结或分类创造性需求需生成新颖内容主题 风格/约束 创新方向结合逻辑框架生成结构化创意自由发散依赖示例引导验证需求需检查逻辑自洽性、数据可靠性结论/方案 验证方法 风险点自主设计验证路径并排查矛盾简单确认缺乏深度推演执行需求需完成具体操作任务 步骤约束 输出格式自主优化步骤兼顾效率与正确性严格按指令执行无自主优化这张表最实用的地方是它给出了每类需求的「必填字段」。决策需求如果漏了评估标准模型给的推荐就没有依据验证需求如果漏了验证方法模型只会复述结论执行需求如果漏了输出格式回来的东西往往不能直接用。4.3 把公式落到可复用的模板公式要能用得落成模板。下面这段代码把五类需求做成可调用的构造函数字段名直接对应上表的公式缺字段时会抛错避免「忘了写评估标准」这类低级失误。from dataclasses import dataclass, field dataclass class DecisionReq: goal: str # 目标 options: list # 可选项 criteria: list # 评估标准缺失则无法比较 def render(self): assert self.criteria, 决策需求必须给出评估标准 opts .join(f{i1}) {o} for i, o in enumerate(self.options)) crit 、.join(self.criteria) return f目标{self.goal}\n可选方案{opts}\n请按 {crit} 逐项对比并给出推荐理由。 dataclass class VerifyReq: claim: str # 待验证的结论或方案 method: str # 验证方法如重算、对照、显著性检验 risks: list field(default_factorylist) def render(self): return (f待验证结论{self.claim}\n f请使用「{self.method}」重新核验并列出可能推翻该结论的风险点。)assert那一行是刻意留下的护栏决策类需求没有评估标准就等于让模型凭偏好选输出看起来合理但不可复现。VerifyReq里method是必填也是同样的道理——只写「请检查一下」模型大多会把原结论换个说法再讲一遍这不叫验证。模板的价值不在于省打字而在于把「需求表达公式」变成不可绕过的结构。写的时候被assert拦一次比拿到一份似是而非的输出再去返工要划算得多。5. 排查与避坑五类让输出质量大幅下降的提示语写法下面这些都是踩过的坑按「现象 → 原因 → 解决」记下来方便对照排查。5.1 对推理模型做角色扮演推理链反而变浅现象给推理模型加上「你是一位资深算法工程师」这类角色设定后解题输出变得很「像专家」但推理步骤明显变短复杂步骤被跳过。原因角色设定注入了一个人格化的先验模型需要分配算力去维持角色一致性逻辑主线被稀释。对推理模型来说这是纯粹的干扰项。解决去掉角色前缀直接写任务目标和输出要求。如果确实需要专业视角用「以算法复杂度为评估标准」这类具体约束替代角色扮演。5.2 对通用模型一次性抛出复杂推理现象把一道多步推导题原样丢给通用模型它给出的答案逻辑跳跃中间缺少关键推导但语气非常笃定。原因通用模型没有内化推理能力默认走的是「下一个 token 似然最大」的路径它会优先产出流畅的结论而不是正确的过程。解决显式要求分步。把「先列已知条件 → 再逐步推导 → 最后给结论」写进指令并要求它把每一步的依据标出来。拿到结果后对关键步骤单独复核。5.3 把「简洁」理解成「模糊」现象听说推理模型喜欢简洁提示于是只写「帮我优化一下这段代码」回来的改动方向和预期完全不符。原因简洁指的是不规定推理步骤不是不定义任务边界。目标模糊时模型只能自己猜你要优化性能、可读性还是内存占用。解决保持指令简洁但把边界说死。补上语言、约束条件、评价维度例如「在不改变时间复杂度的前提下优化这段 Python 代码的可读性」。5.4 用示例堆叠替代需求定义现象提示语里塞了五六个示例模型输出的结构和示例高度相似但换个场景就失效。原因示例是强引导信号数量一多模型会优先复制示例的形式而不是理解你要解决的实际问题本质是把需求定义偷换成了模式匹配。解决示例控制在必要数量内并明确说明「示例仅示意格式内容需按实际需求生成」。需求定义用文字写清楚示例只用来锁定输出结构。5.5 验证需求写成「请检查一下」现象让模型验证一个结论它把原结论换个措辞复述一遍并补充「该结论基本可靠」。原因没有指定验证方法模型缺乏可执行的验证路径只能做表层语言层面的确认这不构成真正的检查。解决把验证方法写进需求指定重算方式、对照条件或风险点清单。要求它输出「可能推翻该结论的情形」比要求它「判断对错」有效得多。注意这五条里有四条的共同根源是「需求边界缺失」而不是模型能力不足。排查时优先检查边界再怀疑模型。6. 设计取舍为什么模型选择必须排在提示语设计之前把这份讲义的结构拆开看会发现它先讲「推理模型与通用模型的差异」再讲「提示语策略」最后才落到具体需求的表达方式。这个顺序不是随手排的它对应一条因果链模型能力由训练目标决定提示语只能在能力边界内做补偿需求表达则是在补偿之上做精确投递。顺序反过来就会陷入「提示语写得不够好」的自我怀疑而真正的问题可能是模型选错了。这个取舍的现实意义在于它给了你一个成本更低的排查顺序。遇到输出不理想先问任务类型对不对——需要严格逻辑链的任务交给通用模型提示语写得再结构化也只是在外部模拟推理效率天然低于内化了推理的模型。再问提示语有没有越界——对推理模型强行拆解步骤是把它的优势压平。最后才问需求边界清不清楚评估标准、验证方法、输出格式这些字段有没有漏。验证这套判断有个简单办法同一个任务用两种模型各跑一遍提示语分别按各自策略写。如果推理模型在逻辑密度高的任务上明显更稳通用模型在开放性任务上明显更活说明你的选型逻辑和提示语策略是自洽的。如果两者表现差不多大概率是提示语把差异抹平了——要么对推理模型约束过度要么对通用模型引导不足。进阶方向也很清楚把五类需求的模板固化成自己的提示语库用代码管理而不是靠记忆。需求类型作为入参模板负责组装模型类型决定是否追加步骤引导。这套东西一旦跑顺换模型、换任务时的迁移成本会降得很低。我自己的习惯是每次拿到一个新任务先花三十秒判断它属于哪类需求、有没有唯一正确答案再决定用哪个模型、套哪个模板。这个动作最初很别扭坚持一段时间后成了条件反射返工率明显下降。踩过的坑大多不是因为提示语写得不够花哨而是因为跳过了这一步判断直接开始写。希望帮到你。本文还有配套的精品资源点击获取