企业官网建设流程全解析

简介：这份由清华大学新闻与传播学院新媒体研究中心团队编写的《DeepSeek：从入门到精通》AI手册，面向希望系统掌握大模型应用的开发者、内容创作者与研究者，帮助读者从基础认知走向实战精通。资源为1个PDF文件，压缩包约4.83MB，内容围绕DeepSeek的能力边界与使用策略展开，涵盖智能对话、文本生成、语义理解、计算推理与代码生成补全等核心场景。手册重点剖析推理模型与通用模型的差异，讲解提示语策略、CoT链式思维及任务与模型的匹配原则，并给出数学证明、创意写作、代码生成等场景下的有效提示示例。读者可借此理解DeepSeek-R1的开源推理优势，掌握从指令驱动到需求导向的提示设计方法，提升AI工具在写作、分析与编程中的实际效能。目前已有2215人学习关注，适合作为大模型入门与进阶的参考读物。

1. 从一份 104 页手册说起：DeepSeek 到底能替我们干什么

上周有个做后端的朋友找我，说他们团队想用大模型把接口文档和单元测试的活儿接过去，试了几个工具，要么生成结果飘，要么一涉及多步逻辑就翻车。我问他看过那份 104 页的《DeepSeek：从入门到精通》没有，他说没听过。这其实是很多一线开发者的现状——模型天天在用，但一份把「怎么选模型、怎么写提示语、什么任务该交给谁」讲透的手册，反而没人系统读过。

这份手册来自清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室，余梦珑博士后团队整理，核心不是讲 DeepSeek 这家公司有多强，而是把「推理模型」和「通用模型」这两类东西掰开揉碎，告诉你什么任务该用哪种、提示语该怎么写、哪些坑不要踩。它覆盖了文本生成、语义理解、代码补全、知识推理这几大块，还专门拆了 CoT 链式思维、快思慢想、提示语策略差异这些容易混淆的概念。如果你日常要写文案、做数据分析、生成代码片段，或者带团队落地 AI 工作流，这份手册能帮你把「凭感觉用」变成「按任务类型选」。

我把它当成一本操作手册来读，而不是科普读物。下面按「先搞懂模型分类 → 再动手写提示语 → 最后避坑」的顺序，把里面真正能落地的部分拆出来。

2. 推理模型与通用模型：选错类型，提示语全白写

2.1 两类模型的本质差异

手册里反复强调一个判断：推理模型和通用模型不是「谁更强」的关系，而是「谁更适合当前任务」。推理模型（比如 DeepSeek-R1 这类）在训练阶段强化了逻辑链、数学推导和复杂问题拆解能力，它内化了推理步骤，所以你给它一个明确目标，它会自己展开思考过程。通用模型则侧重语言生成、上下文理解和多轮对话，它擅长的是多样性高的任务，但遇到严格逻辑链的任务，需要你用提示语把步骤补上。

这个差异直接决定了提示语怎么写。手册里有一张对比表，我把它简化成下面这个版本，方便你贴在工位上：

我自己的经验是：用推理模型写代码，直接说「用 Python 实现快速排序，输出带注释」就够了；用通用模型写同样的东西，得补一句「先解释快速排序原理，再写出代码并测试示例」，否则它可能给你一段能跑但边界条件没处理的代码。

2.2 快思慢想：概率预测与链式推理

手册里用「快思慢想」来区分两类模型的运作方式。概率预测模型（快速反应）基于大量数据训练，快速预测可能答案，响应快、算力成本低，适合即时任务；链式推理模型（慢速思考）基于 CoT 逐步推理问题的每个步骤，算力成本高，但能处理多维度、非结构化问题。

这个区分在实际使用中非常关键。比如你让模型做「分析近三年新能源汽车销量数据，预测明年市占率」，这就是典型的链式推理任务，需要模型触发因果链推导和假设验证。如果你用快速反应模型直接问，它可能给你一个基于表面模式的猜测；如果你用推理模型但提示语写得太碎，比如「先列数据，再算增长率，再预测」，反而可能打断它自己的推理主线。

手册里给了一个判断原则：任务需要权衡选项、评估风险、选择最优解时，优先用推理模型；任务需要快速反馈、处理即时问答时，用通用模型。这不是绝对的，但能帮你少走弯路。

2.3 提示语策略：从「下达指令」到「表达需求」

手册把提示语策略分成三种类型：指令驱动、需求导向、混合模式。指令驱动适合简单任务，直接给明确步骤和格式要求；需求导向适合复杂问题，描述问题背景与目标，由模型规划解决路径；混合模式结合需求描述与关键约束条件，平衡灵活性与可控性。

