简介《DeepSeek从入门到精通清华大学版》是一份由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队整理的 PDF 学习资料面向普通用户与开发者解答 DeepSeek 是什么、能做什么、怎么用三大问题。内容围绕 DeepSeek-R1 开源推理模型的智能对话、文本生成、语义理解、代码生成等能力展开并系统对比推理模型与通用模型在优势领域、性能本质、提示语策略上的差异帮助读者按任务类型选择合适模型、设计更高效的提示词。资源包含 1 个 PDF 文件共 3.69MB图文排版清晰适合从零起步的系统性学习也可作为日常使用 AI 工具时的速查参考。已有 2099 人学习下载适合希望从“下达指令”升级到“表达需求”、提升复杂任务处理效率的读者。1. 这份从入门到精通到底在讲什么网上流传的《DeepSeek 从入门到精通》常被冠以某高校的名头很多人硬盘里存了一份跟着抄了几天提示词一到生产环境照样翻车。原因在于这份资料的方向不是教你怎么聊天而是教你怎么把 DeepSeek 用到位。入门是调通 API、会写基础提示词精通是能控输出格式、能接工具调用、能建评测集还能提前避开长上下文丢信息这类隐蔽问题。下面不替任何原稿背书只按这个标题指向的技术方向把模型选型、提示词分层、API 接入和落地排错的做法讲完整。适合两类人刚拿到 key 的初学者顺着走一遍已经在业务里接了的熟手直接跳到第 5 章对照踩坑。2. 先给 DeepSeek 定位模型选型决定后面 80% 的调参工作2.1 通用对话模型与推理模型的分工先选对再谈调优DeepSeek 在 API 接入层最常见的是两类模型通用对话型和推理型。不同版本的接入名会变我在实际项目里见过以 deepseek-chat、deepseek-reasoner 这类名字区分的具体以你开通服务的控制台为准但两者的分工是稳定的通用对话模型流畅、快、单价低适合内容生成、信息抽取、改写润色、翻译分类这类一次生成、结构可控的任务推理模型会在正式回答前多走一段内部推理数学、逻辑、多步规划、条件判断这类任务明显更稳代价是首字更慢、单价更高。这两类模型的差别来自解码流程。推理模型在输出前会先生成一段隐藏的思考链这也是它延迟高的直接原因通用对话模型没有这一步所以快但遇到需要隐式推理的任务时容易跳步。理解了这一点就不难判断凡是想想再说的任务优先推理模型凡是看完就说的任务通用模型就够了。我一般按任务性质做三档选择。第一档摘要、分类、抽取、润色、翻译一律用通用对话模型能加格式约束就加速度是第一位。第二档代码调试、SQL 生成、数学题、多条件规则判断用推理模型但最终结果还是要用结构化输出框回来不能让它自由发挥。第三档混合任务先在通用模型上把格式做稳再拿推理模型复核一到两个关键结论而不是所有请求都走贵的。任务类型推荐模型原因摘要 / 抽取 / 改写通用对话快、便宜、格式可控数学 / 多步推理推理模型内部思维链提升准确率复杂代码生成推理模型优先逻辑分支多的场景更稳翻译 / 润色通用对话流畅度优先延迟敏感混合任务复核通用生成 推理复核成本与质量折中选型这一步之所以值得单独说是因为它决定了后面所有工作的基准。推理模型在需要多步推理的任务上准确率可能高出通用模型不少但在简单抽取任务上几乎没有收益还多付延迟和成本。我见过一个团队在简单问答场景里全量上推理模型只因为听说效果更好结果成本翻了几倍准确率只涨了一个点。选型错了后面调温度、调提示词都只是在错误的基准上做局部搜索属于把问题延后。提示接入名在不同服务商的实现里有差异换模型前先在文档里确认名字和计费方式别在代码里写死逻辑。2.2 上下文长度与采样参数别把长上下文当卖点DeepSeek 系列的上下文窗口做得长长文本是它的一个卖点但长不等于好用。实际约束有两个一是上下文越长每次请求的 KV Cache 开销越大首字延迟和单次成本一起涨二是模型对长上下文的注意力并不均匀测试里最常见的现象是开头和结尾记得牢中间一大段容易选择性遗忘。我的习惯是能用检索把上下文压到 4K 以内绝不用 32K 硬塞。真遇到必须长上下文的场景有两个补救手段把最关键的约束放在系统提示的末尾复述一遍把材料里的关键结论在问题里显式引用一次。这两招比单纯加大窗口便宜得多也有效得多。采样参数里最常被误用的是 temperature 和 top_p。我一开始也是两个一起调后来发现结果变得更加不可控。原因是两者都作用于采样阶段temperature 是对 logits 做缩放后再采样的随机性控制top_p 是对候选词做累积概率截断两者同时改会叠加出奇特的分布形态出了问题很难定位是哪一个造成的。参数作用我的常用取值temperature采样随机性越低越稳定结构化 0.1~0.3对话 0.7~0.8top_p候选词累积概率截断与 temperature 二选一很少动max_tokens输出长度上限按任务估算留 20% 余量stream是否流式返回长回答必开max_tokens 是很多人忘记设的参数。回答被截断时表现是写到一半突然停了看起来像模型在胡说实际是你设的上限不够。还有一个容易被忽略的点推理模型的内部思考也占用输出长度从通用模型切到推理模型后如果发现回答变短了往往不是模型变笨而是思考过程吃掉了额度。遇到这种情况先把 max_tokens 拉大一截再判断。另外强调一句这些参数都建立在模型能力之上。所谓玄学调参本质是在错误前提下做局部搜索。参数不是不能用而是要每次只动一个并且用同一组测试样本验证效果。2.3 云端 API 还是本地部署先算这笔账大模型落地第一道选择题是用 API 还是本地部署。很多人一上来就想私有化理由是安全但这个决定应该由成本和运维能力驱动而不是感性驱动。API 方式的优势是零运维、按量付费、模型版本始终在线升级劣势是数据要出内网且请求量大了之后单次成本会变成一笔持续支出。本地部署的优势是数据不出内网、单次调用边际成本趋近于零、可以做私有微调劣势是你要养 GPU 资源、处理量化精度、选推理框架、管并发和显存。本地部署不是下载一个模型就能跑我见过不止一个人卡在显存不够和推理加速这一步。我的判断标准很简单日请求量低或业务还在验证期API 一定更划算数据敏感度到不能出内网的程度或者日调用量大到 API 月账单超过 GPU 折旧和电费再考虑本地。更稳的路径是先在 API 上把业务逻辑验证通再评估是否迁移而不是一上来就买卡。对比维度API 方式本地部署运维成本几乎为零需要专人维护推理服务数据流向出内网不出内网单次成本按量付费边际成本趋近零模型版本服务商持续迭代版本固化升级成本高适合阶段验证期、低中量请求高量、强数据合规要求3. 提示词三层写法把会问打磨成能控3.1 第一层结构化角色-任务-约束三段式很多人的提示词是一句话帮我总结这篇文章。模型确实能答但格式、详略、立场全凭当天运气。我习惯的三段式模板是先给角色定位再说具体任务最后列硬约束。下面这段是实际用在反馈分析场景里的模板你是一个资深数据分析师擅长从用户反馈中提炼可执行的改进项。 任务阅读下面的用户反馈输出本版本存在的三个最严重问题。 约束 1. 每个问题用一句话描述不超过 30 字 2. 每个问题后附一条证据引用原文片段 3. 按严重程度从高到低排序 4. 只输出 Markdown 列表不要开场白。这段模板的逻辑分三层。角色行压缩了模型对该用什么语气、什么领域知识来回答的猜测空间任务行明确了唯一目标避免发散约束行把不可度量的写得好拆成可校验的规则——排序、引用原文、限字数都是能在评测时自动验证的。这也是我要强调的约束应该可校验而不是表态度。同一句话回答要认真不可校验每个结论必须附数据来源可校验格式要美观不可校验使用 Markdown 二级标题分节可校验。写提示词时把每条约束过一遍能不能自动化检查这个筛子留下来的才是有效约束。低质量约束高质量约束回答要认真每个结论必须附一条数据来源格式要美观使用 Markdown 有序列表序号连续不要说废话总字数控制在 300 字以内这里有一条血泪经验约束不是越多越好。我把约束从三条加到十条以为写得越清楚模型越听话结果模型开始顾此失彼——守住了格式丢了内容守住了字数丢了证据。原因是约束之间会互相冲突模型要在矛盾里做取舍输出质量自然下降。我的阈值是硬约束不超过五条能合并的合并覆盖不到的规则交给输出格式去约束。每加一条新约束都要用同一批测试样本回归一遍而不是只看当前这一个例子。3.2 第二层思维链与少样本复杂任务稳定性的关键任务一旦需要多步推理直接要答案的写法会让模型跳步。常见做法是让模型先列推理步骤再给结论。DeepSeek 对这种显式思维链的追随能力比较强是少数能在提示词层面把推理过程逼出来的模型之一。请按以下步骤思考最后再给结论 1. 列出题目给出的所有条件 2. 判断需要用到哪个公式或规则 3. 代入数值计算每一步保留中间结果 4. 检查单位与量级是否合理 5. 基于以上步骤给出最终答案。 题目仓库初始库存 500 件每天进货 200 件、出货 150 件问第几天库存超过 2000 件这里的关键不是让它好好想而是把隐式推理拆成可检查的中间产物。你拿到的不只是一个答案而是它算到哪一步开始出错的线索。排错时你能直接指出第三步代入错了而不是对着一个错误结论无从下手。少样本是同一思路的另一面。给一两个完整示例往往比写五条规则更有效。但示例的选择有讲究要选容易答错的边界样本而不是选答得漂亮的典型样本。比如做意图分类正样本给查快递对应查询类远不如给帮我看看这个包裹到哪了这种口语化变体更有信息量。有一类任务要反着用推理模型。DeepSeek 的推理模型内部本来就会生成思考链你再在提示词里要求它显式写步骤效果不会提升反而拉长输出、推高成本。我实测对比过同一道规划题显式思维链让输出长度增加约一倍正确率没有变化。所以思维链提示词留给通用对话模型推理模型只需要告诉它输出格式就够了。3.3 第三层输出格式用 JSON 约束替代请按格式输出请输出 JSON这句话模型听得懂但偶尔会夹带 Markdown 代码块、多余的说明文字甚至直接输出一个不完整的 JSON。更稳的办法是把格式定义直接写进提示词并在代码里做两层容错。{ issues: [ { title: 问题一句话, evidence: 原文引用片段, severity: high | medium | low } ] }把这段结构粘进提示词的约束区同时在 system 里写明只输出 JSON不要 Markdown不要解释。这样组合实践中解析成功率能到 95% 以上。剩下的少数失败靠代码兜底import json, re raw resp.choices[0].message.content try: data json.loads(raw) except json.JSONDecodeError: match re.search(r(?:json)?\s*(.*?)\s*, raw, re.S) if match: data json.loads(match.group(1)) # 剥掉代码块标记再试一次 else: data None # 仍失败就走告警交给人工处理这段兜底的逻辑先按标准 JSON 解析失败后用正则把json 和之间的内容抠出来再试还失败就告警而不是静默返回空。生产环境里兜底逻辑和提示词同样重要。把宝全押在提示词上等于把稳定性寄托在模型的当天状态上。4. 用 Python 跑通接入对话、流式、工具调用一条线4.1 最小可用脚本先让一次对话跑起来DeepSeek 的 API 兼容 OpenAI 协议用官方 Python SDK 就能接不需要自己封装 HTTP。先记一个最小脚本from openai import OpenAI import os client OpenAI( api_keyos.environ[DEEPSEEK_API_KEY], # key 走环境变量别硬编码 base_urlhttps://你的服务商地址/v1, # 以你开通服务的文档为准 ) resp client.chat.completions.create( modeldeepseek-chat, # 接入名以控制台为准 messages[ {role: system, content: 你是一个只输出 JSON 的助手。}, {role: user, content: 把这句话翻译成英文你好世界}, ], temperature0.3, max_tokens512, ) print(resp.choices[0].message.content)这个脚本的要点就几个客户端初始化时指定 key 和 base_url消息列表按 system、user 顺序组织system 负责定基调user 放实际请求temperature 和 max_tokens 在这里已经落到结构化输出的推荐值。有两点必须强调。第一key 一定走环境变量或密钥管理服务不要写进代码仓库。我见过不止一次因为 key 泄露被刷账单的翻车这是接入大模型最贵的教训。第二base_url 不要照抄网上的以你实际开通的服务商文档为准尾部的 /v1 路径拼写敏感错了会返回 404 这类报错。4.2 流式输出长回答别让用户干等不开启流式时接口要等完整回答生成完才返回一段长总结能让你等十几秒。生产环境建议开流式首字到达时间会从十几秒缩短到一两秒。代码改动很小stream client.chat.completions.create( modeldeepseek-chat, messagesmessages, streamTrue, ) for chunk in stream: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)流式模式的核心是理解 delta 字段的结构每一块只携带增量内容不是完整文本。所以拼接逻辑要放在消费侧比如后端逐块转发给前端走 SSE而不是在后端拼成完整文本再一次性返回那样流式就失去了意义。超时参数也要单独设。流式请求的连接超时给 30 秒左右读超时按业务容忍度给比如 120 秒。不要用默认的一刀切超时长流式请求很容易被默认值误杀。排查这类问题时先看超时设置再看网络不要一上来就怀疑模型。4.3 工具调用把 DeepSeek 接进真实业务流程对话只是最浅的一层。真正把模型变成生产力靠的是函数调用——让模型决定调用哪个工具、生成参数你的代码去执行再把结果喂回给模型。这也是从入门到精通的分水岭。tools [{ type: function, function: { name: query_stock, description: 查询指定商品在华东仓的实时库存返回数量和预警阈值, parameters: { type: object, properties: { sku: {type: string, description: 商品编码} }, required: [sku] } } }] resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 查一下 A100 的库存}], toolstools, tool_choiceauto, ) msg resp.choices[0].message if msg.tool_calls: for call in msg.tool_calls: print(call.function.name) # 模型想调用的函数名 print(call.function.arguments) # 模型生成的参数 JSON # 在这里真正执行查询然后把结果以 tool 角色追加回 messages再次请求整个流程分三步缺一不可。第一步模型输出要调用哪个函数、参数是什么它只有这个意图没有执行能力第二步你的代码真正执行查询数据库或调用内部服务因为模型接触不到你的系统第三步执行结果以 tool 角色追加回消息列表模型基于结果生成最终回答但你也可以选择直接返回结果给用户取决于业务设计。工具描述的好坏直接影响调用成功率。description 写库存查询远不如写查询指定商品在华东仓的实时库存返回数量和预警阈值——模型是依据 description 判断该不该用这个工具的写得越具体调用越准。常见错误是让模型自己查它做不到另一类错误是工具名和参数名起得含糊导致模型猜错参数。工具的命名和字段要按人话来让模型少猜。4.4 对话历史的窗口管理别让消息数组无限膨胀接入多轮对话后最容易被忽视的是 messages 数组的长度。每轮对话都往里追加时间一长会有两个问题超出上下文限制导致请求失败历史消息占用 KV Cache成本和首字延迟一起涨。更隐蔽的是过长的历史会让模型抓不住重点——中间轮次的噪音会稀释当前意图。常见做法是保留 system 消息把历史截断到最近 N 轮MAX_HISTORY 10 def build_messages(system, history, user): recent history[-MAX_HISTORY:] # 只保留最近 N 轮 return [{role: system, content: system}] recent [ {role: user, content: user} ]这个函数的逻辑system 永远保留历史和当前用户消息做拼接超过 MAX_HISTORY 的部分直接丢弃。实现简单但要注意两个边界。一是截断会丢信息用户十分钟前提的条件可能被截掉所以进阶做法是把更早的对话压缩成摘要用摘要替代原始历史二是按轮数截断对长对话不精确更稳的是按 token 数截断用分词器估算每条消息的长度总长超过阈值就从最早的开始丢。方案的选择看场景客服类对话窗口保留 10 轮足够代码辅助类可以放宽到 20 轮需要长期记忆的业务与其硬撑窗口不如把关键信息落库需要时检索回来。窗口管理这件事做得越早越省心等接口开始报上下文超限再处理就晚了。5. 落地避坑五个高频翻车点与排查路径5.1 提示词写得太满输出反而更差现象约束从三条加到十条想着越具体越稳定结果模型开始漏字段、格式错乱甚至拒绝执行。 原因约束之间互相冲突超出模型单次注意力能同时兼顾的量级。尤其是字数限制和信息完整这类天然互斥的约束模型只能在矛盾中做取舍。 解决硬约束砍到五条以内冲突的约束用优先级排序例如信息完整优先字数放宽到 40 字每加一条新约束都用同一批测试样本回归而不是只看当前这个例子变好了。5.2 temperature 调高后 JSON 频繁解析失败现象同样的提示词temperature 从 0.1 调到 0.8JSON 解析失败率从 2% 涨到 20%。 原因temperature 控制的是整个输出分布的随机性结构符号同样会被影响。括号、引号的配对出错不是模型不理解 JSON而是采样太散。 解决涉及结构化输出时 temperature 固定在 0.1~0.3需要变化就调 top_p 或干脆不调。如果业务必须高温度加一道修复步骤让模型把夹带了说明文字的内容重写成干净 JSON。这是兜底不是调参。5.3 生产环境三件套超时、重试、限流现象高峰期请求大面积失败报错集中在超时和限流状态码。 原因只设了一个笼统的超时重试策略写成失败立即重试反而加重了限流没有做请求排队。这三个问题叠加故障会被放大而不是被吸收。 解决连接超时设 10 秒读超时按任务给 60~120 秒重试用指数退避第一次等 0.5 秒第二次 1 秒最多三次遇到限流响应读取服务商返回的重试等待时间而不是自己拍脑袋。这套组合是接任何大模型 API 的通用底座跟具体模型无关。5.4 长上下文中间遗忘关键信息要挪位置现象把几万字的资料一次性塞进上下文模型回答时漏掉了中段的某个数字或前提条件。 原因注意力在长输入上不均匀开头和结尾更容易被记住中间段落的线索被淡化。这是长上下文模型的共性表现不是某个具体版本的缺陷。 解决三选一或组合用——能用检索把输入压短就绝不硬塞全文必须长上下文时在系统提示末尾复述一遍最关键的约束再不行就把材料拆成多路查询分别提问再汇总。有效性排序是检索优于复述优于加窗口。5.5 没有评测集就调参等于拍脑袋优化现象每次改完提示词都感觉变好了但上线后指标没动甚至下滑。 原因改完只看了几个手工挑的例子恰好都过了这是幸存者偏差。手工例子覆盖不了边界输入随机性掩盖了真实的能力分布。 解决建一个 30~50 条的固定评测集覆盖正常、边界、恶意输入三类每次改动跑一遍并记录通过率只接受通过率不降的改动。评测集是你摆脱玄学、唯一可依赖的依据。6. 从能用到精通用评分脚本把迭代变成可验证的最后一层也是最多人跳过的一层把手感变成分数。我给自己定的规矩是任何改动上线前先跑评测。做法很简单建一个固定输入列表每条配上理想输出的关键词或校验规则写一个几十行的脚本统计通过率。cases [ {prompt: 提取这段合同里的编号, must_contain: [HT-]}, {prompt: 把你好翻译成英文, must_not_contain: [你好]}, # 30~50 条覆盖正常、边界、恶意输入 ] def run(prompt): # 调用你的封装函数返回模型输出 ... def check(content, case): if must_contain in case: return all(k in content for k in case[must_contain]) if must_not_contain in case: return all(k not in content for k in case[must_not_contain]) return False passed sum(check(run(c[prompt]), c) for c in cases) print(fpass rate: {passed}/{len(cases)})这套脚本的价值不是精确度量质量而是做回归你改完温度、改完提示词、换了模型跑一遍通过率不降改动才敢合入。关键词判定对抽取、分类、格式校验类任务足够开放生成类任务再用二次评分或人工抽检兜底。我的教训很直接。早期调参完全凭感觉某次把 temperature 从 0.3 调到 0.7手工看五个例子都更自然满心欢喜上了线结果线上抽取任务通过率掉了三成用户投诉才意识到问题。后来把评测集跑起来的第一个月就挡住了三次类似的感觉很好、实际更差的改动。从那以后先跑评测再上线成了我接所有大模型的默认开关。走到这一步精通就不再是某个玄学境界而是一套可重复的动作选对模型分层写提示词接好 API 与工具调用用评测集守住每一次改动。某高校那份资料给的是知识框架这里给的是落地习惯。顺着这条路走DeepSeek 对你来说就不是聊天玩具而是能稳定产出价值的业务组件。希望帮到你。本文还有配套的精品资源点击获取