简介《DeepSeek从入门到精通》出自清华大学新闻学院与人工智能学院团队是一份面向AI研究人员、大模型开发者及希望借助提示语设计提升模型效能的从业者的技术指南。全书以“DeepSeek是什么、能做什么、如何使用”为主线先厘清DeepSeek-R1作为开源推理模型的特点再对比推理模型与通用模型在数学推导、代码生成、创意写作等任务上的优劣同时比较快速反应模型与慢速思考模型的适用场景随后围绕智能对话、文本生成、语义理解、知识推理和编程场景讲解由“下达指令”到“表达需求”的提示语策略并给出指令驱动、需求导向、混合模式、启发式提问等具体方法。资源共1个PDF压缩包大小5.4MB便于按章查阅。已有3002人学习下载适合作为从基础认知到自主进阶的参考手册也可用于日常AI协作的效能优化。1. 《DeepSeek从入门到精通》免费下载开放了这本书能解决什么问题值不值得读出版方把《DeepSeek从入门到精通》做成免费电子版放出来之后收藏的人多真正读完的人少。我见过不少从业者的情况是PDF 存进网盘等真要写提示词、调 API 的时候还是回到聊天框里凭着感觉来。这本书的价值恰恰在于把「提示词怎么设计、上下文怎么喂、结构化输出怎么要」这些散在各处的东西串成一条线省掉你自己摸索的机会成本。它解决的是「从会用网页版到能把模型接进自己工作流」这一步。适合的读者是想用 DeepSeek 处理报表、写周报、做知识库问答的从业者以及刚接触大模型开发、需要一条可靠入门路径的新手。纯做研究的人可以跳过里面偏操作的部分直接看 API 参数和 JSON 输出这两块就行。下面按入门最常见的学习路径展开先提示词再 API 命令然后是结构化输出和一段避坑清单。每个部分都给了可以直接抄的写法照着跑通一遍比存十份 PDF 有用。2. 先把提示词这块地基打好角色、任务、约束、输出格式怎么组合才不翻车DeepSeek 这类大模型输入输出的唯一交互界面就是文字。提示词不是「问得礼貌一点」而是你控制模型行为的完整协议。这类入门书最前面几章基本都在讲同一个道理提示词的结构化程度直接决定回答能不能直接用省掉后续大量人工修改。我一般把提示词拆成四个要素角色、任务、约束、输出格式。角色决定语气和信息筛选的偏好任务说明要做什么约束划出边界输出格式决定要不要二次加工。四者缺一个回答就很容易变成「正确的废话」——语法通顺、内容无害但落到具体场景里用不上。2.1 上下文窗口为什么教程把「喂上下文」放在提示词前面上下文窗口是模型单次能接收的文字总量。窗口大不代表要把所有资料一次塞进去。很多人刚上手时长上下文很兴奋把几千行日志、几十页文档全贴进去结果回答反而变差模型注意力被无关信息稀释关键约束被淹没在大量冗余文本里。常见的做法是「按需喂」先把业务规则写成 system prompt再把最近、最相关的数据片段放进 user 消息。比如做客服知识库只放当前用户问的那一类 FAQ而不是把整份知识库都丢进去。做周报只放这一周的工作日志不用把上个月的一起贴。这类书里反复强调的另一个点是示例比描述更有效。你想让模型按某种格式输出与其描述半天不如给它一条真实样例再用「仿照上面的格式」收尾。这一步看着简单实际对输出质量的提升非常明显我几乎每个正式任务里都会放一个输出示例。上下文窗口还有一个实际影响token 就是成本。窗口越大单次请求的输入费用越高。别把上下文当免费内存用能裁剪的先在代码里裁剪好再发请求。2.2 一个可以直接抄的提示词模板与参数影响下面这个模板我配合 DeepSeek 用了很久覆盖大部分办公场景直接复制改内容就能用角色你是一名熟悉[业务领域]的资深分析助手。 任务根据我提供的[素材类型]整理成[交付物名称]。 约束 1. 只能使用素材中出现的信息不许编造或补充 2. 处理结果不超过[条数/字数] 3. 遇到素材缺失的信息在末尾单独列出「待补充项」。 素材 [粘贴原始内容] 输出格式 [示例或格式描述]参数方面最常调的是 temperature。它控制随机性数值越低回答越稳定保守越高越有发散性。事实提取、格式转换这类任务我习惯固定在 00.3文案创意、头脑风暴可以放到 0.71.2。top_p 一般保持默认 1.0多数情况下不需要和 temperature 同时调。任务类型temperature 建议说明事实抽取、格式转换00.3稳定优先禁止发散改写、摘要0.30.7保留一定润色空间创意写作、头脑风暴0.71.2需要多样性和发散调参这件事很容易陷入玄学同一个提示词同一批参数不同时间跑出来的结果也会有细微差异。应对办法是给任务加「可验证的约束」比如要求输出 JSON、要求不出现某个词、要求必须引用素材原文而不是靠反复调温度赌运气。跑题是提示词阶段最常见的翻车点。模型回答得很好但不是你要的东西大概率是任务描述里少了「给谁看」和「用来干什么」。写周报就写明「给直属上级看控制在半页 A4」模型自然会把细节收敛掉。2.3 用示例对替代命令式描述比指令更稳的写法命令式写法把下面的数据按重要程度排序。模型能执行但排序依据、呈现形式全靠它自己猜十次可能给出十种不同格式。示例式写法输入项目A 延期3天项目B 增加2人项目C 正常推进项目D 预算超支5%。 输出 1. 项目D预算超支风险最高 2. 项目A延期影响后续排期 3. 项目B人力增加可控 4. 项目C状态正常模型对模仿样例的偏好远高于理解抽象指令。给它一个输入输出对再补一句「严格按照上面的格式输出」基本不需要第二次返工。如果效果还不够就在示例里加一个反例标注「不要这样做」比单纯强调约束更直观。3. 把书里的例子变成能跑的命令API Key、curl 与 Python 客户端的最小路径网页版玩得再熟也替代不了写进脚本。要让 DeepSeek 进入工作流第一步是把「在聊天框打字」换成「向接口发请求」。这一步打通之后后面接定时任务、接内部系统、做自动化都是同一套逻辑。3.1 先确认两件事模型名和 base_url调用之前把两个信息写进配置模型名和 base_url。模型名决定行为deepseek-chat 是通用对话模型适合日常总结、抽取、问答deepseek-reasoner 是推理模型适合数学、逻辑、复杂拆解响应更慢价格也不同。base_url 是这个接口的根地址客户端会在此基础上拼出 /chat/completions 路径。第一次写代码时最容易错的就是这两个值模型名写成网页版的展示名或者 base_url 多了个 /v1。我的建议是把它们放到环境变量或配置文件里不要在代码块里写死。选型思路很简单任务需要推理、计算、一步步拆解就选 reasoner只是总结、提取、改写选 chat 就行便宜且快。没有必须「更贵的模型更好」这回事匹配任务才是关键。3.2 用 curl 打通第一个请求把「连接不上」和「代码问题」分开export DEEPSEEK_API_KEY你的key curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 用一句话解释什么是上下文窗口} ], temperature: 0.3, max_tokens: 100 }这条命令做的事情向 /chat/completions 接口发一个 POST 请求HTTP 头里带认证信息请求体里指定模型、消息列表和生成参数。返回内容里 choices[0].message.content 就是模型回复。参数说明messages 数组里的 role 有三种常用取值——system 放系统指令user 放用户输入assistant 用于多轮对话时把历史回复带上。temperature 这里设 0.3因为解释类任务需要稳定max_tokens 限制单次最长输出超过就截断别设太小的值。如果这条命令返回 JSON 结构说明 Key、地址和模型名都没问题如果返回 401检查 Key 是否正确返回 404检查路径或模型名。curl 通了再写 Python排错范围会小很多这是最快的验证路径。3.3 用 Python 封装成本地函数把重复请求收进一个入口日常脚本里我习惯用官方兼容 OpenAI 的 Python SDK 来做一个函数封装掉鉴权、请求、超时和返回提取。这样上层业务代码不需要关心接口细节。from openai import OpenAI client OpenAI( api_key你的key, base_urlhttps://api.deepseek.com, timeout60, ) def ask_deepseek(system_prompt: str, user_content: str, temperature: float 0.3) - str: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperaturetemperature, max_tokens1024, ) return resp.choices[0].message.content if __name__ __main__: print(ask_deepseek(你是一个行政助手。, 把下面这段话改成一封通知...))这里把 base_url 和 api_key 放进 OpenAI 客户端是和 DeepSeek 接口兼容的关键写法。timeout60 是给整次请求设置的等待时间网络不稳定时可以调到 120但不宜过长避免脚本卡死在那里等不到返回。temperature 要按任务传改写通知这类轻度创作可以 0.7数据抽取或整理必须 0.2 以下。max_tokens 设 1024 是为了防止个别任务输出过长把单次响应控制在成本范围内如果发现回答经常被截断说明输出确实长该调大而不是硬撑。提示第一次写 Python 客户端时Key 不要硬编码在脚本里用环境变量加载。这样后面接定时任务或 CI 时不会把密钥带到代码仓库里。封装成函数后其他脚本只需要 import 这个 ask_deepseek不用每次关心 Key 怎么传、地址填什么。团队协作时别人也只需要改参数不用重写请求逻辑。4. 让 DeepSeek 输出程序能直接吃的 JSON结构化输出的两种姿势网页版聊天无所谓格式但接进程序就需要 JSON。这一步是「能跑」到「能用」的分水岭。很多人卡在这里不是因为请求写错而是因为模型默认输出根本不适合直接解析。4.1 为什么默认输出不适合直接落库默认情况下模型会在目标内容前后加解释、Markdown 标记甚至客套话。直接 json.loads() 几乎必然报错很多人第一次在这里翻车还以为是自己代码的问题。解决方向有两个一是开 JSON 模式让模型只输出合法 JSON二是在输出里做兜底提取。两个都要会因为 JSON 模式不是万能的遇到旧接口、参数不生效或者特殊字符时兜底解析能救你一次。4.2 用 response_format 开 JSON 模式让模型只吐 JSONfrom openai import OpenAI client OpenAI(api_key你的key, base_urlhttps://api.deepseek.com) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是信息抽取助手。只输出JSON不要输出其他文字。}, {role: user, content: 从下面简历中抽取姓名、工作年限、技能列表。\n原始文本...}, ], response_format{type: json_object}, temperature0, ) content resp.choices[0].message.content print(content)response_format 的关键点是它保证输出是合法 JSON但不会保证字段名和结构符合你的预期。字段名需要你在提示词里显式写出来比如「姓名」「工作年限」「技能列表」作为 key。想更稳就把期望的 JSON 示例一并放进提示词里让模型照着填。temperature 在这里必须设 0。稍微拉高一点JSON 可能合法但字段乱序、空值变多。抽取类任务和 JSON 模式是固定搭配我基本上不会再单独调高。4.3 JSON 字符串常见的坑与兜底解析就算开了 JSON 模式也可能遇到三种情况返回内容带了反引号代码块JSON 被截断或者内容里混入多余解释。所以落库前我会再包一层兜底解析避免偶发情况直接搞崩线上任务。import json import re def safe_json_loads(content: str): if not content: raise ValueError(empty content) # 去掉常见的 markdown 代码块包裹 content re.sub(r^(?:json)?\s*|\s*$, , content.strip()) try: return json.loads(content) except json.JSONDecodeError: # 多数情况是前后有多余文本把第一个 { 到最后一个 } 之间的部分截出来 match re.search(r\{.*\}, content, re.S) if match: return json.loads(match.group(0)) raisesafe_json_loads 先剥离 markdown 代码块再直接解析失败时用正则抓出最外层花括号之间的内容二次解析。这个兜底能解决九成以上的「合法 JSON 被包在多余文字里」的场景。剩下的少数情况比如 JSON 被 max_tokens 截断、字符串里出现了未被转义的引号正则也救不回来。这种没有后悔药只能回溯调大 max_tokens或者让模型输出的字段更短、更少。不要在解析层死磕尽早回到请求层改提示词。4.4 字段太自由怎么办用工具调用收紧结构如果抽取字段多、层级深JSON 模式加提示词描述依然不够稳可以改用工具调用function calling来定义结构。工具调用的返回体由接口按你声明的 JSON Schema 约束字段名和类型更可靠。tools [ { type: function, function: { name: extract_person, description: 抽取简历中的个人信息, parameters: { type: object, properties: { name: {type: string, description: 姓名}, years: {type: integer, description: 工作年限}, skills: {type: array, items: {type: string}} }, required: [name, years, skills] } } } ] resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 从这里抽取...}], toolstools, tool_choiceauto, ) # 结果在 resp.choices[0].message.tool_calls 里注意工具调用的自动模式不保证每次都调用工具偶尔模型会直接回普通文本。要严格要求时把 tool_choice 显式设成需要的函数名而不是 auto。这算是最接近「黑匣子外面装了个模具」的做法——结构由你定模型只负责往里填内容。5. 避坑清单免费 PDF、模型版本、JSON 解析和本地部署的常见问题这一章按「现象 → 原因 → 解决」整理我踩过的坑按出现频率排序。新手照着这几条排查能省下不少瞎折腾的时间。5.1 下载的 PDF 是扫描版复制代码发现全是乱码现象从 PDF 里复制代码缩进丢失引号变成弯引号代码没法直接执行。原因电子版是扫描件或双栏排版没有可复制的文本层或者文本层是 OCR 识别出来的错误字符。这类文件适合阅读不适合当代码参考。解决优先找出版方官网发布的文本版 PDF如果只有扫描件把代码区块截图用 OCR 工具识别识别完逐行校对。文件名带「最新版」「完整版」的来路不明文件谨慎下载安全性比版本号重要。5.2 API 请求返回 404 或提示模型不存在现象curl 命令完全照书抄返回 404错误信息是模型名找不到。原因模型名写错或者 base_url 路径不对比如多写了 /v1、少写了 /chat/completions。解决以官方开放平台当前文档为准核对模型名和 base_url。先跑第 3 章的 curl 最小命令确认通了你再写 Python不要把两个环节的排错混在一起。5.3 本地部署量化等级选错同一个提示词回答质量明显缩水现象同样的提示词网页版回答有逻辑本地模型开始编数据、说废话。原因显存不够选了很低的量化等级模型能力压缩太狠。量化是拿精度换体积等级越低体积越小能力损失也越明显。解决在显存允许的前提下选更高的量化档位能用 API 的场景优先走 API本地部署只留给有数据隐私要求、不能出网的场景。不要指望小显存机器跑出和官方服务一样的效果那是两套东西。5.4 temperature 拉太高JSON 输出不稳定现象同样的请求有时返回合法 JSON有时字段乱序有时直接解析失败。原因温度设太高模型在采样时飘了。JSON 是强结构任务容不下这种随机性。解决JSON 任务把 temperature 固定为 0并且把输出字段的示例放进提示词。先保证稳定再谈「稍微有点变化」。结构任务里变化不是优点是事故。5.5 书上截图和当前 API 行为不一致现象按书上的参数名或返回字段写代码某些字段取不到值或者某个参数传进去被忽略。原因产品迭代比书快接口或字段有变化。书出版时记录的是当时的行为不能当永久接口手册用。解决把书当作思路参考具体请求以官方在线文档为准。遇到取不到值的字段先打印整个返回 JSON用肉眼确认字段名再写解析逻辑。不要假设字段永远存在。6. 进阶用法把 DeepSeek 从「聊天框」变成工作流里的一个函数6.1 把常用诉求固化成一段 system prompt工作里重复率最高的任务我会把提示词固化成一个常量而不是每次现编。这段是我处理「信息整理」类任务常用的开头你是一个严谨的信息处理助手。 对输入内容执行以下处理先提炼核心结论再按时间线整理关键事实最后列出需要人工确认的不确定信息。 要求不添加输入中不存在的信息不确定处标注「待确认」输出格式为 Markdown 的分节列表。固定 system prompt 有个附带好处可以 A/B 测试。同一批输入换一个词、加一条约束对比输出质量慢慢沉淀出自己业务里最稳的一套配置。这比每次凭感觉写要可复用得多时间越长积累价值越大。6.2 给脚本加流式输出长任务不再黑屏等待同步调用在长输出时会一直等到全部生成完。给脚本加 streamTrue可以边生成边处理体验和响应速度都会好一截排查问题时也能及时看到内容方向对不对。messages [ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 用300字介绍你擅长做的事。}, ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, streamTrue, ) for chunk in resp: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)stream 模式下每一条 chunk 都带一个 delta.content 片段拼起来就是完整回答。注意此时响应对象不是一次性返回不能在循环外直接读 choices[0].message.content。我自己的习惯是先固化 system prompt再决定要不要开流式最后才调参数。某开发者当初把一份几十页的文档一次性塞给模型以为上下文窗口大就万事大吉结果输出质量反而下降后来才明白喂上下文像给新人培训分批发、给重点比全量倾倒有效。这个教训我一直带着。希望帮到你。本文还有配套的精品资源点击获取