简介由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的《DeepSeek从入门到精通》103页完整版PDF面向希望系统掌握DeepSeek应用的AI学习者、开发者和内容创作者可作为从零基础到进阶提升的系统教程。资源以单个PDF文件打包共1个文件约5.01MB内容分DeepSeek是什么、能够做什么、如何使用三大部分展开。教程不仅梳理了智能对话、文本生成、语义理解、代码生成等核心能力还重点拆解了推理模型与通用模型的选择原则、快思慢想与CoT链式思维差异以及面向数学证明、创意写作、代码生成等任务的提示语策略并配有指令驱动、需求导向、混合模式等具体示例后段还通过任务-模型匹配表和提示语示例帮助读者选对模型、写对提示词。已有362人学习浏览可作为接触DeepSeek时建立完整认知并避开常见误区的实用速查手册。1. DeepSeek 从入门到精通这份 103 页资料到底在教什么很多人拿到 DeepSeek 之后用成了升级版搜索框丢问题、接答案、复制粘贴三周过去还停在入门层。DeepSeek 真正拉开差距的地方是它的模型分两条线——通用对话模型负责快推理模型负责想两者的提示词写法和参数手感完全不同。那份流传很广的 103 页学习资料主线就是「认识模型 → 调通接口 → 写提示词 → 落到工作流」这么一条可跟做的路径。下面内容不替代那份资料而是按一线落地顺序把跑 API、部署到本地、搭提示词模板、解析结构化输出这些能直接抄的步骤拆开顺便标出五个高频翻车点。适合三类人要接 API 的开发者、整天和文本表格打交道的分析师、以及想搞清楚提示词为什么时灵时不灵的学习者。2. 两条路线跑通 DeepSeekAPI 最小调用与本地部署的显存底线2.1 走 API一个能直接改的 Python 最小调用先说明选型理由如果目标是快速验证提示词、或者做原型API 是最省事的入口不用管显卡、量化和 CUDA 版本。DeepSeek 的接口协议兼容标准 OpenAI SDK这意味着你现有的调用代码改个 base_url 就能切过来学习成本基本为零。from openai import OpenAI # DeepSeek 接口兼容 OpenAI 协议SDK 可以直接复用 client OpenAI( api_keysk-在这里填你的密钥, # 在官方控制台的密钥页面创建 base_urlhttps://api.deepseek.com, # 官方 OpenAI 兼容端点 ) resp client.chat.completions.create( modeldeepseek-reasoner, # 推理模型通用对话请换成 deepseek-chat messages[ {role: system, content: 你是资深后端工程师只输出结论和风险点}, {role: user, content: 检查下面代码在并发场景下的问题只列 3 条。}, ], temperature0.3, # 推理任务压到 0.3创作类可以拉到 0.8 max_tokens2000, # 控制单次输出长度避免一次调用产生过多 token ) # 推理模型会把内部思考过程单独放在 reasoning_content 字段 print(思考过程) print(resp.choices[0].message.reasoning_content) print(最终输出) print(resp.choices[0].message.content)代码逻辑说明先创建客户端密钥从控制台拿别写死在代码里用环境变量更稳。一次 chat.completions.create 就是完整调用重点在 model 参数——deepseek-reasoner 会先推理后回答适合复杂任务deepseek-chat 是直出模式响应更快。system 消息负责定角色和边界user 消息才是真正的任务。temperature 是采样随机度任务越要求确定性压得越低max_tokens 只限制输出长度不限制输入。这段代码踩过坑的地方有两处一是很多人在 system 里写一大段人格设定结果每次请求都把这堆字重新计费后面 5.5 会细说二是忽略 reasoning_content把思考过程当正文存库下游数据会变得特别脏。2.2 本地部署蒸馏版模型选型与启动命令一旦涉及敏感数据或者要跑固定格式的大批量任务API 就不划算了得把模型拉回本地。这里先说一个现实DeepSeek 主模型是千亿级参数的 MoE 架构个人机器直接跑不现实。常见做法是跑它的蒸馏版——把推理能力蒸馏到 7B、8B、32B 这些规模单机能扛得住。# 方案 A个人实验、验证提示词用 Ollama 这类模型管理器最省事 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b# 方案 B有并发和吞吐要求用 vLLM 这类推理框架起服务 vllm serve ./models/deepseek-r1-7b-local \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name deepseek-r1-local第一段命令适合跑通流程ollama pull 拉模型ollama run 进交互。第二段是给生产环境准备的vllm serve 起一个兼容接口的服务客户端把 base_url 指到本地端口就行。模型路径按你实际下载到本地的目录填。参数说明tensor-parallel-size 单卡上就设 1max-model-len 是上下文总预算32768 代表输入加输出最长约 3.2 万 token这个值每涨一倍KV cache 显存占用就涨一大截gpu-memory-utilization 0.9 表示允许框架用掉 90% 显存留点余量给别的进程。显存底线按经验给个参考7B 级别加 4bit 量化16GB 显卡能跑但别把上下文拉满32B 级别建议 24GB 以上不然会触发 CPU offload慢到没法用。注意两个折扣要心里有数量化会损失一点推理质量蒸馏版本身也不是完整版效果验收时别拿完整版的预期去卡它。2.3 怎么选延迟、隐私和成本的取舍表对比项API 调用本地部署前期成本注册即用按 token 付费硬件投入一次到位隐私风险数据经过第三方服务敏感字段要脱敏数据不出机器延迟与并发高峰期不稳定但不用自己扛扩容延迟稳定并发受显存和卡数限制运维负担几乎为零要处理 CUDA 版本、量化、上下文调优模型更新服务端升级无需干预自己拉新权重重新验证我的选择逻辑是提示词调试和原型阶段一律走 API速度快、反馈直接涉及合同、用户数据、内部日志这类内容迁到本地固定格式的批处理任务如果量大本地跑更划算但准确率回归测试要先建起来这个放到第 6 章。还有一条容易被忽略的边界API 拿到的思考过程和本地模型不完全一样同一个提示词在两个环境的结果不能直接互相当基准。3. 提示词写法为什么 DeepSeek 推理模型不吃「逐步思考」这一套3.1 先搞懂 CoT 内化很多人拿到推理模型后干的第一件事是在提示词里加一句「请一步步思考」结果回答反而变长变绕。这里有个机制差异要搞清楚DeepSeek 的通用对话模型是直出模式你给它步骤它就照做而推理模型在内部已经跑了一圈思维链思考过程单独放在 reasoning_content 字段里。你再去要求「逐步思考」它容易把内部思考外化成正文白白浪费输出 token还会让答案结构散掉。所以提示词设计的落点变了对推理模型要給目标、给约束、给输出格式别去指挥它怎么想对通用模型给示例、给步骤、给明确指令。同一个任务两套写法拿到的结果质量能差一个档次。如果你看到回答开头出现「嗯让我想一想」这种话基本可以判定是提示词在逼模型外化推理。3.2 一套能直接抄的提示词模板角色-任务-约束-输出格式# 角色 你是一名有十年经验的 Python 后端工程师。 # 任务 审查下面这个函数找出它在多线程场景下的竞态条件。 # 约束 - 只列问题不重写代码 - 按严重程度从高到低排序 - 如果确实不存在竞态直接说「未发现」不要硬凑。 # 输出格式 每条严重级别 | 问题描述 | 涉及行号 # 待审查内容 把代码贴在这里这套结构的逻辑是角色决定用谁的知识体系回答任务必须只有一个任务一多模型会自己分配权重结果两头都浅约束的作用是砍废话「不要硬凑」这种否定式约束在推理模型上效果很明显输出格式保证你拿到的结果能解析。待审查内容用分隔线隔开避免和指令混在一起。这个模板顺手能改成数据分析、文档审查、翻译等任务只换角色和约束就行不需要重学一套写法。3.3 四个必调的采样参数temperature、top_p、max_tokens 与惩罚系数参数作用推荐起始值什么时候调整temperature采样随机度复杂任务 0.3创作 0.8结果飘忽不定就往下压top_p候选词截断范围0.9与 temperature 二选一调整别同时猛调max_tokens单次输出长度上限预期长度 × 2输出总在半句处截断就加大frequency_penalty对重复词的惩罚0长文反复绕同一观点时调到 0.5 左右四个参数里最容易翻车的是 temperature 和 top_p 同时调两者都在控制随机性一起大幅度改动会把输出变成玄学。我的习惯是固定 top_p 在 0.9只动 temperature。还有一个反直觉的点推理模型内部有思维链很多人以为 temperature 对它无效实际上它会作用到最终答案的采样只是影响方式更隐蔽——同样参数下两次结果依然可能不同。所以任何测试都别只跑一次至少跑三遍看稳定性。4. 把 DeepSeek 接进真实工作流三套可复用模板4.1 代码生成先要方案、再要代码的两段式调用直接让模型写完整功能结果通常是「看起来能跑边界条件全是洞」。我一般拆成两段第一段只要设计方案第二段把方案作为上下文再去要代码。方案在这里起护栏作用模型照着既定结构落代码自由发挥空间被压到最小。def gen_plan(client, task): resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: f给下面的任务写实现方案模块划分、数据结构、边界条件。不写代码。\n{task}}], temperature0.3, max_tokens1500, ) return resp.choices[0].message.content def gen_code(client, task, plan): resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: f任务{task}\n\n已确认方案\n{plan}\n\n请严格按方案写完整可运行代码带关键注释。}], temperature0.2, max_tokens4000, ) return resp.choices[0].message.content两段都用推理模型但 temperature 不同方案阶段 0.3 保证结构稳定代码阶段压到 0.2让语法和逻辑更收敛。实际用的时候第一段输出值得人工花三十秒过一遍——方案明显不对就改提示词重跑别等代码写完再返工。这套做法对 500 行以内的独立功能效果最好超过这个规模还得叠加模块拆分不然第二段 prompt 塞太满代码质量会明显下滑。4.2 结构化输出JSON 反序列化的两道保险让模型返回 JSON 是高频需求但模型经常不老实前面补一句「好的这是结果」或者把 JSON 包进代码围栏里再或者布尔值写成中文。解析前做两道保险import json, re content resp.choices[0].message.content # 第一道保险剥掉 json 代码围栏 cleaned re.sub(r^(?:json)?\s*|\s*$, , content.strip()) # 第二道保险只截取第一个 { 和最后一个 } 之间的内容 start, end cleaned.find({), cleaned.rfind(}) cleaned cleaned[start:end 1] try: data json.loads(cleaned) except json.JSONDecodeError as e: # 定位失败位置把片段打出来人工看 print(JSON 解析失败位置:, e.pos) print(cleaned[max(0, e.pos - 40):e.pos 40])第一道正则处理围栏第二道截取大括号区段把模型多说的废话全部排除。解析失败时别只打印错误行把出错位置前后各截 40 个字符出来一眼能看出是尾逗号、中文引号还是字段缺失。更治本的做法是在提示词里加一句「直接输出 JSON不要任何解释」配合上面的两道保险成功率能稳定到九成以上。4.3 长文本处理分块-加工-合并的操作顺序长文改写、翻译、摘要最容易踩的是「一次喂进去输出被截断」。上下文窗口确实够长但输出有上限而且超长输入会拖慢首字延迟。常见做法是分块处理按段落聚合出块每块独立加工最后合并块与块之间不做二次改写避免信息漂移。def process_long_text(client, text, chunk_size1200): chunks, cur, length [], [], 0 for para in text.split(\n): cur.append(para) length len(para) if length chunk_size: chunks.append(\n.join(cur)) cur, length [], 0 if cur: chunks.append(\n.join(cur)) results [] for i, chunk in enumerate(chunks): resp client.chat.completions.create( modeldeepseek-chat, # 改写类任务不需要深度推理用直出模型更快更便宜 messages[{role: user, content: f把下面第 {i1}/{len(chunks)} 段改写为技术博客风格保留术语和数字\n{chunk}}], temperature0.5, max_tokenslen(chunk) * 2, ) results.append(resp.choices[0].message.content) return \n\n.join(results)分块按段落边界不在句子中间硬切。chunk_size 1200 是经验值中文大约对应 1200 字模型处理起来既不会丢细节也不会因为块太小失去上下文。这里特意用 deepseek-chat 而不是推理模型改写不需要深度推理直出模式速度快、成本低。合并阶段用空行分隔不做二次加工——很多长文改写出问题的环节就在合并时让模型「顺一遍」一顺就把术语和数字改歪了。5. DeepSeek 落地避坑五个高频翻车现场与排查路径5.1 JSON 总是解析失败代码围栏、尾逗号与中文字符的连锁反应现象提示词明确要求输出 JSON代码一跑 json.loads 就抛异常报错位置每次还不一样。 原因三个隐患叠加——模型在 JSON 前输出「好的」之类的废话把整个对象包在代码围栏里数组末尾多了一个逗号或者 true/false 被写成中文写法。 解决解析前先剥围栏、截取首尾大括号用 4.2 的两道保险兜底提示词里加一句「直接输出 JSON不要任何解释」如果还是失败把出错位置前后片段打印出来人工看一眼是哪种脏数据再决定修提示词还是修解析器。5.2 上下文一长就截断max_tokens 和 max-model-len 是两个变量现象输入三千字后输出停在半句话像是被硬生生切断。 原因把 max_tokens 当成了总长度限制但它只管单次输出输入和输出的总预算是服务端上下文窗口本地部署则对应启动参数里的模型上下文长度。 解决API 端先调大 max_tokens再确认总和没超过套餐上下文上限本地部署要重新审视上下文长度和显存的平衡——从 8192 拉到 32768KV cache 占用的显存可能翻好几倍速度也会明显下降。5.3 推理模型答非所问把「请一步步思考」喂给了 R1现象用推理模型处理简单分类或短问答回答又长又绕正文里甚至出现「让我想想」这类口水话。 原因推理模型内部已经有一轮思维链你再要求它逐步思考它倾向于把思考过程外化到正文里既浪费 token也让输出结构散掉。 解决简单任务换成通用对话模型复杂任务只给目标、约束和输出格式不给思考路径正文一出现自我对话的口吻马上检查是不是提示词里混入了「逐步思考」这类指令。5.4 本地部署慢到没法用显存、量化与上下文长度的三角关系现象模型能启动但一个短回答要半分钟并发两个请求直接卡死。 原因显存不够触发 CPU offload权重在内存和显存之间来回搬运没开注意力优化上下文长度设得过大KV cache 把显存挤没。 解决推理优先选择为生产设计的服务框架而不是逐行推理的库显存吃紧就开 4bit 量化同时把上下文长度从 32768 降回 81927B 级别至少准备 16GB 显存32B 级别直接按 24GB 以上规划别想用内存硬扛。5.5 API 费用失控系统提示词越长每次调用越贵现象调用次数没涨多少账单却翻了几倍。 原因每次请求都带着完整 system prompt 和全部历史记录system prompt 写成了八百字小作文对话轮次一多输入 token 成倍增长。 解决system prompt 压到 500 字以内只留角色和关键约束对话历史用滑动窗口只保留最近若干轮大批量固定格式任务迁到本地跑。还有一条某个提示词模板长期不变的话优先确认平台是否提供缓存能力别让同样的字被反复计费。6. 从会用变成精通给 DeepSeek 建一个固定回归集会用和精通的分界线不是会写多少种提示词而是手里有没有一把固定的尺子。我的习惯是维护 20 条样本覆盖代码审查、JSON 抽取、长文改写、问答四类典型任务每条配一个「通过/不通过」的判定标准改任何提示词或参数之前先跑一遍全集记下通过率。cases [ {name: 代码审查, prompt: ..., check: lambda x: 并发 in x}, {name: JSON 抽取, prompt: ..., check: lambda x: json.loads(x)[id] 42}, # 其余样本同一结构扩展check 写可自动判定的规则 ] report [] for case in cases: output call_model(case[prompt]) # 封装你自己的模型调用 report.append((case[name], case[check](output))) passed sum(ok for _, ok in report) print(f通过率{passed}/{len(cases)})样本里要混入两三条非常简单、稳定的用例它们是看门狗——复杂用例全过了、简单用例反而挂了说明提示词改动把基础能力带偏了。有一次我把 system prompt 从 300 字扩到 800 字直觉上更完备回归集一跑通过率掉了 15 个点原因就是角色描述太长模型开始过度解释该直接给结论的地方绕圈子。从那以后我养成两个习惯改完必跑回归集跑完把提示词版本和通过率记在一起同一个任务至少跑三次取稳定结果不拿单次输出当结论。这套标尺一开始维护会嫌麻烦攒到三五十条之后你会发现它才是真正让自己从「会用」走到「精通」的东西。希望帮到你。本文还有配套的精品资源点击获取
