简介面向希望让DeepSeek输出更精准答案的技术开发人员一份提示工程进阶PDF系统讲解从Prompt基础回顾到实际优化的完整路径。内容包括DeepSeek模型的技术架构与性能特点、四类优化Prompt的策略特定指令关键词、结构化引导、示例驱动、长度与复杂度调整、上下文信息的获取与动态更新方法以及模糊表述、信息过载、引导偏差、约束缺失等常见陷阱的规避手段。文档还介绍了基于人工评分、BLEU/ROUGE自动评估的输出质量评估体系并配有智能客服、内容创作、教育辅导三个场景的优化案例与效果对比帮助读者在实际项目中灵活运用。资源包为单个PDF文件共18页大小1.89MB目录完整文字与图表均显示正常。目前已有181人学习下载适合希望系统掌握提示工程并提升大模型应用效果的开发者阅读。1. Prompt Engineering 不是玄学DeepSeek 输出质量的决定权在你的输入里接手过一个客服知识库项目模型从 GPT 换到 DeepSeek 之后原来那套提示词直接失效同一份合同摘要任务以前给三条要点现在能输出两千字散文。排查到最后问题不在模型能力在提示词和参数根本没跟着换。Prompt Engineering 在 DeepSeek 上之所以是刚需是因为它的指令遵循和上下文注意力分配有自己的脾气同样写法在不同模型上效果能差很远。这篇文章是把 DeepSeek 提示词从“能用”调到“稳定可交付”的完整路径覆盖原理理解、模板写法、参数调试、常见翻车现场和回归验证适合正在接 API、做本地部署、或者每天被模型答非所问搞到头疼的工程师。目标很直接看完你今天就能把提示词质量往上提一截。2. DeepSeek 的提示词原理与参数边界先搞懂它以什么为准再改提示词2.1 DeepSeek 按概率生成不是按关键词检索很多人第一次调 DeepSeek把搜索引擎那套“关键词命中”的思路带过来任务要“总结”就在提示词里放一堆“总结、归纳、提炼”。但 DeepSeek 本质上是一个自回归语言模型看到提示词之后不是去数据库里检索匹配项而是根据训练数据里学到的分布逐个预测下一个 token。这时候你的提示词相当于在“裁剪概率空间”你说“帮我总结”候选空间极大训练语料里“总结”这两个字关联的写法五花八门它自然会往任何一个看起来自然的方向漂。所以提示词的本质不是命令是给模型“框定边界”。你给的信息越具体、格式约束越明确模型的采样空间越小输出就越可控。这也是为什么“请总结这份合同”远不如“输出三段标的金额、违约责任、争议解决”来得稳。前一种写法把方向权交给了训练语料里的平均写法后一种写法直接锁死了输出结构。这里还要区分 DeepSeek 的两个常用模型deepseek-chat 和 deepseek-reasoner。前者适合绝大多数日常任务对输出格式的遵循能力更强后者会先走一层内部推理再给结论复杂推理任务更稳但有时候“想了半天没把想的内容完整落到输出里”。我一般建议先把提示词在 chat 版本上调通产品形态确认了再切 reasoner。如果你上来就用 reasoner 调格式会发现它在“输出固定结构”这件事上远没有 chat 听话这会浪费大量调提示词的时间。另外别把 DeepSeek 当黑匣子瞎试。它的行为虽然不透明但输入输出边界是能摸出来的。每次改提示词只动一个变量多跑几次看差异用不了多久你就能总结出适合当前场景的写法。黑匣子不可怕可怕的是你在没有对照组的情况下连续改五个变量最后连自己都不知道是哪个改动起了作用。2.2 温度、Top-P 与 max_tokens三个必调参数让输出不再“乱跳”提示词文本决定模型“想说什么”参数决定模型“敢说得多离谱”。DeepSeek 开放平台提供的 API 兼容 OpenAI 的 chat completions 格式所以 temperature、top_p、max_tokens 这组参数在其他模型上调过的话在这里语义一致。但推荐取值和交互方式有差异别直接套你之前的习惯。参数控制什么我常用的范围调低的效果调高的效果temperature采样随机性0.2~0.7输出稳定、照本宣科更有“创造性”也更爱跑题top_p核采样宽度0.8~1.0候选词少保守候选多发散风险增加max_tokens单次回答长度上限1024~4096可能把回答拦腰截断给足空间但会膨胀成本最常见的错误是 temperature 直接给 0.9 甚至 1.0然后抱怨 DeepSeek 答非所问。对绝大多数“给用户一个确定性答案”的应用场景temperature 不要超过 0.5。我自己的习惯是先固定 top_p1.0只调 temperature如果发现结果还是跳再往下压 top_p 到 0.9。不要同时调低两个参数否则你很难判断是谁起了作用。max_tokens 这里有个容易忽视的联动问题它不是“建议写多长”是“硬性上限”。如果你在提示词里写“请详细回答”模型会先尽情展开然后撞到 max_tokens 被截断用户看到一段没有结论的废输出。要控制篇幅直接在提示词里写“不超过 300 字”、“分三点每点 40 字以内”比单纯靠 max_tokens 靠谱得多。成本也是靠这一层省下来的。提示词里多一个“请详细展开”输出可能从 500 字涨到 3000 字API 账单立刻不一样。DeepSeek 的单价是一方面真正影响总价的是提示词质量导致的输出 token 膨胀。把一段模糊指令改成结构化要求输出长度能降一个数量级这也是提示词工程最直接的 ROI。2.3 先做基线实验用 API 把“感觉不好”变成“数字不对”在写任何复杂提示词之前先建立一个“基线”。没有基线你今天在聊天框随手测明天拿 API 批量调两边参数和 system prompt 都不一样那改提示词就纯靠玄学。我一般这么起步写一个最小的 API 调用脚本固定参数同一个提示词跑 5 次记录输出差异。只有先知道当前的“正常波动范围”后面改词才知道是变好还是变坏。import os from openai import OpenAI # DeepSeek 开放平台提供 OpenAI 兼容接口只是 base_url 不同 client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) def ask(system_prompt: str, user_content: str, temperature: float 0.3) - str: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperaturetemperature, top_p1.0, max_tokens2048, streamFalse, ) return resp.choices[0].message.content if __name__ __main__: system 你是合同审核助手只依据用户提供的文本作答不推测额外条款。 user 总结这份合同的违约条款输出违约情形、违约金计算方式、争议解决方式。 for i in range(5): print(f 第 {i1} 次输出 ) print(ask(system, user))代码逻辑很简单system 负责立人设和铁律user 只放任务。这里的关键是把 system 和 user 分离DeepSeek 对 system 消息的遵循程度比很多人以为的高你明确告诉它“不要推测额外条款”它就真的不乱编。temperature0.3 是保守配置适合抽取、分类、合同审查这类确定性任务max_tokens2048 给长文本留了空间但结合提示词里的“输出三段”约束它不会真写满。跑完 5 次之后正确的判断方式是看有多少次输出了你要求的三段结构。5 次里有 3 次都漏掉“违约金计算方式”那是提示词结构不够强不是随机波动5 次都齐了只是措辞略有差异那就是正常波动别管它。这个基线会是你后面所有工作的参照系。如果你用的是本地部署的 vLLM 服务API 参数结构基本一致。但要注意本地部署时你可能在启动参数里设置了 max-model-len 或 max-tokens 的上限提示词加输出总长度不能超过这个值。我遇到过同事在远端 API 上调好的提示词搬到本地部署后频繁截断最后发现是 vLLM 启动时 --max-model-len 设短了。任何部署方式的改动第一件事就是拿基线脚本重新跑一遍确认输出长度和稳定性没有变化。3. 五段式提示词模板让 DeepSeek 输出一个月不用改的可复用结构3.1 角色、任务、上下文、格式、约束一个模板解决 80% 场景我在 DeepSeek 上实践出来的一个规律提示词越“散装”模型输出越“散装”。与其每次现场想措辞不如固定一个五段式结构。这套结构适用于绝大多数文本生成、抽取、审核类任务模板如下你是【角色】。 任务是【任务描述】。 上下文 【背景信息、材料原文、用户输入】 输出要求 1. 【第一项内容】 2. 【第二项内容】 3. 【第三项内容】 约束 - 【禁止事项一例如“不得依据给定文本以外的信息推断”】 - 【禁止事项二例如“若信息不足请输出信息缺失项”】五个字段各干各的。角色字段限制模型的说话立场比如“你是合同审核助手”比“请帮我审合同”更稳因为它把模型的回答锚定在“审核员”这个专业身份上。任务字段只写目标不掺背景避免模型把背景当成任务。上下文字段放材料原文注意用分隔线或者引号包起来让模型知道哪部分是“事实”哪部分是“指令”。输出要求字段最关键它直接规定答案结构比任何“请认真回答”都有用。约束字段写红线比如“不要推测”、“不要编造”、“信息不足时明确说不知道”。这五段看起来简单但每一段都有对应的问题。有人习惯把角色和任务混在一起写“你是一个专业的合同审核助手请帮我总结违约条款另外注意合同里还有价款约定……”模型会分不清到底哪个是主要任务。有人不给输出格式模型自由发挥有人给了格式但不给约束模型在没有足够信息时会自己脑补内容。这五个字段缺一不可尤其是“约束”字段它决定了模型在边界情况下是老老实实说“不知道”还是硬编一个答案。3.2 三个可以直接改的行业模板技术文档、数据抽取、代码审查五段式不是空架子下面给三个真实场景下的可用模板。第一个是技术文档生成适合给 GitHub 项目写 README 或接口说明。第二个是数据抽取适合合同信息录入、发票结构化。第三个是代码审查适合合并请求前的自动化检查。技术文档模板你是资深后端工程师熟悉 Spring Boot。 任务是为下面这段接口代码写 README 中的“接口说明”章节。 上下文 【粘贴接口代码】 输出要求 1. 接口路径和方法 2. 请求参数表格 3. 响应结构示例 约束 - 只写代码中能确认的内容不要补充代码里不存在的字段 - 响应示例用 JSON 格式这个模板里关键在“不要补充代码里不存在的字段”。DeepSeek 很擅长“合理推测”但推测出来的字段往往是错的排查起来非常费劲。数据抽取模板你是数据录入员。 任务是从下面的合同文本中抽取指定字段。 上下文 【粘贴合同原文】 输出要求 1. 合同编号____ 2. 签约日期____ 3. 付款方式____ 4. 违约金比例____ 约束 - 原文中没有的字段输出“未找到”不要根据常见合同条款推断 - 日期统一为 YYYY-MM-DD 格式做数据抽取最容易翻车的就是“模型觉得应该有违约金条款然后编了一个比例出来”。把“未找到”作为合法输出写进去模型才知道“不知道”和“猜一个”哪个是被鼓励的行为。代码审查模板def review_code(function_code: str) - str: system 你是资深技术专家只指出确凿的问题不进行风格争论。 user f审查下面这段代码输出 1. 潜在 Bug按严重程度排序 2. 安全隐患 3. 建议修改 代码 python {function_code}约束不要提出“变量名可以更有意义”这类建议每个问题必须指出具体代码行 return ask(system, user)这里在 Python 函数里直接拼提示词是为了把模板封装成 team 内部可调用的工具函数。模型输出质量的关键在第二行“只指出确凿的问题”配合约束里的“必须指出具体代码行”它就不敢只给空泛建议了。 ### 3.3 把提示词封装成工程资产配置文件与版本管理 提示词写好了别存成一个 txt 躺在个人电脑里。常见做法是把模板配置化用 JSON 或 YAML 存放代码里只配置文件路径。好处很直接换模型、换场景、调措辞不用改代码改配置文件就行。 json { name: contract_review, model: deepseek-chat, system_prompt: 你是合同审核助手只依据用户提供的文本作答。, user_template: 总结这份合同的违约条款输出违约情形、违约金计算方式、争议解决方式。, parameters: { temperature: 0.3, top_p: 1.0, max_tokens: 2048 } }然后把调用封装成通用函数import json def load_prompt_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) config load_prompt_config(prompts/contract_review.json) result ask( config[system_prompt], config[user_template], temperatureconfig[parameters][temperature], )这样改提示词的成本就降到了“改 json 文件 提交 git”。我见过太多团队把提示词写在硬编码的代码里AI 产品经理想调一句措辞都要等开发排期。把提示词放进配置文件配上版本号每次改动可回溯这才是工程化的做法。等你在 vLLM 本地部署场景下重复实验时这种结构化的方式会大幅降低维护成本。4. 进阶技巧思维链、少样本与上下文续接的三个高杠杆动作4.1 思维链提示让推理任务从“瞎猜”变成“步步有据”DeepSeek 在复杂推理任务上的表现很大程度上取决于你是否给了它“思考路径”。直接问“这个算法的时间复杂度是多少”模型可能凭训练记忆给一个答案改成“请先分析代码结构再指出循环层数最后给出结论”它的输出就会有明显的逻辑层次。这就是思维链的基本用法不只是要结果还要中间步骤。你是算法工程师。 任务是分析下面这段代码的时间复杂度。 思考步骤 1. 先指出外部循环的迭代次数与输入规模 n 的关系 2. 再指出内部循环是否嵌套 3. 计算总操作次数 4. 给出 Big-O 结论 代码 【粘贴代码】 约束 - 如果代码中存在条件分支按最坏情况计算 - 结论必须给出推导过程不能只写 O(n)这段提示词的力量在于“思考步骤”把推理过程切成了四步。DeepSeek 不是真的按这个步骤去思考而是每一步都在缩小最终答案的采样空间。它先回答了第 1 步第 2 步就必须在第一步的结果上继续这样就不太可能在第三步给出一个前后矛盾的结论。但思维链不是万能的。如果任务本身就是简单分类比如“判断这句话是正面还是负面”加思维链反而会让输出冗长而且可能在中间步骤里引入不必要的歧义。我的判断标准是任务需要多步逻辑推导就加思维链单步判断就不加。另外reasoner 版本内部本来就有推理过程你再用思维链提示去约束它两层推理叠加反而可能让输出变得啰嗦。用 chat 版本时思维链是利器用 reasoner 版本时可以先只给“输出格式”让内部推理自由发挥。4.2 少样本示例给得对比给得多重要很多人以为 few-shot 就是拿几个例子塞进提示词效果就是“越多越好”。在 DeepSeek 上我踩过坑给 5 个格式不统一的示例输出格式跟着乱给 3 个格式统一的示例效果反而很好。原因在于少样本提示的价值不在增加信息量而在建立“格式锚点”。模型从中提取的不是知识点是“你期望的输出长什么样”。你是客服质检员。 任务判断下面客服对话是否违规。 对话1 用户我要投诉你们平台。 客服您别急我帮您转接专员。 输出合规 对话2 用户你们是不是骗子 客服这东西我不清楚你找别人吧。 输出违规——消极回应 对话 【新对话内容】 输出两个例子就够了。第一个例子告诉模型“正常回应”长什么样第二个例子告诉模型“负面边界”在哪。关键点是两个示例的格式完全一致“对话→编号→输出→结论”。如果你第一个示例输出写成“这条是合规的因为客服态度良好”第二个示例写成“违规”模型就会困惑到底该输出简短结论还是完整解释。示例的选择也有讲究。选“典型成功样本”和“典型失败样本”比选两个成功率样的效果更好因为模型需要知道边界在哪。另外我一般不会给超过 4 个示例少样本提示的收益在 2 到 3 个时最明显再多就会引入噪声。代码生成场景下尤其如此超过 4 个代码示例之后模型经常会把示例里的变量名、函数名带到新输出里产生幻觉。4.3 超过了对话上限新对话里怎么承接上一个对话的记忆用 DeepSeek 做长对话任务时总会撞到对话上限要么是 API 上下文窗口长度限制要么是应用层设定的最大消息轮数。常见的做法是“摘要 注入”在旧对话即将结束时让模型把关键信息压缩成摘要然后新对话的 system 提示里带上这个摘要。这不是什么高深技巧但它能救回 80% 的断片问题。def compress_history(messages: list, max_len: int 2000) - str: # 超长时只保留消息末尾部分前边压缩成摘要 if len(str(messages)) max_len: return messages_to_text(messages) recent messages[-4:] # 保留最近 4 条保留“当前进行到哪一步”的信息 old messages[:-4] summary_prompt ( 你是对话记录员。下面是用户与助手的旧对话请压缩成100字以内的摘要。 重点保留任务目标、已确定的结论、待办事项。忽略寒暄。\n\n f对话记录\n{old_text(old)} ) summary ask( 你是对话记录员只输出摘要本身。, summary_prompt, temperature0.2, ) return summary \n\n【最近对话】\n messages_to_text(recent)这段代码的思路是把旧对话历史丢给模型压缩成短摘要再把摘要和最近几条原始消息拼在一起作为新对话的上下文。摘要捕获了“任务目标和已定结论”最近的原始消息保留了“当前正在聊什么”。两部分合起来新对话就不会把前面的内容忘光。这里有个很重要的工程判断别把整个历史原封不动搬到新对话。DeepSeek 的上下文窗口虽然不小但塞满历史记录会稀释提示词权重模型会更关注最后的消息而遗忘前边的内容。摘要的本质是“上文的语义权重归一化”。你主动挑了最重要的信息放进去模型才会把注意力放在关键点上。我一般在每一轮对话结束后就维护一个“全局摘要”而不是等到撞了上限才开始压缩。这样新对话的上下文永远是“摘要 最近几轮”既不会超限也不会丢失前文意图。5. DeepSeek 提示词避坑指南五个翻车现场、原因与排查方向5.1 现象让模型“自由发挥”结果变成散文生成器有一次我让 DeepSeek“介绍一下这个项目的技术架构”它洋洋洒洒写了一千多字从背景讲到未来展望核心的架构细节只占了最后两行。原因很简单提示词里没有给输出结构模型只能按训练语料里“技术架构介绍”的平均结构去写那自然是宽泛的叙述文。解决方法是把“输出要求”字段补上先让你用 5 个关键词概括架构风格然后按模块列出核心组件每个组件一句话。模型一旦知道格式就会放弃写散文。5.2 现象同一个提示词五次输出五个版本如果你跑五次每次结果差异大到像换了个模型第一个要查的是 temperature。很多人沿用通用模型的习惯设置了 0.9但在 DeepSeek 上这个值会让同样一段合同文本每次提取出的条款都不太一样。解决方式是先把 temperature 降到 0.2 到 0.3固定 top_p1.0重新跑五次看稳定度。注意如果 temperature 已经很底了还是不稳定那问题多半在提示词里给了模型太多“二选一”的空间比如“如果甲方违约则输出 A否则输出 B”这属于任务本身的歧义需要用输出格式进一步收紧。5.3 现象少样本示例给了好几个模型反而跟着示例跑偏给示例的本意是引导格式但如果你给了一个输出长度很长的示例和一个输出很短的示例模型很容易学走“最多字”的那个。我还遇到过给代码修复示例时示例里用了某个变量名结果模型在修新代码时沿用了一样的变量名看起来没问题实际和项目其他模块对不上。解决方式控制示例数量在 2 到 3 个并确保示例之间格式严格统一。如果发现模型反复模仿示例里的内容而不跟随任务指令可以尝试把示例放到 user 消息里而不是拼在 system 里这样模型更容易把它当作“参考材料”而不是“必须模仿的模板”。5.4 现象长对话聊到后面模型把早先说过的结论丢了这是上下文窗口问题。模型不是“忘记”结论而是早期信息在注意力中占比过低被后面大量的新消息稀释了。解决方式是在对话过程中持续维护一个全局摘要。每轮对话结束后把“用户目标、已确认决策、待处理项”写入摘要字段并在下一轮的 system 提示中带上这个摘要。很多开发者在对话轮数超过 20 轮后才想着处理实际上应该在轮数达到 5 轮左右就开始维护摘要这样模型在一开始就能获得每个阶段的关键状态。5.5 现象要求模型输出 JSON它却给了一堆 Markdown 和解释这是结构化输出最常见的翻车现场。你在提示词里写“请输出 JSON”模型确实输出了 JSON但外面包着一层 code block 标记前边还带着一句“好的这是结果”。下游解析 JSON 的代码直接报错。原因是你没有告诉模型“只输出 JSON不要任何多余字符”。解决方式有两个层面提示词层面明确写“只输出 JSON不要使用 Markdown 代码块不要输出任何前缀”工程层面用正则先从输出中提取第一个 “{” 到最后一个 “}” 之间的内容再做解析。两个层面都要做因为任何模型都可能在长文本输出里加料后处理是最后一层安全网。import json, re def safe_parse_json(text: str) - dict: # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 退一步提取大括号内容 match re.search(r\{.*\}, text, re.DOTALL) if match: return json.loads(match.group(0)) # 实在是没辙单独提取每个字段 result {} for key, value in re.findall(r(\w):\s*([^]*), text): result[key] value return result这段兜底代码在本地部署和在线 API 场景我都用过。第一层直接解析常见格式第二层应对被代码块包裹的情况第三层应对模型胡邹的情况。注意第三层是有损的它拿不到嵌套结构但总比让整个流程崩溃好。工程上要记住提示词再准也只能调高概率没法保证 100% 格式合规后处理永远是最后一道防线。6. 让提示词持续变好用回归测试集锁定每次改动提示词工程里最容易犯的错是“这次感觉不错就上线了”。但模型输出有随机性今天感觉不错明天换一段用户输入可能一塌糊涂。我现在的习惯是维护一个回归测试集挑 20 到 40 条覆盖你场景边界的输入每次都把所有测试案例跑一遍对比新旧提示词在每一个样例上的表现差异。这套方法不复杂但能把提示词调优从“手感”变成“可重复的工程过程”。test_cases [ {name: 正常合同, user: 合同文本A, expect: [违约情形, 违约金]}, {name: 缺少违约金条款, user: 合同文本B, expect: [未找到]}, {name: 英文合同, user: english contract, expect: [标的金额]}, {name: 极短输入, user: 只有一句报价, expect: [未找到]}, ] def evaluate(system_prompt, cases): passed 0 for case in cases: output ask(system_prompt, case[user], temperature0.2) ok all(kw in output for kw in case[expect]) print(f{case[name]}: {PASS if ok else FAIL}) passed ok print(f通过率: {passed}/{len(cases)})评估逻辑很简单每个测试用例里定义期望出现的关键词输出中全部包含才算通过。比如“缺少违约金条款”这个用例期望的是“未找到”出现如果模型硬编了一个 10% 的违约金比例这一条就会判失败。你可以用这个脚本作为基准每次改提示词时跑一次通过率必须不低于上一次才能提交。同时搭配上一章讲的 JSON 解析兜底和格式检查就能组成一套针对提示词质量的回归验证流程。流程走到这一步你就有了完整的方法论从理解 DeepSeek 的生成原理到用五段式模板控制输出结构再到用思维链和少样本提推理质量最后用回归测试集守住每一次改动的底线。我踩过最多的坑就是“凭感觉改提示词”——改了十几次结果越改越偏最后发现自己连最初的基线都丢了。所以后来的习惯是任何一次提示词改动必须带着对比数据来说话。如果你也想让团队把提示词当正经工程来做先从一个 20 条用例的回归集开始比讨论任何理论都管用。希望这条路径能帮到你让你少走我当初那些弯路。本文还有配套的精品资源点击获取