简介这份由清华大学新闻与传播学院新媒体研究中心出品的《DeepSeek从入门到精通》PDF面向希望系统掌握DeepSeek大模型及推理模型应用的AI学习者与从业者。内容以DeepSeek公司与开源推理模型DeepSeek-R1为主线系统讲解智能对话、文本生成、语义理解、计算推理、代码生成补全等核心功能并深入对比推理模型与非推理模型在逻辑推理、创意写作、提示语策略上的差异帮助读者根据任务类型选择合适模型覆盖文本创作、长文本摘要、多语言翻译、代码调试等实际场景。资源为单个PDF文件大小4.79MB便于离线阅读。已有174人浏览学习适合想快速入门大模型应用、提升提示词设计能力的学习者。通过阅读可掌握DeepSeek在线聊天工具的使用方法、链式思维CoT的基本概念以及从指令驱动到需求驱动的提示语设计技巧为在实际工作中更高效地应用大模型提供参考。1. DeepSeek 从入门到精通这堂课到底在解决什么问题一份署名某高校的 DeepSeek 从入门到精通讲义过去几个月在开发者圈子里流传得很广。我最早拿到它时以为是又一份提示词大全翻完之后才发现它真正讲的是另一件事大多数人用不好 DeepSeek不是模型不行而是把大模型对话当成搜索引擎来用。这份讲义的核心价值在于它把“怎么把一个问题拆给模型干”这件事从玄学变成了可以照着练的工程方法。本文不评价这份讲义本身只把其中沉淀下来的方法论、参数调优思路和我在实际项目中复现过的落地路径完整展开成一篇可操作的实战笔记。适合正在做智能客服、文档处理、内容生成流水线或者想认真把 DeepSeek 用进日常工作的开发者阅读。2. 先搞清楚 DeepSeek 能干什么从模型选型到能力边界2.1 为什么选 DeepSeek 而不是别的模型成本、上下文与推理能力的三角权衡很多人第一次接触 DeepSeek是被它的价格吸引的。但价格只是表象真正让我长期把它放在生产环境里的原因是它在“上下文长度、推理能力和部署成本”这三者之间给出了一个当前阶段很实用的平衡点。尤其是在中文场景下它对长文本的理解和生成质量在同级别模型里属于第一梯队。我在某公司的知识库问答项目里做过一个直接对比同样的文档检索增强流程换用通用大模型 API 和换用 DeepSeek在召回内容相同的情况下最终答案的完整度提升了接近三成而单次调用的成本下降了一个数量级。这个差距主要来自它对中文长文本的语义把握更稳尤其是处理合同、制度、技术手册这类结构化不强的文本时不太容易出现“读漏了”的情况。当然选型不能只看优点。DeepSeek 的强项是文本理解和生成但在需要严格数值计算、多步逻辑推理的场景下它和专门的推理模型相比仍有差距。我的习惯是涉及复杂数学推导或需要严格逻辑链的任务让 DeepSeek 做第一步的语义理解和信息抽取把结构化的内容再交给专用工具去算。这个分工方式在我做过的模拟项目X里效果很好避免了在一个模型上硬扛所有类型的任务。2.2 两种接入方式API 调用与本地部署的适用场景接入 DeepSeek 有两条主流路径。第一条是直接调用官方 API适合绝大多数应用场景优点是无需操心算力模型永远是新版部署时间以分钟计。第二条是本地化部署开源权重适合数据敏感、必须内网运行或需要对推理过程做深度定制的场景。我在实际项目中总结的经验是如果你的业务是面向终端用户的对话系统直接走 API 集成是性价比最高的选择。你需要做的核心工作其实是两件事一是把业务流程转化成清晰的提示词策略二是做好模型输出格式的校验与容错。而如果你的业务涉及客户隐私数据或内部研发资料那无论如何都要走本地部署哪怕初期成本高一些也不要拿数据安全去冒险。接着看本地部署的最小化操作。假设你已经通过某种方式获取到了模型权重文件使用 Hugging Face 的 Transformers 库加载并做一次推理验证流程如下from transformers import AutoModelForCausalLM, AutoTokenizer # 加载本地模型目录model_path 指向你存放权重的文件夹 model_path ./deepseek-model tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, trust_remote_codeTrue, torch_dtypeauto, device_mapauto ) # 构造一段测试输入验证模型能否正常加载并生成 messages [ {role: user, content: 用一句话解释什么是检索增强生成RAG} ] inputs tokenizer.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt ) outputs model.generate( inputs.to(model.device), max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.9 ) response tokenizer.decode(outputs[0][inputs.shape[1]:], skip_special_tokensTrue) print(response)这段代码里值得注意的几个参数trust_remote_codeTrue是必须的因为 DeepSeek 的模型文件里包含自定义代码不加这个参数会直接报错device_mapauto让模型自动分配到可用的 GPU 或 CPU 上如果你的机器显存不够可以改成device_mapcpu但推理速度会慢很多生成参数里的temperature0.7和top_p0.9是通用推荐值前者控制随机性后者控制候选词范围在做事实性问答时可以把 temperature 降到 0.3 以下。2.3 理解它的“性格”模型行为模式的快速摸底方法每个大模型都有自己的“行为倾向”DeepSeek 也不例外。我建议你在正式开发之前先花一个小时做一轮摸底测试搞清楚三件事它默认回答风格是简洁还是啰嗦、它面对模糊指令时是主动追问还是自作主张、它对事实性错误的坚持程度有多高。快速摸底的做法准备十道不同类型的问题包括事实查询、观点征询、代码编写、文本改写分别用“直接提问”和“带约束提问”两种方式各问一遍对比输出差异。比如同样问“推荐三个适合初学者的编程语言”直接问得到的是通用答案但你加上“请从就业前景、学习曲线、生态成熟度三个维度对比”之后答案质量就会明显提升。做一轮这个测试你对模型的“性格”就有底了后面写提示词时心里会踏实很多。3. 提示词的系统化设计从一句话到一套可复用的方法论3.1 为什么你写的提示词不生效角色、任务、背景、格式四要素拆解我在带 A 同学做毕业设计时发现他最容易犯的错是把提示词当成命令来写。比如直接对模型说“写一篇产品推广文案”这种提示词得到的输出完全靠运气。问题的根源在于模型并不知道你是谁、读者是谁、想要什么风格、字数多少、要不要分点。它只能根据训练数据里的统计规律给出一个“平均”回答。一份有效的提示词至少包含四个要素角色设定、任务描述、背景信息、输出格式要求。角色设定让模型知道用什么视角说话任务描述说清楚要做什么背景信息提供必要的上下文约束输出格式要求控制答案的结构。四者缺一不可。这里给出一个我在智能客服项目中实际用过的提示词模板你是一位资深的技术支持工程师擅长用通俗易懂的语言解释复杂问题。 用户的问题如下 {user_question} 背景信息 - 我们的产品是一款企业内部使用的数据报表工具 - 用户多为非技术背景的业务人员 - 公司内部已有完整的知识库文档但用户经常找不到 要求 1. 用不超过200字回答用户问题 2. 如果问题涉及操作步骤请用分点列表呈现 3. 如果知识库中有相关文档链接附在回答末尾 4. 如果问题超出你的知识范围明确说“需要转接人工”不要编造答案这个模板的核心逻辑是把模型的身份、任务边界、输出约束一次说清楚。尤其最后一条“不要编造答案”能显著降低错误信息的产生概率这是我在多次翻车之后才学到的。模型默认倾向于回答一切问题你必须显式给它“不知道”的权限。3.2 CO-STAR 框架在 DeepSeek 上的实际效果一个五步构建提示词的操作模板如果你觉得每次从零写提示词太累可以用 CO-STAR 框架来做结构化。这套框架是某机构在提示词工程实践中总结出来的全称是Context背景、Objective目标、Style风格、Audience受众、Response响应格式。它比四要素法更细适合构建复杂的业务提示词。我在知乎类问答平台做内容质量评估实验时用 CO-STAR 框架重写了原先的提示词模型输出的可用率从不足六成提升到了接近九成。具体操作步骤如下第一步写清楚任务发生的场景背景第二步写明确的目标第三步指定输出风格第四步说明读者是谁第五步定义回答结构和长度。每一步都写具体不要使用“好的”“请”这类客套词直接给指令。下面是一个利用 CO-STAR 构建提示词的实际案例用于让 DeepSeek 扮演一个招聘面试官# CONTEXT 我正在面试一位有三年经验的 Java 后端开发者应聘岗位需要熟悉微服务架构和分布式系统。 # OBJECTIVE 生成 5 个面试问题考察候选人的系统设计能力和实践经验。 # STYLE 问题风格与一线互联网公司技术面试保持一致注重追问细节。 # AUDIENCE 候选人有三年工作经验了解常见中间件但不一定做过高并发系统。 # RESPONSE 输出 5 个问题每个问题附带 2 个追问方向和 1 个期望回答要点。我在项目中直接套用了这个格式效果比自由发挥稳定得多。需要注意的一点是CO-STAR 框架适合用来构建“每次都在变化”的提示词模板如果你的提示词是固定不变的直接优化一次写死即可不必每次走完整套流程。3.3 结构化提示词的分层设计先定角色再给任务最后锁格式处理复杂任务时我倾向于把提示词做成分层结构而不是一大段文字压给模型。分层的好处是每一层职责清晰模型不容易混淆指令出问题时也好定位是哪个环节的指令有歧义。我的分层习惯是四层结构第一层定义角色和价值观第二层描述任务背景和目标第三层给出具体执行步骤第四层声明输出格式和禁忌。每一层之间用空行隔开层内用关键词标号方便模型识别主次关系。下面是我在文档摘要自动化项目中使用过的分层提示词结构完整代码示例如下[角色] 你是一位资深的技术文档工程师擅长从冗长的技术方案中提取核心信息。 [任务背景] 我们正在为一份内部技术方案编写摘要方案全文约1.5万字包含背景、现状、问题分析、解决方案和落地计划五个部分。 [执行步骤] 1. 通读全文识别方案的背景和目标 2. 提炼当前面临的核心问题最多列出3条 3. 概括解决方案的总体思路和关键实施步骤 4. 标注方案中涉及的风险和注意事项 [输出格式] - 摘要总字数不超过400字 - 使用一级标题“摘要”二级标题“核心问题”“解决方案”“风险提示” - 使用正式书面语不使用口语化表达 [禁忌] - 不要添加原文中不存在的信息 - 不要评价方案的好坏只做客观概括这套结构的执行效果很好模型对格式的遵从度明显高于自由提问。究其原因[角色]、[任务背景]、[执行步骤]、[输出格式]、[禁忌] 这些清晰的标记给模型提供了一个稳定的信息组织框架。如果你在调试中遇到输出偏离要求的情况优先检查 [执行步骤] 是否足够具体多数问题都出在第二步的描述模糊上。4. 深度推理与场景化落地让 DeepSeek 输出稳定可靠的结果4.1 把复杂任务拆成子任务少“一口气完成”多“分步执行”大模型处理复杂任务时最大的问题是工作记忆有限。你让它在一次回答里完成“阅读长文→提炼观点→对比分析→给出建议”四个步骤它往往会在第三步丢掉前面的一些关键信息。我在实际项目中的经验是复杂任务必须拆碎一次只让模型做一件事。以“分析一份行业报告并给出投资建议”为例我的拆法是这样第一次调用让它做全文摘要第二次调用把摘要与特定问题结合做定向分析第三次调用再输出建议。每一次调用都是独立且简单的输出质量远好于一次调用完成全部。某个跨平台系统项目中我用这种拆解策略做了定时报告生成输出内容的可用率维持在较高水平而且每次出问题时能精确定位到出错的环节。这里的关键原则是判断准确率和任务复杂度成反比。你给模型的任务越单纯模型做得越好。我建议每个任务的描述控制在三句话以内如果超过三句还没说清楚就考虑拆成两个任务。4.2 思维链提示在 DeepSeek 上的实践让模型把推理过程显性化在需要逻辑推理的任务中思维链提示是提升准确率的有效方法DeepSeek 在这类提示下表现出较强的推理能力。所谓思维链就是让模型把推理过程一步一步写出来而不是直接给出最终答案。我在模拟项目X里做过一个有趣的对比测试直接问模型“某公司上月收入120万成本85万本月收入预计增长15%成本预计增长8%估算本月利润”模型直接给出的答案偶尔会出现计算错误但要求模型“先分步计算预期收入和预期成本再计算利润”之后错误率明显下降。原因在于分步计算给了模型“中间校验点”。实现思维链有两种方式。第一种是显式思维链直接要求模型逐步推理第二种是隐式思维链通过在提示词中加入“请仔细思考后回答”这类引导词触发。实际测试中显式思维链的效果更稳定因为它给模型提供了明确的输出结构。需要警惕的是思维链的长度控制。过长的思维链会导致模型“过度思考”反而降低回答质量。我的经验是给模型设置一个推理长度上限比如“请用不超过3步推理得出结论”避免它无限展开。4.3 角色扮演与风格迁移让 DeepSeek 的人格设定稳定不漂移角色扮演是 DeepSeek 的强项之一但很多人会忽略一个关键问题角色一致性。模型在长对话中很容易遗忘最初的设定回复逐渐偏离角色。解决这个问题靠的不是在系统提示词里写一遍就完事而是在对话过程中持续注入角色信息。我的做法有两种。第一种是定期“重申角色”在用户每次提问前系统端重新发送一次完整的角色设定第二种是“角色锚定”在提示词中设置几个角色独有的说话习惯关键词让模型在回复时有针对性地模仿。第二种方式在实际使用中效果更稳定因为它把抽象的角色描述转化成了可执行的语言特征。下面是一个角色设定案例用于搭建一个技术面试官 AI 助手你是一位技术面试官面试风格有以下三个特点 1. 从不直接告诉候选人答案对错而是通过追问引导对方思考 2. 每次只问一个问题等对方回答后再决定下一个问题 3. 偏向考察候选人的思考过程而不是记忆能力这三句话定义了清晰的“边界”模型不太容易漂移。在这个基础上我再补充具体面试岗位的技术范围限定。对比测试结果显示有了行为特征锚定之后的角色对话保持一致性能力大幅增强。记住一个原则描述角色“怎么说话”比描述角色“是谁”更有效。4.4 工作流编排把多个 DeepSeek 调用组合成自动化流水线单次调用能做的事终究有限把多个调用编排成流水线才是从入门走向精通的分水岭。我在某公司做合同风险审核系统时把 DeepSeek 编排进了三个连续环节第一步抽取合同关键条款第二步对风险条款做初步标注第三步按风险等级生成审核建议。编程实现上我用 LangChain 类似的编排框架来组合调用。每个环节独立调用一次 DeepSeek API前一个环节的输出作为后一个环节的输入中间加一个格式校验步骤。这里用 Python 演示一个简易的两级处理流水线import requests import json def call_deepseek(prompt, temperature0.3): # 伪代码实际使用时替换为你自己的API接入方式 payload { prompt: prompt, temperature: temperature, max_tokens: 1024 } response requests.post(your_api_endpoint, jsonpayload) return response.json()[text] # 第一级抽取合同关键条款 extract_prompt 从以下合同文本中抽取【甲方】【乙方】【合同金额】【交付时间】【违约金比例】五项信息以JSON格式输出。 合同文本 {contract_text} # 第二级基于抽取结果做风险分析 risk_prompt 基于以下合同关键条款逐项分析潜在风险 - 甲方{party_a} - 乙方{party_b} - 合同金额{amount} - 交付时间{deadline} - 违约金比例{penalty} 输出格式每项风险用“风险描述 - 产生原因 - 应对建议”三段式呈现。 条款数据 {structured_text} # 执行流水线 contract_text open(contract.txt, encodingutf-8).read() structured call_deepseek(extract_prompt.format(contract_textcontract_text)) risk_result call_deepseek(risk_prompt.format(structured_textstructured)) print(risk_result)这个流水线结构清晰每一级任务单一且中间的 JSON 结构化输出便于程序解析和后置校验。我在实际项目中做过的方案里类似的编排经常用来处理合同预审、简历初筛、舆情摘要等重复性高、量大的文本任务人工只需要审核模型输出的终结果效率提升相当可观。5. DeepSeek 使用避坑指南从提示词翻车到接入失败的排查手记5.1 现象模型输出偏离主题答非所问原因提示词里包含了过多不相关背景信息干扰了模型对核心任务的理解。模型被大量冗长的背景描述带跑了方向忽略了真正的指令。这是提示词工程里最容易犯的错误——为了“给足上下文”而塞入无用信息。解决核心提示词控制在两百字以内背景信息只保留与任务直接相关的内容。把提示词改成“角色设定加任务指令”的最小结构去掉所有修饰性描述问题立刻得到缓解。5.2 现象模型坚持编造不存在的参考资料原因大模型的训练目标不是事实数据库而是文本生成器。当它面对不确定的问题时默认行为是生成“看起来合理”的内容而不是承认不知道。尤其是在要求引用数据来源时模型会自动补全一些看似真实实则虚构的出处。解决在提示词里显式声明“如果不确定请直接说明”或“只能使用上下文提供的信息回答问题”。对于生成内容涉及公开信息的功能我还会加一道自动校验工序用搜索引擎或内部知识库兜底双重确认之后才能对外输出。5.3 现象长对话中模型遗忘早期设定的角色原因上下文窗口有限早期信息被后续对话内容挤占模型的注意力集中在最近几轮对话上。这种情况不完全是模型能力问题也与提示词的重复强化策略有关。解决对需要保持长期角色的对话场景不再依赖单次系统提示词而是把角色设定改为每轮对话前重新注入。以系统消息的形式在每轮用户消息发送前插入一条角色提醒角色一致性会大幅提升。测试表明这种方案能有效延长角色的稳定保持轮次。5.4 现象API 接入频繁超时或返回空响应原因并发请求量超过接口限额或者请求参数里含有模型不支持的格式。比如 max_tokens 设置过小模型来不及生成完整回答就被截断或者提示词使用了模型不兼容的特殊字符。解决对 API 调用做重试和熔断处理连续失败时自动切换备用通道。参数检查以官方文档为准重点关注 max_tokens、temperature、top_p 三者的配合关系。另一个隐蔽坑是字符编码中文文本传输时如果用错编码格式模型返回的内容可能出现乱码或直接解析失败。5.5 现象模型输出的 JSON 格式不合法程序解析直接报错原因大模型生成 JSON 时偶尔会夹带注释、尾逗号或前后多余的说明文字导致 strict 模式解析失败。这不是 DeepSeek 独有现象而是所有大模型的通病。解决不直接使用模型的原始输出做解析先在提示词里要求“只输出 JSON不要包含任何其他文字”再用容错解析逻辑做二次清理。我在实际项目中写过一段清理函数去掉输出中的代码块标记、提取第一个 JSON 子串、修复尾逗号三步处理之后解析成功率基本拉到可用级别。在写提示词的时候我一句一句地告诉模型“严格输出 JSON 对象不要 Markdown 代码块包裹”翻车率能压到极低。6. 进阶垂类场景微调之外的高效提升路径和很多人想的不同把 DeepSeek 用到极致不一定非要去微调。微调成本高、周期长而且对普通业务场景往往是过度投入。我更推荐的进阶路径是先做提示词工程优化再做知识库外挂最后才考虑微调。多数场景做到前两步效果已经足够支撑业务上线了。知识库外挂的做法业界一般叫检索增强生成。核心思路是在调用 DeepSeek 之前先从自己的知识库检索出相关内容把检索结果注入提示词让模型基于这些信息作答。这样既不需要微调模型又能保证回答的时效性和权威性。我在某跨平台系统的客服模块上落地过这套方案用户问题的命中率和满意度都显著高于纯模型直接回答。最后一个值得养成的习惯是建立自己的提示词小仓库。每次调试出一版高质量的提示词就立刻记录下来标注好适用场景和踩过的坑。久而久之你会发现大部分业务场景都能从旧提示词里快速组合出新的可用版本。这个习惯帮我避免了大量重复调参希望帮到你。本文还有配套的精品资源点击获取
