简介：北京大学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 和 Agent
4.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 测试也变得很轻松，两组用户用两版提示词，跑一天看指标就行。把提示词当成一等公民来管理，这是我从这份课件标题里提炼出的最实用建议。希望这些拆解和踩坑记录能帮你在自己的项目里少走一段弯路，祝顺利。
本文还有配套的精品资源，点击获取
)
