DeepSeek模型选型与提示语策略：推理做减法，通用做加法

简介：《DeepSeek从入门到精通》是一份面向AI初学者与进阶使用者的系统学习PDF，围绕DeepSeek的能力边界、模型选择与提示语设计展开，帮助读者从“会用”走向“用好”。内容涵盖DeepSeek-R1的开源与免费商用特点、文本生成、语义理解、计算推理、代码生成等应用场景，并重点梳理推理模型与通用模型的优势差异、快思慢想两类模型及不同任务下的提示语策略。压缩包内共1个PDF文件，大小约4.83MB，结构紧凑，适合按章节通读或按任务检索。已有730人浏览学习。读者可借此建立模型选型框架，理解数学证明、创意写作、代码生成等场景的提示语差异，并掌握从指令驱动到需求表达、从入门到精通的实践路径。

1. 从一份模型使用手册说起：为什么很多人用DeepSeek只发挥了三分之一

我见过太多人用 DeepSeek 的方式：把它当成一个更便宜、更快的搜索框，问一句「帮我写个总结」，复制结果，走人。用了三个月，评价是「也就那样」。同一时间，另一批人用同一套模型，把一份三十页的技术报告拆成结构、做假设验证、让它自己列风险点，最后产出的东西能直接进评审材料。差别不在模型，在他们有没有意识到一件事：DeepSeek 这类模型分两种脑子——推理模型和通用模型，选错了脑子，提示语写得再花也没用。

这篇东西讲的就是这份《DeepSeek 从入门到精通》里的核心骨架：它到底能干什么、推理模型和通用模型怎么分、提示语策略在两种模型上为什么必须反过来写、以及从「下达指令」到「表达需求」这条路上会踩哪些坑。新手可以照着结论直接改自己的用法，熟手能看到每个判断背后的依据。我不讲虚的，先把最容易翻车的那个点摊开：你对着推理模型做角色扮演，大概率是在给它添乱。

2. 先分清两种脑子：推理模型与通用模型到底差在哪

2.1 从能力边界看：不是谁更强，是谁更适合

很多人默认「推理模型」是升级版，什么任务都上推理模型。这是第一个认知坑。材料里对这两类模型的界定很清晰：推理模型在传统大语言模型基础上强化了推理、逻辑分析和决策能力，通常借助强化学习、神经符号推理、元学习等技术，典型代表就是 DeepSeek-R1 这类；通用模型侧重语言生成、上下文理解和自然语言处理，通过对大量文本的训练掌握语言规律，能生成合适内容，但不强调深度推理。

关键的那句话是「并非全面更强」。推理模型只在它的训练目标领域——数学推导、逻辑分析、代码生成、复杂问题拆解——显著优于通用模型；通用模型在文本生成、创意写作、多轮对话、开放性问答这类多样性高的任务上更灵活。反过来也一样：你让推理模型去写诗、写发散性的营销创意，它可能还不如通用模型放得开，因为它的推理链路在这种任务上属于「用力过猛」。

我一般这么比：看这个任务有没有唯一正确答案或者可验证的逻辑链。有，走推理模型；没有，走通用模型。数学证明、代码调试、多约束条件下的方案对比，都属于有验证标准的；而文案风格、故事创作、开放式头脑风暴，属于没有标准答案的。

这张表建议直接存下来。它解决的是「DeepSeek 哪个模式适合我」这个最高频的问题——答案不是固定的，取决于你手上的任务属于哪一栏。

2.2 「快思慢想」：概率预测和链式推理的性能账

再往下一层，是 CoT 链式思维带来的分野。材料里把这个分野讲得很形象：一类是「概率预测（快速反应）」模型，像 ChatGPT 4o 那种路子；一类是「链式推理（慢速思考）」模型，像 OpenAI o1、DeepSeek-R1 这类。

