简介：这份PDF讲义源自北京大学DeepSeek原理与应用系列研讨，面向不具备专业AI或IT背景的初学者、教育工作者及希望厘清AIGC概念的从业者，重点回应网络内容多停留在工具操作、易造成概念与思维方式误导的问题。讲义共1个PDF文件，约16.61MB，已有210人学习。内容从DeepSeek-R1的技术特性、优势与历史地位切入，对比生成模型与推理模型的定位、能力边界和典型场景，并梳理DeepSeek公司背景、产品系列及低成本开源策略对行业的影响；随后深入大模型与AIGC的底层工作机制，讲解AIGC发展历程、能力构成与工具选择方法，帮助读者突破“只会用工具”的局限。目录涵盖详解DeepSeek-R1、AIGC概念和应用、能力揭秘、选择AIGC工具等模块，并给出科学选择与高效使用AI工具的指导，适合作为系统入门与教学参考。

1. 一份“不需要 AI 背景”的研讨讲义，实际能应用到什么程度

上个月有人把一份六十多页的内部研讨讲义发给我，问这东西除了当 PPT 从头念到尾，还能干什么。讲义主题是 DeepSeek 与 AIGC 应用，来自某高校人工智能研究团队，分四块：DeepSeek-R1 详解、AIGC 概念与应用、能力揭秘、工具选择。它最有价值的地方在于把“生成模型和推理模型压根不是一类东西”这件事，用一张五维对照表固定下来，而非又吹了一遍 DeepSeek 多强。很多人用 AI 翻车，根源就是把推理模型当生成模型使，或者反过来，然后怪模型不行。这份材料的定位很清楚：不需要 AI 或 IT 背景也能读懂，但读完你得能自己判断“这个任务该派谁上”。适合谁？要给团队做 AI 内训的技术负责人、刚接触 AIGC 想建立正确概念的开发者、被各种工具榜单搞晕的产品同学。下面按我拆解这份材料的顺序来讲。

2. 生成模型与推理模型：先把选型骨架立住

这一部分对应讲义的第一块。绝大多数人拿到这类材料，会直接从“DeepSeek-R1 有多强”开始读，然后记住几个跑分，回去发现用不上。我的建议是反过来：先把术语分层理清，再拿对照表建立判断力，最后才去看性能数字。因为跑分会过期，判断框架不会。

2.1 三层术语：多模态、通用模型、行业模型

讲义开篇花了不少篇幅做术语铺垫，很多人会快速翻过去，其实这三层是整个选型的地基。第一层是模态，文本、图片、音频、视频；第二层是模型类型，通用的大语言模型、视频模型、多模态模型，以及垂直的教育、医疗、金融行业模型；第三层才是具体工具，也就是你在网页上点开就能用的那些对话产品和搜索产品。三层混在一起谈，就会出现“某工具支持传图片，所以它能做图纸审阅”这种典型误判。

这里有个最常见的混淆点必须点破：支持图片输入 ≠ 具备多模态理解能力。前者是接口层面的事，后者要看模型在图表、公式、版式上的实际表现。我一般会让对方拿三张自家业务里的真实截图去测，一张带密集表格、一张带手写批注、一张带低对比度小字，能把这三张读对的才算过关，宣传页上写什么不算。

行业模型那层也容易被神化。垂直模型的价值主要来自训练数据分布和评测集，不是名字里带个行业词就自动变强。判断方法很土但有效：看它在你的业务指标上有没有可复现的对比数据，没有就按通用模型处理，别为“行业”两个字付溢价。

提示：把这三层写成一张自己的清单，每引入一个新工具就往上填一行，比收藏一堆测评文章管用得多。

2.2 五维对照：一张表决定谁上

讲义里最值得抄下来的，是生成模型与推理模型的五维对照。我按原文数据整理成下面这张表，维度做了微调，方便直接拿去开会用。

讲义里给的一组公开测评数字值得记一下：推理模型在数学类基准上能到 90.7 分，阅读理解类 F1 到 92.2%，竞赛级数学通过率 79.8%，代码生成通过率 65.2%；对应的生成模型在数学基准上是另一档，代码通过率 65.2% 那一档则由生成模型占据。数字本身会变，但两类的相对位置短期内不会反转：推理模型赢在需要多步推演的题，生成模型赢在需要广度、速度和多模态的活。

