简介《北京大学DeepSeek系列提示词工程和落地场景》PPT来自北大校内专题研讨面向零基础及进阶用户帮助大家通过自然语言交互用好DeepSeek掌握提示词工程核心方法。资源为1个pptx演示文稿压缩包大小808KB内容精炼已有376人学习浏览。讲座系统拆解DeepSeek-R1的显著优势——全球首创将模型思考过程可视化推理能力跻身全球第一梯队复杂推理任务可精准处理并从开源、低成本、国产化三大维度分析其火爆原因全量开源训练代码与数据清洗工具、训练成本仅约557万美元、推理成本降低83%大幅推动AI普惠。同时给出官方APP、网页端、API调用三种直接使用方式并针对教育、金融、医疗等垂直领域结合生活场景演示提示词技巧让专家思维赋能日常学习与工作。还延伸介绍了Ollama/vLLM私有化部署及蒸馏模型帮助读者突破工具表层应用实现人机智能融合。1. DeepSeek 提示词工程先看懂这份课件在帮你解决什么问题拿到《北大-DeepSeek系列-提示词工程和落地场景》这份材料的人大多已经不再是DeepSeek 是什么的阶段而是卡在一个更难受的位置同样一个需求别人写提示词能一次出可用结果自己写出来的回复总是偏、散、不像样。这不是模型不行也不是你运气差而是提示词工程这个环节还没成型。这个标题背后其实是一整套关于怎么和 DeepSeek 对话的方法论——不是让你背模板而是让你理解模型的行为偏好再把业务需求翻译成它听得懂的结构。它解决的痛点是API 调用能通、APP 能聊但距离稳定产出可用结果还差一层提示词设计。适合正在把 DeepSeek 接进文档问答、代码辅助、内容生成流程里的开发者或产品运营。2. 深挖 DeepSeek 的推理偏好提示词工程的第一个分水岭2.1 为什么 DeepSeek 是逻辑先行的模型做提示词工程之前先得接受一个前提DeepSeek 是推理能力很强的模型它不是聊天机器人式的有问必答而是更像一个你给足约束它就给你推演的引擎。这个特性决定了提示词的写法基调——你给它模糊的指令它会把模糊当成自由发挥的空间你给它明确的规则它才愿意收敛在规则里。我一般在写 DeepSeek 提示词时会先用一句话给自己定调这条提示词是不是让模型不需要猜如果模型还需要猜你的真实意图那问题不在模型在提示词。比如你直接写帮我写个 Python 脚本它确实会写但版本、依赖、异常处理全靠它心情。换成写一个 Python 3.10 的脚本功能是批量重命名目录下所有 .txt 文件文件名前缀改为 meeting_保留原文件名后四位遇到重名自动加 _1它产出的代码就接近能直接跑的成品。这就是推理型模型和通用模型的区别它吃结构不吃情绪。还有一个容易被忽略的参数维度temperature。DeepSeek 这类模型在低温下推理更稳在高温下创造力更强。落地到生产环境我通常把 temperature 压到 0.3 以下甚至 0.1只有做头脑风暴、文案变体这类场景才拉到 0.7 以上。提示词工程不是只在文本上做文章参数本身也是提示词的一部分。你写的提示词越含糊温度参数造成的随机性就越致命——同一个问题今天答得对明天答得偏你还以为是模型抽风其实是温度太高加上指令太宽。2.2 角色、任务、输出格式提示词的三件套结构把一份能稳定工作的提示词拆开看里面几乎都有三块内容角色设定、任务描述、输出格式约束。这三块不是可选项是地基。角色设定是给模型划定知识范围和语气基调任务描述是告诉它现在要做什么、输入是什么、约束是什么输出格式约束是把它从长篇大论拉到可以对接程序的轨道上。我一般落地时会把三者拼成一个标准结构化模板类似这样system_prompt 你是一位资深 Python 后端工程师擅长代码审查与性能优化。 请基于以下规则完成任务不要输出任何与任务无关的内容。 【任务】 审查用户提供的代码找出潜在 bug、安全隐患和性能问题。 【输入】 代码片段 {code_snippet} 【输出要求】 以 JSON 格式返回字段如下 {{ issues: [ {{severity: high|medium|low, line: 行号或函数名, description: 问题描述, suggestion: 修改建议}} ], summary: 整体评价不超过 50 字 }} 这个结构的核心在于角色设定让模型自动带入资深工程师的经验库任务描述把审查动作拆成一个明确指令输出要求则把结果锁死成程序可以解析的 JSON。我在实际项目里反复用这套结构发现它的容错率远高于帮我看看这段代码有什么问题这种口语化指令——因为模型不需要判断你要什么只需要执行。参数上还有两个点值得注意。第一temperature在有固定输出格式要求时建议调到 0.2 以下否则 JSON 格式偶尔会给你漂出多余字段。第二如果用了max_tokens要估算好输出长度——JSON 结构本身就消耗 token设太短会导致截断截断后的 JSON 基本没法用。我一般给这种结构化任务留出比实际需要多 20% 的 token 余量。2.3 少样本示例与思维链用对了是杠杆用错了是噪音提示词工程里有两个经常被过度使用的技巧少样本示例few-shot和思维链chain-of-thought。先说少样本。给 DeepSeek 提供 1 到 2 个输入-输出示例能有效稳定输出风格尤其是格式敏感的生成任务。但也有副作用示例里的瑕疵会被模型当成风格参考放大比如你在示例里漏了一个字段它可能每条结果都漏。我通常只在格式复杂、语言风格要求高的场景里放示例而且每个示例都是经过验证的标准答案不放未经检查的手写样例。思维链则要更小心。DeepSeek 本身有较强的推理能力你在提示词里写请一步一步思考它确实会给你展示推理过程——但这个过程消耗大量 token且在某些 API 实现下推理过程可能混入最终输出导致你要的结果里夹着嗯让我想想这类中间产物。我的做法是默认不显式要求思维链只在复杂数学、多条件判断场景里用先列出约束条件再给出结论的句式做轻量引导。比如写请先根据以下条件逐条判断再输出最终结论而不是请深入思考每一个细节——前者是给推理路径后者是鼓励废话。这里还有一个常见误用把 ChatGPT 时代的提示词习惯直接搬给 DeepSeek。早期很多提示词教程强调扮演一个什么都懂的专家这类角色设定在 DeepSeek 上依然有效但要注意它同样会放大模型的表演欲——角色越宏大输出越有可能脱离实际任务。提示词工程的核心是约束不是激发。你要做的不是让模型搜肠刮肚而是让它在一个明确的小范围内做出最优解。3. 落地场景拆解从 API 调用到业务逻辑的接入路径3.1 用系统提示词搭建 API 调用的稳定基线提示词工程的第一个真实落地场景就是 API 对接。不管你是接官方接口还是通过 Codex、Claude Code 这类工具做模型托管最终的请求结构都是一样的system层放全局规则user层放具体输入assistant层放历史或示例。很多人只往user里塞内容把system留空这是一个巨大的浪费——system是唯一能全程约束模型行为的位置它不在单次对话里被稀释。我一般会这么组织一次完整的调用import requests payload { model: deepseek-chat, temperature: 0.3, max_tokens: 1024, messages: [ {role: system, content: ( 你是企业内部的文档助手。 只依据用户提供的资料回答资料中没有的信息 明确回复资料中未提及不要自行推测。 回答控制在 200 字以内使用中文。 )}, {role: user, content: 以下是资料{doc_text}\n\n问题{question}} ] } resp requests.post(https://api.deepseek.com/chat/completions, jsonpayload)这段代码里有三个值得留意的设计。第一system文案第一句是你是企业内部的文档助手这是角色场景的双重约束比单纯你是助手更具体能显著减少模型泛泛而谈的倾向。第二资料中没有的信息明确回复资料中未提及——这句在文档问答场景里几乎是保命条款它把幻觉问题变成了一个格式规则。第三temperature: 0.3是文档问答场景的常用取值太低会导致回复机械重复太高会导致回答偏离原文。参数上还要注意max_tokens与文档长度的关系。如果doc_text很长超过上下文窗口的一半回答质量会明显下降——不是模型不聪明是前面的长文本挤压了注意力资源。常见做法是先在本地做切片只把与问题最相关的一段文本拼进user消息而不是一股脑全丢进去。切片策略一般分两步先把文档按段落或固定长度切块再用关键词或向量相似度召回 Top 3 块拼成最终输入。3.2 文档问答场景上下文拼接与引用格式的讲究文档问答是提示词工程落地价值最高的场景之一但它远不是把文档丢进去提问那么简单。真正决定输出质量的是三件事上下文怎么切、提示词怎么约束引用、答案怎么兜底。上下文切块时我通常会带上段落标题一起切。原因是 DeepSeek 特别擅长捕捉文本间的逻辑关系如果你只给 Model 一段孤零零的正文它能读但不知道这段在整篇文档里属于哪个篇章回答时就会缺少层级感。做法是切块时把## 章节名和### 小节名作为前缀拼进块内容。这个细节对长文档效果提升非常明显有时比调整提示词还有用。引用格式方面我一般会在system里写明回答中涉及资料里的具体数字、日期、结论请在括号内标注来源段落编号。这个要求看起来很机械但它能强制模型在生成时回到原文去对位而不是凭印象创作。你甚至可以更进一步要求它输出答案时附带source_id字段方便前端做标注。这本质上是在用格式约束降低幻觉概率比在提示词里反复喊不要胡说有效得多。兜底策略同样重要。无论提示词写得多好DeepSeek 偶尔还是会碰到资料里根本没有答案的问题。我的处理方案是在user消息里固定加一句如果问题无法由上述资料回答请直接回复信息不足不要尝试推断。这不是防御性废话它在模型推理路径上设置了一个合法的退出通道——有通道在模型就不需要靠编造来完成任务。这个技巧我在多个项目里用过直接把无意义输出率降低了将近一半。3.3 代码生成场景把规则设定写进提示词而不是口头约定另一个高频落地场景是 AI 辅助写代码。这里的提示词工程难点已经不在让模型写出代码而在让模型按你的工程规范写代码。很多人遇到的问题是模型写的代码能跑但命名风格、错误处理、日志规范和团队标准完全不一致拿回来还是得改一遍。解决办法是提前在提示词里铺设规则设定模块。比如团队要求所有函数都必须带类型注解、所有网络请求必须有超时和重试、所有日志必须用结构化字段。这些规范不用等到代码评审时发现全部可以写进系统提示词CODE_RULES 编码规范必须遵守: 1. 所有函数必须使用 Python 3.10 类型注解 2. 所有文件读写必须使用 with 语句禁止裸 open() 3. 所有网络请求必须设置 timeout10且捕获 requests.exceptions.RequestException 4. 日志必须使用 logging.getLogger(__name__)格式为 JSON包含 event, duration_ms 字段 5. 禁止使用全局变量所有状态通过参数传递 请先输出完整代码再输出一个变更说明列表。 把编码规范以规则编号的方式写进提示词效果远好于请写出高质量的代码这种抽象要求。因为模型对高质量的理解是概率分布而对你明确列出的编号规则是精准执行。这套方法也呼应了标题里提示词工程和落地场景的深层关系——提示词不是几个人闲聊时的措辞发挥它本身就是可管理的工程配置。我在实际接入 DeepSeek 写代码的工作流里一般会把规则分成两层全局规则命名、格式、安全存在system里任务上下文这次要写什么功能、有哪些输入输出存在user里。这样下次换任务时只需替换user部分规则层始终生效成本和时间都省下来了。如果你考虑在 Codex、Claude Code 这类工具里接入 DeepSeek这套规则即提示词的思路同样适用——把工具的工作流配置当成提示词工程的一部分来设计效果比零散调教稳定得多。4. 提示词工程避坑手册四个最容易翻车的地方4.1 坑一把通用 Prompt 模板直接搬进 DeepSeek效果不升反降现象从网上找了一套号称万能的提示词模板替换模型名称后直接上生产结果输出风格诡异甚至出现了答非所问。原因模板里大量使用了针对某些模型的行为描述比如JSON 格式回复不要道歉请逐步思考等短语在 DeepSeek 的指令解析下会被当作强约束叠加执行反而干扰了它本身的推理模式。解决换模型必须重新校准提示词建议先删掉模板里所有模型行为修饰语只保留任务格式约束三要素跑通后再逐步加回确有必要的限定。4.2 坑二对话到达上限后换新会话上下文直接断片现象长对话进行到一半API 返回上下文长度错误你清空上下文开新对话继续问结果模型完全不记得之前讨论的变量名和需求约束重新解释好几轮还是对不上。原因对话上下文是一串连续的 tokens新会话意味着历史全部归零DeepSeek 不会替你记忆你需要在外面维护状态。解决开启新对话前把当前项目的关键决策、已确认的术语定义、待办事项压缩成一段会话摘要在下一次对话的system消息里直接注入。摘要不用长关键信息点列清楚即可这相当于你的上下文后悔药。4.3 坑三输出格式验证缺失让 JSON 变成黑匣子现象提示词里明明写了请以 JSON 格式返回程序偶尔还是解析报错一看返回结果里混入了好的下面是根据您要求生成的 JSON这类附带文字。原因模型对输出格式的理解是概率性的不是确定性的片头问候语是它在模拟人类沟通习惯时的残留行为。解决不要相信模型会自动遵守格式后端解析前加一道清理和校验。最稳妥的做法是要求只输出 JSON 本身同时在代码里做提取兜底——用正则捕获第一个{到最后一个}之间的内容再解析解析失败就标记重试。这个校验逻辑是提示词工程的收尾环节少了它会让你排查问题时完全摸不着头脑。4.4 坑四上下文里信息密度过低长文本把关键指令稀释掉了现象系统提示词里写了五条规则实际测试时前两条执行得很好后三条经常被忽略。你想加大 prompt 权重但 API 又不像搜索引擎允许额外加权。原因模型对提示词开头的注意力天然高于中后段规则排在后面会被长文本挤出有效处理范围。解决把最重要的规则往前放次要规则往后排如果规则太多拆成必须遵守和建议遵守两档模型对优先级词敏感这个分层会显著提升关键规则的执行率。5. 把提示词做成可维护的资产模板化、版本化与回归验证5.1 从写在聊天框里到放在配置里提示词模板化的三个层次提示词工程的进阶是从个人技巧变成团队资产。第一步就是模板化。常见做法是把系统提示词抽成独立的配置文件或数据库记录通过代码动态拼接。核心原因有两条一是提示词需要频繁迭代写死在代码里每次改动都要重新发布二是同一个组织内不同场景的系统提示词有大量公共部分——角色定位、安全红线、输出风格——这些应该复用而不是复制。我习惯把提示词拆成三层模板全局层放所有场景通用的安全规则和角色基调场景层放针对特定任务的指令比如文档问答、代码生成、内容改写各一份实例层放单次任务的具体参数比如输入文本、问题、目标语言。代码运行时按全局 场景 实例的优先级拼接最后一次组合成system和user消息。这样做的好处是你改一条全局规则所有场景的模型行为都会跟着变不再需要去每个场景里逐个编辑提示词。5.2 版本化与回归验证让提示词改动不再凭感觉提示词是逻辑代码不是情绪表达但它很容易被当成玄学来调——改几个词看看效果不行再改回来。这种工作方式在单人项目里还能忍一旦多人协作就会出现谁改的为什么改改完其他地方为什么崩了的惨案。解法是给提示词做版本管理和回归测试。具体做法不复杂。每个提示词版本分配一个版本号维护一份变更记录。回归测试则是一套固定的问题集——我一般准备 20 到 30 条覆盖各场景的代表性输入每次改动提示词后都拿同一份问题集去跑一轮对比新旧版本的关键指标。指标不追求完美固定看三件事有没有破坏格式要求、有没有偏离安全规则、输出长度是否在预算内。这比刚才试了一个感觉不错可靠得多也让你在团队里有据可依地说这版改动带来了什么变化。5.3 从单轮对话到工作流提示词不是全部分工才是必须承认一个边界提示词工程解决的是对话质量问题但很多落地场景的根本问题不是对话质量而是流程设计。比如自动生成报告的任务单靠一个精心设计的提示词让模型一口气产出完整报告成功率很低——因为报告涉及的章节多、逻辑层次复杂超出单轮上下文能承载的范畴。常见做法是把任务拆成多个子任务用工作流串起来第一步让模型根据资料生成大纲第二步逐章生成内容第三步汇总润色。每一步都有自己的 prompt也可以在不同步骤切换不同的参数配置。这个思路背后其实就是标题里落地场景的真正含义提示词工程不是孤立的文本游戏它必须服务业务流程。你在设计提示词时先问自己这个需求是单轮问答能解决的还是必须拆解成多阶段流水线对应地是追求单条 prompt 的完美还是追求各阶段 prompt 的衔接效率大多数失败案例都是把需要工作流的问题硬塞进单轮对话然后归咎于提示词没写好——这锅提示词不该背。6. 落地体检三个指标和一段校验代码评估你的提示词方案提示词写完了、场景也接上了怎么判断它到底行不行我有一个固定的体检流程用三个指标快速评估格式稳定率、关键约束命中率、单次调用成本。格式稳定率指返回内容能通过程序解析的比例关键约束命中率指规则里最核心的两三条是否在每次输出中都得到执行成本则通过 token 消耗估算。三个指标里前两个直接反映提示词质量第三个决定方案能不能规模化落地。体检代码可以做得非常轻我一般用一个 Python 脚本直接验证返回结果是否符合预期import json def validate_response(text: str) - dict: # 兜底提取最外层 JSON 对象 start, end text.find({), text.rfind(}) if start -1 or end -1: return {valid: False, reason: no_json_found} try: data json.loads(text[start:end1]) except json.JSONDecodeError as e: return {valid: False, reason: fjson_decode_error: {e}} # 核心约束检查必须包含 summary 字段且非空 if summary not in data or len(data[summary]) 0: return {valid: False, reason: missing_summary} return {valid: True, data: data}这段代码的逻辑是先做最简单的 JSON 提取兜底再验证必须有的字段是否存在。它不负责评估内容质量只负责判断这次输出能不能进下游流程。我通常会把同样的验证逻辑接进测试集循环里批量跑完所有样本后统计通过率。通过率低于 95% 的提示词版本不会放进生产环境——这是我做提示词工程的一条硬性红线。另外有一个成本侧的体检技巧每次调用后记录 token 使用量和耗时积累一段时间后按场景画一条基线。如果某个场景的 token 消耗比同类场景高出一倍大概率是提示词里塞了太多不必要的背景信息。这时候不是继续调 prompt 措辞而是去压缩上下文——把废话删掉、把示例减少、把不需要的 role 描述去掉。提示词工程的最后一公里往往发生在删减而不是堆砌的时刻。这套方法我用了很久最大的教训是不要迷信某个大神的超强提示词任何提示词都要跑过自己的数据才算数。模型在升级、业务在变化提示词方案不是一劳永逸的答案而是一套需要持续维护的资产。希望这篇文章能帮你把 DeepSeek 的提示词工程从玄学拉回到工程让你接下来的每次落地都少一点翻车、多一点确定性。本文还有配套的精品资源点击获取