文章详情
以下为资讯详情页模板：正文区域由后台内容渲染，图片与正文将自动替换为对应文章内容。
简介来自北京大学相关团队的《DeepSeek提示词工程和产业应用》讲座资料面向教师、科研人员、程序员、管理者等各行业从业者系统讲解如何借助提示词工程充分释放DeepSeek推理模型在办公、教育、科研、代码开发等场景中的效率价值。资源收录为一份PDF共1个文件大小约18.66MB以图文并茂的课件形式完整呈现讲座章节。已有311人学习下载。内容从DeepSeek-R1的核心优势与推理过程可视化切入先分析其火爆原因再梳理直接使用官方入口、第三方通道与私有化部署的三种方式随后重点讲解提示词设计技巧、常见误读以及公文写作、教学设计、数据分析、编程开发等大量真实场景案例。即使不具备专业技术背景也可按图索骥快速上手将专家思维融入日常任务提升工作质量与产出效率。1. 提示词工程在推理模型上为什么“不灵了”这门课到底在讲什么拿到某高校这门课程材料之前我以为它讲的又是“怎么把需求描述得更清楚一点”的老生常谈。真正看完才发现核心命题完全相反DeepSeek 这类推理模型大规模进入产业之后提示词工程正在从“命令式”转向“约束式”而大多数团队手里的提示词还停留在指令模型时代——这就是为什么很多人觉得模型“变笨了”其实是提示词没跟上模型形态的变化。这门课围绕推理模型的应用场景与实践展开把提示词工程拆成了三个问题推理模型和指令模型在输入侧到底差在哪不同产业场景下提示词应该长成什么样以及进了生产环境之后参数、模板、验证体系该怎么搭。我结合自己在某公司做过的大小项目把课程里的思路落到可复现的模板和命令上。适合正在做对话产品、RAG、自动化流程或者准备把 DeepSeek 接进生产环境的工程师读。下面就直接进入正题。2. 推理模型为什么“不听话”与指令模型的差异决定了提示词写法2.1 推理模型的工作机制从“直接作答”到“内部推导”指令模型的训练目标是“接到指令直接给答案”模型会把注意力集中在匹配已有模式上而 DeepSeek 这类推理模型在架构上多了一层内部推导机制先形成一个推理过程再基于推理结果给出最终回答。这个过程会让模型在复杂任务上明显更稳但也会带来三个此前没遇到过的副作用。第一是输出长度显著变长。推理过程本身要消耗 token原本 500 字能答完的问题现在可能要占用 2 倍以上的输出长度。第二是采样策略对结果的影响变大了。同样的提示词、同样的参数多次调用结果可能漂移因为中间步骤的微小差异会被后续推导放大。第三是提示词里如果塞进了过多“格式约束”模型会机械地去填格子而不是先推理再作答反而打碎思维链。我在最初接 DeepSeek 的时候踩过最典型的一个坑把之前给指令模型用的提示词原封不动搬过来加了“请一步一步思考”之类的话术结果任务从 3 秒变成 30 秒答案质量反而没有提升。后来才明白推理模型本身就内置了推导能力用户侧的显式话术只会干扰它。下面用一个对比表来说明两代模型在输入侧的关键差异方便做团队技术选型的时候对齐认知维度指令模型偏好推理模型偏好输入粒度明确指令最好给出步骤明确目标与约束路径可自行推导格式要求对输出格式敏感模板越细越好过度格式化会压制推理链错误行为答非所问、套话推理被截断、结论丢失token 消耗低几百字内解决高需预留思维链空间失败信号输出含糊常见截断或结论与推理矛盾结论很直接提示词工程的注意力要从“告诉模型怎么答”挪到“告诉模型边界在哪”。这也是整门课给我最大的启发。2.2 提示词工程从“命令式”转向“约束式”三个法则法则一定义边界不定义路线。给模型明确的目标、输入范围、资源限制和可用的数据字段但不要告诉它“第一步必须排序第二步必须过滤”。推理模型需要自己找到路径你替它选路线往往会把它的推导强行拽回指令模型的套路里。我一般会这样组织提示词结构system_prompt 你是数据分析助手。你的任务根据用户提供的业务问题输出可执行的 数据分析方案。约束只能使用用户给定的字段如果字段不足以回答问题 必须列出缺失的数据不假设业务背景。 这里的关键是“不假设业务背景”六个字。推理模型一旦开始猜测就会生成一套漂亮的、但完全没有数据支撑的分析脚本。对产业场景来说这比“答错”更危险因为它的输出看起来太可信了。法则二写清“不能做什么”比写“要做什么”更能稳定输出。指令模型时代我们习惯用正向指令堆砌推理模型的提示词里失败条件和负向约束往往是效果提升最大的部分。比如“信息不足时明确回答无法判断”这句话可以挡住大量幻觉。法则三把验证写进提示词。让模型先给一段推理摘要再给最终结论。这样做的价值在于程序侧可以用简单的规则检查推理摘要和结论是否矛盾即使不接入复杂评测人也能快速定位是推理出错还是结论出错。response_format 你的输出必须包含两个部分 1. 推理摘要用 3 句话概括你的判断依据 2. 最终结论以列表形式输出。 若摘要与结论冲突结论部分不得出现推理中未提及的信息。 这三个法则几乎能覆盖所有产业场景。理解它们之后再看具体应用思路就清晰很多。3. 拆解四个产业应用的提示词设计推理模型能落地到什么位置3.1 数据分析场景把模糊业务问题翻译成可计算的推理链数据分析可能是 DeepSeek 推理模型在产业里最直接的应用。但业务方提的问题通常是“为什么这周转化率降了”这类模糊表达。推理模型需要的是一个可拆解的问题定义。我会在提示词里把问题拆成四层数据口径、对比窗口、影响因素、数据需求。analysis_prompt 业务问题{question} 请你完成以下步骤 1. 将业务问题拆解为可计算的数据分析子问题 2. 列出每个子问题所需的数据字段 3. 指出当前字段能否支撑分析若缺少关键字段明确写出缺失项 4. 只输出上述结构化内容不要直接给结论。 已知字段event_date, channel, uv, order_cnt, pay_amount 这段提示词的价值在于它把“回答一个问题”变成了“产出一个可执行的分析任务清单”。我在某公司落地时直接把模型输出的字段清单交给后续的数据脚本去执行把提示词作为任务定义的入口。效果比让模型直接写 SQL 稳定得多因为模型不接触真实数据就不会产生数据幻觉。需要注意一个参数这里 temperature 必须设置为 0 或接近 0。分析任务的答案有确定性任何随机性都会让字段清单不稳定。同时 max_tokens 要留足推理模型的思维链会占用大量输出空间我第一次调用时只给了 1024结果字段清单列到一半被截断后处理直接报错。3.2 文本抽取与结构化场景先分类再抽取避免字段遗漏文本抽取是最成熟的产业场景之一合同信息抽取、客服工单打标、供应链单据结构化。我见过不少团队直接给模型一个字段模板要求“填写所有字段”。这在指令模型时代还可以但在推理模型上会出现一类典型问题模型连文档类型都没判断对就开始填字段结果一整行数据全是错的。正确做法是让模型先判断文档属于哪个类型再按类型去匹配抽取模板。类型对了字段才有意义。我把这个思路写成下面的提示词模板extract_prompt 输入文档{content} 任务先判断文档类型合同/发票/工单/其他再按对应模板抽取信息。 规则 - 类型判断置信度低于 80% 时只输出“类型无法确定”不抽取字段 - 字段值必须能在原文档中找到依据不得推断 - 找不到的字段明确写“缺失”不允许编造 - 输出格式为 JSON。 这个提示词的核心是“先判断再抽取”。推理模型如果同时面对类型判断和字段抽取注意力会被“要不要做判断”消耗掉一旦类型错了后面的字段抽取就是连锁错误。加了“类型不确定就停止抽取”这条规则后模型的错误率明显下降代价是会有一部分输入无法自动化但这比产出错误数据要健康得多。另一个细节是 JSON 输出。推理模型在格式化上偶尔会丢括号或者加注释导致 json.loads 直接失败。我会在后处理里做一层容错先把模型输出的内容用正则截出第一个{到最后一个}之间的部分再解析能挡掉大部分低级错误。3.3 客服与决策辅助场景多轮记忆与上下文浓缩客服场景的难点从来不是单轮回答而是多轮一致性。推理模型的推理链在多轮对话里会累积偏移第三轮回复可能和第二轮的结论互相矛盾。原因是上下文窗口里的历史消息越长模型越难抓住关键前提。我用的提法是把每轮回答需要依赖的前提显式浓缩出来。multi_turn_prompt 当前对话上下文 {context_with_preconditions} 用户在上一轮的问题{last_question} 上一轮答复的关键结论{last_conclusion} 规则 1. 读了上一轮结论后再回答本轮问题 2. 如果本轮问题涉及的业务规则发生变化必须先声明变更再回答 3. 不要重复解释已经回答过的问题。 这套设计把“记忆”从模型的黑匣子变成了可审计的上下文。每个新轮次开始时程序先调用一次模型生成上一轮的结论摘要再拼入新提示词。这样模型不需要从头阅读几千字历史消息推理链被大幅缩短回答一致性也变好。代价是多了一次内部调用延迟会增加几百毫秒。对于客服这种延迟容忍度较高的场景完全可以接受如果是实时交互我会改为缓存上一层结论只有在新消息来时再触发一次摘要更新。3.4 RAG 问答场景让推理模型先判断证据足不足再判断怎么答RAG 是很多人第一个想到的应用方式但推理模型接 RAG 有一个特有的坑检索到的文档越多模型越容易被无关内容带偏。推理链会把噪声文档也纳入推导过程答案反而比不检索还差。我处理这个问题的方法是在提示词里显式增加一道证据判断关卡。模型在回答问题之前必须先判断检索内容是否覆盖了问题知识。如果覆盖不足直接输出“证据不足”而不是硬凑一个答案。这个判断本身就需要推理能力正好发挥 DeepSeek 这类模型的优势。rag_prompt 检索内容 {retrieved_chunks} 当前问题{question} 回答规则 1. 先对照检索内容判断“哪些块和问题直接相关” 2. 如果相关块不足以回答问题输出 {answer: 证据不足无法回答, missing: [需要的信息1, 需要的信息2]} 3. 如果证据充足直接基于相关块回答并在答案后引用块编号。 这段提示词把 RAG 的失败模式从“胡说八道”变成“明确说不知道”——这在企业知识库场景里是质的区别。丢了“证据不足”这个出口之后模型就从一个被迫作答的机器变成了一个会评估不确定性的助手。后处理也可以据此把“证据不足”的请求自动转人工形成一套干净的兜底链路。4. 把提示词搬进生产系统调用参数与最小可跑通的接口示例4.1 一个最小可运行的提示词调用代码课程讲的是方法论但要落地最终必须回到接口调用。我通常用 Python 加 requests 搭第一版调用不引入重依赖方便快速在测试环境验证。下面是一个与实际生产结构一致的最小示例import os import json import requests # 从环境变量读取配置避免在代码里写死密钥 endpoint os.environ[DEEPSEEK_ENDPOINT] api_key os.environ[DEEPSEEK_API_KEY] model os.environ[DEEPSEEK_MODEL] prompt 业务问题为什么本周订单转化率比上周下降 已知字段event_date, channel, uv, order_cnt, pay_amount 规则 1. 拆解问题为可计算的子问题 2. 列出每个子问题所需字段 3. 若字段不足明确指出缺失项。 payload { model: model, # 推理模型 ID以开通服务控制台为准 messages: [ {role: system, content: 你是数据分析助手只能基于给定字段推理。}, {role: user, content: prompt} ], temperature: 0, # 分析任务必须关闭随机性 max_tokens: 4096 # 给推理链预留足够空间 } resp requests.post( endpoint, headers{Authorization: fBearer {api_key}}, jsonpayload, timeout60 ) resp.raise_for_status() content resp.json()[choices][0][message][content] print(content)这段代码的逻辑很简单从环境变量读配置拼一个 system 加 user 的两轮消息请求推理模型拿到结果。但里面有三个细节值得说明。第一个是 system prompt 里写“只能基于给定字段推理”这等于把边界焊死防止模型自由发挥。第二个是 temperature 设置为 0数据分析任务存在唯一正确解随机性只会带来不确定性。第三个是 timeout 设置为 60 秒推理模型响应时间明显长于指令模型超时时间设置太短会把正常请求误杀。接口地址和模型 ID 会因服务商而异不要硬编码在代码里我习惯放在.env文件里用环境变量加载这样代码在测试和生产环境间迁移时不需要改动。4.2 生产环境必须调的三个参数推理模型的生产参数和指令模型很不一样。指令模型常用的 temperature0.7、top_p0.9 那套组合在推理模型上会放大中间推导的随机性。我直接给出生产环境我常用的参数基准参数推荐值影响什么时候改动temperature0越小输出越稳定需要创意输出时可调到 0.3但不要超过 0.5max_tokens4096~8192决定推理链是否被截断任务步骤多时调大简单任务可降到 2048top_p1与 temperature 联动仅在配合低 temperature 时微调一般不动streamtrue影响首字延迟交互场景开流式批处理关流式最常被忽略的是 max_tokens。很多人沿用指令模型的习惯只给 512结果推理模型输出思维链就直接把额度用完了结论部分被截断看起来就像“模型回答了一半”。我在部署客服系统时遇到过几次排查到最后才发现是 max_tokens 不够而不是提示词的问题。推理链路越长越需要给足输出空间。另一个容易踩的是 stream。推理模型的思维方式决定了它从开始输出到第一个 token 的间隔更长因为要先算推理链。如果产品要求极低首字延迟建议在流式输出时直接隐藏中间推理部分只向用户展示最终结论体验会好很多。4.3 提示词模板的版本管理从“随手改”到“可回滚”我在某公司做过一段时间提示词运维最大的教训是提示词就是代码不管理版本就是在给自己埋雷。业务方说“回答质量下降了”你打开线上配置发现提示词已经被改过十几轮根本不知道是哪一轮改坏的。我的习惯是把每个场景的提示词单独放一个目录用 git 管理prompts/ ├── analysis/ │ ├── v1.0_rule_based.md │ └── v1.1_add_missing_fields.md ├── extract/ │ ├── v0.9_initial.md │ └── v1.0_classify_first.md └── README.md命名规则是“版本号 改动摘要”。每次上线前都要记录这次改了什么、为什么改、影响哪个场景。排查问题时先用 git diff 看近期改动再结合线上效果做回归基本能在十分钟内定位到问题版本。版本管理还有一种做法把提示词模板存到数据库或配置中心带上生效时间。但如果团队还没有配套体系先从 git 开始成本最低效果也最直接。提示词质量不应该是靠“感觉”去维护的黑匣子它应该和生产代码一样有历史、有回滚点、有评审流程。5. 避坑提示词工程在推理模型上最容易翻车的五个场景5.1 现象加了“请一步一步思考”输出反而变差不少团队把指令模型的提示词原样迁移过来加一句“请一步一步思考”。结果模型的输出开始大量重复推理过程结论质量不升反降。原因推理模型本身就内置了思维链显式要求会让模型重复推导甚至把“思考”变成一种输出表演消耗 token 却没有增加信息量。解决去掉这类话术改用约束式提示词把重心放在“目标、边界、失败条件”上。如果想让模型输出推理摘要改成“先用 3 句话概括你的判断依据”而不是要求它思考。5.2 现象输出被截断结论只写了一半线上反馈“答案到一半就断了”第一反应往往是网络问题或超时实际排查后发现在提示词和参数层面。原因推理模型的思维链占用了大量 max_tokens传统设定在 512 到 1024 的输出额度根本不够用模型把额度花在推理过程里结论还没来得及输出就被截断了。解决调大 max_tokens推荐至少 4096。另一个办法是把输出结构改为“先结论、后推理”让结论先落袋就算截断也不会丢失最核心的信息。5.3 现象同样的提示词多次调用结果不一致测试环境同一个问题反复调用答案时好时坏看起来像玄学。原因推理模型的采样在思维链每一步都会累积随机性Temperature 稍高一点中间步骤选择的分支不同最终结果差异就被放大。解决关键场景把 temperature 设成 0。仍然漂移时可以跑 3 到 5 次采样取投票结果但生产环境更推荐用后置规则校验而不是靠多次调用来拼概率。5.4 现象RAG 检索到的文档越多答案越乱接 RAG 之后发现答案质量不是随检索数量单调提升反而在 5 段以上开始变差。原因无关检索片段被推理模型纳入推导路径噪声变成了逻辑链条的一部分。检索越多混入的无关信息概率越大模型把不相关的内容也当作依据。解决提示词中写明“先筛选相关块再基于相关块回答”同时在检索侧做相关性打分低于阈值的片段直接不进上下文。两道过滤之后答案稳定性会明显改善。5.5 现象字段抽取出现幻觉一个字段被重复输出多次合同抽取任务里同一个“签署日期”字段出现了两个不同值。原因模型在尝试“填模板”而不是从原文定位答案。当上下文里有多处相似信息时推理模型可能会把不同位置的取值都填进去不做一致性校验。解决提示词中允许模型输出“缺失”而不是强行填值后处理增加去重规则对同一字段的多个取值按置信度排序。这属于提示词和程序双重兜底。6. 验证提示词质量从“看着对”到“批量回归”提示词上线前光靠人工测几条样例是不够的。我在某公司经历过一次线上翻车后养成了一个习惯任何提示词改动都必须跑一遍回归集。回归集不用很大每个场景准备 20 到 50 条典型输入覆盖正常、边界、失败三类情况就足够拦住大多数质量问题。做法是写一个轻量评测脚本用另一个通用模型做裁判评分。裁判模型不参与业务只负责对比“预期答案”和“实际输出”的语义一致性。评分标准用百分制80 分以下直接拦截上线。脚本结构大致是这样judge_prompt 你是评审员。请对比参考答案与模型输出是否在核心信息上一致。 参考答案{reference} 模型输出{prediction} 评分标准核心信息一致给 90-100部分缺失给 60-80 完全无关给 0-50。只需输出分数。 for case in test_cases: prediction call_business_model(case.input) score float(call_judge(judge_prompt, case.reference, prediction)) if score 80: report.append({case: case.id, score: score})这套流程跑起来之后提示词改动就不再依赖“我觉得没问题”。我自己的习惯是每次改完提示词先跑回归再对比线上日志里的真实请求分布补测试集。补测试集这个动作很关键因为产业场景的输入永远比测试集复杂只有不断把线上踩到的案例回填到回归集里提示词质量才会螺旋上升。这门课没有给出“万能模板”但它把一句话讲透了推理模型的提示词工程核心是定义问题和约束而不是指挥模型怎么思考。这门课里的边界思维帮我解决掉了早期的大部分事故。希望帮到你。本文还有配套的精品资源点击获取特别提醒：考试时间、报名批次等安排如有调整，以河南省应急管理厅及官方考点最新通知为准。
