简介这份《DeepSeek从入门到精通》PDF文档面向希望系统掌握DeepSeek的初学者、内容创作者、开发者与职场用户围绕“是什么、能做什么、怎么用、如何从入门到精通”展开帮助读者建立从功能认知到模型选择、提示语设计的完整学习路径。压缩包内仅含1个PDF文件大小约4.83MB便于在电脑或移动端直接阅读与检索。内容覆盖智能对话、文本生成、语义理解、计算推理、代码生成与调试、长文摘要、多语言翻译等场景并重点比较推理模型与通用模型在数学推导、逻辑分析、创意写作、多轮对话中的优势与局限同时讨论CoT链式思维下“快速反应”与“慢速思考”的差异给出任务类型与提示语策略的匹配原则、常见误区及示例。已有730人学习适合按章节查阅也可作为选择模型和优化提示语的实践参考。1. DeepSeek 从入门到精通一份把提示语当工程拆的实操讲义DeepSeek 这个名字现在几乎不用解释但决定输出质量的往往不是模型而是你递给它的那段话。这份《DeepSeek 从入门到精通》的讲义把“提示语”当成一门有结构、有类型、有公式的手艺来拆先分清推理模型和通用模型再按需求类型套表达公式最后落到文本生成、代码调试、文件解析这些具体场景。它适合三类人天天写提示语但输出全靠玄学的内容岗、想把模型接进业务流程的开发、以及带团队做 AI 落地需要一套统一话术规范的人。下面按我自己拆这份文档的顺序讲重点放在能直接抄走的部分和容易翻车的地方。2. 推理模型与通用模型怎么选一张四维选型表加一组对照实验拿到任何一份讲大模型使用的材料最容易跳过、也最容易吃亏的一节就是模型分类。很多人默认“新的、热的、参数大的就是好的”结果拿推理模型去写营销文案嫌它慢、嫌它端着拿通用模型去推数学证明嫌它算错。讲义里把这条讲得很直白强弱判断不是全面更强而是仅在其训练目标领域显著优于对方。2.1 快思慢想背后的两套算力账讲义用“快思慢想”来区分两类模型这个类比挺准确。概率预测型模型快速反应靠海量数据训练本质是预测下一个最可能的词响应快、算力成本低决策依赖预设算法和规则创造力限于模式识别与优化人机互动按预设脚本走擅长解决结构化和定义明确的问题。链式推理型模型慢速思考走的是 Chain-of-Thought 路线把问题拆成一步步推算力成本高、响应慢但能自主分析情况、实时调整决策路径也能处理多维度和非结构化问题。这个差异落到实操上最直接的影响是“你能省多少提示语”。推理模型把推理逻辑内化了你只需要说清目标和约束通用模型没有这层内化你得替它把推理脚手架搭出来否则它就会顺着语言的惯性往下滑看着通顺中间步骤却跳了。下面这张表是我按讲义内容整理的对照日常选型基本够用维度推理模型通用模型优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作、自由联想需要严格逻辑链的任务如数学证明、多步核算性能本质专精于逻辑密度高的任务擅长多样性高的任务提示语成本低一句话说清目标即可高需要分步引导与示例补偿典型误用强行拆步骤、加角色扮演直接抛复杂推理题、不做结果验证注意表里最后一行。绝大多数“模型不好用”的抱怨源头都在这一行——不是模型不行是把提示语策略用反了。2.2 一张选型表把任务投到对的模型上讲义给的关键原则是优先根据任务类型而非模型热度选择。这句话听着像废话实际执行时非常难因为热度是会传染的。我见过团队把所有任务都切到推理模型上结果写商品文案的环节慢了三倍产出还更“正经”少了那点松弛感。把任务类型和模型对上我一般按下面这张表走任务类型推荐模型提示语侧重点需要避免的做法数学证明、公式推导推理模型直接提问给出已知条件与求证目标冗余拆解如“先画图再列公式”代码生成与重构推理模型说清输入输出、边界条件、语言版本分步指导如“先写递归函数再写主函数”逻辑分析与方案对比推理模型直接抛出复杂问题要求给出判断依据加主观引导如“你觉得哪个对”创意写作、故事、文案通用模型明确风格、篇幅、受众鼓励发散过度约束逻辑如“按时间顺序逐条列出”多轮对话、客服问答通用模型自然交互给足背景强制输出逻辑链条结构化整理、格式转换通用模型给模板、给字段名、给示例开放式指令这张表有个隐含前提任务是可以拆的。一份真实的工作流往往是“先分析再创意再执行”那就分段换模型不要指望一个模型从头扛到尾。讲义里“任务需求与提示语策略”那部分其实就是在讲这件事——同一个需求投喂顺序不同结果差很远。2.3 一组对照实验同一道题两种问法光看表没感觉我建议花十分钟做一次对照。挑一道你自己业务里的题用两种写法各跑一遍把结果并排放。讲义里给的示例思路可以直接借一道需要多步推导的题分别用“简洁需求”和“分步指导”去问推理模型再用同样两种写法去问通用模型。第一组对推理模型的两种写法!-- 写法 A简洁需求只给目标与约束 -- 用 Python 实现快速排序输出需包含注释并说明时间复杂度。 !-- 写法 B分步指导强行拆解 -- 第一步先写一个递归函数 第二步在函数里选择基准元素 第三步写分区逻辑把小于基准的放左边 第四步递归调用左右两部分最后用注释说明每一行。第二组对通用模型的两种写法!-- 写法 C直接提问不做引导 -- 用 Python 实现快速排序。 !-- 写法 D显式要求分步并给示例结构 -- 请分四步完成 1. 解释快速排序的分区思路 2. 写出带注释的实现 3. 给出三组测试用例包含空列表和重复元素 4. 用一段话说明最坏时间复杂度出现在什么情况下。跑完你会看到两种典型现象写法 A 通常比写法 B 更干净注释位置合理甚至主动补了边界说明写法 B 反而因为被强行规定了顺序出现“先递归后定义基准”这类逻辑错位。写法 C 对通用模型经常给出能跑但有隐患的代码比如没处理重复元素导致递归深度异常写法 D 则明显更稳。逻辑说明这四段提示语不是让你背下来而是让你建立一个判断——推理模型的提示语要“减”通用模型的提示语要“补”。参数层面减的是步骤数、角色设定、格式细则补的是分步要求、输入输出示例、失败情况的处理约定。判断标准也很简单如果输出里出现了你没要求过的中间推理段落说明模型在自行补链这时候再叠加拆解指令就是负收益如果输出直接跳到结论、中间缺失说明需要补脚手架或换模型。实验记录建议做成两列对照表左边记“提示语写法”右边记“输出是否符合预期、错在哪一步”。三五次之后你对自家业务该用哪个模型、该怎么写会比看任何教程都清楚。3. 提示语的三段结构与六种类型把“下达指令”改成“表达需求”讲义里有一节叫“还要不要学提示语”这个问法很实在。既然模型越来越聪明写提示语是不是多余了结论是需要学但学的东西变了。从背模板变成理解结构。3.1 指令、上下文、期望三段结构怎么落到模板里提示语的基本结构是三段指令是核心明确告诉模型要执行什么任务上下文提供背景信息帮它更准确地理解和执行期望则明确或隐含地表达你对输出的要求。这三段听着抽象落到具体写法就是三句话的功夫指令动词开头一句话说清产出物是什么一份摘要、一段代码、一张对比表。上下文给足材料与边界数据从哪来、面向谁、有什么限制、哪些信息不能改。期望格式、长度、颗粒度、是否需要给出判断依据。讲义把策略分成四类我按自己的使用频率排了个序策略类型定义与目标适用场景风险需求导向描述问题背景与目标由模型规划路径复杂问题、需要模型自主推理需求边界不清时容易跑偏混合模式需求描述加关键约束条件大多数日常任务约束过多会压制模型发挥指令驱动直接给出明确步骤或格式要求简单任务、需要快速执行限制模型的自主优化空间启发式提问通过“为什么”“如何”引导模型自解释探索性问题、需要解释逻辑可能偏离核心目标这四类没有优劣只有匹配。写周报、做字段抽取这类结构化活儿指令驱动最省事做方案对比、找业务瓶颈需求导向更合适混合模式是默认档八成场景能用。启发式提问容易被低估实际上它在做复盘时特别好用——让模型解释“为什么选这个方案而不是另一个”往往能把你没想到的假设暴露出来。3.2 六种提示语类型与它们的失效边界讲义列了六种类型指令型、问答型、角色扮演型、创意型、分析型、多模态。前四种大家天天在用后两种最容易被误用。类型写法特征适用失效边界指令型直接告诉模型要执行什么任务翻译、格式转换、批量整理任务本身需要判断时会硬做问答型提问期望得到答案知识查询、概念解释问题含糊时会给出含糊答案角色扮演型设定身份与场景模拟对话、风格化写作用在推理模型上会干扰逻辑主线创意型引导创意写作与内容生成故事、文案、命名约束缺失时产出空泛分析型要求对给定信息分析推理评论归类、意图识别、因果分析材料不足时会补编细节多模态文本加图像、文件等混合输入图表解读、扫描件取数表格结构复杂时容易串行角色扮演型这条要单独说。它在通用模型上效果明显给个身份、给个语气输出立刻不一样但搬到推理模型上很多人的血泪经验是“越演越差”。原因不复杂推理模型的内化推理链是它最大的资产角色设定相当于往这条链上叠了一层无关的语义噪声模型得同时兼顾“我是谁”和“这题怎么推”逻辑主线就被拉散了。真要风格化正确顺序是先用推理模型拿结论再让通用模型做改写。多模态那条也值得警惕。讲义提到文件上传能扫描读取各类文件及图片中的文字内容这在处理扫描版合同时很省事但表格类文件是重灾区——二维结构被拉平成文本流之后行和列容易错位模型还会用语言先验把缺失的数字“补”得像模像样。后面第 5 章会专门讲这个坑怎么排查。3.3 五类需求的需求表达公式讲义最实用的部分是把需求分成五类每类给了一个表达公式。决策需求是“目标加选项加评估标准”分析需求是“问题加数据加分析方法”创造性需求是“主题加风格约束加创新方向”验证需求是“结论加验证方法加风险点”执行需求是“任务加步骤约束加输出格式”。公式本身好记难的是每次写提示语时真的填满。我一般用一个拼装函数把这件事固定下来缺项直接报错逼自己把话说全# 五类需求的最小模板缺关键字段直接抛错避免半成品提示语被丢给模型 TEMPLATES { 决策: 目标{goal}\n候选方案{options}\n评估标准{criteria}\n请量化对比后给出推荐并说明放弃另一方案的理由。, 分析: 问题{goal}\n数据{data}\n分析方法{method}\n请给出因果链推导并标注每一步依赖哪些字段。, 创造性: 主题{goal}\n风格与约束{constraints}\n创新方向{direction}\n先给三个方向的一句话概述再展开其中一个。, 验证: 结论{goal}\n验证方法{method}\n已知风险点{risks}\n请逐条判断结论是否成立并指出证据不足之处。, 执行: 任务{goal}\n步骤约束{constraints}\n输出格式{fmt}\n严格按格式输出不要额外解释过程。, } # 每类需求的必填字段options/data/constraints 等可按任务裁剪 REQUIRED { 决策: (goal, options, criteria), 分析: (goal, data, method), 创造性: (goal, constraints, direction), 验证: (goal, method, risks), 执行: (goal, constraints, fmt), } def build(kind, **kw): if kind not in TEMPLATES: raise ValueError(f未知需求类型{kind}) missing [k for k in REQUIRED[kind] if not str(kw.get(k, )).strip()] if missing: raise ValueError(f{kind} 需求缺少字段{missing}) return TEMPLATES[kind].format(**kw) # 用法物流成本方案对比 print(build( 决策, goal降低区域仓配成本, options自建区域仓第三方按需付费, criteria五年总成本、履约时效、旺季弹性, ))逻辑说明TEMPLATES 里每一条都是“角色不写、步骤不写、只写目标与约束”的骨架刻意留白让模型自己补推理路径。REQUIRED 的作用是防呆——最常见的低质量提示语不是写得差而是缺字段比如只说要“对比方案”却不给评估标准模型只能按自己的偏好排序。build 函数把校验前置报错信息直接告诉你缺哪个字段。参数说明kind 是需求类型只能取五个键之一取错直接抛异常goal 是目标必填options、data、constraints、criteria、method、risks、direction、fmt 按类型取用任何一个空白字符串都会被认为缺失。实际接入时我会把这个函数包一层让它输出成 markdown 段落再复制到对话框省掉手工排版。一个提醒公式是底线不是上限。填满公式能得到及格线以上的输出想拿到更好的结果还得在“评估标准”和“风险点”这两栏上做功课——这两栏写得多具体输出就有多具体。4. 三个高频场景的落地打法长文摘要、代码调试、文件与联网讲义按能力把 DeepSeek 的用途铺得很开文本创作、营销文案、社交媒体内容、剧本对话、长文本摘要、文本简化、多语言翻译、结构化生成、代码生成与调试、API 文档生成、语义分析与情感分析、知识推理与逻辑问题解答。铺得开是好事但落地时真正高频的就三类。这一章按我自己的使用频率拆。4.1 长文本摘要与结构化输出先约束格式再喂料长文本摘要最常见的失败不是摘要不准而是“只摘了前半篇”。二十页的报告贴进去输出覆盖了前三页后面全是泛泛而谈的套话。原因有两层一是长上下文里注意力会衰减越靠后的内容权重越低二是没有结构锚点模型不知道哪些段落是重点。我一般用两步走。第一步先让它建锚点不要材料只要结构下面是一份报告我先不给正文。请根据我提供的章节标题判断哪些章节最可能包含关键结论并说明判断依据。 章节标题一、背景二、现状三、问题四、方案对比五、实施路径六、风险。第二步再分段喂料每段要求带出处请对第三章节做摘要要求 1. 输出三到五条要点每条不超过 40 字 2. 每条要点后用括号标注来源段落序号例如三-2 3. 如果某条要点在原文中找不到明确依据直接写“无依据”不要推测 4. 最后单列一行“本章结论”一句话概括。逻辑说明第一段的作用是让模型先建立“这份文档长什么样”的认知相当于给它一张地图后续喂料时它知道每块内容在全局中的位置。第二段的三条约束分别解决三个问题字数限制压制套话来源标注强制回溯原文“无依据”这一条是防幻觉的后悔药——允许模型说不知道比逼它编一个更像真的。参数说明要点条数建议三到五条超过七条人会疲劳也容易稀释重点单条字数 40 字是经验值能装下一个完整判断又不至于展开来源标注的格式要固定比如“章节号-段落号”后续合并时才好去重。如果文档超过三十页直接走分段摘要再合并别指望一次到位先按章节各出一份要点再把要点列表当输入让它合并成一份总摘要并标注冲突项。结构化输出这块讲义提到表格、列表生成我补一条实操建议把字段名写进提示语别让它自由发挥。要日程表就给“时间、事项、负责人、备注”四个字段要菜谱就给“食材、用量、步骤、耗时”。字段名一旦固定后续做二次加工比如导成 CSV就不用再清洗一遍。4.2 代码生成与调试把错误信息和最小复现一起给代码类任务里问法决定成败。只说“这段代码报错了帮我看下”模型只能猜把报错栈、运行环境、输入样例一起给命中率立刻不一样。讲义里提到代码生成、错误分析与修复建议、代码性能优化提示、API 文档生成、代码库解释与示例生成这些能力的前提都是上下文完整。我常用的调试模板是这样请帮我定位下面这段代码的问题。 运行环境Python 3.11无第三方依赖 预期行为读入列表后返回去重且保持原顺序的结果 实际行为返回结果顺序被打乱 报错信息无报错逻辑错误 最小复现代码 def dedup(items): return list(set(items)) 输入样例[3, 1, 3, 2] 实际输出[1, 2, 3] 期望输出[3, 1, 2] 要求先说明根因再给修改后的完整函数最后补两组边界用例空列表、全重复。逻辑说明这段模板把五件事一次说清——环境排除了版本干扰预期与实际定义了“错在哪”最小复现代码把问题范围压到十行以内输入输出样例给了可验证的判据最后的要求规定了输出结构。少任何一项模型都会开始猜猜出来的修复方案经常是“看起来对但改错了地方”。参数说明环境信息里语言版本必写第三方库版本按需最小复现代码控制在二十行以内超过就说明你还没定位到问题输入样例至少给两组一组正常一组边界最后的“要求”部分建议固定成三段式根因、修复代码、边界用例方便你批量比对。生成类任务反过来重点在约束。要它写解析函数就把输入格式、异常情况、返回结构写全要它写 API 文档就给函数签名和一两个调用示例。讲义提到代码注释与文档撰写这类任务最怕“自由发挥”参数类型、异常抛出条件、返回值边界这三样必须写进提示语否则生成的文档看着完整实际漏掉最关键的错误分支。4.3 文件上传、联网搜索、深度思考三个开关什么时候开这三个功能是使用体验差异最大的地方也是最容易开错的。文件上传适合两类材料非结构化的长文档PDF、Word和含图的扫描件。它的价值在于省掉复制粘贴并且能读到图片里的文字。但它不适合做精确的表格计算——二维表格被拉平成文本后行列对应关系会丢。要处理表格我一般先转成 CSV 再贴或者明确要求“逐行引用原文并标注行号”把核对成本压到最低。联网搜索的价值在时效性。需要最新数据、需要核对某个说法、需要看近期动态时才开纯逻辑题、写作题开了反而引入噪声因为检索回来的片段会挤占上下文还可能带进不相关的表述。判断标准很朴素这个问题如果三个月后再问答案会不会变会变就开。深度思考模式对应的是推理模型那条路径。它适合逻辑密度高的任务比如多步核算、方案权衡、复杂条件判断。不适合发散性创作也不适合简单的格式转换——开了只是多等一会儿。一个组合建议需要核实事实的分析任务开联网加深度思考但要在提示语里限定来源范围和时间窗口纯创作任务两个都关直接走通用模型长文档处理上传文件但不开联网避免检索内容干扰对原文的理解。5. 常见问题与排查五个翻车现场的现象、成因与补救这一章按“现象、原因、解决”三段的格式写都是我实际遇到过的。看完至少能少走半年弯路。5.1 选型与提示语层面的两个坑现象一给推理模型加了角色扮演和分步拆解输出反而更啰嗦、甚至算错。原因推理模型的推理链是内化的外部强加的步骤顺序会跟它自己的规划冲突角色设定引入的人设语义会干扰逻辑主线模型要花算力去维持“我是谁”留给推理的就少了。解决把提示语砍到只剩目标与约束允许它自己规划路径。需要风格化输出的分两步走先用推理模型拿结论再把结论丢给通用模型做语气改写。判断是否踩了这个坑有个简单信号——输出里出现大段“作为一个……我认为……”的开场白基本就是角色设定在抢戏。现象二对通用模型直接抛复杂推理题结论看着合理中间数字对不上。原因通用模型走的是概率预测本质是预测下一个最可能的词。多步推导时它会顺着语言的惯性往下滑每一句都通顺但整条链断在中间某一环。这类错误特别隐蔽因为文风自信。解决三个动作任选。一是显式要求分步并给示例结构二是在提示语里加验证环节比如“给出结论后用不同方法再算一遍若两次结果不一致请指出”三是直接换推理模型。日常做财务测算、参数推算这类活儿我直接上推理模型省下来的核对时间远超等待成本。5.2 输入与工具开关层面的三个坑现象三长文档整篇粘贴摘要只覆盖前面一小部分。原因上下文变长后注意力分布不均靠后的内容权重下降加上材料本身没有结构锚点模型不知道哪些段落该重点看。解决先给章节标题让它判断重点再分段摘要后合并。合并环节要加一条约束“若各段要点存在冲突单列一节标注冲突项及各自出处”否则合并时容易被悄悄抹平。文档超过三十页别犹豫直接走分段路线。现象四开了联网搜索答案里的数据仍然是旧的。原因检索词是模型自己生成的问题描述太笼统时检索命中的是泛泛的旧文章另一种情况是问题本身不需要时效信息开了联网只是引入了不相关的片段。解决把时间范围、来源类型、需要核对的字段写进问题里比如“请核对 2024 年之后的公开数据只采用带统计口径的表述并注明数据截止时间”。同时养成习惯开联网前先问自己这个问题是否随时间变化不变就关掉。现象五上传文件后模型“读”出了原文里没有的内容。原因扫描件和复杂表格在识别与结构还原环节存在误差模型遇到缺失值时会用语言先验去补补出来的内容读起来毫无破绽。解决关键数字一律要求“逐行引用原文并标注页码或行号”抽样人工核对两到三处表格类材料先转 CSV 再喂涉及金额、日期、编号的字段追加一句“若原文未明确给出写‘未找到’不要推算”。这条约束看着笨实际能挡掉大部分幻觉。6. 进阶把提示语当代码管起来版本表加回归集写到这儿剩下的都是习惯问题。提示语用久了会自然分化同一个摘要任务你会攒出五六个版本改到后来自己都忘了哪版好用。我后来的做法是把提示语当代码管——建目录、打版本、留回归集。目录结构很土但够用按任务建文件夹每次大改复制一份加日期后缀改动原因写在文件头部的注释里。这样两周后回头找“那版要求标注出处的摘要模板”三秒能翻出来。更关键的是回归集。挑十到十五条覆盖典型场景的输入固定下来每次改完提示语就跑一遍比对输出结构有没有塌。不需要接 API把输出粘回本地做结构校验就行# 对粘贴回来的模型输出做结构校验防止改提示语时把格式改崩 import re CHECKS { 要点条数: lambda t: 3 len(re.findall(r^\d\.\s, t, re.M)) 5, 来源标注: lambda t: len(re.findall(r[一二三四五六]-[0-9], t)) 3, 结论单列: lambda t: 本章结论 in t, 字数上限: lambda t: all(len(x) 60 for x in re.findall(r^\d\.\s(.)$, t, re.M)), } def check(text): bad [name for name, fn in CHECKS.items() if not fn(text)] return 通过 if not bad else f未通过{bad} # 把模型输出整段贴进三引号里跑一次 print(check(open(output.md, encodingutf-8).read()))逻辑说明CHECKS 里每一项都是一个可自动判定的格式约束对应提示语里写死的要求。改完提示语跑一遍哪条亮红就说明这次改动破坏了哪个约束比人眼扫一遍靠谱得多。要点条数用行首编号匹配来源标注按固定格式匹配字数上限按每条要点的正文字符数判断。参数说明条数区间按你的模板设定改三到五条是摘要场景的常用值来源标注的正则要跟你提示语里的格式完全一致格式一改这条就得同步改字数上限 60 是包含序号和标点的宽松值要严格控字数就把正则收窄到正文部分。这套校验只验格式不验内容内容质量还得靠人工抽样。还有一件事我后来才想明白提示语的价值不在于写得多漂亮而在于可复用、可对比、可回滚。上次为了赶一个紧急需求临时把摘要模板里的“来源标注”删了输出确实快了一倍看着也顺眼交上去被打回来——三条要点里两条在原文找不到出处。从那以后我每次改提示语都强制走一遍回归集再上生产哪怕只是删一句话。希望帮到你。本文还有配套的精品资源点击获取