简介：《北京大学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", json=payload)这段代码里有三个值得留意的设计。第一，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. 所有网络请求必须设置 timeout=10，且捕获 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:end+1]) except json.JSONDecodeError as e: return {"valid": False, "reason": f"json_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 的提示词工程从"玄学"拉回到"工程"，让你接下来的每次落地都少一点翻车、多一点确定性。
本文还有配套的精品资源，点击获取
