简介:这份PDF资料是清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队出品的DeepSeek教程PPT,共104页,面向希望系统掌握国产大模型应用的初学者与进阶用户,帮助读者厘清DeepSeek的能力边界与使用策略。压缩包内仅含1个PDF文件,约5.07MB,以图文并茂的幻灯片形式组织内容,便于按章节浏览与对照学习。目前已有664人学习下载。资料围绕DeepSeek是什么、能做什么、如何使用三条主线展开,涵盖文本创作、摘要改写、多语言翻译、代码生成与调试、语义分析与知识推理等应用场景,并重点对比推理模型与非推理模型在优势领域、性能本质、决策能力与伦理问题上的差异,给出提示语策略与任务匹配建议,如数学证明宜用推理模型、创意写作宜用通用模型。读者可借此建立从入门到精通的完整认知框架,掌握按任务类型选择模型与设计提示语的方法。
1. 推理模型不是「更聪明的通用模型」:一个被误读的能力边界
很多人第一次用 DeepSeek-R1,会下意识把它当成「升级版 GPT」——参数更大、更聪明、什么都能干。结果拿它写营销文案,输出干巴巴像说明书;让它编个故事,逻辑严密但毫无灵气。反过来,用通用模型解数学证明,它会在关键步骤「跳步」,答案看着对,推导链是断的。这不是模型不行,是你把两类模型的任务边界搞混了。
推理模型和通用模型的差异,不是「强弱」而是「专精方向」。R1 这类模型通过强化学习把推理逻辑内化进了权重,擅长数学推导、代码生成、复杂问题拆解;通用模型则靠海量文本训练出语言规律,擅长创意写作、多轮对话、开放性问答。搞懂这条边界,你才知道什么时候该「要什么直接说」,什么时候该「缺什么补什么」。这份 104 页的教程 PPT,核心价值就在于把这条边界讲透了。
2. 快思慢想:概率预测与链式推理的底层分野
2.1 两类模型的运算原理差在哪
要理解推理模型为什么「慢而准」,得先看它和通用模型在运算原理上的根本差异。通用模型(比如 GPT-4o 这类)本质是概率预测机器:给定上文,它通过大量数据训练出的分布,快速预测下一个最可能的 token。这个过程是并行的、一次前向传播就出结果,响应快、算力成本低。但它的问题也在这里——它没有「停下来想一想」的机制,遇到需要多步推导的任务,它倾向于给出「看起来最像答案」的输出,而不是「推导出来正确」的输出。
推理模型(R1、o1 这类)走的是另一条路:链式思维(Chain-of-Thought)。它在给出最终答案前,会先生成一段内部的推理过程,把复杂问题拆成若干步骤,逐步推演。这个「慢速思考」的过程消耗更多算力,但换来的是逻辑链的完整性。用教程里的比喻,这就是「快思慢想」——系统一快速反应,系统二慢速推理。
这个差异直接决定了提示语策略。对推理模型,你不需要教它「先画图再列公式」,它自己会拆步骤;你强行拆解,反而可能干扰它内化的推理主线。对通用模型,你不显式引导推理步骤,它就可能跳过关键逻辑。这就是为什么教程里反复强调:推理模型「要什么直接说」,通用模型「缺什么补什么」。
2.2 能力矩阵:优势领域与劣势领域的对照
把两类模型的能力摊开对比,边界会更清楚。下面这张表是根据教程内容整理的维度对照,能帮你快速判断任务该交给谁:
| 维度 | 推理模型 | 通用模型 |
|---|---|---|
| 优势领域 | 数学推导、逻辑分析、代码生成、复杂问题拆解 | 文本生成、创意写作、多轮对话、开放性问答 |
| 劣势领域 | 发散性任务(如诗歌创作) | 需要严格逻辑链的任务(如数学证明) |
| 性能本质 | 专精于逻辑密度高的任务 | 擅长多样性高的任务 |
| 决策能力 | 能自主分析情况,实时做出决策 | 依赖预设算法和规则进行决策 |
| 创造力 | 能生成新创意和解决方案 | 限于模式识别和优化 |
| 人机互动 | 更自然,理解复杂情感和意图 | 按预设脚本响应,较难理解情感 |
这张表最容易被误读的一点是「强弱判断」——推理模型并非全面更强,它仅在其训练目标领域显著优于通用模型;通用模型在通用场景更灵活,但专项任务需要靠提示语补偿能力短板。换句话说,选错模型不是「效果差一点」,而是「方向性错误」。
2.3 一个容易翻车的认知:推理模型也会「过度思考」
这里有个血泪经验值得单独说。推理模型的链式推理不是免费的——它对简单任务也会展开推理,导致响应变慢、甚至把简单问题复杂化。比如你问「今天天气怎么样」,它可能先分析「用户为什么问天气」「需要哪些信息」再回答,反而啰嗦。教程里提到的「避免误区」就包括这一点:不要对推理模型使用启发式提示(如角色扮演),可能干扰其逻辑主线;但也不要在所有场景都无脑上推理模型,简单任务用通用模型更快更省。
常见的实现思路是:先按任务类型分流——数学、代码、逻辑证明走推理模型;文案、对话、创意走通用模型。混合任务则拆开处理,比如「先解释快速排序原理,再写出代码并测试示例」,原理部分可以交给通用模型讲清楚,代码部分交给推理模型保证正确性。
3. 提示语策略:从「下达指令」到「表达需求」的范式转换
3.1 提示语的三层结构:指令、上下文、期望
很多人以为提示语就是「把问题打进去」,但教程把提示语拆成了三层结构,这个拆法很关键:
- 指令(Instruction):明确告诉 AI 要执行什么任务,这是核心。
- 上下文(Context):提供背景信息,帮助 AI 更准确理解任务。
- 期望(Expectation):明确或隐含地表达对输出的要求和预期。
这三层对应提示语的本质特征——它是「沟通桥梁」(连接人类意图和 AI 理解)、「任务定义器」(明确任务)、「输出塑造器」(影响输出形式)、「能力引导器」(引导 AI 使用特定能力)。理解这个结构,你才知道为什么同样一句话,有人问出来精准,有人问出来跑偏:差在上下文和期望没给够。
教程还列了六种提示语类型:指令型、问答型、角色扮演型、创意型、分析型、多模态。类型本身不新鲜,新鲜的是它和模型类型的匹配关系——角色扮演型对推理模型可能是干扰,对通用模型却是激发创意的有效手段。
3.2 五种需求表达公式与模型适配
教程里最有实操价值的部分,是把需求分成五类,每类给了表达公式和双模型适配策略。这套东西值得逐条拆:
决策需求:公式是「目标 + 选项 + 评估标准」。推理模型适配策略是要求逻辑推演和量化分析,通用模型是直接建议、依赖经验归纳。示例:「为降低物流成本,现有两种方案:①自建区域仓库(初期投入高,长期成本低);②与第三方合作(按需付费,灵活性高)。请根据 ROI 计算模型,对比 5 年内的总成本并推荐最优选择。」——这种题给推理模型,它会真的算;给通用模型,它可能给你一段「各有优劣」的废话。
分析需求:公式是「问题 + 数据/信息 + 分析方法」。推理模型触发因果链推导与假设验证,通用模型做表层总结或分类。示例要求「使用 ARIMA 模型并解释参数选择依据」,这就是在逼模型走推理路径。
创造性需求:公式是「主题 + 风格/约束 + 创新方向」。这里反过来——推理模型结合逻辑框架生成结构化创意,通用模型自由发散、依赖示例引导。写智能家居产品设计,要求「解决独居老人安全问题 + 结合传感器网络和 AI 预警 + 三种技术路线原型草图」,推理模型能给结构化方案,通用模型能给更有想象力的描述。
验证需求:公式是「结论/方案 + 验证方法 + 风险点」。推理模型自主设计验证路径并排查矛盾,通用模型只能简单确认。示例是验证「神经网络模型 A 优于传统方法 B」的论文结论,要求检查对照组偏差、重算 p 值——这种活通用模型容易糊弄,推理模型会认真走统计逻辑。
执行需求:公式是「任务 + 步骤约束 + 输出格式」。推理模型自主优化步骤、兼顾效率与正确性,通用模型严格按指令执行。代码转换类任务(C 转 Python、保持时间复杂度、用 numpy 优化)就是典型执行需求。
3.3 提示语设计的关键原则:别对推理模型「过度指导」
教程给的三条关键原则,本质是在纠正常见误用:
第一,优先按任务类型选模型,而非按热度。数学任务选推理模型,创意任务选通用模型,这条前面已经说透。
第二,推理模型简洁指令、聚焦目标、信任其内化能力;通用模型结构化、补偿性引导。这里有个反直觉点:对推理模型,你越「手把手教」,它可能越差——因为你的拆解步骤可能和它内化的推理路径冲突,反而限制了它的能力。
第三,避免两个极端:不要对推理模型用启发式提示(角色扮演可能干扰逻辑主线),也不要对通用模型「过度信任」(直接问复杂推理问题,需分步验证结果)。我一般会这么理解:推理模型像经验丰富的老手,你给目标就行;通用模型像聪明的通才,你得给脚手架。
4. 从文本生成到代码补全:能力矩阵背后的任务分流逻辑
4.1 文本生成与语义理解:通用模型的主场
教程把 DeepSeek 的能力铺得很开,但按前面的模型分野重新看,会发现每类能力其实有默认归属。文本生成这块——文章/故事/诗歌写作、营销文案、社交媒体内容、剧本对话设计——几乎全是通用模型的主场,因为这类任务要的是发散性和语言自然度,不是逻辑链。摘要与改写(长文本摘要、文本简化、多语言翻译)也偏通用模型,但「结构化生成」(表格、列表、日程安排)可以交给推理模型保证格式严谨。
自然语言理解与分析这块更微妙:语义分析、情感分析、意图识别、实体提取、文本分类、主题标签生成,这些任务通用模型做得不错,但涉及「知识推理」「逻辑问题解答」「因果分析」时,推理模型的优势就出来了。教程把「知识推理」和「逻辑问题解答(数学、常识推理)」单列,其实就是在暗示这条分流线。
4.2 代码生成与调试:推理模型的专精区
编程相关任务是推理模型最该上场的场景。代码生成(Python、JavaScript 片段)、代码调试(错误分析与修复建议)、代码性能优化提示、API 文档生成、代码库解释与示例生成——这些任务对逻辑严密性要求高,通用模型容易生成「语法对但逻辑错」的代码,推理模型的链式推理能显著降低这类错误。
教程里代码生成任务的提示语示例很能说明问题:对推理模型是「用 Python 实现快速排序」,简洁直接;对通用模型是「先解释快速排序原理,再写出代码并测试示例」,需要显式引导。这个差异背后是同一个逻辑:推理模型内化了「先想清楚再写」的过程,通用模型需要你用提示语把这个过程补出来。
4.3 联网搜索与文件读取:能力边界外的工程补位
教程提到 DeepSeek 支持联网搜索、深度思考模式、文件上传、扫描读取文件及图片文字。这些不是模型推理能力本身,而是工程层的补位——联网搜索解决知识时效性,文件读取解决上下文注入,OCR 解决多模态输入。理解这一点很重要:模型的「能力」和产品的「功能」是两层东西,提示语策略管的是模型层,功能层则是产品帮你把输入输出管道铺好。用的时候要分清,别把「联网搜到的信息」当成「模型自己知道的」,也别指望文件读取能替代你对文档结构的理解。
5. 避坑与排查:提示语实践中的五类典型翻车
5.1 现象:推理模型输出啰嗦、绕圈子
原因:对简单任务用了推理模型,或提示语里塞了角色扮演、启发式引导,干扰了它内化的推理主线。解决:简单任务换通用模型;推理模型的提示语砍掉角色设定和分步指导,只留目标和必要约束。
5.2 现象:通用模型解数学题跳步、答案对但推导断
原因:通用模型没有链式推理机制,直接问复杂推理问题它会「猜答案」。解决:显式要求分步思考、提供示例(CoT 提示),或干脆换推理模型。教程的原则是「通用模型需拆分问题、逐步追问」。
5.3 现象:创意任务用推理模型,输出干瘪没灵气
原因:推理模型专精逻辑密度高的任务,发散性创作是它的劣势领域。解决:创意写作、诗歌、故事换通用模型,并给风格/约束示例引导;推理模型只在需要「结构化创意」(带技术路线、约束条件的方案设计)时上场。
5.4 现象:提示语写得很长很细,效果反而变差
原因:过度约束。对推理模型,冗余拆解可能限制其能力;对通用模型,约束太死会压缩它的灵活性。解决:回到三层结构检查——指令是否清晰、上下文是否必要、期望是否合理。教程的「混合模式」思路是兼顾目标与细节,但避免过度约束。
5.5 现象:同一提示语换个模型效果天差地别
原因:提示语策略没跟着模型类型切换。推理模型要简洁、通用模型要补偿,这是两套打法。解决:建立「任务类型 → 模型 → 提示语风格」的映射习惯,别一套提示语打天下。教程里五类需求的适配表就是现成的对照清单。
6. 设计取舍:为什么「会用」和「用得好」之间隔着一条提示语工程
把这份教程读透,会发现它真正想回答的问题不是「DeepSeek 能干什么」,而是「当人人都会用 AI 时,你怎么用得更好更出彩」。这个问题的答案,藏在两个设计取舍里。
第一个取舍是模型专精 vs 通用。推理模型和通用模型的分野,本质是工程上「把能力做深」还是「把覆盖面做广」的选择。专精模型在目标领域显著更强,但需要用户自己判断任务类型、切换模型;通用模型更灵活,但专项任务要靠提示语补偿。这个取舍没有对错,只有匹配——教程的价值在于把匹配规则讲清楚了,而不是告诉你「哪个更好」。
第二个取舍是提示语的自由度 vs 可控性。指令驱动精准高效但限制模型自主优化,需求导向激发深层推理但需要清晰定义边界,混合模式平衡灵活性与可控性但要求更高。这三种策略对应不同的任务复杂度和用户成熟度。新手容易走「指令驱动」的极端,把 AI 当执行器;熟手会往「需求导向」走,把 AI 当协作者。这个迁移过程,就是「入门到精通」的实际含义。
验证方法上,我一般会这么做:拿到一个新任务,先判断它属于五类需求里的哪类,再按公式写提示语,然后分别丢给两类模型跑一遍,对比输出质量。跑多了会形成直觉——哪些任务根本不用试就知道该给谁。这个直觉不是玄学,是任务特征和模型能力矩阵反复对齐后的结果。
从那以后我每次写提示语前,都强制走一遍「任务分类 → 模型选择 → 提示语风格」这三步,不再凭感觉直接开问。翻车的次数明显少了,输出质量也稳定了。这份 104 页的教程把这条路径拆得足够细,从模型原理到提示语公式再到避坑清单,适合放在手边当对照手册翻。希望帮到你。
本文还有配套的精品资源,点击获取