简介清华大学《DeepSeek从入门到精通》课程讲义以PDF形式整理面向希望系统掌握DeepSeek大模型尤其是开源推理模型DeepSeek-R1的应用学习者与开发者。内容从DeepSeek公司背景、模型定位讲起覆盖智能对话、文本生成、语义理解、计算推理、代码生成等核心应用场景并专门对比推理模型与非推理模型在决策能力、创造力、人机互动上的差异结合链式思维CoT阐述提示语策略如何根据任务类型选择模型与措辞。资源共1个PDF文件约4.79MB文字与图表排版清晰便于按章节从头阅读或快查。目前已有174人学习浏览。学习者可从中获得对DeepSeek功能边界的完整认知、各类实际任务如长文本摘要、多语言翻译、代码调试、知识推理的适用方法以及优化提示语的实用原则可作为从入门到进阶的参考学习材料。1. DeepSeek 从入门到精通为什么说它把大模型的使用门槛拉到了新低很多人是被某高校那份《DeepSeek 从入门到精通》的公开资料带进门的但真正常用的往往不是里面最炫酷的提示词模板而是几个最基础的动作把模型跑起来、把上下文喂对、把输出格式锁死。DeepSeek 这个系列模型的最大特点是在同等参数量下把推理成本压得很低同时开源了多个尺寸的底座模型让个人开发者和中小团队都能用得起。本文想解决的不是「怎么把文档读一遍」而是「怎么从零开始把 DeepSeek 用出生产力」。适合的读者很明确刚接触大模型、想在本地或云端跑通一个可用服务的开发者以及已经在用其他模型、想评估 DeepSeek 是否值得迁移的从业者。读完你可以得到一个可复现的最小链路以及我踩过的、文档里不会写的那些坑。2. DeepSeek 的模型底座与选型先分清该用哪个入口2.1 模型系列的定位差异对话、推理、代码不是同一个东西DeepSeek 对外提供的模型不是一个而是一族。常见的有基础对话模型、专门强化过推理能力的版本以及在代码数据上做过增量训练的变体。我刚接触时犯过一个典型错误拿代码模型去跑日常对话任务发现它话少、语气硬还总想输出代码块。后来才意识到选错模型等于让一个后端工程师去当前台活能干但体验很差。选择顺序我一般这样定先看任务是生成型还是理解型。生成型任务写文案、做翻译、整理摘要选对话模型它跟你一来一回地聊措辞自然得多。理解型任务数学题、逻辑推理、代码生成与调试选推理增强的版本它会在内部做更长的思考链答案质量明显提升。至于代码专用模型只在你确定任务就是写代码、补全代码、解释代码时用不要拿它做通用问答。参数范围也要提前知道。大尺寸模型效果最好但显存和延迟要求高小尺寸版本能用 CPU 跑适合做原型验证。我的判断标准是如果任务允许 3 到 5 秒的等待时间优先用中等尺寸模型效果和成本的平衡点最好。如果要做实时交互比如聊天机器人再考虑量化后的小模型。2.2 本地部署的最小可行方案量化选型与显存预算本地部署是很多人的第一步因为数据不出内网调试也方便。常见做法是用 GGUF 格式的量化模型配合推理框架跑。GGUF 把模型权重压缩成不同精度的版本常见的有 q4_k_m、q5_k_m、q8_0 这几档。量化位数越低模型体积越小但效果损失越明显。q4_k_m 是我用得最多的档位它在体积和效果之间最均衡q8_0 几乎无损但体积大一圈。启动一个量化模型的最小命令长这样# 拉取 q4_k_m 量化版本尺寸约 4 到 5 GB按实际情况调整仓库名 # 用 llama.cpp 自带的 server 启动监听 8080 端口 llama-server \ -m ./models/deepseek-q4_k_m.gguf \ -c 4096 \ --host 0.0.0.0 \ --port 8080 \ -n 2048这段命令的意思是-m指定模型文件路径-c 4096把上下文窗口设为 4096 token足够大多数日常任务--host 0.0.0.0允许局域网内其他机器访问方便联调-n 2048限制单次生成的最大 token 数防止模型失控输出长篇废话。启动后用浏览器或 curl 访问http://localhost:8080就可以测试。如果是纯 CPU 环境建议把线程数加上比如-t 8指定 8 个线程吞吐会明显改善。显存预算方面q4_k_m 的 7B 模型大约需要 5 到 6 GB 显存13B 级别大约 9 到 10 GB30B 以上建议 16 GB 起步。如果显存不够可以退而求其次用 q2 或 q3 量化效果会打折扣但至少能跑起来。我见过很多人在 8 GB 显存的机器上硬跑 13B 模型结果每秒只吐两三个 token那种体验基本没法用。量化档位不是越高越好要按显存和任务类型一起定。2.3 云端 API 接入一个请求把 DeepSeek 跑起来本地部署适合调试和隐私敏感场景但生产环境我一般建议走云端 API。DeepSeek 提供了兼容常见 API 协议的接口这意味着你不需要引入新的 SDK直接用标准的 HTTP 请求或现成的开发库就能调。下面是一个用 Python 调用云端 API 的最小示例import requests # 请替换为实际可用的 API 地址和密钥 API_BASE https://api.example.com/v1/chat/completions API_KEY sk-xxxxxx payload { model: deepseek-chat, # 对话模型按控制台实际模型名填写 messages: [ {role: system, content: 你是一个熟悉大模型落地的工程师回答要简洁、具体、不说废话。}, {role: user, content: 用一句话解释什么是上下文窗口} ], temperature: 0.7, max_tokens: 500, stream: False } resp requests.post( API_BASE, jsonpayload, headers{Authorization: fBearer {API_KEY}} ) if resp.status_code 200: result resp.json() # 取返回内容的字段前先确认响应结构不同服务商的字段名可能不一样 print(result[choices][0][message][content]) else: print(请求失败状态码, resp.status_code, resp.text)这个请求里最关键的是messages数组。很多初学者只在里面放一条 user 消息其实system消息才是控制模型行为倾向的杠杆。我在例子中把系统提示词设成了「回答要简洁、具体」模型输出风格会立刻从默认的「详细解释」变成「直给结论」。temperature控制随机性0.7 是对话任务的常用值做代码生成或格式严格的输出时我会降到 0.2 以下。stream如果设为true响应会变成流式返回适合做打字机效果但解析逻辑要改。3. DeepSeek 提示词工程把「会说话」变成「会干活」的四个抓手3.1 系统提示词定角色与边界让模型不乱来很多人第一次接触 DeepSeek上来就写「帮我写个方案」然后发现输出又空又泛。问题不在模型在于你没有先给它一个身份和行动边界。系统提示词就是干这个的在对话真正开始前告诉模型它是谁、任务是什么、哪些不能做。我常用的系统提示词结构分三层。第一层定义角色你是什么岗位、什么风格。第二层定义输出要求格式、长度、语气。第三层定义禁区比如「不要编造数据」「不知道就说不知道」。这套结构写一次之后每次任务都复用效果比每次临时想一句强得多。一个写技术文档的例子你是一位资深后端工程师负责把复杂的系统设计讲清楚。 输出要求 1. 先给结论再展开原因 2. 每段不超过 5 行 3. 涉及具体参数时给出取值范围和推荐值 4. 不知道的信息明确说「需要查证」不要猜测。如果你发现模型答非所问先检查系统提示词是否给了足够的约束。我在调试一个文档生成任务时模型老是把「简述」写成 2000 字长文后来在系统提示词里加了一句「总字数控制在 400 字以内」问题立刻解决。这不是玄学是你在把模糊的需求翻译成模型能理解的指令。3.2 结构化输出用 JSON Schema 约束回答格式大模型返回自然语言很在行但返回「程序能直接解析的格式」经常翻车。你让它给你 JSON它给你一段 JSON 外面包着 Markdown 代码块你让它给数组它给带序号的行文。解决思路是不靠「请输出 JSON」这句软约束而是给出明确的格式定义和示例。实践中最稳的做法是在提示词里同时给 Schema 和示例请从下面的项目描述中提取结构化信息严格按以下 JSON 格式输出不要输出其他任何内容 { project_name: 项目名称字符串, difficulty: 难度等级取值为 低/中/高, keywords: [关键词1, 关键词2], estimated_time_hours: 预估工时数字 } 示例输出 { project_name: 用户登录模块, difficulty: 中, keywords: [认证, JWT, 安全], estimated_time_hours: 8 } 项目描述...这里的关键是把「输出格式」从描述变成「语言模型的 few-shot 示例」。模型看到完整示例后仿写比理解更可靠。解析时即使你给了严格提示仍然要加一层容错逻辑先去掉输出里的 Markdown 标记再尝试解析。因为偶尔模型还是会夹带私货比如在 JSON 后面加一句「以上是提取结果」这需要在后处理里剥掉。3.3 few-shot 示例的摆放位置与数量控制few-shot 是在提示词里给模型看几个「问题-答案」对让它照着样子做。这个技巧对 DeepSeek 这类模型非常有效因为它的训练数据里就有大量「模仿示例」的模式。但摆法有讲究。示例要放在 user 消息之前还是和 user 消息混在一起我的经验是放在 system 消息的末尾或者在 user 消息里先给示例、再给真实问题两种方式都行但不能放在最后一条 user 消息之后。模型会更关注靠近末尾的内容所以真实问题必须出现在最后。示例数量上3 到 5 个最佳。给少了模型还没理解模式给多了上下文被占掉不少且模型开始「总结规律」而不是「照做」反而失真。一个真实场景是信息抽取。我给模型看了两个「原文-抽取结果」示例再让它抽第三个准确率从 60% 跳到了 90% 以上。这个提升不是模型变聪明了而是你有效地利用了它的上下文学习能力。3.4 temperature、top_p、max_tokens 三个旋钮怎么配合这三个参数是模型输出的「三观旋钮」很多人从入门到精通都没搞清楚它们各自的职责。temperature控制输出的随机性。数值越低模型越倾向于选概率最高的词输出更保守、更确定数值越高越敢于冒险但胡说八道的概率也涨。代码生成和 JSON 输出我设在 0 到 0.3文案写作可以放到 0.8 到 1.0。top_p是另一个随机性控制它限制模型只在累计概率达到 p 的候选词里选。很多框架里 temperature 和 top_p 同时起作用建议一次只动一个两个一起调容易不知道是谁的功劳。max_tokens是硬性上限防止模型无限生成。调参时要记录基线。我每调一个任务先在默认参数下跑一次记录输出质量和长度然后分别调 temperature 和 top_p对比结果。经验是先固定 max_tokens 到合理值比如 500再定 temperature最后微调 top_p。三个旋钮一起乱拧翻车了都不知道是哪一步造成的。4. DeepSeek 进阶工作流从单次问答到可复用 Agent4.1 上下文窗口管理塞进资料前先做切分与压缩DeepSeek 的上下文窗口有上限你没法把整本文档一次性塞进去。很多人第一次做长文档问答直接把 PDF 全文复制进提示词结果模型说「你的内容超过我的处理范围」。这不是模型不行是你的投喂方式不对。上下文管理的三个动作是切分、压缩、按需检索。切分是把长文档按段落或固定长度切成多个片段每次只把相关片段送进模型。常见做法是按 token 数切每段 500 到 1000 token相邻段保留 50 token 的重叠防止句子在切缝处被截断。压缩则是把不重要的内容用摘要替代比如把 100 页的会议记录压缩成 10 条要点。按需检索是先把文档向量化用户提问时只取最相关的几个片段。一个简化版的切分逻辑def split_document(text, chunk_size800, overlap50): 按字符数粗粒度切分文本。生产环境建议换成按 token 切分。 chunks [] start 0 while start len(text): end start chunk_size # 尽量在段落边界处切开避免句子被腰斩 if end len(text): while end start and text[end] not in \n。: end - 1 chunks.append(text[start:end]) start end - overlap return chunks这里chunk_size是每段的目标长度overlap是相邻段的重叠量。重叠的目的是让跨段的信息至少出现在两个片段里检索时不容易漏。切分后把每个片段连同编号存起来之后用 embeddings 或关键词匹配选出相关片段。选片段的数量也有讲究我一般取 2 到 3 个片段拼进上下文多了会稀释模型对核心内容的注意力。4.2 用 function calling 把 DeepSeek 接进自己的工具链单次问答的天花板很低真正的玩法是把模型接进你自己的系统——让它可以调函数、查数据库、触发流程这就是 Agent 的雏形。DeepSeek 支持 function calling核心不再是你写提示词让它输出答案而是让模型先判断「该调哪个工具」然后根据工具结果继续回答。一个常见流程是用户问「帮我把团队本周的工时统计一下」模型先解析意图决定调用一个get_work_hours函数拿到数据后组织成回答。这个过程的编程模式是先把函数和它的参数定义发给模型模型返回一个函数调用请求你执行函数并把结果回传给模型。functions [ { name: get_work_hours, description: 按团队成员和日期范围查询工时统计, parameters: { type: object, properties: { member: {type: string, description: 成员姓名}, start_date: {type: string, description: 起始日期 YYYY-MM-DD}, end_date: {type: string, description: 结束日期 YYYY-MM-DD} }, required: [start_date, end_date] } } ]这段代码定义了一个查询工时的函数描述把它放进请求后模型会自己判断用户的提问是否匹配这个函数。匹配时它返回的不是回答而是一个带参数的工具调用请求。你在代码里执行真实的数据库查询把查询结果以 tool 消息的形式回传模型再基于这些内容生成最终回答。这个来回是关键函数描述写得越清晰模型的判断越准参数定义越严格模型传错参的概率越低。function calling 的坑在于模型可能会臆造参数。比如用户没给起始日期模型自己填了一个「今天」这时候要么代码里做参数校验要么在函数描述里明确「如果用户未提供日期不得自行假设必须追问」。4.3 简易 RAG让 DeepSeek 基于私有文档回答RAG检索增强生成是目前让大模型「懂你的私有资料」最可靠的方案。原理不复杂把文档切碎、向量化、存入向量库用户提问时把问题也向量化检索出最相似的文档片段然后拼进提示词让模型基于这些片段回答。它的价值在于模型不需要「记住」你的文档每次回答都现查保证信息时效性也能标注来源。一个最小的 RAG 流程只需要三个库一个 embedding 模型、一个向量数据库、一个 DeepSeek 实例。代码结构大致如下# 1. 把文档切块用 4.1 的 split_document chunks split_document(document_text) # 2. 用 embedding 模型把每块转成向量存入向量数据库 # 这里以伪代码示意不同向量库的 API 略有差异 vector_db.add_texts(chunks, embeddingsembedding_model.encode(chunks)) # 3. 用户提问时把问题转成向量检索前 k 个最相似片段 question 项目的验收标准是什么 results vector_db.search(queryquestion, top_k3) # 4. 把片段拼进提示词交给 DeepSeek context \n.join([r[text] for r in results]) prompt f请基于以下资料回答问题如果资料中没有答案直接说不知道。\n\n资料\n{context}\n\n问题{question}这个流程里最容易被低估的是第一步切分质量直接决定检索质量。切得太粗一个片段里塞了多个主题检索命中率下降切得太细单一片段信息量不足模型回答没有依据。我调过一版参数把奖励写在文档最后结果没有一段被切到「奖励」这个词模型只能乱答。后来把 chunk 调大、重叠调高才解决。做 RAG 不要先调模型先调你的切分和检索这个顺序能省你半天时间。5. DeepSeek 落地避坑五个高频翻车现场与排查顺序5.1 现象模型输出 JSON 永远带 Markdown 代码块这是个老熟人了。明明提示词里写了「不要输出任何其他内容」返回的仍然是在代码块里的 JSON。原因有两个一是模型的训练数据里JSON 示例大多出现在 Markdown 代码块里它认为这是标准格式二是系统提示词的约束权重没有你想象的那么高。解决方式是双向的。提示词层面在示例里直接给出「裸 JSON」的形态不要给包着代码块的示例。代码层面解析前做一次清洗def clean_and_parse(text): # 去掉开头的 json 和结尾的 text text.strip() if text.startswith(): text text.split(, 2)[1] if text.endswith(): text text.rsplit(, 1)[0] return json.loads(text)这段清洗逻辑不能省。它把常见的 Markdown 围栏剥掉然后才进入json.loads。我见过不少人卡在这上面骂模型不听话其实加三层防御就够了提示词给裸格式示例、解析前剥围栏、解析失败时提示重试。5.2 现象温度调高了代码生成出现莫名其妙的「创意」有次我拿 DeepSeek 生成 SQL 查询temperature 用了默认的 0.7结果模型给我写了一个在语法上完全合法、但逻辑上毫无意义的 JOIN。原因很直接0.7 对于代码任务太高模型开始「发挥」了。解决就是在代码和数据处理任务里把 temperature 降到 0.2 以下。这不是保守而是这类任务需要确定性同样的输入今天跑和明天跑结果应该一致。如果你需要多次生成结果做组合请在代码里固定随机种子或者干脆设 0。我的习惯是写代码用 0做文案用 0.8做分析报告用 0.3。5.3 现象长对话后进行到一半模型突然「失忆」表现为对话的前面几轮你明确告诉过它的信息到后面它不认账了。最直接的原因是上下文窗口被占满早期的消息被截断或丢弃。还有一种可能是代码里在做多轮请求时只带了最近的几条消息把 system 和早期消息丢了。排查顺序先看请求日志里的 token 用量确认是否接近窗口上限再看 messages 数组里是否保留了 system 消息。我一般会写一个上下文裁剪函数按 token 数从早期消息开始丢但永远保留 system 消息和最近三轮的对话。这个策略在长对话场景下比无脑截断稳得多。5.4 现象stream 模式响应正常但解析端拿不到完整内容流式返回时内容被切成多个 chunk 推送客户端需要自己拼装。翻车点在于很多人只解析了第一个 chunk拿到一段残句就停手还有人以为finish_reason在第一个 chunk 里就会返回结果被异常中断。代码层面要处理两个事件收到内容块时追加收到结束标志时合并输出。此外流式模式下异常不一定走 HTTP 状态码可能是一个包含 error 字段的 JSON 尾块解析逻辑里必须判断这种形态。我的建议是除非有打字机需求否则第一版先用非流式把链路跑通再切流式。5.5 现象并发一上来响应变慢甚至报错 429本地部署时单请求的延迟可能没问题但多个用户同时访问排队时间和显存占用会一起涨。云端 API 则有并发上限和速率限制超出就返回 429。排查思路是分层看。本地部署先看显存是否被打满再看是否配置了并发队列云端则看控制台的速率限制检查是否有退避重试逻辑。解决通常在应用层加一个信号量限制最大并发请求数超过的请求排队等待而不是让它们同时打到模型。另外把流式响应打开可以显著降低首个 token 的等待时间让并发体验好很多。这里的血泪经验是先限流再调模型不要一慢就怪模型。6. 用验证集保住 DeepSeek 的「精通」回归测试才是最值得投入的技巧做到这一步你已经能把 DeepSeek 跑通、接到业务里了。但从「能用」到「精通」中间隔着一条护城河怎么知道一次提示词改动不会让另一些任务变差答案是建立回归测试集。我在本地维护一个大约 50 条测试用例的脚本每条用例是一个任务代码生成、JSON 抽取、摘要、问答。每次改动系统提示词或调参先跑一遍脚本对比输出和预期结果的匹配度。比如 JSON 抽取任务我写了自动校验解析结果里字段是否存在、类型是否正确、值是否在合法范围内。代码生成任务则靠编译或执行报错来判断。这个习惯帮我挡掉了至少三次「改好了 A 任务、弄坏了 B 任务」的翻车。测试集不要贪大质量比数量重要。把真实业务中最高频的 10 个任务抽出来每个配 5 个变体就足够覆盖大多数回归风险。另外不要只在调参时跑换模型版本、改上下文切分策略时也要跑。这个验证习惯的价值远超过你在网上找的任何「高级提示词模板」。我现在接手任何大模型项目第一件事不是看代码是问有没有测试集。没有的话我先花半天建一个最小集后面所有改动都在这个集上验证。希望这套从跑到护航的方法能帮你在 DeepSeek 这个方向上少走几段弯路。本文还有配套的精品资源点击获取