简介《DeepSeek从入门到精通》PDF面向希望系统了解并上手DeepSeek的普通用户、开发者与AI学习者围绕其能力边界、使用方法与进阶路径展开。内容涵盖DeepSeek-R1开源可免费商用、复杂任务处理以及智能对话、文本生成、语义理解、计算推理、代码生成等场景并介绍联网搜索、深度思考、文件上传和图片文字读取功能重点比较推理模型与非推理模型、概率预测与CoT链式推理的差异结合数学证明、创意写作、代码生成等任务说明模型选择、提示语策略及常见误区。压缩包共1个PDF文件约4.83MB已有730人学习。适合作为系统阅读材料帮助读者按任务类型选模型、优化提示语并理解应用边界。1. 拿到这份《从入门到精通》我先翻的是提示语那几页它其实是一份选型手册上周有做投放的朋友问我DeepSeek 到底怎么用才不像在跟搜索引擎聊天。我把手里这份 2025 年 2 月初版本的《DeepSeek 从入门到精通》讲义翻给他看重点压根不在“能写文案、能改代码”那串功能罗列上而是中间那几页把模型分成推理和通用两条线、再给出两套提示语策略的对照表。这份材料出自某高校新媒体研究团队通篇没有一句 API 参数讲的是同一件事什么任务交给哪类模型需求该怎么表达。适合已经把对话跑起来、但产出时好时坏的人纯新手照着也能走只是前半部分会觉得偏概念。2. 模型先分清推理模型和通用模型不是“新旧两代”选型的混乱几乎都来自一个误解把推理模型当成通用模型的升级版。这份讲义把它拆得很干脆两者是训练目标不同不是能力高低不同。搞清楚这一层后面所有提示语技巧才有落点。2.1 快思慢想的坐标系两组能力别混着比讲义用 CoT 链式思维的出现作为分水岭把大模型切成两类。一类是概率预测型的快速反应模型靠大量语料训练出的模式匹配一句话进来下一个词的概率分布就出去了快、便宜、覆盖面广另一类是链式推理的慢速思考模型把问题拆成若干步逐步推演再给答案慢、算力成本高但在逻辑密度大的任务上明显更稳。DeepSeek-R1 属于后者开源且允许商用这一点对要把它塞进业务流程的团队来说比榜单排名实在得多。两类的差异可以摊开成一张表看维度快速反应概率预测慢速思考链式推理运算原理基于概率预测快速给出可能答案基于链式思维逐步推演每个步骤性能表现响应快算力成本低响应慢算力成本高决策能力依赖预设算法和规则能自主分析情况、实时调整创造力偏模式识别与优化能生成新的思路和解法人机互动按预设脚本响应情感理解较弱更能接住复杂意图和情绪擅长问题结构化、定义明确的问题多维度、非结构化的开放问题表格最右一列容易被读成“推理模型全面更强”这是第一个坑。讲义自己就写了反面发散性任务比如诗歌创作推理模型反而吃亏它会把一首诗写成论证文。强弱判断那句话值得抄下来——并非全面更强仅在其训练目标领域显著优于通用模型。反过来通用模型在需要严格逻辑链的任务上会跳过关键步骤你以为它推了其实它是顺着语感接下去的。我一般这么用涉及数字、代码正确性、多步因果的走推理涉及语气、创意、多轮闲聊、格式转换的走通用。同一件事两头都要就拆成两轮先用推理把结论和依据定下来再用通用把结论写成人话。这个组合在写技术方案、写复盘报告时特别省事前者负责逻辑不自洽后者负责不像机器写的。2.2 选型三问拿到任务先问自己三句话讲义给的原则是“优先根据任务类型而非模型热度选择”落到操作上我会在开对话前先过三个问题这个任务有没有唯一正确答案需要把推导过程摆出来数学证明、代码正确性、多步业务推演答案是要被检验的选推理。输出是收敛的还是发散的写十条广告语、起二十个标题、模拟一段客服对话要的是多样性选通用。我能不能自己验证结果能验证且需要看过程的用推理并让它给中间结果不能验证但要创意的用通用并多给示例把方向框住。第三个问题最容易被跳过。很多人把“我不懂这个领域”当成选推理模型的理由其实恰恰相反——你不懂就没法判断它推得对不对这时候更该做的是把任务拆小、要求它给可核对的中间产物而不是换一个“更聪明”的模型然后全盘接受。讲义里那张任务与提示语策略的对照表本质就是把这三问的答案固化下来任务类型适用模型提示语侧重点有效写法要避免的写法数学证明推理直接提问不拆步骤“证明勾股定理”冗余拆解如“先画图再列公式”数学证明通用显式要求分步并给示例“请分三步推导参考1. 画直角三角形…”直接提问容易跳步创意写作推理鼓励发散设定角色与风格“以某位极简主义作家的风格写一个冒险故事”过度约束逻辑如“按时间顺序列出”创意写作通用明确约束目标“写一个包含‘量子’和‘沙漠’的短篇不超过 200 字”开放式指令如“自由创作”代码生成推理简洁需求信任其逻辑“用 Python 实现快速排序”分步指导如“先写递归函数”代码生成通用细化步骤明确输入输出“先解释原理再写代码并给测试用例”模糊需求如“写个排序代码”多轮对话通用自然交互无需结构化“你觉得这类工具的边界在哪”强制逻辑链条如“分三点回答”逻辑分析推理直接抛出复杂问题“分析电车难题中功利主义与义务论的冲突”加主观引导如“你认为哪种对”逻辑分析通用拆分问题逐步追问“先解释定义再对比两种伦理观差异”一次性提问复杂逻辑这张表我打印出来贴在显示器边上用了两周最大的收获不是记住了哪一行而是养成了“先看右两列”的习惯——多数翻车不是因为模型不行是因为写法和模型类型对不上。2.3 同一需求两套写法把差异落到具体句式抽象地讲“提示语要适配模型”没什么用落到句子上才有感觉。讲义举的五组对照我挑三组展开说。数学证明这组最能说明问题。对推理模型一句“证明勾股定理”就够了它自己会走完辅助线、相似三角形、面积关系那套链条你要是贴心地写“先画直角三角形再列面积公式最后化简”反而可能把它按在你的路径上走到一半卡住。对通用模型就完全反过来必须显式要求分步还得给一个步骤样例否则它很可能直接甩出结论中间过程是补出来的看着顺但经不起推敲。创意写作这组是个反直觉的例子。给推理模型写“按时间顺序列出三个情节”它会把故事写成流程说明正确姿势是给风格锚点和开放空间比如“以极简克制的笔法写一个关于误车的故事”让它自己组织。给通用模型则要反过来收紧明确字数、必须出现的意象、禁止的套路不然它会滑向最平庸的表达。代码生成这组差异最实用。推理模型适合一句话下单“用 Python 实现快速排序带注释”它会自动处理边界通用模型则需要你把输入输出格式、时间复杂度要求、要不要测试样例全写清楚它负责按图施工。我在实际项目里两种都用算法骨架让推理模型出样板代码和胶水层让通用模型写因为后者对框架 API 的熟悉度往往更均衡。还有一条讲义里点了但容易被忽略不要对推理模型用“你是一位资深 XX”这类角色扮演式启发。它确实能触发自解释但也会把注意力从逻辑主线上拽走尤其是你后面还要追问细节的时候前面那层人设会一直干扰它。角色扮演留给通用模型更合适那是它的主场。3. 提示语拆成三件套指令、上下文、期望各管什么讲义对提示语的定义很朴素你输入给模型的指令或信息用来引导它产出特定结果。它可以是一个问题、一段详细指令也可以是一整个任务描述。朴素归朴素但后面那句“基本结构包括指令、上下文和期望”才是能直接抄的部分。3.1 三件套的边界哪一件缺了会怎样指令是核心明确告诉模型要做什么上下文提供背景帮它理解任务落在什么场景里期望则明确或隐含地表达你对输出的要求。三件缺一件症状各不相同而且很好辨认组件作用缺失时的典型症状自查问句指令定义任务输出泛泛而谈答非所问我到底要它干什么上下文提供背景内容正确但用不上像通用模板它知道我的场景、对象、约束吗期望塑造输出形式长度失控、结构混乱、风格不对我要几段、什么格式、给谁看举个人人都遇到的例子。“帮我写个周报”这是只有指令输出必然是那种放之四海皆准的套话。加上期望“三段每段一个进展加一个阻塞不超过 300 字”输出立刻收敛。再加上下文“我是后端本周做的是订单服务拆分阻塞是联调环境不稳定”这才有具体内容。三件套齐全的提示语长度往往比一句指令长三五倍但返工次数会掉下来。讲义的表述里期望可以是明确也可以是隐含的。我的经验是别赌隐含——你想要表格就写“用表格”想要 Markdown 就写“用 Markdown 标题分级”想要它别加客套话就写“直接给结论不要开场白”。这些不是矫情是省掉后面三轮修改。3.2 六种提示语类型及其失效场景讲义把提示语分成六类我把它们的适用边界和翻车点整理在一起类型做法典型示例失效场景指令型直接下达任务“把下面这段翻译成法语”任务复杂时信息不足输出空泛问答型抛出问题等答案“这两组数据差异的成因是什么”问题太宽答案停在常识层角色扮演型设定身份与场景“假设你是一位十九世纪的历史学者评价这次技术变革”用于推理模型时干扰逻辑主线创意型引导内容生成“为一篇气候主题文章写 200 字引言”约束太少产出套路化分析型对给定信息做推理“用十岁孩子能懂的话解释量子纠缠”没给材料分析变成复述多模态型文本加图像等混合输入上传截图让它读出表格数据图片清晰度不够识别串行这张表最有用的是最后一列。角色扮演型在通用模型上是利器在推理模型上经常是负资产分析型提示语如果没有附上材料模型只能靠记忆编看着像分析其实是复述多模态那一条讲义提到支持文件上传和图片文字识别实际用的时候扫描件倾斜、表格线断裂都会让识别结果错位重要数字必须回原图核对。3.3 从“下指令”到“表达需求”三种策略的取舍讲义里有一段标题我印象很深从“下达指令”到“表达需求”。它给了三种策略不是三选一而是按任务复杂度切换指令驱动直接给明确步骤或格式要求。适合简单任务、需要快速执行。优势是精准高效风险是限制了模型自主优化的空间。需求导向描述问题背景与目标由模型自己规划路径。适合复杂问题、需要模型自主推理。优势是能激发深层推理风险是需求边界不清时会跑偏。混合模式需求描述加关键约束条件。兼顾目标与细节是日常最常用的一种风险是约束给多了会捆住手脚。还有一类是启发式提问比如“为什么选梯度下降而不是别的优化方法”。它能触发模型自解释适合做技术选型的思维陪练但很容易偏离核心目标问着问着就变成闲聊。我的做法是把它限制在一轮之内得到解释就收不让它继续发散。三种策略的切换信号其实很清楚任务一句话能说清就用指令驱动任务需要它做判断、做取舍就用需求导向任务既要它判断又有硬约束比如预算、字数、技术栈就用混合模式把约束单列成条目。3.4 五类需求的表达公式讲义把日常需求归成五类每类给了一个表达公式和两种模型的适配策略。这张表是全篇最值得直接抄走的部分需求类型特点表达公式推理模型适配通用模型适配决策需求需权衡选项、评估风险、选最优解目标 选项 评估标准要求逻辑推演和量化分析直接建议依赖经验归纳分析需求需理解数据、发现模式或因果问题 数据/信息 分析方法触发因果链推导与假设验证表层总结或分类创造性需求需生成新颖内容主题 风格/约束 创新方向结合逻辑框架生成结构化创意自由发散依赖示例引导验证需求需检查逻辑自洽、数据可靠结论/方案 验证方法 风险点自主设计验证路径并排查矛盾简单确认缺乏深度推演执行需求需完成具体操作任务 步骤约束 输出格式自主优化步骤兼顾效率与正确性严格按指令执行无自主优化公式本身不难难的是把需求归类。举个讲义里的决策需求例子降低物流成本有两个方案一是自建区域仓库初期投入高但长期成本低二是与第三方合作按需付费但灵活性高要求按 ROI 模型对比五年总成本并给推荐。这个句式的骨架就是目标降本、选项自建或合作、评估标准五年 ROI。缺了评估标准模型只能泛泛说“各有优劣”缺了选项它会自己造两个不相关的方案。验证需求的例子也很典型给一个论文结论“某神经网络优于传统方法”要求验证实验数据是否支持、对照组设置是否有偏差、重新计算显著性。这套写法的价值在于它把“帮我看看对不对”这种无效提问换成了三条可执行的检查项。至于执行需求关键是输出格式要写死——把 C 代码转成 Python保持时间复杂度不变、用 numpy 优化数组操作、输出带时间测试的完整代码这三条约束一给返工率直线下降。4. 落到工作流四个高频场景的复现步骤讲义里的场景覆盖很广文本生成、语义分析、情感分析、意图识别、代码调试都提到了。挑对日常最有用的几个把步骤写细照着走就行。4.1 长文档摘要先切结构再压字数最常见的翻车是一上来就写“把这篇文章总结成 300 字”结果开头讲得细后半部分一句话带过。原因不玄学模型在压缩时倾向于优先保留前文信息越往后权重越低。稳妥的四步是这样的第一步先让它出结构。提问“列出这份文档的章节标题和每节核心论点不要摘要只列结构”拿到骨架你就能判断它有没有读全。第二步按节压缩。把文档按章节切开逐节投喂每节要求“保留数字、结论和限定条件输出 3 条以内”。分段处理比整篇丢进去稳得多。第三步合并去重。把各节结果拼起来再让它合并“合并以下分节摘要去掉重复表述保持原有结论顺序”。第四步反向自检。加一句“指出合并后的摘要中有哪些结论在原文里找不到明确出处”。这一步经常能揪出它自己补出来的内容尤其是数字和因果判断。提示涉及合同条款、财务数字、技术参数的长文档第四步不能省。模型补出来的数字看起来和原文一样自然肉眼很难分辨。4.2 代码生成与调试把验收标准写进需求代码场景的提示语我一般按四段写任务、约束、验收、输出格式。任务一句话约束列条目验收写测试样例输出格式指明语言和文件结构。比如要一个配置读取模块任务写一个读取 YAML 配置的函数。 约束只用标准库加 PyYAML配置缺失时抛自定义异常而不是返回 None支持环境变量覆盖前缀统一。 验收给三个测试用例——正常读取、字段缺失、环境变量覆盖优先级。 输出单个 Python 文件函数带 docstring最后附 pytest 用例。调试时的写法反过来信息越全越好贴最小复现片段、完整报错栈、运行环境和版本、已经试过的两种方案及结果。最忌讳的是只说“报错了”然后截半行日志——那不是提示语那是猜谜。代码生成还有个隐性成本模型给的代码能跑但和你项目的风格、日志规范、异常体系不匹配合并时改的时间比自己写还长。我的做法是在约束里塞一段现有代码作为风格样例明确说“异常处理、日志、命名参照这段代码”。多花两行字省半小时返工。4.3 知识推理与交叉验证让它自证推理类任务最怕的是“看起来推了”。有三个动作能把过程逼出来一是要求给中间结果比如“每步计算后写出当前数值”二是要求列反例“给出三个会让这个结论不成立的条件”三是换表述重问一次看结论是否稳定。交叉验证在事实性问题上尤其管用。同一件事用两种问法问一次问“这个说法成立吗依据是什么”一次问“这个说法在什么情况下不成立”。两次答案如果互相矛盾说明模型对这块知识并不确定那就别采信回去查原始资料。注意联网搜索和深度思考是分开的开关。开了搜索不等于结果一定准来源质量仍然要自己看一眼开了深度思考也不等于逻辑一定对长链条里任何一步错了后面全歪。两个都开的时候先看它引用了什么再看它推了什么。4.4 用一个脚本把提示语模板管起来手工改提示语最大的问题是没法对比。今天调一版觉得好明天再调一版两周后想回头找当初那版聊天记录已经翻不到了。我一般会建一个极简的模板库把讲义里那三类策略和五类需求公式固化成条目跑完把结果记进 CSV做 A/B 对比。# prompt_lib.py —— 提示语模板库固化策略类型记录每次结果 import csv import json import pathlib from datetime import datetime # 模板结构id - 元信息 带槽位的正文 # model_type: reasoning / general决定这条模板只能投给哪类模型 # strategy: 指令驱动 / 需求导向 / 混合模式对应讲义里的三种策略 # need: 决策 / 分析 / 创造 / 验证 / 执行对应五类需求公式 TEMPLATES { verify_paper: { model_type: reasoning, strategy: 需求导向, need: 验证, text: ( 以下是一份研究结论{conclusion}。请验证 1) 实验数据是否支持该结论2) 对照组设置是否存在偏差 3) 重新计算显著性并说明判断依据。 ), }, creative_slogan: { model_type: general, strategy: 混合模式, need: 创造, text: ( 主题{topic}。风格{style}。 输出 {n} 条不超过 12 字的标语避免使用‘赋能’‘引领’这类词。 ), }, } def render(template_id: str, **slots) - str: 按槽位填充模板缺失槽位直接报错避免半成品提示语流出去 tpl TEMPLATES[template_id] try: return tpl[text].format(**slots) except KeyError as e: raise ValueError(f模板 {template_id} 缺少槽位: {e}) from e def log_result(path: str, template_id: str, output: str, score: int, note: str ) - None: 把每次输出记进 CSVscore 用 1-5 主观打分方便后面横向比 file pathlib.Path(path) is_new not file.exists() with file.open(a, newline, encodingutf-8) as f: writer csv.writer(f) if is_new: writer.writerow([time, template_id, model_type, score, note, output]) tpl TEMPLATES[template_id] writer.writerow([ datetime.now().isoformat(timespecseconds), template_id, tpl[model_type], score, note, output[:500], ]) if __name__ __main__: print(render(creative_slogan, topic家用净水器, style克制、不夸张, n5)) # 跑完把输出贴回来打分同一模板换个模型再跑一遍就有了第一条对比数据这段代码不长三个设计点值得说一下。model_type这个字段是硬约束模板标了 reasoning 就不该投给通用模型写死在元信息里比记在脑子里可靠。render里槽位缺失直接抛异常是为了防止半成品提示语流出去——{conclusion}没填就发出去模型会把它当占位符糊弄过去你还以为是自己表达不清。log_result只截前 500 字是为了让 CSV 能直接丢进表格软件看太长的输出反而没人读。参数上score用 1 到 5 的主观分就够关键不是精确是同一批模板之间能排出先后。5. 避坑与排查五条翻车记录下面这几条都是我自己踩过或者看着同事踩的按“现象、原因、解决”写遇到类似症状可以对着排。5.1 提示语层面的三个坑第一条给推理模型加了角色扮演和“请一步步思考”。现象回答开头先自我介绍“作为一名资深产品经理”然后绕了两段才进正题逻辑链条反而断断续续。原因推理模型本身已经内化了推理结构你再要求它分步等于在它自己的链条外面套一层壳角色设定又额外占用注意力让它把力气花在维持人设上。讲义里那句“不要对推理模型使用启发式提示”说的就是这个。解决把角色和“一步步思考”删掉只留目标、约束、输出格式。删完再做一次对照多数情况下回答会更短更准。第二条数学或代码题答案看着对一跑就错中间步骤缺失。现象让它算一个多步推导结论对但过程是跳的代码逻辑看似合理边界一测就崩。原因多半是用了通用模型还问得太短。通用模型顺着语感往下接形似推导实际没有逐步验证反过来如果你用的是推理模型却强行拆步骤也会限制它的推理空间。解决先确认模型类型对不对再决定提示语写法。推理模型直接抛问题通用模型显式要求分步并给示例最后统一加一句“给出可验证的中间结果”。第三条长文档摘要漏掉后半段关键结论。现象一份几十页的材料摘要里前半部分细节齐全后半部分的结论、限制条件几乎没提。原因一上来就压成固定字数模型优先保留前文文档越长越靠后的内容在注意力分配上越吃亏。解决先出结构大纲再按节压缩最后合并去重并做反向自检要求它指出哪些结论找不到原文出处。这套流程比一次成型的摘要慢但返工少。5.2 使用习惯上的两个坑第四条同一条提示语今天好用、明天崩产出风格飘忽。现象同一个模板周一生成的文案干脆利落周三生成的就变得啰嗦还夹杂一堆形容词。原因模板没固定每次都是现打而且一直在同一个会话里连续追问历史上下文越堆越长模型的输出被前面的对话带偏。解决模板写成槽位固化下来像上节那个脚本一样重要任务开新会话跑别在几十轮的老对话里继续追加需求。第五条让它“分析数据”回来一堆通用建议一个数字都没有。现象贴了一段销售数据过去让它分析输出是“建议加强渠道建设、优化产品结构”这类放之四海皆准的话。原因两个问题叠在一起。一是数据没给全或者格式混乱它读不出结构二是需求类型写错了你想要的是分析需求写出来却像决策需求它就跳过分析直接给建议。解决数据用表格或 CSV 贴清楚指明分析方法比如趋势、同比、异常点明确要求“每条结论必须挂具体数字”。要决策建议就再单独提一轮别和分析混在一句话里。6. 进阶把提示语当代码管跑一轮 A/B 就知道该信谁讲义的最后一层意思其实不是教你写出多花哨的提示语而是让你有办法判断哪一版更好。没有对比所有“我觉得这版更顺”都是自我感觉。我现在的流程是这样一个模板固定下来之后同一批输入分别投给推理模型和通用模型各跑三遍输出记进 CSV 打分。三遍是必要的因为单次输出有随机性跑一遍就下结论等于抛硬币。评分维度我只留三个——事实有没有错、结构能不能直接用、要不要二次加工。三个维度各打 1 到 5 分加总排序比逐字读十遍输出高效得多。模板 ID模型类型策略事实准确性结构可用性二次加工量备注verify_paper推理需求导向54低三次结论一致可作为固定模板creative_slogan通用混合模式45低第三次出现重复句式需加去重约束longdoc_summary推理混合模式43中后半段仍会漏需强制分节表格跑上两三周你会得到一份很个人的经验数据哪类任务用哪个模型、哪种策略返工最少。这份东西比任何通用攻略都准因为它对应的是你的业务、你的文档、你的验收标准。还有一个容易被忽略的进阶点把失败样本留下来。翻车的输出比成功的输出值钱它直接告诉你边界在哪。我一般在 CSV 里加一列备注写清楚“为什么这版不能用”比如“引用了不存在的文献编号”“把同比写成了环比”。攒到十几条你会发现翻车高度集中在几个固定形态上针对性改模板比漫无目的地调提示语有效得多。从那以后我每次上新模板都强制先在两类模型上各跑三遍、把分数记进表里再决定用哪版哪怕只是改了一个词也走一遍。这习惯救过我一次——一条看着完全无害的措辞调整让验证类模板的准确性从 5 掉到 3表格一摆就露馅了。希望帮到你。本文还有配套的精品资源点击获取