简介这份PDF资料是清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队出品的DeepSeek教程PPT共104页面向希望系统掌握DeepSeek的开发者、内容创作者与AI初学者帮助读者从入门走向精通。压缩包内仅含1个PDF文件大小约5.07MB便于直接阅读与随身查阅。目前已有664人学习下载具备一定的参考热度。内容围绕DeepSeek是什么、能做什么、如何使用三条主线展开涵盖文本创作、摘要改写、多语言翻译、代码生成与调试、语义分析与知识推理等应用场景并重点对比推理模型与非推理模型在优势领域、性能本质、决策能力与伦理问题上的差异给出提示语策略与任务匹配建议如数学证明宜用推理模型、创意写作宜用通用模型。读者可借此建立模型选型与提示语设计的完整认知框架快速上手官方平台并提升实际使用效果。1. 一份 104 页 PPT 拆完我才明白多数人用 DeepSeek 的方式从第一步就错了上周帮一个做运营的朋友看他的 DeepSeek 对话记录三十多条提问清一色是“帮我写个文案”“帮我改改这段话”。他说感觉这工具“也就那样”写出来的东西一股 AI 味。我让他把同一个需求换成带约束条件的结构化提示语再试一次输出质量直接上了一个台阶。问题不在模型在于他把一个能跑复杂推理的工具当成了高级输入法。这份 104 页的教程 PPT 来自一个高校新媒体研究团队的整理覆盖了 DeepSeek 的定位、能力边界、推理模型与通用模型的差异、提示语策略和五类需求的表达公式。它不是 API 文档也不是参数手册而是一份“怎么把模型用对”的方法论材料。适合两类人一是日常用 DeepSeek 但总觉得输出不够精准的从业者二是想把提示语设计从“凭感觉”变成“有章法”的开发者。下面我按自己拆读的顺序把里面真正能落地的部分拎出来配上可复现的操作和踩过的坑。2. 推理模型与通用模型选错模型提示语写得再好也白搭2.1 两类模型的本质差异与选型判断PPT 里花了不少篇幅讲推理模型和通用模型的区别这个点值得放在最前面说因为选型错了后面所有提示语技巧都是白费。DeepSeek-R1 属于推理模型它的训练目标偏向数学推导、逻辑分析、代码生成和复杂问题拆解内部已经内化了链式推理的逻辑。通用模型则侧重文本生成、创意写作、多轮对话和开放性问答擅长多样性高的任务。关键判断标准不是“哪个更强”而是任务类型。数学证明、逻辑推理、代码调试这类逻辑密度高的任务推理模型显著占优诗歌创作、营销文案、开放式头脑风暴这类发散性任务通用模型更灵活。PPT 里有一句话我印象很深推理模型并非全面更强仅在其训练目标领域显著优于通用模型。很多人默认“新模型一定更好”拿推理模型去写创意文案结果输出干巴巴的反过来怪模型不行。实际操作中我一般这样判断如果任务有明确的正确性标准算得对不对、代码跑不跑得通、逻辑链条是否自洽走推理模型如果任务是“好不好看”“有没有创意”“像不像人话”走通用模型。混合任务就拆开先用推理模型做结构化分析再用通用模型做表达润色。2.2 快思慢想概率预测与链式推理的效能取舍PPT 用“快思慢想”这个框架来解释两类模型的运算原理差异这个类比比单纯说“推理模型更强”有用得多。快速反应模型基于概率预测通过大量数据训练来快速预测可能的答案响应速度快、算力成本低适合即时反馈类任务。慢速思考模型基于链式思维逐步推理问题的每个步骤来得到答案算力成本高但能处理多步骤的复杂问题。这个差异直接影响到使用策略。推理模型因为已经内化了推理逻辑提示语反而要简洁只需明确任务目标和需求不需要逐步指导。强行给它拆解步骤可能限制它自身的推理能力。通用模型则相反需要显式引导推理步骤通过 CoT 提示或者提供示例来补偿能力短板。PPT 里给了一个很直白的对照对推理模型说“证明勾股定理”就够了对通用模型则要说“请分三步推导勾股定理参考1. 画直角三角形……”。我自己的血泪经验是早期用推理模型时习惯性地写“先做 A 再做 B 然后做 C”结果模型被我的步骤框死反而漏掉了它自己能想到的更优路径。后来改成只给目标和约束让它自己规划步骤代码生成和逻辑分析的质量明显提升。这个反直觉的点是这份 PPT 里最值得反复看的段落之一。2.3 提示语策略的对照表与实操改法PPT 把提示语策略按模型类型做了对照我整理成下面这张表方便直接对照改自己的提问习惯任务类型适用模型提示语侧重点有效示例要避免的写法数学证明推理模型直接提问不拆步“证明勾股定理”“先画图再列公式”数学证明通用模型显式要求分步给示例“请分三步推导参考1. 画直角三角形……”直接提问容易跳过关键步骤创意写作推理模型鼓励发散设定角色风格“以海明威的风格写一个冒险故事”过度约束逻辑按时间顺序列创意写作通用模型明确约束目标“写一个包含‘量子’和‘沙漠’的短篇不超过 200 字”开放式“自由创作”代码生成推理模型简洁需求信任逻辑“用 Python 实现快速排序”分步指导“先写递归函数”代码生成通用模型细化步骤明确输入输出“先解释原理再写代码并测试示例”模糊需求“写个排序代码”多轮对话通用模型自然交互不结构化“你觉得人工智能的未来会怎样”强制逻辑链条“分三点回答”逻辑分析推理模型直接抛复杂问题“分析电车难题中的功利主义与道德主义冲突”添加主观引导“你认为哪种对”这张表的用法很简单先判断任务类型再选模型最后按对应列写提示语。我拿代码生成那行做过对比测试同一个“快速排序”需求对推理模型写“先写递归函数再写分区逻辑”输出反而比只写“用 Python 实现快速排序带注释”更啰嗦且容易出错。而对通用模型只写一句“写个排序代码”它经常给出一个没处理边界条件的版本。这个对照不是玄学是两类模型训练目标差异的直接体现。3. 五类需求的表达公式把“下达指令”换成“表达需求”3.1 从指令驱动到需求导向的三种策略PPT 里把提示语策略分成了三种类型指令驱动、需求导向、混合模式。指令驱动是直接给出明确步骤或格式要求适合简单任务和需要快速执行的场景优势是结果精准高效风险是限制了模型的自主优化空间。需求导向是描述问题背景与目标由模型规划解决路径适合复杂问题和需要模型自主推理的场景能激发深层推理但需要清晰定义需求边界。混合模式结合需求描述与关键约束条件平衡灵活性与可控性。这个分类的价值在于它解释了为什么同一句话对不同任务效果差异巨大。简单任务用指令驱动没问题但复杂任务如果还用指令驱动等于把模型的推理能力锁死了。我一般会这样切换任务步骤明确、结果格式固定的用指令驱动任务目标清楚但路径不唯一的用需求导向既要方向对又要结果可控的用混合模式。举个实际改写的例子。原始提问“帮我优化一下用户登录流程。”这是典型的指令驱动但目标模糊。改成需求导向“我需要优化用户登录流程请分析当前瓶颈并提出 3 种方案。”模型会先做瓶颈分析再给方案。再改成混合模式“设计一个登录流程优化方案要求包含短信验证和第三方登录两种方式且首屏加载时间控制在 1 秒内。”这样既有方向又有约束输出更贴近可落地的方案。3.2 五类需求的公式化表达与代码化落地PPT 把需求分成决策、分析、创造性、验证、执行五类每类给了表达公式和适配策略。这部分是整份材料里最能直接抄作业的内容我按自己的理解整理成可执行的模板# 五类需求的提示语模板按任务类型直接套用 prompts { # 决策需求目标 选项 评估标准 decision: ( 为降低物流成本现有两种方案 ①自建区域仓库初期投入高长期成本低 ②与第三方合作按需付费灵活性高。 请根据 ROI 计算模型对比 5 年内的总成本并推荐最优选择。 ), # 分析需求问题 数据/信息 分析方法 analysis: ( 分析近三年新能源汽车销量数据附 CSV说明 ①增长趋势与政策关联性 ②预测下一年市占率需使用 ARIMA 模型并解释参数依据。 ), # 创造性需求主题 风格/约束 创新方向 creative: ( 设计一款智能家居产品要求 ①解决独居老人安全问题 ②结合传感器网络和 AI 预警 ③提供三种不同技术路线的原型草图说明。 ), # 验证需求结论/方案 验证方法 风险点 verify: ( 以下是某论文结论神经网络模型 A 优于传统方法 B。请验证 ①实验数据是否支持该结论 ②检查对照组设置是否存在偏差 ③重新计算 p 值并判断显著性。 ), # 执行需求任务 步骤约束 输出格式 execute: ( 将以下 C 语言代码转换为 Python要求 ①保持时间复杂度不变 ②使用 numpy 优化数组操作 ③输出带时间测试案例的完整代码。 ), }这段模板的逻辑是按需求类型匹配表达结构。决策需求的关键是给出选项和评估标准让模型做权衡而不是拍脑袋分析需求要附上数据和分析方法触发因果链推导创造性需求要给约束但不能给死留出发散空间验证需求要指定验证路径和风险点避免模型只做表面确认执行需求要明确步骤约束和输出格式保证结果可直接用。参数上我一般会把“三种方案”“5 年内”“不超过 200 字”这类量化约束写死模型对数字约束的遵守度明显高于模糊描述。3.3 提示语的基本结构与类型选择PPT 把提示语的基本结构拆成三部分指令、上下文、期望。指令明确告诉模型执行什么任务上下文提供背景信息帮助理解期望表达对输出的要求和预期。这个结构看起来简单但多数人的提问只包含了指令缺了上下文和期望模型只能靠猜。提示语类型上PPT 列了指令型、问答型、角色扮演型、创意型、分析型、多模态六种。角色扮演型在推理模型上要慎用PPT 明确提醒“不要对推理模型使用启发式提示如角色扮演可能干扰其逻辑主线”。我试过让推理模型“扮演一位资深架构师”来分析系统瓶颈输出确实带上了角色口吻但逻辑链条反而变松了。换成直接描述问题背景和目标分析深度明显更好。通用模型则相反角色扮演能有效引导风格和视角写文案时给个“你是某消费品牌的文案策划”比干说“写个文案”强不少。4. 文本生成与代码辅助的落地场景哪些活能交给它哪些得自己兜底4.1 文本生成的四条产线与质量边界PPT 把文本生成拆成四条线文本创作文章、故事、诗歌、营销文案、社交媒体内容、剧本对话、摘要与改写长文本摘要、文本简化、多语言翻译与本地化、结构化生成表格、列表、日程安排、菜谱、代码注释与文档撰写。这四条线的共同点是“有输入有输出、可校验”适合交给模型做初稿或批量处理。但质量边界要清楚。营销文案和社交媒体内容模型能快速产出多个版本供筛选但品牌调性和合规红线得人来把关。长文本摘要模型对结构清晰的报告摘要质量不错但对逻辑跳跃的材料容易漏掉关键论点。多语言翻译通用模型在常见语种上表现稳定小语种和行业术语密集的文本建议人工复核。结构化生成是模型比较稳的场景给清楚字段和格式要求表格和列表的完整度很高。我自己的习惯是批量初稿交给模型终稿必须过一遍人工。尤其是对外发布的文案模型偶尔会生成看似合理但事实错误的表述这个黑匣子不打开检查翻车是迟早的事。4.2 代码生成与调试的提示语写法代码相关的能力是 PPT 里着墨较多的部分覆盖代码生成、代码调试、技术文档处理三个方向。代码生成包括根据需求生成代码片段Python、JavaScript 等、自动补全与注释生成代码调试包括错误分析与修复建议、代码性能优化提示技术文档处理包括 API 文档生成、代码库解释与示例生成。实际用下来代码生成的质量高度依赖提示语的约束精度。下面是我常用的一个代码任务模板# 代码生成任务的提示语模板适配推理模型 prompt 用 Python 实现一个带过期时间的 LRU 缓存要求 1. 支持 get 和 put 操作时间复杂度 O(1) 2. 过期时间按秒级精度过期条目自动清理 3. 输出完整可运行代码包含类型注解和关键行注释 4. 附一个简单的测试用例验证过期和淘汰逻辑。 这个模板的关键是把“时间复杂度 O(1)”“秒级精度”“类型注解”“测试用例”这些约束写进需求而不是事后让模型补。推理模型对这类结构化约束的遵守度很高生成完基本能直接跑。如果只写“写个 LRU 缓存”经常拿到一个没处理过期、也没测试的版本还得来回追问。代码调试场景我一般会把报错信息和相关代码段一起贴进去并明确要求“先分析错误原因再给修复方案最后说明修改点”。这个顺序能逼模型走完分析链路而不是直接甩一个改好的版本让你猜它改了哪。技术文档生成则适合用通用模型给清楚函数签名和参数说明让它按固定格式输出 API 文档比手写快很多。4.3 自然语言理解与分析的适用场景PPT 里自然语言理解与分析部分覆盖语义分析、语义解析、情感分析、意图识别、知识推理、实体提取、文本分类、因果分析。这些能力在客服对话分析、用户反馈归类、新闻主题标签生成等场景有直接用处。我拿情感分析做过一个小测试给一批用户评论让模型按“正面/负面/中性”分类并给出判断依据。推理模型在带反讽和隐含否定的评论上判断更准因为它会走一遍语义推理通用模型在直白表达上速度更快。实体提取场景给清楚要提取的实体类型人名、地点、事件、时间和输出格式JSON 或表格准确率明显高于开放式提问。这类任务的共性是“有明确判断标准”适合用推理模型加结构化输出约束。5. 避坑与排查五个我实际踩过的坑5.1 对推理模型过度拆解步骤反而限制输出质量现象用推理模型做逻辑分析时按习惯写了“第一步分析 A第二步分析 B第三步得出结论”结果输出机械地跟着步骤走漏掉了步骤之外的关联因素。原因推理模型内部已内化推理逻辑外部强行拆解会覆盖它自身的推理路径把它降级成一个按指令执行的通用模型。解决只给任务目标和约束条件让模型自己规划步骤。需要控制输出结构时用“输出需包含以下要素”代替“按以下步骤执行”。5.2 对通用模型直接抛复杂推理问题结果看似合理实则漏洞百出现象拿通用模型做数学证明或多步逻辑推理输出格式漂亮、语气笃定但中间步骤有跳步或错误假设。原因通用模型侧重语言生成和上下文理解缺乏推理模型那样的链式推理能力遇到严格逻辑链任务容易“编”出一个看起来对的答案。解决复杂推理任务换推理模型必须用通用模型时显式要求分步思考并提供示例且对每一步做人工校验。5.3 提示语只有指令没有上下文和期望输出靠猜现象提问“帮我写个产品介绍”输出泛泛而谈跟产品实际卖点对不上。原因提示语缺了上下文产品是什么、面向谁和期望篇幅、风格、必须包含的卖点模型只能按通用模板生成。解决按“指令 上下文 期望”三段式补全。例如“为某智能家居产品写一段电商详情页介绍面向 30 至 45 岁有老人家庭突出安全预警功能200 字以内语气平实不夸张”。5.4 把量化约束写在事后追问里而不是首次提问中现象首次提问没写字数、格式、数量要求输出后再追问“改成 200 字”“输出成表格”来回多轮效率低且容易改乱。原因模型对首次提问中的约束遵守度最高事后追加约束相当于在已生成内容上打补丁一致性容易丢失。解决把字数、格式、数量、必须包含的要素一次性写进首次提问。我现在的习惯是提问前先列一个约束清单确认都写进去了再发送。5.5 拿模型输出直接对外发布不做事实核查现象模型生成的文案或分析里出现看似合理但实际错误的数据、引用或结论直接发布后被发现。原因模型基于概率生成内容流畅度和合理性不等于事实正确性尤其在数据、引用、专业结论上存在编造风险。解决对外内容必须人工核查事实和数据涉及专业结论的要求模型给出推理依据并逐条验证。这个后悔药没有捷径只能靠流程卡住。6. 进阶用法用“模型选择 提示语分层”搭一套可复用的工作流把前面几章串起来我目前稳定在用的一套工作流分三层。第一层是任务分类拿到需求先判断是逻辑密集型还是发散型逻辑密集型走推理模型发散型走通用模型混合型拆成两段。第二层是提示语组装按“指令 上下文 期望”三段式写再从五类需求模板里选对应结构把量化约束一次性写全。第三层是输出校验逻辑类任务检查推理链是否自洽创意类任务检查是否符合约束对外内容做事实核查。这套流程里有一个容易被忽略的技巧同一任务用两个模型交叉验证。比如一段关键代码先用推理模型生成再用通用模型做代码审查提示语写“检查以下代码的边界条件处理和潜在 bug”两边结论不一致的地方就是需要人工重点看的地方。这个做法比单模型自检靠谱得多因为两个模型的训练目标不同盲区不容易重叠。再给一个提示语分层的具体写法以“分析一份用户反馈数据并给出改进建议”为例# 分层提示语先分析后建议两段式输出 prompt 背景某产品近一个月的用户反馈数据附 CSV含评分、评论文本、反馈渠道。 任务分两步 第一步对评论文本做情感分析和主题归类输出每个主题的反馈数量和典型原话 第二步基于第一步结果按影响面排序给出 3 条改进建议每条建议注明依据的反馈主题。 约束情感分析需区分正面、负面、中性主题归类不超过 5 类建议需可落地不写空话。 这个写法的关键是“分两步”而不是“分两步执行第一步先做 A 再做 B 再做 C”。前者给模型留了在每步内部自主规划的空间后者容易把分析过程框死。我对比过两种写法分两步的版本在主题归类的完整性上更好因为它允许模型自己决定情感分析的细粒度。最后说一个验证方法把同一批提示语分别喂给推理模型和通用模型记录输出差异差异大的任务类型就是选型敏感区后续遇到同类任务优先按差异结论选模型。这个习惯我坚持了几个月现在基本能做到拿到任务就判断出该走哪条路少走了很多“先试错再换模型”的弯路。从那以后我每次写提示语前都强制走一遍“任务分类、三段式组装、约束清单核对”这三步希望这套流程也能帮到你。本文还有配套的精品资源点击获取