简介：《DeepSeek从入门到精通》是一份面向AI初学者、内容创作者与开发者的PDF讲义，聚焦国产大模型DeepSeek的基础认知与进阶使用，帮助读者理解其能力边界，并解决模型选择与提示语设计中的实际问题。压缩包内为1个PDF文件，约5.36MB，内容围绕“是什么、能做什么、如何使用、如何进阶”展开，结构紧凑，便于通读与检索。该讲义结合自然语言处理、AIGC与提示工程语境，系统梳理DeepSeek-R1等推理模型在逻辑推理、数学推导和代码生成中的优势，也对比通用模型在文本创作、多轮对话与开放性问答中的适用场景；同时讲解“快思慢想”、链式思维及任务需求与提示语策略的匹配方法。已有1011人学习，适合希望从会用到用好、按任务选择模型并优化提示语的中初级读者参考。

1. 一句话说清 DeepSeek 是什么：从「会用」到「用得好」差在哪

很多人手机里装着一把瑞士军刀，但真正用到的只有主刀那一层。DeepSeek 给人的感觉也差不多：人人都能用它聊天、写文案、查资料，可多数人停在「会问一句、会得一段」的层面，再往前一步就没了方向。说直白点，DeepSeek 是一款国产的大语言模型产品，背后是一家专注通用人工智能方向、主攻大模型研发与应用的公司，其中开源的推理模型 DeepSeek-R1 擅长处理复杂任务，并且开放商用。它能做的事覆盖智能对话、文本生成、语义理解、计算推理、代码生成与补全，还支持联网搜索、深度思考模式，以及上传文件、读取文件与图片里的文字。真正值得搞懂的，不是「它能不能回答」，而是「为什么同一个问题，有人问出来是废稿，有人问出来是能直接交差的成品」。

2. 它到底能干什么：一张能力地图拆成四块

把 DeepSeek 当成一个「什么都会一点」的聊天框，是最容易浪费它的方式。它的能力其实可以拆成四块相对独立的地盘：一块管「写出来」，一块管「读懂了」，一块管「把代码跑通」，还有一块管「把手边的文件、图片和网上信息接进来」。这四块不是并列的功能按钮，而是四种不同的思维动作——生成、理解、构造、检索。分清楚一块能力负责哪类活儿，你才知道手上的任务该往哪块扔。下面按这四块逐一说透，每块都给出它擅长的具体场景和它容易翻车的地方。

2.1 文本生成：从创意写作到长文摘要的三层用法

第一层是「从零写出来」。文章、故事、诗歌这类创作，营销文案、广告语、社交媒体推文和帖子，剧本或对话设计，都属于这一层。这一层的难点不在模型，而在你有没有把「给谁看、什么调性、多长、要不要留钩子」说清楚。同一句「写个咖啡店开业文案」，得到的是通用模板；换成「写给附近写字楼上班族，早上八点前到店，强调三分钟出杯和自带杯减两块，控制在80字内，不要感叹号」，出来的东西才像人写的。

第二层是「把长的压短、把难的讲浅」。长文本摘要用于论文、报告这类动辄几十页的材料，文本简化用于把专业表述降维成外行能读的版本，多语言翻译与本地化则是在语言之间搬运的同时调整表达习惯。这三件事的共同点是：原文已经在那里了，模型的价值是「不失真地重排信息」。翻车高发区也在这——摘要容易漏掉限定条件，简化容易把「在特定条件下成立」简化成「一定成立」，翻译容易把行业术语译成字面意思。所以这一层产出必须回头对原文核一遍关键结论。

第三层是「结构化生成」。表格、列表这类有固定骨架的内容，比如日程安排、菜谱步骤，以及代码注释、技术文档撰写，都属于这一层。它的特点是输出格式本身就是一半的价值：你要的是一张能贴进文档的对比表，而不是一段散文。这一层最实用的技巧是先把表头或字段名给出来，让模型往格子里填，而不是让它自己决定用什么结构。格式一旦定死，内容质量会明显稳定。

三层用法的共同逻辑是：越往后，你对输出形态的约束要越具体。第一层约束风格，第二层约束事实，第三层约束结构。把这三层混在一起提要求，通常会得到一个哪层都不满意的结果。

2.2 理解与分析：语义、情感、意图背后的「读懂」