快速反应模型的原理是基于概率预测，通过大量数据训练快速预测可能的答案，响应速度快，算力成本低，依赖预设算法和规则做决策，创造力限于模式识别和优化。慢速思考模型基于链式思维，逐步推理问题的每个步骤来得到答案，算力成本高，能自主分析情况实时做决策，能生成新的创意和解决方案，更能自然地理解复杂情感和意图。

这段对比里最值钱的是两个词：算力成本、响应速度。这意味着选型不只是「哪个答得好」，还是一笔效能账。你让推理模型去处理一批简单的分类标注任务，等于用大炮打蚊子，慢且贵；你让通用模型去啃一道多步数学证明，它可能跳过关键逻辑，给你一个看起来很像那么回事、实际中间步骤站不住的结论。这个「看起来对」比「明显错」更危险，因为它不容易被发现。

我见过一个真实的翻车场景：有人拿通用模型做一份财务模型的逻辑校验，模型给了一段非常流畅的分析，语气笃定，结论也符合直觉，但里面有一个隐含假设——它默认了增长率恒定——从头到尾没说出来。这种错误只有你自己拿计算器一步步验才会暴露。换成推理模型，它大概率会把假设显式列出来，因为链式推理本身就会走「先设条件、再推导」的路子。

提示：判断一个任务该用哪种模型，最快的办法是问自己「如果我拿这个结果去担责，我能不能接受它跳过中间步骤」。不能接受的，上推理模型。

3. 提示语策略：两种模型要反着写

3.1 推理模型要「少说」，通用模型要「补齐」

这是整份材料里最反直觉、也最实用的一节。很多人的习惯是提示语写得越详细越好，把每一步都拆给模型。对通用模型，这个习惯是对的；对推理模型，这个习惯是错的。

材料里的原则很明确：推理模型的提示语应该更简洁，只需明确任务目标和需求，因为它已经内化了推理逻辑，无需逐步指导，模型会自动生成结构化推理过程——如果你强行拆解步骤，反而可能限制它的能力。通用模型则相反，需要显式引导推理步骤，比如通过 CoT 提示，否则它可能跳过关键逻辑；它依赖提示语来补偿能力短板，比如要求分步思考、提供示例。

我把这条原则浓缩成八个字：推理模型「要什么直接说」，通用模型「缺什么补什么」。这不是修辞，是两种完全不同的交互姿态。对着推理模型写「请你先分析题目，再列出已知条件，然后第一步、第二步……」，你实际上是在用一个二流流程覆盖它的一流内部流程。

材料里给了几组对照，我挑两个最有代表性的：

注意代码生成那两行：同一个任务，对推理模型你就说一句「用 Python 实现快速排序」，剩下交给它；对通用模型你得把「先解释原理、再写代码、再测试」这个流程明说出来，否则它可能直接甩一段没验证过的代码给你。

3.2 三个必须避开的提示语误区

材料里点了三条误区，我按踩坑的严重程度排一下。

第一条，不要对推理模型使用启发式提示，比如角色扮演。这一条很多人不信，觉得「你是一位资深架构师」这种开场白百试百灵。但推理模型的强项是逻辑主线，角色扮演这类启发式引导可能干扰它的逻辑主线，让它把算力花在「扮演」上而不是「推理」上。我的经验是：需要它严谨推导的时候，别给它加人设；需要它出创意的时候，本来也不该用它。

第二条，不要对通用模型过度信任，尤其是直接询问复杂推理问题。通用模型不会告诉你「这个问题超出了我的推理能力」，它会给你一个通顺的答案。所以对通用模型问复杂推理，必须分步验证结果，必要时拆成多个小问题追问。

第三条，优先根据任务类型而不是模型热度选。这条听着像废话，但每年新模型出来的时候，一堆人把所有任务都迁到最新最热的那个模型上，然后发现创意类任务反而变差了。热度是别人的评价，任务类型是你自己的处境。

3.3 从「下达指令」到「表达需求」：三种策略怎么选

再往上一个层次，是策略类型的选择。材料把它分成指令驱动、需求导向、混合模式三类，这个分层我很认同，因为它对应的是三种不同的任务确定性。

