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

简介：《清华大学 DeepSeek从入门到精通》是一份面向AI初学者、产品与技术人员及高校师生的PDF课程材料，围绕DeepSeek公司与DeepSeek-R1开源推理模型展开，帮助读者建立从基础认知到实际应用的完整知识框架。内容系统梳理DeepSeek是什么、能做什么、如何使用，并延伸到文本生成、语义理解、计算推理、代码生成补全等典型场景，同时对比推理模型与非推理模型在优势领域、性能本质和适用任务上的差异。材料还讨论链式思维下的“快思慢想”、提示语策略差异、任务需求与提示语匹配，以及从“下达指令”到“表达需求”的转变，并给出指令驱动、需求导向、混合模式与启发式提问等策略示例。资源包为1个PDF文件，大小约4.79MB，结构紧凑便于通读与检索；目前已有175人学习。读者可借此理解DeepSeek-R1的能力边界，掌握面向不同任务的模型选择与提示语设计思路，形成可复用的AI应用方法。

1. 大多数人第一次用推理模型，都会本能地把提示语写长

加角色、加步骤、加示例，生怕模型漏掉什么。结果常常相反：输出的推理链条反而变短、变浅，甚至绕开了真正难的那一步。这不是玄学。DeepSeek 这类推理模型在训练阶段就把「怎么想」内化了，你从外面再塞一套思考模板，等于在它已经铺好的推理轨道上横插一段岔路。反过来，同一个问题丢给通用模型，如果只写一句「帮我分析一下」，它大概率会跳步——因为你没有替它把推理的台阶搭出来。

同一个动作，两种模型给出相反的结果，背后是「推理是否被展开成显式步骤」这个根本差异。搞懂这条分界线，提示语该怎么写、模型该怎么选，就都有了判断依据，而不是靠反复试错攒经验。

2. 快思与慢想：CoT 究竟把大模型劈成了哪两类

链式思维（Chain-of-Thought）出现之后，大模型不再是一个笼统的概念。按「推理过程是否外化为 token」这条线切，至少分成两类：一类是概率预测型的快速反应模型，一类是链式推理型的慢速思考模型。这两者的差别不是参数多少、也不是版本新旧，而是计算路径不一样。

2.1 概率预测与链式推理：同一个问题，两条计算路径

给定一个问题 q，概率预测模型的典型行为是一次前向计算，直接对答案 y 的 token 分布做采样。链式推理模型则不同，它在给出最终答案之前，会先生成一串中间推理 token，再把「问题 + 这串中间结果」一起作为上下文，去生成下一段推理或最终答案。把这条路径写成伪代码，差异一目了然。

# 路径 A：概率预测（快速反应） # 一次前向，直接得到答案分布 answer = sample(P(y | q)) # 路径 B：链式推理（慢速思考） # 推理过程本身被展开成 token，逐步累积进上下文 chain = [] for step in range(max_steps): r = sample(P(r | q, *chain)) # 第 n 步依赖前 n-1 步 if is_conclusive(r): # 模型自行判断推理是否收敛 break chain.append(r) answer = sample(P(y | q, *chain)) # 答案建立在整条推理链之上

这段伪代码里有三个值得盯住的点。第一，chain是一个显式的、可被外部读取的中间结构，它既带来了可解释性，也带来了可纠错性——推理链错了，人能看见错在哪一步。第二，循环次数max_steps直接决定了延迟和算力成本，这就是「慢」的来源，它不是工程缺陷，而是用延迟换正确率的主动取舍。第三，第 n 步的采样依赖前 n-1 步的全部输出，任何一个中间步骤跑偏，误差都会沿着链条往后传，所以这类模型对「第一步」的质量极其敏感。

is_conclusive是模型自己学出来的终止判断，不是外部脚本控制的开关。这一点很关键：意味着你无法通过外部指令精确规定它「想几步」，只能通过需求描述的清晰度去影响它的推理收敛速度。

2.2 优势领域的错位：为什么擅长写诗的模型算不好数学题

能力边界是由训练目标塑造的，不是由参数量塑造的。文本生成类模型的优化目标是「下一个 token 的似然」，这个目标对开放式、多样性高的任务是友好的——写诗、写文案、多轮闲聊，本来就没有唯一正确答案，多样性是优点而不是噪声。但数学证明、逻辑推演、复杂问题拆解属于逻辑密度极高的任务，它们的特征是「某一步错了整条链就废了」，需要的是每一步的局部正确性校验，而不是整体语言流畅度。

推理模型在这类任务上显著更强，是因为「生成正确的推理链」本身成了优化目标的一部分。常见的实现思路是引入强化学习等手段，让模型在大量可验证的问题上反复练习「怎么一步步推」这件事，而不是只练「怎么把话说顺」。

