简介北京大学DeepSeek系列《提示词工程和落地场景》PPT课件聚焦如何通过自然语言交互充分释放DeepSeek潜能适合零技术背景的普通用户、职场人士及教育从业者。内容覆盖DeepSeek-R1核心优势、火爆原因分析、提示词技巧、直接使用三种方法与常见应用场景并结合教育、金融、医疗等垂直领域展开帮助学习者突破工具表层应用实现人机智能协同。资源为1个pptx演示文稿压缩包约808KB共1个文件图文结构完整适合直接用做培训分享或自学参考。目前已有376人学习浏览。借助这份演示文稿可系统了解DeepSeek开源、低成本、国产化三大特点掌握提示词设计思路与专家思维赋能日常学习工作的具体路径。整体结构从背景、原理到实操层层递进便于快速定位所需内容是一份兼顾原理认知与落地实践的高质量入门资料。1. 提示词工程和落地场景一份课件标题背后的真实工作量去年给一家制造业客户做知识库问答时我们拿着内部流程文档直接丢给大模型结果回一句“根据文档无法确定”气得业务方把需求书摔在桌上。后来我把系统提示词从三行扩到一百多行又加了输出格式约束和拒答兜底同样的文档准确率从六成提到了九成。这件事让我意识到提示词工程不是“写几句话让模型听话”而是围绕模型的上下文、能力和边界去做一套结构化设计。北京大学这套 DeepSeek 系列课件把提示词工程和落地场景放在一起讲恰好戳中了从业者最缺的东西——提示词不是玄学它是可以被拆成模板、规则和验证流程的工程方法。这篇笔记我就顺着标题拆开讲选模型、写提示词、接进业务系统、处理那些让你半夜爬起来查日志的坑。北大这套系列课件我手头没有原文但“提示词工程和落地场景”这个组合本身就是技术栈的两段主线先弄清楚 DeepSeek 各型号的能力边界和上下文窗口再把这些能力落到 API 调用、RAG、Agent 和批量任务里。只要这两段跑通了标题背后的知识就基本吃透了。2. 先把模型和上下文搞对DeepSeek 系列能力分化和上下文窗口2.1 按任务选型号别拿一把锤子敲所有钉子DeepSeek 系列这些年迭代下来已经不是一个模型打天下而是按用途拆成了几类。常见分法是通用对话模型、深度推理模型和代码模型。例如 V3 系列适合日常对话、文本抽取、摘要速度快且成本低R1 系列适合数学证明、逻辑推理、复杂拆解它会先输出一段内部推理链再给答案Coder 系列则专门处理代码生成、补全和仓库级重构。在提示词工程里选错模型是最大的隐形成本因为你在提示词里写的再精细模型底座能力不够产出照样拉胯。反过来说通用任务拿推理模型跑一遍推理链路又长又慢成本还高。我一般会在提示词工程之前先做一个任务分类。把业务需求按“抽取型、生成型、决策型、编码型”四种标签归档抽取型优先通用模型决策型可以考虑推理模型编码型走代码模型生成型看你要的是稳定格式还是发散创意。这个步骤听起来像废话但很多团队一上来就追最新的推理大模型把简单的命名实体抽取也丢进去最后还得在系统提示词里写“不要输出思考过程”来兜底属于典型的模型和任务错配。模型选择画一张参数表是值得的即使型号版本更新快维度不变上下文长度、输出预算、扣费方式、适合任务、并发上限。DeepSeek 系列各版本的上下文长度普遍从 64K 到 128K 起步部分版本支持更长窗口输出预算要看具体套餐。这里有一个常见误区把上下文窗口当成提示词可以一直堆长实际上超过一定长度后模型对中段内容的注意力会衰减老话讲“上下文被稀释了”。所以提示词工程的第一课不是怎么把提示词写漂亮而是怎么在有限的注意力预算里分配位置。2.2 上下文工程提示词长度的分配策略最近业内流行一个词叫“上下文工程”它比提示词工程多管了一层不只要写清楚指令还要安排指令放在上下文哪个位置、用户内容塞多少、历史记录怎么裁剪。这套思路对 DeepSeek 这类上下文窗口大的模型尤其重要因为窗口大你就更想把所有材料都塞进去结果反而翻车。我的分配习惯是系统提示词占最前部把角色、任务、输出格式、拒答边界都写在开头用户消息里只放当次请求的关键材料历史对话做滑动窗口裁剪超出轮次的旧消息要么摘要压缩要么直接丢弃最后再放一句“基于以上信息作答”的复述性指令让模型把注意力收回到最近的任务上。为什么这么做注意力机制对序列头部和尾部更敏感中间容易被稀释所以最重要的角色设定必须放在开头最关键的当前任务提示要放在尾部。这里和 DeepSeek 的 API 调用直接相关的是 KV Cache 机制。长上下文的成本大多是 Cache 命中成本如果多条请求共享同一段系统提示词和知识库材料把公共前缀固定下来命中率上去了费用和时延都会下降。实际做法是让系统提示词和知识库内容始终放在 messages 数组最前面用户每次只追加尾部不同的查询这样服务端的 Cache 就能复用前面的 Key。如果你把系统提示词每次都重新拼接成新的顺序缓存命中率就掉得厉害。2.3 系统提示词、Skill 和 Agent 的边界网上有人问“系统提示词工程和 Skill Agent 有什么区别”这个问题问到点子上了。系统提示词是一段固定指令它适用于单次请求的静态约束例如“你是法务助手只依据提供的合同条款回答不确定就说不知道”。Skill 则是把系统提示词、少样本示例、输出解析逻辑和后处理封装成一个可复用单元适合同一技能被反复调用的场景例如“合同条款抽取”就是一个 Skill它的提示词模板、JSON Schema 和校验函数打包成一个模块。Agent 则是编排多个 Skill 和工具调用的执行体它决定调哪个工具、按什么顺序调、结果如何汇总。做落地时我的经验是单轮任务用系统提示词就够了同一个任务重复出现就封装成 Skill任务需要多步决策、查库、调外部 API 才能完成再引入 Agent 编排。一上来就搭 Agent 的团队多半会死在调试上因为模型每一步都可能自己跑偏。很多开源项目叫“harness”本质就是干这个的把多个智能体编排进一个可监控、可断点续跑的工作流里。课件标题里的提示词工程只是起点harnes 这类编排层才是把提示词推进到生产环境的关键一环。3. 写提示词的系统化套路从三段式模板到少样本示例3.1 一套可以抄走的系统提示词模板我在多轮项目里打磨出一套通用模板结构分六块角色设定、任务说明、输入要点、输出格式、边界约束、兜底策略。每块对应一个实际坑。角色设定解决立场问题任务说明解决方向问题输入要点告诉模型该重点看什么输出格式让后续解析不返工边界约束预防胡说八道兜底策略处理模型回答不出来的情况。一个典型的系统提示词长这样system_prompt # 角色 你是企业知识库问答助手服务对象是内部员工。 # 任务 根据提供的资料片段回答用户问题。 不得使用资料以外的知识作答。 # 输入要点 用户问题放在 question 标签内 资料片段放在 context 标签内。 # 输出格式 - 先直接给结论不超过 3 句话 - 然后列出依据标注来源段落号 - 如果资料不足输出抱歉资料中没有相关内容。 # 边界约束 - 不编造数据、不推测政策意图 - 不讨论资料范围外的敏感话题 - 回答语气中性、克制。 # 兜底 资料无法回答时严禁强行作答必须返回预设兜底句。 这段模板的价值在于把约束显式写出来。我会特别注意“输入要点”这一块用标签对用户输入和资料切片分框模型就不容易把问题文本和资料文本混在一起读。很多翻车案例就是问题里带着一段资料模型分不清哪个是待处理对象加上标签框定后就清爽多了。参数说明上温度建议按任务类型调抽取和分类任务设置为 0 或接近 0保证稳定输出头脑风暴和文案生成可以开到 0.7~0.9代码生成我一般用 0.2。top_p 默认 1.0 就够用除非你发现输出重复率特别高。max_tokens 要按输出格式估算JSON 结构建议给足 1024 以上纯文本摘要 512 足够如果截断了错误往往不是提示词问题是预算没给够。frequency_penalty 和 presence_penalty 在做长文本生成时才需要调问答场景尽量不动。3.2 少样本示例一个示例胜过十句抽象描述模型对“要什么格式”的理解力远比“不要什么”强。与其写“请以 JSON 格式输出”不如直接给一个输入输出对模型照猫画虎的成功率高得多。举例说从客户留言里抽意向等级我通常会放两三个示例样本每个样本都是“输入留言 输出 JSON”并且刻意覆盖边界情况比如一条“你们价格太贵了”被标注成“低意向但可跟进”。少样本不是越多越好。放太多示例会挤占上下文还会让模型过度模仿示例风格。我的经验是 3~5 个示例覆盖典型和边界即可示例顺序也有讲究把最标准的放第一个最难判定的放最后一个因为在序列末尾的内容对模型当下决策影响更大。示例要覆盖错误类型你希望模型避免的情况也应该有一个示例展示“这种输入应该输出哪种兜底结果”。3.3 结构化输出让模型按 Schema 说话落地场景里下游程序要解析模型输出自由文本只能靠正则硬抠抠得又痛又脆。更好的方式是直接要求模型输出 JSON并且用 JSON Schema 约束字段。比如让 DeepSeek 从简历中抽取技能清单我的提示词里会带一段 Schema 说明让模型只输出指定字段、指定嵌套深度。schema { type: object, properties: { name: {type: string}, skills: {type: array, items: {type: string}}, years_of_experience: {type: integer} }, required: [name, skills, years_of_experience] }把 Schema 直接写进提示词比写“请输出 JSON”管用因为模型的预训练见过大量 Schema 格式看到它就更容易进入结构化输出状态。注意字段名尽量用英文或拼音别用带空格的长中文名否则模型输出的键名容易漂移。解析端也要做容错模型偶尔会在 JSON 前后加一段解释文字我在代码里会先剥掉首尾的非 JSON 字符再 json.loads并捕获 JSONDecodeError 做重试。如果你要的系统是调用 OpenAI 兼容的接口还可以利用 response_format 参数直接在 API 层要求 json_object 输出。DeepSeek 的 API 也兼容这类格式比纯靠提示词约束稳定得多。不过要注意response_format 开启后提示词里必须显式出现“json”字样否则部分服务端会直接报错这个细节排起错来很费时间后面避坑章再展开。4. 把 DeepSeek 接进真实业务API、本地部署、RAG 和 Agent4.1 从聊天界面到 API最小可复现的接入路径课件里的“落地场景”落到实地上第一步是把模型从网页对话框迁到 API。DeepSeek 的 API 兼容 OpenAI 格式所以很多现成工具链能直接换 base_url 就用。最小接入其实就三件事拿到 API Key、设置 base_url、构造 messages 列表。curl -X POST https://api.deepseek.com/chat/completions \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [ {role: system, content: 你是文档摘要助手}, {role: user, content: 把这段合同摘要成三句话} ], temperature: 0.3, max_tokens: 512 }这里 model 名要查最新文档确认不同版本有不同的模型标识填错会直接 400。messages 数组的格式是 OpenAI 系标准role 分 system、user、assistant 三种历史对话就按轮次把 assistant 回复也塞回数组。有一个常见的坑有人把多轮对话里的历史回复全塞进一个 user 消息里模型会分不清哪段是它自己说的行为变得怪异。Python 端我一般用 openai 库把 base_url 和 api_key 指过去代码和官方 SDK 几乎不用改。注意超时时间要设置足够长文本生成可能超过默认的 60 秒还有重试逻辑网络抖动返回 5xx 时指数退避重试三次比立刻报错好用得多。接入微信公众号或企业微信这类 IM 场景也没那么神秘本质是平台回调消息后把它翻译成 messages 数组调用 API再把返回文本发回去。瓶颈往往在对话状态管理上比如怎么按用户维度存历史这个后面避坑章细说。4.2 本地部署和 API 怎么选业务约束决定DeepSeek 的本地部署这两年特别热尤其是数据不能出内网的企业。常见做法是用 vLLM 起一个兼容 OpenAI 的服务或者用 Ollama 跑量化版模型。vLLM 部署的好处是吞吐高、支持并发、有 continuous batching适合多业务线共用Ollama 适合单机快速验证一条命令就能拉模型跑起来但并发能力和显存管理不如 vLLM。本地部署选多大的模型要看硬件。像 Jetson Orin 这类边缘设备显存和算力都有限只能跑量化后的中小型模型比如 7B、14B 或 17B 左右的档位效果和云端大模型有明显差距。这种差距靠提示词是补不回来的。我的建议是本地部署用在推理、抽取、分类这类结构化任务上提示词要写得极其明确输出格式用 Schema 强约束创造性写作、复杂推理还是走云端大模型。很多人以为本地部署省钱把模型一拉就上线结果回答质量上不去最后又要二次开发兜底隐性成本更高。部署完成后把服务当成一个黑盒接入业务和调用 API 没有本质区别只需要把 base_url 改成内网地址。此时检查三件事并发压测时延迟是否可接受、显存溢出时服务是否自动恢复、模型版本是否固定。版本固定特别重要我吃过亏本地模型文件被重新 pull 覆盖后输出风格变了上层业务没感知结果分析报告里突然多了一堆格式漂移。4.3 RAG 落地提示词里怎么拼上下文最稳RAG 是当前最常见的落地形态把企业文档切成片段检索到相关内容后拼进提示词再让模型基于这些片段作答。这里提示词工程的价值在于组装规则检索结果怎么去重、按什么顺序拼接、片段超长时怎么截断、模型引用片段时怎么标注来源。我一般用的拼接模板是系统提示词固定不变用户消息里先放“请基于以下资料回答问题”然后是检索片段每个片段用编号包裹最后是用户原始问题。为什么把问题放最后因为模型会倾向于回答靠近结尾的内容问题放最后它的注意力集中在用户当前诉求上编号包裹片段是为了让模型能在回答里引用编号比如“依据片段 2”方便下游做溯源展示。分块策略直接影响检索质量。切片太短语义不完整切片太长又会塞进大量无关内容稀释注意力。经验值是按语义边界分块而不是死板地按字符数切。比如合同按条款切、说明书按功能模块切、对话记录按轮次切块大小控制在 300~500 字之间。检索回来的 Top-K 不要贪多取 3~5 块足够多了模型容易捡了芝麻丢西瓜。另外一个隐性参数是重排如果检索用向量相似度前面几块可能是关键词重复但语义不相关的加一个轻量重排步骤能显著提升回答准确率代价是多一次模型调用。4.4 Agent 化工具调用和编排层标题里的“落地场景”走到深水区就是 Agent让模型不只是回答问题而是调用工具完成多步任务。DeepSeek 的 API 支持 function calling也就是模型输出一个结构化工具调用字段你的程序解析后执行真实函数再把结果作为新消息回传给模型。这个循环是 Agent 的基本盘。tools [{ type: function, function: { name: search_warehouse, description: 根据关键词查询仓库库存返回库存数量和位置, parameters: { type: object, properties: { keyword: {type: string, description: 物料名称或编码} }, required: [keyword] } } }]关键在于工具描述要写得让模型看得懂而不是让人看得懂。description 字段里要写清楚什么时候该调用这个函数、参数是什么含义、返回结果什么样。模型是依据描述来决策的描述写得含糊它就会该调时不调、不该调时乱调。我在工具描述里会加上“当用户询问……时使用”的触发条件比只写功能名称准确得多。Agent 跑起来后一定会遇到失败。常见的一个错误信息是“messages tool calls need immediate results”意思是模型发出了工具调用请求但你的程序没有把工具结果立刻作为 assistant 之后的 tool 消息回传或者回传顺序不对。解决方法是严格按 OpenAI 的多轮消息格式来模型返回的 tool_calls 消息必须原样保留在 messages 里紧接着追加每条 tool_call 对应的 tool 消息role 必须是 tool并带上 tool_call_id 对应回去。这里丢了 tool_call_id 是最常见的翻车原因。如果要把多个智能体编排起来各司其职可以引入 harness 这个概念它相当于给每个 Agent 配一份独立的提示词和一组可用工具由编排层负责把任务路由给合适的 Agent、汇总各 Agent 的输出。这种架构比“一个超大提示词管所有事”更可控而且某个 Agent 挂了不会拖垮整条链路。部署时可以用 Docker 把各 Agent 拆成独立服务用消息队列串起来哪个环节慢了就单独扩容。5. 提示词落地中的高频翻车点现象、原因、解决5.1 工具调用要求立即返回结果但你的循环没闭合现象报错信息里出现 tool calls need immediate results整个 Agent 任务在第一步就崩。原因基本是代码收到模型返回的 tool_calls 后没有把执行结果按协议回传或者回传时用错了 role。解决检查 messages 数组确保模型返回的 assistant 消息原样保留且每条 tool_call 都对应一条 tool 消息。tool_call_id 必须和请求里的 id 完全一致不能重新生成。这个循环跑通一次后再去做多轮工具调用的复杂编排因为模型是逐轮决策的消息格式错误会在第二轮立刻暴露。5.2 request extension preparation failed提示词或超参数格式不对现象请求发出后返回 request extension preparation failed 之类的错误通常在换模型版本或换服务端环境后出现。原因有两类一是请求体里有服务端不认识的扩展字段二是某些参数在特定模型上不被支持。比如 response_format 要求 json_object 时提示词里必须明确出现 json 字样否则部分服务端在扩展准备阶段就拒绝了。解决先删掉所有额外参数只保留 model、messages 和 max_tokens逐步加回参数定位问题。换用兼容层时也要留意不同网关对扩展字段的透传策略不一样有的会静默丢弃有的会直接报错。5.3 长上下文里的“中段失忆”关键约束被稀释现象系统提示词写了“只依据资料回答”但用户消息里塞了一段很长的参考文档后模型就开始脱离资料自由发挥或回答里混入训练数据里的常识。原因注意力在长序列中段衰减指令被淹没。解决把最重要的约束在开头和结尾各写一遍开头声明角色和边界结尾再用一句“再次提醒只能依据以上资料回答”收住。同时控制单次上下文总量参考文档超过窗口一半时优先做检索裁剪而不是全量拼入。这个问题的表现是“时好时坏”特别难排查我排查时会先看上下文长度是不是最近才涨上去的。5.4 安全过滤导致的误伤“破甲”思路没有意义现象用户试图绕过安全限制网上也有所谓“破甲无限制词”的说法。实际落地时这类尝试大多以失败或质量崩坏告终更常见的情况是正常业务请求因为措辞敏感被安全策略拦下。原因模型本身训练了安全对齐提示词层面的“越狱”不持久也不稳定升级版本后基本失效。解决与其琢磨绕过不如把业务场景里的合理需求翻译成中性表达。比如医疗健康问题不用“怎么自杀”而是“患者出现自伤倾向应如何处置”法务问题不用“如何逃税”而是“税务筹划的合法边界”。模型对中性专业表述更配合也更稳定。这道红线业务上不要碰技术上也走不通。5.5 本地小模型把提示词上限拉低硬件的账逃不掉现象同样的提示词模板在云端 DeepSeek 大模型上表现良好换成本地量化小模型后输出格式不稳定、抽取漏字段、示例照抄得四不像。原因小模型能力阈值就在那提示词工程只能在边界内微调不能拔高上限。解决本地部署的业务只保留结构化程度高的任务复杂推理和长文本生成走云端如果必须本地就把输出 Schema 写得再死一点、少样本示例再加两个边界样本、温度调到 0。量化等级也要记录在案换量化级别等于换了一个模型提示词可能需要重新调。6. 让提示词“上保险”建立验证集和版本化管理最后一层进阶做法是把提示词当成软件代码来治理。我现在的习惯是每个项目建一个 eval 目录里面放 20~50 条带标准答案的评测样本每改一版提示词就全量跑一遍回归对比准确率、格式合规率和兜底命中率。没有这套验证集提示词优化就是盲人摸象你永远不知道改动是变好了还是变坏了。这些评测样本要注意覆盖边界正常的、模糊的、缺资料的、带干扰信息的、长文本的、用户语气不好的全部都要有。用脚本批量调用 API把输出和期望做比对结构化字段用 JSON 比对自由文本用关键词或 LLM-as-judge 打分。改动提示词后如果格式合规率掉了 5 个百分点哪怕准确率涨了也要警觉因为下游解析管道可能直接崩掉。提示词本身也要版本化。我一般把每个版本的 system prompt 存成文件命名带日期和改动原因例如 system_prompt_v3_add_reject_rules.md。模型版本升级时先跑一遍 eval如果分数下降优先怀疑是提示词里示例风格和新模型不搭而不是急着改业务代码。这套流程坚持半年后你会发现自己不再害怕换模型、调参数因为每一次改动都有数据兜底。再分享一个我踩过的教训不要把提示词硬编码在业务代码里。把提示词放到配置中心或独立文件里线上出了问题可以热更新不用重新发版。一开始我把提示词写在 Python 文件里每次调优都要走发布流程浪费了大量时间。后来改成配置中心管理A/B 测试也变得很轻松两组用户用两版提示词跑一天看指标就行。把提示词当成一等公民来管理这是我从这份课件标题里提炼出的最实用建议。希望这些拆解和踩坑记录能帮你在自己的项目里少走一段弯路祝顺利。本文还有配套的精品资源点击获取