简介：这份PDF资料源自清华大学新闻与传播学院新媒体研究中心团队，面向希望系统掌握DeepSeek的开发者、内容创作者与AI初学者，帮助读者从基础认知走向实际应用。内容围绕DeepSeek-R1开源推理模型展开，涵盖文本生成、语义理解、代码生成与调试、常规绘图等应用场景，并深入讲解推理模型与通用模型的维度差异、快思慢想机制及CoT提示语策略，指导读者按任务类型选择合适模型。资源包共1个PDF文件，约5.92MB，结构完整、便于通读与检索。目前已有9313人学习，适合需要理解大模型能力边界、优化提示语设计并提升实际使用效果的读者参考。

1. 拿到这份 DeepSeek 手册，先别急着翻目录

上周有个做后端的朋友问我，DeepSeek 到底该怎么用才不浪费。他试过几次，觉得“跟别的聊天框差不多”，就搁下了。我让他把那份从某高校新媒体研究团队流出的《DeepSeek：从入门到精通》翻到提示语那一章，他看完回头跟我说了一句：原来我一直在用通用模型的习惯去喂推理模型。

这份材料的价值不在“DeepSeek 是什么”这种介绍，而在于它把推理模型和通用模型的差异拆成了可操作的提示语策略。它面向的是已经会用 AI、但用得不够好的人——写文案的、做分析的、写代码的、带项目的。如果你只是想知道 DeepSeek 官网在哪，这份东西对你偏重；但如果你手里有具体任务，想让输出稳定、可复现，它值得逐页过一遍。下面我按自己拆读的顺序，把能直接抄的部分和容易翻车的地方讲清楚。

2. 推理模型与通用模型：先选对模型再谈提示语

2.1 两类模型的本质差异在哪

材料里反复强调一个判断：推理模型不是“全面更强”，而是在训练目标领域显著优于通用模型。DeepSeek-R1 这类推理模型，强在数学推导、逻辑分析、代码生成、复杂问题拆解；弱在发散性任务，比如诗歌创作、开放式头脑风暴。通用模型反过来，文本生成、创意写作、多轮对话更灵活，但遇到严格逻辑链的任务，需要提示语去补偿。

这个差异的底层是 CoT（链式思维）带来的分叉。一类是“概率预测”的快速反应模型，靠大量数据快速预测下一个可能答案，响应快、算力成本低；另一类是“链式推理”的慢速思考模型，逐步推演每个步骤再给结论，慢但逻辑密度高。材料用“快思慢想”来概括，这个说法虽然借自心理学，但放在选型上很实用：即时反馈类任务走快思，复杂推理类任务走慢想。

我一般会先问自己一句：这个任务错了会不会很难发现？如果答案是会，比如一段数学证明、一段涉及边界条件的代码，那就该上推理模型，并且提示语要简洁，把目标说清楚就行，不要替它拆步骤。反过来，写营销文案、做多轮客服对话，通用模型更合适，但提示语要给足约束和示例。

2.2 选型对照表与提示语侧重

材料里给了一张任务类型与模型匹配的表，我把它整理成下面这个版本，方便直接对照使用：

这张表的关键不是背下来，而是理解背后的原则：推理模型已经内化了推理逻辑，你强行拆解反而可能限制它的能力；通用模型缺乏这条逻辑链，你不显式引导，它就容易跳过关键步骤。材料里有一句话我印象很深——“不要对推理模型使用启发式提示，比如角色扮演，可能干扰其逻辑主线”。这一点很多人会踩，后面避坑章节会展开。

2.3 一个可复现的对比实验

光看表不够，我建议自己做一次对照。同一个问题，分别用两种提示语喂给推理模型，看输出结构差异。下面是我常用的测试脚本思路，用 Python 调 API 的方式写，参数按你实际环境改：

import requests # 替换为你实际使用的接口地址与密钥，这里只演示请求结构 API_URL = "https://api.example.com/v1/chat/completions" API_KEY = "your_key_here" def ask(prompt, model="deepseek-reasoner", temperature=0.3): payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": temperature, # 推理任务压低随机性 "max_tokens": 2048 } headers = {"Authorization": f"Bearer {API_KEY}"} resp = requests.post(API_URL, json=payload, headers=headers, timeout=60) return resp.json()["choices"][0]["message"]["content"] # 提示语 A：简洁目标型，适合推理模型 prompt_a = "证明勾股定理，给出完整推导步骤。" # 提示语 B：过度拆解型，常见误用 prompt_b = "先画一个直角三角形，再标出三条边，然后列出公式，最后推导勾股定理。" print("A:", ask(prompt_a)) print("B:", ask(prompt_b))