我拿一个实际场景来演示。假设你要优化用户登录流程，用推理模型时，提示语可以这样写：

# 推理模型提示语示例：需求导向 prompt = """ 我需要优化用户登录流程，请分析当前瓶颈并提出3种方案。 当前情况：日活10万，登录接口平均响应时间800ms，峰值QPS 2000。 约束：不能改动现有数据库表结构，预算有限。 """

这段提示语没有告诉模型「先做什么再做什么」，而是把问题背景、目标、约束条件说清楚，让推理模型自己展开逻辑链。如果你用的是通用模型，同样的任务需要补上步骤引导：

# 通用模型提示语示例：结构化补偿 prompt = """ 请分三步分析用户登录流程优化问题： 第一步：列出当前登录流程的各个环节及耗时； 第二步：识别每个环节的瓶颈点； 第三步：针对每个瓶颈提出至少一种优化方案，并评估实施成本。 背景：日活10万，登录接口平均响应时间800ms，峰值QPS 2000。 """

两种写法的区别在于：推理模型需要的是「边界清晰的需求」，通用模型需要的是「步骤明确的引导」。手册里有一句话我印象很深：不要对推理模型使用启发式提示（比如角色扮演），可能干扰其逻辑主线；不要对通用模型过度信任，直接问复杂推理问题，需要分步验证结果。

3. 提示语设计实战：五类需求怎么写才不翻车

3.1 决策、分析、创造性、验证、执行：五类需求的提示语公式

手册把用户需求分成五类：决策需求、分析需求、创造性需求、验证需求、执行需求。每一类都有对应的需求表达公式和模型适配策略。我把它整理成一张表，方便你按需查：

这张表的价值在于：它把「怎么写提示语」从玄学变成了可操作的流程。比如你要做一个决策需求，公式是「目标 + 选项 + 评估标准」，推理模型会自动做逻辑推演，通用模型则需要你直接给建议方向。

3.2 实战案例：从物流成本到代码转换

手册里给了几个实战技巧示例，我挑两个最常用的场景展开。

第一个是决策需求。假设你要降低物流成本，有两个方案：自建区域仓库（初期投入高，长期成本低）和与第三方合作（按需付费，灵活性高）。用推理模型时，提示语可以这样写：

# 决策需求：推理模型 prompt = """ 为降低物流成本，现有两种方案： ① 自建区域仓库（初期投入高，长期成本低） ② 与第三方合作（按需付费，灵活性高） 请根据ROI计算模型，对比5年内的总成本并推荐最优选择。 """

推理模型会自动展开ROI计算、成本对比和推荐逻辑。如果你用通用模型，需要补上「请分步计算」的引导，否则它可能直接给你一个结论，缺少中间验证过程。

第二个是执行需求。假设你要把一段 C 语言代码转成 Python，要求保持时间复杂度不变、使用 numpy 优化数组操作、输出带时间测试案例的完整代码。这个任务用推理模型时，提示语可以写得简洁：

# 执行需求：推理模型 prompt = """ 将以下C语言代码转换为Python，要求： ① 保持时间复杂度不变； ② 使用numpy优化数组操作； ③ 输出带时间测试案例的完整代码。 """

推理模型会自己规划转换步骤，兼顾效率和正确性。通用模型则需要你细化步骤，比如「先解释原代码逻辑，再逐函数转换，最后加测试」。

3.3 提示语的基本结构：指令、上下文、期望

手册把提示语的基本结构拆成三部分：指令（Instruction）、上下文（Context）、期望（Expectation）。指令是核心，明确告诉 AI 执行什么任务；上下文提供背景信息；期望明确或隐含地表达你对输出的要求。

这个结构看起来简单，但实际写的时候很容易漏。我见过很多人写提示语只写指令，比如「帮我写个登录接口」，结果模型生成的代码跟项目技术栈完全不匹配。补上上下文和期望之后，效果会好很多：

# 完整提示语结构示例 prompt = """ 指令：帮我写一个用户登录接口。 上下文：项目使用 FastAPI + PostgreSQL，已有 User 表，字段包括 id、username、password_hash。 期望：输出完整的路由函数，包含参数校验、密码验证、JWT 生成，并附上单元测试示例。 """

手册里还提到提示语的本质特征：沟通桥梁、上下文提供者、任务定义器、输出塑造器、AI 能力引导器。这些词听起来有点抽象，但落到实际操作上，就是提醒你：提示语不是「问问题」，而是「定义任务」。

4. 避坑指南：提示语写错，模型再强也救不回来

4.1 对推理模型强行拆解步骤