指令驱动是直接给出明确步骤或格式要求，适合简单任务、需要快速执行的场景，优势是结果精准高效，风险是限制了模型的自主优化空间。需求导向是描述问题背景与目标、由模型规划解决路径，适合复杂问题、需要模型自主推理的场景，能激发深层推理，但要求你把需求边界说清楚，否则容易跑偏。混合模式结合需求描述与关键约束条件，兼顾目标与细节，平衡灵活性与可控性，但约束过度会适得其反。

举材料里的三个例子，感受一下差别：

• 指令驱动：「用 Python 编写快速排序函数，输出需包含注释。」
• 需求导向：「我需要优化用户登录流程，请分析当前瓶颈并提出 3 种方案。」
• 混合模式：「设计一个杭州三日游计划，要求包含西湖和灵隐寺，且预算控制在 2000 元内。」

第三个例子最能说明混合模式的价值：它给了目标（三日游）、给了硬约束（西湖、灵隐寺、2000 元），但没有规定每天几点去哪，把路线规划的空间留给模型。这就是「约束给够、路径放开」。

至于启发式提问——「为什么选择梯度下降法解决此优化问题？请对比其他算法」——它适合探索性问题、需要模型解释逻辑的场景，能触发模型的自解释能力，但风险是可能偏离核心目标。用它的前提是你有精力跟着它的解释往下追。

4. 按需求类型配对：五类需求各自的提示语公式

4.1 五类需求的表达公式与模型适配

这一节是整份材料里最能直接抄作业的部分。它把需求分成决策、分析、创造性、验证、执行五类，每类给了特点、表达公式、以及两种模型各自的适配策略。

这张表建议和 2.1 那张对照着看。两张表合起来，基本能覆盖「我这个任务该用哪个模型、提示语该怎么写」的九成场景。

4.2 每个公式配一个能直接用的例子

光有公式不够，材料里每类需求都配了实战示例，我挑几个最能体现差异的展开说。

决策需求的例子：「为降低物流成本，现有两种方案：①自建区域仓库（初期投入高，长期成本低）；②与第三方合作（按需付费，灵活性高）。请根据 ROI 计算模型，对比 5 年内的总成本并推荐最优选择依据。」这个提示语的骨架是「目标（降本）+ 两个选项 + 评估标准（ROI、5 年总成本）」。注意它没有说「帮我选一个」，而是说「推荐最优选择依据」——要的是依据，不是拍脑袋的结论。这种问法对推理模型特别对路，因为它逼着模型把量化过程摊开。

分析需求的例子：「分析近三年新能源汽车销量数据（附 CSV），说明：①增长趋势与政策关联性；②预测 2025 年市占率，需使用 ARIMA 模型并解释参数。」这里的关键是把分析方法和输出结构都钉死——ARIMA、解释参数、两个具体问题。如果不钉死，通用模型很可能给你一段「总体呈上升趋势，前景广阔」的废话。这个例子其实更适合推理模型，因为「政策关联性」和「参数解释」都需要因果链。

验证需求的例子最值得学：「以下是某论文结论：'神经网络模型 A 优于传统方法 B'。请验证：①实验数据是否支持该结论；②检查对照组设置是否存在偏差；③重新计算 p 值并判断显著性。」这个提示语的精妙之处在于它没有问「这个结论对不对」，而是给了三条具体的验证路径。这是把验证需求从「简单确认」提升到「深度推演」的关键——你得告诉模型往哪儿查，它才会真的去查。

执行需求的例子：「将以下 C 语言代码转换为 Python，要求：①保持时间复杂度不变；②使用 numpy 优化数组操作；③输出带时间测试案例的完整代码。」三条约束，一条比一条硬：时间复杂度不变是正确性约束，numpy 是工具约束，带时间测试是完整性约束。这类任务如果丢给通用模型而不给约束，你很可能拿到一段能跑但慢十倍、还没法验证的代码。

