DeepSeek推理模型与通用模型：选型、提示语策略与避坑指南

简介：《清华大学 DeepSeek从入门到精通》是一份面向AI初学者、内容创作者、开发者与职场使用者的PDF课件，围绕DeepSeek公司与开源推理模型DeepSeek-R1展开，帮助读者厘清它“是什么、能做什么、如何使用”以及如何从入门走向进阶。资源包仅含1个PDF文件，大小约4.79MB，轻量便于在电脑或移动端查阅，适合作为系统学习与随时检索的提纲式材料。目前已有175人学习。内容从智能对话、文本生成、语义理解、计算推理、代码生成补全等应用切入，进一步讲解推理模型与非推理模型在优势领域、性能本质和适用任务上的差异，并延伸到链式思维、快思慢想、提示语策略及任务需求匹配等关键方法。读者可据此建立模型选择与提示语设计的判断框架，理解不同任务该用简洁指令还是结构化引导，从而在实际写作、分析、编程与多轮对话中更稳妥地发挥DeepSeek-R1的能力。

1. 先认清手上这个模型是哪一类

有个结论我先摆出来：大多数人在 DeepSeek 从入门到精通这件事上卡住，不是因为功能没学会，而是因为从头到尾没搞清「推理模型」和「通用模型」的边界。我第一次把一句「以资深架构师的身份帮我看看这段代码」丢给推理模型时，输出反而比通用模型更僵——那次翻车让我意识到，模型选错了，提示语写得再花也是白搭。这篇东西就是把我自己踩过的坑、比过的维度摊开讲：如果你是刚上手 DeepSeek 的人，能直接抄走一套提示语模板；如果你已经用了一阵，能看到每个结论背后的判断依据，以及为什么有些「玄学调参」其实有明确的因果链。

2. 选模型先立维度：推理模型和通用模型的能力边界在哪

2.1 从「快思慢想」说起，两类模型的底层差别

链式思维（CoT）出现之后，大模型实际上被劈成了两条路线。一条是基于概率预测的快速反应模型，靠大量数据训练快速预测下一个可能答案，响应快、算力成本低，决策靠预设规则和模式识别；另一条是链式推理模型，逐步推理问题的每个步骤再给结论，慢速思考、算力成本高，但能自主分析情况、实时调整决策路径。

DeepSeek-R1 走的是后一条路。它开源、可免费商用，训练目标集中在逻辑密度高的任务上。这里有个特别容易被误读的点：推理模型并不是「全面更强」的升级版，它只是在自己训练目标覆盖的领域里显著优于通用模型。通用模型在开放性、发散性任务上依然更灵活，只是遇到严格逻辑链的任务时，得靠提示语去补偿能力短板。

这个判断直接决定后面所有写法。我见过最常见的误用，是把推理模型当成「更聪明的通用模型」去用，让它写营销文案、写诗、做角色扮演，结果产出又干又硬，然后得出「这模型不行」的结论。反过来，把一道需要严格证明链的数学题丢给通用模型，一次问完，答案看着像模像样，中间步骤却悄悄跳过了一环。

2.2 四个维度打分，把「感觉」变成可比较的判断

我不太信「哪个更强」这种问法，更愿意拆成可打分的维度。下面这张表是我自己常用的，权重按我手头任务的实际比例调的，你可以按自己的场景改权重。

按这张表走一遍，多数任务会落到一个很清晰的象限里：数学推导、逻辑分析、代码生成、复杂问题拆解归推理模型；文本生成、创意写作、多轮对话、开放性问答归通用模型。真正有争议的是中间地带，比如「带约束的创意生成」——既要发散又要有硬性边界，这类我会先用通用模型跑一版，再用推理模型检查约束是否被违反。

2.3 关键原则：按任务类型选，不按热度选

一句话概括选型原则：优先根据任务类型而非模型热度选。数学任务选推理模型，创意任务选通用模型。这话说起来简单，实际落地时最大的干扰来自「新模型出来了，什么都想试试」，试完之后没有对照组，也就无从判断到底是谁的功劳。