真正的判断不在表格里，而在你的任务描述里。我一般用四个问题做快速分流：这个任务能不能拆成有先后依赖的步骤？答案能不能用规则或测试用例验证？单次调用的时间预算是不是超过十秒还能接受？输出需不需要给人看推导过程？前两个是“是”，优先推理模型；后三个都是“否”，老老实实用生成模型。四个问题里只要出现“要快、要便宜、要能看图”中的任意一个，就不该选推理模型。

2.3 能力边界：推理模型什么时候会帮倒忙

讲义很实在地列了推理模型的两面。优势那栏是演绎归纳能力强、链式思维出色、擅长复杂决策、能呈现思考过程；劣势那栏更值得贴在显示器上：响应慢且成本高、基于知识的任务更容易出错、处理简单任务效率低容易过度思考。

第三条“过度思考”是最容易被忽略的成本项。我见过一个场景，让推理模型把一段两百字的会议纪要改写成三条待办，它输出了一千多字的分析，最后待办还是错的。这不是模型坏了，是任务错配——改写属于生成类任务，推理链路在这里纯属浪费。判断标准很简单：如果人来做这件事不需要打草稿，就别让推理模型打草稿。

第二条“基于知识的任务更容易出错”也是血泪经验。推理模型的强项是推理链，不是事实库。问它“某标准里第几条怎么规定的”，它可能会用非常漂亮的逻辑推演出一个不存在的规定。这类问题应该走检索增强，先拿到原文片段，再让模型基于片段做推理，而不是让它凭记忆推。

还有人会问，既然推理模型能呈现思考过程，是不是可以拿思考过程当解释给客户看。我的建议是别直接给。链式思考是模型的工作草稿，里面有试错、有回头、有自我否定，非技术读者看了只会更困惑。要给人看的是结论加关键依据，思考过程留给自己排查用。

3. AIGC 的底层机制：把“会用工具”抬成“会判断工具”

第二块内容是 AIGC 的概念与能力揭秘。这部分是整份材料里最“不实用”却也最能救人的一节——不理解机制，你只能在工具层面反复试错，出了问题也不知道往哪个方向调。

3.1 从 token 预测到思维链：三层机制拆开看

第一层是自回归的 token 预测。模型每次输出一个 token，把它接回输入，再预测下一个。这决定了两个基本事实：输出长度直接等于成本，且生成过程没有全局规划，只有局部最优。很多人抱怨模型“前面说得挺好后面跑偏了”，本质是它在生成后半段时，前半段已经变成了不可修改的既成事实。

第二层是思维链，也就是讲义里说的“让模型进行慢思考”。它的作用是把原本隐式的推理过程外化成可观察的中间 token。工程上的意义在于：中间步骤一旦被写出来，就变成了后续推理的上下文，模型可以在上面自我检查、回头修正。所以思维链不是“让模型更聪明”，而是“让模型有地方打草稿”。这也解释了为什么思维链对小任务反而有害——草稿纸比答案还长，纯亏。

第三层是强化学习与蒸馏。强化学习解决的是“怎么让模型自己探索出好的推理路径”，核心在于有没有可验证的奖励信号。数学题能对答案、代码能跑测试，这类任务天然适合；开放式写作没有客观奖励，就很难用同一套方法优化。蒸馏解决的是“怎么把大模型的能力压缩到小模型”，代价是天花板受教师模型限制，且蒸馏出来的模型在面对分布外问题时更容易崩。

提示：这三层不需要背，但要能回答一个问题——你手上的任务，属于“有明确对错”还是“只有好坏之分”？前者是推理模型的舒适区，后者老老实实用生成模型加人工筛选。

3.2 三个关键词落到工程上是什么

把思维链、强化学习、蒸馏这三个词翻译成日常判断，大概是这样的：看到某个模型宣称“推理能力强”，先问它的训练任务里有多少是可自动验证的；看到“小模型效果接近大模型”，先问它是蒸馏来的还是从头训的，蒸馏来的要看它在你的业务分布上还剩下多少能力；看到“展示思考过程”，先确认这个过程的长度是否可控，因为不可控的思考长度等于不可控的成本。

我自己踩过的一个坑是把蒸馏模型当主力用在一个边界很模糊的任务上——输入是用户随手写的一段投诉。头两周效果还行，第三周开始出现大量“分析得很认真但结论跑偏”的案例。后来换成完整版推理模型加更严格的输出约束才稳住。蒸馏模型不是不能用，是不能用在输入分布不受控的地方。