注意：创造性需求用通用模型时，开放式指令（如「自由创作」）是陷阱，容易得到平庸结果；更有效的做法是给约束，比如「写一个包含『量子』和『沙漠』的短篇小说，不超过 200 字」。约束不是限制创意，是给创意一个落点。

5. 提示语还要不要学：拆开指令、上下文、期望

5.1 提示语的本质是沟通桥梁，不是咒语

标题问「还要不要学提示语」，这是很多人心里的疑问——模型越来越聪明，是不是随便说就行？材料给的答案是：提示语是用户输入给 AI 系统的指令或信息，用于引导 AI 生成特定输出或执行特定任务；它可以是简单问题、详细指令，也可以是复杂任务描述。它的基本结构包括指令、上下文、期望三部分：指令是核心，明确告诉 AI 执行什么任务；上下文提供背景信息，帮助它更准确理解；期望明确或隐含地表达你对输出的要求和预期。

材料用四个词概括提示语的本质特征：沟通桥梁（连接人类意图和 AI 理解）、上下文提供者（为 AI 提供必要的背景信息）、任务定义器（明确指定需要完成的任务）、输出塑造器（影响 AI 输出的形式和内容）、AI 能力引导器（引导 AI 使用特定能力或技能）。

这五个定位里，我认为最容易被忽略的是「输出塑造器」。很多人只把提示语当任务定义器用——告诉它做什么，但不告诉它输出长什么样、要多长、给谁看。结果就是内容对了、形态不对，还得自己返工。加上一句「输出为 200 字以内的引言，面向非技术读者」，返工率立刻降下来。

5.2 六种提示语类型，各配一个判断标准

材料列了六种提示语类型：指令型（直接告诉 AI 任务）、问答型（提问并期望答案）、角色扮演型（要求扮演特定角色模拟场景）、创意型（引导创意写作或内容生成）、分析型（对给定信息分析推理）、多模态提示语（结合文本、图像等多种输入）。

我把这六种和前面的模型选择结合起来给个判断标准：

指令型对应执行需求，两种模型都能用，但对推理模型要精简，对通用模型要补步骤。问答型是最自然的交互，适合通用模型的多轮对话；如果问题本身是复杂推理，换推理模型，并且别把问题拆碎。角色扮演型要慎用——对通用模型是好工具（比如「假设你是一位 19 世纪的历史学家，评论拿破仑的崛起」），对推理模型可能干扰逻辑主线。创意型天然属于通用模型，配合风格和约束使用。分析型是推理模型的主场，配合 4.1 那张表里的分析需求公式。多模态提示语依赖模型的图像理解能力，材料提到 DeepSeek 支持文件上传、能扫描读取各类文件及图片中的文字内容，处理扫描件、截图类材料时可以直接上传，省掉自己转录的环节。

顺带提一句材料里那张「提示语的本质」对照表，它给每个特征都配了示例，比如「将以下内容翻译为法语：Hello, world」是指令型，「为一篇关于气候变化的文章写一个引言，长度 200 字」体现了输出塑造。这些示例的价值不在记住，在于建立一种直觉：好的提示语里，你几乎总能找到指令、上下文、期望这三块的影子。

6. 避坑清单：五条踩过的坑和解法

6.1 五个高频翻车现场

这一节按「现象 → 原因 → 解决」写，都是我或身边人真实碰过的。

坑一：对着推理模型写了一长串「请你先…再…然后…」，结果它反而答得不如预期。现象是输出变得机械，缺少它本该有的结构化推理；原因是冗余拆解覆盖了模型内化的推理逻辑，相当于给它套了个二流流程；解决是把步骤全部删掉，只留任务目标和输出要求，重跑一遍做对比，差异通常一眼可见。

坑二：用通用模型做复杂逻辑验证，拿到一个通顺但站不住的结论。现象是答案读起来毫无破绽，一验就露馅；原因是通用模型会跳过关键逻辑，且不会主动声明「我跳过了」；解决是换推理模型，或者把问题拆成多个小问题逐步追问，并在提示语里明确要求「列出你所做的所有假设」。

