DeepSeek提示语实战:模型分流、三段结构与需求表达
简介这份《DeepSeek从入门到精通》PDF由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室编写面向希望系统掌握DeepSeek的开发者、内容创作者与AI应用学习者帮助读者厘清模型能力边界并建立从入门到实践的学习路径。内容围绕DeepSeek-R1开源推理模型与免费商用特性讲解智能对话、文本生成、语义理解、计算推理、代码生成补全、联网搜索、深度思考、文件上传读文等能力并展开文章与故事创作、营销文案、长文本摘要、多语言翻译、结构化表格生成、情感分析、意图识别、代码调试及文档撰写等场景。文中重点比较推理模型与非推理模型的优势领域、快思慢想机制和提示语策略差异给出按任务类型选择模型、按模型特性设计提示语的原则。压缩包内为1个PDF文件大小约4.14MB结构紧凑便于通读与检索已有335人学习下载适合作为快速搭建DeepSeek知识框架、对照实际任务查阅方法的手册。1. 手册拆开看一份讲义真正值钱的地方在哪不少人下载《DeepSeek 从入门到精通》之后翻两页就扔进收藏夹觉得“不就是个产品说明书”。这大概是最浪费的一种用法。它实际是一份由某高校新闻与传播学院新媒体研究团队整理的实操讲义主线不在于罗列功能而在于把“怎么把任务说清楚”拆成了一张张可以对照的表格什么任务该换模型、提示语该写几段、需求该怎么表达、哪类写法会互相打架。适合三类人天天用对话工具写材料但输出总差一口气的内容岗想把模型接进开发流程、又不想靠反复试错碰运气的工程师以及需要给团队定一套统一用法的人。下面按我拆读的顺序讲结构长什么样、哪几页能直接抄、哪些地方照做会翻车。2. 推理模型与通用模型的分流同一条提示语换个模型为什么就崩最常听到的抱怨是“昨天还好用今天同样的问法就拉胯”。多数时候不是模型抽风而是任务被换到了另一类模型上。这份讲义花了相当篇幅讲模型分流因为它把“提示语怎么写”这个玄学问题拆成了“先用对模型再谈写法”的两步。顺序反了后面所有技巧都是白费力气。2.1 快思慢想不是修辞两类模型的训练目标差在哪推理模型是在传统大语言模型基础上额外用强化学习、神经符号推理、元学习一类技术去强化推理、逻辑分析和决策能力的模型。它的训练目标不是“下一个词更顺”而是“多步推导别断链”所以在数学推导、逻辑分析、代码生成、复杂问题拆解上明显更强。DeepSeek-R1 属于这一类开源且允许免费商用这也是它被大量项目选作推理侧底座的原因之一。通用模型走的是另一条路靠大规模文本训练掌握语言规律侧重语言生成、上下文理解和自然语言处理输出流畅、覆盖面广但不强调深度推理。它在创意写作、多轮对话、开放性问答上更灵活遇到需要严格逻辑链的任务就容易“看起来很有道理实际上中间步骤是编的”。讲义里有一句话很关键推理模型并非全面更强只是在其训练目标领域显著优于通用模型。维度推理模型通用模型优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作需要严格逻辑链的任务如数学证明性能本质专精于逻辑密度高的任务擅长多样性高的任务强弱判断仅在其训练目标领域显著更优通用场景更灵活专项任务依赖提示语补偿讲义还借用“快思慢想”这个说法做了第二层区分一类是概率预测式的快速反应模型靠海量数据快速预测可能答案响应快、算力成本低但决策依赖预设算法和规则创造力限于模式识别与优化另一类是链式推理式的慢速思考模型逐步推演每个步骤算力成本高但能自主分析情况、处理多维度非结构化问题。两类模型没有优劣只有任务匹配度。真正需要记住的是它们的短板位置快的那类在结构化、定义明确的问题上很稳慢的那类在需要发散时反而拘束。落到实操上这个区分直接决定提示语的长度。推理模型已经把推理逻辑内化了提示语越简洁越好只需明确任务目标和需求通用模型缺的正是推理步骤得靠提示语把步骤补上比如显式要求分步思考、给一个示例。同一个提示语在两类模型之间来回搬结果必然飘。2.2 分流判断的三个问题与一张对照表我一般用三个问题快速分流不用记模型名只判断任务形状。第一答案有没有相对唯一解有唯一解的证明、换算、定位 bug走推理侧。第二中间步骤要不要被人检查要检查的推导、核算、方案权衡走推理侧因为它会把步骤摊开。第三任务是不是靠发散取胜靠发散取胜的起标题、写故事、想 slogan走通用侧。三个问题里只要有一个答案落在“发散”就别硬上推理模型。讲义里给的任务—模型—提示语对照我整理成了下面这张表实际用的时候照着“要避免的写法”那一列自查比记正面写法更有效。任务类型适用模型提示语侧重点要避免的写法数学证明与多步推导推理模型直接提问不必分步引导冗余拆解如“先画图再列公式”创意写作故事、文案通用模型明确风格、字数、约束目标开放式指令如“自由创作”代码生成与调试推理模型给需求、输入输出格式、边界条件分步指导如“先写递归函数”多轮对话与开放问答通用模型自然交互补足背景信息强制逻辑链条如“必须分三点回答”逻辑分析与方案权衡推理模型直接抛出复杂问题加主观引导如“你认为哪种对”长文摘要与改写通用模型给长度、读者、必须保留的项只丢一句“帮我简化一下”这张表有个隐含前提任务是可以拆的。真实工作里经常是混合任务比如“分析这份销售数据并写一段对外文案”前半段要推理后半段要文采。常见做法是拆成两轮先让推理模型把数据和结论跑清楚再把结论喂给通用模型做表达不要指望一个模型一次做完两件事。2.3 换模型的实操顺序先控变量再看三个观察点很多人调提示语的习惯是“改一句、跑一次、再改一句”改到第五版已经不知道哪句起了作用。我自己的顺序是反过来的先固定提示语不动只换模型跑一遍看清楚差异到底来自模型还是来自提示语。第一步把当前提示语原样复制到另一类模型一字不改。第二步看它有没有主动给出中间步骤——推理模型通常会通用模型经常跳过这是最直观的分流信号。第三步数一数你在提示语里写了几条约束看输出漏了几条漏得多的那类模型就是提示语补偿不足。第四步看输出有没有过度展开简单任务被写成八百字小论文多半是把慢速思考模型用在了快速反应场景。第五步才决定动作是改提示语还是换模型。提示常见采样参数比如控制随机性的强度先别动。提示语结构没理顺之前调参数等于在黑匣子外面猜改完也不知道是哪一项起的作用。这五步里最容易跳过的是第一步。血泪经验是模型切换带来的差异往往比你在提示语里加三行修饰词更大不先控住这个变量后面所有对比都是无效对比。3. 提示语的三段结构指令、上下文、期望各自填什么模型分流解决“用谁”接下来才是“怎么说”。讲义把提示语定义成用户输入给 AI 的指令或信息用于引导生成特定输出并且明确拆成三段指令、上下文、期望。这个拆法看起来朴素但它把“我表达不清”这种模糊自责变成了三个可以逐项检查的填空位。3.1 三段各自解决什么问题指令是核心明确告诉模型要执行什么任务上下文提供背景信息帮它更准确地理解和执行期望则明确或隐含地表达你对输出形式和内容的预期。三段里最容易被省略的是上下文和期望而这两段恰恰是输出“泛”和“空”的主要来源。讲义还给了提示语的本质特征我按自己的理解重排了一下它解释了三段结构为什么有效特征作用缺失时的表现沟通桥梁连接人的意图和模型的理解输出“对但没用”答的不是你问的上下文提供者为模型提供必要背景输出泛化、套话多缺少具体信息任务定义器明确指定要完成的任务模型自由发挥做了你没要求的事输出塑造器影响输出的形式和内容长度、格式、详略全凭模型心情能力引导器引导模型调用特定能力该推理的地方在抒情该创作的地方在列条目我见过最多的情况是只写指令“帮我优化这段登录流程。”模型只能给一堆通用建议。补上上下文当前流程几步、卡在哪一步、日活量级、不能改动的约束和期望要三种方案、每种写清改动点和风险输出立刻从鸡汤变成可评审的材料。3.2 从下达指令到表达需求四种策略怎么选讲义把提示策略分成几类核心差别在于“你把路径也规定了还是只给目标”。指令驱动是直接给出明确步骤或格式要求适合简单任务和需要快速执行的场景胜在结果精准高效代价是限制了模型自主优化空间。需求导向是描述问题背景与目标由模型自己规划路径适合复杂问题能激发深层推理但要求你把需求边界写清楚否则容易跑偏。混合模式是两者折中给需求描述同时给关键约束兼顾目标与细节既不失控也不太死。第四种是启发式提问用“为什么”“如何”引导模型自解释适合探索性问题能触发它把推理逻辑讲出来风险是可能偏离核心目标。策略定义与目标适用场景典型写法优势与风险指令驱动直接给出步骤或格式要求简单任务、需快速执行“用 Python 写快速排序输出需含注释”精准高效但限制自主优化需求导向描述背景与目标由模型规划路径复杂问题、需模型自主推理“我要优化登录流程请分析瓶颈并给三种方案”激发深层推理但需清晰边界混合模式需求描述加关键约束兼顾目标与细节“设计某城市三日行程包含两个指定景点预算 2000 元内”平衡灵活与可控忌过度约束启发式提问用提问引导模型自解释探索性问题、需解释逻辑“为什么这个优化问题选梯度下降请与其他算法对比”触发自解释可能偏离核心目标选哪种看你对路径有没有把握。路径清楚、只要结果用指令驱动路径不清楚、需要模型帮你找用需求导向怕它跑偏又不想写死用混合模式。3.3 六种提示语类型与一个高危类型讲义列了六类提示语指令型直接告诉任务问答型提出问题等答案角色扮演型要求模型模拟特定角色和场景创意型引导创意写作分析型要求对给定信息分析推理多模态型结合文本、图像等多种输入。前五类日常都在用第六类取决于所用产品是否支持文件与图片输入。真正需要标红的是角色扮演型。它在通用模型上很好用能让文案有腔调但用在推理模型上容易干扰它的逻辑主线——你让它“扮演一位十九世纪的历史学家评论某段历史”它会把算力花在维持人设上推理链反而松了。这不是绝对不能用而是要有意识要人设就别指望它同时把多步推导做到最紧。类型典型写法适用慎用场景指令型“把以下内容翻译为法语”格式转换、明确任务需求本身模糊时问答型直接提问等答案知识查询、快速确认需要多步推导的复杂问题角色扮演型“假设你是一位……评论……”文案、风格化表达推理模型上的逻辑任务创意型给主题、风格、字数故事、标题、脚本需要严格事实约束时分析型给材料要求分析推理数据解读、方案评估材料本身不完整时多模态型文本加图片、文件输入扫描件、图表读取排版复杂、公式密集的文档3.4 一套三段式模板和六条自检把上面的东西压成一个可复用的填空模板我用的是下面四行每次写提示语先填满再发出去字段填写要求反例正例任务一个动词开头只写一个主任务“优化并推广并评估一下”“评估这套登录流程的瓶颈”上下文现状、约束、读者、已有材料“我们流程不太好”“当前五步第二步流失最高后端接口不可改”期望输出形式、长度、必须包含的项“给点建议”“三种方案每种写改动点、风险、预估工时”边界明确不要做什么不写“不要改数据库结构不要引入新依赖”发出去之前过六条自检这六条基本覆盖了大部分翻车主任务是不是只有一个上下文里有没有具体数字或原文期望里有没有写清输出格式有没有互相冲突的约束这任务该用推理模型还是通用模型提示语里有没有多余的角色设定在干扰推理。注意约束不是越多越好。三条硬约束比十条并列要求更容易被完整执行超出的部分模型会自行取舍而它取舍的顺序你控制不了。4. 五类需求的需求表达公式决策、分析、创造性、验证、执行到这一步模型选对了、结构填满了剩下的问题是“我到底在要什么”。讲义把日常需求归成五类每类给了一个表达公式。这套分类的价值在于它让你在写提示语之前先想清楚这是决策题还是执行题因为这两类要的输出根本不是一个东西。4.1 五条公式和它们各自防的失败模式需求类型特点表达公式推理模型适配通用模型适配决策需求需权衡选项、评估风险、选最优解目标 选项 评估标准要求逻辑推演和量化分析直接建议依赖经验归纳分析需求需深度理解数据、发现模式或因果问题 数据/信息 分析方法触发因果链推导与假设验证表层总结或分类创造性需求需生成新颖内容主题 风格/约束 创新方向结合逻辑框架生成结构化创意自由发散依赖示例引导验证需求需检查逻辑自洽、数据可靠、方案可行结论/方案 验证方法 风险点自主设计验证路径并排查矛盾简单确认缺乏深度推演执行需求需完成具体操作任务 步骤约束 输出格式自主优化步骤兼顾效率与正确性严格按指令执行无自主优化这张表的用法是反向的先看你的需求像哪一行再决定模型和提示语写法。决策需求丢给通用模型得到的往往是一段“各有优劣建议结合实际情况”的废话执行需求丢给推理模型并要求它自主优化它可能真的给你改了实现思路而你要的只是照做。4.2 逐类拆开从需求到提示语骨架决策需求的关键是评估标准必须量化。比如要比较自建区域仓库和第三方合作两种方案提示语里要写明用 ROI 模型、对比五年总成本、给出推荐结论。标准不写模型只能按“成本、效率、风险”泛泛排一遍。这类任务交给推理模型让它把计算过程摊开你能逐项核对交给通用模型它更可能给你一个听起来合理的结论。分析需求的关键是把数据真的放进去。只写“分析一下销量趋势”模型只能复述常识。写成“分析近三年销量数据附 CSV说明增长趋势与政策关联性预测下一年市占率使用 ARIMA 并解释参数选择依据”输出才有可核对的对象。这里有个细节要求解释参数依据比要求给出预测值更有价值因为预测值你无法当场验证参数解释可以。创造性需求的关键是约束方向而不是约束细节。做一款面向独居老人的智能家居产品要求解决安全问题、结合传感器网络与预警机制、给三种不同技术路线的原型草图说明——主题、方向、产出形式都给了但没规定它必须用哪种传感器。反过来如果你把技术选型也写死输出的“创意”就只剩排版了。这类任务用通用模型更顺硬上推理模型容易得到一份结构严谨但毫无惊喜的方案。验证需求的关键是把验证方法和风险点一起要。比如拿到一个“某模型优于传统方法”的结论提示语要写明检查实验数据是否支持该结论、检查对照组设置是否存在偏差、重新计算显著性并判断。只问“这个结论对不对”模型大概率顺着你的话说对。这类任务适合推理模型因为它会把每一步检查单独列出来你能看到它在哪里卡住。执行需求的关键是输出格式和步骤约束。把一段 C 代码转成 Python要求保持时间复杂度不变、用向量化库优化数组操作、附上带时间测试的完整代码——三句话把边界、手段、交付物都定死了。这类任务反而不需要模型“聪明”要的是它别自作主张。4.3 输出验收三个可量化的检查点拿到输出先别急着用过三个检查点。结构检查约定的三项是不是三项格式对不对长度在不在范围内这一条最容易自动化也最容易被跳过。事实抽查从输出里挑两三个具体数字或结论回到原始材料里核对尤其是模型自己补的数据这类内容最容易看着合理但来源不明。可执行性检查如果是方案或代码问一句“按这个做第一步要准备什么”答不上来的部分就是空话。5. 落地排查五条踩坑记录每条都对应一个具体动作前面讲的是怎么用对这一章讲怎么用崩的。下面五条都是我实际遇到过的按“现象—原因—解决”写方便对照。5.1 模型与开关层面的两条现象给推理模型加了详细的人设和分步指令输出反而变啰嗦逻辑链中途断掉。原因推理模型已经把推理过程内化了外部的分步拆解和角色设定会跟它自己的推理主线抢注意力强行拆步反而限制能力。解决删掉角色描述和“第一步、第二步”的硬拆解只保留任务目标、必要约束和输出格式重跑一遍对比。现象开了深度思考去处理一个简单改写任务等很久输出还过度展开。原因慢速思考模型适合复杂问题简单任务上它的逐步推演是纯开销而且容易把一句话的改写写成三段分析。解决按任务复杂度决定是否开启改写、翻译、格式转换这类任务关掉证明、核算、方案权衡再开。5.2 提示语与输入层面的三条现象输出看着很专业但中间步骤是编的数字对不上。原因拿通用模型做多步推理它靠概率续写补全了缺失环节表面上连贯。解决换推理模型或者把任务拆成多轮每轮只让它做一步并要求给出中间结论逐步核对。现象一份提示语里同时要“两百字以内”和“覆盖八个要点”输出顾此失彼。原因约束之间互相冲突模型只能自行取舍而取舍顺序不可控。解决一次只留一个主目标其余降级为建议项或者拆成两轮先扩写再压缩。现象上传扫描件或图片让它读文字表格错行、公式丢失后续分析全错。原因文件里的版式信息在识别环节被压平了模型拿到的是流水文本。解决先让它复述识别到的结构几列、几行、表头是什么确认无误再让它做加工结构不对就换更清晰的输入。提示这五条里前两条和第四条最容易被忽略因为它们不会报错只会让输出“看起来还行”。判断标准很简单结果你需要二次返工的比例就是踩坑率。6. 把提示语沉淀成资产一张登记表加三档验收调到第十版提示语的时候人已经记不清第一版长什么样了。我后来的习惯是每类任务只维护一张登记表字段固定任务类型、用哪个模型、提示语版本号、关键约束、验收点、已知失败模式。看起来是多此一举但它解决了一个很实际的问题——下次遇到同类任务不用从零开始试直接翻表拿最近一版能用的。这张表大概长这样字段填写示例作用任务类型分析需求 / 决策需求决定模型与公式模型推理侧或通用侧固定变量避免混跑版本号v3注明改动点出问题能回滚关键约束三种方案、不引入新依赖防输出漂移验收点数字可核对、格式为表可量化检查失败模式漏掉边界条件下次重点看验收我分三档成本从低到高。第一档只做格式核对几秒钟适合高频低风险任务比如改写和摘要。第二档加事实抽查从输出里挑两三个点回原文核对适合要对外发的材料。第三档做回归对比同一提示语在两类模型上各跑一遍看结论是否一致一致才敢用适合涉及数字和结论的活儿。第三档最费时间但它是唯一能提前发现“模型自信地编”的办法。还有一个具体技巧把提示语里的约束编号。写成“约束 1、约束 2、约束 3”输出后直接对着编号数它执行了几条。这比通读一遍找问题快得多也方便判断是哪条约束总被忽略——总被忽略的那条要么写得太抽象要么和主目标冲突该删就删。从那以后我每次把一条提示语交给团队复用之前都强制走一遍这三档验收尤其是第三档哪怕只挑一个关键结论对比。省下来的返工时间远比多跑一遍模型的时间长。希望帮到你。本文还有配套的精品资源点击获取