反过来的错位同样成立：在发散性任务上，推理模型并不占优。它被训练成收敛到一条正确路径，而创意写作恰恰需要不收敛。用推理模型写诗，经常得到一个结构工整但没什么惊喜的结果，原因就在这里。

把这个差异整理成一张对照表，选型时的判断会更立体：

表格里最容易被忽略的是「强弱判断」那一行：推理模型并非全面更强。这个判断的价值在于，它直接否定了「新模型一定碾压旧模型」的直觉，也顺带解释了为什么按热度选型是个坏习惯。

2.3 从训练目标反推能力边界：选型的判断依据

理解了上面这条因果链，选型就不再是玄学。判断顺序应该是：先看任务有没有唯一正确答案。有唯一答案、且需要多步推导（数学、代码、逻辑分析），交给推理模型；没有唯一答案、或者答案的开放性本身就是价值（文案、故事、头脑风暴），交给通用模型。

再看任务对延迟的容忍度。链式推理的算力成本高、响应慢，交互式的即时补全场景里，快速反应模型反而更合适。最后看任务是否需要人复核中间过程。需要看推理链的场景，推理模型的显式链条本身就是可审计的资产；只关心最终结果的场景，链条长反而增加了阅读负担。

这条判断依据之所以重要，是因为它把「模型选择」放在了「提示语设计」之前。提示语是补偿手段，不是能力来源。选错模型，提示语写得再精巧，也只是在错误的地基上做装修。

3. 提示语策略的分叉：同一句话，两种模型收到的是不同信号

很多提示语技巧的失效，不是因为写得不好，而是因为用错了对象。推理模型和通用模型对同一段提示语的「吸收方式」不一样：前者读的是任务目标和需求边界，后者读的是步骤和示例。写给谁，决定了该写什么。

3.1 内化逻辑与「少即是多」

推理模型已经通过训练把推理逻辑内化了，所以提示语只需要明确任务目标和需求，剩下的交给它自己规划。常见的写法是「用 Python 实现快速排序，输出需包含注释」，一句话就够了，步骤怎么拆、递归怎么写，模型自己会处理。这时候如果你强行拆解步骤，比如先要求它「定义递归函数」再要求「写分区逻辑」，反而可能限制它的能力——因为它本来有一条更优的路径，被你用外部模板锁死了。

这就是「少即是多」的真实含义：不是提示语越短越好，而是不要把模型的自主规划空间提前压缩掉。你可以给足上下文和边界条件，但不要给推理过程本身派活。

需要特别提醒的是「启发式提示」的干扰。角色扮演这类手法，本质是在给模型注入一个人格化的先验，它对通用模型的发散输出有帮助，但对推理模型可能干扰逻辑主线——模型会花算力去维持角色一致性，而不是解题。

提示：判断一条提示语是否越界，标准是它有没有替模型规定「先想什么再想什么」。规定了，就是越界。

3.2 补偿性引导：通用模型缺什么补什么

通用模型的短板恰好是推理模型的默认能力，所以对它的提示语需要做补偿性设计：显式要求分步思考，提供示例，明确输入输出格式。这一整套动作，本质上是在外部用提示语模拟出一个 CoT 过程——模型自己没有内化推理，你就用语言把台阶一级一级搭出来。

关键在于「显式」二字。对通用模型直接问一个复杂推理问题，它可能跳过关键逻辑直接给结论，而且这个结论听上去还挺像回事。这种输出最难排查，因为它看起来完整。解决办法是把「分步」写进要求里，比如要求「先列出已知条件，再逐步推导，最后给结论」，把推理过程变成必须产出的中间产物。

同时也要避免另一个极端：对通用模型过度信任。涉及数字、逻辑链、事实核验的任务，拿到结果之后要分步验证，而不是整段照收。

3.3 提示语的三层结构与五种型态

不管写给哪类模型，提示语的结构是稳定的，由三层组成：指令明确告诉模型要执行什么任务，是核心；上下文提供必要的背景信息，帮助它更准确地理解任务；期望则明确或隐含地表达对输出的要求和预期。三层缺一，输出要么跑偏，要么飘。

按功能再往下分，提示语可以归成几种型态：指令型直接下达任务，问答型抛出问题等待答案，角色扮演型要求模拟特定场景，创意型引导内容生成，分析型要求对给定信息做推理，多模态型则结合文本与图像等多种输入。每种型态的适用场景不同，混用容易失效——比如把分析型任务写成角色扮演型，模型会花力气「演」而不是「算」。