坑三：给推理模型加了角色扮演人设，严谨任务反而变差。现象是数学或代码任务里出现了多余的叙述性内容；原因是启发式提示干扰了逻辑主线；解决是处理严谨任务时去掉人设，只保留任务本身，需要创意时再换回通用模型加人设。

坑四：需求描述太开放，通用模型给出平庸的创意结果。现象是文案、故事类输出四平八稳、没有记忆点；原因是开放式指令让模型退回到概率最高的大众表达；解决是加约束——限定风格、限定字数、限定必须出现的元素，把创意逼到一个具体落点上。

坑五：只写任务不写输出形态，反复返工。现象是内容对但长度、结构、读者对象全不合适；原因是没有把期望说清楚，模型只能猜；解决是把输出格式、长度、面向人群一并写进提示语，比如「输出为表格，三列，不超过 300 字，面向决策者」。

提示：这五条里，坑一和坑三是同源的——都是把通用模型的使用习惯带到了推理模型上。切换模型时，提示语习惯也要跟着切。

7. 我的落地做法：从需求出发选模型、从模型出发写提示

回到最开始那个问题：为什么有人用同一套模型只发挥三分之一。答案是把模型当工具、把提示语当咒语，而不是把模型当有不同专长的协作者、把提示语当需求说明书。

我现在的一个固定流程是这样的，四步，不到两分钟：

第一步，先判任务。这个任务有没有可验证的正确答案或严格逻辑链？有——推理模型；没有——通用模型。这一步只看任务类型，不看哪个模型最近热度高。

第二步，套需求类型。决策、分析、验证这三类偏推理模型，创造性偏通用模型，执行类看复杂度——简单的给通用模型加步骤约束，涉及性能优化的给推理模型。套完类型，公式就出来了：决策是「目标 + 选项 + 评估标准」，验证是「结论 + 验证方法 + 风险点」。

第三步，按模型调提示语。推理模型做减法，删掉所有分步指导和人设，只留目标和输出要求；通用模型做加法，把步骤、示例、输出格式都补上。

第四步，看输出做一次反向校验。推理模型的输出，我重点看它的假设有没有明说；通用模型的输出，我重点抽查中间步骤。这一步是后悔药——与其等结论用在正式材料里被挑出错，不如在这里花三十秒。

举个具体例子。上周我要评估两个技术方案的取舍，一开始图快，丢给通用模型，提示语写得很详细，列了七八条要点，结果它给了一段很圆滑的分析，两个方案各打五十大板，最后建议「结合实际选择」。这就是典型的通用模型在决策需求上的表现——它擅长归纳，不擅长权衡。

我把提示语改写成决策需求公式：「现有两个方案：A（自建，初期投入高，长期边际成本低）、B（采购，按需付费，灵活性高）。请基于五年总成本和风险暴露两个维度做量化对比，明确指出在什么条件下选 A、什么条件下选 B，并列出你使用的所有假设。」换成推理模型，重跑。这一次它把两个方案的交叉点算出来了，假设也列了三条，其中一条我原本没想到——它指出方案 B 在用量波动超过某个区间后成本会反超。这个结论我拿表格验了一遍，站得住。

从那以后我每次动笔写提示语之前，都强制走一遍「先判任务、再套公式、最后按模型加减」这三步。这习惯救过我几次，尤其是在赶进度想偷懒直接开问的时候。

这份《DeepSeek 从入门到精通》里真正值钱的不是那些功能罗列——文本生成、语义分析、代码调试，这些看标题就知道——而是第 2 章和第 3 章那两张对照表，以及「推理模型做减法、通用模型做加法」这条原则。把这条原则吃透，你对同一套模型的使用效率会立刻上一个台阶。资源里的完整框架比我这里展开的更细，尤其是五类需求的实战示例和六种提示语类型的对照，值得对着自己的高频任务逐条改一遍。希望帮到你。

本文还有配套的精品资源，点击获取