简介《DeepSeek从入门到精通》是清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的103页PDF教程面向希望系统掌握国产大模型的学生、内容创作者与开发者帮助读者从「会用」走向「用得好」。全包仅含1个PDF文件约5.01MB轻量易读适合碎片时间翻阅。教程以「是什么、能做什么、怎么用」为主线先梳理DeepSeek-R1开源推理模型的能力边界与免费商用特点再逐层展开文本创作、摘要改写、多语言翻译、语义与情感分析、代码生成与调试等应用场景最后落到推理模型与通用模型的差异对比——快思与慢想、概率预测与链式推理在性能、决策与创造力上的取舍并给出指令驱动、需求导向、混合模式与启发式提问等提示语策略以及数学证明、创意写作、代码生成等不同任务下可直接参照的示例与需规避的写法。目前已有363人学习。1. 103 页讲义别急着通读值钱的是模型分类和提示语策略拿到这份 103 页的 DeepSeek 讲义多数人的第一反应是从第一页翻到最后一页翻完记住一句“国产、免费、开源、强大”然后该怎么写提示语还是怎么写。这份材料的实际结构是前半部分讲 DeepSeek-R1 这类推理模型和通用模型的能力边界中间讲提示语的结构与策略后半部分是文本生成、语义理解、代码生成这些场景的拆解。真正能改变你日常使用效果的是前两部分场景清单只是告诉你“能干什么”不解决“怎么干得好”。它适合日常用 AI 写材料、做竞品分析、写脚本的从业者也适合带团队做内部 AI 使用规范的人不适合想找 API 参数手册、私有化部署方案、微调流程的读者那些内容这份讲义里没有。下面按“先选对模型再写对提示语最后沉淀成自己的库”这条线拆。2. 推理模型与通用模型怎么分选错模型提示语写得再漂亮也无法补救2.1 两类模型的能力边界先看训练目标再看榜单讲义里把模型分成两类这个划分比“哪个更强”有用得多。推理模型在传统大语言模型的基础上强化了推理、逻辑分析和决策能力常见的技术手段是强化学习、神经符号推理、元学习这一类代表就是 DeepSeek-R1它在数学推导、逻辑分析、代码生成、复杂问题拆解上表现突出因为训练目标本身就是往“逻辑密度高”的方向压。通用模型走的是另一条路通过对大量文本数据的训练掌握语言规律侧重语言生成、上下文理解、自然语言处理文本生成、创意写作、多轮对话、开放性问答是它的主场。这里有个反直觉的结论讲义写得很直白推理模型并不是全面更强它只在训练目标覆盖的领域显著优于通用模型。你让它写一首有意象的诗、编一段带情绪转折的对话它反而容易给出结构工整但没有灵气的东西通用模型碰到需要严格逻辑链的数学证明则会跳步、会“看起来推了其实没推”。我一般把这条当成分流线任务里能不能画出一条可验证的推理链能就用推理模型不能就老老实实用通用模型。再往下拆一层讲义用了“快思慢想”这个框架。概率预测类模型靠大量数据训练快速预测答案响应快、算力成本低决策依赖预设算法和规则创造力限于模式识别和优化链式推理类模型基于 Chain-of-Thought 逐步推演每个步骤慢、贵但能自主分析情况、实时调整决策路径也更容易产出新的解决思路。这两类不是替代关系是同一条流水线上的两道工序先用快模型把问题收敛成结构化描述再用慢模型啃里面真正难的那一段。维度推理模型通用模型优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作需要严格逻辑链的任务如数学证明性能本质专精于逻辑密度高的任务擅长多样性高的任务成本特征慢速思考算力成本高快速反应算力成本低典型误用用角色扮演、分步拆解去“帮”它直接抛复杂推理题不做分步验证2.2 快思慢想的成本账什么时候值得为一段推理多等十几秒很多人排斥慢模型理由就一个字慢。但成本要按“返工次数”算不是按“单次响应时间”算。写营销文案快模型三秒出五条你挑一条改改就能用慢模型等半分钟出来一条四平八稳的反而是浪费。反过来算一个带边界条件的排产方案、审一段有并发问题的代码快模型给你一版看着通顺、跑起来就崩的结果你回头排查的时间早就把省下的十几秒吃回去了。讲义里列了一组对照处理多维度和非结构化问题、提供创造性解决方案慢模型更强解决结构化和定义明确的问题快模型更擅长。我看这组对照的实际用法是——先判断你的输入是“结构化的”还是“非结构化的”。需求文档写得清清楚楚、字段定义齐全、只要按规则算那是结构化快模型足够需求是一段会议记录、一份没有格式的调研纪要、一堆散落的用户反馈那属于非结构化得让慢模型先把结构抽出来。还有一个容易被忽略的点伦理与控制。讲义提到快模型作为受控工具几乎不涉及自主性问题慢模型因为会自己规划推理路径会引出“它为什么这么判断”的可解释性追问。落到工程上就是——凡是结果要签字、要对外、要担责的场景慢模型的推理过程本身就是交付物的一部分你得能把它贴进报告里凡是内部草稿、批量生成、二次筛选的场景快模型的过程不重要结果对不对抽样验一下就行。2.3 一张选型决策表把“凭感觉选”变成“按任务选”讲义给的关键原则第一条是优先根据任务类型而非模型热度选择。这句话看着像废话实际踩坑最多。新模型一发布所有人都拿它去写周报结果发现还不如旧的顺手然后得出结论“新模型不行”。问题不在模型在任务和模型不匹配。我把讲义里的任务类型整理成一张可以直接贴在工位上的表任务类型建议模型提示语侧重点要避免的写法数学证明、公式推导推理模型直接提问无需分步引导冗余拆解如“先画图再列公式”创意写作、故事、文案推理模型发散或通用模型约束设定角色与风格给明确约束过度约束逻辑顺序如“按时间线罗列”代码生成推理模型给清输入输出与运行环境手把手教它先写递归函数代码解释、文档撰写通用模型给上下文和目标读者开放式指令如“随便解释一下”多轮对话、需求澄清通用模型自然交互不做结构化强制强制“分三点回答”逻辑分析、方案对比推理模型直接抛复杂问题要求给判断依据加主观引导如“你觉得哪个对”用法很简单拿到任务先在左列找一行找不到就说明你还没想清楚任务类型这时候写什么提示语都是玄学。找到之后按第三列写第四列的写法看到就删。这张表我贴在显示器边上用了很久最大的价值不是让我选对模型而是让我在任务描述不清的时候立刻意识到——该回去补需求而不是换模型重试。3. 两套提示语写法推理模型说需求通用模型补步骤3.1 提示语的三段结构指令、上下文、期望讲义把提示语拆成三个组成部分。指令是核心明确告诉模型要执行什么任务上下文提供背景信息帮它更准确地理解和执行期望则明确或隐含地表达你对输出的要求和预期。这三段不是必须写满但缺哪一段输出就会在哪个维度上失控——缺指令模型自由发挥缺上下文模型按通用常识猜缺期望输出长度、格式、语气全靠运气。再往深一层讲义给了提示语的五个本质特征我觉得这段是整份材料里最容易被跳过、但最该记住的沟通桥梁连接人类意图和模型理解上下文提供者为模型补充必要背景任务定义器明确指定要完成的任务输出塑造器影响输出的形式和内容能力引导器引导模型调用特定的能力或技巧。这五个角色对应五个自检问题我的意图说清楚了吗背景给够了吗任务边界在哪输出长什么样我要它用哪种能力举个具体的。写“帮我写个引言”五个问题一个都没答。改成“为一篇关于气候变化的科普文章写一个引言读者是高中生长度 200 字不要用数据堆砌”指令写引言、上下文气候变化科普、高中生读者、期望200 字、不用数据齐了能力引导科普表达能力也隐含在里面。差别不在字数在于后者能一次过。3.2 推理模型的写法要什么直接说别帮它拆步骤讲义里对推理模型的提示语策略只有一句话但分量很重提示语更简洁只需明确任务目标和需求因为它已经内化了推理逻辑。后面跟了一句更关键的——无需逐步指导模型会自动生成结构化推理过程若强行拆解步骤反而可能限制它的能力。这个坑我踩过。当时让它推导一个带约束条件的优化问题我怕它跳步特意写了“第一步先列出目标函数第二步求偏导第三步验证边界条件”。结果它老老实实按我给的三步走走到第三步发现边界条件和我预设的不一致但它没有回头改第一步的建模而是硬着头皮在错误建模上继续推最后给了一个自洽但错误的结果。后来去掉那三段引导只说“求该约束优化问题的最优解说明建模假设和边界条件的处理”它自己回头改了两次建模结果对了。讲义把这种现象归到“避免误区”里不要对推理模型使用启发式提示比如角色扮演可能干扰它的逻辑主线。同理不要给它“你是一位资深数学家”这种开场它不需要身份加持需要的是问题本身描述准确。真正该给的是三样东西问题是什么、约束条件有哪些、输出要什么形式。剩下的推理路径交给它。3.3 通用模型的写法缺什么补什么把步骤显式写出来通用模型是反过来的。讲义的原话是需显式引导推理步骤如通过 CoT 提示否则可能跳过关键逻辑依赖提示语补偿能力短板比如要求分步思考、提供示例。这里的关键词是“补偿”——你缺的不是模型的智力是它没有为这类任务专门训练过所以你得用提示语把推理路径铺出来。讲义给了一个很实用的对照。数学证明类任务对通用模型要写成“请分三步推导勾股定理参考1. 画直角三角形…”对推理模型则只需要“证明勾股定理”。代码生成类任务对通用模型要“先解释快速排序原理再写出代码并测试示例”对推理模型只要“用 Python 实现快速排序”。同一个任务两种写法差的不是水平是路径。我一般的做法是给通用模型配一个“三段式骨架”先让它复述对任务的理解防止跑偏再让它按我列出的维度逐条分析防止跳步最后要求它给出自检结论哪里不确定、哪里依赖假设。第三段特别有用它会把“我不确定”的部分标出来你顺着这些标记去验证比整体重算一遍省事得多。3.4 把提示语沉淀成模板一个小脚本管住版本改提示语最痛苦的是改完发现还不如上一版而上一版已经被覆盖了。我的习惯是用一个 JSON 文件存模板用脚本渲染改坏了直接回滚。# prompt_lib.py # 用途把聊天记录里试出来的提示语沉淀成可版本管理的模板 import json from pathlib import Path LIB Path(prompts.json) REQUIRED (id, task_type, model_type, template) def load_lib(): return json.loads(LIB.read_text(encodingutf-8)) def validate(items): # 缺字段的模板直接拒收别等到渲染时才炸 for it in items: miss [k for k in REQUIRED if not it.get(k)] if miss: raise ValueError(f模板 {it.get(id, 无id)} 缺少字段: {miss}) return items def render(item, **kwargs): # 参数没给全就报错避免 {problem} 被模型原样复述回来 try: return item[template].format(**kwargs) except KeyError as e: raise KeyError(f模板 {item[id]} 缺少参数: {e}) from e配一个最小的prompts.json[ { id: math-001, task_type: 数学推导, model_type: reasoning, template: 求解{problem}\n约束条件{constraints}\n输出要求给出建模假设、关键推导步骤与最终结论。 }, { id: code-002, task_type: 代码生成, model_type: reasoning, template: 用 {lang} 实现 {feature}。运行环境 {env}输入 {input_fmt}输出 {output_fmt}不要引入第三方依赖。 } ]逻辑说明task_type和model_type两个字段是关键它们强制你在写模板的时候就想清楚“这个模板是给哪类模型、哪类任务用的”避免把给通用模型的分步引导套到推理模型上。validate在加载时做一次全量校验防止手改 JSON 时漏字段。render用format做占位符替换缺参数直接抛异常——这一点比“让模型自己猜”重要得多占位符没替换掉模型会把它当成待解释的符号原样写回来你拿到输出还得回头排查。参数说明prompt.json里所有占位符必须和调用方的kwargs对齐建议在模板里用有语义的英文名problem、constraints、env不要用a、b。模板 id 命名带任务前缀加序号回滚时按 id 找历史版本比在聊天记录里翻要快得多。4. 五类需求表达公式把“我想要”翻译成模型能理解的指令4.1 需求类型对照表先分类再动笔讲义把向 AI 表达需求分成五类每类给了一个公式。这段是我认为整份材料里最可直接抄作业的部分需求类型特点表达公式推理模型适配通用模型适配决策需求需权衡选项、评估风险、选择最优解目标 选项 评估标准要求逻辑推演和量化分析直接建议依赖经验归纳分析需求需深度理解数据、发现模式或因果问题 数据/信息 分析方法触发因果链推导与假设验证表层总结或分类创造性需求需生成新颖内容主题 风格/约束 创新方向结合逻辑框架生成结构化创意自由发散依赖示例引导验证需求需检查逻辑自洽性、数据可靠性结论/方案 验证方法 风险点自主设计验证路径并排查矛盾简单确认缺乏深度推演执行需求需完成具体操作任务 步骤约束 输出格式自主优化步骤兼顾效率与正确性严格按指令执行无自主优化这张表的用法不是背诵是当检查清单用。你写完一段提示语问自己这属于哪一类公式里的三个要素齐了吗比如决策需求缺“评估标准”模型就只能按它自己的价值观替你选选完你还不一定认同。4.2 决策与分析需求把评估标准写进提示语讲义给了两个例子我照着改过好几版。决策需求的原例是“为降低物流成本现有两种方案①自建区域仓库初期投入高长期成本低②与第三方合作按需付费灵活性高。请根据 ROI 计算模型对比 5 年内的总成本并推荐最优选择。”这段的关键不是把两个方案说清楚而是把“ROI 计算模型、5 年”这个评估标准钉死了。你要是只说“帮我选个方案”它会给你一段“各有优劣建议结合实际情况”的正确废话。分析需求的原例是“分析近三年新能源汽车销量数据附 CSV说明①增长趋势与政策关联性②预测 2025 年市占率需使用 ARIMA 模型并解释参数依据。”这里有两个设计值得抄一是把数据作为附件给出而不是让它凭记忆编数二是明确指定分析方法ARIMA并要求解释参数依据这就把“随便画条趋势线”的路堵死了。我一般会在这两类需求后面再加一句“如果你的判断依赖某个我没提供的假设请先列出来再继续”。加了这句之后输出的可用性明显提升因为它会把假设摊在明面上你不同意可以当场纠正而不是拿到一份建立在你不知道的假设上的结论。4.3 创造性、验证与执行需求约束边界和验证路径创造性需求的原例是“设计一款智能家居产品要求①解决独居老人安全问题②结合传感器网络和 AI 预警③提供三种不同技术路线的原型草图说明。”注意第三条它要求的是“三种不同技术路线”不是“三个方案”。前者逼着模型在技术选型层面发散后者往往给你三个换汤不换药的版本。这就是“创新方向”这一要素的实际作用——你得告诉它往哪个维度发散。验证需求的原例更值得抄“以下是某论文结论‘神经网络模型 A 优于传统方法 B’。请验证①实验数据是否支持该结论②检查对照组设置是否存在偏差③重新计算 p 值并判断显著性。”这条的价值在于它把“验证”拆成了可执行的三步而不是笼统地说“帮我看看对不对”。验证需求最容易犯的错就是只说“检查一下”模型只能给你一段“整体逻辑通顺建议补充数据”的反馈。执行需求的原例是代码转换“将以下 C 语言代码转换为 Python要求①保持时间复杂度不变②使用 numpy 优化数组操作③输出带时间测试案例的完整代码。”三条约束一条管复杂度一条管实现方式一条管可验证性。少了第一条它可能给你一个三重循环的“直译版”少了第三条你拿到代码还得自己搭测试环境。4.4 三种交互策略与六种提示语类型的适用边界讲义还区分了三种策略。指令驱动是直接给出明确步骤或格式要求适合简单任务和需要快速执行的场景优势是结果精准高效风险是限制了模型自主优化空间。需求导向是描述问题背景与目标由模型规划解决路径适合复杂问题和需要模型自主推理的场景优势是激发深层推理风险是需求边界不清就会跑偏。混合模式是结合需求描述与关键约束条件兼顾灵活性与可控性但约束过度就成了指令驱动。举个混合模式的例子“设计一个三日游计划要求包含某两个景点且预算控制在 2000 元内。”前半句是需求导向设计计划后半句是两个硬约束景点、预算。这类写法在日常任务里用得最多因为它既给了模型发挥空间又给了验收标准。六种提示语类型也顺带过一遍重点是知道什么时候不该用哪种。指令型直接告诉任务问答型提问题等答案角色扮演型要求模型扮演特定角色创意型引导创意写作分析型要求对给定信息推理多模态型结合文本、图像等输入。讲义在误区里明确写了“不要对推理模型使用角色扮演这类启发式提示”原因前面说过——它有自己的推理主线你给它套一个角色它得先花精力维持人设逻辑主线反而被打断。角色扮演留给通用模型用来约束语气和视角效果更稳。5. 提示语翻车排查五类高频现象与对应修法5.1 现象推理模型输出变“规矩”了反而没以前好用现象给推理模型加了详细的分步引导和角色设定之后输出结构工整、步骤齐全但结论经常是错的而且错得很自信。原因讲义里写得很清楚推理模型已内化推理逻辑强行拆解步骤反而可能限制它的能力角色扮演这类启发式提示会干扰逻辑主线。它不是不会推是被你的步骤框住了只能在你的框架内推框架错了它也不回头。解决把提示语里的“第一步、第二步、第三步”全部删掉只留三样——问题描述、约束条件、输出格式要求。如果确实需要它展示过程用“请说明你的建模假设和关键判断依据”而不是“请按以下步骤作答”。改完之后对比跑两次你会发现它自己规划的路径通常比人手拆的更细。5.2 现象通用模型给的答案看着对一验算就崩现象让通用模型解一道需要多步推理的题它给出完整解答每步都像模像样但中间某一步的数值或前提悄悄变了。原因通用模型侧重语言生成和上下文理解不强调深度推理能力遇到严格逻辑链任务会跳过关键步骤——它不是故意编是它的训练目标里没有“必须自洽”这一项。解决换模型是首选。如果必须用通用模型就在提示语里显式铺步骤并要求它每一步标注依赖的前一步结论最后加一段自检“请检查上述推导中是否存在与前文矛盾的假设如有请指出。”这段自检不能保证全对但能把大部分自相矛盾的地方暴露出来比你自己从头核对省时间。5.3 现象需求描述很完整输出却“正确但没用”现象提示语写了三百字背景、目标、读者都交代了输出也确实扣题但就是不能用——要么太泛要么格式对不上你要填的表格。原因缺“期望”这一段。讲义把提示语拆成指令、上下文、期望三部分多数人写前两段很认真期望只写一句“请给出详细回答”。“详细”不是期望是形容词。期望应该是可验收的多少字、几段、什么结构、要不要表格、要不要给反面意见。解决把期望改写成验收条件。比如“输出 500 字以内分三小节每节一个小标题第二节必须包含一张对比表表头为方案、成本、周期、风险”。写完自己读一遍能不能拿这段去验收别人的交付物能就说明写清楚了。5.4 现象长文档摘要丢关键信息重点全在边角现象把一份几十页的报告丢进去让它“总结一下”出来的摘要通顺、结构清晰但你要找的那几个关键数字和结论一个都没有。原因开放式摘要指令没有告诉模型“什么算重要”。它会按语言模型的通用判断挑“看起来像结论”的句子而你关心的可能是某张表里的异常值、某段脚注里的限定条件。解决把摘要任务改造成抽取任务。给维度不给形容词比如“按以下五项抽取核心结论、关键数据含口径、适用前提、与上一版相比的变化、未解决的问题每项不超过 100 字原文没有的写‘未提及’”。最后那句“未提及就写未提及”很重要能有效减少它为了凑满格式而编内容。5.5 现象生成的代码能跑但不敢合进项目现象代码逻辑没问题跑测试也过但一看实现——三重循环、手写了个轮子、引入了一个项目里根本没用的依赖。原因执行需求的公式是任务 步骤约束 输出格式多数人只给了任务步骤约束和输出格式全空。模型不知道你的运行环境、不知道你能不能加依赖、不知道性能底线在哪它只能按最通用的方式写。解决把约束补全。运行环境版本、可用库、输入输出格式、复杂度或性能要求、禁止事项不许引入新依赖、不许改函数签名这四项至少给三项。再加一句“如果实现方式有多种先列两种并说明取舍再给推荐实现”你能在它动手之前就把方向纠回来比事后重写省事。6. 把它变成自己的提示语库三个文件加一轮回归验证讲义的最后一层是“从入门到精通”的学习路径但真正让水平稳住的是把试出来的东西固化下来。我自己的做法是三个文件一个任务卡、一个提示语模板库、一个回归用例集。任务卡记录的是“什么任务用什么模型、提示语侧重什么”就是第 2 章那张选型表的个人版本。模板库就是第 3 章那个 JSON按任务类型分组每条带 id 和版本号改坏了直接回滚。回归用例集最容易被忽略但价值最高——挑五到十个你常做的真实任务每个任务存一份“输入 期望输出要点”每次大改模板或者换模型拿这组用例跑一遍对比结果。文件存什么更新频率关键字段任务卡任务类型、模型选择、提示语侧重季度任务名、模型类型、验收标准模板库可渲染的提示语模板每次改动id、task_type、model_type、template回归用例真实任务输入与期望要点半年用例 id、输入、期望要点、历史最佳输出回归验证不用搞得很重一个最简单的记录脚本就够# regress.py # 用途模板改动后跑同一批用例人工比对输出是否退化 import json, datetime from pathlib import Path CASES json.loads(Path(cases.json).read_text(encodingutf-8)) def log_result(case_id, template_id, output, note): # 只记元信息和输出快照不存完整对话方便 diff record { case_id: case_id, template_id: template_id, ts: datetime.date.today().isoformat(), chars: len(output), note: note, output: output, } with Path(runs.jsonl).open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)这段的逻辑是cases.json存用例 id 和输入每次调用模型后把输出快照追加到runs.jsonl一行一条。chars字段是个便宜的退化信号——同一用例字数突然翻倍通常意味着模型开始兜圈子突然腰斩通常是关键段落被跳过了。note用来记“这次改了什么”回滚时按 note 找。参数上ensure_asciiFalse保证中文不被转义ts按天记录够用。验证方法我自己固定三条。第一同一用例跑三次看结论是否稳定三次里出现两种以上结论说明这个模板的约束不够得收紧。第二换一种措辞重跑看输出是否还成立成立说明它真的理解了任务不成立说明它只是在匹配你的句式。第三人工抽检中间步骤尤其是数字和前提条件模型最容易在这两处悄悄改东西。血泪经验是别在同一个会话里反复让模型“再改改”。改到第五版的时候它已经被前面四版的上下文带偏了输出会越来越像前面那几版。正确的做法是每次大改都开新会话用模板库里的最新模板从头跑把结果记进回归日志再比对。从那以后我每次动模板都强制走一遍这三个文件和三条验证宁可多花十分钟也不愿意在交付前一刻发现输出退化了。希望帮到你。本文还有配套的精品资源点击获取