所以我一般会给自己定个规矩：同一条需求，两个模型各跑一次，输出放一起对照。跑上十来组，你对边界的直觉就建立起来了，比看十篇评测都管用。这也是我建议把这份资料当「操作手册」而不是「知识读物」的原因——里面的功能清单扫一眼就够，真正值钱的是那些对照关系。

3. 提示语策略分叉：推理模型要「直接说」，通用模型要「缺什么补什么」

3.1 提示语的基本结构，先拆成三块

提示语本质上是用户输入给模型、用来引导其生成特定输出的指令或信息。它的基本结构可以拆成三块：指令（明确任务）、上下文（提供背景信息）、期望（明确或隐含地表达对输出的要求）。这三块不是每块都得写满，但缺哪块，输出就会在哪块上出问题。

按功能再细分，常见的有六种类型：指令型（直接告诉任务，比如「把这段翻译成法语：Hello, world」）、问答型（提问题要答案）、角色扮演型（要求模拟特定场景，比如「假设你是一位 19 世纪的历史学家，评论拿破仑的崛起」）、创意型（引导创意写作，比如「为一篇关于气候变化的文章写引言，长度 200 字」）、分析型（对给定信息做分析推理，比如「用简单的语言解释量子力学，假设你在跟一个 10 岁的孩子说话」）、多模态提示语（结合文本、图像等多种输入）。

类型本身没有优劣，问题出在把某类提示语套到不匹配的模型上。角色扮演型提示语是典型的「通用模型友好、推理模型不友好」，这一点后面会展开。

3.2 推理模型的写法：目标加约束，别替它拆步骤

推理模型的提示语更简洁，只需明确任务目标和需求，因为它已经内化了推理逻辑。你不需要逐步指导，它会自动生成结构化推理过程。这里有个反直觉的点：如果你强行拆解步骤，反而可能限制它的能力。

拿勾股定理举例。对推理模型，有效的提示就是直接一句「证明勾股定理」；无效甚至有害的写法是「先画图，再列公式，然后推导」——你把它本来会自动完成的路径给钉死了，它只能在你的框架里打转，出不了框架外的更优解。

提示：推理模型不是不能加约束，而是约束要放在「结果」层面，不要放在「过程」层面。「输出不超过 500 字」是结果约束，可以加；「第一步做什么、第二步做什么」是过程约束，尽量别加。

这个区别在我自己的实际使用里非常明显。同样是让模型分析一段优化算法选型，我写「为什么选择梯度下降法解决此优化问题？请对比其他算法」，推理模型给出的对比维度经常比我自己想的更全；而我如果写成「先列三种算法，再说明各自优缺点，最后给结论」，它反而变成机械填空。

3.3 通用模型的写法：补推理链、补示例、补格式

通用模型这边逻辑正好反过来。它侧重于语言生成、上下文理解和自然语言处理，不强调深度推理，所以需要显式引导推理步骤，否则可能跳过关键逻辑。典型的补偿手段有三种：要求分步思考、提供示例、明确输出格式。

还是勾股定理，对通用模型的写法是「请分三步推导勾股定理，参考：1. 画直角三角形并标注三边；2. 利用面积关系建立等式；3. 化简得到结论」。这不是在教它数学，是在给它一个可执行的骨架，把它的输出空间压缩到正确的通道里。

再往下细分，通用模型的引导有三条实用套路：

第一，缺什么补什么。它缺推理链，你就要求分步；它缺格式感，你就规定输出结构；它缺领域背景，你就在上下文里补两句话说明场景。

第二，给示例比给规则管用。同样要求「输出简洁」，写十遍「请简洁」不如给一个 50 字以内的样例，模型对样例的模仿精度远高于对抽象形容词的理解。

第三，用结构化标签分隔不同部分。一个提示语里同时塞了背景、任务、约束、格式要求时，用分段或者标签隔开，模型漏项的概率会明显下降。

3.4 三种提示语策略类型，按场景选一种

从「下达指令」到「表达需求」，中间其实有三档策略，各自的适用面不一样。

