简介《DeepSeek从入门到精通》面向AI初学者、内容创作者与开发者聚焦国产大模型DeepSeek的能力边界与实操方法帮助读者从“会用”走向“用好”。压缩包内仅含1个PDF文件约5.36MB体量轻便适合碎片化阅读。内容由清华大学新媒体研究团队整理围绕DeepSeek是什么、能做什么、如何使用展开辨析推理大模型与非推理大模型的差异讲解推理模型与通用模型在提示语策略、任务匹配上的关键原则。读者可掌握文本创作、摘要改写、多语言翻译、代码生成与调试、语义分析与知识推理等场景的提问思路理解指令驱动、需求导向、混合模式、启发式提问等策略的适用边界避免对推理模型过度拆解、对通用模型过度信任。目前已有1011人学习适合希望建立大模型应用框架、提升提示词设计能力的读者参考。1. 先搞懂一件事DeepSeek 是什么零基础该怎么理解它第一次听到 DeepSeek 的人十有八九会先问一句它到底是个 App、一个网站还是又一个大模型我刚开始也卡在这儿。用大白话说它是一个能听懂人话、也能把话写出来的国产大模型你打开网页把要求打进去它给结果。所以 DeepSeek 入门这件事难的从来不是操作——打开页面、打字、回车三十秒就会难的是把“我到底想要什么”说清楚。这份材料里反复出现的那句话挺戳人当人人都会用 AI 时你如何用得更好更出彩。它适合谁写文案的、做表格的、写代码的、天天写汇报的以及所有想让重复劳动少一点的人。2. 它能替你干什么先把四类活分清楚新手最容易犯的错是一上来就研究“怎么问才高级”结果连它能干什么都没数。更稳的顺序是反过来的先在自己的工作里找出三件烦人的事再去看它能不能接。这一章不讲原理只把它的能力范围摊开给你看看完你心里应该有一张清单知道哪些活可以试着丢给它。2.1 文本类写、改、缩、译占日常使用的八成这四类任务是新手最快见效的地方也是最不容易翻车的地方因为结果好不好你一眼就能看出来。“写”包括文章、故事、诗歌这类创作也包括营销文案、广告语、社交媒体推文和帖子还有剧本和对话设计。我一般不推荐新手一上来就让它写长文容易得到一堆正确但没味道的话反而是短文案更好用比如让它给同一个产品写五条不同风格的推荐语你从里面挑一条改效率比对着空白页面发呆高得多。“改”和“缩”是另外两个高频动作。长文本摘要可以对付论文、报告、会议记录文本简化则是把一段绕口的专业表述降到你需要的阅读难度。这两件事的关键在于你要说清楚“缩到什么程度”和“给谁看”——是给领导看的 200 字摘要还是给自己看的要点清单结果完全是两个样子。“译”除了常规的多语言翻译还有本地化这一层同一句话翻成另一种语言语气、称呼、单位都可能要跟着换。新手可以把原文和译文都贴回去让它对照着指出哪里不自然这一招我用得很多。最后是结构化生成比如把一段乱糟糟的需求整理成表格、列表、日程安排或者把菜谱整理成步骤清单。这类任务对新手特别友好因为格式是否合格你一眼就能判断不用纠结文采。2.2 代码类不会写代码的人也能用上很多人以为代码相关的能力只对程序员有用其实不是。只要你需要处理数据、批量改文件、跑一个小脚本这类能力就派得上用场。它能做的事情大致有根据需求生成代码片段Python 和 JavaScript 这类常用语言都没问题对报错信息做分析并给出修复建议对已有代码做性能优化提示生成 API 文档、解释整个代码库的结构、给出使用示例以及自动补全和写注释。这里有个对新手很实用的点你不一定要会写但你要会看结果对不对。所以入门阶段最值得练的动作是“让它写然后让它解释自己写了什么”。举个最典型的场景你手上有一段别的语言写的老代码想换成 Python。这时候与其自己硬啃不如把代码贴给它同时把要求说死——保持原有逻辑、别改输入输出、每一行加注释。它给出的东西未必能直接上生产但作为“看得懂的初稿”非常好用。2.3 理解类从一堆文字里抽结论这一类是新手最容易忽略、但价值最高的一类。它的能力包括语义分析、情感分析评论和反馈、意图识别客服对话、用户查询、实体提取人名、地点、事件、文本分类和主题标签生成、垃圾内容检测以及因果分析和逻辑问题解答。说得具体一点你手上有几百条用户反馈想知道大家到底在抱怨什么。硬看要看一整天交给它的话先让它按“功能问题、体验问题、价格问题、其他”分类再让它从每类里挑出三条最有代表性的原话。注意最后这半句很重要——要求它引用原话你就有了核对的办法能立刻发现它是不是在瞎编。这一类任务对提示语的要求比文本类高一些因为“分类标准”必须你自己给不能指望它猜。你给的标准越明确结果越能用。2.4 先把预期调整到合理水平它做不好什么入门阶段最影响体验的不是技巧是预期。有四件事新手一定要提前知道。第一它对实时信息的掌握有限涉及“今天”“最新”“刚发布”这类问题时一定要看联网搜索有没有打开或者干脆自己把资料贴进去让它读。第二它会生成看起来很像真的、但其实不存在的内容尤其是数字、人名、文献引用凡是需要签字负责的结论必须回到原始材料核对。第三文件上传虽然能扫描读取文字但图片和扫描件识别偶尔会出错重要文件先让它复述关键段落再动手分析。第四它给的是初稿不是终稿你省下的是从 0 到 1 的时间从 1 到 10 还得自己来。提示把“它能帮我省哪一步”想清楚比“它能不能全替我做完”有用得多。3. 第一个例子怎么跑从一句话需求到能用的结果理论说再多不如亲手跑一遍。这一章带你走完一个最小闭环写一句需求、发出去、拿到结果、改三遍。整个过程不涉及任何安装配置打开官方网页版就能做。第一次跑通之后你对它的感觉会从“玄学”变成“工具”。3.1 第一步先想清楚成品长什么样新手最常见的动作是打开对话框就敲“帮我写个方案”然后对着结果摇头。问题不在模型在于你没定义成品。发出去之前先回答三个问题这东西给谁看大概多长要什么格式和语气“给谁看”决定了用词和详略给同事看可以带术语给客户看要说人话。“多长”决定了它是要点清单还是一篇完整文章不给长度它往往写得比你要的长。“格式和语气”决定了它是一段话、一个表格还是分点罗列。这三个问题花不了两分钟但能把结果质量拉开一大截。我第一次带新人时让他们分别用“一句话需求”和“回答完三个问题的需求”各跑一次对比完基本就没人再偷懒了。3.2 第二步照着这个结构把需求写下来不用背什么复杂框架记住三块就够你要它干什么、它需要知道什么、你要什么形式的结果。下面这个模板可以直接抄去改。# 任务帮我把下面这段会议记录整理成一份给部门负责人看的工作简报 # 背景会议讨论的是下季度的活动排期参会的有市场、运营、设计三个组 # 材料把你的记录粘贴在这里 # 要求 # 1. 只保留结论和待办事项过程讨论不要写 # 2. 待办事项要标出负责组和截止时间没提到的写“待定” # 3. 总长度控制在 300 字以内 # 输出格式先一段 100 字以内的概述再用列表列待办这几行分别对应了三个东西任务那一行是“指令”告诉它做什么背景和材料是“上下文”让它有依据要求加输出格式是“期望”框住结果的样子。新手写不好提示语九成是缺了中间那块上下文导致它只能靠猜。粘贴材料的时候有个小技巧材料里的无关内容可以删但别删得太狠把关键数字和时间删了它就只能编。宁可多贴两段也不要让它靠常识补。3.3 第三步发出去然后按方向改三遍第一遍的结果大概率是“能用但不够好”这很正常。改的时候别只说“再改改”要说清楚改哪个方向。常用的三个方向是加约束、给示例、换说法。加约束就是补条件比如“每条待办不超过 20 字”“不要用‘进一步’‘持续’这类词”。给示例是最有效的一招你可以把它上一版里写得好的那一条贴回去说“后面几条照这个长度和语气来”。换说法适用于结果完全跑偏的情况与其在原句上修修补补不如重新描述一遍需求。改三遍是个经验值。第一遍看方向对不对第二遍调节奏和篇幅第三遍抠细节和用词。超过三遍还在原地打转通常不是提示语的问题是需求本身没想清楚这时候该停下来自己先写两行提纲。3.4 第二个例子让它写一段能跑的代码文本类跑通之后可以试试代码。下面这段是我常用来给新人演示的需求你可以原样发过去看看它给什么。# 需求写一个函数统计一段文字里每个英文单词出现的次数 # 要求 # 1. 忽略大小写Apple 和 apple 算同一个词 # 2. 去掉标点符号但保留单词中间的连字符比如 well-known 算一个词 # 3. 返回一个字典按出现次数从高到低排序 # 4. 每一行加中文注释说明这行在干什么它给出的代码细节每次可能不太一样这不要紧。你要看的是三件事它有没有处理大小写、有没有处理标点、排序有没有真的做。这三点就是检验它是否认真读了你的要求。拿到代码之后别急着复制走。先自己造一条测试数据跑一遍比如Apple apple, well-known well-known banana.看结果是不是apple出现两次、well-known出现两次、banana出现一次。跑不通就把报错原样贴回去让它自己修——这比自己盯着看快得多。参数上也需要留意输入的text应该是字符串返回值是字典键是单词、值是次数。如果它返回的是列表而不是字典说明排序那一步它用了别的写法你要么接受要么明确要求“返回字典而不是列表”。对新手来说能看懂返回值的结构就已经跨过最难那道坎了。3.5 还有一条路把文件直接丢给它读除了打字提问它还支持上传文件能扫描读取各类文件及图片中的文字内容。这条路对新手特别友好因为你不用把长材料复制粘贴直接上传就行。步骤上建议这么做先把文件传上去然后问一句“这份文件一共几页、主要讲了几件事”确认它读全了接着再提具体问题比如“把第三章提到的三个风险点列出来”最后要求它引用原文方便你核对。如果上传的是图片或扫描件一定加上那句“请先复述图片里的关键文字再回答我的问题”。这一步看起来多余实际上能帮你筛掉大部分识别错误。我吃过亏一份拍歪了的表格它读错了两列数字我当时没核对就用了后面返工了半小时。4. 入门绕不开的一个概念推理模型和通用模型差在哪用了一段时间你会发现同样是提问有些问题它答得又快又顺有些问题怎么问都不到位。这背后有个很关键的分野模型分两类一类靠“快速反应”一类靠“慢速思考”。搞懂这件事你的提示语水平会往上跳一档因为你会发现很多时候不是你不会问是你问错了对象。4.1 一个比喻先说明白快思和慢想有些模型的工作方式像直觉反应基于大量数据训练快速预测接下来最可能出现的内容响应快、算力成本低适合处理即时任务。另一类模型则在生成答案前先做链式推理把问题拆成若干步一步步往前推速度慢、成本高但复杂问题上更稳。这个区别可以类比成人做数学题。简单口算你可以脱口而出但一道需要多步推导的证明题你必须拿草稿纸一步步写。前一种模式适合聊天、改写、头脑风暴这类不需要严密链条的事后一种适合数学推导、逻辑分析、代码生成、复杂问题拆解。有个反直觉的点新手容易忽视这两类不是“谁更强”的关系而是“谁更适合”。推理模型在它训练目标覆盖的领域显著更好但在发散性任务上反而不如通用模型比如让它写诗它可能给你一首结构工整但毫无灵气的作品。4.2 怎么判断手上的活该交给哪一类判断标准其实很简单看这个任务需不需要“一步一步推”。需要严谨链条的交给推理型数学证明、逻辑推理、代码生成与调试、需要拆解的复杂问题、需要验证结论是否成立的场景。这类任务的共同点是中间错一步后面就全错所以要的是稳不是快。需要发散和表达的交给通用型创意写作、文案、多轮对话、开放性问答、把一段话换个说法。这类任务没有唯一正确答案要的是灵活和语感。现实里很多任务是混合的。比如“分析一份数据并给出三条建议”分析部分需要推理建议部分需要表达。这时候可以拆成两轮先让它做分析、把推导过程写出来你确认没问题再让它基于这个分析写建议。一次干两件事往往两件都干得一般。还有一类容易被误判看起来是“写”实际是“推”。比如写一份带预算的方案里面涉及成本测算那就不是纯创意任务了该按推理的路子来。4.3 同一件事两种问法结果差很远这里的差别主要在提示语策略上。对推理型模型提示语应该更简洁只需明确任务目标和需求因为它已经把推理逻辑内化了你强行拆解步骤反而可能限制它的能力。对通用型模型则需要显式引导推理步骤或者提供示例否则它可能跳过关键逻辑。下面这张表是新手最该记住的一张做任务前扫一眼就行。任务类型适合的模型提示语侧重点有效的问法要避免的问法数学证明推理型直接提问不用分步引导“证明勾股定理”强行拆成“先画图、再列公式”创意写作通用型鼓励发散给风格和角色“以海明威的风格写一个冒险故事”过度约束比如要求按时间顺序列代码生成推理型简洁需求信任它的逻辑“用 Python 实现快速排序带注释”手把手教它先写哪个函数多轮对话通用型自然交互不用结构化指令“你觉得人工智能的未来会怎样”强制它必须分三点回答逻辑分析推理型直接抛出复杂问题“分析电车难题中的功利主义与道德主义冲突”加主观引导比如“你认为哪种对”看这张表你会发现一个规律越是需要严密推导的越要少管越是需要风格和表达的越要多给方向。4.4 两个必须记住的误区第一个误区是对推理型模型用“启发式”提示比如给它安排一个角色、让它分步骤想。这类做法在通用模型上很有效但对推理模型可能干扰它的逻辑主线结果是它一边演角色一边推理两头都没做好。要什么直接说是这类模型最舒服的用法。第二个误区是反过来——对通用模型过度信任。你直接问它一道复杂推理题它可能给你一个听起来很顺、但过程有漏洞的答案。这时候的正确做法是把问题拆开一步步追问每步都验证。判断自己有没有踩坑有个简单的自查如果你发现“怎么改提示语都没用”先别改措辞换一类模型试试。很多时候问题不在你怎么问在你问错了对象。5. 新手最容易踩的 5 个坑都是我没核对吃的亏这一章会比较扎心因为每一条都是真实发生过的。新手阶段最大的成本不是不会用是用错了还不知道把错误结果当成正确答案用出去。下面五条按“现象、原因、解决”写遇到对应情况直接对号入座。5.1 坑一把它当搜索引擎用现象问“最近有什么新政策”“某个产品现在多少钱”它给了一个很像样但经不起核对的答案你一查发现根本不存在。原因它的知识有截止时间对实时信息的掌握有限遇到不确定的地方不会说“我不知道”而是会生成一个看起来合理的内容补上。这不是它故意骗你是这类模型的工作方式决定的。解决涉及实时信息的任务先看联网搜索有没有打开如果没有就把资料自己找好贴进去明确说“只根据我提供的材料回答材料里没有的写‘未提及’”。后面这半句是关键它能把编造的空间压到最小。5.2 坑二一句话扔过去然后嫌它写得空现象输入“帮我写个活动方案”得到一份放在任何公司都能用的模板全是“提升品牌影响力”“增强用户粘性”这类话一句能用的都没有。原因它没有你的上下文。你的活动是什么性质、预算多少、面向谁、场地在哪、上一次同类活动出过什么问题这些它一概不知道只能往最通用的方向写。解决至少补齐三样——给谁看、要多长、有什么硬约束。再加一样最好用的给它一个你自己写过的例子说“照这个风格来”。有示例和没示例结果差得很明显。5.3 坑三对推理型模型手把手教越教越差现象你怕它想不周全把步骤拆得特别细还给它安排了角色结果它给出的答案反而绕逻辑链断在半路。原因这类模型本身已经内化了推理逻辑会自动生成结构化的推导过程。你强行拆解等于给它加了一堆额外约束它得一边完成推理一边满足你的格式要求注意力被分散了。解决把任务目标和需求说清楚就行剩下的交给它。如果你确实想控制过程可以等它给出结果后再让它“把第三步的推导展开讲讲”而不是一开始就把路堵死。5.4 坑四拿到结果直接用数字和人名一个都不核对现象一份带数据的报告里有两个百分比明显不对劲或者引用了一本书书名对但作者错了。这类问题往往在交出去之后才被发现。原因模型生成的是“最像正确答案的内容”不是“查证过的内容”。数字、人名、文献引用、法规条款这几类是最容易出问题的地方。解决给自己定一条硬规矩——凡是需要签字、需要对外发布、需要担责的内容里面的每一个数字和专有名词都要回到原始来源核对。改这一遍大概多花十分钟但省下的是返工和解释的成本。5.5 坑五一次问十件事每件都得到一句废话现象一条消息里塞了“帮我分析数据、写个总结、再想三个方案、顺便起个标题”结果每一项都答得很浅你还得重新问一遍。原因一次任务里目标太多它的注意力被摊薄每个方向都只能给出通用回答。这跟人一样你让同事一次干四件事他也只能每件都做得马马虎虎。解决拆成多轮一轮一个目标。先做分析确认没问题再基于分析写总结最后单独起标题。多花几轮对话但每一轮的产出都能直接用。注意这五条里第四条最容易造成实际损失也最容易被忽略因为错误看起来太像正确的了。6. 下一步学什么把“下指令”换成“说需求”跑通第一个例子之后很多人会开始背各种提示语模板我不太建议这么做。模板会过时需求表达不会。真正值得练的能力是把“下指令”换成“说需求”——不是命令它做什么而是把它需要知道的信息给全。具体来说一条好用的需求通常包含三块指令明确告诉它要完成什么任务上下文提供背景信息帮它准确理解期望说明你要什么形式、多长、给谁看的结果。这三块你可以当成检查清单每次发出去之前扫一眼缺哪块补哪块。不同类型的需求表达方式也有差别。做决策时给出目标、选项和评估标准做分析时给出问题、数据和你想用的分析方法要创意时给主题、风格和约束要验证时给结论、验证方法和风险点要执行时给任务、步骤约束和输出格式。这些不是死规则是提醒你别漏信息。如果你只打算练一个动作我建议练“给示例”。从你已有的材料里挑一段写得好的贴进去说“照这个来”效果比加十条形容词都明显。我第一次带新人时不信这个觉得太土后来发现他们用示例的那几次产出质量稳定得离谱。最后说个我自己的习惯。从那以后我每次把结果发给别人之前都强制走一遍“数字核对 让它复述结论”这两步不管多赶。这两步加起来不到五分钟但帮我挡掉过好几次尴尬。入门阶段最重要的不是学多少技巧是养成一个能长期用的习惯。希望帮到你。本文还有配套的精品资源点击获取