简介这份PDF资料源自清华大学新闻与传播学院新媒体研究中心团队面向希望系统掌握DeepSeek的开发者、内容创作者与AI初学者帮助读者从基础认知走向实际应用。内容围绕DeepSeek-R1开源推理模型展开涵盖文本生成、语义理解、代码生成与调试、常规绘图等应用场景并深入讲解推理模型与通用模型的维度差异、快思慢想机制及CoT提示语策略指导读者按任务类型选择合适模型。资源包共1个PDF文件约5.92MB结构完整、便于通读与检索。目前已有9313人学习适合需要理解大模型能力边界、优化提示语设计并提升实际使用效果的读者参考。1. 拿到这份 DeepSeek 手册先别急着翻目录上周有个做后端的朋友问我DeepSeek 到底该怎么用才不浪费。他试过几次觉得“跟别的聊天框差不多”就搁下了。我让他把那份从某高校新媒体研究团队流出的《DeepSeek从入门到精通》翻到提示语那一章他看完回头跟我说了一句原来我一直在用通用模型的习惯去喂推理模型。这份材料的价值不在“DeepSeek 是什么”这种介绍而在于它把推理模型和通用模型的差异拆成了可操作的提示语策略。它面向的是已经会用 AI、但用得不够好的人——写文案的、做分析的、写代码的、带项目的。如果你只是想知道 DeepSeek 官网在哪这份东西对你偏重但如果你手里有具体任务想让输出稳定、可复现它值得逐页过一遍。下面我按自己拆读的顺序把能直接抄的部分和容易翻车的地方讲清楚。2. 推理模型与通用模型先选对模型再谈提示语2.1 两类模型的本质差异在哪材料里反复强调一个判断推理模型不是“全面更强”而是在训练目标领域显著优于通用模型。DeepSeek-R1 这类推理模型强在数学推导、逻辑分析、代码生成、复杂问题拆解弱在发散性任务比如诗歌创作、开放式头脑风暴。通用模型反过来文本生成、创意写作、多轮对话更灵活但遇到严格逻辑链的任务需要提示语去补偿。这个差异的底层是 CoT链式思维带来的分叉。一类是“概率预测”的快速反应模型靠大量数据快速预测下一个可能答案响应快、算力成本低另一类是“链式推理”的慢速思考模型逐步推演每个步骤再给结论慢但逻辑密度高。材料用“快思慢想”来概括这个说法虽然借自心理学但放在选型上很实用即时反馈类任务走快思复杂推理类任务走慢想。我一般会先问自己一句这个任务错了会不会很难发现如果答案是会比如一段数学证明、一段涉及边界条件的代码那就该上推理模型并且提示语要简洁把目标说清楚就行不要替它拆步骤。反过来写营销文案、做多轮客服对话通用模型更合适但提示语要给足约束和示例。2.2 选型对照表与提示语侧重材料里给了一张任务类型与模型匹配的表我把它整理成下面这个版本方便直接对照使用任务类型适用模型提示语侧重点要避免的写法数学证明推理模型直接抛出问题信任其内化推理冗余拆解如“先画图再列公式”创意写作通用模型明确风格、字数、约束目标开放式指令如“自由创作”代码生成推理模型简洁需求加输出格式分步指导如“先写递归函数”多轮对话通用模型自然交互给背景不给结构强制逻辑链条如“分三点回答”逻辑分析推理模型直接给复杂问题主观引导如“你认为哪种对”这张表的关键不是背下来而是理解背后的原则推理模型已经内化了推理逻辑你强行拆解反而可能限制它的能力通用模型缺乏这条逻辑链你不显式引导它就容易跳过关键步骤。材料里有一句话我印象很深——“不要对推理模型使用启发式提示比如角色扮演可能干扰其逻辑主线”。这一点很多人会踩后面避坑章节会展开。2.3 一个可复现的对比实验光看表不够我建议自己做一次对照。同一个问题分别用两种提示语喂给推理模型看输出结构差异。下面是我常用的测试脚本思路用 Python 调 API 的方式写参数按你实际环境改import requests # 替换为你实际使用的接口地址与密钥这里只演示请求结构 API_URL https://api.example.com/v1/chat/completions API_KEY your_key_here def ask(prompt, modeldeepseek-reasoner, temperature0.3): payload { model: model, messages: [{role: user, content: prompt}], temperature: temperature, # 推理任务压低随机性 max_tokens: 2048 } headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, jsonpayload, headersheaders, timeout60) return resp.json()[choices][0][message][content] # 提示语 A简洁目标型适合推理模型 prompt_a 证明勾股定理给出完整推导步骤。 # 提示语 B过度拆解型常见误用 prompt_b 先画一个直角三角形再标出三条边然后列出公式最后推导勾股定理。 print(A:, ask(prompt_a)) print(B:, ask(prompt_b))这段代码的逻辑很简单同一模型、同一温度只改提示语。temperature设 0.3 是为了让推理输出更稳定创意任务可以调到 0.8 以上。max_tokens给 2048 是留足推导空间数学证明类任务别卡太小。跑完对比你会发现B 这种拆解式提示在推理模型上经常出现“步骤齐全但推导跳跃”的情况因为模型被你的步骤框住了反而没走自己的推理链。这个实验成本很低但能让你对“简洁指令”四个字有体感。3. 提示语结构拆解指令、上下文、期望怎么填3.1 三段式结构的实际写法材料把提示语拆成指令、上下文、期望三部分。指令是核心告诉 AI 做什么上下文提供背景帮它理解期望明确输出要求。听起来像教科书但落到实操难点在于三者的比例。我的经验是推理模型偏指令通用模型偏上下文和期望。举个材料里的例子改写。决策需求公式是“目标 选项 评估标准”。原文示例是降低物流成本的两个方案对比。我把它写成可直接复制的形式目标降低区域物流成本。 选项①自建区域仓库初期投入高、长期成本低②第三方合作按需付费、灵活性高。 评估标准按 ROI 模型对比 5 年总成本考虑折现率 8%。 请给出推荐方案并说明关键假设。这段提示语里指令是“给出推荐方案”上下文是两个选项和评估标准期望是“说明关键假设”。注意我没有写“请一步一步分析”因为这是推理模型它自己会推。如果换成通用模型我会补一句“请分三步先算两方案五年现金流再算 ROI最后给结论”这就是补偿性引导。3.2 五类需求的表达公式材料把需求分成决策、分析、创造性、验证、执行五类每类给了公式。这部分是整份材料里最能直接抄的。我按自己的使用习惯重新组织了一下决策需求用“目标 选项 评估标准”适合选型、方案对比。分析需求用“问题 数据/信息 分析方法”适合数据解读、归因。创造性需求用“主题 风格/约束 创新方向”适合文案、方案设计。验证需求用“结论/方案 验证方法 风险点”适合审稿、查逻辑漏洞。执行需求用“任务 步骤约束 输出格式”适合格式转换、代码改写。这里有个容易忽略的点验证需求在推理模型上特别好用。材料里的示例是让模型验证一篇论文的结论是否被数据支持要求检查对照组偏差、重算 p 值。这种任务通用模型容易顺着你的话说推理模型更可能挑出矛盾。我实际用下来把“请验证以下结论指出数据是否支持、对照组是否有偏差”这类提示语固定成一个模板审技术方案时能省不少事。3.3 提示语类型与适用边界材料列了六种提示语类型指令型、问答型、角色扮演型、创意型、分析型、多模态。这里要泼一盆冷水角色扮演型在推理模型上要慎用。材料明确写了“不要对推理模型使用启发式提示如角色扮演可能干扰其逻辑主线”。我踩过这个坑让推理模型“扮演一位资深架构师”去分析一个并发问题结果它花了不少篇幅在角色语气上真正的锁竞争分析反而浅了。后来改成直接给问题、给约束输出质量明显回升。创意型提示语则相反通用模型上要给足风格和约束否则容易写成四不像。材料里“以海明威的风格写一个冒险故事”是个好例子但我会再加一句“不超过 300 字包含一个反转”把期望压实。多模态提示语涉及图片输入材料提到支持文件上传和图片文字扫描这部分我建议单独测因为扫描质量受图片清晰度影响很大后面避坑会讲。4. 把提示语落到具体任务四类场景的实操配置4.1 文本生成与摘要改写文本生成是通用模型的舒适区但“能生成”和“生成得能用”之间差的是约束。材料里列了营销文案、社交媒体内容、长文本摘要、多语言翻译等场景。我拿长文本摘要举例因为这是很多人每天都要做的。一个常见的翻车是直接丢一篇长报告说“帮我摘要”输出要么太泛要么漏掉关键数据。我的做法是把期望拆成结构任务摘要以下报告。 上下文报告主题是某季度运营复盘读者是管理层关注转化率和成本两项指标。 期望输出 3 条要点每条不超过 40 字必须包含具体数字最后附一句风险提示。 报告内容{粘贴正文}这里{粘贴正文}是占位符实际使用时替换。参数上摘要任务温度建议 0.3 到 0.5太高容易改写失真。如果报告超过模型上下文长度常见做法是先分段摘要再汇总不要硬塞。材料提到支持文件上传读取实操中 PDF 扫描件的文字识别质量不稳定重要数字建议人工核对一遍这一点后面避坑章节会展开。4.2 代码生成与调试代码任务是推理模型的主场。材料里列了代码生成、错误分析、性能优化、API 文档生成。我的经验是代码提示语要把“输入输出格式”和“边界条件”写死否则模型容易给你一个能跑但没处理异常的版本。# 提示语模板把这段作为 content 发给模型 prompt 任务实现一个函数统计文本中每个单词出现次数。 约束 1. 输入为字符串可能包含标点需先清洗 2. 输出为 dict按次数降序 3. 空字符串返回空 dict不抛异常 4. 用 Python 3.10 语法附 3 个测试用例。 这段提示语的关键在约束第 3 条。不写这句模型很可能不处理空输入或者直接return None。测试用例要求也是我固定加的因为模型自带的用例往往只覆盖正常路径。调试场景则反过来把报错信息和相关代码一起给提示语写“分析错误原因给出修复建议并说明修复后可能引入的新风险”。最后半句是材料里验证需求的思路能逼模型多想一层。4.3 语义分析与知识推理语义分析包括情感分析、意图识别、实体提取、文本分类。这类任务看起来简单但标签体系不清晰时输出会飘。材料里提到主题标签生成、垃圾内容检测。我的做法是先给标签定义再给示例最后给判定规则。比如做用户反馈情感分析提示语里我会写清楚三分类的边界正面指明确表达满意或推荐负面指明确表达不满或阻碍中性指陈述事实无情绪倾向。然后给两三个边界案例。这一步不能省因为“中性”和“弱负面”的界限不同人理解不一样模型需要锚点。推理模型在这类任务上会给出判定理由通用模型则可能直接给标签需要你追问依据。4.4 结构化输出与表格生成材料提到表格、列表生成比如日程安排、菜谱。结构化输出的坑在于格式不稳定同一提示语跑两次列名可能不一样。解决办法是把 schema 写进提示语并要求“只输出 JSON不要解释”。任务把以下会议记录转成任务清单。 输出格式JSON 数组每个元素包含 owner字符串、task字符串、deadlineYYYY-MM-DD、priority高/中/低。 约束deadline 缺失时填 nullpriority 按紧急程度推断并在 task 末尾用括号注明依据。 会议记录{粘贴内容}owner、task这些字段名固定下来下游解析才稳。deadline缺失填 null 而不是空字符串是为了避免类型混乱。要求注明优先级依据是借了推理模型的自解释能力方便你复核。如果输出还是带 markdown 代码块包裹可以在提示语末尾加一句“直接输出 JSON 文本不要用代码块”多数情况下能压住。5. 避坑与排查五条血泪经验5.1 对推理模型做角色扮演逻辑主线被带偏现象让推理模型“扮演资深律师”分析合同风险输出大量角色语气铺垫真正的条款风险点反而一笔带过。 原因角色扮演属于启发式提示会占用模型的推理预算干扰其内化的逻辑链。 解决去掉角色设定直接给任务和约束比如“分析以下合同条款的违约责任风险按高/中/低分级并说明依据”。需要语气时在输出格式里指定不要放进角色。5.2 通用模型直接问复杂推理结果看似合理实则跳步现象用通用模型做多步数学或逻辑题答案结构完整但中间某步凭空出现一个结论。 原因通用模型靠概率预测生成缺乏链式推理遇到严格逻辑链会“补全”而非“推导”。 解决换推理模型或在通用模型上显式要求分步并给示例同时要求每步标注依据。重要结论必须人工验算别被流畅的表述骗过去。5.3 文件上传后直接摘要扫描件数字错位现象上传 PDF 扫描件让模型摘要金额、日期出现明显错位或漏读。 原因图片文字识别对清晰度、排版敏感表格类内容尤其容易串行。 解决关键数字单独用文本贴一遍或先人工核对扫描件再喂。材料提到支持文件与图片文字读取但读取不等于准确涉及财务、合同类内容我一般强制走一遍人工比对。5.4 提示语过度拆解推理模型反而变笨现象把一道证明题拆成“第一步、第二步、第三步”喂给推理模型输出步骤齐全但推导跳跃。 原因推理模型已内化推理逻辑外部强加的步骤框架限制了它的自主推理路径。 解决只给目标和输出要求删掉过程性指令。判断标准很简单如果你的提示语里出现了“先……再……然后……”而任务是推理类就该删。5.5 结构化输出不带 schema下游解析频繁报错现象让模型输出表格或 JSON字段名每次不一样解析脚本三天两头改。 原因提示语只说了“输出表格”没定义列名和类型模型自由发挥。 解决把字段名、类型、缺失值处理写进提示语并要求只输出目标格式。跑通后把提示语存成模板别每次重写。温度也压到 0.2 左右减少格式抖动。6. 进阶把提示语模板固化成可复用的验证流程材料最后落到“还要不要学提示语”这个问题上答案是肯定的但学的方式要变。不是背模板而是建立一套自己的验证流程。我现在的习惯是任何要重复用的提示语先跑三组对照——推理模型简洁版、推理模型拆解版、通用模型补偿版看哪组输出最稳然后把胜出的那组连同参数一起存进一个本地模板库。这个模板库不需要复杂工具一个 Markdown 文件加几个代码块就够。每条模板记录四样东西适用任务、模型类型、完整提示语、温度与 max_tokens。下面是我模板库里的一个片段用 Python 字典存方便脚本直接调用TEMPLATES { contract_risk: { model: deepseek-reasoner, temperature: 0.2, max_tokens: 3000, prompt: ( 分析以下合同条款的违约责任风险。 按高/中/低分级每条注明条款原文和风险依据。 若条款存在歧义单独列出并给出两种解释。 条款内容{clause} ) }, feedback_sentiment: { model: deepseek-chat, temperature: 0.4, max_tokens: 1024, prompt: ( 对以下用户反馈做情感三分类正面/中性/负面。 正面指明确满意或推荐负面指明确不满或阻碍中性指陈述事实无情绪。 输出 JSON{label, reason}reason 不超过 30 字。 反馈{text} ) } }contract_risk走推理模型温度压到 0.2因为合同分析要稳feedback_sentiment走通用模型温度 0.4 留一点灵活性。{clause}和{text}是占位符调用时替换。这个结构的好处是换模型或调参数只改一处提示语本身不动。验证方法上我固定做两件事。一是同一输入跑三次看输出结构是否一致格式抖动大的模板直接淘汰。二是拿已知答案的案例做回归比如一段明确该判“高”风险的条款看模板是否稳定判高。这两步花不了多少时间但能挡住大部分“看着能用、一上量就崩”的模板。从那以后我每次新建提示语模板都强制走一遍三组对照加三次重跑宁可前期多花二十分钟也不想后面在几十条输出里手工纠错。这份材料里关于推理模型与通用模型差异的那几页我建议你单独打印出来贴在工位上选型时扫一眼比事后返工划算。希望帮到你。本文还有配套的精品资源点击获取