混合模式是我日常用得最多的一档。它的问题在于「约束多少算合适」没有标准答案——约束太少，模型跑偏；约束太多，输出变成填空。我的经验是先只给两条硬约束跑一版，看输出缺什么，再把缺的那部分补成第三条约束，迭代两轮基本能收敛。

另外一个容易被忽略的类型是启发式提问：通过「为什么」「如何」这类提问引导模型主动思考，触发它的自解释能力。这类提示适合探索性问题、需要模型解释逻辑的场景，比如「为什么选择梯度下降法解决此优化问题？请对比其他算法」。但对推理模型用这一招要小心，因为它本来就会自解释，你再问一遍「为什么」，它可能把精力花在复述上，反而偏离核心目标。

4. 五类任务逐项对照：数学证明、创意写作、代码生成、多轮对话、逻辑分析

4.1 一张任务对照表，看清什么提示有效、什么提示有害

把模型差异落到具体任务上，最能说明问题的是一张对照表。下面这五行是我反复验证过的，每一行都对应「适用模型 + 有效提示 + 需避免的提示策略」三件事。

这张表最值得记住的不是内容本身，而是它的结构：同一个任务，换模型就要换提示语写法。很多人抱怨「模型听不懂我说话」，实际上是拿 A 模型的提示模板去套 B 模型。

创意写作那一行特别典型。推理模型在创意任务上不是不能干，而是它的训练目标让它倾向于收敛到「结构完整、逻辑严密」的方向，你再加「按时间顺序列出」这类约束，产出会彻底失去创意。反过来，给通用模型一句「自由创作」，它会飘到你完全控制不住的地方，最后拿到的东西既不符合需求也不好改。折中办法是给通用模型一个具体的意象组合加一个字数上限，「包含量子与沙漠」这种约束既收窄了范围，又保留了发散空间。

4.2 代码生成任务的复现细节：把提示语模板工程化

代码生成是我用得最多、也最容易验证效果的一类任务。验证成本低——跑一遍就知道对不对，所以特别适合拿来做对照实验。

我的做法是把提示语拆成一个可复用的函数，按模型类型自动切换引导强度。这样每次换模型不用重写提示，只改一个参数。

# 提示语拼装模板：按模型类型切换引导强度 # 参数说明： # model_kind: "reasoning" 走精简分支，"general" 走补偿分支 # payload: 包含 goal（目标）、constraint（硬约束）、skeleton（推理骨架）、 # example（示例）、format（输出格式）五个字段，缺省值按任务类型给 def build_prompt(model_kind, payload): goal = payload["goal"] constraint = payload.get("constraint", "") if model_kind == "reasoning": # 推理模型：只给目标和结果层面的硬约束 # 不写步骤，不写角色扮演，避免干扰其内部推理主线 return f"{goal}\n约束：{constraint}" if constraint else goal # 通用模型：补推理骨架、补示例、补输出格式，三件套缺一不可 skeleton = payload.get("skeleton", "1. 明确已知条件 2. 分步推导 3. 给出结论") example = payload.get("example", "") fmt = payload.get("format", "分点输出，每点不超过两行") return ( f"{goal}\n" f"请按以下步骤思考：\n{skeleton}\n" f"参考示例：{example}\n" f"输出格式：{fmt}" )

这段代码的价值不在实现难度，而在它把「换模型换写法」这件事变成了显式分支，而不是靠人记。我在模拟项目里接过一个代码转换任务，把一段 C 语言逻辑改成 Python，同时要求保持时间复杂度不变、用数组操作优化、输出带时间测试的完整代码。第一次我直接把需求一股脑丢给推理模型，输出质量其实不错，但测试用例是自己补的，跟我的预期不一致。后来改成把三条约束写进constraint字段，测试用例的写法就稳定下来了。

参数怎么改也有讲究。skeleton不是写得越细越好，写到三层以上，通用模型的输出会变成机械填空，反而丢掉它擅长的语言组织能力。我一般控制在三步，每步一个动作，不嵌套。example尽量用短样例，超过一百字模型容易照抄而不是模仿结构。format只约束形式不约束内容，写成「分点输出，每点不超过两行」比写成「每点写满两行」效果好得多，后者会诱发凑字数。

