★ FEATURED ARTICLE 简介清华大学新闻与传播学院新媒体研究团队编写的DeepSeek应用指南面向希望系统学习大模型技术的入门者与进阶实践者围绕从入门到精通的主线解答模型选型、提示语设计与任务落地等核心问题。资源为1个PDF文档压缩包约5.5MB内容系统梳理了DeepSeek-R1推理模型的智能对话、文本生成、语义理解、代码生成等典型场景并重点对比推理模型与通用模型的性能差异、CoT链式思维的应用原理以及不同任务场景下的提示语策略。已有1870人学习下载适合初次接触大模型的AI学习者也适合需要在工作中高效运用提示词的开发者与内容创作者。文档以清晰结构呈现知识要点读者可快速掌握数学推导、代码生成、创意写作等场景的模型选择方法避开常见使用误区更充分地发挥国产开源模型的能力。1. 从一份被疯传的PDF说起DeepSeek真正值钱的是调教方法网上那份标着某高校出品的《DeepSeek从入门到精通》PDF最近又被翻出来传了一遍。说实话我也下载过翻了十几页就关掉了内容不是没用而是太像教程目录——什么是大模型、什么是Token、什么是上下文窗口每章都讲得四平八稳但真正让DeepSeek从“能聊天”变成“能干活”的那些细节全藏在后几十页的例子里没有耐心根本挖不到。这篇笔记想做的就是把这类PDF里最值得学的部分拎出来直接落到可复现的操作上。聊三个事一是DeepSeek到底适合放在哪条使用路径上二是提示词怎么写才稳定三是API接入后哪些参数真正值得调。最后我会把最常见的翻车点列一遍。适合谁看想用DeepSeek替自己跑批量文本处理的开发、刚接触大模型 API 的产品和测试以及被“提示词万能论”忽悠过、想知道边界在哪的人。PDF可以帮你建立初步概念但真正拉开差距的是后面这几章的实操细节。2. DeepSeek三条使用路径先想清楚你要的是聊天、API还是本地模型2.1 页面聊天验证想法最快但别让它背锅很多人第一次用DeepSeek是在网页聊天框里。这个路径的门槛最低适合做三件事验证提示词思路、看模型对某个领域的回答风格、快速整理碎片信息。我一般会用它来“试Prompt”先在聊天框里把角色设定、任务描述、输出格式都敲一遍确认输出形态符合预期再搬到代码里跑批量任务。但页面聊天有个容易被忽略的问题它背后有一套默认参数比如temperature通常不是0回答里带了随机性而且聊天框有自动的上下文裁剪策略。你在网页上把一段超长文本粘进去它可能只读了前半部分就开始回答——页面不会告诉你它裁掉了什么。所以页面聊天适合“看方向”不适合“定标准”。真要到生产环境必须走API参数自己控制日志自己留。这个阶段的另一个价值是建立“手感”。用同一段需求分别用口语化描述和结构化描述试几次能直观感受什么叫“指令越具体输出越稳定”。具体怎么写第三章会展开。2.2 API接入DeepSeek变成业务流水线的一环当你要把DeepSeek集成到自己的工具、脚本或系统里API是唯一靠谱的路径。API方式有几个明确的好处可以批量处理、可以传结构化参数、可以拿到流式输出、可以把每轮请求的输入输出都记录下来。常见做法是走OpenAI兼容的接口格式这意味着你如果写过OpenAI接口的代码迁移成本很低。下面这个是最小可用的调用脚本我用它来验证API连通性from openai import OpenAI client OpenAI( api_keysk-你的密钥, base_urlhttps://api.deepseek.com/v1 # 或你实际使用的网关地址 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个严谨的技术文档翻译助手。}, {role: user, content: 把下面这段中文翻译成英文保留术语原样\n上下文窗口决定了模型能记住多长的对话历史。} ], temperature0.3, max_tokens500, streamFalse ) print(resp.choices[0].message.content)这段代码里base_url指向DeepSeek兼容接口的地址api_key换成你自己的密钥。model选deepseek-chat是通用对话模型如果任务偏代码生成或结构化推理某些版本会有专门的模型标识具体以官方文档为准。messages列表里system角色用来设定整体行为约束user是本次输入。temperature0.3是为了让翻译输出更稳定减少随机发挥。streamFalse表示等完整结果返回后再打印调试时这样最直观生产环境建议改成streamTrue边生成边输出降低首字延迟。跑通这段代码之后DeepSeek才算真正接进了你的工具箱。后续所有进阶操作比如批量摘要、结构化抽取、多轮对话管理都是在这个基础上加逻辑。2.3 本地部署什么时候才值得碰本地部署DeepSeek这类模型是三条路里成本最高的。你需要考虑显存、推理速度、模型量化精度还要自己维护推理服务。对绝大多数团队来说本地部署的理由只有三个数据不能出内网、单次调用量大到API费用扛不住、需要在离线环境做推理实验。如果你的诉求只是“把PDF里的技巧应用到业务里”我建议直接走API把省下来的时间拿去做提示词迭代和结果评测。本地部署是一个“看起来更自主、实际更烧运维精力”的方向适合有专门模型服务团队的情况不适合一个人边学边用。真到了需要本地推理那一步也先别碰量化参数、KV Cache这些细节先跑通官方推荐的部署脚本再说。3. 提示词从“能用”到“好用”结构比措辞更重要3.1 反直觉结论指令越具体模型越“听话”聊天框里人跟人说话可以靠默契但DeepSeek没有默契它只能靠你给出的约束。这里有个反直觉的结论很多用不好DeepSeek的人问题不是“不会提问”而是“太像跟人说话了”。对比一下这两条指令差帮我写个周报。好你是我的项目助理。请基于以下三条项目进展写一份周报。格式要求分“本周完成”“风险与阻塞”“下周计划”三节每节用无序列表不超过5条语气客观不夸大成果。第二条能拿到稳定可用的结果第一条大概率会得到一篇泛泛而谈的流水账。背后的原理是DeepSeek这类模型在训练时见过海量的“指令—回答”配对如果指令里没有结构约束它只能按语料里最常见的回答模式生成而那种模式是统计意义上的“平均答案”不是为你的场景定制的答案。你把角色、背景、格式、长度、语气都讲清楚它就失去了“自由发挥”的空间输出自然更可控。3.2 结构化提示词模板把角色、背景、约束、输出格式拆开我一般会把提示词拆成五个部分角色、任务、背景信息、输出要求、边界条件。下面是一个可以直接改的模板实现用Python字典来组织方便后续维护和测试prompt_system { role: 你是一名资深的科技媒体编辑擅长把技术内容改写成通俗易懂的短文。, task: 把用户提供的技术说明改写成一篇适合公众号发布的文章。, context: 用户会提供原文原文可能是代码注释、技术文档或会议纪要。你可能需要补充背景信息但不得编造事实。, output_format: 结构要求先写一段100字以内的摘要再分3个部分展开每部分配一个小标题。语言要求口语化避免‘赋能’‘抓手’类黑话。, boundary: 如果原文提到具体版本号或数字必须原样保留不得推测。字数控制在800字以内。 } def build_prompt(system_parts: dict, user_text: str) - str: system_content \n.join(f{k}{v} for k, v in system_parts.items()) return f【系统设定】\n{system_content}\n\n【用户原文】\n{user_text}这段代码的核心价值在于把提示词当成代码来维护。每一部分单独成一个键改任务描述不会影响角色设定评审时也能逐条过。最终生成的内容里“【系统设定】”和“【用户原文】”之间有一条空行这能帮助模型区分指令和输入数据。使用的时候只需要调build_prompt(prompt_system, text)然后喂给上一章的API调用脚本即可。参数说明这几段提示词的顺序也有讲究角色在最前让模型先“入戏”边界条件放在最后相当于最后重申一次红线实测对控制输出长度更有效。如果你的任务偏抽取比如从简历里抽字段把output_format改成“只输出JSON不要任何解释文字”效果会比在对话里反复叮嘱好得多。3.3 几个让提示词稳定复现的小习惯提示词工程里面我踩过不少坑摸索出几个稳定复现的习惯。第一个习惯是“拒绝让模型猜”。比如你要它抽取日期就明确告诉它“格式一律为YYYY-MM-DD”否则它今天给你“2024年3月1日”明天给你“March 1, 2024”你的下游程序第一个挂掉。第二个习惯是“给例子比给描述更有用”。描述抽字段的规则要写一大段但给一个“输入→输出”的示例模型一眼就能看懂。这种做法在专业术语里叫few-shot放到提示词里其实就一句话在用户指令后附上一对示例。第三个习惯是“长任务做分步”。一次让DeepSeek同时做“改写 提炼摘要 翻译 找错别字”它往往顾此失彼。拆成多轮调用每轮只干一件事准确率会明显提高。这些习惯在页面聊天时也能用但真正的收益是在批量场景里体现的改一次模板几百条文本一起变整齐。这也回答了标题里“从入门到精通”到底精在哪——不是会聊而是会设计输入。4. 用API把DeepSeek接进自己的工具完整调用与参数调优4.1 一个能直接改的DeepSeek API调用脚本第二章里那个脚本只做了连通性验证这节我们把它扩展成一个能处理实际任务的版本。假设我们要做一件事把一批用户反馈按“设备问题、账号问题、功能建议、其他”四类打标。直接让DeepSeek分类看起来很简单但直接写Prompt会得到各种意外输出比如它可能会在类别后加一句解释。要拿到干净结果必须在请求里做约束。from openai import OpenAI client OpenAI( api_keysk-你的密钥, base_urlhttps://api.deepseek.com/v1 ) def classify_feedback(items: list[str]) - list[dict]: results [] for text in items: resp client.chat.completions.create( modeldeepseek-chat, messages[ { role: system, content: 你是一个客服工单分类器。只输出分类结果不要输出任何解释。 }, { role: user, content: ( 请把下面这条用户反馈归类为设备问题 / 账号问题 / 功能建议 / 其他。\n 输出格式只输出类别名称例如设备问题\n\n f用户反馈{text} ) } ], temperature0, max_tokens20, frequency_penalty0.0, presence_penalty0.0, timeout30 ) label resp.choices[0].message.content.strip() results.append({text: text, label: label}) return results逻辑说明我把“只输出分类结果不要解释”放在系统消息里把“你是一个分类器”这个身份放在最前面这样模型倾向于直接给答案而非展开论述。用户消息里任务描述、格式要求、示例格式、具体内容依次排列并用\n\n隔开。temperature0很重要这个任务需要确定性输出宁可牺牲一点多样性也不允许它把“账号问题”写成“这可能是账号方面的问题”。max_tokens20是因为分类结果很短设太大会浪费等待时间——如果模型输出超长这个上限还能逼它早点结束。实际上极端情况下它会因为长度限制被切断但对短分类任务来说20个Token足够。还有两个容易被忽视的参数frequency_penalty和presence_penalty。前者惩罚重复用词后者惩罚话题重复。分类任务里两个都设0让模型按字面意思做映射不要“自由发挥”。timeout30也很关键DeepSeek在高峰时段可能响应较慢设一个超时时间避免单条卡死整个循环。4.2 五个参数的调优方向与推荐起点很多人在API接入后第一个动作就是乱调temperature这其实不对。参数调优的正确顺序是先固定提示词再调生成参数。下面这张表是我自己调参时的参考起点场景不同可以浮动但方向是稳定的。参数作用什么时候调低什么时候调高推荐起点temperature控制随机性分类、抽取、翻译等需要确定性输出写文案、头脑风暴、生成创意0.3业务场景多数在00.5top_p控制候选词范围与temperature有叠加效应想让输出更集中时想保留更多候选时0.8左右注意别和temperature同时大幅调整max_tokens限制输出长度输出只要短答案长文生成按任务估算分类给20摘要给500frequency_penalty惩罚重复词不希望模型啰嗦允许重复、需要强调某个点0.00.5presence_penalty惩罚重复话题需要每篇输出话题不同需要围绕同一话题深挖0.00.5写系列文章时可调高比参数更重要的是观测。每跑一次批量任务把输入提示词、参数组合、原始输出都存到日志里。下次某个参数改了对比一下前后的失败case才知道改动到底起了什么作用。否则你会发现昨天能复现的结果今天换了几个词就翻车了而你根本不知道变量是什么。4.3 流式输出与批量处理两个提升体验的常见做法页面聊天时你看到的是一个字一个字蹦出来的这就是流式输出。API默认是一次性返回全部结果如果模型生成2000个Token可能要等十几秒。传到代码里streamTrue以后结果变成生成器你可以边收边处理也能给用户端做一个“正在打字”的效果。stream client.chat.completions.create( modeldeepseek-chat, messages[...], streamTrue ) collected [] for chunk in stream: delta chunk.choices[0].delta if delta and delta.content: collected.append(delta.content) print(.join(collected))这里choices[0].delta是流式返回的增量片段没有内容时要跳过。批量处理时还要注意频率限制大批量任务尽量加time.sleep(0.2)之类的节流或者做成指数退避重试否则很容易撞上接口限流。这两个点做到位你的API调用才具备“能上生产”的基本素质。5. 避坑指南DeepSeek用起来最常见的5个坑5.1 同样的意思换个说法输出判若两“模”现象把“把这段文字压缩成50字摘要”改成“请用50字以内的篇幅概括这段文字”输出风格明显变了前者干巴巴后者像人话。原因DeepSeek对措辞敏感尤其是指令里的动词和长度描述。“压缩”暗示了删减“概括”暗示了重新组织模型会跟着这个语义走。解决固定一套你测试过的高质量措辞写进模板不要每次临场改。想测试新措辞效果不要拿一条文本试拿20条跑一遍对比。5.2 上下文一长模型开始“选择性失忆”现象多轮对话里前面第3轮你告诉它“不要引用英文资料”到第8轮它引用了一堆英文文献或者在一个长文档分析任务里它分析的结论明显只基于后半部分内容。原因模型对上下文中间部分的信息记忆最弱这是Transformer架构的已知特征不是DeepSeek独有的问题。上下文太长时头部和尾部的指令更容易被“记住”中间内容被稀释。解决重要约束重复放在每轮对话里不要只说一次。如果是长文档分析把原文按章节切片分多次调用API最后再做汇总而不是一次性全塞进去。5.3 输出总被拦腰截断不是模型不行现象生成到一半突然停止既没有总结也没有结尾最后一行停在句子的中间。原因max_tokens设小了。模型生成到上限被迫中断它不会聪明到“先收个尾”而是直接停。解决先估算任务输出规模再设max_tokens。对表格、长文、代码这类结构化内容把上限放宽50%摘要任务500长文生成放宽到2000以上。如果必须限制长度把“控制在500字以内”写进提示词而不是只靠max_tokens硬切。5.4 温度不是“智商旋钮”调太高就飘现象temperature0.7以上时代码注释开始出现“花哨”的措辞翻译结果开始加戏抽取任务偶尔冒出不存在的字段。原因temperature控制的是采样随机性不是模型能力。它调高以后低概率词更容易被选中输出看起来“有创意”同时也更不可控。有些人把它当“提升创造力”的开关结果把事实性任务做成了文本生成游戏。解决事实性任务一律用temperature0或0.1创意任务也用0.5起步不要冲到1以上。想测试极端温度去页面聊天里玩别在生产环境里试。5.5 别人的提示词模板不能直接抄现象看到一个博主分享的“万能提示词模板”原样复制到DeepSeek里效果远不如博主的演示。原因提示词的效果跟模型版本、任务类型、甚至输入数据的格式都强相关。博主用的模型版本可能和DeepSeek不同样本数据也可能是挑选过的。模板的“骨架”可以借鉴“血肉”必须自己填。解决把别人的模板当成初版先在你的10条真实样本上跑一遍逐条看失败原因再改角色设定、格式约束和示例。这个迭代过程才是提示词工程的本质而不是靠一条咒语通吃所有场景。6. 进阶技巧建一个DeepSeek回归评测集告别“靠感觉调参”我用DeepSeek做批量文本处理时踩得最多的坑不是不会调参而是“上次调好用了这次改了别的东西就坏了”。比如你改了提示词里的格式要求本以为只影响输出格式结果分类准确率也变了。要杜绝这个问题得有一套固定的评测样本。我建议你从自己真实的业务数据里挑20到30条覆盖典型场景最好包含几条边界case比如空文本、超长文本、带错别字的文本。然后写一个简单的评测脚本固定输入只改要测试的变量自动调用API记录输出结果并打分。import csv from openai import OpenAI client OpenAI(api_keysk-你的密钥, base_urlhttps://api.deepseek.com/v1) test_cases [ {text: 手机连不上Wi-Fi重启也没用, expected: 设备问题}, {text: 账号被锁定了收不到验证码, expected: 账号问题}, # ... 继续补充边界case ] def run_eval(prompt_version: str, temperature: float): results [] for case in test_cases: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是客服工单分类器。只输出类别。}, {role: user, content: f分类{case[text]}} ], temperaturetemperature, max_tokens20 ) pred resp.choices[0].message.content.strip() results.append({ text: case[text], expected: case[expected], pred: pred, correct: pred case[expected] }) acc sum(r[correct] for r in results) / len(results) with open(eval_result.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[text, expected, pred, correct]) writer.writeheader() writer.writerows(results) return acc这个脚本每次只改temperature、prompt_version这一个变量把全部测试case跑完输出准确率和失败明细到CSV。这样你改任何提示词或参数都能立刻看到是变好还是变坏而不是凭感觉说“好像好了一点”。我之前就是靠感觉调参结果为了复现一个偶然的好结果浪费了整整两天——从那天起我立了个规矩任何一次生产变更先跑评测集再上真实任务。后来我把评测集扩到50条每次调完跑一遍只要几分钟但省下的排障时间数不过来。这点习惯比记住任何参数说明都值钱。如果你现在正准备用DeepSeek做实际任务别急着把PDF里所有技巧都用上。先搭一条最小链路把20条样本的评测跑通再开始调优。真正让你“从入门到精通”的不是模型本身而是你对自己数据的理解。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