文本生成是往外倒，语义理解是往里读。这部分能力平时不显眼，但它是很多实际工作的地基。语义分析与语义解析负责把一句话拆成「谁、对什么、做了什么」，情感分析用于评论和反馈里判断褒贬强弱，意图识别则常见于客服对话和用户查询——用户打出来的是「我这个订单怎么还没到」，真实意图可能是「查物流」，也可能是「要补偿」，两者的应对完全不同。

再往深一层是知识推理与文本分类。实体提取能从一段杂乱文本里拎出人名、地点、事件；逻辑问题解答覆盖数学和常识推理；因果分析判断事件之间的关联性；主题标签生成用于新闻分类这类场景；垃圾内容检测则是在大量文本里筛掉无效信息。这些能力单独看都不算惊艳，但串起来就是一条流水线：先分类，再抽取，再判断，最后打标签。

这里有个容易被忽略的点：理解类任务的准确率，很大程度取决于你有没有给它「判断标准」。让它判断一条评论是正面还是负面，它会给一个模糊的答案；告诉它「带明确推荐语算正面，只描述事实算中性，出现具体故障描述算负面」，它才有一致的尺子。理解任务的提示语，本质是在交付一套判定规则。

2.3 代码与技术文档：为什么它能当半个编程搭子

代码相关的用法可以列得很具体：按需求生成代码片段（Python、JavaScript 这类常见语言都行）、自动补全与注释、错误分析与修复建议、代码性能优化提示、API 文档生成、代码库的解释与示例生成。这些事有个共同特征——对错是可验证的。代码跑不跑得起来，一运行就知道，这让它成为最容易建立信任的一类用法。

举个具体的：让它写一段读取 CSV 并清洗分数列的代码，关键不是它写得多花哨，而是注释和异常兜底有没有到位。

import csv def load_scores(path, key="score"): """读取 CSV 文件，把指定列转成浮点数，空值和非法值统一记为 0.0 参数: path: CSV 文件路径 key: 需要转成数值的列名，默认 score 返回: 由字典组成的列表，每行一个字典 """ rows = [] with open(path, newline="", encoding="utf-8") as f: for row in csv.DictReader(f): try: # 空字符串、None、非数字都会被 float() 拒绝 row[key] = float(row[key]) except (TypeError, ValueError): row[key] = 0.0 # 兜底，避免后续统计报错 rows.append(row) return rows

这段代码的价值不在逻辑复杂，而在于它把「输入是什么、异常怎么处理、返回什么结构」写在了注释里。参数key之所以单独拎出来，是因为真实表格里分数列不一定叫score，硬编码列名是新手最常踩的坑之一。拿到这类代码后，你要做的检查也很固定：先跑一遍边界数据（空值、负数、超长字符串），再看异常分支是不是静默吞掉了错误——except里只写pass的代码，看着干净，出问题时会让你找不到原因。

还有一类用法容易被低估：让它解释别人的代码库。丢一段陌生函数进去，问「这段在干什么、有哪些隐含假设、改哪一行会影响什么」，比自己逐行啃快得多。这类回答不一定全对，但它给出的「阅读路线」通常是对的。

2.4 文件与图片：联网搜索和深度思考模式打开了什么

前面三块都是在「你给的信息」里打转，这一块是把外部信息接进来。DeepSeek 支持联网搜索，也支持深度思考模式，同时支持文件上传，能够扫描读取各类文件及图片中的文字内容。这三件事解决的是三个不同的缺口：联网搜索补「模型不知道的近期信息」，文件上传补「信息在你手里但太长看不完」，图片文字读取补「信息在纸上或截图里，根本没法复制」。

实际用起来，这三者的组合方式比单独使用更有价值。比如一份几十页的合同截图，先靠图片文字读取转成文本，再让它按「付款条件、违约责任、解除条款」三块做摘要，最后对拿不准的条款开联网搜索核对公开的表述惯例。整条链路走下来，比你一页页翻要省力得多。

一个必须提醒的边界：文件读取出来的是文字，不是理解。扫描件里的表格错位、图片里的手写体、跨页断开的句子，都会让提取结果失真。所以凡是要作为依据的数字和条款，都要回到原文件核对一眼。深度思考模式也不是万能开关——它适合那些需要多步推演的问题，对「这句话怎么改得更顺」这种任务，开了反而慢且啰嗦。

3. 为什么会有「推理模型」：慢思考这件事到底解决什么问题