失败时看什么也有章法。如果通用模型的输出漏了中间步骤，八成是skeleton太粗，加一层；如果输出格式每次都跑偏，是format描述太抽象，换成一个具体样例；如果推理模型的输出开始绕圈子，说明你在提示里塞了过程约束或者角色设定，删掉再跑。

4.3 五种需求类型的表达公式，把「想要什么」说清楚

比任务类型更细一层的是需求类型。同样一个任务，你表达需求的方式不同，模型调配的资源也不同。我按决策、分析、创造性、验证、执行五类整理了一套表达公式，配合各自的实战示例。

落到实战，五个示例能说明差别在哪。决策需求：「为降低物流成本，现有两种方案：一是自建区域仓库，初期投入高但长期成本低；二是与第三方合作，按需付费但灵活性高。请根据 ROI 计算模型，对比 5 年内的总成本并推荐最优解。」分析需求：「分析近三年新能源汽车销量数据（附 CSV），说明增长趋势与政策关联性，并预测 2025 年市占率，需使用 ARIMA 模型并解释参数依据。」创造性需求：「设计一款智能家居产品，要求解决独居老人安全问题、结合传感器网络和 AI 预警、提供三种不同技术路线的原型草图说明。」

验证需求是最容易被忽视的一类。典型写法：「以下是某论文结论：神经网络模型 A 优于传统方法 B。请验证：实验数据是否支持该结论；检查对照组设置是否存在偏差；重新计算 p 值并判断显著性。」注意这里的措辞是「验证」不是「解释」，前者逼模型去找反例，后者只会让它把原结论复述一遍。这个区别在我做方案评审时救过不止一次——推理模型确实会主动去挑矛盾点，而通用模型倾向于顺着你的话说。

执行需求的要点是把不确定项全部钉死。比如「将以下 C 语言代码转换为 Python，要求保持时间复杂度不变、使用数组操作优化、输出带时间测试案例的完整代码」。三条要求分别约束了语义、性能和可验证性，少任何一条，输出都会在对应维度上放飞。落库前的最后一步，我会把执行需求和验证需求配对使用：先执行，再把结果丢回去做验证，两轮下来基本能过滤掉大部分「看起来对」的错误。

5. 避坑记录：五次把提示语写歪的现场

5.1 给推理模型套角色扮演，输出反而变僵

现象：让推理模型「以资深架构师的身份点评这段代码」，输出比不加角色时更模板化，通篇是分层架构、关注点分离这类大词，具体到这段代码的问题一条没说。

原因：角色扮演属于启发式提示，本质是给模型一个输出风格的先验。推理模型的强项是把推理链走完整，角色设定会把它的一部分注意力从逻辑主线拽到风格模仿上，两条目标打架，结果两头都不占。

解决：推理模型去掉角色，把角色背后的需求拆出来直说。不要写「以资深架构师身份点评」，改写成「检查这段代码的空指针处理与时序依赖，指出三条具体风险」。角色是手段不是目的，手段在 A 模型上失效，就直接用目的的表述。

5.2 对通用模型一次丢复杂推理题，答案看着对

现象：一道多步逻辑题一次性丢给通用模型，输出结构完整、结论明确，但把中间某一步代回去验算，发现前提被悄悄改了一个条件。

原因：通用模型侧重语言生成与上下文理解，不强调深度推理能力，它能生成「看起来像推导过程」的文本，但每一步未必真的在运算。条件被改这类错误不会报错，只会顺着写下去。

解决：分步追问，每步单独验证。把一道大题拆成三到四个小问，前一步的答案作为后一步的输入，中间人工或者用另一轮对话核验。麻烦是麻烦，但比事后发现结论错了要省事。这条我吃过亏之后就没再偷懒过。

5.3 创意任务给错模型，产出干得像说明书

现象：用推理模型写一段产品文案，出来的东西句式整齐、信息完整，但读起来像需求文档，完全没有传播力。

