简介：这份PDF资料源自清华大学新闻与传播学院新媒体研究中心团队，面向希望系统掌握DeepSeek大模型的开发者、学生与职场用户，帮助读者从基础认知走向进阶应用。内容围绕DeepSeek是什么、能做什么、如何使用与如何精通四条主线展开，涵盖文本生成、语义理解、代码生成补全等应用场景，并重点辨析推理大模型与通用模型在优势领域、性能本质上的差异，以及两类模型在提示语设计策略上的关键原则，如推理模型宜简洁指令、通用模型需显式引导推理步骤。资源包共1个PDF文件，约5.5MB，结构清晰，便于按章节查阅与对照学习。目前已有311人学习，适合作为大模型入门与提示语设计的参考读本。
1. 从一张能力地图说起：DeepSeek 到底该怎么学
很多人第一次接触 DeepSeek，会把它当成“又一个聊天框”，问几句、写两段，就以为摸清了。真正梳理下来会发现，这份资料的价值不在“教你点按钮”，而在它把大模型的使用拆成了一条清晰的能力链：先分清模型类型，再理解推理模型与通用模型的差异，然后落到提示语设计，最后用需求表达公式把任务说清楚。这条链上任何一环断了，用起来都会觉得“它好像不太行”，其实是自己没给对输入。
这份笔记适合两类人：一类是正在系统学大模型应用、想把零散经验串成体系的人；另一类是备考或复习、需要一张能查漏补缺地图的人。下面按“模型认知 → 提示语策略 → 需求表达 → 易错点 → 复习清单”的顺序展开，重点放在那些真正决定输出质量的分岔口上。
2. 模型认知：推理模型与通用模型的分水岭
2.1 两类模型到底差在哪
大模型并不是越新越强、越大越全能。按训练目标和能力侧重，可以粗分成两类：推理模型和通用模型。推理模型在传统语言模型基础上强化了推理、逻辑分析和决策能力，通常借助强化学习、神经符号推理、元学习等技术，擅长数学推导、逻辑分析、代码生成和复杂问题拆解。通用模型则侧重语言生成、上下文理解和自然语言处理，适合文本创作、创意写作、多轮对话和开放性问答。
这个区分不是学术分类游戏，它直接决定你该用哪个模型、该怎么写提示语。用通用模型硬啃数学证明，它可能跳过关键步骤；用推理模型写诗，它反而可能被逻辑主线绑住，发散不出来。
| 维度 | 推理模型 | 通用模型 |
|---|---|---|
| 优势领域 | 数学推导、逻辑分析、代码生成、复杂问题拆解 | 文本生成、创意写作、多轮对话、开放性问答 |
| 劣势领域 | 发散性任务（如诗歌创作） | 需要严格逻辑链的任务（如数学证明） |
| 性能本质 | 专精于逻辑密度高的任务 | 擅长多样性高的任务 |
| 强弱判断 | 并非全面更强，仅在其训练目标领域显著优于通用模型 | 通用场景更灵活，但专项任务需依赖提示语补偿能力 |
提示：模型选择的第一原则是“按任务类型选”，不是“按热度选”。数学任务选推理模型，创意任务选通用模型，这条判断比记任何参数都实用。
2.2 快思慢想：概率预测与链式推理
理解模型差异，还有一个更底层的视角：快思与慢想。基于概率预测的模型像“快速反应”，通过大量数据训练快速预测可能答案，响应快、算力成本低，擅长结构化和定义明确的问题；基于链式思维（Chain-of-Thought）的模型像“慢速思考”，逐步推理问题的每个步骤，算力成本高，但能处理多维度、非结构化问题，并给出创造性解决方案。
CoT 链式思维的出现，把大模型明确分成了这两类。前者适合快速反馈、处理即时任务；后者通过推理解决复杂问题。这个划分的意义在于：它解释了为什么同一个问题，换个模型问，结果可能天差地别。不是模型“笨”，而是你让快思模型去干了慢想的活，或者反过来。
梳理下来会发现，很多使用翻车的根源，是把“快思”和“慢想”混为一谈。比如让通用模型直接做复杂逻辑推理，它靠概率预测快速给一个看似合理的答案，但中间步骤经不起推敲；又比如让推理模型做发散创意，它每一步都要讲逻辑，反而束手束脚。认清这条分水岭，后面的提示语策略才有落脚点。
3. 提示语策略：推理模型和通用模型要分开写
3.1 提示语的基本结构与类型
提示语是用户输入给 AI 系统的指令或信息，用于引导 AI 生成特定输出或执行特定任务。它的基本结构包括三部分：指令（明确告诉 AI 要执行什么任务）、上下文（提供背景信息，帮助准确理解）、期望（明确或隐含地表达对输出的要求）。三者缺一，输出就容易跑偏。
按用途，提示语可以分成几类：指令型（直接告诉任务）、问答型（提出问题期望答案）、角色扮演型（要求扮演特定角色）、创意型（引导创意写作）、分析型（要求对信息分析推理）、多模态提示语（结合文本、图像等输入）。类型本身没有优劣，关键是和模型类型匹配。
指令：将以下内容翻译为法语 上下文：这是一段产品介绍，面向法国市场 期望：保持正式语气，术语准确，不超过 200 字上面这个结构看起来简单，但它把“做什么、在什么背景下做、做到什么程度”一次说清。很多人写提示语只写指令，上下文和期望全靠模型猜，猜对了是运气，猜错了就怪模型不行。
3.2 两类模型的提示语差异
这是整份资料里最值得反复看的部分。推理模型的提示语要更简洁，只需明确任务目标和需求，因为它已经内化了推理逻辑，无需逐步指导，模型会自动生成结构化推理过程。强行拆解步骤，反而可能限制它的能力。通用模型则相反，需要显式引导推理步骤，比如通过 CoT 提示，否则可能跳过关键逻辑；它依赖提示语补偿能力短板，比如要求分步思考、提供示例。
| 任务类型 | 适用模型 | 提示语侧重点 | 有效提示示例 | 需避免的提示策略 |
|---|---|---|---|---|
| 数学证明 | 推理模型 | 直接提问，无需分步引导 | “证明勾股定理” | 冗余拆解（如“先画图，再列公式”） |
| 数学证明 | 通用模型 | 显式要求分步思考，提供示例 | “请分三步推导勾股定理，参考：1. 画直角三角形…” | 直接提问（易跳过关键步骤） |
| 创意写作 | 推理模型 | 鼓励发散性，设定角色/风格 | “以海明威的风格写一个冒险故事” | 过度约束逻辑（如“按时间顺序列出”） |
| 创意写作 | 通用模型 | 需明确约束目标，避免自由发挥 | “写一个包含‘量子’和‘沙漠’的短篇小说，不超过 200 字” | 开放式指令（如“自由创作”） |
| 代码生成 | 推理模型 | 简洁需求，信任模型逻辑 | “用 Python 实现快速排序” | 分步指导（如“先写递归函数”） |
| 代码生成 | 通用模型 | 细化步骤，明确输入输出格式 | “先解释快速排序原理，再写出代码并测试示例” | 模糊需求（如“写个排序代码”） |
| 多轮对话 | 通用模型 | 自然交互，无需结构化指令 | “你觉得人工智能的未来会怎样？” | 强制逻辑链条（如“分三点回答”） |
| 逻辑分析 | 推理模型 | 直接抛出复杂问题 | “分析‘电车难题’中的功利主义与道德主义冲突” | 添加主观引导（如“你认为哪种对？”） |
这张表建议直接抄进复习笔记。它把“什么模型配什么提示语”落到了具体例子上，比背原则管用。最容易忽略的是最后两列：很多人只记“该怎么做”，不记“不该怎么做”，结果踩的都是同一个坑。
3.3 从下达指令到表达需求
提示语的进阶，是从“下达指令”转向“表达需求”。指令驱动是直接给出明确步骤或格式要求，适合简单任务、需快速执行的场景，但限制了模型自主优化空间；需求导向是描述问题背景与目标，由模型规划解决路径，适合复杂问题、需模型自主推理的场景，但需要清晰定义需求边界；混合模式结合需求描述与关键约束条件，兼顾目标与细节，平衡灵活性与可控性，但要避免过度约束。
这个转变的本质，是把模型从“执行器”当成“协作者”。你给的不是一串命令，而是一个带背景、带目标、带边界的需求。模型的能力越强，这种表达方式的天花板越高。反过来，如果一直停留在指令驱动，用推理模型也发挥不出它的推理优势。
4. 需求表达：五类任务的公式化拆解
4.1 五类需求与对应公式
把需求说清楚，是有公式可循的。资料里把常见需求分成五类，每类都有对应的表达结构和适配策略。
| 需求类型 | 特点 | 需求表达公式 | 推理模型适配策略 | 通用模型适配策略 |
|---|---|---|---|---|
| 决策需求 | 需权衡选项、评估风险、选择最优解 | 目标 + 选项 + 评估标准 | 要求逻辑推演和量化分析 | 直接建议，依赖模型经验归纳 |
| 分析需求 | 需深度理解数据/信息、发现模式或因果关系 | 问题 + 数据/信息 + 分析方法 | 触发因果链推导与假设验证 | 表层总结或分类 |
| 创造性需求 | 需生成新颖内容（文本/设计/方案） | 主题 + 风格/约束 + 创新方向 | 结合逻辑框架生成结构化创意 | 自由发散，依赖示例引导 |
| 验证需求 | 需检查逻辑自洽性、数据可靠性或方案可行性 | 结论/方案 + 验证方法 + 风险点 | 自主设计验证路径并排查矛盾 | 简单确认，缺乏深度推演 |
| 执行需求 | 需完成具体操作（代码/计算/流程） | 任务 + 步骤约束 + 输出格式 | 自主优化步骤，兼顾效率与正确性 | 严格按指令执行，无自主优化 |
这张表的价值在于，它把“我该怎么问”变成了“我先判断这是哪类需求”。判断对了，公式一套，提示语自然成形。判断错了，比如把决策需求当成执行需求来问，模型只会给你一个执行方案，而不是帮你权衡。
4.2 公式怎么落到实战
公式不是摆设，落到具体场景才有意义。决策需求的实战写法是：“为降低物流成本，现有两种方案：①自建区域仓库（初期投入高，长期成本低）；②与第三方合作（按需付费，灵活性高）。请根据 ROI 计算模型，对比 5 年内的总成本并推荐最优选择。”这里目标、选项、评估标准齐全，模型才有得算。
分析需求的写法是：“分析近三年新能源汽车销量数据（附 CSV），说明：①增长趋势与政策关联性；②预测 2025 年市占率，需使用 ARIMA 模型并解释参数选择依据。”数据、方法、输出要求都给了，模型不会只给你一段泛泛的趋势描述。
创造性需求的写法是：“设计一款智能家居产品，要求：①解决独居老人安全问题；②结合传感器网络和 AI 预警；③提供三种不同技术路线的原型草图说明。”主题、约束、创新方向都在，模型不会跑题去写营销文案。
验证需求的写法是：“以下是某论文结论：‘神经网络模型 A 优于传统方法 B’。请验证：①实验数据是否支持该结论；②检查对照组设置是否存在偏差；③重新计算 p 值并判断显著性。”结论、验证方法、风险点明确，模型才会去查逻辑漏洞，而不是简单说“有道理”。
执行需求的写法是：“将以下 C 语言代码转换为 Python，要求：①保持时间复杂度不变；②使用 numpy 优化数组操作；③输出带时间测试案例的完整代码。”任务、约束、输出格式清楚，模型不会给你一段跑不起来的伪代码。
注意：公式是骨架，不是填空模板。每类需求里“评估标准”“分析方法”“风险点”这些槽位，必须填具体内容，填“合理”“科学”这类空词等于没填。
5. 易漏点：四个最容易翻车的地方
5.1 易漏点一：把推理模型当万能模型
为什么漏：推理模型在数学、逻辑、代码上表现突出，很容易让人产生“它全面更强”的错觉，于是什么任务都丢给它。但它在发散性任务上并不擅长，强行用逻辑框架去写诗、写故事，输出会显得僵硬。
怎么补：建立“任务类型 → 模型类型”的对照习惯。动手前先问一句：这个任务要的是逻辑链还是发散性？要逻辑链走推理模型，要发散性走通用模型。拿不准时，同一提示语分别喂给两类模型，对比输出结构再决定。
5.2 易漏点二：对推理模型做冗余拆解
为什么漏：很多人习惯了“一步一步教模型做事”，写提示语时忍不住把步骤拆得很细。但推理模型已内化推理逻辑，强行拆解反而干扰它的逻辑主线，甚至让它放弃自主推理、只按你给的步骤走。
怎么补：对推理模型，提示语聚焦目标即可，比如“用 Python 实现快速排序”，不要加“先写递归函数、再写分区逻辑”这类分步指导。判断标准很简单：如果你给的步骤比模型自己能想到的还细，那就是过度干预。
5.3 易漏点三：对通用模型过度信任
为什么漏：通用模型在开放问答上表现自然，容易让人直接抛复杂推理问题给它，然后被一个“看起来很有道理”的答案骗过去。它靠概率预测快速生成，中间步骤可能跳过关键逻辑，结论未必经得起推敲。
怎么补：对通用模型处理复杂逻辑任务时，显式要求分步思考、提供示例，并对结果做分步验证。不要只看最终结论，要看它每一步的依据是否成立。涉及数据、计算的，要求它把中间过程写出来。
5.4 易漏点四：提示语只有指令，没有上下文和期望
为什么漏：指令是最直观的部分，“帮我写个方案”张口就来，上下文和期望却需要动脑整理，于是被省略。模型只能靠猜，猜对了是运气，猜错了就归咎于模型能力。
怎么补：写提示语时强制走一遍“指令 + 上下文 + 期望”三件套。上下文至少交代背景和目标受众，期望至少交代格式、长度、语气中的一项。这个习惯一旦养成，输出质量的稳定性会明显提升。
6. 复习清单：从入门到精通的查漏补缺路径
复习这件事，最怕的是“感觉都会，一用就废”。下面这份清单按能力链排列，可以逐条自测，哪条卡住就回到对应章节补。
| 复习项 | 自测问题 | 卡住时回看 |
|---|---|---|
| 模型分类 | 能否说出推理模型和通用模型各三个优势领域和一个劣势领域 | 第 2.1 节 |
| 快思慢想 | 能否解释概率预测和链式推理在响应速度、算力成本上的差异 | 第 2.2 节 |
| 提示语结构 | 能否把一个模糊需求改写成含指令、上下文、期望的完整提示语 | 第 3.1 节 |
| 模型与提示语匹配 | 给定一个任务，能否判断该用哪类模型、提示语该简洁还是该分步 | 第 3.2 节 |
| 需求分类 | 能否把五个实战例子分别归入决策、分析、创造性、验证、执行五类 | 第 4.1 节 |
| 易错点 | 能否说出四个易漏点各自的表现和补救方法 | 第 5 章 |
自测时建议用“口述 + 手写”双通道：先合上笔记口述一遍，说不清的地方标记出来；再用手写把关键表格默写一遍，尤其是模型对比表和需求公式表。默写不出来的，就是没真正记住的。
还有一个具体技巧：给自己建一个“提示语错题本”。每次输出不理想，不要只改提示语重试，而是把原始提示语、模型类型、输出问题、修改后的提示语一起记下来。积累十几条之后，你会发现翻车模式高度集中，基本都落在第 5 章那四个易漏点里。这个错题本比任何教程都贴身，因为它是你自己的盲区地图。
我自己的习惯是，每次切换模型类型前，都强制走一遍“任务类型判断 → 提示语结构检查 → 易错点对照”这三步，哪怕任务很简单也不跳过。有一次赶时间跳过了，用通用模型直接问一个多步逻辑问题，输出看着顺溜，实际第二步就偷换了概念，返工花的时间比省下的多得多。从那以后我每次换模型都强制走一遍这套检查，再没在这上面栽过。希望这份梳理能帮到你，把零散的使用经验收成一张真正能复习、能查漏的地图。
本文还有配套的精品资源，点击获取