如果用一句话概括这几年大模型的分岔，那就是：有的模型被训练成「张口就来」，有的模型被训练成「先想清楚再说」。前者反应快、覆盖面广，后者慢、但在逻辑链条长的任务上更稳。这个分岔不是厂商为了做卖点硬造的，而是任务本身逼出来的——写一首诗和证明一个定理，需要的根本不是同一种能力。DeepSeek-R1 这类推理模型的存在，恰恰是在回答一个问题：当任务的关键在于「每一步都不能错」时，模型该怎么组织自己的思考过程。

3.1 快思与慢想：概率预测和链式推理的分工

推理大模型指的是在传统大语言模型基础上，强化推理、逻辑分析和决策能力的模型，通常借助强化学习、神经符号推理、元学习等技术来增强推理与问题解决能力。非推理大模型则侧重语言生成、上下文理解和自然语言处理，通过大量文本训练掌握语言规律，能生成合适内容，但不强调深度推理。这两类模型的分野，被人用一个很形象的框架概括过：快思与慢想。

「概率预测」这一路，靠海量数据训练来快速预测可能的答案，响应速度快、算力成本低，决策上依赖预设算法和规则，创造力限于模式识别和优化，人机互动上按预设脚本响应，擅长解决结构化和定义明确的问题，作为受控工具几乎没有额外的伦理争议。通俗地说，它像一个经验极丰富的老师傅，见过足够多的场面，凭手感就能给出一个八九不离十的答案。

「链式推理」这一路走的是另一条路：基于链式思维，逐步推理问题的每个步骤来得到答案。它慢、算力成本高，但能自主分析情况、实时做出决策，能生成新的创意和解决方案，更自然地与人互动、理解复杂情感和意图，能处理多维度和非结构化问题。代价是它带来了自主性和控制方面的讨论——一个会自己往下想的系统，你想拦住它想歪，比拦住一个只会复述的系统难。

注意：这里说的「快」和「慢」不是响应时间的长短，而是思考方式的不同。慢想模型也可能秒回，只是它内部走的步骤更多。

这套划分的实用价值在于：它告诉你什么时候该切换。查一条常识、改一句文案、把一段话翻成英文，快思模型足够；做一道多步数学题、拆解一个业务流程的瓶颈、审一段代码的隐含假设，值得交给慢想模型。

3.2 推理模型与通用模型的对照：强在哪，弱在哪

把两类模型放在同一张表上比，会看得更清楚。这个对比最关键的一句结论是：推理模型并非全面更强，它只在训练目标覆盖的领域显著优于通用模型。

这张表最容易被误读的一行是「劣势领域」。推理模型写不好诗，不是它能力不足，而是它的训练方向把「收敛到一个正确解」当成了目标，而写诗恰恰需要发散。反过来，通用模型做数学证明会跳过关键步骤，也不是它笨，而是它习惯了「给出一个看起来合理的答案」而不是「逐条验证每一步」。

所以选型的正确姿势是看任务类型，而不是看模型热度。数学任务选推理模型，创意任务选通用模型，这是最朴素的判断。真正难的是那些混合任务——比如「写一份带数据分析的市场方案」，它既需要发散创意，又需要严密推算。这类任务的处理办法不是二选一，而是拆开：先让推理模型把数据和逻辑跑通，再让通用模型把结论包装成能读的文字。

3.3 提示语策略为什么必须跟着模型换

模型换了，提问方式也得换，这是最多人忽略的一环。对推理模型，提示语应该更简洁，只需明确任务目标和需求，因为它已经把推理逻辑内化了，无需逐步指导，模型会自动生成结构化的推理过程；如果你强行拆解步骤，反而可能限制它的能力。对通用模型则相反，需要显式引导推理步骤，比如通过链式思维的提示，否则它可能跳过关键逻辑，所以它依赖提示语来补偿能力短板，比如要求分步思考、提供示例。

一句话概括这条原则：推理模型「要什么直接说」，通用模型「缺什么补什么」。

与之配套的还有三条避免误区的提醒。第一，不要对推理模型使用「启发式」提示，比如角色扮演，这可能干扰它的逻辑主线——你让它「扮演一位数学家」，它可能真的开始表演，而不是解题。第二，不要对通用模型「过度信任」，直接问它复杂推理问题，得到的答案需要分步验证。第三，不要因为某个模型最近热度高就所有任务都用它，模型选择应该优先看任务类型。

举个具体的对照。同样是写快速排序，对推理模型说「用 Python 实现快速排序，带注释」，它自己会处理边界条件和递归结构；对通用模型，你得说「先解释快速排序的分区思路，再写出实现，注明基准值怎么选、空数组怎么处理」。同一个需求，两种问法，得到的完成度差别很大。这不是模型水平问题，是配合方式问题。