从机制角度理解，提示语扮演的是五个角色：连接人类意图与模型理解的沟通桥梁、提供背景的上下文提供者、明确任务的任务定义器、影响输出形式的输出塑造器，以及引导模型调用特定能力的引导器。把一段提示语拆到这几个角色上逐一检查，通常能定位出它为什么不好用——是桥梁没搭上（意图不清），还是塑造器缺位（输出格式没定）。

def build_prompt(task, context, expectation, model_type): """按三层结构组装提示语，并按模型类型调整引导强度""" parts = [task] # 指令：任务核心，必填 if context: parts.append(f"背景：{context}") # 上下文：帮模型准确理解 if expectation: parts.append(f"要求：{expectation}") # 期望：输出形式与质量标准 if model_type == "general": # 通用模型：显式补上推理步骤要求，外部模拟 CoT parts.append("请先列出关键条件，再逐步推导，最后给出结论。") # 推理模型：不加步骤指令，保留自主规划空间 return "\n".join(parts)

这个模板里，task是不能省的那一层，context和expectation按需补。真正体现设计取舍的是末尾那个分支：只对通用模型追加步骤要求，对推理模型保持沉默。一个if分支，就把两类模型的提示语策略差异固化进了代码，避免每次手写时凭感觉决定加不加步骤。

4. 需求表达的三种策略与五类形态

从「下达指令」到「表达需求」，是提示语设计的一次视角切换。指令驱动关心的是「你按我说的做」，需求导向关心的是「我要解决什么问题」。前者可控但上限低，后者上限高但需要把需求边界说清楚。

4.1 指令驱动、需求导向与混合模式

指令驱动适合简单任务和需要快速执行的场景，写法是直接给出明确步骤或格式要求，比如「用 Python 编写快速排序函数，输出需包含注释」。优势是结果精准高效，风险是限制了模型的自主优化空间——它只能在你划的圈里走。

需求导向适合复杂问题、需要模型自主推理的场景，写法是描述问题背景与目标，比如「我需要优化用户登录流程，请分析当前瓶颈并提出 3 种方案」。优势是能激发深层推理，风险是需求边界不清时输出会发散。

混合模式是两者的折中：给目标和关键约束，但不规定路径。比如「设计一个三日行程，包含某两个指定地点，且预算控制在 2000 元内」。它兼顾了灵活性与可控性，真正的难点在于「约束不能过度」——约束太多就退化成指令驱动，约束太少就变成纯需求导向。

这三种策略的选择，本质是在「可控性」和「模型自主性」之间调一个比例。任务越标准化，越往指令驱动偏；问题越新颖、越需要模型的判断力，越往需求导向偏。

4.2 五类需求的表达公式与适配矩阵

把需求按目的分类，会得到五种形态，每种都有相对稳定的表达公式和适配策略。这张矩阵是把「感觉怎么写都行」变成「知道该写哪几段」的关键。

这张表最实用的地方，是它给出了每类需求的「必填字段」。决策需求如果漏了评估标准，模型给的推荐就没有依据；验证需求如果漏了验证方法，模型只会复述结论；执行需求如果漏了输出格式，回来的东西往往不能直接用。

4.3 把公式落到可复用的模板

公式要能用，得落成模板。下面这段代码把五类需求做成可调用的构造函数，字段名直接对应上表的公式，缺字段时会抛错，避免「忘了写评估标准」这类低级失误。

from dataclasses import dataclass, field @dataclass class DecisionReq: goal: str # 目标 options: list # 可选项 criteria: list # 评估标准，缺失则无法比较 def render(self): assert self.criteria, "决策需求必须给出评估标准" opts = "；".join(f"{i+1}) {o}" for i, o in enumerate(self.options)) crit = "、".join(self.criteria) return f"目标：{self.goal}\n可选方案：{opts}\n请按 {crit} 逐项对比并给出推荐理由。" @dataclass class VerifyReq: claim: str # 待验证的结论或方案 method: str # 验证方法，如重算、对照、显著性检验 risks: list = field(default_factory=list) def render(self): return (f"待验证结论：{self.claim}\n" f"请使用「{self.method}」重新核验，并列出可能推翻该结论的风险点。")

assert那一行是刻意留下的护栏：决策类需求没有评估标准，就等于让模型凭偏好选，输出看起来合理但不可复现。VerifyReq里method是必填，也是同样的道理——只写「请检查一下」，模型大多会把原结论换个说法再讲一遍，这不叫验证。

模板的价值不在于省打字，而在于把「需求表达公式」变成不可绕过的结构。写的时候被assert拦一次，比拿到一份似是而非的输出再去返工要划算得多。

5. 排查与避坑：五类让输出质量大幅下降的提示语写法

下面这些都是踩过的坑，按「现象 → 原因 → 解决」记下来，方便对照排查。

