DeepSeek 提示词工程全指南：从参数调优到五段式模板的实践路径

简介：面向希望让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.9 甚至 1.0，然后抱怨 DeepSeek 答非所问。对绝大多数“给用户一个确定性答案”的应用场景，temperature 不要超过 0.5。我自己的习惯是先固定 top_p=1.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_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) def ask(system_prompt: str, user_content: str, temperature: float = 0.3) -> str: resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_content}, ], temperature=temperature, top_p=1.0, max_tokens=2048, stream=False, ) return resp.choices[0].message.content if __name__ == "__main__": system = "你是合同审核助手，只依据用户提供的文本作答，不推测额外条款。" user = "总结这份合同的违约条款，输出：违约情形、违约金计算方式、争议解决方式。" for i in range(5): print(f"==== 第 {i+1} 次输出 ====") print(ask(system, user))

代码逻辑很简单，system 负责立人设和铁律，user 只放任务。这里的关键是把 system 和 user 分离：DeepSeek 对 system 消息的遵循程度比很多人以为的高，你明确告诉它“不要推测额外条款”，它就真的不乱编。temperature=0.3 是保守配置，适合抽取、分类、合同审查这类确定性任务；max_tokens=2048 给长文本留了空间，但结合提示词里的“输出三段”约束，它不会真写满。

跑完 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", encoding="utf-8") as f: return json.load(f) config = load_prompt_config("prompts/contract_review.json") result = ask( config["system_prompt"], config["user_template"], temperature=config["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, temperature=0.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_p=1.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"], temperature=0.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 条用例的回归集开始，比讨论任何理论都管用。希望这条路径能帮到你，让你少走我当初那些弯路。

本文还有配套的精品资源，点击获取