4. 常见误区：这几个概念一混，提示语就白写了

4.1 误区一：模型越新越强，什么任务都往上堆

易混点：把「推理能力更强」直接等同于「所有任务都更好」。为什么容易混？因为推理模型在最能展示实力的场景（数学、代码、逻辑题）上表现确实突出，很容易让人产生「全面升级」的错觉。怎么区分：回到训练目标。推理模型专精逻辑密度高的任务，在发散性任务上反而受限；通用模型擅长多样性高的任务，在严格逻辑链任务上需要提示语补偿。判断标准不是「哪个更强」，而是「这个任务要的是收敛还是发散」。写诗、起标题、想 slogan，要的是发散，硬上推理模型往往得到工整但无趣的结果。

4.2 误区二：把「提示语长」当成「提示语好」

易混点：以为信息给得越多，模型就越懂。为什么容易混？因为确实存在「说清楚背景后效果好很多」的经验，于是有人把这条经验无限外推，把提示语写成千字长文，塞进五六个互相冲突的要求。怎么区分：看提示语里有没有「不可执行的约束」。比如同时要求「专业严谨」和「轻松活泼」，同时要求「简短」和「覆盖十个要点」，模型只能随机满足其中一部分。好的提示语不是长，而是每条要求都能被检验——长度、语气、必须包含的信息、必须避免的内容，一条一条能对上号。

4.3 误区三：对推理模型也做角色扮演和分步拆解

易混点：把所有模型都当成需要手把手教的通用模型。为什么容易混？因为角色扮演和分步引导在通用模型上确实管用，形成习惯后就会无差别套用。怎么区分：推理模型已内化推理逻辑，提示语更简洁即可，只需明确任务目标和需求；强行拆解步骤反而可能限制它的能力，启发式提示（如角色扮演）还可能干扰它的逻辑主线。判断的简单办法：如果这个任务的核心是「每一步都不能错」，就少给表演性指令，多给目标和约束；如果核心是「要有味道、有风格」，角色设定才有价值。

4.4 误区四：把「深度思考」当成万能开关

易混点：以为开了深度思考模式，答案就一定更准。为什么容易混？因为名字听起来像是「加强版」。怎么区分：慢想适合多步推演、需要权衡和验证的任务，对快速反馈类任务反而拖慢节奏，还可能把一个简单问题过度复杂化。判断标准很土但有效：这个问题的答案，是我自己坐下来想十分钟能想明白的，还是必须一步步推的？前者不需要开，后者值得开。

4.5 误区五：把「AI 给的答案」当成「验证过的结论」

易混点：混淆「生成」和「核实」两件事。为什么容易混？因为输出格式太像成品——有结构、有术语、有结论，看起来就该是对的。怎么区分：把每个输出分成「可核对的事实」和「组织方式」两部分。组织方式（结构、措辞、分类框架）通常可以直接用；事实部分（数字、条款、引用、结论）必须回到原始材料核。凡是模型自己推算出来的中间步骤，尤其要检查——链路越长，中间某一步悄悄跑偏的概率越高。

5. 怎么把需求说清楚：五种需求类型和它们的表达公式

提问这件事，往浅了说是措辞问题，往深了说是表达能力问题。很多人以为自己在「下指令」，其实是在「许愿」：说了想要什么，没说约束是什么、判断标准是什么、输出给谁看。从「下达指令」转向「表达需求」，是使用水平拉开差距的地方。这一步跨过去，模型输出的稳定性会有明显变化，因为它终于知道你到底要什么了。

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

三种下笔方式，对应三种任务成熟度。

指令驱动是直接给出明确步骤或格式要求，适合简单任务、需要快速执行的场景，优势是结果精准高效，风险是限制了模型的自主优化空间。比如「用 Python 编写快速排序函数，输出需包含注释」，这就是典型的指令驱动——步骤和形态都定死了。

需求导向是描述问题背景与目标，由模型规划解决路径，适合复杂问题、需要模型自主推理的场景，优势是能激发深层推理，风险是需要你清晰定义需求边界。「我需要优化用户登录流程，请分析当前瓶颈并提出三种方案」，这就是需求导向，你把问题交出去，路径由它想。

混合模式结合需求描述与关键约束条件，兼顾灵活性与可控性，适合需要平衡目标与细节的任务，风险是容易过度约束。「设计一个三日游计划，要求包含某两个景点，且预算控制在两千元内」，目标和约束都在，路径留白。

