简介:这份PPT源自北京大学DeepSeek系列研讨活动,由北大青鸟人工智能研究院、计算机学院元宇宙技术研究所、教育学院学习科学实验室联合打造,面向希望快速上手DeepSeek的普通用户与产业从业者,聚焦提示词工程与落地场景两大核心模块。内容系统梳理了DeepSeek火爆背后的能力突破、开源、低成本与国产化四大动因,拆解DeepSeek-R1将模型思考过程可视化的首创优势,并给出官方APP、网页端与API三种直接使用路径,同时直面市场对提示词的常见误读,通过简单有效的技巧将专家思维代入教育、金融、医疗等垂直领域及日常生活场景。资源包内含1个pptx文件,约808KB,结构清晰、图文并茂,便于按目录模块检索学习。目前已有376人学习下载,适合无需技术背景即可掌握AI提效路径的读者参考。
1. 从一份疯传的 PPT 说起:提示词工程到底在解决什么问题
最近技术群里反复出现一份名为“DeepSeek 系列-提示词工程和落地场景”的 PPT,来源标注为某高校 AI 团队 2025 年 2 月的内部研讨资料。我花了一个周末把它拆完,发现它真正有价值的地方不是讲 DeepSeek 有多强,而是把“提示词工程”从玄学拉回到了可复现的工程方法。很多人用 DeepSeek-R1 觉得时好时坏,本质上是把推理模型当传统生成模型在用,提示词结构完全没变。这份资料的核心贡献在于:它明确区分了 R1 这类推理模型和传统指令模型的交互差异,并给出了一套可以直接套用的提示词公式。如果你正在做 AI 应用落地、企业内部提效,或者单纯想让 DeepSeek 的输出稳定可控,这份 PPT 里的方法论值得逐页拆解。它适合没有算法背景但需要快速上手的从业者,也适合已经踩过“提示词写了跟没写一样”这个坑的老手回头补课。
2. DeepSeek-R1 的推理模型特性与提示词设计逻辑
2.1 为什么 R1 的提示词不能照搬 GPT 那套
DeepSeek-R1 和传统生成模型最大的区别在于它把思考过程可视化了。你在网页端或 APP 里开启“深度思考”后,会看到模型先输出一段推理链,再给最终答案。这个机制直接影响了提示词的写法。传统模型你给一个模糊指令,它靠概率补全给你一个看起来合理的回答;R1 会先拆解你的问题,如果问题本身结构混乱,它的推理链就会跑偏,最终答案自然不可控。
PPT 里反复强调一个观点:R1 是推理模型,不是知识问答模型。这意味着提示词的重点应该从“告诉它答案长什么样”转向“告诉它怎么想”。我实测下来,同样的任务,给 R1 一个结构化的思考框架,输出质量比给一堆示例(few-shot)还要稳。因为 R1 的强化学习训练阶段本身就在优化推理路径,你顺着它的机制走,效果立竿见影;你逆着来,它就会在推理链里反复绕圈。
2.2 提示词通用公式的四个变量拆解
PPT 里给出的通用公式我整理成了可操作的四个变量:任务、对象、目标、顾虑。这四个变量不是随便列的,它们对应了 R1 推理链的四个锚点。
| 变量 | 作用 | 缺失后的典型翻车现象 |
|---|---|---|
| 任务 | 定义模型要做什么 | 模型自行脑补任务范围,输出跑题 |
| 对象 | 定义输出给谁看 | 语气、术语层级错位,专业内容过于口语化 |
| 目标 | 定义期望效果 | 输出平庸,没有重点,像百科词条 |
| 顾虑 | 定义要避免的问题 | 模型踩中你没想到的雷区,比如格式错误、遗漏关键约束 |
我拿一个实际场景验证过:让 R1 写一份技术周报。如果只写“帮我写周报”,它会给你一篇泛泛而谈的流水账。加上四个变量后,提示词变成“帮我写一份给技术总监看的数据平台周报,重点突出本周上线的三个模块的性能提升数据,避免写成流水账,不要超过 500 字”。输出质量直接上了一个台阶,推理链里能看到它在主动筛选哪些数据值得放进去。
2.3 把“内心戏”写进提示词的操作方法
PPT 里有个很妙的说法叫“内心戏”,其实就是把你在真实工作里会跟同事交代的隐含信息显式化。比如你让同事帮你做个方案,你不会只说“做个方案”,你会说“老板很看重成本,上次那个方案就是因为预算超了被毙了,这次注意点”。这些背景信息就是“内心戏”。
对 R1 来说,内心戏尤其重要,因为它的推理链会把这些约束条件纳入思考。我一般会按这个模板来写:
任务:帮我整理一份竞品分析摘要 对象:给产品经理看,他关注功能差异和定价策略 目标:输出三个竞品的核心差异点,每个点配一句结论 顾虑:不要罗列功能清单,不要写没有数据支撑的判断 背景:上次的分析因为太泛被退回,这次需要直接可用的结论代码块里最后一行“背景”就是内心戏。加上之后,R1 的推理链会明显更聚焦,输出里“可能”“大概”这类模糊词会少很多。这个技巧在 PPT 里被归为“真诚+直接”原则,说白了就是别跟模型客气,把真实约束条件摆出来。
3. 三种直接使用路径的选型与配置实操
3.1 网页端、APP 与 API 的适用边界
PPT 里把直接使用 DeepSeek 的方式分成了三类:官方网页、官方 APP、API 调用。这三条路径不是随便选的,各有明确的适用边界。
网页端适合深度交互场景,比如写长文档、做复杂分析、需要反复调整提示词。它的优势是能看到完整的推理链,方便你判断模型是在哪个环节跑偏的。APP 适合碎片化场景,比如通勤路上快速查个资料、语音输入一个灵感。API 适合集成到现有工作流里,比如自动生成日报、批量处理文本。我自己的习惯是:探索性任务用网页端,确定性任务用 API,临时记录用 APP。
PPT 里还提到了第三方通道,比如国家超算平台、硅基流动、纳米 AI 搜索等。这些通道的价值在于提供备用访问路径,但提示词技巧是通用的,换通道不影响方法论本身。
3.2 API 调用的最小可用配置
如果你要走 API 路线,最小可用配置其实很简单。以下是一个 Python 示例,用的是 OpenAI 兼容格式,DeepSeek 官方 API 支持这种调用方式:
from openai import OpenAI client = OpenAI( api_key="你的 API Key", # 从 DeepSeek 平台申请 base_url="https://api.deepseek.com" # 官方接口地址 ) response = client.chat.completions.create( model="deepseek-reasoner", # 推理模型用这个标识 messages=[ {"role": "system", "content": "你是一个严谨的技术文档助手,输出前先梳理逻辑框架。"}, {"role": "user", "content": "帮我写一段关于数据清洗流程的说明,给新人看,避免用太专业的术语。"} ], temperature=0.3, # 推理任务建议低温度,减少随机性 max_tokens=2000 ) print(response.choices[0].message.content)这段代码的关键参数是model和temperature。deepseek-reasoner对应 R1 推理模型,temperature设到 0.3 左右能让推理链更稳定。如果你用的是蒸馏版模型(比如 7B、14B),模型标识要换成对应的名称。PPT 里列了一张蒸馏模型对照表,我整理成下面这个简版:
| 蒸馏模型 | 基础模型 | 适用场景 |
|---|---|---|
| DeepSeek-R1-Distill-Qwen-7B | Qwen2.5-Math-7B | 本地轻量推理,显存要求低 |
| DeepSeek-R1-Distill-Qwen-14B | Qwen2.5-14B | 平衡性能与资源,适合开发机 |
| DeepSeek-R1-Distill-Qwen-32B | Qwen2.5-32B | 接近满血效果,需要较大显存 |
| DeepSeek-R1-Distill-Llama-70B | Llama-3.3-70B-Instruct | 高精度场景,生产环境部署 |
选型逻辑很简单:显存够就上大的,显存紧就上小的,但提示词公式不变。我见过有人用 7B 蒸馏模型跑出了比满血版更稳定的输出,原因就是提示词写得足够结构化,小模型也能顺着推理链走。
3.3 私有化部署的提示词适配要点
PPT 里提到了 Ollama 和 vLLM 两种私有化部署方式。Ollama 适合个人本地快速拉起,vLLM 适合生产环境。私有化部署后,提示词需要做一点适配:因为本地模型的推理能力通常弱于满血版,你需要把提示词写得更“手把手”一些。
比如同样一个任务,在满血版上你可以写“帮我分析这份数据”,本地 7B 模型上最好写成“请按以下步骤分析这份数据:第一步,统计各列缺失值;第二步,计算数值列的均值和标准差;第三步,用一句话总结数据质量”。步骤拆得越细,小模型越不容易跑偏。这个经验在 PPT 里没有明写,但我在实际部署中反复验证过,算是血泪经验。
4. 垂直场景落地的提示词模板与参数调优
4.1 把专家思维拆成可复用的提示词结构
PPT 里有一个核心观点:提示词工程的本质是把领域专家的思考方式翻译成模型能执行的指令。比如一个资深市场分析师看报告,他会先看数据来源是否可靠,再看结论是否有数据支撑,最后看有没有遗漏关键变量。这个思考顺序就可以直接写成提示词。
我按这个思路整理了一个通用模板:
你是一位有十年经验的[领域]专家,请按以下思考顺序处理任务: 1. 先判断输入信息的完整性和可靠性,如果有缺失请指出 2. 再按[具体分析框架]逐项分析,每项给出结论和依据 3. 最后检查是否有遗漏的关键因素,如果有请补充 输出格式:[具体格式要求] 避免:[具体要避免的问题]这个模板的好处是把专家的“检查清单”显式化了。R1 的推理链会跟着这个顺序走,输出自然就有结构感。PPT 里给的旅游攻略案例其实就是这个逻辑:先考虑父母体力,再考虑城市间交通,最后检查每个景点是否适合老人。这个思考顺序不是模型自己悟出来的,是提示词里写清楚的。
4.2 温度、Top-P 与最大长度的联动调整
很多人调 API 只改 temperature,其实 Top-P 和 max_tokens 也要联动。我一般按任务类型分三档:
| 任务类型 | temperature | top_p | max_tokens | 说明 |
|---|---|---|---|---|
| 推理分析 | 0.2-0.4 | 0.9 | 2000-4000 | 低温度保证推理链稳定 |
| 创意生成 | 0.7-0.9 | 0.95 | 1000-2000 | 高温度增加多样性 |
| 格式转换 | 0.1-0.2 | 0.8 | 按输出长度定 | 极低温度保证格式严格 |
PPT 里没有展开讲这些参数,但我在实际调优中发现,推理任务把 temperature 设到 0.5 以上,推理链里会出现明显的“犹豫”现象,比如反复推翻自己的结论。降到 0.3 以下就稳很多。这个边界值不是绝对的,但方向是对的:推理模型要稳,生成模型要活。
4.3 多轮对话中的上下文管理技巧
R1 的上下文窗口有限,多轮对话时如果历史消息太长,推理质量会下降。我一般用两个策略:一是每轮对话结束后,把关键结论手动摘出来作为下一轮的系统提示;二是用“继续”类指令时,把上一轮的核心约束重新贴一遍。
比如第一轮让 R1 写了个方案框架,第二轮想让它填充细节,不要直接说“继续”,而是说“基于上一轮的方案框架,现在填充第二部分的技术实现细节,保持之前的格式和术语风格”。这样模型不需要从历史消息里重新提取约束,推理链会更短更准。PPT 里提到的“清晰表达”原则,在多轮对话里就体现为主动帮模型减负。
5. 避坑与排查:提示词工程里最容易翻车的五个地方
5.1 把 R1 当传统模型用,提示词里塞大量示例
现象:写了五六个 few-shot 示例,输出反而更差,推理链里出现“根据示例推断”之类的表述。
原因:R1 的推理机制是基于规则和逻辑的,不是基于模式匹配的。大量示例会干扰它的推理路径,让它误以为你要的是模仿而不是分析。
解决:推理任务最多给一个示例,或者干脆不给示例,改用步骤描述。把“像这样写”改成“按这个逻辑写”。
5.2 提示词里堆砌形容词,缺少可执行约束
现象:输出看起来很华丽,但落地时发现关键数据缺失、格式不对、长度超标。
原因:形容词是主观的,模型无法量化。“专业一点”“详细一些”对模型来说没有操作意义。
解决:把形容词换成可检查的条件。不说“详细”,说“每个结论配一个数据支撑”;不说“专业”,说“使用行业标准术语,避免口语化表达”。
5.3 忽略推理链的中间输出,只看最终答案
现象:最终答案有问题,但不知道哪里错了,只能反复重写提示词。
原因:R1 的推理链是调试提示词的最佳入口。推理链跑偏了,最终答案一定有问题;推理链对了,答案即使不完美也能快速定位。
解决:每次输出不理想时,先看推理链的前三步。如果前三步就偏了,说明任务定义有问题;如果中间偏了,说明约束条件不够;如果最后偏了,说明输出格式没写清楚。
5.4 多轮对话不清理上下文,导致约束漂移
现象:第一轮说“不要超过 500 字”,第三轮输出变成 2000 字。
原因:多轮对话中,早期约束会被后续消息稀释。模型在长上下文里会优先关注最近的消息。
解决:每轮对话把核心约束重新贴一遍,或者用系统提示固定约束。我一般会在第三轮之后主动开新对话,把关键结论带过去。
5.5 私有化部署后直接套用满血版提示词
现象:本地 7B 模型输出质量断崖式下降,推理链经常断掉。
原因:小模型的推理能力有限,满血版能理解的抽象指令,小模型理解不了。
解决:把提示词拆成更细的步骤,每一步都给出明确的输入输出要求。抽象指令换成具体操作,比如“分析数据”换成“计算均值、中位数、缺失值比例”。
6. 进阶技巧:用提示词链把复杂任务拆成流水线
当你需要 R1 完成一个多阶段任务时,单条提示词往往力不从心。我常用的方法是提示词链:把任务拆成三个独立阶段,每个阶段用一条专门的提示词,上一阶段的输出作为下一阶段的输入。
以“写一份竞品分析报告”为例:
第一阶段,信息提取。提示词聚焦在“从给定材料中提取竞品名称、核心功能、定价策略、目标用户”,输出结构化 JSON。
第二阶段,对比分析。把第一阶段输出的 JSON 作为输入,提示词聚焦在“按功能完整度、价格竞争力、用户匹配度三个维度做对比,每个维度给出评分和依据”。
第三阶段,报告生成。把第二阶段的分析结果作为输入,提示词聚焦在“生成一份给产品总监看的报告,先给结论,再给支撑数据,最后给建议,不超过 800 字”。
# 提示词链的伪代码示意 stage1_prompt = "从以下材料中提取竞品信息,输出 JSON 格式:{材料}" stage1_output = call_deepseek(stage1_prompt) stage2_prompt = f"基于以下竞品信息做三维度对比分析:{stage1_output}" stage2_output = call_deepseek(stage2_prompt) stage3_prompt = f"基于以下分析结果生成报告:{stage2_output}" final_report = call_deepseek(stage3_prompt)这个链条的好处是每个阶段的任务足够单一,R1 的推理链不会因为任务太复杂而跑偏。而且中间输出可以人工检查,哪一步出了问题就调哪一步的提示词,不用从头重来。
验证方法也很简单:把最终报告和原始材料对照,看关键数据有没有遗漏,结论有没有数据支撑。如果发现某个维度的分析偏了,回溯到第二阶段,检查对比维度的定义是否清晰。我一般会在第二阶段加一个自检指令:“请检查以上分析是否覆盖了所有竞品,如果有遗漏请补充”,这样能拦住大部分低级错误。
从那以后我每次做复杂任务,都强制走一遍提示词链,哪怕多花十分钟拆步骤,也比反复重写一条大提示词要省时间。希望帮到你。
本文还有配套的精品资源,点击获取