简介：清华大学《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 GB，30B 以上建议 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, json=payload, headers={"Authorization": f"Bearer {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 进阶工作流：从单次问答到可复用 Agent
4.1 上下文窗口管理：塞进资料前先做切分与压缩
DeepSeek 的上下文窗口有上限，你没法把整本文档一次性塞进去。很多人第一次做长文档问答，直接把 PDF 全文复制进提示词，结果模型说「你的内容超过我的处理范围」。这不是模型不行，是你的投喂方式不对。
上下文管理的三个动作是：切分、压缩、按需检索。切分是把长文档按段落或固定长度切成多个片段，每次只把相关片段送进模型。常见做法是按 token 数切，每段 500 到 1000 token，相邻段保留 50 token 的重叠，防止句子在切缝处被截断。压缩则是把不重要的内容用摘要替代，比如把 100 页的会议记录压缩成 10 条要点。按需检索是先把文档向量化，用户提问时只取最相关的几个片段。
一个简化版的切分逻辑：
def split_document(text, chunk_size=800, overlap=50): """按字符数粗粒度切分文本。生产环境建议换成按 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, embeddings=embedding_model.encode(chunks)) # 3. 用户提问时，把问题转成向量，检索前 k 个最相似片段 question = "项目的验收标准是什么？" results = vector_db.search(query=question, top_k=3) # 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 这个方向上少走几段弯路。
本文还有配套的精品资源，点击获取