这段代码的逻辑很简单：同一模型、同一温度，只改提示语。temperature设 0.3 是为了让推理输出更稳定，创意任务可以调到 0.8 以上。max_tokens给 2048 是留足推导空间，数学证明类任务别卡太小。跑完对比你会发现，B 这种拆解式提示在推理模型上经常出现“步骤齐全但推导跳跃”的情况，因为模型被你的步骤框住了，反而没走自己的推理链。这个实验成本很低，但能让你对“简洁指令”四个字有体感。

3. 提示语结构拆解：指令、上下文、期望怎么填

3.1 三段式结构的实际写法

材料把提示语拆成指令、上下文、期望三部分。指令是核心，告诉 AI 做什么；上下文提供背景，帮它理解；期望明确输出要求。听起来像教科书，但落到实操，难点在于三者的比例。我的经验是：推理模型偏指令，通用模型偏上下文和期望。

举个材料里的例子改写。决策需求，公式是“目标 + 选项 + 评估标准”。原文示例是降低物流成本的两个方案对比。我把它写成可直接复制的形式：

目标：降低区域物流成本。 选项：①自建区域仓库，初期投入高、长期成本低；②第三方合作，按需付费、灵活性高。 评估标准：按 ROI 模型对比 5 年总成本，考虑折现率 8%。 请给出推荐方案并说明关键假设。

这段提示语里，指令是“给出推荐方案”，上下文是两个选项和评估标准，期望是“说明关键假设”。注意我没有写“请一步一步分析”，因为这是推理模型，它自己会推。如果换成通用模型，我会补一句“请分三步：先算两方案五年现金流，再算 ROI，最后给结论”，这就是补偿性引导。

3.2 五类需求的表达公式

材料把需求分成决策、分析、创造性、验证、执行五类，每类给了公式。这部分是整份材料里最能直接抄的。我按自己的使用习惯重新组织了一下：

决策需求用“目标 + 选项 + 评估标准”，适合选型、方案对比。分析需求用“问题 + 数据/信息 + 分析方法”，适合数据解读、归因。创造性需求用“主题 + 风格/约束 + 创新方向”，适合文案、方案设计。验证需求用“结论/方案 + 验证方法 + 风险点”，适合审稿、查逻辑漏洞。执行需求用“任务 + 步骤约束 + 输出格式”，适合格式转换、代码改写。

这里有个容易忽略的点：验证需求在推理模型上特别好用。材料里的示例是让模型验证一篇论文的结论是否被数据支持，要求检查对照组偏差、重算 p 值。这种任务通用模型容易顺着你的话说，推理模型更可能挑出矛盾。我实际用下来，把“请验证以下结论，指出数据是否支持、对照组是否有偏差”这类提示语固定成一个模板，审技术方案时能省不少事。

3.3 提示语类型与适用边界

材料列了六种提示语类型：指令型、问答型、角色扮演型、创意型、分析型、多模态。这里要泼一盆冷水：角色扮演型在推理模型上要慎用。材料明确写了“不要对推理模型使用启发式提示，如角色扮演，可能干扰其逻辑主线”。我踩过这个坑，让推理模型“扮演一位资深架构师”去分析一个并发问题，结果它花了不少篇幅在角色语气上，真正的锁竞争分析反而浅了。后来改成直接给问题、给约束，输出质量明显回升。

创意型提示语则相反，通用模型上要给足风格和约束，否则容易写成四不像。材料里“以海明威的风格写一个冒险故事”是个好例子，但我会再加一句“不超过 300 字，包含一个反转”，把期望压实。多模态提示语涉及图片输入，材料提到支持文件上传和图片文字扫描，这部分我建议单独测，因为扫描质量受图片清晰度影响很大，后面避坑会讲。

4. 把提示语落到具体任务：四类场景的实操配置

4.1 文本生成与摘要改写

