★ FEATURED ARTICLE 简介这份PDF是由清华大学新闻与传播学院新媒体研究中心发布的《DeepSeek从入门到精通》学习材料适合AI工具使用者、内容创作者、程序员及希望系统了解大模型应用的读者。资源以图文形式系统梳理了DeepSeek的定位与核心能力从智能对话、文本生成、语义理解到代码调试与知识推理均有覆盖并结合推理模型与通用模型的对比、CoT链式思维差异及提示语策略给出不同任务下的模型选型建议。压缩包共1个文件为PDF格式大小5.14MB版式清晰、目录完整便于按章节阅读。已有228人学习下载。通过这份资料读者可以快速掌握DeepSeek官网入口与典型用法理解DeepSeek-R1等推理模型在数学推导、逻辑分析、代码生成上的优势同时学会针对创意写作、多轮对话等场景为通用模型设计有效提示语避免常见使用误区提升实际应用效率。1. 某高校这份某国产大模型使用介绍核心不是教聊天而是教干活某高校给师生发了一份某国产大模型的使用介绍我翻完之后最大的感受是它通篇在讲“怎么用对”而不是“它有多厉害”。这与网上大多数教程是两回事——网上教的是怎么问出更好听的答案这份材料教的是怎么分清哪些任务该交给它、哪些任务不该交给它以及交出去之后怎么验收结果。作为一个常年把大模型接进工作流的人我可以负责任地说这份介绍里最值钱的不是功能清单而是它对使用边界的强调。它能解决三个实际问题入门者不用再靠零散技巧去试错已经用了一段时间的人可以对照检查自己的用法哪里出了问题需要把模型接入自动化流程的人能从中找到明确的参数和判断依据。适合学生、工程师、做文档与数据分析的办公族三类人读。2. 上手前先选入口网页端、API、本地部署三选一2.1 三个入口的本质差别某高校这份材料在开头就给了结论不要一上来就考虑本地部署。我复述一下它的判断逻辑网页端适合零成本验证想法API适合把模型嵌进现有系统本地部署只有在数据不能出内网时才值得碰。三者不是升级关系而是不同任务的不同工具。入口适合谁主要成本典型用法网页/App新手、非开发者零部署成本查资料、改写文案、翻译、头脑风暴API开发者、自动化流程按调用量计费批量处理、爬虫结果清洗、业务系统接入本地部署数据有隔离要求的团队显存与运维成本高内网知识库问答、涉密文档处理我见过不少人一上来就折腾本地部署最后卡在显存不够和推理速度上连一个像样的问答都跑不起来。某高校材料的建议是对的先想清楚你的数据能不能出内网、调用频率有多高、有没有现成的API能用三句话就能过滤掉大部分伪需求。2.2 网页端零门槛但最容易被用错网页端是最简单的一步但恰恰是这一步大部分人做得不对。常见做法是打开对话框先来一句“你好”或者“在吗”然后等模型回应再输入真实问题。这属于把聊天习惯带进了工具场景。这个模型不像人你寒暄它不会更配合只会多浪费一次交互。我一般会直接给任务指令示例你是资深数据分析师。我有一段销售数据字段为日期、城市、销售额、退款额。 请按城市汇总净销售额并指出退款率超过 15% 的城市。 数据如下 日期,城市,销售额,退款额 2025-01-01,北京,12000,2100 2025-01-01,上海,9800,1300这样做的逻辑是模型的能力上限取决于你给的上下文和约束。你给它角色、任务、数据它才能按结构化的方式处理。如果只丢一句“帮我看下数据”它就会按默认的通用方式回答生成一堆泛泛而谈的分析框架而不是你要的具体结果。网页端最适合做的事是验证验证这个模型能不能处理你的任务类型、输出格式是否符合预期、回答质量是否值得接入流程。验证通过再上API验证不通过换一种问法再试或者直接换模型。很多人在网页端聊得风生水起一接API就翻车原因不是模型变了而是网页端有自动补全的对话上下文API调用时你没给够背景信息。2.3 API接入把模型变成一个可调用的函数API接入的核心不是写代码而是理解接口的参数语义。某高校材料对API部分的介绍并不长但提到的几个参数都是决定回答质量的关键。下面是一个最简调用示例import requests url https://api.example.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, # 从控制台获取不要硬编码进代码仓库 Content-Type: application/json } payload { model: chat-model-v1, # 具体模型标识以平台文档为准 messages: [ {role: system, content: 你是一位严谨的文档审校员只改错别字和病句不改原文语义。}, {role: user, content: 请校审以下文本\n这个方案的核心目标是提升平效同时降底库存周转天数。} ], temperature: 0.3, # 校对任务用低温减少自由发挥 max_tokens: 512, # 限制输出长度防止长文本截断后丢结论 stream: False # 需要完整结果时关闭流式 } resp requests.post(url, headersheaders, jsonpayload, timeout30) try: data resp.json() print(data[choices][0][message][content]) except KeyError: # 常见于限流或鉴权失败resp.json() 里会有 error 字段 print(请求失败状态码:, resp.status_code, 原始响应:, resp.text)这段代码的关键有三处。第一system消息里明确了角色和边界这一步能显著降低幻觉率第二temperature设成0.3校对场景要的是确定性不是创造性第三加了超时和异常捕获因为API接口的常态是偶尔抖动处理不了异常就无法进生产环境。参数的语义必须说清楚。temperature控制的是采样随机性取值范围通常是0到2越接近0输出越确定越接近2越发散。max_tokens不是“回答的长度上限”而是“生成到多少token就强制截断”。很多人把max_tokens设得太小导致回答在关键结论处被切断还以为是模型能力不行。另一个容易忽略的参数是top_p它和temperature类似但机制不同temperature在全局调整概率分布top_p则只在累积概率达到阈值的token集合里采样。实践中建议只调其中一个两个一起调容易互相干扰结果难以预测。2.4 本地部署什么情况下才值得碰某高校材料对本地部署基本持劝退态度这个立场在高校场景里其实是理智的。本地部署意味着你要自己搞定权重文件、推理框架、显存规划和并发控制。一台消费级显卡跑小尺寸模型倒是不难但回答质量和小尺寸推理的差距是实打实的想跑到接近网页版的水平显存需求会直接跳到几十GB量级。什么情况下值得碰我就说一个数据不出内网是硬性要求。比如处理未公开的科研数据、涉及个人隐私的调研问卷、企业内部渠道的投诉记录这类内容贴到公共接口有合规风险。这时候本地部署是唯一选项没有别的办法。常见做法是先用llama.cpp或vLLM这类推理框架拉起一个小尺寸模型验证流程是否通顺再决定要不要上更大尺寸。需要重点盯三个指标首token延迟、生成速度token/s、显存占用峰值。生成速度低于5 token/s基本没法用高于20 token/s就属于流畅。显存不够时会触发CPU回退表现是单次回复要等几十秒这种体验上线即翻车。我见过最典型的错误是数据没有隔离需求却因为“觉得本地部署很酷”浪费了一周时间。最后模型跑起来效果比API差一截运维还要每天盯日志。本地部署应该是合规倒逼的结果而不是技术偏好。3. 提示词与参数从“能聊”到“能用”的关键两步3.1 提示词四要素模板某高校材料里把提示词拆成了四个要素任务、背景、约束、输出格式。这四件事说清楚模型输出基本不会跑偏缺任何一项回答就开始变得含糊。我用过很多提示词框架这个是最不装腔作势的一个也是最好复现的一个。我常用的模板如下【任务】请对以下会议记录做结构化摘要。 【背景】这是某项目周会的原始速记有口误和重复内容只保留有效信息。 【约束】不新增原文没有的结论不评价与会者表现总字数不超过300字。 【输出格式】 - 待办事项列出责任人截止时间 - 关键决策每条一行 - 遗留问题没有则写“无”四要素的逻辑很清楚。任务决定模型做什么背景决定它按什么语境理解约束划定了它不能做什么输出格式把答案锁定在你可以直接消费的结构里。四个要素里最容易漏的是“背景”。你不告诉模型这是口误很多的原始速记它就会把那些口头禅当成有效内容一并整理进去。这套模板可以直接抄进任何场景。想改用途就替换括号里的内容框架不用动。我做文档批处理的时候习惯把这四要素写进一个Python字典再拼成字符串传给API这样批量执行时每个任务都能保持一致的约束强度。3.2 temperature、top_p与max_tokens三个最常调错的参数参数取值范围推荐场景容易翻车的原因temperature0~2创意写作 0.8~1.2检索/抽取 0.1~0.3越高越容易编造事实top_p0~10.9是默认安全区精确抽取用0.3~0.5与temperature同时大幅调整会互相抵消max_tokens视上下文而定分类任务 64~128长文摘要 512~1024设小了结果被截断设大了计费翻倍这里要着重说temperature。很多教程喜欢说“temperature调高一点回答更有创意”这句话对了一半但代价没讲清楚。temperature升高模型更愿意从概率较低的token里取样这确实会让句子更丰富同时也会让事实性内容更容易出错。你问“北京到上海的高铁要多久”它可能给你一个听起来很流畅但偏差十分钟的答案。凡是需要核对事实的场景比如数据处理、代码审查、政策解读temperature都应设低这是血泪经验换来的。top_p的原理理解成本略高实操中你可以简单记成top_p越小候选词池越小回答越保守。有人习惯先调temperature再调top_p结果发现同一个输入的输出变化很大且不可控。我的习惯是只动temperaturetop_p保持默认除非模型明显在胡言乱语才把top_p降到0.5以下试试。max_tokens是最容易被误解的参数。它不是“本次对话的总长度”而是“本次生成的最大长度”。上下文里的历史消息不计入max_tokens但会计入计费。所以长对话场景里要么控制历史消息数量要么在过期消息上做截断否则账单会先给你上一课。3.3 角色设定与输出格式约束让模型按照你的规矩说话给模型设定角色本质上是在缩小它的回答分布空间。同样一句“请帮我看看这段代码的问题”没有角色设定时模型可能给出通用建议设定“你是十年经验的代码审查员只指出会导致运行错误的缺陷”输出就会聚焦到运行时异常、边界条件、资源泄漏这些具体点。输出格式约束也一样。你不需要模型发挥文采只需要它把结果变成一个列表、一个JSON、一段可解析的文本。案例分析你是网络故障排查助手。请判断以下日志属于哪类故障。 只能输出故障类型不能输出其他文字。 故障类型选项连接超时、DNS解析失败、TLS握手失败、有数据但丢包严重。 输出格式JSON {fault_type: 故障类型} 日志内容 connect to host: timeout after 5s为什么强调格式因为真实工作流里模型输出是要被下一段程序消费的不是给人看的。一个带前后缀文字的JSON会直接让解析器报错而这个错往往要到运行中途才暴露排查成本极高。这是典型的黑匣子问题你不知道模型会怎么回答所以必须在提示词里把回答的形态锁死。设定角色的另一个好处是减少不必要的“抱歉”和“作为AI我不能……”。不是所有的拒绝都合理很多时候模型是因为你没有给它授权范围它只能踩默认安全边界。你在系统提示词里明确“你可以基于给定数据做推理并给判断”它就能放开手脚做推理而不是每次都先给你一段免责声明。某高校材料里有一个细节写得很好角色设定要写“能做什么”也要写“不能做什么”两者并列模型的自我约束会更稳定。4. 三个高频场景的落地模板学习、办公、写代码4.1 学习场景让它搭建框架不替你做作业高校场景里最常见的用法是学习辅助但某高校材料特别强调了一个边界模型应该用来解释概念、对比思路、搭建知识框架而不是直接输出一篇论文或作业答案。这不是道德说教而是实用考虑——模型生成的内容如果不能被你理解你拿在手里也过不了答辩。我常用的学习类提示词是这样的我是一名刚接触强化学习的学生。 请用“先做什么、再做什么、为什么”的结构解释策略梯度方法的训练流程。 不要使用公式推导用日常语言描述。 最后给一个简短的类比帮助记忆。这背后的设计逻辑是三重递进先要求解释流程再限定语言风格最后让模型提供一个类比。这样得到的回答前两段是可用于复习的叙述最后一段是用来“挂住”记忆的点。直接问“什么是强化学习”也能得到答案但那种回答要么太泛要么太深对新手不友好。更推荐的做法是让模型扮演提问者。你让它“针对这一章内容出5道自测题先出题不附答案”然后自己做一遍再让它批改。批改时明确要求“指出错误点并解释原因不要只说对错”。这比反复重读教材有效得多因为模型批改时你会自然地把注意力放在自己的逻辑链条上这是一种主动回忆的过程。4.2 办公场景会议纪要、文档摘要的模板化写法办公场景的核心诉求是提效不是让模型创作花哨文案。会议纪要这类任务最大的痛点在于原始速记里有大量口语、重复内容和无关讨论。直接丢给模型让它“总结一下”它会把客套话也当成有效信息写进纪要。我一般会这样构造任务请从下面这段会议速记中提取三项内容 1. 达成的决策 2. 明确的待办格式负责人 事项 截止时间 3. 被推迟或否决的议题 过滤规则删除寒暄、重复表达、与议题无关的技术争论。 速记内容 粘贴原始速记这个模板的关键在于“过滤规则”写在了要求里。模型不会自动判断什么该删你必须给出删除标准。不然它会倾向保留所有听起来相关的句子最后纪要比原文短不了多少。文档摘要同理。不要只让它“摘要”要指定输出篇幅一段话摘要、三百字简报、十条要点列表三种结果的筛选逻辑完全不同。还需要告诉它保留什么数据指标、时间节点、责任人。这些信息在原文里分散在各段你不点名它就会按自己对“重要性”的理解挑大概率挑错。办公场景还有一个常见误区把多个不相关的任务塞进同一次对话。比如先让它整理纪要又问它“下午的PPT怎么改”。同一轮对话里指令会互相污染。正确做法是每个独立任务开一个对话或者至少在消息里用分隔符把任务域重新声明。4.3 代码场景把它当结对程序员而不是代码生成器写代码场景里最常见的心态是“让AI把代码写出来我复制粘贴”。这恰恰是最危险的一种用法。模型生成的代码看起来逻辑完整但边界条件、异常处理、性能衰减它不会主动替你考虑。它更像一个经验丰富但不太了解你项目的结对程序员你需要给它上下文还要审查它的输出。代码审查是正确打开方式。我经常让模型做预审提示词如下# 提示词模板代码审查 prompt 你是资深后端工程师。请审查以下Python代码重点检查 1. 未处理的异常路径 2. 数据边界情况空列表、None、超大输入 3. 资源泄漏文件、连接、线程 4. 明显的性能问题 对每个问题先给出严重等级高/中/低再给修复建议。 不要重写整个函数只针对问题点给diff级别的修改建议。 代码 {code} 这里有几个值得注意的设计。第一要求“不要重写整个函数”避免模型一股脑给出风格迥异的完整版本反而让你难以审查。第二问题要“先给严重等级”强制它排序防止淹没在细节里。第三修复建议要“diff级别”能直接落到代码里而不是宽泛的“建议增加异常处理”。有了预审结果再决定哪些问题自己改、哪些让模型改。让模型改的时候把审查结论连同原始代码一起发回去说“根据你自己的审查结论修复问题”。这一步利用了两个回合之间的上下文记忆效果通常好于直接让它“优化这段代码”。代码生成类任务也有靠谱用法让它生成测试用例。你写实现它写测试天然互补。提示词建议是“为下面这个函数设计测试用例覆盖正常输入、边界输入、非法输入三类用pytest风格”。模型写测试用例的安全感远高于写实现因为测试的验收标准是明确的断言文字本身就是验收。5. 避坑与常见问题翻车现场、玄学调参、血泪经验5.1 幻觉它一本正经地胡说八道怎么办现象你问一个历史事件的年份模型给出清晰、流畅、具体到日期的回答但你对答案稍有怀疑一查发现年份差了整整五年。更难防的是在专业领域——它引用了一篇不存在的论文标题还说得有板有眼。原因大模型的生成机制是概率预测它在token接token地推测“最合理的下一个词”而不是在数据库里查询后再回答。因此当某个知识点在训练语料里出现得不多或者你问的内容与它学过的模式相似但不完全相同它就会用“最像正确答案”的表达来补全。从模型的视角看它不是在撒谎它是在用语言惯性填充。解决核心方法是给模型提供可验证的锚点。要么你在提示词里提供可信资料片段让它基于这些片段作答要么让它“先回答并标注哪些内容来自资料、哪些内容是推测”。对重要事实我的习惯是追问一句“这个结论的依据可以再展开一下吗”如果它给出的是泛泛而谈而不是具体来源就直接标记为存疑。还可以用反向验证把模型给出的结论拆成几个独立断言逐个追问“这个断言在什么条件下成立”。幻觉通常会在两层追问之后露出破绽因为它的填充逻辑撑不住连续性检验。5.2 隐私与数据安全哪些内容不能贴进对话框现象同事把一份包含客户手机号的Excel粘贴给模型让它整理格式然后问“这样合规吗”。这需要用脑子而不是模型回答。任何把未脱敏数据直接发往第三方接口的行为都可能在合规审查里变成事故。原因大部分人默认“对话框里的内容是私密的”但这种认知和实际情况是有差距的。在使用公共接口时输入数据可能被记录用于服务改进或安全审查。没有明确条款保障的情况下最稳妥的做法就是不传敏感数据。解决先分级再使用。公开的代码片段、脱敏后的样本数据、通用文本可以正常使用包含个人身份信息、未公开的财务数据、内部战略材料的数据一律不上传。如果确实需要在模型辅助下处理敏感数据就把数据先做脱敏处理比如手机号保留前三位后四位姓名替换为编号。某高校材料对此讲得很克制但原则很清晰拿不准就默认不能传。另一个隐藏风险是提示词本身。你的提示词里如果写了具体的项目代号、客户名、未公开的计划那即使数据本身是脱敏的上下文也已经在泄露信息。习惯上要把提示词里的专有名词也做替换项目代号改成“项目A”客户名改成“客户X”。5.3 依赖过重用了三个月发现自己变懒了现象一位A同学向我抱怨说他现在写邮件要先让模型列提纲读完论文要让模型写摘要甚至自己写周报都要先让模型起底稿。三个月后他发现自己独立写东西时的措辞结构都开始向模型风格靠拢而且写初稿这个行为本身让他焦虑了。原因模型回答的质量稳定导致大脑形成了“有更优解不必自己先尝试”的预期。写作和思考都是需要大量重复才能内化的技能每跳过一步就少一次练习。这不是模型的错是使用方式出了问题。解决给模型设定一个“先交初稿”的规矩。我可以告诉你我现在的习惯所有需要表达个人判断的任务——周报、方案、评审意见——第一稿必须自己写写完放进模型让它挑毛病。它负责攻击我负责防御。这样模型帮你提升的是“检查能力”而不是替代“产出能力”。在知识学习上也一样让模型出题、批改、对比解释都很好但让模型直接回答一页纸的标准答案再背诵就和抄作业没有区别。5.4 API调用失败限流、超时、上下文超长现象代码明明没有问题但调用偶尔返回报错有时候是请求超时有时候是标识无效还有时候提示“最大上下文长度超过限制”。日志里一片红系统看起来完全不可用。原因三个原因各有各的坑。超时通常是因为请求等待时间没有设够或服务端在高峰期响应变慢标识无效大概率是密钥更换后没有同步到环境变量或密钥被误提交到了公共仓库上下文超长则是把整个对话历史无脑拼接超出了模型的最大输入范围。解决三条经验供你自查。第一requests请求务必设置timeout建议重试策略采用指数退避连续失败三次就降级处理不要无限重试。第二密钥统一从环境变量读取不写入代码如果你怀疑密钥已泄露去控制台吊销并重新生成。第三长对话时保留最近几轮消息即可或把早期消息压缩成摘要后再传给模型。错误处理方面解析返回结果不要直接用键名索引先判断status_code再取值。下面是一个可复用的初步框架import time import requests def call_model(payload, max_retries3): for attempt in range(max_retries): try: resp requests.post(url, headersheaders, jsonpayload, timeout30) if resp.status_code 200: return resp.json() # 429限流与5xx服务端错误都可以重试 if resp.status_code in (429, 500, 503): time.sleep(2 ** attempt) continue # 4xx中除了429之外属于请求问题不重试 resp.raise_for_status() except requests.exceptions.Timeout: time.sleep(2 ** attempt) except requests.exceptions.RequestException: break raise RuntimeError(调用失败请检查日志)这个框架的核心观点是网络抖动和服务过载是常态要在代码层面接受这个现实。不要追求单次调用永远成功而是让重试机制接管偶发失败让系统整体的可用性达标。6. 进阶让模型自证、自纠、自检的三个硬技巧6.1 反向验证法让模型挑自己答案的毛病第一轮让模型给出答案第二轮把答案原封不动发回去让它“你以一位挑剔的评审专家身份逐条检查以上结论是否有逻辑漏洞或事实错误”。实践中有相当高的概率模型会找出自己刚才忽略的问题并给出修正版。关键点在于两轮对话之间不能插入其他内容保持上下文的纯净度。6.2 递进追问法一次问清不如三次问深与其期望一次提示词拿到最终结论不如设计三次提问第一次要方向第二次要细节第三次要反面论证。比如先问“这个方案的风险有哪些”再针对列出的每一条追问“你怎么判断这个风险发生的概率”最后问“如果概率判断是错的什么信号能早期发现”。层层收紧答案质量会明显高于一次长提示词。6.3 在系统提示词里写验收标准把“验收标准”直接写进系统提示词这是我用过最见效的习惯你给出的回答必须满足以下验收标准 1. 每个结论都有依据无依据的推测单独标注 2. 不重复提问者已知的背景信息 3. 字数符合要求不超限不凑数 4. 如果信息不足直接说“缺少什么信息”不强行作答这一段话等于给模型立了工作纪律。它不是通用的“请你好好回答”而是四条可以逐条核对的检查点。输出不符合时你可以直接指着一句问“这一条的依据是什么”模型会立刻调整。我现在养成的习惯是重要任务完成后不急着采用先花一分钟对照四条验收标准过一遍不达标就让它返工。这套流程被验证了无数次——大模型的价值不在于一次答对而在于你可以用它低成本地产出多轮方案再把验收标准交给它执行。希望这篇笔记能帮你把它的边界摸清楚真正变成干活时顺手的那把工具。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