现象：用推理模型做数学证明或代码生成时，你写了「先画图，再列公式，最后推导」这样的分步指令，结果模型输出反而变得机械，甚至跳过关键推理环节。

原因：推理模型已经内化了推理逻辑，强行拆解步骤会干扰它自己的逻辑主线。手册里明确说：推理模型提示语应简洁，聚焦目标，信任其内化能力。

解决：把分步指令去掉，只给明确目标和约束条件。比如「证明勾股定理」就够了，不需要告诉它先做什么。

4.2 对通用模型直接问复杂推理问题

现象：用通用模型做数学推理或逻辑分析，直接问「分析这个算法的复杂度并优化」，结果模型给了一个表面答案，没有深入推导。

原因：通用模型缺乏推理模型那样的复杂推理和决策能力，需要显式引导推理步骤，比如通过 CoT 提示来补偿能力短板。

解决：补上「请分步思考」「先解释原理再给出方案」这类引导语，或者提供示例让模型参考。

4.3 提示语缺少上下文和期望

现象：模型生成的代码能跑，但跟项目技术栈不匹配；生成的文案风格不对，需要反复调整。

原因：提示语只写了指令，缺少上下文（项目背景、技术栈、数据格式）和期望（输出格式、长度、风格）。

解决：按「指令 + 上下文 + 期望」的结构补全。比如写代码时说明技术栈和已有数据结构，写文案时说明目标受众和风格要求。

4.4 对推理模型使用角色扮演提示

现象：用推理模型做逻辑分析时，写了「假设你是一位资深架构师」这样的角色扮演提示，结果模型输出偏离了核心逻辑。

原因：手册里提到，不要对推理模型使用启发式提示（如角色扮演），可能干扰其逻辑主线。

解决：推理模型更适合直接给任务目标和约束条件，角色扮演留给通用模型或创意类任务。

4.5 通用模型过度信任，缺少验证

现象：用通用模型生成数据分析结论，直接采用，结果发现数据解读有偏差。

原因：通用模型在严格逻辑链任务上需要分步验证，不能直接信任其输出。

解决：对通用模型的输出做交叉验证，或者用推理模型做二次检查。手册里建议：通用模型适合多样性高的任务，专项任务需依赖提示语补偿能力。

5. 进阶技巧：用「需求表达公式」把提示语变成可复用资产

手册里最让我觉得实用的部分，是它把提示语从「每次现写」变成了「按公式套用」。五类需求对应五套公式，你只需要判断当前任务属于哪一类，然后按公式填充内容就行。我自己的习惯是：把常用任务的提示语模板存成一个 Python 字典，用的时候直接调用。

# 提示语模板库示例 PROMPT_TEMPLATES = { "decision": """ 目标：{goal} 选项：{options} 评估标准：{criteria} 请根据以上信息进行逻辑推演和量化分析，推荐最优选择。 """, "analysis": """ 问题：{problem} 数据/信息：{data} 分析方法：{method} 请触发因果链推导与假设验证，输出分析结论。 """, "creative": """ 主题：{topic} 风格/约束：{style} 创新方向：{direction} 请结合逻辑框架生成结构化创意。 """, "verification": """ 结论/方案：{conclusion} 验证方法：{method} 风险点：{risks} 请自主设计验证路径并排查矛盾。 """, "execution": """ 任务：{task} 步骤约束：{constraints} 输出格式：{format} 请自主优化步骤，兼顾效率与正确性。 """ } # 使用示例：决策需求 prompt = PROMPT_TEMPLATES["decision"].format( goal="降低物流成本", options="①自建区域仓库 ②与第三方合作", criteria="5年内总成本ROI" )

这个模板库的好处是：你不需要每次重新思考提示语结构，只需要判断任务类型，然后填充具体内容。手册里还提到一个关键原则：优先根据任务类型而非模型热度选择模型。数学任务选推理模型，创意任务选通用模型，这个判断比「哪个模型更强」重要得多。

另一个进阶技巧是「混合模式」：结合需求描述与关键约束条件，平衡灵活性与可控性。比如设计一个杭州三日游计划，要求包含西湖和灵隐寺，预算控制在2000元内。这个提示语既有需求描述（三日游计划），又有关键约束（西湖、灵隐寺、预算2000元），推理模型和通用模型都能处理，但推理模型会给出更结构化的行程安排。

从那以后我每次写提示语之前，都会先问自己三个问题：这个任务属于哪类需求？该用推理模型还是通用模型？提示语里有没有漏掉上下文和期望？这三个问题过一遍，基本不会翻车。希望帮到你。

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