简介这份PDF由厦门大学软件和人工智能专家程希冀主讲主题是DeepSeek提示词设计与幻觉规避同时兼谈Manus智能体。内容面向AI开发研究人员、提示词工程爱好者及希望更高效使用大模型的职场人群、教育工作者和普通用户重点解决“AI越来越聪明提示词是否还重要”这一核心困惑并通过推理型与非推理型模型的对比给出差异化的提问策略。资源为单个PDF文件大小约2.27MB已有248人学习。讲解从“人机预先默契”说起梳理了DeepSeek-R1与V3的不同性格、思维链CoT适用场景、六何分析法5W1H等实用技巧还演示了如何设计提示词让AI生成炫酷图表和动画。针对AI幻觉现象文档提出了限制知识来源、明确时间界限及检索增强框架等应对策略帮助读者在降低错误输出的同时提升对话系统的可靠性与实用性。适合想系统掌握提示词设计方法并规避AI幻觉风险的各类学习者。1. DeepSeek提示词设计为什么同一个人用效果能差出一倍手上拿到一份题为《2025厦门大学DeepSeek提示词设计、幻觉避免与应用》的PDF第一反应是这年头讲提示词的材料太多了但真正能把 DeepSeek 提示词设计、幻觉避免、应用落地串成一条完整链路的确实稀缺。这份材料好就好在它不是拿通用大模型的提示词套路硬套 DeepSeek而是从模型自身的指令遵循特性、解码参数和上下文管理出发给了能直接复现的写法。对从业者来说这份材料要解决的是两类痛点。一类是提示词写了跟没写一样模型输出空泛、说教、答非所问另一类是看似答得很顺实际上数字、引用、专有名词全在编也就是幻觉。前者浪费调优时间后者直接把 AI 应用挡在生产环境门外。适合读它的人是要接 DeepSeek API 做应用的后端工程师、要给团队沉淀 prompt 规范的算法工程师以及被“编数据”坑过的数据分析师和科研辅助工作者。2. 提示词设计从模板堆砌到结构化表达2.1 为什么 DeepSeek 的提示词不能照搬 GPT 时代的写法GPT 时代的很多提示词技巧本质是在跟一个“对话能力强但指令遵循不严格”的模型周旋。但 DeepSeek 的指令遵循能力比较强它的设计逻辑更接近“把需求说清楚模型就能拆解得比较准”。你会发现很多在 GPT 上有效的“角色扮演”“思维链引导”写法在 DeepSeek 上反而显得绕因为模型本来就倾向于直接执行指令。另一个关键差异是 DeepSeek 的长上下文支持。上下文窗口大了之后提示词不再只是“一段话”而是一份完整的任务说明书。你可以把背景资料、历史结论、输出格式要求一次性塞进去而不需要担心截断。但这也带来一个新问题上下文越长幻觉出现的概率越高因为模型会在长距离里丢失对约束条件的注意力。所以 DeepSeek 的提示词设计第一原则不是“写得好而是”结构清楚、约束靠后置反复强调“。2.2 一套可以直接抄的提示词结构我一般在设计 DeepSeek 提示词的时候会遵循五段式结构角色定位、任务陈述、输入数据、输出格式、边界条件。这五段不是并列关系而是层层递进。角色定位决定模型的语气和立场任务陈述告诉它要做什么输入数据给它素材输出格式约束它的表达边界条件划清不能做什么。下面是一个可以直接用的 Python 模板我建议你把它存成字典方便后续批量调用和管理。实际使用时只需填充各字段内容即可快速组装多种任务。prompt_template { role: 你是一位资深数据分析师擅长从原始数据中提炼结论并指出数据质量的异常。, task: 请根据给定的销售数据集分析本季度各区域业绩变化的原因。, input_data: 将用户上传的 CSV 数据内容放在这里或在这里描述数据文件的路径与字段说明。, output_format: 输出 3 个核心结论每个结论后附一条数据证据用 markdown 表格呈现。, constraints: 只能基于给定数据回答若数据不足必须说明缺失字段禁止编造同比、环比数字。 }这段代码的逻辑不复杂核心是约束条件必须放在最后。模型对 Prompt 末尾内容的注意力权重往往更高把“禁止编造数字”放在最后比放在开头更容易被遵守。参数上的经验是如果任务偏分析总结temperature 设 0.3 左右比较稳太高容易让模型在数据里“自由发挥”。如果是头脑风暴类任务再考虑调到 0.7 以上。2.3 反直觉的技巧减少提示词里的“聪明词”很多人写提示词喜欢堆砌“精准地”“深入地”“严格地”这类修饰词这会让模型的输出风格变得很僵化。DeepSeek 对指令的遵循能力越强就越吃具体的动作词——“列出”“对比”“计算”“排序”这类动词远比“仔细分析”有效。举个例子。把“请深入分析这份销售数据”改成“请按季度分组计算各区域销售额并对比环比变化找出超过平均值 20% 的区域”输出的可用性差别很大。前者模型给你一段流畅但空洞的文字后者直接给可核验的结果。这个思路在给 DeepSeek 写提示词的场景里几乎能普遍提升回答质量。如果团队要沉淀规范我建议在文档里加一条硬性要求提示词里禁止出现“深入”“精准”这类无信息量的形容词。3. 幻觉避免从“事后纠正”到“事前约束”3.1 DeepSeek 的幻觉从哪里来幻觉不是 bug而是语言模型生成机制的直接产物。DeepSeek 预测下一个词的时候选择的是概率最高的词而不是经过事实核验的词。所谓“幻觉避免”本质是让模型在“流畅续写”和“事实约束”之间把权重压向后者。常见幻觉集中在三个区域具体数字、引文来源、罕见专有名词。模型对常识性知识的把握相对可靠但对数字这类概率分布比较平缓的 token天生容易出错。比如让它回答一个公司上一季度的营收它可能给出一个看起来合理、实际上完全不存在的数字。另一个容易出幻觉的地方是引用——模型没有真实访问文献库的能力它的“引用”虽然在格式上像模像样但篇目名、作者、年份都可能是组合出来的。在学术和数据分析场景里这比单纯“回答错误”更有迷惑性。3.2 在提示词层面建立三道防线第一道防线是指定知识来源。直接在提示词里声明“只基于我提供的上下文回答”并且把参考资料粘进输入数据段。第二道防线是强制不确定性表达。要求模型在置信度不足时输出“无法确认”或“需要更多数据”这比让它硬着头皮猜要安全得多。第三道防线是结果自检——让模型在输出后自己检查答案中出现的每个数字和专有名词是否都能在上下文中找到依据。一个常见的做法是在提示词末尾增加一条输出要求要求模型在回答末尾列出“事实核验清单”逐条标注每条结论对应的数据来源。这种做法看着简单但能显著减少“表面正确、实际无据”的幻觉。原因在于它把模型的一部分生成注意力从“怎么把话说流畅”转移到了“怎么把话说有据”上同时也方便人做二次核查。如果你在跑数据类任务建议把 temperature 降低到 0.2 以下并且讲清楚这个参数的含义——它降低了采样随机性让模型更倾向于选高概率的下一个词而不是冒进选一些“听起来更有创意”的词。3.3 问对问题的前提把模糊问题改造成可核验问题幻觉很多时候不是模型的问题而是问题本身不可核验。你问“中国数字经济规模怎么样”模型只能凭记忆作答——记忆又是压缩过的必然丢细节。但如果你把问题改成“根据附件《某省数字经济报告》第 3 页的数据计算 2024 年该省数字经济占 GDP 的比重”模型的可执行空间就完全不同了。这里有一个我在实际中反复用到的技巧在提问前先问自己三个问题——这个问题有标准答案吗答案能从哪里找来我希望模型用什么样的证据支撑它如果三个问题都回答不上来那这个问题本来就不该直接丢给模型。DeepSeek 的技术社区里很多人抱怨幻觉多但仔细看他们贴的 prompt多半问的是“你觉得……”这类开放式问题这种问题模型不产生幻觉才是怪事。4. 应用落地从 API 调用到完整工作流4.1 最小可用的 DeepSeek API 调用代码不论最终做什么应用接 API 是第一步。DeepSeek 的接口兼容 OpenAI 的调用格式所以如果你有调用 GPT 的经验切换成本很低。下面这段代码是最小可用版本我建议你直接拿去跑通再在此基础上迭代。from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) def ask_deepseek(user_input: str, history: list None): messages history or [] messages.append({role: user, content: user_input}) response client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.3, max_tokens2048, ) return response.choices[0].message.content有两点值得展开说明。第一messages参数直接回答了“DeepSeek 怎么继承上一个对话”——把历史消息按 user/assistant 交替传进来就行接口本身不帮你记忆所有上下文都得自己维护。第二temperature0.3是个偏保守的设置适合需要事实准确性的任务。如果你的场景是写文案可以上调到 0.7但如果跑数据整理就保持低温度。4.2 把提示词设计接进业务一个文档问答的例子光会调用还不够要把提示词设计落进流程里。我服务的一家数据团队要做一个内部文档问答系统最初直接把文档丢给模型回答质量惨不忍睹。后来改成三段式先做文本切块再做检索召回再把召回内容拼进提示词的input_data段。代码量不大但效果提升非常明显。# 文本切块与向量化伪代码流程 1. 读取 PDF/Word 文档按章节切块单块控制在 500 字以内 2. 使用文本嵌入模型为每块生成向量存入向量数据库 3. 用户提问时先检索最相关的 3~5 块内容 4. 将检索结果拼接到 prompt_template[input_data]再调 DeepSeek 接口这样做的好处是模型不需要“回忆”知识——它只需要“概括”给定内容。顺带解决了一个大模型应用里的经典悖论模型参数里有的知识是静态的文档是动态的只有把动态知识塞进上下文回答才能跟上业务变化。DeepSeek 的上下文窗口够大所以一次塞 5 个文本块完全不是问题这点对落地很有利。4.3 本地部署什么时候需要自建服务API 方式适合大多数场景但有些团队因为数据不出域、调用频率过高或成本控制的原因会选择本地部署 DeepSeek 模型。常见方案是用 vLLM 做推理服务框架支持高并发和连续批处理。我不会在这里展开部署细节因为这份 PDF 的核心在提示词和幻觉管理部署只是承载它们的基础设施。但有一个判断标准值得写在这里如果你的调用量每天在几千次以内、对延迟不敏感且数据可以出域直接用 API 最划算如果数据敏感或者调用量到了万次级别才值得投入本地部署的运维成本。很多团队一上来就搞本地部署结果卡在显卡配置和推理优化上反而耽误了业务验证——先跑通应用再考虑基础设施。4.4 从单轮到工作流把 PDF 里的方法论变成流水线对个人用户或小团队来说比较务实的做法是做一个“输入—增强—生成—检验”的四步流水线。输入阶段收集用户问题和参考文档增强阶段做检索和上下文拼接生成阶段用 DeepSeek 出答案检验阶段拿关键词列表核对回答里有没有编造的内容。这四步看着普通但每一环都在对幻觉做一次拦截。做完之后你再回头看那份 PDF 里的方法就会发现提示词设计是其中的一环不是全部。5. 避坑指南DeepSeek 落地中的常见问题与排查5.1 提示词编写阶段的 3 个坑坑一负向指令反而触发拒答。现象是提示词里写“不要编造数据”模型反而频繁回答“我无法回答这个问题”。原因是模型把“不要”后面的内容也当成了关注对象它在解码时对“编造”这个词产生了不必要的激活。解决把负向指令改成正向约束写成“请在我提供的资料范围内回答资料中未提到的信息请明确标注‘资料中未涉及’”。这样的表述既给了模型边界又给了它一个合规的出路不会触发拒答。这个坑在技术社区里被反复讨论但很多人还是习惯性写“不要”改成正向表达之后拒答率会明显下降。坑二提示词太长导致约束失效。现象是前面交代的输出格式到后面模型没遵守。原因是模型对超长上下文的注意力会衰减尤其当上下文中穿插大量无关背景时。解决把最重要的约束放在提示词的开头和结尾各强调一次。比如开头写“你的回答将用于对外发布必须使用 markdown 表格”结尾再写“再次提醒回答仅以 markdown 表格呈现”。在这个问题上重复不是冗余是防止注意力衰减的补偿机制。坑三temperature 不区分任务。现象是同一个参数打天下做数据清洗的任务输出极不稳定有时同一个问题两次结果不一样。原因是温度高采样随机性就大。解决按任务类型建立参数规范——抽取、分类任务设 0改写、总结设 0.3创意写作设 0.7推理链任务设 0.5 并配合思维链提示。这个参数表我建议直接写进团队规范里比每次调一遍效率高得多。5.2 调用与部署阶段的 2 个坑坑四接口偶尔报错或响应变慢。现象是调用时报连接错误、超时或者返回 503表现就是“deepseek 服务器繁忙”。原因是对外服务在高负载时段确实会出现排队。解决在代码里加指数退避重试第一次等待 2 秒第二次 4 秒第三次 8 秒。同时把超时时间从默认值调大到 60 秒。如果你在跑生产级应用最好做一个简单的熔断机制——连续失败 5 次就切备用模型或本地模型。这个现象不是代码问题是并发资源问题设计上要容忍它。坑五长文输出中断或截断。现象是生成到一半突然停下内容不完整。原因极可能是max_tokens设得太小模型生成到了长度上限被强制截断。解决先算一下你的提示词和回答大概要多少字一个汉字大概对应 1.5 到 2 个 token然后在设定max_tokens时留出至少 30% 的余量。还有一种可能模型识别到输出中重复了某些片段主动停止了生成。这种情况要把 temperature 稍微调高到 0.5 左右打破重复循环。6. 验证方法三层检查法在交付前拦住幻觉最后一章我讲一个自己验证 prompt 质量的固定流程。这套流程花不了多少时间但它能直接反映“提示词到底写没写对”比让同事帮忙“感觉一下”靠谱得多。第一层是事实核查。拿到模型输出后逐个检查里面出现的数字、日期、专有名词和引用凡是在我的参考文档里找不到出处的一律标记为疑似幻觉。这个检查可以做成半自动的——把输出里的数字提取出来再用脚本跑一遍原文匹配效率会高很多。第二层是反向验证。把模型的结论重新塞回 DeepSeek用一条新提示词让它判断“上面的结论是否有充分的论据支撑”相当于做一次交叉审查。第三层是边界测试。故意输入一些超出参考文档范围的问题看它能不能正确地说“不知道”而不是硬答这一步检验的是提示词里边界条件叙写的有效性。下面是一个可以在这份流程里直接使用的自检提示词注意看它是怎么把“自检”变成一个具体动作的。逻辑上这一步是把模型从“回答者”切换到“审核者”换一种视角重新看一遍自己的答案相当于让模型站在检查者的立场上审视输出从而暴露它在回答阶段忽略掉的细节。self_check_prompt 请以审核员的身份检查以下回答。 检查要点 1. 所有数字是否能在参考文档中找到对应出处。 2. 专有名词和引用格式是否正确不得伪造篇目与作者。 3. 是否存在超出参考文档范围的推测性表述。 参考文档{reference_text} 待检查回答{answer_text} 输出格式列出每个可疑点标注可疑原因最后给出“通过/需修正”的结论。 这段代码在实际使用中我一般会在“待检查回答”里加入被检查内容的原文同时把参考文档一并传入。这样模型才有足够的上下文进行比对否则它会凭借自己的既有知识去臆断陷入二次幻觉。我自己经历过一次“用幻觉检查幻觉”的翻车——那次没有传参考文档模型把错误信息当作事实放行了之后我就把这个流程固定成了现在的样子。回看这份 PDF 的价值它本质上不是一份“新知识合集”而是一套把 DeepSeek 提示词设计、幻觉避免和应用落地揉在一起的工程方法论。它的几个核心点——结构化提示词、事前约束代替事后修正、参数分任务设置、三层验证——每一条都值得你在自己的项目上跑一遍。公式化提示词只能让你应付简单的对话任务真正拉开差距的是对模型机制的尊重知道它擅长什么、在什么地方会翻车然后设计流程去规避。我自己现在的习惯是任何一条 prompt 上线前先跑一轮边界测试。哪怕只是多花十分钟它也能拦住大部分会让业务翻车的幻觉输出。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek提示词设计与幻觉避免：结构化表达与工程落地指南
简介这份PDF由厦门大学软件和人工智能专家程希冀主讲主题是DeepSeek提示词设计与幻觉规避同时兼谈Manus智能体。内容面向AI开发研究人员、提示词工程爱好者及希望更高效使用大模型的职场人群、教育工作者和普通用户重点解决“AI越来越聪明提示词是否还重要”这一核心困惑并通过推理型与非推理型模型的对比给出差异化的提问策略。资源为单个PDF文件大小约2.27MB已有248人学习。讲解从“人机预先默契”说起梳理了DeepSeek-R1与V3的不同性格、思维链CoT适用场景、六何分析法5W1H等实用技巧还演示了如何设计提示词让AI生成炫酷图表和动画。针对AI幻觉现象文档提出了限制知识来源、明确时间界限及检索增强框架等应对策略帮助读者在降低错误输出的同时提升对话系统的可靠性与实用性。适合想系统掌握提示词设计方法并规避AI幻觉风险的各类学习者。1. DeepSeek提示词设计为什么同一个人用效果能差出一倍手上拿到一份题为《2025厦门大学DeepSeek提示词设计、幻觉避免与应用》的PDF第一反应是这年头讲提示词的材料太多了但真正能把 DeepSeek 提示词设计、幻觉避免、应用落地串成一条完整链路的确实稀缺。这份材料好就好在它不是拿通用大模型的提示词套路硬套 DeepSeek而是从模型自身的指令遵循特性、解码参数和上下文管理出发给了能直接复现的写法。对从业者来说这份材料要解决的是两类痛点。一类是提示词写了跟没写一样模型输出空泛、说教、答非所问另一类是看似答得很顺实际上数字、引用、专有名词全在编也就是幻觉。前者浪费调优时间后者直接把 AI 应用挡在生产环境门外。适合读它的人是要接 DeepSeek API 做应用的后端工程师、要给团队沉淀 prompt 规范的算法工程师以及被“编数据”坑过的数据分析师和科研辅助工作者。2. 提示词设计从模板堆砌到结构化表达2.1 为什么 DeepSeek 的提示词不能照搬 GPT 时代的写法GPT 时代的很多提示词技巧本质是在跟一个“对话能力强但指令遵循不严格”的模型周旋。但 DeepSeek 的指令遵循能力比较强它的设计逻辑更接近“把需求说清楚模型就能拆解得比较准”。你会发现很多在 GPT 上有效的“角色扮演”“思维链引导”写法在 DeepSeek 上反而显得绕因为模型本来就倾向于直接执行指令。另一个关键差异是 DeepSeek 的长上下文支持。上下文窗口大了之后提示词不再只是“一段话”而是一份完整的任务说明书。你可以把背景资料、历史结论、输出格式要求一次性塞进去而不需要担心截断。但这也带来一个新问题上下文越长幻觉出现的概率越高因为模型会在长距离里丢失对约束条件的注意力。所以 DeepSeek 的提示词设计第一原则不是“写得好而是”结构清楚、约束靠后置反复强调“。2.2 一套可以直接抄的提示词结构我一般在设计 DeepSeek 提示词的时候会遵循五段式结构角色定位、任务陈述、输入数据、输出格式、边界条件。这五段不是并列关系而是层层递进。角色定位决定模型的语气和立场任务陈述告诉它要做什么输入数据给它素材输出格式约束它的表达边界条件划清不能做什么。下面是一个可以直接用的 Python 模板我建议你把它存成字典方便后续批量调用和管理。实际使用时只需填充各字段内容即可快速组装多种任务。prompt_template { role: 你是一位资深数据分析师擅长从原始数据中提炼结论并指出数据质量的异常。, task: 请根据给定的销售数据集分析本季度各区域业绩变化的原因。, input_data: 将用户上传的 CSV 数据内容放在这里或在这里描述数据文件的路径与字段说明。, output_format: 输出 3 个核心结论每个结论后附一条数据证据用 markdown 表格呈现。, constraints: 只能基于给定数据回答若数据不足必须说明缺失字段禁止编造同比、环比数字。 }这段代码的逻辑不复杂核心是约束条件必须放在最后。模型对 Prompt 末尾内容的注意力权重往往更高把“禁止编造数字”放在最后比放在开头更容易被遵守。参数上的经验是如果任务偏分析总结temperature 设 0.3 左右比较稳太高容易让模型在数据里“自由发挥”。如果是头脑风暴类任务再考虑调到 0.7 以上。2.3 反直觉的技巧减少提示词里的“聪明词”很多人写提示词喜欢堆砌“精准地”“深入地”“严格地”这类修饰词这会让模型的输出风格变得很僵化。DeepSeek 对指令的遵循能力越强就越吃具体的动作词——“列出”“对比”“计算”“排序”这类动词远比“仔细分析”有效。举个例子。把“请深入分析这份销售数据”改成“请按季度分组计算各区域销售额并对比环比变化找出超过平均值 20% 的区域”输出的可用性差别很大。前者模型给你一段流畅但空洞的文字后者直接给可核验的结果。这个思路在给 DeepSeek 写提示词的场景里几乎能普遍提升回答质量。如果团队要沉淀规范我建议在文档里加一条硬性要求提示词里禁止出现“深入”“精准”这类无信息量的形容词。3. 幻觉避免从“事后纠正”到“事前约束”3.1 DeepSeek 的幻觉从哪里来幻觉不是 bug而是语言模型生成机制的直接产物。DeepSeek 预测下一个词的时候选择的是概率最高的词而不是经过事实核验的词。所谓“幻觉避免”本质是让模型在“流畅续写”和“事实约束”之间把权重压向后者。常见幻觉集中在三个区域具体数字、引文来源、罕见专有名词。模型对常识性知识的把握相对可靠但对数字这类概率分布比较平缓的 token天生容易出错。比如让它回答一个公司上一季度的营收它可能给出一个看起来合理、实际上完全不存在的数字。另一个容易出幻觉的地方是引用——模型没有真实访问文献库的能力它的“引用”虽然在格式上像模像样但篇目名、作者、年份都可能是组合出来的。在学术和数据分析场景里这比单纯“回答错误”更有迷惑性。3.2 在提示词层面建立三道防线第一道防线是指定知识来源。直接在提示词里声明“只基于我提供的上下文回答”并且把参考资料粘进输入数据段。第二道防线是强制不确定性表达。要求模型在置信度不足时输出“无法确认”或“需要更多数据”这比让它硬着头皮猜要安全得多。第三道防线是结果自检——让模型在输出后自己检查答案中出现的每个数字和专有名词是否都能在上下文中找到依据。一个常见的做法是在提示词末尾增加一条输出要求要求模型在回答末尾列出“事实核验清单”逐条标注每条结论对应的数据来源。这种做法看着简单但能显著减少“表面正确、实际无据”的幻觉。原因在于它把模型的一部分生成注意力从“怎么把话说流畅”转移到了“怎么把话说有据”上同时也方便人做二次核查。如果你在跑数据类任务建议把 temperature 降低到 0.2 以下并且讲清楚这个参数的含义——它降低了采样随机性让模型更倾向于选高概率的下一个词而不是冒进选一些“听起来更有创意”的词。3.3 问对问题的前提把模糊问题改造成可核验问题幻觉很多时候不是模型的问题而是问题本身不可核验。你问“中国数字经济规模怎么样”模型只能凭记忆作答——记忆又是压缩过的必然丢细节。但如果你把问题改成“根据附件《某省数字经济报告》第 3 页的数据计算 2024 年该省数字经济占 GDP 的比重”模型的可执行空间就完全不同了。这里有一个我在实际中反复用到的技巧在提问前先问自己三个问题——这个问题有标准答案吗答案能从哪里找来我希望模型用什么样的证据支撑它如果三个问题都回答不上来那这个问题本来就不该直接丢给模型。DeepSeek 的技术社区里很多人抱怨幻觉多但仔细看他们贴的 prompt多半问的是“你觉得……”这类开放式问题这种问题模型不产生幻觉才是怪事。4. 应用落地从 API 调用到完整工作流4.1 最小可用的 DeepSeek API 调用代码不论最终做什么应用接 API 是第一步。DeepSeek 的接口兼容 OpenAI 的调用格式所以如果你有调用 GPT 的经验切换成本很低。下面这段代码是最小可用版本我建议你直接拿去跑通再在此基础上迭代。from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) def ask_deepseek(user_input: str, history: list None): messages history or [] messages.append({role: user, content: user_input}) response client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.3, max_tokens2048, ) return response.choices[0].message.content有两点值得展开说明。第一messages参数直接回答了“DeepSeek 怎么继承上一个对话”——把历史消息按 user/assistant 交替传进来就行接口本身不帮你记忆所有上下文都得自己维护。第二temperature0.3是个偏保守的设置适合需要事实准确性的任务。如果你的场景是写文案可以上调到 0.7但如果跑数据整理就保持低温度。4.2 把提示词设计接进业务一个文档问答的例子光会调用还不够要把提示词设计落进流程里。我服务的一家数据团队要做一个内部文档问答系统最初直接把文档丢给模型回答质量惨不忍睹。后来改成三段式先做文本切块再做检索召回再把召回内容拼进提示词的input_data段。代码量不大但效果提升非常明显。# 文本切块与向量化伪代码流程 1. 读取 PDF/Word 文档按章节切块单块控制在 500 字以内 2. 使用文本嵌入模型为每块生成向量存入向量数据库 3. 用户提问时先检索最相关的 3~5 块内容 4. 将检索结果拼接到 prompt_template[input_data]再调 DeepSeek 接口这样做的好处是模型不需要“回忆”知识——它只需要“概括”给定内容。顺带解决了一个大模型应用里的经典悖论模型参数里有的知识是静态的文档是动态的只有把动态知识塞进上下文回答才能跟上业务变化。DeepSeek 的上下文窗口够大所以一次塞 5 个文本块完全不是问题这点对落地很有利。4.3 本地部署什么时候需要自建服务API 方式适合大多数场景但有些团队因为数据不出域、调用频率过高或成本控制的原因会选择本地部署 DeepSeek 模型。常见方案是用 vLLM 做推理服务框架支持高并发和连续批处理。我不会在这里展开部署细节因为这份 PDF 的核心在提示词和幻觉管理部署只是承载它们的基础设施。但有一个判断标准值得写在这里如果你的调用量每天在几千次以内、对延迟不敏感且数据可以出域直接用 API 最划算如果数据敏感或者调用量到了万次级别才值得投入本地部署的运维成本。很多团队一上来就搞本地部署结果卡在显卡配置和推理优化上反而耽误了业务验证——先跑通应用再考虑基础设施。4.4 从单轮到工作流把 PDF 里的方法论变成流水线对个人用户或小团队来说比较务实的做法是做一个“输入—增强—生成—检验”的四步流水线。输入阶段收集用户问题和参考文档增强阶段做检索和上下文拼接生成阶段用 DeepSeek 出答案检验阶段拿关键词列表核对回答里有没有编造的内容。这四步看着普通但每一环都在对幻觉做一次拦截。做完之后你再回头看那份 PDF 里的方法就会发现提示词设计是其中的一环不是全部。5. 避坑指南DeepSeek 落地中的常见问题与排查5.1 提示词编写阶段的 3 个坑坑一负向指令反而触发拒答。现象是提示词里写“不要编造数据”模型反而频繁回答“我无法回答这个问题”。原因是模型把“不要”后面的内容也当成了关注对象它在解码时对“编造”这个词产生了不必要的激活。解决把负向指令改成正向约束写成“请在我提供的资料范围内回答资料中未提到的信息请明确标注‘资料中未涉及’”。这样的表述既给了模型边界又给了它一个合规的出路不会触发拒答。这个坑在技术社区里被反复讨论但很多人还是习惯性写“不要”改成正向表达之后拒答率会明显下降。坑二提示词太长导致约束失效。现象是前面交代的输出格式到后面模型没遵守。原因是模型对超长上下文的注意力会衰减尤其当上下文中穿插大量无关背景时。解决把最重要的约束放在提示词的开头和结尾各强调一次。比如开头写“你的回答将用于对外发布必须使用 markdown 表格”结尾再写“再次提醒回答仅以 markdown 表格呈现”。在这个问题上重复不是冗余是防止注意力衰减的补偿机制。坑三temperature 不区分任务。现象是同一个参数打天下做数据清洗的任务输出极不稳定有时同一个问题两次结果不一样。原因是温度高采样随机性就大。解决按任务类型建立参数规范——抽取、分类任务设 0改写、总结设 0.3创意写作设 0.7推理链任务设 0.5 并配合思维链提示。这个参数表我建议直接写进团队规范里比每次调一遍效率高得多。5.2 调用与部署阶段的 2 个坑坑四接口偶尔报错或响应变慢。现象是调用时报连接错误、超时或者返回 503表现就是“deepseek 服务器繁忙”。原因是对外服务在高负载时段确实会出现排队。解决在代码里加指数退避重试第一次等待 2 秒第二次 4 秒第三次 8 秒。同时把超时时间从默认值调大到 60 秒。如果你在跑生产级应用最好做一个简单的熔断机制——连续失败 5 次就切备用模型或本地模型。这个现象不是代码问题是并发资源问题设计上要容忍它。坑五长文输出中断或截断。现象是生成到一半突然停下内容不完整。原因极可能是max_tokens设得太小模型生成到了长度上限被强制截断。解决先算一下你的提示词和回答大概要多少字一个汉字大概对应 1.5 到 2 个 token然后在设定max_tokens时留出至少 30% 的余量。还有一种可能模型识别到输出中重复了某些片段主动停止了生成。这种情况要把 temperature 稍微调高到 0.5 左右打破重复循环。6. 验证方法三层检查法在交付前拦住幻觉最后一章我讲一个自己验证 prompt 质量的固定流程。这套流程花不了多少时间但它能直接反映“提示词到底写没写对”比让同事帮忙“感觉一下”靠谱得多。第一层是事实核查。拿到模型输出后逐个检查里面出现的数字、日期、专有名词和引用凡是在我的参考文档里找不到出处的一律标记为疑似幻觉。这个检查可以做成半自动的——把输出里的数字提取出来再用脚本跑一遍原文匹配效率会高很多。第二层是反向验证。把模型的结论重新塞回 DeepSeek用一条新提示词让它判断“上面的结论是否有充分的论据支撑”相当于做一次交叉审查。第三层是边界测试。故意输入一些超出参考文档范围的问题看它能不能正确地说“不知道”而不是硬答这一步检验的是提示词里边界条件叙写的有效性。下面是一个可以在这份流程里直接使用的自检提示词注意看它是怎么把“自检”变成一个具体动作的。逻辑上这一步是把模型从“回答者”切换到“审核者”换一种视角重新看一遍自己的答案相当于让模型站在检查者的立场上审视输出从而暴露它在回答阶段忽略掉的细节。self_check_prompt 请以审核员的身份检查以下回答。 检查要点 1. 所有数字是否能在参考文档中找到对应出处。 2. 专有名词和引用格式是否正确不得伪造篇目与作者。 3. 是否存在超出参考文档范围的推测性表述。 参考文档{reference_text} 待检查回答{answer_text} 输出格式列出每个可疑点标注可疑原因最后给出“通过/需修正”的结论。 这段代码在实际使用中我一般会在“待检查回答”里加入被检查内容的原文同时把参考文档一并传入。这样模型才有足够的上下文进行比对否则它会凭借自己的既有知识去臆断陷入二次幻觉。我自己经历过一次“用幻觉检查幻觉”的翻车——那次没有传参考文档模型把错误信息当作事实放行了之后我就把这个流程固定成了现在的样子。回看这份 PDF 的价值它本质上不是一份“新知识合集”而是一套把 DeepSeek 提示词设计、幻觉避免和应用落地揉在一起的工程方法论。它的几个核心点——结构化提示词、事前约束代替事后修正、参数分任务设置、三层验证——每一条都值得你在自己的项目上跑一遍。公式化提示词只能让你应付简单的对话任务真正拉开差距的是对模型机制的尊重知道它擅长什么、在什么地方会翻车然后设计流程去规避。我自己现在的习惯是任何一条 prompt 上线前先跑一轮边界测试。哪怕只是多花十分钟它也能拦住大部分会让业务翻车的幻觉输出。希望帮到你。本文还有配套的精品资源点击获取