原因：推理模型的训练目标是逻辑密度高的任务，创意写作属于发散性任务，正好落在它的劣势领域。它不是不会写，而是会优先保证结构完整和逻辑自洽，牺牲掉语言上的意外感。

解决：创意类任务换通用模型，并且一定要给约束。给通用模型「自由创作」，它会飘；给「包含量子与沙漠两个意象的短篇小说，不超过 200 字」，既有边界又有发散空间。如果非要用推理模型做创意，把它放在「检查约束是否被违反」的位置上，别放在「生成」的位置上。

5.4 约束堆太多，模型只完成一半

现象：一条提示语里塞了六条要求，输出只满足了前三条，后三条被忽略，而且模型不会提示你它漏了。

原因：约束越多，模型在解码时需要在多个目标之间做取舍，排在前面的、表述更具体的约束权重更高，靠后的、抽象的约束容易被稀释。这不是模型「不听话」，是提示语的结构问题。

解决：约束分层。硬约束不超过三条，写在最前面并且用具体数字或格式锚定；软偏好放在后面，用「尽量」「优先」这类词标记，允许模型取舍。超过三条硬约束的任务，拆成两轮对话，第一轮定框架，第二轮在框架上补细节。

5.5 把验证需求写成执行需求，拿到结论没拿到验证

现象：想让模型检查一个方案有没有漏洞，写的是「请分析这个方案的可行性」，输出是一篇结构工整的可行性分析，通篇在论证方案可行，漏洞一条没提。

原因：可行性分析和找漏洞是两个方向。前者是顺着结论做支撑，后者是逆着结论找反例。通用模型天然倾向于顺着说，推理模型好一些但也需要明确的指令方向。

解决：把验证需求写成清单式追问——「请列出该方案在并发场景下可能失效的三种情况」「请指出对照组设置中可能存在的偏差」。用「失效」「偏差」「反例」这类反向词，比用「分析」「评估」这类中性词有效得多。我现在写验证类提示，第一句一定是「请找出以下内容中的问题」，而不是「请评价以下内容」。

6. 一套能反复用的判断流程，从会问到问得准

把前面这些收成一条可执行的路径，我在实际项目里是这么走的，顺序不能乱：

第一步，把任务归类。先问自己这活儿的逻辑密度高不高，是不是需要严格推理链才能做对。数学证明、代码实现、方案评审归高密度；文案、对话、开放问答归低密度。这一步错了，后面全错。

第二步，按类型定模型。高密度优先推理模型，低密度优先通用模型。中间地带用混合打法：通用模型出初稿，推理模型做校验。别按「哪个模型更新」来选，这条我强调过不止一次。

第三步，写提示语。推理模型走精简路线，只给目标和结果层面的硬约束；通用模型走补偿路线，补推理骨架、补示例、补输出格式，骨架控制在三步以内，示例控制在一百字以内。

第四步，验证。执行类任务出结果后，把结果再丢回去做一轮验证，用反向词提问。验证成本永远低于返工成本，这一点在代码和方案类任务上是铁律。

第五步，沉淀模板。跑通的提示语存下来，按任务类型归档。我自己的模板库现在有二十来条，覆盖代码转换、数据核对、文案生成、方案挑错几类高频场景。模板复用不是偷懒，是把「写提示语」这件事从每次从零开始变成增量改进。

注意：模板要定期回炉。模型迭代之后，原来有效的提示语可能变成过度约束，尤其是推理模型这一路。我一般每换一次主用模型，就把模板库跑一遍，删掉那些明显多余的步骤引导。

回过头看，我从「会问」到「问得准」中间隔了大半年，踩的坑基本都集中在两件事上：模型选错，以及提示语强度和模型类型不匹配。这两件事都不是靠多读功能列表能解决的，得靠对照实验。从那以后我每次换新模型，都强制走一遍上面这五步，先用十来组对照任务把边界摸出来，再往正式任务上铺。这套流程不快，但它是我目前找到的最省后悔药的办法。这份资料里关于推理模型与通用模型的对照部分，恰好是这套流程的现成注脚，把它当操作底稿比当读物更划算。希望帮到你。

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