简介北京大学DeepSeek系列讲座之《提示词工程和落地场景》PPT梳理了DeepSeek-R1的核心能力、技术优势与实用方法。内容涵盖模型思考过程可视化、开源低成本国产化三大特点、火爆原因分析以及官方APP、网页端、API三种直接使用方式。配套讲解提示词技巧如何突破工具表层应用将专家思维迁移到学习、工作和垂直行业场景中适合希望零基础上手大模型、提升人机协作效率的普通用户与AI应用开发者。资源为1个pptx演示文稿压缩包大小808KB页面结构完整包含DeepSeek原理拆解、应用渠道对比、私有化部署方式及参考文献指引可直接用于讲座复盘、内部培训或自学梳理。已有376人学习对快速理解DeepSeek提示词工程和落地场景具有较高参考价值。1. 提示词工程不是“把话说清楚”而是把模型的推理边界画出来做提示词工程和落地场景最容易被误解的一点是以为提示词写不好是因为话没说明白。我接手过不少 DeepSeek 相关项目真正的问题从来不是“模型听不懂”而是“模型太会猜”。你给它一句含糊的指令它会用最自信的语气编一个最合理的答案。提示词工程要解决的不是让模型更聪明而是让它在你的业务边界内输出少发挥、少脑补、多按规矩办事。这篇笔记我按自己实际跑过的方案来讲从 DeepSeek 的生成机制、提示词结构、API 落地到排查翻车把能直接复用的写法和参数都摊开。2. 提示词工程的第一性先搞懂 DeepSeek 怎么“读”你的话2.1 从补全到对话DeepSeek 的生成机制决定了提示词要怎么写DeepSeek 这类大模型本质是一个超长的文本补全器。你在对话框里发的内容会连同历史消息一起拼成一段上下文模型从这个上下文往后续写。它没有“理解”你的意图它只是在计算下一个最可能的 token。这一点决定了提示词工程的核心思路不要指望模型主动体察你的言外之意要把言外之意写进上下文里。我一般会把提示词分成三层来看。第一层是系统提示词通常放在对话最前面用来设定角色、目标和全局约束第二层是用户消息承载具体任务和材料第三层是历史对话或工具返回结果决定模型的短期记忆。绝大多数翻车问题不在第二层而在第一层和第三层。系统提示词写得像散文模型越到后面越容易“忘”历史消息塞了太多无关内容模型会把噪声当成线索。所以写提示词之前先回答三个问题模型需要扮演谁、需要做什么、不能做什么。把这三个答案写清楚比堆砌“你是一个优秀的人工智能助手”有用得多。角色设定要给行为约束例如“你是售后客服只根据知识库内容回答知识库里没有的内容直接说明不知道”不要只给身份不给规则。2.2 系统提示词、上下文工程和 Skill Agent 的分工边界很多人分不清系统提示词、上下文工程和 Skill Agent 的区别我在团队里也经常被问。简单说系统提示词是静态约束每次请求都会原样带上描述模型在整场对话里的行为准则上下文工程是动态管理解决“哪些内容该进上下文、哪些不该进、按什么顺序进”Skill Agent 则是把提示词、工具调用和决策逻辑打包成一个可复用的智能体单元类似 DeepSeek harness 里那种多智能体编排的方式。三者的分工可以用一句话概括系统提示词定边界上下文工程管记忆Agent 编排控流程。如果你的任务是一次性的文本处理写好系统提示词和用户消息就够了不需要引入 Agent。如果任务是多步骤的比如先查资料再写报告就要考虑用 Agent 或工具调用来拆分而不是把所有步骤压进一条提示词里。我见过一个典型误用有人为了让模型“更聪明”把几十条规则全部塞进系统提示词结果模型在长对话后半段开始无视规则。问题的根源不是规则写得不好而是上下文太长模型注意力被稀释。这类问题的解法不是继续加规则而是把规则精简到十条以内把决策点拆出去用代码判断或工具调用来替代。2.3 一个能直接套用的最小提示词模板和参数配置下面这个模板是我在多个场景里反复用过的适用于大多数文本生成、信息抽取和问答类任务。它的结构很简单角色、背景、任务、约束、输出格式。你是{角色}。 背景{业务场景一句话} 任务{要模型完成的动作} 约束 1. 只基于给定材料回答不得自行补充外部知识 2. 不确定时输出“信息不足”不要编造 3. 不要输出与任务无关的内容 输出格式{JSON 结构或条目列表} 材料 {用户输入}这套模板看起来平淡但每个部分都有明确的工程意图。角色设定了回答的立场背景给模型提供了判断语境的锚点任务必须是动词开头的具体指令约束用来压制幻觉和多话输出格式决定了后续程序能不能直接解析。模板的顺序不要随意打乱因为模型对靠前内容的注意力更强角色和约束放前面比放后面更有效。参数配置上我通常用这样的起步值temperature 0.3 以下用于抽取、分类、格式化输出0.7 左右用于文案生成和头脑风暴top_p 保持默认或随 temperature 联动。max_tokens 要根据输出格式估算不要让模型在长输出中途被截断。如果你在用 API建议把 response_format 设为 JSON能显著提高结构化输出的稳定性后面第四章会专门讲调用方式。3. 动手写提示词把思路落成可复现的指令3.1 用“角色-任务-约束-输出格式”四段式搭骨架上一章给了一个最小模板这一章讲怎么把业务需求翻译成提示词。我习惯用“角色-任务-约束-输出格式”四段式搭骨架原因很简单它强迫你把模糊的需求拆成模型可以执行的操作。先写角色。角色不是装饰它决定了模型调用哪部分知识。同一个问题“请解释什么是幂等性”和“你是一名系统架构师请向初级开发解释什么是幂等性”后者的输出在术语深度和表达方式上都会不同。角色描述要具体最好带上行业和职级。再写任务。任务要避免“请帮我分析一下”这种空泛写法换成“请从这段日志中提取错误码、发生时间和影响范围”。任务的每个动词都对应一种输出提取对应结构化结果改写对应文本重写判断对应结论加理由。然后是约束。约束是防幻觉和防跑题的关键。常见的约束包括只基于给定材料、不要输出思考过程、不确定时直接说不知道、禁止重复材料中的无关内容。约束不要超过五条太多约束会互相打架模型会为了满足某一条而牺牲另一条。最后是输出格式。如果你要接程序直接给 JSON 结构示例如果要给人看给分条列表的示例。模型对格式的遵循能力比你想象的要强只要你在提示词里给了明确的格式范例它就很少跑偏。反过来如果你只写“结构化输出”模型会按照它对“结构化”的理解自由发挥。3.2 给模型“思考空间”复杂任务用步骤化指令而不是催它给答案场景一复杂直接把结果丢给模型它常常会跳步骤、合并问题、省略中间推导。这是我做提示词工程时踩得最深的坑之一。后来我发现对复杂任务与其催它直接给答案不如把步骤写进提示词让模型一步步来。做法是在任务描述里加上步骤编号任务判断用户的退款申请是否符合规则。 步骤 1. 从用户描述中提取订单号、申请原因、商品类目 2. 对照规则表中对应的退款条件 3. 列出符合和不符合的条款 4. 给出结论同意退款 / 拒绝退款 / 需要人工复核这个写法利用的是模型在逐token生成时的自注意力机制分步指令让模型在每一步生成的文本都会成为下一步的上下文相当于强迫它先思考再落结论。你还可以在提示词里加一句“请先列出你的判断依据再输出结论”效果类似。但这里有个边界步骤化指令只对逻辑可拆解的任务有效。对创意写作、情感分析这类任务强行分步骤反而会限制输出质量。我的原则是任务越接近“判断题”或“计算题”越适合分步任务越接近“开放题”越应该少给步骤多给风格和样例。另外注意分步思考不等于把模型内心想法全量输出。如果输出要给人看你可以在提示词里注明“只输出最终结论不要输出分析过程”这不会影响模型的内部推理但会让最终文本干净很多。3.3 用示例和边界条件约束输出从“能跑”到“稳定跑”提示词工程里最容易被低估的技术是示例few-shot。一段干巴巴的规则模型可能理解但执行起来会有偏差给它一个正面例子和一个反面例子它立刻能对齐你的预期。我举个例子。做评论审核分类直接写“判断评论是否涉及人身攻击”模型会把“你就是个笨蛋”和“这个功能太蠢了”都判成攻击。加上示例就好很多请判断以下评论是否属于人身攻击只输出“是”或“否”。 示例1 评论这个作者水平太差完全是外行在误导人。 输出是 示例2 评论这篇文章的逻辑我没看懂但数据看起来不太对。 输出否 待判断 评论连基本语法都写不对还好意思发教程。示例的关键是边界贴近你的真实业务。你要覆盖最容易误判的那类输入而不是给几个无关痛痒的样例。通常两个正面加两个反面就够多了会占用上下文还可能出现示例彼此矛盾的问题。边界条件也要写清楚。比如“当输入长度超过模型窗口时截断策略是什么”“当材料内容为空时怎么回复”“当用户问题与角色无关时怎么处理”。这些边界条件看起来是小事但生产环境里模型被问住的情况绝大多数落在你没有定义过的边界上。把边界提前写进提示词比事后写代码兜底要省事得多。4. 调用 API 落地场景从提示词到可交付功能4.1 DeepSeek API 调用最小可运行代码与参数说明提示词写得再好如果调用方式不对落地一样失败。DeepSeek 的 API 走的是 OpenAI 兼容格式这意味着你之前写的认知可以无缝迁移。下面是最小可运行代码我一般用 Python 和 requests 直接调不引额外包方便在任何环境里跑通。import requests payload { model: deepseek-chat, messages: [ {role: system, content: 你是售后客服只根据知识库回答。}, {role: user, content: 订单号 123456 什么时候发货} ], temperature: 0.2, max_tokens: 500, stream: False } resp requests.post( https://api.deepseek.com/chat/completions, headers{ Authorization: Bearer 你的API密钥 }, jsonpayload, timeout60 ) data resp.json() print(data[choices][0][message][content])这段代码的逻辑很直接构造 messages 列表系统消息决定模型角色用户消息承载实际请求然后 POST 给 chat/completions 接口。返回的数据结构中choices 数组里取第一个元素的 message.content就是模型生成的文本。参数说明上temperature 控制随机性0.2 适合客服、抽取这类低容错任务max_tokens 限制生成长度注意它算的是输出 token不是字数中文通常一个汉字约一个 token。timeout 我习惯设 60 秒以上因为 DeepSeek 在长上下文或复杂任务下响应时间可能超过 30 秒。另外如果你接入的是 codex 之类的工具链DeepSeek API 的 OpenAI 兼容格式让这类接入成本很低换 base_url 和密钥就能跑通。4.2 用 JSON 模式和工具调用把提示词接进业务逻辑文本接进业务不能靠人去读模型输出要让程序直接解析。JSON 模式是首选方案。在请求体里加入 response_format 参数模型就会尽量输出合法 JSON。payload { model: deepseek-chat, messages: [ {role: system, content: 你是信息抽取助手。}, {role: user, content: 从以下投诉中抽取原因和期望\n我买的充电器三天就坏了客服让我自己寄回去修太麻烦了希望直接换新。} ], response_format: {type: json_object}, temperature: 0.0 }加了 response_format 之后输出会用 JSON 包起来例如返回 {原因: 充电器质量问题, 期望: 直接换新}。这个模式必须在提示词里明确告诉模型要输出 JSON 的字段结构否则它不知道往 JSON 里塞什么。我的经验是在提示词里加一行“输出格式{字段1: #字段2: #}”给一个空壳模板模型会照着填。工具调用function calling是更进阶的玩法。它的逻辑是模型不直接生成最终答案而是生成一个函数调用请求你的程序执行函数后把结果再传给模型。这解决了一个关键问题——模型没有真实数据访问能力通过工具调用可以把数据库、API、计算逻辑接进来。DeepSeek 支持 OpenAI 兼容的 tools 参数定义方式和 API 调用方式都很标准但这块不建议新手一上来就碰先把普通提示词和 JSON 模式跑稳再上工具调用。4.3 落地场景拆解客服、写作、代码三个方向怎么改提示词落地场景不同提示词的侧重点完全不同。拿客服场景来说核心诉求是安全、不捏造。系统提示词里要写“只基于知识库回答知识库无答案时直接说需要转人工”温度调到 0.2 以下同时用工具调用把订单查询接口接进来让模型在回答前先拿真实数据。写作场景相反核心诉求是风格稳定。temperature 调到 0.7 到 0.9提示词里给足风格示例约束部分要少一点只限制“不写空话、不使用重复句式”。这里最容易翻车的是把写作任务当成抽取任务温度设太低结果生成出来的文字干巴巴像在念说明书。代码场景介乎两者之间。生成代码时 temperature 用 0.2 比较合适太高会编出不存在的方法名。提示词里要给出编程语言、依赖版本、输入输出示例和约束条件。比如“用 Python 3.10 写一个函数输入是列表输出是去重后的列表保持原顺序不要用第三方库”。你给的信息越接近一个需求单模型生成的代码越能直接跑。5. 提示词落地避坑5 个真实翻车现场和排查方法5.1 输出不稳定温度越高幻觉越“自信”现象是同一个提示词连续调用结果有时候对有时候错错的时候模型语气特别肯定。我最早做客服机器人时模型偶尔会把知识库没有的信息说得像真事最离谱的一次是给用户编了一个不存在的退款政策。原因很直接temperature 设太高模型在概率分布里选了更“有创意”的路径。温度越高低概率 token 被选中的机会越大模型就越倾向于编造细节来让回答显得完整。它不是不知道答案而是被允许“即兴发挥”。解决方法是把温度压在 0.2 以下同时把“只基于知识库回答”写进系统提示词再加上一条“信息不足时直接说不知道”。如果业务允许干脆把温度设 0得到可重复的输出方便做回归测试。5.2 系统提示词被忽略上下文一长早期指令被稀释现象是多轮对话进行到十几轮之后模型开始违背系统提示词比如不再遵守“不要提及竞品”或者回答风格越来越随意。起初我以为是模型“忘性大”后来发现是上下文太长导致的注意力稀释。原因在于模型处理超长上下文时对早期内容的关注度会下降尤其是当中间夹了大量用户消息和工具返回结果时系统提示词的相对权重会被摊薄。这不是 DeepSeek 特有的问题所有长上下文模型都有。解决方法是三管齐下精简系统提示词只留不可妥协的底线规则定期截断或总结历史对话把无关内容移出上下文在关键节点把系统提示词重新插入用户消息里比如每次用户发新问题时程序先拼上“提醒你仍需遵守如下底线规则”再发送。5.3 “工具调用需要立即结果”报错多轮 tool call 的时序问题现象是接入工具调用后模型报错。错误信息大意是“本轮运行失败消息中的工具调用需要立即返回结果”也就是 DeepSeek 模型发出了工具调用请求但客户端没有在下一轮消息里立刻补充工具结果而是又发了一条用户消息或系统消息导致请求格式不符合要求。原因是对 OpenAI 兼容工具调用的规则不熟当模型返回 tool_calls 字段时你必须在下一轮请求里按顺序把所有 tool_calls 对应的 tool 角色消息补齐然后才能追加其他内容。顺序错了或者漏了API 就会报错。解决方法是把工具调用流程做成严格的状态机先发送请求检查响应里有没有 tool_calls如果有逐一执行工具后构造 tool 角色的 response 消息再带着这些消息重新请求一次模型。代码里不要混入多余的消息保持“请求-工具-回复”这个循环。5.4 成本失控上下文越长单次调用越贵现象是账单越跑越高明明调用次数没涨多少。DeepSeek 的价格是按输入输出的 token 总数计费的而输入 token 里很大一块是历史对话和系统提示词。很多应用每轮都把全部历史消息重新发一遍上下文越滚越长成本自然水涨船高。原因是忽视了上下文管理。落地提示词工程时只关注了提示词怎么写没关注每次请求实际携带了多少内容。做 Agent 任务时工具返回的长文本如果不做截断或摘要很快就能把一个轻量任务拖成高价任务。解决方法是做上下文裁剪设置历史消息上限超出就丢弃最旧的消息工具调用返回结果只保留关键字段对长文档用摘要替换原文。另外可以统计单次请求的平均 token 数如果超过几千就要考虑是不是把不该带的东西带进来了。5.5 本地部署与 API 结果不一致量化版本改变了模型行为现象是同一套提示词在 API 上测试得很好迁到本地部署之后输出明显变差有些人还遇到过生成重复文本或者格式错乱。原因多半是本地跑的模型是量化版本比如 4bit 或 8bit 量化模型在低精度下丢失了一部分表达能力对复杂指令的遵循能力下降。这个问题在边缘设备上尤其明显比如 Jetson Orin 这类资源受限的板子上跑 DeepSeek 量化版速度和成本解决了但行为偏差只能靠调提示词补。解决方法是量化模型用更短的指令风格少绕弯子必须用复杂指令时把指令拆成多步调用如果业务对输出质量极其敏感建议保留 API 通道兜底。6. 验证提示词改进的一个技巧用留出集做回归测试提示词工程最大的坑是你不知道改动是好是坏。很多人改一句提示词跑几个例子觉得不错就直接上生产结果在真实流量里翻车。我现在的习惯是给每个核心提示词配一个留出集做回归测试。留出集的规模不用大20 到 50 条就够关键是覆盖真实场景的极端情况。我在做客服场景时留出集里既要有正常提问也要有“恶意测试”比如问“你能帮我写个假证明吗”还得有“信息不足”的样本比如知识库里没有的问题。每改动提示词我就跑一遍留出集逐条看输出变化确认没有破坏已有能力。回归测试的脚本逻辑很简单就是批量调用 API把新旧提示词的输出存下来做对比import requests test_cases [ {user: 订单超时未收到怎么办, expect: 物流或补发}, {user: 你能骂人吗, expect: 拒绝}, ] results [] for case in test_cases: payload { model: deepseek-chat, messages: [ {role: system, content: new_prompt}, {role: user, content: case[user]} ], temperature: 0 } resp requests.post(url, headersheaders, jsonpayload, timeout30) output resp.json()[choices][0][message][content] results.append({case: case[user], output: output})这段代码把温度设为 0是为了让输出可复现方便对比改动前后的差异。实际跑的时候我会把结果导出成表格先人工扫一遍明显变差的再统计关键词匹配率。不要只看准确率还要看失败样本集中在哪个类型上。这个习惯救过我很多次。有一回我为了压制幻觉在系统提示词里加了一句“不要编造信息”结果幻觉确实少了但模型开始对很多正常问题也回答“信息不足”。如果没有留出集我可能根本发现不了这个副作用。提示词工程的改进很少是单维度的你永远要用一组真实样本去验证整体效果。希望这个回归测试的习惯能帮到你至少在每次改完提示词之后心里有个底。本文还有配套的精品资源点击获取 DeepSeek提示词工程实战：从生成机制到API落地与避坑
简介北京大学DeepSeek系列讲座之《提示词工程和落地场景》PPT梳理了DeepSeek-R1的核心能力、技术优势与实用方法。内容涵盖模型思考过程可视化、开源低成本国产化三大特点、火爆原因分析以及官方APP、网页端、API三种直接使用方式。配套讲解提示词技巧如何突破工具表层应用将专家思维迁移到学习、工作和垂直行业场景中适合希望零基础上手大模型、提升人机协作效率的普通用户与AI应用开发者。资源为1个pptx演示文稿压缩包大小808KB页面结构完整包含DeepSeek原理拆解、应用渠道对比、私有化部署方式及参考文献指引可直接用于讲座复盘、内部培训或自学梳理。已有376人学习对快速理解DeepSeek提示词工程和落地场景具有较高参考价值。1. 提示词工程不是“把话说清楚”而是把模型的推理边界画出来做提示词工程和落地场景最容易被误解的一点是以为提示词写不好是因为话没说明白。我接手过不少 DeepSeek 相关项目真正的问题从来不是“模型听不懂”而是“模型太会猜”。你给它一句含糊的指令它会用最自信的语气编一个最合理的答案。提示词工程要解决的不是让模型更聪明而是让它在你的业务边界内输出少发挥、少脑补、多按规矩办事。这篇笔记我按自己实际跑过的方案来讲从 DeepSeek 的生成机制、提示词结构、API 落地到排查翻车把能直接复用的写法和参数都摊开。2. 提示词工程的第一性先搞懂 DeepSeek 怎么“读”你的话2.1 从补全到对话DeepSeek 的生成机制决定了提示词要怎么写DeepSeek 这类大模型本质是一个超长的文本补全器。你在对话框里发的内容会连同历史消息一起拼成一段上下文模型从这个上下文往后续写。它没有“理解”你的意图它只是在计算下一个最可能的 token。这一点决定了提示词工程的核心思路不要指望模型主动体察你的言外之意要把言外之意写进上下文里。我一般会把提示词分成三层来看。第一层是系统提示词通常放在对话最前面用来设定角色、目标和全局约束第二层是用户消息承载具体任务和材料第三层是历史对话或工具返回结果决定模型的短期记忆。绝大多数翻车问题不在第二层而在第一层和第三层。系统提示词写得像散文模型越到后面越容易“忘”历史消息塞了太多无关内容模型会把噪声当成线索。所以写提示词之前先回答三个问题模型需要扮演谁、需要做什么、不能做什么。把这三个答案写清楚比堆砌“你是一个优秀的人工智能助手”有用得多。角色设定要给行为约束例如“你是售后客服只根据知识库内容回答知识库里没有的内容直接说明不知道”不要只给身份不给规则。2.2 系统提示词、上下文工程和 Skill Agent 的分工边界很多人分不清系统提示词、上下文工程和 Skill Agent 的区别我在团队里也经常被问。简单说系统提示词是静态约束每次请求都会原样带上描述模型在整场对话里的行为准则上下文工程是动态管理解决“哪些内容该进上下文、哪些不该进、按什么顺序进”Skill Agent 则是把提示词、工具调用和决策逻辑打包成一个可复用的智能体单元类似 DeepSeek harness 里那种多智能体编排的方式。三者的分工可以用一句话概括系统提示词定边界上下文工程管记忆Agent 编排控流程。如果你的任务是一次性的文本处理写好系统提示词和用户消息就够了不需要引入 Agent。如果任务是多步骤的比如先查资料再写报告就要考虑用 Agent 或工具调用来拆分而不是把所有步骤压进一条提示词里。我见过一个典型误用有人为了让模型“更聪明”把几十条规则全部塞进系统提示词结果模型在长对话后半段开始无视规则。问题的根源不是规则写得不好而是上下文太长模型注意力被稀释。这类问题的解法不是继续加规则而是把规则精简到十条以内把决策点拆出去用代码判断或工具调用来替代。2.3 一个能直接套用的最小提示词模板和参数配置下面这个模板是我在多个场景里反复用过的适用于大多数文本生成、信息抽取和问答类任务。它的结构很简单角色、背景、任务、约束、输出格式。你是{角色}。 背景{业务场景一句话} 任务{要模型完成的动作} 约束 1. 只基于给定材料回答不得自行补充外部知识 2. 不确定时输出“信息不足”不要编造 3. 不要输出与任务无关的内容 输出格式{JSON 结构或条目列表} 材料 {用户输入}这套模板看起来平淡但每个部分都有明确的工程意图。角色设定了回答的立场背景给模型提供了判断语境的锚点任务必须是动词开头的具体指令约束用来压制幻觉和多话输出格式决定了后续程序能不能直接解析。模板的顺序不要随意打乱因为模型对靠前内容的注意力更强角色和约束放前面比放后面更有效。参数配置上我通常用这样的起步值temperature 0.3 以下用于抽取、分类、格式化输出0.7 左右用于文案生成和头脑风暴top_p 保持默认或随 temperature 联动。max_tokens 要根据输出格式估算不要让模型在长输出中途被截断。如果你在用 API建议把 response_format 设为 JSON能显著提高结构化输出的稳定性后面第四章会专门讲调用方式。3. 动手写提示词把思路落成可复现的指令3.1 用“角色-任务-约束-输出格式”四段式搭骨架上一章给了一个最小模板这一章讲怎么把业务需求翻译成提示词。我习惯用“角色-任务-约束-输出格式”四段式搭骨架原因很简单它强迫你把模糊的需求拆成模型可以执行的操作。先写角色。角色不是装饰它决定了模型调用哪部分知识。同一个问题“请解释什么是幂等性”和“你是一名系统架构师请向初级开发解释什么是幂等性”后者的输出在术语深度和表达方式上都会不同。角色描述要具体最好带上行业和职级。再写任务。任务要避免“请帮我分析一下”这种空泛写法换成“请从这段日志中提取错误码、发生时间和影响范围”。任务的每个动词都对应一种输出提取对应结构化结果改写对应文本重写判断对应结论加理由。然后是约束。约束是防幻觉和防跑题的关键。常见的约束包括只基于给定材料、不要输出思考过程、不确定时直接说不知道、禁止重复材料中的无关内容。约束不要超过五条太多约束会互相打架模型会为了满足某一条而牺牲另一条。最后是输出格式。如果你要接程序直接给 JSON 结构示例如果要给人看给分条列表的示例。模型对格式的遵循能力比你想象的要强只要你在提示词里给了明确的格式范例它就很少跑偏。反过来如果你只写“结构化输出”模型会按照它对“结构化”的理解自由发挥。3.2 给模型“思考空间”复杂任务用步骤化指令而不是催它给答案场景一复杂直接把结果丢给模型它常常会跳步骤、合并问题、省略中间推导。这是我做提示词工程时踩得最深的坑之一。后来我发现对复杂任务与其催它直接给答案不如把步骤写进提示词让模型一步步来。做法是在任务描述里加上步骤编号任务判断用户的退款申请是否符合规则。 步骤 1. 从用户描述中提取订单号、申请原因、商品类目 2. 对照规则表中对应的退款条件 3. 列出符合和不符合的条款 4. 给出结论同意退款 / 拒绝退款 / 需要人工复核这个写法利用的是模型在逐token生成时的自注意力机制分步指令让模型在每一步生成的文本都会成为下一步的上下文相当于强迫它先思考再落结论。你还可以在提示词里加一句“请先列出你的判断依据再输出结论”效果类似。但这里有个边界步骤化指令只对逻辑可拆解的任务有效。对创意写作、情感分析这类任务强行分步骤反而会限制输出质量。我的原则是任务越接近“判断题”或“计算题”越适合分步任务越接近“开放题”越应该少给步骤多给风格和样例。另外注意分步思考不等于把模型内心想法全量输出。如果输出要给人看你可以在提示词里注明“只输出最终结论不要输出分析过程”这不会影响模型的内部推理但会让最终文本干净很多。3.3 用示例和边界条件约束输出从“能跑”到“稳定跑”提示词工程里最容易被低估的技术是示例few-shot。一段干巴巴的规则模型可能理解但执行起来会有偏差给它一个正面例子和一个反面例子它立刻能对齐你的预期。我举个例子。做评论审核分类直接写“判断评论是否涉及人身攻击”模型会把“你就是个笨蛋”和“这个功能太蠢了”都判成攻击。加上示例就好很多请判断以下评论是否属于人身攻击只输出“是”或“否”。 示例1 评论这个作者水平太差完全是外行在误导人。 输出是 示例2 评论这篇文章的逻辑我没看懂但数据看起来不太对。 输出否 待判断 评论连基本语法都写不对还好意思发教程。示例的关键是边界贴近你的真实业务。你要覆盖最容易误判的那类输入而不是给几个无关痛痒的样例。通常两个正面加两个反面就够多了会占用上下文还可能出现示例彼此矛盾的问题。边界条件也要写清楚。比如“当输入长度超过模型窗口时截断策略是什么”“当材料内容为空时怎么回复”“当用户问题与角色无关时怎么处理”。这些边界条件看起来是小事但生产环境里模型被问住的情况绝大多数落在你没有定义过的边界上。把边界提前写进提示词比事后写代码兜底要省事得多。4. 调用 API 落地场景从提示词到可交付功能4.1 DeepSeek API 调用最小可运行代码与参数说明提示词写得再好如果调用方式不对落地一样失败。DeepSeek 的 API 走的是 OpenAI 兼容格式这意味着你之前写的认知可以无缝迁移。下面是最小可运行代码我一般用 Python 和 requests 直接调不引额外包方便在任何环境里跑通。import requests payload { model: deepseek-chat, messages: [ {role: system, content: 你是售后客服只根据知识库回答。}, {role: user, content: 订单号 123456 什么时候发货} ], temperature: 0.2, max_tokens: 500, stream: False } resp requests.post( https://api.deepseek.com/chat/completions, headers{ Authorization: Bearer 你的API密钥 }, jsonpayload, timeout60 ) data resp.json() print(data[choices][0][message][content])这段代码的逻辑很直接构造 messages 列表系统消息决定模型角色用户消息承载实际请求然后 POST 给 chat/completions 接口。返回的数据结构中choices 数组里取第一个元素的 message.content就是模型生成的文本。参数说明上temperature 控制随机性0.2 适合客服、抽取这类低容错任务max_tokens 限制生成长度注意它算的是输出 token不是字数中文通常一个汉字约一个 token。timeout 我习惯设 60 秒以上因为 DeepSeek 在长上下文或复杂任务下响应时间可能超过 30 秒。另外如果你接入的是 codex 之类的工具链DeepSeek API 的 OpenAI 兼容格式让这类接入成本很低换 base_url 和密钥就能跑通。4.2 用 JSON 模式和工具调用把提示词接进业务逻辑文本接进业务不能靠人去读模型输出要让程序直接解析。JSON 模式是首选方案。在请求体里加入 response_format 参数模型就会尽量输出合法 JSON。payload { model: deepseek-chat, messages: [ {role: system, content: 你是信息抽取助手。}, {role: user, content: 从以下投诉中抽取原因和期望\n我买的充电器三天就坏了客服让我自己寄回去修太麻烦了希望直接换新。} ], response_format: {type: json_object}, temperature: 0.0 }加了 response_format 之后输出会用 JSON 包起来例如返回 {原因: 充电器质量问题, 期望: 直接换新}。这个模式必须在提示词里明确告诉模型要输出 JSON 的字段结构否则它不知道往 JSON 里塞什么。我的经验是在提示词里加一行“输出格式{字段1: #字段2: #}”给一个空壳模板模型会照着填。工具调用function calling是更进阶的玩法。它的逻辑是模型不直接生成最终答案而是生成一个函数调用请求你的程序执行函数后把结果再传给模型。这解决了一个关键问题——模型没有真实数据访问能力通过工具调用可以把数据库、API、计算逻辑接进来。DeepSeek 支持 OpenAI 兼容的 tools 参数定义方式和 API 调用方式都很标准但这块不建议新手一上来就碰先把普通提示词和 JSON 模式跑稳再上工具调用。4.3 落地场景拆解客服、写作、代码三个方向怎么改提示词落地场景不同提示词的侧重点完全不同。拿客服场景来说核心诉求是安全、不捏造。系统提示词里要写“只基于知识库回答知识库无答案时直接说需要转人工”温度调到 0.2 以下同时用工具调用把订单查询接口接进来让模型在回答前先拿真实数据。写作场景相反核心诉求是风格稳定。temperature 调到 0.7 到 0.9提示词里给足风格示例约束部分要少一点只限制“不写空话、不使用重复句式”。这里最容易翻车的是把写作任务当成抽取任务温度设太低结果生成出来的文字干巴巴像在念说明书。代码场景介乎两者之间。生成代码时 temperature 用 0.2 比较合适太高会编出不存在的方法名。提示词里要给出编程语言、依赖版本、输入输出示例和约束条件。比如“用 Python 3.10 写一个函数输入是列表输出是去重后的列表保持原顺序不要用第三方库”。你给的信息越接近一个需求单模型生成的代码越能直接跑。5. 提示词落地避坑5 个真实翻车现场和排查方法5.1 输出不稳定温度越高幻觉越“自信”现象是同一个提示词连续调用结果有时候对有时候错错的时候模型语气特别肯定。我最早做客服机器人时模型偶尔会把知识库没有的信息说得像真事最离谱的一次是给用户编了一个不存在的退款政策。原因很直接temperature 设太高模型在概率分布里选了更“有创意”的路径。温度越高低概率 token 被选中的机会越大模型就越倾向于编造细节来让回答显得完整。它不是不知道答案而是被允许“即兴发挥”。解决方法是把温度压在 0.2 以下同时把“只基于知识库回答”写进系统提示词再加上一条“信息不足时直接说不知道”。如果业务允许干脆把温度设 0得到可重复的输出方便做回归测试。5.2 系统提示词被忽略上下文一长早期指令被稀释现象是多轮对话进行到十几轮之后模型开始违背系统提示词比如不再遵守“不要提及竞品”或者回答风格越来越随意。起初我以为是模型“忘性大”后来发现是上下文太长导致的注意力稀释。原因在于模型处理超长上下文时对早期内容的关注度会下降尤其是当中间夹了大量用户消息和工具返回结果时系统提示词的相对权重会被摊薄。这不是 DeepSeek 特有的问题所有长上下文模型都有。解决方法是三管齐下精简系统提示词只留不可妥协的底线规则定期截断或总结历史对话把无关内容移出上下文在关键节点把系统提示词重新插入用户消息里比如每次用户发新问题时程序先拼上“提醒你仍需遵守如下底线规则”再发送。5.3 “工具调用需要立即结果”报错多轮 tool call 的时序问题现象是接入工具调用后模型报错。错误信息大意是“本轮运行失败消息中的工具调用需要立即返回结果”也就是 DeepSeek 模型发出了工具调用请求但客户端没有在下一轮消息里立刻补充工具结果而是又发了一条用户消息或系统消息导致请求格式不符合要求。原因是对 OpenAI 兼容工具调用的规则不熟当模型返回 tool_calls 字段时你必须在下一轮请求里按顺序把所有 tool_calls 对应的 tool 角色消息补齐然后才能追加其他内容。顺序错了或者漏了API 就会报错。解决方法是把工具调用流程做成严格的状态机先发送请求检查响应里有没有 tool_calls如果有逐一执行工具后构造 tool 角色的 response 消息再带着这些消息重新请求一次模型。代码里不要混入多余的消息保持“请求-工具-回复”这个循环。5.4 成本失控上下文越长单次调用越贵现象是账单越跑越高明明调用次数没涨多少。DeepSeek 的价格是按输入输出的 token 总数计费的而输入 token 里很大一块是历史对话和系统提示词。很多应用每轮都把全部历史消息重新发一遍上下文越滚越长成本自然水涨船高。原因是忽视了上下文管理。落地提示词工程时只关注了提示词怎么写没关注每次请求实际携带了多少内容。做 Agent 任务时工具返回的长文本如果不做截断或摘要很快就能把一个轻量任务拖成高价任务。解决方法是做上下文裁剪设置历史消息上限超出就丢弃最旧的消息工具调用返回结果只保留关键字段对长文档用摘要替换原文。另外可以统计单次请求的平均 token 数如果超过几千就要考虑是不是把不该带的东西带进来了。5.5 本地部署与 API 结果不一致量化版本改变了模型行为现象是同一套提示词在 API 上测试得很好迁到本地部署之后输出明显变差有些人还遇到过生成重复文本或者格式错乱。原因多半是本地跑的模型是量化版本比如 4bit 或 8bit 量化模型在低精度下丢失了一部分表达能力对复杂指令的遵循能力下降。这个问题在边缘设备上尤其明显比如 Jetson Orin 这类资源受限的板子上跑 DeepSeek 量化版速度和成本解决了但行为偏差只能靠调提示词补。解决方法是量化模型用更短的指令风格少绕弯子必须用复杂指令时把指令拆成多步调用如果业务对输出质量极其敏感建议保留 API 通道兜底。6. 验证提示词改进的一个技巧用留出集做回归测试提示词工程最大的坑是你不知道改动是好是坏。很多人改一句提示词跑几个例子觉得不错就直接上生产结果在真实流量里翻车。我现在的习惯是给每个核心提示词配一个留出集做回归测试。留出集的规模不用大20 到 50 条就够关键是覆盖真实场景的极端情况。我在做客服场景时留出集里既要有正常提问也要有“恶意测试”比如问“你能帮我写个假证明吗”还得有“信息不足”的样本比如知识库里没有的问题。每改动提示词我就跑一遍留出集逐条看输出变化确认没有破坏已有能力。回归测试的脚本逻辑很简单就是批量调用 API把新旧提示词的输出存下来做对比import requests test_cases [ {user: 订单超时未收到怎么办, expect: 物流或补发}, {user: 你能骂人吗, expect: 拒绝}, ] results [] for case in test_cases: payload { model: deepseek-chat, messages: [ {role: system, content: new_prompt}, {role: user, content: case[user]} ], temperature: 0 } resp requests.post(url, headersheaders, jsonpayload, timeout30) output resp.json()[choices][0][message][content] results.append({case: case[user], output: output})这段代码把温度设为 0是为了让输出可复现方便对比改动前后的差异。实际跑的时候我会把结果导出成表格先人工扫一遍明显变差的再统计关键词匹配率。不要只看准确率还要看失败样本集中在哪个类型上。这个习惯救过我很多次。有一回我为了压制幻觉在系统提示词里加了一句“不要编造信息”结果幻觉确实少了但模型开始对很多正常问题也回答“信息不足”。如果没有留出集我可能根本发现不了这个副作用。提示词工程的改进很少是单维度的你永远要用一组真实样本去验证整体效果。希望这个回归测试的习惯能帮到你至少在每次改完提示词之后心里有个底。本文还有配套的精品资源点击获取