简介这份由北京大学相关机构联合出品的讲座材料为PDF格式面向程序员、教师、科研人员、管理者等不同行业人士旨在解决如何借助推理大模型完成公文写作、教学设计、数据分析、编程开发等日常任务的提效问题。文档聚焦深度求索模型的核心优势如推理过程可视化、低成本与开源生态不仅分析了其火爆原因涵盖能力突破、开源共享、低成本与国产化加持还系统梳理了直接使用的三种方式、提示词工程常用技巧及常见误区并结合教育、学术、专业工作、医疗保健等领域的真实案例展开说明。整个资源为单份PDF文件压缩包大小约18.66兆字节内容完整便于阅读保存。目前已有三百一十一人学习下载。读者通过这套整理既能理解深度求索模型的推理机制与调用路径包括官方接口、第三方平台及私有化部署又能获得多个垂直场景的提示词示例和配套学习指引快速迁移到实际工作与学习中。1. DeepSeek 提示词工程到底在解决什么推理模型不是更聪明的对话模型把之前给对话模型的提示词原样搬到 DeepSeek 推理模型上第一天上线就翻车——响应变慢只是小事更要命的是模型开始把“分析过程”打印进回答客户看到的是一堆“首先、其次、综上”的内心戏。后来我把提示词从八百字砍到一百二十字只留任务、边界、输出格式效果反而变好了。这件事让我意识到提示词工程在推理模型这里换了一套规则以 DeepSeek 为代表的推理模型把“思考”内化到了参数里用户要写的是任务边界不是思考步骤。北京大学那份《DeepSeek 提示词工程和产业应用》公开材料主线就是把推理模型的应用场景和落地实践讲清楚。这篇内容沿着同一条主线展开适合三类人正在把 deepseek-reasoner 接进业务后端的开发带产品需要评估推理模型成本与效果的负责人以及被 Agent 工具链折磨、想搞清提示词和 skill 到底怎么分工的从业者。后面的内容不聊空概念全部是能直接抄的写法、参数和排错经验。2. 推理模型与对话模型的提示词边界为什么“请一步步思考”会翻车2.1 推理模型的工作机制思维链从提示词搬进了模型内部要搞清楚提示词怎么写得先清楚这代推理模型reasoning model和上一代对话模型chat model在生成机制上的差别。对话模型是“看到问题直接给答案”你给它什么指令它按指令组织语言。所以过去几年我们养成的习惯是给模型布置详细步骤先做什么后做什么条理越清晰越好因为对话模型本身不具备“规划”能力步骤是用户替它想的。推理模型不一样。DeepSeek 的 deepseek-reasoner 在正式回答之前会在内部生成一段不对外展示的思考链reasoning chain。这段思考链占据额外的生成时间和 token换来的是复杂任务上的准确率提升。从产品角度看这段思考链是一个“黑匣子”你只能看到最终答案和一段摘要看不到完整的脑内活动。这也是推理模型主要测试指标里“首字延迟 TTFT”比对话模型高的根本原因——它在开口之前先想了很久。这个机制直接带来一个反直觉结论提示词写得越“完备”推理模型越难受。当你要求它“请一步一步地思考”它要么把内部推理过程误认为输出要求在回答里复述推导要么把这句话当成额外约束反而限制了它本来更高效的那条推理路径。真正该做的是把提示词收敛成“任务 约束 输出格式”三段其余过程交给模型。2.2 一套提示词写两种模型对话模型给步骤推理模型给边界用一个真实的业务场景做对照合同风险审查。给对话模型写提示词我会把审查步骤拆开给推理模型写只交代清楚要什么格式的结果。同一个后端服务里两者可以共存但提示词模板要分开维护。from openai import OpenAI client OpenAI( base_urlhttps://api.deepseek.com, api_keysk-xxxx, # 换成你的 key ) user_prompt 审查这份合同输出 JSON {risks: [{clause: 条款编号, level: 高/中/低, reason: 一句话理由}], suggestions: [{clause: 条款编号, new_text: 建议文本}]} # 对话模型版本给它走查步骤效果更好 chat_resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是资深合同审查法务。先通读合同再按条款逐一识别风险。}, {role: user, content: user_prompt}, ], temperature0.3, # 对话模型建议低温减少随机性 max_tokens2048, ) # 推理模型版本给任务和输出格式思考步骤交给它自己 reasoner_resp client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: user, content: user_prompt}, ], max_tokens4096, # 注意内部推理 token 也占用这个上限 )注意差异对话模型版本里我放了一条 system 指令告诉它“先通读再按条款走查”这对 deepseek-chat 是有效的推理模型版本我直接去掉了 system 消息只留任务和输出格式。原因是 deepseek-reasoner 对“怎么做”的指令非常敏感一旦它认为你在规定流程就会牺牲自己的推理路径去迎合你的流程。另一个差异是 max_tokens同样的任务推理模型需要更大的上限因为它要在同一个生成序列里“先想后答”我在线上一般直接给对话模型的 1.5 到 2 倍。2.3 推理模型的三个关键指标首字延迟、推理耗时、输出一致性把推理模型接进生产环境评估指标和对话模型不完全一样。对话模型看吞吐和首字延迟就够了推理模型还要多关注两件事推理耗时和输出一致性。下面这是我在项目里实际盯的三个指标。指标含义对提示词的影响首字延迟 TTFT请求发出到收到第一个 token 的时间提示词里的长背景、大段落 few-shot 会显著推迟首字任务复杂度也直接影响这个值推理耗时模型内部思考链消耗的时间与 token 数提示词里的冲突指令会让推理链变长比如让它“先按 A 再按 B 分析”输出一致性相同输入多次输出的稳定程度推理模型内部有采样随机性同一提示词可能给出不同结构的结果TTFTTime To First Token是推理模型最直观的体验指标。用户发出一个请求半天没动静产品上就会觉得“卡了”。我在线上用 streamTrue 把首字时间从 3 秒到 8 秒的波动优化成了固定等待的“打字机效果”体感改善明显。但注意这只是遮羞布——真正治本的是把输入长度压下来这个放在后面避坑章细说。3. DeepSeek 提示词工程落地API 调用与场景化参数设置3.1 最小调用代码把 deepseek-reasoner 接进业务线DeepSeek 的 API 兼容 OpenAI 的协议这意味着你不需要引入新的 SDK直接用 openai 库换 base_url 就能工作。最小调用代码比想象中短但有几个参数必须一次性配对否则上线后要反复改。import os from openai import OpenAI client OpenAI( base_urlhttps://api.deepseek.com, # 如果报 404改成 https://api.deepseek.com/v1 api_keyos.getenv(DEEPSEEK_API_KEY), timeout60.0, # 推理模型耗时是秒级起步别用默认 10 秒 max_retries2, ) resp client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: user, content: 把下面的需求拆成数据库表结构输出 DDL不要解释……} ], max_tokens8192, streamFalse, ) print(resp.choices[0].message.content)参数说明base_url 填 https://api.deepseek.com 或者带 /v1 都有人用我的经验是优先填不带 /v1 的官方地址如果客户端版本较老出现 404再补 /v1。timeout 是第一个要改的参数默认值通常只有 10 秒而 deepseek-reasoner 处理中等难度任务时推理阶段就可能花 20 到 40 秒提前超时会让业务端误判为失败。max_retries 不要设太大推理模型的重复请求会成倍消耗账号额度2 次重试已经是上限。另外如果你是把 DeepSeek 接进企业微信这类 IM 机器人记得在系统提示词里强制要求“输出纯文本不要 Markdown不要表格”。推理模型生成的表格在微信里会被渲染成一坨乱码这算是提示词工程里最容易忽略的落地细节。3.2 参数取舍temperature、max_tokens 与推理预算推理模型的参数和对话模型是同名的但语义发生了偏移尤其是 temperature 和 max_tokens。下面是我在实际项目中固定下来的参数基线可以直接作为起点。参数推荐设置说明temperature保持默认不手动调低deepseek-reasoner 内部已经有采样策略调低不会提高稳定性反而可能让它思考不充分max_tokens对话模型的 1.5 到 2 倍内部推理 token 和最终回答 token 共用这个上限设太小会截断在思考链里导致“答案没说完”stream推荐 True推理阶段没有 token 输出开启流式后虽然前端还是会等待但至少能看到连接是活的timeout60 秒以上不能按对话模型的 10 秒习惯来任务越难推理耗时越长关于“推理预算”这个概念推理模型内部有一个类似思考深度控制的机制DeepSeek 这边没有直接开放专门的预算参数但可以通过 max_tokens 和提示词里的复杂度要求来间接控制。比如同一个分类任务你在提示词里写“只输出类别不要分析”它的推理链会明显变短如果写“先分析再下结论”推理耗时可能翻倍。预算控制不是调一个旋钮而是靠提示词约束思考范围这是很多人忽略的点。3.3 上下文工程系统提示词、任务文本与 skill/agent 的分工提示词工程发展到今天已经不只是“写一段话塞进 system”了。更准确的说法是上下文工程把系统提示词、任务文本和外挂的能力skill、工具调用分开管理。很多人问“系统提示词工程和 skill agent 有什么区别”我的理解是系统提示词定义的是不变的策略和边界skill/agent 定义的是可复用的动作流程两者混在一起是常见的翻车点。system_prompt 你是客服质检分析助手。 策略只分析用户消息中的情绪与诉求不评价客服表现。 边界不输出任何个人信息不输出原始聊天记录。 格式JSON字段 fixedsentimentpositive/negative/neutral、request_category。 task_prompt 输入客服会话 {user: 你们物流也太慢了三天了还没到, agent: 先生您好我帮您查一下……} resp client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: system, content: system_prompt}, {role: user, content: task_prompt}, ], max_tokens2048, )这个例子里system 提示词只放“不可变策略”任务文本放“本次输入”而真正的质检规则、敏感词表、工单流转动作则由外部代码和 skill 去执行不塞进大模型上下文。按照这条线去拆系统提示词会越来越薄但效果反而更稳。把可枚举的规则写进提示词是大忌——那些规则本应写在代码里或检索库里写进提示词只会让推理模型在互相冲突的约束间打转。4. 从 API 到产业部署本地部署、vLLM 服务化与开发工具接入4.1 先算账API 与本地部署的成本与延迟权衡产业落地第一步不是选模型是选部署形态。同一个 DeepSeek 推理模型走官方 API 和本地部署成本和体验是两个极端。先算明白这笔账再决定要不要自建推理服务。维度官方 API本地部署vLLM 蒸馏模型启动成本几分钟接入需要至少一张 24GB 以上显存的 GPU数据合规数据出内网数据不出内网适合政务、医疗、金融首字延迟 TTFT波动较大取决于服务端负载自控但小显存下会明显偏高单位成本按 token 计费推理 token 也收费一次性硬件投入加电费量大时更划算需要特别提醒deepseek-reasoner 的计费不只是按“回答字数”算的内部推理生成的 token 同样计入账单。我在项目里见过一个只看输出字数的成本预估上线后实际账单超出预算三倍——原因是用户每次提问模型都先花几百个 token 思考。要做成本估算一定要先把“推理 token 占比”加进去建议先跑一周日志统计真实 token 消耗再定价。数据合规要求高的场景本地部署不是选择题而是必答题下面这份部署流程是按 vLLM 的常见做法整理的。4.2 用 vLLM 把 DeepSeek 蒸馏模型部署成本地服务本地部署 DeepSeek最常见的开源推理服务框架是 vLLM。它把 OpenAI 兼容接口直接暴露出来业务端只需要改一行 base_url。部署命令如下# 安装 vLLM建议在 Python 3.10 环境 pip install vllm # 启动推理服务模型用 R1 的 Qwen 蒸馏版 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --port 8000 \ --served-model-name deepseek-reasoner参数说明--max-model-len 是上下文上限蒸馏模型本身支持长上下文但如果显存只有 48GB把上限压到 16384 或 8192能显著降低首字延迟和显存占用线上常见的做法是“按业务实际需求裁剪而不是按模型最大值配置”。--gpu-memory-utilization 设置为 0.9 是给驱动和并发请求留余量多卡场景建议降到 0.85。--served-model-name 是关键它让本地服务对外暴露的模型名和官方 API 保持一致这样业务端切换时只需要改 base_url 和 api_key不用改任何业务代码。启动之后原来的 OpenAI 客户端代码里 base_url 改成 http://localhost:8000/v1 即可。如果你部署的是小参数量蒸馏模型比如 7B 或 14B 级别还可以在这台机器上同时跑量化版本INT4 或 INT8显存占用直接砍半。像 Jetson Orin 这类边缘设备上跑推理模型目前可行方案就是“小蒸馏模型 INT4 量化 压低 max-model-len”不要去试 32B 甚至更大参数的模型TTFT 会突破用户忍耐极限。本地部署适合对延迟要求高、数据敏感的场景但换来的是你要自己处理并发排队、显存溢出和日志监控运维成本不会低。4.3 开发工具链路接入Codex、Claude Code 与多智能体编排框架产业落地的另一条常见路径是把 DeepSeek 接进开发工具和 Agent 框架。Codex CLI 和 Claude Code 这类工具都支持通过环境变量改写模型接入点配置思路完全一致指向 DeepSeek 的 OpenAI 兼容接口。# Codex CLI 接入 DeepSeek export OPENAI_API_KEYsk-xxxx codex config set api_base_url https://api.deepseek.com codex config set model deepseek-reasoner # Claude Code 接入 DeepSeek走 Anthropic 兼容层时 export ANTHROPIC_BASE_URLhttps://api.deepseek.com export ANTHROPIC_MODELdeepseek-reasoner配置说明Codex 和 Claude Code 这类 agent 工具在调用模型时不会只发一次请求它们会反复对话、调用工具、读取文件整个会话里的 token 消耗比单次问答高一个数量级。所以接入前先确认账号余额和限流策略不然很容易在半小时内把日配额打光。Agent 场景里推理模型更适合做“规划大脑”而不是每个环节都交给它。类似 DeepSeek Harness 这样的多智能体编排框架常见做法是让 deepseek-reasoner 负责拆解任务和决策让轻量模型或外部工具负责检索、格式化和执行动作避免每个节点都触发一次深度推理否则一次任务的耗时会被累加成分钟级。另一个硬性要求agent 框架在调用工具后必须立即把工具结果回传给模型如果 messages 里夹带一大段历史对话再回传推理模型会因为上下文过长而长时间无响应严重的会直接触发超时错误。这个场景下控制 messages 长度比提示词质量还重要。5. 推理模型落地避坑5 个从线上翻车里总结的教训5.1 现象提示词里写了“请一步步思考”结果响应又慢又差某次客服工单分类需求我把详细的分析步骤写进了提示词上线后准确率反而比 baseline 低了 8 个百分点响应时间翻倍。原因推理模型把“一步步思考”当成输出要求在回答里复述推导过程干扰了它原有的推理链。解决删掉所有描述思考过程的句子只保留“任务、约束、输出格式”三段。我现在的规范是提示词里禁止出现“思考”“分析”“逐步”这类动词。5.2 现象思维链像黑匣子解释不了模型为什么翻车人工审核时发现模型把一个标点异常的合同判为“无风险”但没人能说清判断依据。原因推理模型的思考链默认不完整对外暴露运营侧只能看到结果无法定位是提示词问题还是模型能力问题。解决在提示词末尾加一条“输出关键依据”让每条结论都带一句话理由——比如“依据合同第 7 条第 2 款”这在可解释性要求高的行业几乎是硬性需求代价是每个回答多消耗几十个 token但值得。5.3 现象tool call 之后长时间无响应直到超时报错Agent 框架里模型返回了一个工具调用结果框架去执行完工具后把一段很长的历史消息连同工具结果一起回传结果模型迟迟不给最终回复。原因消息列表里既有 history 又有工具输出上下文长度暴涨推理模型的预填充时间被拉长到秒级甚至分钟级触发 LLM 服务端的超时限制。解决收到 tool call 后立即把工具结果作为 user 消息传回不要把整段对话历史再送一遍对不需要模型关注的历史做截断或摘要。在不少 agent 框架里这条规则直接决定一个任务能不能跑完。5.4 现象首字延迟 TTFT 飙升长文档把用户等没金融场景里需要模型分析一份五十页的 PDF用户点击“分析”之后等了四十秒没看到任何反馈直接关闭页面。原因长文档的预填充本身就耗时推理模型还要在读完文档后再思考一轮首字延迟被叠加放大。解决不要直接把整份文档塞给推理模型。先用对话模型或检索模块抽取出关键段落再交给推理模型做判断。另一种补救是用 streamTrue 配合前端流式输出至少让用户看到“正在生成”但这只是缓解体感真正的优化是减少输入长度。5.5 现象系统提示词越长越好两千字约束压坏了推理为了做合规往系统提示词里堆了两千字规则和案例结果模型频繁输出“根据规则 17 无法判断”之类的话。原因推理模型对相互冲突的约束极度敏感超长系统提示词里任何两条规则存在语义重叠都会让它进入无休止的内部权衡推理 token 消耗暴增。解决系统提示词压到两百字以内只保留不可变红线可枚举的规则、名单、案例全部外置到检索库或代码逻辑里。提示词是给模型划边界用的不是给它装知识的——装知识用 RAG这句话写进团队规范后这类问题少了八成。6. 验证推理模型的产出质量不靠感觉的回归检查方案6.1 固定用例集与三组指标每次改完提示词不能只拿一两个例子“肉眼验收”那和掷骰子没区别。我把线上真实请求抽了四十条按难易程度分成三层组成固定用例集每次变更后跑回归。指标只看三组首字延迟 TTFT、总耗时、结果格式可用率。格式可用率很重要——我遇到过提示词改动后模型开始偶尔漏字段的情况肉眼根本看不出来但下游入库直接失败。6.2 回归检查的最小实现import json import time from openai import OpenAI client OpenAI( base_urlhttps://api.deepseek.com, api_keysk-xxxx, timeout120, ) cases [ {name: simple_10, prompt: 11?, expect: 2}, {name: contract_01, prompt: 审查合同输出JSON风险列表, expect: risks}, ] def check_case(case): t0 time.time() resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: case[prompt]}], max_tokens4096, streamTrue, # 流式拿首字时间 ) first_token_time None content for chunk in resp: if not first_token_time: first_token_time time.time() - t0 content chunk.choices[0].delta.content or return { name: case[name], ttft: round(first_token_time, 2), total: round(time.time() - t0, 2), ok: case[expect] in content, } for case in cases: print(json.dumps(check_case(case), ensure_asciiFalse))这段脚本把每个用例的 TTFT、总耗时和是否包含期望关键词全部打印出来。我做提示词变更时要求 TTFT 不超过上一次基准的 1.5 倍格式字段一个不能漏否则不进发布。这套回归脚本已经在项目里跑了大半年最大的价值不是测 bug而是让我在改提示词时敢下手——改坏了能立刻知道改好了也能量化出效果。我自己的习惯是每次只改一个变量要么删一段 system 提示词要么动输出格式模板改完就跑回归用数据说话。这比任何人拍胸脯保证“这版效果更好”都可靠。希望这套思路帮你也少踩几个坑。本文还有配套的精品资源点击获取