文本生成是通用模型的舒适区，但“能生成”和“生成得能用”之间差的是约束。材料里列了营销文案、社交媒体内容、长文本摘要、多语言翻译等场景。我拿长文本摘要举例，因为这是很多人每天都要做的。

一个常见的翻车是：直接丢一篇长报告说“帮我摘要”，输出要么太泛，要么漏掉关键数据。我的做法是把期望拆成结构：

任务：摘要以下报告。 上下文：报告主题是某季度运营复盘，读者是管理层，关注转化率和成本两项指标。 期望：输出 3 条要点，每条不超过 40 字，必须包含具体数字；最后附一句风险提示。 报告内容：{粘贴正文}

这里{粘贴正文}是占位符，实际使用时替换。参数上，摘要任务温度建议 0.3 到 0.5，太高容易改写失真。如果报告超过模型上下文长度，常见做法是先分段摘要再汇总，不要硬塞。材料提到支持文件上传读取，实操中 PDF 扫描件的文字识别质量不稳定，重要数字建议人工核对一遍，这一点后面避坑章节会展开。

4.2 代码生成与调试

代码任务是推理模型的主场。材料里列了代码生成、错误分析、性能优化、API 文档生成。我的经验是，代码提示语要把“输入输出格式”和“边界条件”写死，否则模型容易给你一个能跑但没处理异常的版本。

# 提示语模板：把这段作为 content 发给模型 prompt = """ 任务：实现一个函数，统计文本中每个单词出现次数。 约束： 1. 输入为字符串，可能包含标点，需先清洗； 2. 输出为 dict，按次数降序； 3. 空字符串返回空 dict，不抛异常； 4. 用 Python 3.10 语法，附 3 个测试用例。 """

这段提示语的关键在约束第 3 条。不写这句，模型很可能不处理空输入，或者直接return None。测试用例要求也是我固定加的，因为模型自带的用例往往只覆盖正常路径。调试场景则反过来，把报错信息和相关代码一起给，提示语写“分析错误原因，给出修复建议，并说明修复后可能引入的新风险”。最后半句是材料里验证需求的思路，能逼模型多想一层。

4.3 语义分析与知识推理

语义分析包括情感分析、意图识别、实体提取、文本分类。这类任务看起来简单，但标签体系不清晰时，输出会飘。材料里提到主题标签生成、垃圾内容检测。我的做法是先给标签定义，再给示例，最后给判定规则。

比如做用户反馈情感分析，提示语里我会写清楚三分类的边界：正面指明确表达满意或推荐，负面指明确表达不满或阻碍，中性指陈述事实无情绪倾向。然后给两三个边界案例。这一步不能省，因为“中性”和“弱负面”的界限，不同人理解不一样，模型需要锚点。推理模型在这类任务上会给出判定理由，通用模型则可能直接给标签，需要你追问依据。

4.4 结构化输出与表格生成

材料提到表格、列表生成，比如日程安排、菜谱。结构化输出的坑在于格式不稳定，同一提示语跑两次，列名可能不一样。解决办法是把 schema 写进提示语，并要求“只输出 JSON，不要解释”。

任务：把以下会议记录转成任务清单。 输出格式：JSON 数组，每个元素包含 owner（字符串）、task（字符串）、deadline（YYYY-MM-DD）、priority（高/中/低）。 约束：deadline 缺失时填 null；priority 按紧急程度推断并在 task 末尾用括号注明依据。 会议记录：{粘贴内容}

owner、task这些字段名固定下来，下游解析才稳。deadline缺失填 null 而不是空字符串，是为了避免类型混乱。要求注明优先级依据，是借了推理模型的自解释能力，方便你复核。如果输出还是带 markdown 代码块包裹，可以在提示语末尾加一句“直接输出 JSON 文本，不要用代码块”，多数情况下能压住。

5. 避坑与排查：五条血泪经验

5.1 对推理模型做角色扮演，逻辑主线被带偏

现象：让推理模型“扮演资深律师”分析合同风险，输出大量角色语气铺垫，真正的条款风险点反而一笔带过。 原因：角色扮演属于启发式提示，会占用模型的推理预算，干扰其内化的逻辑链。 解决：去掉角色设定，直接给任务和约束，比如“分析以下合同条款的违约责任风险，按高/中/低分级并说明依据”。需要语气时，在输出格式里指定，不要放进角色。

