简介这份PDF资料源自清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室面向希望系统掌握DeepSeek的开发者、内容创作者与AI学习者帮助读者从基础认知走向进阶应用。内容围绕DeepSeek是什么、能做什么、如何使用以及如何从入门到精通展开涵盖文本生成、语义理解、代码生成补全、联网搜索与深度思考等应用场景并深入对比推理模型与通用模型在数学推导、逻辑分析、创意写作等任务上的优势差异同时讲解提示语策略、任务需求匹配与模型选择原则。资源包共1个PDF文件大小约4.14MB结构清晰便于按章节检索学习。目前已有334人学习适合希望理解推理大模型与非推理大模型差异、掌握提示语设计方法并提升AI使用效率的读者参考。1. 一份被传疯了的 DeepSeek 手册到底值不值得花时间拆上周有个做后端的朋友甩给我一份 PDF标题写着“DeepSeek 从入门到精通”落款是某高校新闻与传播学院新媒体研究中心下面的一个实验室。他问我这东西是不是又一份把官网文档复制粘贴、加几张配图就敢叫“手册”的水货我花了一个晚上把整份材料从头到尾拆了一遍结论是——它确实不是技术文档但它解决了一个技术文档解决不了的问题当模型能力已经溢出的时候人该怎么组织自己的需求。这份材料的核心不在 DeepSeek 的 API 怎么调、参数怎么传那些东西官网写得更准。它真正花篇幅讲的是三件事推理模型和通用模型的差异、提示语策略怎么随模型类型切换、以及五类需求决策、分析、创造性、验证、执行各自该怎么表达。换句话说它是一份面向使用者的认知手册不是面向开发者的接口文档。如果你已经能熟练调 API 但总觉得模型输出“差口气”或者你团队里有人天天用 AI 但产出质量忽高忽低这份东西值得花两个小时过一遍。但如果你指望从里面找到 temperature 怎么设、top_p 调多少那你会失望——它压根不讲这些。2. 推理模型与通用模型先搞清楚你手里这把刀是砍柴的还是剔骨的2.1 两类模型的本质差异不在“强弱”而在“任务密度”材料里花了不少篇幅区分推理模型和通用模型这个区分是整份手册的地基。很多人下意识觉得推理模型就是“更强的模型”通用模型就是“弱一点的模型”这个认知偏差会直接导致你用错工具。推理模型比如 DeepSeek-R1 这类的训练目标里强化了逻辑链、数学推导和复杂问题拆解它在训练阶段就内化了“一步步想”的能力。你给它一个数学证明题它自动展开推理链你给它一个代码需求它自己会先想清楚边界条件再动手。但它的劣势也很明显发散性任务上反而容易“想太多”。你让它写一首诗它可能给你整出一段押韵的议论文。通用模型比如 GPT-3、BERT 那一类侧重语言生成、上下文理解和多轮对话它在创意写作、开放性问答上更灵活但遇到需要严格逻辑链的任务就容易跳步。你问它一个数学证明它可能直接给你结论而不展示推导过程。材料里有一张对比表把这两类模型的优劣势列得很清楚我把它简化成一张更直观的对照维度推理模型通用模型优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务诗歌创作、头脑风暴需要严格逻辑链的任务数学证明、因果推理提示语风格简洁指令信任其内化能力结构化引导补偿推理短板典型误用强行拆解步骤反而限制其推理直接问复杂推理题结果跳步这张表的关键结论是模型选择应该优先看任务类型而不是看模型热度。数学任务选推理模型创意任务选通用模型这个原则比“哪个模型跑分高”重要得多。2.2 提示语策略的切换逻辑从“下达指令”到“表达需求”搞清楚模型类型之后下一步是调整你和模型的交互方式。材料里把提示语策略分成了几种类型我按自己的理解重新梳理一下。对推理模型核心原则是“要什么直接说”。你不需要告诉它“先分析 A 再推导 B 最后得出结论”它自己会做这件事。你强行拆解步骤反而可能干扰它的推理主线。比如你要它写一个快速排序直接说“用 Python 实现快速排序输出带注释”就够了不需要加“先写递归函数再写分区逻辑”这种指导。对通用模型核心原则是“缺什么补什么”。它不会自动展开推理链所以你需要显式引导。同样是写快速排序你得说“先解释快速排序的原理再写出代码并给出一个测试示例”。材料里管这叫“补偿性引导”我觉得这个说法很准确——你不是在教它做事你是在补它缺的那块能力。材料里还提到了一个“快思慢想”的框架把模型分成了概率预测型快速反应和链式推理型慢速思考。这个分类和推理/通用的二分有重叠但不完全一样。概率预测型适合即时任务链式推理型适合复杂问题。理解这个差异的好处是你知道什么时候该等什么时候不该等。一个简单的翻译任务丢给推理模型它可能花三倍时间给你一个和通用模型差不多的结果这就是典型的资源错配。2.3 五类需求对应的提示语模板材料里把用户需求分成了五类决策需求、分析需求、创造性需求、验证需求、执行需求。每一类都有对应的表达公式和适配策略。这部分是我觉得整份手册里最实用的内容因为它把“怎么问”这件事从玄学变成了可操作的流程。我把它整理成一张可以直接抄的对照表需求类型表达公式推理模型适配通用模型适配决策需求目标 选项 评估标准要求逻辑推演和量化分析直接建议依赖经验归纳分析需求问题 数据/信息 分析方法触发因果链推导与假设验证表层总结或分类创造性需求主题 风格/约束 创新方向结合逻辑框架生成结构化创意自由发散依赖示例引导验证需求结论/方案 验证方法 风险点自主设计验证路径并排查矛盾简单确认缺乏深度推演执行需求任务 步骤约束 输出格式自主优化步骤兼顾效率与正确性严格按指令执行无自主优化这张表的用法很简单先判断你的需求属于哪一类再根据你用的模型类型选择对应的表达方式。比如你要做一个技术选型决策这是决策需求用推理模型就给它目标、选项和评估标准让它自己推演用通用模型就得把评估标准写得更细甚至给它一个参考案例。材料里给每个需求类型都配了实战示例我挑一个验证需求的例子展开说一下。原文的例子是“某论文结论说模型 A 优于传统方法 B请验证实验数据是否支持该结论、对照组设置是否有偏差、重新计算 p 值判断显著性”。这个例子的精妙之处在于它把验证需求拆成了三个可操作的子任务而且每个子任务都有明确的输出要求。你用推理模型的时候可以直接这么问它会自己设计验证路径用通用模型的话你可能需要把“怎么验证”也写进去比如“用 t 检验重新计算 p 值显著性水平设为 0.05”。3. 把手册里的策略落到实际工作流从单次对话到可复用模板3.1 从“每次重新想怎么问”到“建一套自己的提示语库”手册里讲了很多策略和原则但如果你每次用 AI 的时候都要重新想“这是决策需求还是分析需求”“该用推理模型还是通用模型”那这些策略反而成了负担。我的做法是把高频场景固化成模板用的时候直接填参数。比如我经常需要做技术方案对比这就是典型的决策需求。我给自己建了一个模板目标在 [场景] 下选择 [技术方案类型] 选项 A. [方案A描述] B. [方案B描述] C. [方案C描述] 评估标准[维度1]、[维度2]、[维度3] 请根据上述标准对比各方案给出量化评分和推荐结论。这个模板对推理模型直接可用它会自己展开推演。对通用模型我会在最后加一句“请先列出每个方案的优缺点再进行对比”。这个模板我用了大概两个月最大的感受是它把“想清楚自己要什么”这件事前置了。以前我经常是边问边想问了三轮才搞清楚自己到底要什么现在填模板的过程就是理清需求的过程。3.2 代码生成场景的提示语差异一个具体例子材料里提到了代码生成场景下推理模型和通用模型的提示语差异我用自己的实际经验补充一下。用推理模型生成代码我的提示语通常长这样# 提示语示例推理模型 用 Python 实现一个带过期时间的 LRU 缓存。 要求 1. 支持 get 和 put 操作 2. 过期时间可配置 3. 线程安全 4. 输出完整代码和单元测试 推理模型会自动处理很多细节它知道 LRU 需要双向链表加哈希表知道线程安全要加锁知道过期时间需要额外的数据结构。你不需要告诉它这些它自己会想。同样的任务用通用模型提示语就得写得更细# 提示语示例通用模型 请按以下步骤实现一个带过期时间的 LRU 缓存 1. 用 OrderedDict 或双向链表 字典实现 LRU 淘汰逻辑 2. 每个缓存项记录插入时间戳 3. 用 threading.Lock 保证线程安全 4. get 操作检查是否过期过期则删除并返回 None 5. put 操作检查容量超限则淘汰最久未使用的项 6. 写三个单元测试正常读写、过期删除、并发访问 输出完整代码。 这个差异的本质是推理模型内化了“怎么做”你只需要说“做什么”通用模型需要你同时说清楚“做什么”和“怎么做”。材料里把这个原则总结为“推理模型要什么直接说通用模型缺什么补什么”我觉得这个总结比我见过的很多提示语教程都更一针见血。3.3 多轮对话中的策略切换什么时候该换模型实际工作中很少是一次对话就解决问题的多轮对话里经常需要切换模型。材料里提到了多轮对话场景下推理模型和通用模型的适配策略我补充一个自己的判断标准。如果对话进入“深挖”阶段——比如你在排查一个 bug需要逐步缩小范围、验证假设——这时候推理模型更合适因为它能保持逻辑链的连贯性。如果对话进入“发散”阶段——比如你在做头脑风暴需要尽可能多的想法——这时候通用模型更合适因为它不会过度约束在逻辑框架里。我的一般做法是第一轮用通用模型快速了解问题全貌第二轮切推理模型深入分析第三轮如果需要创意方案再切回通用模型。这个切换节奏不是固定的但核心原则是让模型类型匹配当前的思维模式而不是从头到尾用一个模型。4. 避坑那些我踩过的提示语翻车现场4.1 对推理模型用角色扮演结果逻辑主线被带偏现象我让推理模型“扮演一个资深架构师”来评审一段代码结果它花了大段篇幅描述“作为架构师我会关注哪些方面”真正对代码的分析反而很浅。原因角色扮演属于启发式提示它会激活模型的“表演”模式干扰推理模型原本的逻辑主线。推理模型的优势在于自主展开推理链你给它一个角色它反而把精力花在“演好这个角色”上。解决对推理模型直接给任务不要给角色。要评审代码就直接说“评审以下代码指出三个最严重的问题并给出修复方案”。如果确实需要特定视角用约束条件代替角色扮演比如“从性能角度评审以下代码”。4.2 对通用模型直接问复杂推理题结果跳步严重现象我用通用模型问一个多步数学证明它直接给了结论中间推导过程跳了好几步我根本没法验证。原因通用模型没有内化链式推理能力你不显式要求它分步它就按概率预测最可能的输出——而最可能的输出往往是“看起来像答案的东西”不是真正的推导过程。解决对通用模型必须显式要求分步思考。我的固定句式是“请分三步推导每一步写出依据”。如果任务特别复杂我会先让它列出解题计划确认计划合理后再让它执行。4.3 提示语里塞了太多约束模型反而不知道重点现象我写了一个很长的提示语列了七八条要求结果模型只满足了前三条后面的全忽略了。原因提示语过长时模型的注意力会被分散。材料里提到推理模型“无需逐步指导”其实通用模型也一样——约束太多等于没有约束。解决把约束按优先级排序只保留最核心的三条。如果确实有很多要求拆成多轮对话每轮聚焦一个方面。我现在的习惯是单次提示语不超过 200 字超过就拆。4.4 用推理模型做创意发散输出过于“正确”但无趣现象我让推理模型想十个产品 slogan它给的十个都逻辑通顺但毫无记忆点像是一个模子刻出来的。原因推理模型的训练目标里强化了逻辑性和正确性这恰恰是创意发散的天敌。它会在“合理”的范围内搜索而不是在“有趣”的范围内搜索。解决创意任务换通用模型或者在提示语里明确要求“打破常规”“允许不合理”。我试过在推理模型的提示语里加“不要考虑逻辑性优先考虑记忆点”效果会好一些但还是不如直接用通用模型。4.5 忽略模型版本差异同一套提示语换个模型就失效现象我为一款推理模型调好了一套提示语换到另一款推理模型上效果差了很多。原因不同模型的训练数据、强化学习策略、甚至 tokenizer 都不一样同一套提示语在不同模型上的表现可能有显著差异。材料里虽然没展开讲这一点但从它区分推理/通用的逻辑可以推导出来模型分类是粗粒度的具体到每个模型还需要微调。解决换模型时先做小规模测试用三到五个典型任务对比输出质量再决定是否需要调整提示语。我一般会保留一个“提示语测试集”换模型时跑一遍心里有数再大规模用。5. 进阶把提示语策略变成团队可复用的资产5.1 建一个团队级的提示语模板库个人用提示语靠记忆和习惯就够了。但团队里每个人用 AI 的方式不一样产出质量方差很大。我的做法是建一个共享的提示语模板库按任务类型分类每个人都可以往里加模板但加之前要经过至少两个人的验证。模板库的结构大概是这样的prompts/ ├── decision/ │ ├── tech-selection.md │ └── vendor-comparison.md ├── analysis/ │ ├──># 提示语测试脚本示例 test_cases [ {input: 用 Python 实现二分查找, expected: 包含边界条件处理}, {input: 分析这段代码的时间复杂度, expected: 给出 Big-O 推导过程}, {input: 设计一个短链接系统, expected: 包含存储方案和哈希策略}, ] for case in test_cases: result call_model(prompt_template.format(case[input])) # 人工检查 result 是否满足 expected print(fInput: {case[input]}) print(fOutput: {result[:200]}...) print(---)这个脚本不复杂但它把“提示语好不好用”从主观感受变成了可检查的流程。我一般会在换模型、改提示语、或者团队新人加入的时候跑一遍。5.3 一个我常用的提示语调试技巧最后分享一个我自己的习惯当模型输出不理想的时候我不会直接改提示语而是先问模型“你理解的任务是什么”。这个技巧来自材料里“验证需求”的思路——先确认理解一致再检查执行。具体操作是在提示语末尾加一句“请先用一句话复述你理解的任务再开始执行”。如果模型复述的任务和你的预期不一致说明提示语本身有歧义改提示语比反复调整输出更有效。如果复述一致但输出不对那可能是模型能力边界的问题需要考虑换模型或拆任务。这个习惯帮我省了很多来回调试的时间。从那以后我每次写重要提示语都会强制走一遍“复述确认”的流程。希望帮到你。本文还有配套的精品资源点击获取