DeepSeek 提示词工程实战：从对话到任务交付的完整指南

简介大模型的能力边界由提示词质量直接决定。提示词工程Prompt Engineering正是通过结构化指令设计引导模型生成更准确、更可控的文本。其核心原理在于将模糊需求拆解为指令、背景、输入、输出四要素并利用角色设定、思维链、少样本示例等技术约束模型的推理路径从而提升生成结果的稳定性与工程可用性。这类技术广泛应用于自动写作、代码生成、文本分析、智能客服和批量数据处理等场景。以国产大模型 DeepSeek 为例掌握提示词设计不仅是提升对话质量的技巧更是将 AI 嵌入业务流、实现任务交付的关键能力。从 API 调用到上下文管理从输出格式硬约束到多轮自查完整的提示词工程体系能帮助开发者大幅降低调试成本让 AI 应用真正落地。 好的这是根据标题“DeepSeek 从入门到精通 清华大学版”的要求生成的实战笔记。1. 先从结论说起这份资料教会你的不是“聊天”是“提需求”网上热传的那份高校整理版《DeepSeek 从入门到精通》我拿到手之前以为又是一份“模型说明书”翻完才发现它真正解决的是一个很实际的问题大部分人把大模型当成搜索引擎在用问一句等一句得到的答案自然又散又浅。真正能拉开差距的是把提示词当成一份需求文档来写。这篇文章不逐页复述那份资料而是顺着它的体系把“怎么从一个只会对话的人变成一个能交付任务的人”讲清楚每一章都能照着操作。适合刚接触 DeepSeek 不久、想用它做写作、代码和数据分析但还不知道提示词怎么设计的从业者。2. 先跑通最小闭环从网页对话到 API 调用的完整链路在谈任何技巧之前先把地基打牢。绝大多数人刚开始都是用网页对话框在和大模型交互这个习惯本身没有问题问题在于网页对话和程序化调用是两种完全不同的使用方式。前者适合来回试探、打磨思路后者适合把打磨好的思路固化成一条稳定产出结果的链路。我见过不少同事在网页里跑通了一段对话就以为可以把它搬到生产环境里结果一碰批量任务就各种翻车。所以这一章先把两个入口的边界划清楚。2.1 两个入口的不同定位为什么我建议先网页后 API网页对话的核心优势是低成本试错。你可以随意换说法、拆问题模型回答慢了也不会心疼成本。API 调用则适合两件事一是批量处理比如一次要生成三十份周报二是把提示词嵌入到自己的业务系统里比如做一个自动审合同的小工具。注意它们在模型能力和行为上并没有本质差别同一个模型在两端用的都是同一套推理逻辑差别只在于你对输入输出的控制粒度。所以我一般会先要求自己或者团队里的新人在网页端把提示词改到“连续三次输出都稳定达标”再考虑写代码。这个习惯能省掉大量调试接口的时间。反过来如果一开始就上代码你会很难判断效果差到底是提示词写得不好还是参数设置不对变量太多问题就不好定位。入口适合场景成本特征可控性网页对话思路探索、提示词打磨按对话计费单价低低无法精细控制参数API 调用批量任务、系统集成按 token 计费量大有优惠高temperature、max_tokens 均可调这里要特别提醒一点网页对话和 API 的上下文策略不完全一致。网页端通常会帮你隐藏一些系统层面的处理API 端则是你给什么 messages 它就带什么 messages 去推理所有历史记录都要你自己管理。网上那些“模型怎么突然失忆了”的抱怨绝大多数都在 API 场景下发生的原因就在上下文是自己维护的。2.2 最小可用的调用脚本一个请求看清全貌不要把第一步想复杂。我一个最简单的 HTTP 请求就能把 DeepSeek 的调用链路跑通不需要引入任何第三方库只要环境里有requests就行。下面这个脚本就是最小闭环import requests # 请求体messages 是对话历史列表model 指定模型其余是生成参数 payload { model: deepseek-chat, messages: [ {role: system, content: 你是一名严谨的技术文档编辑。}, {role: user, content: 把下面这段文字改写成三个要点\n大模型的效果既取决于模型本身也取决于提问方式。} ], temperature: 0.7, max_tokens: 512, } resp requests.post( https://api.example.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, jsonpayload, timeout60, ) # 解析返回结构choices 里是模型生成的候选结果 data resp.json() print(data[choices][0][message][content])这个脚本里有三个关键点值得展开说。第一messages是一个列表列表里每个元素有role和content两个字段。system说的是系统级指令用来设定整体行为user是用户输入后续如果需要多轮对话就继续追加assistant和user。顺序很重要模型是按这个顺序理解上下文的不要把 system 放到后面。第二temperature控制的是生成时的随机程度。0 到 1 之间取值值越接近 0输出越确定越接近 1花样越多。这个参数在后面的避坑章还会再提到这里先记住一句话事实类任务用低温度创意类任务用高温度。第三max_tokens限制的是生成的最大长度不是对话总长度。512 表示模型最多输出约 512 个 token如果你的任务需要长文输出比如写一篇两千字的方案这里要预留足够空间否则内容会被硬生生截断。2.3 上下文机制为什么模型“记得”前面的话是因为你每次都把历史传给了它很多新手会误以为模型“记住”了之前的对话。实际上模型本身没有记忆它每次生成都是基于当前请求里的完整 messages 列表重新推理的。所谓“上下文”其实就是你放在 messages 里的历史记录。你传多少、传什么直接决定模型能不能“想起”前面聊过的事。这就引出一个非常实际的建议多轮对话中不要无脑把全部历史都塞进去。上下文窗口是有限的窗口一旦被塞满早期信息会被挤出去或者被压缩得面目全非。我在处理长任务时会定期做一次“历史摘要”——把已经聊过的内容总结成一段一两百字的概述放到 system 里后面继续对话就基于这个摘要展开。这样既保留关键信息又不浪费窗口空间。# 伪代码长对话中的上下文压缩策略 history [] # 原始历史 summary 用户正在写一份产品方案核心卖点已确定…… messages [ {role: system, content: f以下是之前对话的摘要{summary}}, {role: user, content: 继续刚才的话题给出第二章的框架}, ]这段伪代码展示了压缩策略的核心思路用一个摘要占位符代替整段历史。代价是会丢失一些细节但换来的是相对稳定的长对话体验。这也是我处理所有长任务的默认方式。3. 提示词工程的四个要素把对话从“碰运气”变成“有结构”如果你在网页里和 DeepSeek 聊天感觉时好时坏问题大概率不在模型而在提示词的结构性太差。高校整理版那份资料里最有价值的部分就是把提示词拆成了几个可用要素指令、背景、输入、输出。这四个词分别回答“做什么”“在什么情况下做”“对什么做”“做成什么样”。我不会把这套框架说得过于理论化直接讲它怎么落到实际写作中。3.1 指令、背景、输入、输出一份提示词的骨架我先给一个最简模板你写任何提示词都可以先按这个骨架填空【指令】请基于用户提供的对话记录提取本周待办事项。 【背景】这是一份销售团队的周会记录会议时间为一小时。 【输入】以下是会议记录的原始文本…… 【输出】请以列表形式输出每条待办包含负责人和截止日期。这套框架的厉害之处在于它把原本口头化的需求变成了结构化描述模型不需要去“猜”你要什么。很多时候模型答得不对不是因为笨而是因为你只给了它一句话它只能在多种理解里选一个最可能的赌错了就翻车。四要素里最容易漏的是背景。同样一句话“总结一下”放在技术方案评审和放在销售周会上总结的侧重点天差地别。把背景写清楚等于帮模型缩小了理解范围这是性价比最高的一步。3.2 一个可抄的完整示例把模糊需求改造成四要素提示词很多人的第一反应是“我哪有时间每次写这么多”。这确实是门槛但换个角度看一份四要素提示词通常也就三四行字写完之后可以反复用。下面这个例子是我实际工作中常用的一种写法从模糊到结构化的对照能很直观地体现差距。# 模糊版 帮我把这段录音转的文字整理一下去掉废话。 # 四要素版 【指令】将以下采访录音转写文本整理为有效问答片段。 【背景】这是一段面向开发者社区的访谈受访者在解释某个新框架的设计取舍。 【输入】 此处粘贴转写文本 【输出】 1. 按“话题 - 核心观点 - 原文依据”三段结构输出 2. 删除口头语、重复表达和不完整句子 3. 每个话题不超过 200 字。这个例子里模糊版只给出了“想做什么”四要素版把“这是什么东西、要对什么做、答成什么样”都交代清楚了。效果差别在多次运行后非常稳定模糊版每次输出的结构都不太一样四要素版则能保持同样的骨架只替换骨架里的内容这对需要批量处理文本的人来说极其重要。3.3 把输出格式变成硬约束让模型直接产出 JSON如果说四要素是提示词的地基那么输出格式就是承重墙。在“程序要消费结果”的场景里写清楚输出格式比什么都重要。模型默认输出是人类可读的自然语言如果你让它“给我 JSON”它很可能给你一段嵌在解释文字里的 JSON解析的时候还得做一轮清洗。正确的做法是告诉模型“只输出 JSON不要输出任何解释性文字”。下面这个例子展示了我常用的写法prompt 请分析以下评论的情感倾向只输出 JSON不要输出任何解释或前言不要用 Markdown 代码块包裹。 评论这个新版本的上手速度比预期快很多但文档还是跟不上。 输出格式 { sentiment: positive|neutral|negative, confidence: 0.0-1.0, reason: 判断依据一句话 } 注意我在格式里写了reason字段并要求是“一句话”。这一步是故意留的让模型为判断给出一句话依据能显著提升情感判断的质量因为它被迫走了一遍推理过程而不是凭第一个直觉选一个标签。sentiment字段用了竖线分隔候选项也是一种很实用的写法它比写“请输出正面、中性或负面”更不容易被模型理解成其他答案。这套输出约束在批量场景里价值最大。你可以直接把模型返回的 JSON 丢给下游程序中间完全不需要人工介入。这是“会聊天”和“会交付”之间最关键的一道分水岭。4. 场景化进阶从“会写提示词”到“能交付任务”前面两章解决的是“对话质量”问题这一章解决的是“任务完成度”问题。一份提示词写得好不代表它能在真实场景里稳定完成任务。真实场景里还有两个影响因素模型的推理路径是否受控以及任务本身是否被你拆得足够小。这四个小节分别讨论角色设定、思维链、少样本示例和多轮自查它们是高校整理版资料里进阶部分的核心也是我日常使用频率最高的四类技巧。4.1 角色设定什么时候用什么时候反而拖后腿给模型设定一个角色本质上是帮它选定一个回答风格和知识侧重。写技术文档时设定“你是一名严谨的技术编辑习惯先列要点再展开”写广告文案时设定“你是一名擅长制造悬念的营销文案”。这两个例子说明角色设定的本质是风格约束而不是真的让模型“变成”谁。但角色设定不是万能的。当任务本身是事实判断类比如“这段代码有没有内存泄漏”“这份数据里有没有异常值”角色设定基本没有帮助因为答案的正确性由模型能力和上下文决定和语气关系不大。我见过有人把角色设定写成长达几百字的“人设小传”结果反而把任务指令挤到上下文边缘导致跑题。角色设定最多两句话且应紧贴任务本身。这也是一个“为什么这么选”的典型场景。4.2 思维链与少样本示例让模型沿着你的路径走思维链的做法很简单让模型在给出结论之前先输出推理步骤。常见写法是“请先一步一步思考再给出最终结论”。它的价值在于迫使模型把隐式判断变成显式推理尤其适合数学题、逻辑推断、代码排查这类需要中间过程的场景。需要注意配套动作把 temperature 调到 0 到 0.3 之间否则推理路径会发散。少样本示例则是另一条路给模型展示一两个“输入到输出”的完整例子让它模仿这个映射关系。它和思维链可以叠加使用先给示例再要求推理。reasoning_prompt 任务判断下面这段代码是否存在资源泄漏问题。 规则先一步步分析资源的获取和释放路径再给出结论。 示例 输入打开文件后在异常分支里没有关闭文件。 分析文件在 try 块中打开except 分支直接 return文件对象没有被关闭。 结论存在资源泄漏。 输入使用 with 语句打开文件并写入数据。 分析with 语句会在代码块结束后自动调用关闭操作。 结论不存在资源泄漏。 待判断代码 def read_config(path): f open(path) data json.load(f) if timeout not in data: return 60 return data[timeout] 这里我给了一个“示例 规则 待判断代码”的组合。示例的作用是告诉模型你期望它给出什么样的推理粒度规则做了行为约束而最后输入的代码才是真正要处理的对象。这种提示词在生产环境中效果稳定因为模型不需要现场猜测你应该需要多详细的推理。如果把示例去掉模型可能会直接给结论也可能给出很长一段不聚焦的推理输出质量就不受控了。4.3 一个完整的交付案例从杂乱的会议记录到结构化待办把前面所有技巧串起来的最好方式是走一个完整案例。场景是我处理一段会议记录转写需求是整理成待办事项。你完全可以直接套用这个提示词结构替换输入文本即可。【指令】将以下会议转写文本整理成待办清单。 【背景】这是产品团队的一次周会参与者包括产品经理和两名开发。 【输出要求】 - 每条待办包含任务描述、负责人、截止时间 - 截止时间不明确的标注“待确认” - 只输出表格不要输出任何开场白或结尾总结。 【输入】 粘贴原始会议记录长度不限这个提示词是四要素、输出硬约束和角色背景的组合应用。做这个任务的关键难点是把口语化的表达映射到“负责人、时间”这些结构化字段上模型能不能做好取决于背景信息是否充分。我一般会先在网页里测试一版看输出的表格有没有错误归因再决定要不要改提示词。4.4 多轮自查让模型先答再查再交付最后介绍一个提升可靠性的习惯让模型自己当一回“审稿人”。具体做法是在第一轮输出之后追加一条消息内容是让模型检查自己的回答是否满足原始要求。这个技巧对付两类问题特别有效一是输出格式不统一模型第一轮可能偶尔漏字段让它自查就能补上二是内容不够完整比如漏了某个角度的分析自查时会主动补齐。用户请按以上要求检查你刚才的回答重点核对两点1. 是否覆盖了所有输入文本中的关键信息2. 输出格式是否与要求完全一致。发现不足请直接输出修订版不要解释。有人会觉得这是“多此一举”但从效果看一轮自查付出的额外时间和成本非常低换来的是输出稳定性的明显提升。在批量任务里我会更多轮几次直到连续两轮输出完全一致为止。5. 避坑提示词调试中的 5 个高频问题与排查思路这一章写的是我在接入和使用 DeepSeek 过程中真实遇到过的坑。每一条都按“现象—原因—解决”来记录方便你直接对照排查。5.1 模型答非所问回了一堆正确但没有用的内容现象问“这个方案有什么风险”模型答了“什么是方案”“方案的重要性”之类的背景知识完全没有落到你的方案上。原因提示词里没有交代背景模型只能猜测一个通用的回答方向。它对你的业务一无所知自然只能给出正确的废话。解决把和问题直接相关的背景写进 system 或 user 内容里。哪怕一句话也好。比如“背景我们正在评审一份机房搬迁方案目前处于可行性分析阶段”。加了背景之后模型的回答会立刻从“泛泛而谈”变成“针对当前场景”这个差别是最明显、也是修复成本最低的。5.2 输出格式不稳定说了“输出 JSON”结果带了一堆解释现象明明提示词里写了“输出 JSON”模型却先来一句“好的以下是分析结果”再把 JSON 放在代码块里。程序端解析时要多写一堆清洗逻辑。原因对模型来说“输出 JSON”是一个软约束它会理解成“在回答中嵌入 JSON”而不是“整个回答只包含 JSON”。解决把指令改成“只输出 JSON不要输出任何解释性文字不要用代码块包裹”。如果接口支持结构化的输出格式参数也建议打开。在提示词中加入“只”这个字比单纯说“请输出 JSON”可靠得多。5.3 长对话越聊越笨更早之前的信息全被遗忘了现象对话进行到二十轮以后模型开始重复问已经确认过的问题或者跟前面的决定矛盾。原因上下文窗口被大量历史消息占满早期关键信息被截断或压缩。这不是模型“失忆”而是你把它能看到的窗口塞爆了。解决定期做上下文摘要具体做法见 2.3 节。另外及时关闭已经结束的话题不要在一段对话里做完全无关的多个任务。我习惯“一个任务一段对话”比强行在一个会话里切换主题更稳。5.4 提高 temperature 之后事实错误变多了现象为了让回答“更有创造力”把 temperature 调到 1.0 以上结果模型在事实描述里开始编造细节。原因temperature 本身不是“创意开关”而是采样随机性。值越高模型越倾向于选概率较低的词编造的可能性也随之上升。解决事实类任务把 temperature 控制在 0.2 以下创意文案可以适当调高但不要超过 0.9。如果确实需要“稳定的创造力”应该用“给出多个可选方案”这样的提示词手段而不是抬高温参数。5.5 长文本输出总是被截断内容到一半就停了现象让模型写一篇两千字的文章写完一千字左右就戛然而止也没有任何提示。原因max_tokens 限制的是单次生成的最大长度。默认值往往偏小输出超过上限就会被截断而且这个过程是静默的模型不会告诉你。解决在调用接口时显式调大 max_tokens。如果单次要生成的内容超过上限就把任务拆成“分段生成”或“先生成框架、再逐段展开”两步来做。分段生成时前面章节的摘要和已写内容可以作为 prompt 一部分传给后续轮次保证风格统一。5.6 排查套路遇到问题先按这个顺序检查排错和分析代码一样是有固定顺序的。我通常在五秒内就能定位大部分提示词问题靠的是下面这套顺序检查背景是否缺失模型回答空泛优先补背景信息。检查输出要求是否明确格式乱、字段缺优先加“只输出”“不要解释”等硬约束。检查历史上下文是否过长表现是越聊越乱优先压缩历史。检查参数是否匹配任务事实任务高温、创意任务低温都是常见误配置。检查输入是否真的有信息量如果输入本身信息密度极低模型巧妇难为无米之炊。这套顺序的价值在于它能帮你把“模型不行”的猜测换成具体的、可修改的变量。绝大多数问题都指向提示词而非模型本身这也是我想强调的一点。6. 最后一章把提示词当代码管版本化、回归测试和组合复用判断你是否“精通”DeepSeek 提示词不需要看你记住了多少模板只需要看一个习惯是否开始把提示词当成代码一样管理。我现在做任何提示词工程都遵循三条纪律。第一条是版本化。每份提示词单独存放一个文本文件文件名写清版本号和用途改动之后立刻存为新版保留上一版方便效果变差时快速回退。这个习惯救过我好几次某次调整输出格式后模型表现突然下滑十分钟内就通过对比旧版本定位到是新加的字段约束导致了理解偏差直接回退就是后悔药。第二条是回归测试。维护一个固定的小测试集里面放十到二十条有代表性的输入任何提示词改动都跑一遍测试集对比输出肉眼查看结构是否一致。这套做法让提示词不再是“玄学”而是一个可验证的工程产物。第三条是组合复用。把一份提示词拆成若干最小单元比如“摘要单元”“格式转换单元”“质量检查单元”再用 Python 脚本按顺序组合。大任务拆成小提示词串联不仅不容易超长而且每个环节都能单独调优。这三个习惯做到之后提示词就不再是散落在聊天记录里的灵感而是一笔可以复用的资产。我现在接到一个新的文本处理需求第一件事不是查模板而是写一版四要素草稿、跑一遍测试集、再把结果交给下游程序。这套流程用了很久稳定可靠。希望帮到你。本文还有配套的精品资源点击获取