3.3 一次可复现的对照实验

光看对照表不够，最好自己跑一遍。下面这段代码做的事很简单：同一道多步推理题，分别打给生成模型和推理模型，记录耗时、思考内容长度和答案长度。跑十次，你对两类模型的差异会有一手体感。

import os, time from openai import OpenAI # 接口地址和密钥从环境变量读，避免写死在代码里 client = OpenAI( api_key=os.environ["DS_API_KEY"], base_url=os.environ["DS_BASE_URL"], ) PROMPT = ( "某仓库周一入库120箱，周二出库总数的三分之一，周三入库80箱，" "周四出库剩余的一半，周五盘点时剩150箱。问周一之前仓库原有多少箱？" "请给出计算过程。" ) def run(model: str, prompt: str, temperature: float = 0.6) -> dict: t0 = time.time() resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=temperature, # 对照实验里两类模型必须用同一个值 max_tokens=2048, ) elapsed = time.time() - t0 msg = resp.choices[0].message # 推理模型通常把思考过程单独放在 reasoning_content 字段 reasoning = getattr(msg, "reasoning_content", None) or "" return { "model": model, "latency_s": round(elapsed, 2), "think_chars": len(reasoning), "answer_chars": len(msg.content or ""), "answer": (msg.content or "").strip().replace("\n", " ")[:60], } for m in ["deepseek-chat", "deepseek-reasoner"]: for _ in range(3): # 每类跑三次，看波动 print(run(m, PROMPT))

逻辑说明：外层循环切换模型，内层循环重复三次观察稳定性；run里只做三件事——计时、取回消息体、把思考字段和答案字段分开统计。参数上temperature固定在 0.6，如果两类模型用不同温度，测出来的差异就混入了采样随机性，结论不可信；max_tokens给到 2048 是为了让推理模型有足够空间写完思考链，设小了会被截断，你会误以为它答不出来。

跑完你会看到几个典型现象：推理模型的latency_s通常是生成模型的两到五倍，think_chars可能上千而answer_chars只有几十；生成模型反过来，答案来得快，但在这种多步题上正确率明显更低，且三次之间波动更大。这三个数字就是你跟业务方沟通成本时的依据——不是“推理模型更贵”，而是“这道题上它要多花三倍时间写草稿”。

4. 科学选择 AIGC 工具：四步流程和一张决策表

第三、四块内容讲的是能力揭秘与工具选择，讲义里那句“当前网络内容多停留在工具应用层面，容易误导初级使用者”说得比较客气，实际情况是：大部分人选工具的方式是看榜单和热度，然后在第一个真实任务上翻车。

4.1 选型前先算清四个约束

我一般把选型约束压成四条，按顺序过一遍，过不了就直接排除，不进入比价环节。

第三条要特别算清楚。很多人做预算只算 token 单价，忘了推理模型的输出 token 里有很大一部分是思考内容。同样一个问题，生成模型可能消耗 200 个输出 token，推理模型轻松上千。按调用量放大之后，差距不是百分比，是量级。

4.2 决策表：任务类型直接映射到模型类型

这张表不能替你决策，但能挡住八成明显错配。用的时候从左边找最接近的任务类型，再看“常见误用”那列自己有没有中招。

4.3 四步选型流程

第一步，拆任务。把一个笼统需求拆成若干子任务，每个子任务单独判断类型。比如“做一个合同审核助手”，实际包含条款抽取、风险条款比对、修改建议生成三个子任务，前两个可以走推理模型，第三个更适合生成模型。

第二步，定类型。拿子任务去对上面那张决策表，注意一个子任务只能落一个类型，落不进去说明拆得还不够细。

第三步，定形态。同一类模型有网页端、API、私有化部署三种接入形态，差别不在能力而在边界，下一节展开。

第四步，小样本回测。从真实业务数据里抽三十到五十条，人工标注期望输出，跑一遍算通过率。这一步最容易被跳过，也最不该跳过——榜单分数和你业务上的通过率之间，通常没有稳定关系。

提示：回测样本一定要包含“脏数据”，比如错别字、表格串行、多语言混排。干净样本上的通过率没有参考价值。

4.4 三种接入形态的边界

