简介由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的《DeepSeek从入门到精通》高清PDF完整覆盖DeepSeek是什么、能做什么、如何使用三大核心问题并系统拆解推理模型与通用模型的能力边界、快思慢想的工作机制、提示语策略差异以及数学证明、创意写作、代码生成等典型任务的模型选型与提示语设计面向AI学习者、内容创作者和开发者从零基础讲解到进阶应用。资源为1个PDF文档大小5.39MB排版清晰、支持检索与批注可离线随时查阅。目前已有7095人学习下载是了解国产开源大模型应用逻辑的高人气入门资料。内容涵盖文本生成、语义理解、代码生成、联网搜索与深度思考等场景结合具体示例引导读者从“下达指令”转向“表达需求”并给出避免提示误区的实用建议帮助读者真正用好DeepSeek。1. 一份标着“高清免费”的DeepSeek资料为什么很多人看完还是不会用网上流传着一份《DeepSeek从入门到精通》的资料标着某高校的名义还带着“高清免费”的字样不少人的网盘里都存了一份。但真实情况是存了资料不等于会用。我见过不少人照着资料里的对话示例聊了几轮转头面对自己的实际任务还是不知道提示词该怎么写、参数该怎么调。我的判断是从入门到精通的关键不在那份资料本身而在于你看完之后有没有建立一套自己的使用闭环选对模型模式、写清任务约束、调好输出参数、再从翻车对话里反推改进。这篇文章就是把这套闭环拆开讲用可以直接抄走的提示词模板和参数说明带你把DeepSeek真正用起来而不是停留在“问一句答一句”的聊天层面。适合刚接触DeepSeek的新手也适合已经用了一阵子但总觉得输出不稳定的熟手。2. DeepSeek是什么模型模式、上下文边界与最小可运行调用2.1 先说通用模型和推理模型选错模式是第一个翻车点DeepSeek对外提供两类模型能力一类是通用对话模型一类是推理增强模型。很多人不知道这件事以为同一个模型能搞定所有问题结果在需要逻辑推演的数学题上问出了错误答案或者在只需要快速回复的闲聊场景里等来了冗长的思考过程。通用对话模型的优势是响应快、语气自然适合日常写作、头脑风暴、文本改写这类不需要严格推导的任务。推理增强模型则会在最终回答前内部走一段较长的思维链把问题拆解、验证、再收敛适合数学计算、代码调试、策略分析这类需要多步推理的场景。用反了就很尴尬拿通用模型解一道复杂的动态规划题它会一本正经地给出一个看起来合理但跑不通的方案拿推理模型问“帮我写一句欢迎语”它会给你输出一大段分析过程最后才补一句结论。我的做法是在系统提示词里直接声明当前任务需要哪种模式。如果用户明确要了推理模式我会把任务描述写成“需要分步骤推导后再给结论”如果是通用模式我会让任务聚焦在“直接输出不要解释”。选模型模式这件事比调任何提示词都优先——模式选错后面怎么调都像在给错误的方向打补丁。对比一下更直观对比项通用对话模型推理增强模型适用场景写作、改写、摘要、闲聊数学、逻辑、代码、策略分析响应速度快较慢需要内部推理输出风格直接给结果带推导过程或解释典型误用用来解复杂算法题用来问简单事实问题这里的关键不是记参数名而是建立一种条件反射任务里带有明确的逻辑链条或数值计算就走推理模型任务只是语言表达层面的转换或润色就走通用模型。很多人就是没做这一步区分才觉得DeepSeek“时灵时不灵”——其实灵与不灵很大程度取决于你问的方式和模型模式的匹配程度。2.2 上下文长度与输出长度先定边界再写提示词DeepSeek的上下文窗口支持得很长长到可以塞进一整份技术文档或者几十页对话记录。但上下文长不等于用得越长越好。上下文越长模型对信息的注意力会被稀释中间的细节容易被“遗忘”同时单次请求的延迟和费用都会上升。所以每次写提示词之前我都会先估算两件事这个任务需要多少输入信息需要多少输出内容。输出长度的控制是通过一个参数完成的通常叫 max_tokens。它的作用是限制模型最多生成多少个词元相当于给输出画了一条上限线。很多人的翻车现场是让DeepSeek写一篇长文写到一半突然停了看起来像“卡住”其实是没有把这个参数调大模型默认只生成了几百个词元就撞到了上限。温度参数同样值得注意。温度控制的是生成的随机性温度越低输出越稳定、越保守适合代码和结构化内容温度越高输出越多样、越有发散性适合创意文案和头脑风暴。我的习惯是代码和数据处理任务把温度压到 0.3 甚至 0.1文案类任务放到 0.7 到 0.9。这里没有绝对正确的数值但如果你发现同样的提示词每次回复差别很大那大概率是温度太高了。整理成参数表方便直接抄参数作用常见取值我的默认值max_tokens限制输出长度5128192长文 4096短文 1024temperature控制随机性02代码 0.3文案 0.8top_p控制候选词范围01保持默认不常调stream是否流式输出true / false长回复用 true这里还涉及一个常被忽略的细节上下文长度和输出长度是同一个预算里的两面。如果上下文窗口是 128K你一次性塞进去 120K 的输入那模型能留给输出的空间就非常有限了。所以写提示词时如果输入内容太长我会先做一步缩减——只保留和任务直接相关的片段而不是把整份文档原封不动丢进去。2.3 用一次真实API调用把DeepSeek跑起来理论说完了直接上最小可运行的调用代码。不管那份资料里是怎么讲架构的落到实际使用绝大多数人走的是API调用这条路。下面这段代码是我常用的最小调用模板用 Python 的 requests 库就能跑通不需要额外安装重依赖。# 调用DeepSeek API的最小示例 import requests url https://api.deepseek.com/chat/completions # 接入地址按实际情况替换 payload { model: deepseek-chat, # deepseek-chat 或 deepseek-reasoner messages: [ { role: system, content: 你是一名Python代码助手只输出代码和简短说明不要输出多余内容。 }, { role: user, content: 写一个Python函数把列表中的重复元素去掉并保持原有顺序。 } ], max_tokens: 1024, # 限制输出长度 temperature: 0.3 # 低温度让代码输出更稳定 } headers { Authorization: Bearer YOUR_API_KEY, # 换成你自己的密钥 Content-Type: application/json } resp requests.post(url, jsonpayload, headersheaders) data resp.json() print(data[choices][0][message][content])这段代码的逻辑很简单构造一个包含 system 和 user 两条消息的请求体POST 到对话补全接口然后从响应里取出模型生成的内容。system 消息用来设定模型的整体行为user 消息放任务本身。这里我建议你花点心思在 system 消息上——很多人只写 user 消息把系统提示词当摆设但系统提示词才是稳定模型行为最有效的位置。参数说明直接对着代码看max_tokens 设成 1024对这个任务来说足够temperature 设成 0.3避免同一个问题每次生成的代码差别太大。如果你的任务是写一份长报告把 max_tokens 调到 4096如果是头脑风暴类任务把 temperature 调到 0.8。如果你在本地部署接口地址要换成你本地服务监听的端口模型名也要看部署时实际加载的权重但请求结构完全一致。换模型名、调参数、改消息内容这套骨架能覆盖绝大部分日常任务。3. 把提示词当参数调四条可抄的进阶写法3.1 角色、任务、约束、示例一个通用的提示词骨架很多人写提示词的方式是“帮我写一个方案”“分析一下这段代码”这类问法不是不能用而是太依赖模型自由发挥。同样的任务不同时间问结果的稳定性和可用性会有明显差异。要降低这种方差我一般用四段式骨架角色、任务、约束、示例。你是一名{角色}。 任务是{具体任务}。 约束 - {约束一例如字数范围} - {约束二例如必须包含的内容} - {约束三例如禁止出现的内容} 示例 {输入示例} {输出示例} 现在请处理{实际输入}这个骨架的逻辑是角色让模型调用对应的知识组织方式任务把目标锁死约束把输出的边界画出来示例则告诉模型“正确输出长什么样”。四段里初学者最容易省掉的是约束和示例而恰恰是这两段对输出质量的影响最大。约束可以直接消灭一半以上的翻车情况示例则能把模型的输出格式拉到预期轨道上。举个例子说明差别。如果直接问“给我一个产品推广方案”模型给出来的会是一堆正确的废话渠道、预算、时间节点什么都提了什么都不落地。但如果提示词写成“你是一名消费品行业的产品经理任务是为一款面向学生群体的文具做一个推广方案约束预算不超过5万元必须包含线上和线下两个渠道活动时间不超过2周输出格式用表格”模型的产出立刻会变成可以直接拿去开会讨论的东西。这里有一个容易被忽略的点约束不是写得越多越好。约束写太多模型会为了同时满足所有条件而顾此失彼。我一般控制在三到四条且优先保留“可验收”的约束——比如字数、格式、必须包含的内容。那些听起来很严谨但没法客观判断的约束比如“要专业”“要有洞察”写了也等于白写。3.2 用分隔符隔离指令与内容避免模型“自由发挥”的三个写法让模型区分“指令”和“待处理的内容”是提示词工程里最容易出效果的一步。很多任务翻车不是模型能力不够而是它分不清哪句话是要求、哪句话是素材。最常见的例子你给模型一段用户评论让它做情感分类它把评论里的话当成了对自己的指令回复得前言不搭后语。解决办法是用分隔符把内容和指令隔开。我常用的三种分隔符是XML标签、Markdown代码块标记、以及固定语义的占位符。下面这段提示词展示了XML标签的写法把下面feedback标签内的用户反馈归类为投诉、建议、咨询。 只输出类别名称不要输出解释。 feedback 你们的App更新之后闪退了好几次我都卸载了再这样我就换别的产品了。 /feedbackXML标签的好处是语义清晰模型几乎不会混淆标签内外的内容。Markdown代码块标记适合处理长文本比如代码或Markdown格式的文档因为它天然支持多行内容。固定语义的占位符则适合你在自己的程序里做模板替换比如用两个大括号包住变量位置。使用分隔符时有一条很实用的原则指令里不要出现跟待处理内容长得像的内容否则分隔符也救不回来。比如你要处理的是程序代码指令里就别再贴一段代码当做示范。如果确实需要示例把示例也放进另一个独立的分隔符里并明确标注“这是示例”。3.3 思维链与输出格式给模型画好“跑道”思维链这个词在资料里被反复提及但实际使用中很多人对它的理解有两个极端一是什么任务都要求“一步步思考”二是什么任务都拒绝模型多想。我的经验是要区分模型类型来对待。如果你用的是推理增强模型它内部已经会走思维链你不必在提示词里反复强调“请思考”反而应该要求它“给出结论”。你可以这样写先一步步分析最后在 标签里给出结论。这样既保留了推理过程的可靠性又控制住最终输出的格式。如果你用的是通用对话模型那么“请先写出你的分析过程再把最终结论放在最后一段”这类写法是有用的能显著提升复杂任务的准确率。但要注意限制分析过程的长度否则模型会在过程里绕圈子。我的写法是先给出分析过程不超过200字再给出最终结论。输出格式控制是另一件容易被忽略的事。让模型输出JSON、表格或特定结构时最有效的手段是在提示词里给出一个输出示例。这是API调用里常用的 JSON 约束写法# 要求模型输出结构化JSON的提示词写法 payload_example { role: user, content: 从下面这段文字中提取公司名称、融资轮次、发布时间。 只输出JSON格式如下 {company: 公司名, round: 轮次, date: 发布日期} 待处理文字某AI公司今天宣布完成新一轮融资本轮由多家机构参与。 }逻辑说明先在提示词里给出一个输出格式模板模型就会按这个结构生成内容。这比单纯说“以JSON格式输出”有效得多因为模型不需要猜测字段名和嵌套结构。参数层面这类任务要把 temperature 调低到 0.2 左右并在 system 消息里加一句“只输出JSON不要输出其他内容”。如果你发现模型偶尔还是会在JSON前后加解释文字就在代码里增加一步解析校验解析失败时自动重试一次而不是手动去改提示词。4. 在真实任务里迭代从“能回答”到“能交付”4.1 代码生成给约束、给输入、给验收标准前两章教的是把提示词“写对”这一章讲的是让它“能交付”。很多人跟DeepSeek的交互停留在“问一句、答一句”但真实的工程场景里你要的是能直接用或稍加修改就能用的产物。以代码生成为例我见过的最常见提问方式是“用Python写一个爬虫”“写一个登录接口”这种任务描述太宽泛模型只能给出一个通用骨架离可用还有很长距离。我的做法是在提示词里同时给出输入、约束和验收标准。输入告诉模型它要处理什么约束告诉它该怎么做验收标准告诉它做到什么程度算完成。下面是一段我常用的代码生成提示词你是一名Python后端工程师。 任务写一个函数从给定URL列表批量下载文件并保存到本地目录。 约束 - 使用requests库不用其他第三方依赖 - 支持重试机制失败重试2次 - 下载时显示进度 - 代码里包含必要的异常处理 验收标准输入urls列表和save_dir路径函数能逐个下载文件下载失败的文件记录到日志而不是中断整个流程。把这段提示词和“用Python写一个批量下载程序”对比一下后者得到的代码大概率需要你自己补重试、补异常处理、补进度显示前者得到的代码基本可以满足需求你只需要做小幅度调整。差别不在模型能力而在你描述任务的颗粒度。逻辑说明代码生成任务里约束的优先级最高。模型默认生成的代码是“最简可用版”你不想让它省略的部分必须明确写在约束里。我的实践经验是每条约束对应一个验收点写了“失败重试2次”那么代码里就必须有循环和计数逻辑写了“不依赖其他第三方库”它就不会擅自用tqdm之类的东西。生成之后我会把代码放进本地跑一遍测试用例而不是直接复制进项目——这一步能发现很多提示词里没约束到的边界情况。4.2 文档整理用输出模板锁住格式DeepSeek处理长文本的能力很强但强不等于听话。它的默认输出风格是“流畅的段落式叙述”如果你需要的是结构化产出比如会议纪要、问题清单、复盘报告就必须用输出模板锁死格式。这是我的常用做法先给出模板再输入原始材料。把下面的会议记录整理成结构化纪要按这个模板输出 【会议主题】 【参会人员】 【讨论要点】 1. xxx 2. xxx 【决策事项】 1. xxx负责人xxx截止时间xxx 【待跟进事项】 1. xxx跟进人xxx 会议记录原文 xxx这里粘贴原始记录这段提示词的关键在于模板先行。模型看到模板后会把原始材料里的内容往模板的各个字段里填而不是自己重新组织一套结构。整理长文档时如果原始材料超过上下文预算我的习惯是先让模型分段落生成“摘要片段”再把片段合并成最终结果。分段处理能避免长上下文带来的注意力稀释问题缺点是会多调几次接口但换来的是每一段的质量都更稳定。文档整理还有一个容易踩坑的地方模型会把原文里没有的信息“脑补”进模板。比如原文只讨论了三个事项模型可能在“决策事项”里补出第四个。解决方法是加一条约束“只整理原文出现过的内容不要补充原文没有的信息。”这一句看起来简单实际能把脑补问题的发生率降低大半。输出格式锁得越死模型自由发挥的空间就越小稳定性就越高。4.3 把高频任务固化成提示词模板一次调好反复使用如果你每天都在做重复性任务比如处理客服工单、写周报、做代码审查那就值得把提示词固化成模板。我的习惯是这样第一次用的时候先写一个基础版提示词跑完看结果如果结果里有不满意的地方加一条对应的约束反复迭代几轮之后把最终版本存成模板文件。这个模板就是你个人的“提示词资产”。# 模板周报生成器 你是一名项目负责人。 任务根据下面的工作日志生成周报。 约束 - 每条工作项不超过50字 - 按“已完成、进行中、风险与问题”三组分类 - 风险与问题条目必须给出影响说明 - 不要补充日志中不存在的任务 输入工作日志 {日志内容}模板的迭代逻辑跟调试代码一样每发现一个输出缺陷就追加一条约束或示例来修正。比如模型总是把“进行中”的工作写成“已完成”你就加一条约束“只有标注了完成日期的任务才能放进已完成组”。模板迭代的底层逻辑是利用模型的反馈来反向修正提示词而不是每次从头写。几个边界的提醒模板里的变量要用花括号或占位符标出来方便程序替换内容模板本身要定期复查如果任务类型变化太大别硬套旧模板重新写一份更快。通用模板在不同任务间的迁移效果有限一个给客服工单设计的模板拿去生成法律文书效果不会好因为约束和示例都是从原任务里提炼的迁移时最好针对新任务做一轮重新迭代。5. 避坑从入门到翻车的四个高频问题与排查清单5.1 现象输出被截断回答停在半路这是最高频的问题让DeepSeek写代码、写文章写到一半突然停了看起来像网络断了一样。其实绝大多数情况是 max_tokens 撞到上限了模型不是不想写了是生成预算用完了。原因分析很多人调用时没有显式设置 max_tokens用模型默认值。默认值对短问答够用但对付不了长文生成和长代码。另一个容易被忽略的因素是上下文窗口的占用输入内容太长时留给输出的空间会被压缩。解决把 max_tokens 调整到足够大的值比如长文生成调到 4096 甚至更高。如果单次生成了好几千词元仍然不够就别硬撑了改成多段生成——第一段生成主体内容后面用上一段结尾作为输入继续生成最后人工合并。这类问题的排查步骤我固定为三步先看返回的 finish_reason 字段如果是 length 而不是 stop说明是截断再查请求里的 max_tokens最后看输入长度占了多少上下文窗口。三步走完问题基本定位。5.2 现象上下文一长就“失忆”前后回答对不上对话进行到几十轮之后模型开始忘记前面说过的话——比如前面明确说了用某种格式输出后面几轮又回到了默认格式。这不是模型坏了是长上下文的注意力稀释和早期内容的压缩导致的。原因分析长对话或长文档场景下模型对中间部分的记忆不如开头和结尾清晰。越早的信息在模型内部可能被压缩得越厉害导致关键约束“漂移”。解决有三个实操手段。第一把最重要的约束放在 system 消息里或者放在每轮 user 消息的开头重复一遍这能显著提高约束的保持率。第二每经过一段对话让模型把已确认的关键信息重新输出一次再带着摘要继续下一段任务相当于给对话做压缩归档。第三不要把一百轮的对话当上下文一次性提交按任务拆成多次独立的请求每次只带相关历史。如果你发现模型连续几轮都“忘事”大概率不是提示词问题而是任务设计本身对长上下文的依赖太重了这时候要改任务结构而不是继续堆提示词。5.3 现象推理模式在简单任务上过度思考让DeepSeek解一道算法题它给了非常详细的推导过程最后答案也是对的但整体耗时比预期高出一大截让它写一句欢迎语它先分析了用户心理和品牌调性再给出三个版本有用但严重“超配”。原因分析你把推理增强模型用在了不该用它的场景上。推理模型的内部机制决定了它遇到任何问题都会先走一段思维链即使这个问题简单到不需要推理。解决为任务匹配模型模式。简单事实类、写作类、转换类任务用通用对话模型数学、逻辑、策略、代码调试类任务用推理模型。判断标准是一个“是否涉及多步推导”的问题如果回答能一步到位就选通用模型。如果你只能用一个模型那么在提示词里加一句“直接给出答案不要分析过程”对推理模型也会产生一定的约束效果但不如直接换模型模式来得彻底。5.4 现象输出格式不稳定该JSON的时候带出解释文字要求模型输出JSON结果它输出了JSON加一段“以上是我的回答”之类的文字。解析时报错整个流程直接断掉。原因分析模型默认倾向于输出自然语言提示词里的格式要求写得不够“硬”。如果系统消息里只说“输出JSON”而不强调“只输出JSON”模型会认为解释文字是被允许的。解决用三重约束锁格式。第一在 system 消息里写明“只输出JSON不要输出任何解释性文字”第二在 user 消息里给出输出模板让模型照着填第三把 temperature 调到 0.2 以下降低模型“发挥”的可能性。代码层面在解析 JSON 时要做异常兜底提取第一个出现的大括号开始到最后一个大括号结束之间的内容再解析而不是直接对整段返回做解析。这三个手段叠加格式不稳定的概率会降到很低。6. 从会用走向精通给自己的提示词建一套“回测”习惯最后一个技巧也是我眼里“入门”和“精通”之间最实在的分水岭把提示词当成代码来管理给每一份常用提示词建一套回测用例。我见过太多人收藏了一大堆提示词模板真正要用的时候不知道哪个好随便试了几个效果不稳定就换了下一个。问题的根源是没有“验证”这个环节——提示词到底好不好用不是看它写得漂不漂亮而是看在固定输入下能不能稳定产出预期结果。我的做法很简单给每个核心模板维护一组测试输入和预期输出。每次修改模板之后跑一遍同一组测试用例对比输出质量修改生效再更新模板版本。这个习惯的成本不高收益却很直接一段时间之后你手里留下的模板都是经过验证的而不是看过就算的。可以建立一个简单的表格来跟踪模板名称测试输入预期输出实际结果问题记录周报生成器三天的日志分类清晰、无脑补在售问题记录代码审查助手一段带bug的代码指出问题并给修复建议在售问题记录会议纪要模板一段会议录音转写格式与模板一致在售问题记录表格不用做大做全三到五条核心用例就够重点是坚持迭代。回测的价值在于它能让你区分“模型能力问题”和“提示词设计问题”。如果换了好几种提示词写法输出质量都没有明显变化那大概率是任务本身超出了模型的可靠能力边界这时候该调整的是任务拆解方式而不是继续在提示词上堆力气。我自己在这个方向上有过一次印象很深的踩坑就是执着于用一段复杂的提示词让模型输出结构化数据试了十几种写法都不稳定。后来把任务拆成两步第一步先让模型提取关键内容第二步再按模板重排效果立刻稳定了。从那之后我养成了一个习惯遇到输出不稳定的情况先想想是不是流程设计的问题而不是条件反射地去改提示词。从入门到精通说到底不是学会多少技巧而是建立一套验证和迭代的闭环。资料可以帮你跨过第一道门槛但真正让你精通的是每一次跟模型交互之后多问自己一句“这次为什么好、下次怎么更好”。希望这个思路能帮你在DeepSeek这条路上少走一段弯路。本文还有配套的精品资源点击获取