5.1 对推理模型做角色扮演，推理链反而变浅

现象：给推理模型加上「你是一位资深算法工程师」这类角色设定后，解题输出变得很「像专家」，但推理步骤明显变短，复杂步骤被跳过。

原因：角色设定注入了一个人格化的先验，模型需要分配算力去维持角色一致性，逻辑主线被稀释。对推理模型来说，这是纯粹的干扰项。

解决：去掉角色前缀，直接写任务目标和输出要求。如果确实需要专业视角，用「以算法复杂度为评估标准」这类具体约束替代角色扮演。

5.2 对通用模型一次性抛出复杂推理

现象：把一道多步推导题原样丢给通用模型，它给出的答案逻辑跳跃，中间缺少关键推导，但语气非常笃定。

原因：通用模型没有内化推理能力，默认走的是「下一个 token 似然最大」的路径，它会优先产出流畅的结论，而不是正确的过程。

解决：显式要求分步。把「先列已知条件 → 再逐步推导 → 最后给结论」写进指令，并要求它把每一步的依据标出来。拿到结果后对关键步骤单独复核。

5.3 把「简洁」理解成「模糊」

现象：听说推理模型喜欢简洁提示，于是只写「帮我优化一下这段代码」，回来的改动方向和预期完全不符。

原因：简洁指的是不规定推理步骤，不是不定义任务边界。目标模糊时，模型只能自己猜你要优化性能、可读性还是内存占用。

解决：保持指令简洁，但把边界说死。补上语言、约束条件、评价维度，例如「在不改变时间复杂度的前提下，优化这段 Python 代码的可读性」。

5.4 用示例堆叠替代需求定义

现象：提示语里塞了五六个示例，模型输出的结构和示例高度相似，但换个场景就失效。

原因：示例是强引导信号，数量一多，模型会优先复制示例的形式，而不是理解你要解决的实际问题，本质是把需求定义偷换成了模式匹配。

解决：示例控制在必要数量内，并明确说明「示例仅示意格式，内容需按实际需求生成」。需求定义用文字写清楚，示例只用来锁定输出结构。

5.5 验证需求写成「请检查一下」

现象：让模型验证一个结论，它把原结论换个措辞复述一遍，并补充「该结论基本可靠」。

原因：没有指定验证方法，模型缺乏可执行的验证路径，只能做表层语言层面的确认，这不构成真正的检查。

解决：把验证方法写进需求，指定重算方式、对照条件或风险点清单。要求它输出「可能推翻该结论的情形」，比要求它「判断对错」有效得多。

注意：这五条里有四条的共同根源是「需求边界缺失」，而不是模型能力不足。排查时优先检查边界，再怀疑模型。

6. 设计取舍：为什么模型选择必须排在提示语设计之前

把这份讲义的结构拆开看，会发现它先讲「推理模型与通用模型的差异」，再讲「提示语策略」，最后才落到具体需求的表达方式。这个顺序不是随手排的，它对应一条因果链：模型能力由训练目标决定，提示语只能在能力边界内做补偿，需求表达则是在补偿之上做精确投递。顺序反过来，就会陷入「提示语写得不够好」的自我怀疑，而真正的问题可能是模型选错了。

这个取舍的现实意义在于，它给了你一个成本更低的排查顺序。遇到输出不理想，先问任务类型对不对——需要严格逻辑链的任务交给通用模型，提示语写得再结构化，也只是在外部模拟推理，效率天然低于内化了推理的模型。再问提示语有没有越界——对推理模型强行拆解步骤，是把它的优势压平。最后才问需求边界清不清楚，评估标准、验证方法、输出格式这些字段有没有漏。

验证这套判断有个简单办法：同一个任务，用两种模型各跑一遍，提示语分别按各自策略写。如果推理模型在逻辑密度高的任务上明显更稳，通用模型在开放性任务上明显更活，说明你的选型逻辑和提示语策略是自洽的。如果两者表现差不多，大概率是提示语把差异抹平了——要么对推理模型约束过度，要么对通用模型引导不足。

进阶方向也很清楚：把五类需求的模板固化成自己的提示语库，用代码管理而不是靠记忆。需求类型作为入参，模板负责组装，模型类型决定是否追加步骤引导。这套东西一旦跑顺，换模型、换任务时的迁移成本会降得很低。

我自己的习惯是，每次拿到一个新任务，先花三十秒判断它属于哪类需求、有没有唯一正确答案，再决定用哪个模型、套哪个模板。这个动作最初很别扭，坚持一段时间后成了条件反射，返工率明显下降。踩过的坑大多不是因为提示语写得不够花哨，而是因为跳过了这一步判断，直接开始写。希望帮到你。

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