选择哪种，取决于你对答案形态的确定程度。你已经知道要什么样子，用指令驱动；你只知道问题在哪，用需求导向；两者都有，用混合模式。

5.2 五类需求：决策、分析、创造、验证、执行

需求其实可以归成五类，每类有一个好用的表达公式，也各有对应的模型适配策略。

五类里最容易被做砸的是验证需求。多数人验证一个结论，只问「这个对吗」，得到的回答通常是「基本正确」。换成公式化的问法：「以下是一段结论：某神经网络模型优于传统方法。请验证：一、实验数据是否支持该结论；二、对照组设置是否存在偏差；三、重新计算显著性并判断。」三个问题都是可执行的检查动作，输出才有含金量。

创造性需求的坑在另一头：完全放开让它自由创作，得到的东西往往平庸。加上风格和约束反而更好——「写一个包含两个指定意象的短篇小说，不超过两百字」，限制本身就是创造力的边界条件。

5.3 提示语的三段结构：指令、上下文、期望

再往底层走，一条完整提示语通常由三部分构成。指令是核心，明确告诉模型要执行什么任务；上下文提供背景信息，帮助它更准确地理解和执行；期望则明确或隐含地表达你对输出的要求和预期。三者缺一块，输出就会在对应维度上打折：缺指令，它不知道干什么；缺上下文，它只能给通用答案；缺期望，它不知道什么算「好」。

从功能上看，提示语扮演着几种角色：它是连接人类意图和模型理解的沟通桥梁，是提供必要背景的上下文提供者，是明确任务的任务定义器，是影响输出形式与内容的输出塑造器，也是引导模型调用特定能力的引导器。理解这几重身份，比背提示语模板有用得多。

注意：三段结构不是必须写满三段。简单任务里，上下文和期望可以压缩成半句话，但心里要清楚自己压缩掉了什么。

6. 什么时候该用它、什么时候别用：几条边界判断

把前面几章的东西落到一个具体判断上：你手上有个活儿，该不该交给它、该怎么交。我的经验是先问三个问题——这件事的对错能不能被快速验证？它需要的是收敛还是发散？我手上有多少可用的原始材料？三个问题答完，边界基本就出来了。

能快速验证的活儿，放心交出去，比如代码片段、格式转换、结构整理、初稿撰写。这些即使出问题，你也能在几分钟内发现。需要收敛的活儿，优先给推理模型，比如多步计算、逻辑排查、方案取舍；需要发散的活儿，优先给通用模型，比如起名、写故事、想创意方向。原始材料越多，越要先把材料喂进去再说需求——只凭一句模糊描述问「帮我分析一下」，得到的必然是泛泛而谈。

反过来，有几种情况我会主动收手。第一，结论会被直接拿去当依据、而我没有原始材料核对的，不用；它的作用是加速我的判断，不是替代我的判断。第二，涉及需要专业资质才能下结论的领域，不用它给结论，只用它整理信息和列出需要确认的问题。第三，任务本身要求「每一句话都可追溯来源」的，我会把它降级成辅助工具，因为它的输出不天然带出处。第四，纯粹为了省事而把整个流程一次性丢进去的，我会拆开——链条越长，中间某一步悄悄跑偏的概率越高，而你不知道是哪一步。

有一个具体的例子可以说明拆分的价值。某次要做一份数据清洗脚本，我最初的写法是把需求和示例数据一起丢进去，说「帮我写个清洗脚本」。结果它给的代码能跑，但把两列含义不同的空值当成同一种处理，跑完统计结果全偏了。后来我改成三步走：第一步只描述字段含义和每类异常的处置策略，让它输出规则表；第二步确认规则表没问题，再让它按表写代码；第三步拿十行边界数据回归测试。多花了十几分钟，但后面没再返工。同一件事，一次性丢进去是省事，拆开丢进去是省心。

从那以后，我每次把稍有分量的任务交给它之前，都强制走一遍「先给规则、再要产出、最后拿边界数据验一遍」的流程。这个习惯听起来笨，但它把「AI 玄学」变成了可重复的工序——不是靠运气碰到好答案，而是靠流程逼出稳定答案。这份资料把能力地图、模型选型、需求表达和提示语结构整理成了一条完整的进阶路线，从「会用」到「用得好」中间那些说不清的坎，基本都能在里面找到对应的判断依据，需要的话可以取来对照着自己走一遍。希望帮到你。

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