5.2 通用模型直接问复杂推理，结果看似合理实则跳步

现象：用通用模型做多步数学或逻辑题，答案结构完整，但中间某步凭空出现一个结论。 原因：通用模型靠概率预测生成，缺乏链式推理，遇到严格逻辑链会“补全”而非“推导”。 解决：换推理模型，或在通用模型上显式要求分步并给示例，同时要求每步标注依据。重要结论必须人工验算，别被流畅的表述骗过去。

5.3 文件上传后直接摘要，扫描件数字错位

现象：上传 PDF 扫描件让模型摘要，金额、日期出现明显错位或漏读。 原因：图片文字识别对清晰度、排版敏感，表格类内容尤其容易串行。 解决：关键数字单独用文本贴一遍，或先人工核对扫描件再喂。材料提到支持文件与图片文字读取，但读取不等于准确，涉及财务、合同类内容，我一般强制走一遍人工比对。

5.4 提示语过度拆解，推理模型反而变笨

现象：把一道证明题拆成“第一步、第二步、第三步”喂给推理模型，输出步骤齐全但推导跳跃。 原因：推理模型已内化推理逻辑，外部强加的步骤框架限制了它的自主推理路径。 解决：只给目标和输出要求，删掉过程性指令。判断标准很简单：如果你的提示语里出现了“先……再……然后……”，而任务是推理类，就该删。

5.5 结构化输出不带 schema，下游解析频繁报错

现象：让模型输出表格或 JSON，字段名每次不一样，解析脚本三天两头改。 原因：提示语只说了“输出表格”，没定义列名和类型，模型自由发挥。 解决：把字段名、类型、缺失值处理写进提示语，并要求只输出目标格式。跑通后把提示语存成模板，别每次重写。温度也压到 0.2 左右，减少格式抖动。

6. 进阶：把提示语模板固化成可复用的验证流程

材料最后落到“还要不要学提示语”这个问题上，答案是肯定的，但学的方式要变。不是背模板，而是建立一套自己的验证流程。我现在的习惯是：任何要重复用的提示语，先跑三组对照——推理模型简洁版、推理模型拆解版、通用模型补偿版，看哪组输出最稳，然后把胜出的那组连同参数一起存进一个本地模板库。

这个模板库不需要复杂工具，一个 Markdown 文件加几个代码块就够。每条模板记录四样东西：适用任务、模型类型、完整提示语、温度与 max_tokens。下面是我模板库里的一个片段，用 Python 字典存，方便脚本直接调用：

TEMPLATES = { "contract_risk": { "model": "deepseek-reasoner", "temperature": 0.2, "max_tokens": 3000, "prompt": ( "分析以下合同条款的违约责任风险。" "按高/中/低分级，每条注明条款原文和风险依据。" "若条款存在歧义，单独列出并给出两种解释。" "条款内容：{clause}" ) }, "feedback_sentiment": { "model": "deepseek-chat", "temperature": 0.4, "max_tokens": 1024, "prompt": ( "对以下用户反馈做情感三分类：正面/中性/负面。" "正面指明确满意或推荐，负面指明确不满或阻碍，中性指陈述事实无情绪。" "输出 JSON：{label, reason}，reason 不超过 30 字。" "反馈：{text}" ) } }

contract_risk走推理模型，温度压到 0.2，因为合同分析要稳；feedback_sentiment走通用模型，温度 0.4 留一点灵活性。{clause}和{text}是占位符，调用时替换。这个结构的好处是，换模型或调参数只改一处，提示语本身不动。

验证方法上，我固定做两件事。一是同一输入跑三次，看输出结构是否一致，格式抖动大的模板直接淘汰。二是拿已知答案的案例做回归，比如一段明确该判“高”风险的条款，看模板是否稳定判高。这两步花不了多少时间，但能挡住大部分“看着能用、一上量就崩”的模板。

从那以后我每次新建提示语模板，都强制走一遍三组对照加三次重跑，宁可前期多花二十分钟，也不想后面在几十条输出里手工纠错。这份材料里关于推理模型与通用模型差异的那几页，我建议你单独打印出来贴在工位上，选型时扫一眼，比事后返工划算。希望帮到你。

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