实际项目里通常是混合的：敏感数据走私有化，非敏感的高频任务走 API，探索性需求先用网页端验证可行性。我见过有团队一上来就全套私有化，结果模型版本落后半年，效果比网页端差一截，白折腾。

5. 避坑与排查：五条真实翻车记录

5.1 把推理模型当生成模型用，输出又长又飘

现象：让它写一段产品介绍，输出三倍长度，中间还夹杂大段自我质疑，最后一段推翻了第一段的说法。

原因：任务本身没有推理需求，模型却被强制进入慢思考模式，思考链里没有可验证的中间结论，只能在语义空间里反复打转。

解决：按任务类型分流，改写、摘要、翻译类一律走生成模型；如果必须用推理模型，在提示词里明确“直接给最终结果，不需要分析过程”，并把输出长度上限压到合理值。

5.2 拿推理模型做知识问答，幻觉反而更多

现象：问某个内部规范的条款细节，生成模型会说“资料不足”，推理模型却能给出一段逻辑严密、细节完整的错误答案。

原因：推理模型擅长在给定前提下推演，但前提本身是错的或缺失时，它会用推理能力把缺口补圆，看起来比“我不知道”可信得多。

解决：知识类问题一律先检索后生成，把原文片段作为上下文喂进去，并要求“只依据给定片段作答，片段中没有的内容直接说明未提及”。这条规则写进系统提示词，不要靠临时嘱咐。

5.3 提示词里堆“请一步步思考”，把小任务拖成大任务

现象：一个简单的字段分类任务，加了“请一步步思考”之后，准确率没涨，延迟涨了三倍。

原因：思维链提示对需要多步推导的任务有效，对单步判断类任务只是增加了输出长度，稀释了关键信息。

解决：把“一步步思考”从通用模板里删掉，只在高复杂度任务上按需开启。判断标准还是那句：人做这件事需不需要打草稿。

5.4 跟着热榜选工具，第二周就发现场景不匹配

现象：某工具在测评里排第一，接进业务两周后发现它在长文本结构化抽取上频繁丢字段。

原因：榜单测的是通用能力，你的业务测的是特定分布的稳定性，两者不是一回事。

解决：任何工具进场前跑一遍自己的三十条回测样本，通过率不达标就不进生产。回测集要版本化管理，每次换模型都重跑，别凭印象。

5.5 把讲义里的基准分数当成自家场景的预期

现象：看到代码通过率 65.2% 这类数字，就认为自家代码任务也能到这个水平，实际跑出来不到一半。

原因：基准任务的题目分布、判分方式、提示词模板都是标准化的，业务场景的输入更脏、要求更细、判分更严。

解决：基准分数只用来做相对比较，不用来做绝对预期。对外沟通时给区间不给点值，比如“这类任务目前通过率大概在四到六成，需要人工复核兜底”。

6. 进阶用法：把一份讲义变成可复用的判断力

这份材料真正的用法，不是从头读到尾，而是拆成四块分别落地。第一块 DeepSeek-R1 详解，抽出来做成一页“模型能力卡”，写清它擅长什么、不擅长什么、成本量级，贴在团队文档首页。第二块 AIGC 概念，用来统一团队语言，避免有人把“支持图片上传”说成“多模态能力”。第三块能力揭秘，做成排查手册：出现幻觉先查检索，出现冗长先查任务错配，出现不稳定先查温度。第四块工具选择，做成上面那张决策表，每季度更新一次。

我自己还会加一道工序：把讲义里的每个结论，翻译成一条可执行的检查项。下面这张表是我常用的版本，换项目时改中间一列就行。

还有一个我反复验证过的技巧：给推理模型的提示词里，把“输出格式”和“推理要求”分开写。前半段说清楚要什么结构、多长、给谁看，后半段才说需要哪些中间校验。混在一起写，模型经常把格式要求也当成推理对象，在思考链里反复纠结“到底该用几号字体”，纯属浪费。

最后说个教训。早些年我做模型选型，习惯先看参数和榜单，选完再想怎么用，结果有两次都是上线后才发现任务类型压根不匹配，回头改架构的成本是当初省下的选择时间的几十倍。从那以后我每次引入一个新模型，都强制先走一遍“拆任务—定类型—小样本回测”这三步，哪怕只是内部试用，也把回测记录留档。这习惯救过我不少次，也让我少说了很多“这个模型不行”的错话——大多数时候不是模型不行，是派错了活。希望帮到你。

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