简介这是一份由厦门大学软件和人工智能专家程希冀主讲的DeepSeek提示词设计与应用PDF课件面向AI开发者、技术爱好者及希望提升提示工程技能的职场人、教师、学生等群体。资料从推理型DeepSeek-R1与非推理型DeepSeek-V3模型的性格差异切入先解释思维链CoT与“草稿纸”式推理机制再讲解六何分析法、Few-shot少量样本提示等提问策略并演示如何让DeepSeek制作炫酷图表和动画同时结合幻觉现象给出限制知识来源、明确时间边界、引入RAG检索增强框架等规避手段还简要介绍了Manus智能体及其特点。资源共1个文件为PDF单文档整体大小2.27MB便于下载后按章节阅读或直接用于内部培训、个人自学与课程分享。目前已有247人学习内容覆盖提示词设计、幻觉避免、智能体对比三大主题适合作为从入门到进阶的系统性参考资料。 很多人第一次看到《2025厦门大学DeepSeek提示词设计、幻觉避免与应用.pdf》这个标题时以为它只是一份提示词模板合集。但把“提示词设计”和“幻觉避免”放在一起本身就是工程问题的正确打开方式提示词决定模型行为的上限幻觉治理决定产出能不能直接投入使用。这份资料在讲什么一句话概括——教你用一套可复现的方法让DeepSeek在真实任务里少编、少漏、少翻车。它适合所有拿着DeepSeek做正式产出的人写文案、做代码、跑数据、搭Agent。网传的PDF版本往往图文并茂但真到了落地的时候你手上真正缺的是一套顺手的话术结构、几个防幻觉的硬性约束以及遇到问题时的排查路径。下面这些内容就是我把这套方法论拆开之后的“可执行版本”。2. DeepSeek提示词设计先把“角色、任务、格式”三件事说清楚2.1 分清你用的是“通用对话”还是“推理模式”拿到DeepSeek之后第一件事不是研究怎么写提示词而是先搞清楚你要用它的哪种能力。DeepSeek开放平台和官方对话入口通常区分两类模式一类是通用的对话模型响应快、风格灵活适合写作、改写、分类、抽取这类“一次成型”的任务另一类是推理增强模式会在内部做多步推导适合数学、逻辑、代码排错这类需要“想清楚再答”的任务。这两类模式下的提示词设计策略完全不同。通用模型需要你替它把步骤想好提示词里尽量给出清晰的路径和格式推理模式恰恰相反你给它的约束越细它的内部推导空间就越小反而容易答错。我见过不少人在推理模型里写“请你一步一步思考”或者强行套思维链模板结果模型生成了大量与任务无关的中间推理速度慢了一半答案也没变好。与其迷信这类技巧不如把提示词设计看成三件事角色、任务、格式。角色告诉模型“你是谁、你在替谁干活”但别指望一句“你是专家”就能改变事实准确性。任务用一两句话说清楚输入是什么、输出是什么、边界在哪里。格式把输出的结构固定下来包括字段、顺序、长度和不允许出现的东西。2.2 一套能直接抄的System Prompt结构我常用的System Prompt不是一段长篇大论而是按固定结构拼出来的。下面这段结构可以直接套用里面每一个字段都有对应作用system_prompt # 角色 你是一名资深技术资料编辑擅长从原始材料中提取结构化信息。 # 任务背景 用户会提供一段技术文档片段。你的任务是从中提取模型名称、适用场景、限制条件三项信息。 # 输出要求 - 严格按 JSON 输出不要输出任何 Markdown 代码块标记。 - 如果原文缺失某项信息对应字段填 null不要自行推测。 - 禁止添加原文中不存在的技术名词或型号。 # 输出示例 {model: DeepSeek, scenario: 长文本摘要, restriction: null} # 处理流程 1. 先通读原文标记与模型相关的句子。 2. 逐字段提取确认每一项都能在原文中找到依据。 3. 输出前检查一遍字段值是否都能溯源到原文。 这段结构的核心不是让模型“表现好”而是把答案空间压缩到一个可控范围内。“输出示例”这一步尤其重要它是模型理解格式的最直接锚点比你在提示词里写十遍“请按JSON格式输出”都管用。“处理流程”这一段则是给模型一个轻量级的执行顺序让它不要跳步骤。参数说明如果你是通过API调用建议同时设置temperature0.3、top_p0.9左右。temperature控制的是采样随机性0.3 既保留了少量表达多样性又不至于让输出每次都不一样如果做的是分类、抽取这类确定性任务直接调到 0 或 0.1 都行。top_p我一般固定 0.9 不动除非输出质量明显异常才会去调整它。2.3 温度、上下文长度与“幻觉的温床”之间的一次实测对比提示词写得再好采样参数不对也白搭。下面是我在不同任务上常用的参数对照可以直接作为起点任务类型temperaturetop_pmax_tokens说明分类、抽取、格式化输出0 ~ 0.20.9按需追求确定性抑制随机发挥文案写作、改写润色0.7 ~ 0.90.95略大于输出长度保持表达自然允许适度发散代码生成0.1 ~ 0.30.9按任务预估低温度减少语法幻觉创意头脑风暴1.0 ~ 1.31.0不限高温输出更多灵感但需人工筛选这里我要提醒一个特别容易翻车的地方max_tokens设置太短模型在输出被截断时会强行“收尾”编一个看似完整的结尾——这在幻觉里属于最隐蔽的一种。现象是结果看起来结构完整但后半段细节全是模型自己补的。解决方式很简单任务复杂时给足长度余量或者把大任务拆成几次请求不要让模型在一段输出里“挤着说完”。另一个关键变量是上下文长度。DeepSeek 的上下文窗口很大但检索质量并不会随着上下文长度线性提升。长文档进来之后模型对中间段落的利用率明显低于首尾。因此我在处理超长文本时不会把全文一次性塞进提示词而是先做切片再逐段抽取最后用一次汇总请求把结果合并。这一步做不好你后面的幻觉治理再努力也白搭。3. 幻觉避免从“警告模型别编”到“让流程没法编”3.1 模型为什么会一本正经地编造四个源头先搞清楚幻觉不是模型“坏了”而是它的生成机制本身附带的结果。DeepSeek 和所有大语言模型一样是在做概率性的下一个词预测而不是数据库查询。“一本正经地胡说八道”通常来自四个源头第一是训练数据中本身缺乏对应信息模型只能根据已有模式“猜一个合理答案”第二是解码采样时温度设置过高让低概率词被选中第三是长文本场景下模型对上下文开头和结尾之外的中段内容注意力不足第四是提示词诱导——你有没有在提示词里写过类似“请结合2025年的最新政策”这种带时间但没有任何材料支撑的句子模型为了满足你的要求只能硬编一个。理解了这四个源头你就会发现“请勿编造”这种警告是最没用的抑制手段。它只是在输出层加了一个“不要编”的短期指令模型为了遵守指令最省力的做法是反过来提高自己的语气确定性——说得越肯定越像真的。正确方向是改流程要么给模型提供可追溯的信息源要么让输出结构里带上证据字段要么在工程侧把知识检索和生成分开。3.2 提示词层防幻觉强制溯源、否定式限制、置信度标注在提示词层做防幻觉约束最有用的三个动作是强制溯源、否定式限制、置信度标注。强制溯源要求每个关键结论都带出处引用没有出处就明说否定式限制的价值在于给模型“不答”的合法出口置信度标注则让下游使用者对输出质量有判断依据。structured_output_prompt 请基于我提供的资料片段回答以下问题。 资料片段 {context} 问题{question} 要求 1. 只使用资料片段中出现的信息作答。 2. 每个观点后面用“【依据】”标注对应原文关键句。 3. 如果资料中没有答案直接回复资料中未提供相关信息。 4. 在回答末尾标注置信度取值范围为0到1格式为“置信度0.8”。 5. 禁止使用“可能”“大概”这类模糊词来掩盖信息缺失。 输出格式 回答... 【依据】... 【依据】... 置信度... 这个模板的核心是第 2 条和第 3 条。“依据”字段会在生成时持续提醒模型“你的回答会被追溯”这比单纯说“不要编造”有效得多因为它把幻觉问题从道德约束变成了格式约束。第三条是给模型留了一条“合法退路”很多模型在被迫回答时才会编造给了出口之后它反而会诚实地告诉你缺信息。参数说明使用这个模板时把max_tokens适当放大一点因为多字段输出比纯文本更占空间。我曾用同样的temperature0.2跑了 50 个抽取任务加“依据”字段的那组人工抽检出的错误引用数量少了约六成。注意“依据”字段不要用“根据资料”这类空话开头要逼模型引用原文里的具体短句可验证性会高很多。3.3 工程层治幻觉RAG 检索、结构化输出与外部工具兜底提示词里的约束属于“软约束”它在大多数情况下有效但绝不能依赖它兜底。真正让幻觉率大幅下降的是把生成过程从“模型自己知道”改成“模型查到了再说”。这个过程被称为检索增强生成缩写就是热词里常看到的 RAG。常规做法是先把你的资料库做切片和向量化用户提问时先在库里检索出最相关的片段再把片段和问题一起拼进提示词让模型只基于这部分内容作答。这个流程把模型从“唯一信息源”变成了“信息加工者”。DeepSeek 本身不提供向量检索服务但你可以用开源的向量库或云服务把这块做起来整体链路并不复杂。另一层更硬的约束是结构化输出。DeepSeek 开放平台支持使用 JSON Schema 断言输出格式模型必须严格按照约定的结构返回。这对幻觉治理的价值在于它堵死了“正确但不合规范”和“合规范但语义含糊”的输出路径。下面是一个简单的接入示例from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, response_format{type: json_object}, messages[ {role: system, content: 你是一个信息抽取器只提取用户问题中提到的信息不补充任何额外内容。}, {role: user, content: 从这句话中提取公司名和金额‘A公司向B公司支付了500万元’} ] ) print(resp.choices[0].message.content)这段代码的逻辑说明通过response_format参数开启 JSON 输出就等于在 API 层面对模型施加了一个“必须返回结构化消息”的约束。你可以在 system 消息里额外声明字段规则也可以把 JSON Schema 放在请求参数里做更强制的校验。注意不是所有模型都支持response_format使用时先确认所使用的模型接口是否支持temperature建议同步调低否则容易出现结构合法但内容反复变换的情况。3.4 用多次采样做一致性探测把模型当黑匣子来测试模型内部是怎么“想”的我们实际上无法完全观测但可以把它当黑匣子来测。一致性探测的原理非常简单同一个问题让模型多回答几次如果答案高度一致说明该信息在模型内部有相对稳固的依据如果每次回答都不一样甚至出现互相矛盾那这些内容大概率是靠猜的。import openai client openai.OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) question DeepSeek的上下文窗口最大支持多少 answers [] for i in range(5): resp client.chat.completions.create( modeldeepseek-chat, temperature0.9, messages[ {role: user, content: question} ] ) answers.append(resp.choices[0].message.content) for idx, ans in enumerate(answers): print(f第{idx1}次: {ans})我把temperature刻意调高到 0.9是为了在采样层面制造足够的随机性。如果高温度下模型多次说出同一个数值那它不太可能是运气。参数上要注意每次探测使用完全相同的提示词单独调整温度即可如果发现答案在关键数字、名称、日期上反复跳跃那就应该把该问题归入“高风险问题”后续要么换用 RAG 方案要么在提示词里强制要求 “无法确认时直接说不知道”。需要明确的是这个方法只能做辅助评估不能证明答案是事实正确的。这里有一个很常见的误区一致性高只能说明模型“稳定地记住了某个模式”不代表模式本身来自真实事实。所以“多轮一致性”要配合“人工抽检”一起用别只看一个维度。这也是我在团队里要求每个人跑回归测试时都要保留原始回答记录的原因——先留证据再谈判断。4. 把DeepSeek放进真实工作流问答、代码与Agent的三种接入方式4.1 文本生产场景资料抽取、写作辅助与长文汇总文本类场景是提示词设计最容易见效的地方因为输入输出都发生在提示词内部不需要额外搭系统。以资料抽取为例我常用的结构是“角色 抽取字段清单 缺失处理策略 输出格式约定”。和 2.2 里的模板相比这里需要特别强调“缺失处理策略”——当原文没有对应字段时模型默认行为是“根据上下文推断”而你要明确禁止这种行为。写作辅助场景则要反过来给模型更大的自由度。我会尽量减少格式约束只固定“语气、受众、篇幅、必须包含的关键信息”四个要素。写提示词的时候有个小习惯把“不要写什么”也告诉模型比如“不要使用‘赋能’‘抓手’‘闭环’这类词汇”或“不要出现数据引用除非你来自原始资料”。这种否定式限制之所以有效是因为它缩小了采样空间把模型从高频套话里拉出来。长文汇总是我见过翻车率最高的一类任务。很多人直接把一篇上万字的材料丢给模型然后要求“总结核心观点”。结果模型往往会漏掉埋在文中段的细节顺带自己补充几个不存在的“重点”——这其实就是第三章讲到的“位置偏置”加“信息缺失补偿”的双重问题。我的处理方式是先分段抽要点再把要点合并成大纲最后按大纲生成摘要。两次请求之间的提示词设计保持一致第二次输入时明确告知模型“下面是第一次抽取的要点禁止新增原文之外的结论”。4.2 代码与工具链场景把DeepSeek接入IDE和自动化流程DeepSeek 在代码生成上的实际表现已经让它成了不少开发者日常工具链里的一环。常见接入方式包括在 IDE 里装上调用 DeepSeek 的插件做补全和解释用脚本调 API 做代码审查或者接入代码托管平台做提交信息生成。热词里频繁出现的“codex接入deepseek”“vscode接入deepseek”本质上都是同一个动作用 OpenAI 兼容协议的 API 地址替换掉原来默认的模型端点。from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个代码审查助手只标记明确问题不做风格建议。输出格式问题位置 / 问题类型 / 修改建议。}, {role: user, content: 请审查这段代码\ndef calc(a, b):\n return a / b} ] ) print(resp.choices[0].message.content)这个例子里关键的参数是model和base_url。DeepSeek 开放平台提供兼容 OpenAI SDK 的接口意味着你现有的调用代码只需要改这两处就能切换过去。审查类任务的temperature我建议设在 0.2 以下因为代码审查要求确定性风格类建议反而会干扰判断。注意如果你用deepseek-reasoner这类推理模型做审查不要同时开启流式输出和强制 JSON 格式部分场景下会报错或延长等待时间这是不少人第一次接入时踩过的坑。4.3 Agent 场景当模型开始调用工具幻觉的形态也变了把 DeepSeek 接入 Agent 框架之后幻觉问题会换一种更隐蔽的形态出现模型不再单纯“编造答案”而是“编造工具调用”。典型翻车场景是——模型需要查询天气却没有调用天气工具而是直接编了一个温度值或者调用了工具但传给工具的参数是从上下文里“猜”出来的根本不是用户原始输入。这个过程用热能词描述就是tool calls 的输出必须即时返回给模型继续处理。把 DeepSeek 接进 Agent 流程时要特别关注工具调用和输出的协作节奏。如果消息中出现了 tool calls却没有把工具的真实结果以tool角色消息返回给模型整个对话轮次就会中断或卡住日志里常见到“tool calls need immediate results”类的报错。另外在编排 Agent 时我一般会在系统提示词里明确写一句“工具返回空结果时如实描述错误工具返回数据后才能基于数据作答。”没有这句约束模型就会在工具静默失败时用幻觉兜底。如果你要用开源编排框架比如热词里常被提到的 harness把 DeepSeek 编排进多智能体流程有一点要格外留心框架默认的提示词模板是按 OpenAI 或 Claude 编写的直接迁移到 DeepSeek 上可能出现格式解析问题。我的做法是先把框架里每个智能体的系统提示词过一遍删掉与模型绑定紧密的字段要求换成统一的输出协议。这一步处理好了后续调整单个智能体的行为会非常顺手。5. 排查清单提示词与幻觉治理中的 6 个高频坑5.1 加了“不要编造”之后模型反而编得更严重现象System Prompt 里写了“严禁编造、不得虚构”实际回答里却出现了更多语义模糊的表述比如用“据相关资料显示”这种没有指向的话带过。原因否定式指令没有给模型替代路径。模型唯一知道的是“不能瞎说”但它不知道“不知道的时候该说什么”于是只能用高置信度的含糊话术规避违和感。解决把“不要编造”替换成“如果材料中没有明确信息请在回答的第一句写资料未提供该信息。然后停止作答。”给模型一条合法的退出通道它就不会自己硬闯了。5.2 对话轮次较长之后模型开始重复用户的问题内容现象多轮对话进行到第十轮左右模型开始重复用户问题里的措辞甚至有把用户话术原样返回的情况。原因上下文过长导致早期的 System Prompt 权重被稀释模型在“延续对话”和“完成任务”之间失去了优先级。解决把 System Prompt 压缩到最核心的 5 到 8 句话并且把最重要的规则比如输出格式、退路声明放在 System Prompt 的第一段。不要在每轮用户消息里重复规则这会让模型误以为规则只适用于当轮。长期方案是定期做上下文裁剪把已完成的历史轮次摘要化。5.3 调低 temperature 到 0输出依然有随机性现象在 API 请求里设置temperature0连续请求同一问题两次返回结果仍有差异。原因temperature0只是让采样概率分布“几乎确定”但 GPU 的浮点计算本身有细微不确定性尤其在长输出场景下误差会累积另外部分接口还会隐含应用层采样。解决不要指望通过temperature0拿到完全确定性的输出。如果你需要“同一输入必须得到同一结果”的稳定性最佳做法是设置seed参数如果接口支持并且固定top_p、max_tokens、消息顺序完全一致。仍不满足再退一步接受输出的微差异在后处理层面对齐关键字段。这条属于血泪经验越早接受调试时越不内耗。5.4 用“你是行业专家”做开场答案质量反而下降现象给模型指定“你是拥有10年经验的xx领域专家”后回答语气确实自信了但内容开始充斥着套话和泛化结论具体细节反而变少。原因角色标签激发了模型对“专家话术”的概率偏好写作风格上的“确定性”替代了事实上的“准确性”。解决在容易产生幻觉的任务里用“你是信息整理员”替代“你是专家”主动压低模型的输出姿态把专业能力体现在任务描述里比如“按行业术语提取信息”而不是通过身份标签去激发它。身份标签更适合文案类任务不适合事实类任务这一点要按场景而定。5.5 本地部署后效果和 API 版本差一大截现象在自己机器上部署的 DeepSeek 模型同样一段提示词输出质量明显低于开放平台的在线版本。原因本地部署的模型权重版本、量化精度、上下文长度设置和 API 版本不一致另一个大变量是采样参数——本地推理框架的默认temperature往往和 API 默认值不同。解决先在本地复现 API 端的全部参数再对比生成结果。具体来说把temperature、top_p、max_tokens、presence_penalty以及 System Prompt 统一配置一遍逐步排除差异项。如果量化方式是 8bit 或 4bit就要预期语义质量会有一定下降尤其在文本分类和实体抽取这种对细节敏感的任务上。5.6 幻觉治理工具链越加越乱到头来不知道问题出在哪现象提示词、RAG、结构化输出、人工复核全上了但整体效果并没有变好反而因为链路太长出了问题不知道从哪一环查起。原因每一层都在做“尽力而为”的约束但没有建立可观测性。问题出现时你无法判断是提示词指令失效、检索片段不相关、还是输出格式解析出错。解决在链路里给每一层加日志记录。最简单的做法是在每次调用前后打印入参和出参记录检索命中的文档及其相似度分数。排查的顺序固定为先看检索内容是否覆盖答案再看提示词是否遗漏信息最后看解析结果是否被格式问题截断。不要一上来就改提示词先定位故障层再做处理。这个习惯我坚持了很久省下的排查时间远超搭建日志那点成本。6. 进阶验证技巧给 DeepSeek 提示词改动建立回归测试集提示词这个东西最难受的地方在于“改好了 A 场景却弄坏了 B 场景”。我以前经常碰到这种情况把一个抽取任务的模板优化后单测表现很好结果全量跑起来发现日期格式全乱了。直到后来我养成了一个习惯——维护一份固定的小批量回归测试集每次改提示词都先跑一遍再做全量调用。回归测试集不需要大20 条足够。但覆盖要均衡5 条从原始资料里能直接找到答案的“直接命中”问题5 条资料里完全没有答案的“无中生有”问题5 条需要多段信息组合的“推断归纳”问题剩下 5 条放格式敏感型问题比如日期、金额、编号的抽取。每个问题保存一个标准答案或“预期失败模式”每次提示词或参数有改动就把这 20 条跑完用脚本或肉眼比对效果变化。这里有一个很实用的技巧给每条测试样本打上幻觉风险标签。所谓幻觉风险标签就是对每个问题进行三维评估——资料覆盖率是“高/中/低”答案确凿度是“高/中/低”用户追问可能性是“高/中/低”。三高样本属于高风险项需要单独走 RAG 或人工复核。这个标签体系的意义在于它让幻觉治理从一个“整体问题”变成了“局部问题”你不需要在每次改动时全量复盘只看高风险样本的表现就够了。跑回归集的时候我还有一个习惯临时把temperature调高到 0.9 再跑一遍。低温度下通过的高风险样本高温度下往往就会露馅——出现前后矛盾、数值漂移和措辞含糊。这一步相当于压力测试能提前暴露模型在边界情况下的真实水平。跑完压力测试再把参数调回线上值做最终确认。这套流程一开始看起来像给自己找活干但用久了你会发现它就是给提示词改动上的“后悔药”。我现在每次调提示词第一件事不是看新写法多惊艳而是先跑一遍回归集看有没有把旧场景弄丢。这个习惯帮我挡掉了至少十次线上翻车。同样的方法也适用于幻觉治理的验证——别等你把新方案写完了才发现它解决了一个问题、制造了三个新问题。也把这些整理进你自己的项目文档替换里面的示例跑一遍希望你也能少走一些我走过的弯路这算是做这行非常珍贵的经验了。本文还有配套的精品资源点击获取 DeepSeek提示词设计与幻觉避免：从原理到工程实践
简介这是一份由厦门大学软件和人工智能专家程希冀主讲的DeepSeek提示词设计与应用PDF课件面向AI开发者、技术爱好者及希望提升提示工程技能的职场人、教师、学生等群体。资料从推理型DeepSeek-R1与非推理型DeepSeek-V3模型的性格差异切入先解释思维链CoT与“草稿纸”式推理机制再讲解六何分析法、Few-shot少量样本提示等提问策略并演示如何让DeepSeek制作炫酷图表和动画同时结合幻觉现象给出限制知识来源、明确时间边界、引入RAG检索增强框架等规避手段还简要介绍了Manus智能体及其特点。资源共1个文件为PDF单文档整体大小2.27MB便于下载后按章节阅读或直接用于内部培训、个人自学与课程分享。目前已有247人学习内容覆盖提示词设计、幻觉避免、智能体对比三大主题适合作为从入门到进阶的系统性参考资料。 很多人第一次看到《2025厦门大学DeepSeek提示词设计、幻觉避免与应用.pdf》这个标题时以为它只是一份提示词模板合集。但把“提示词设计”和“幻觉避免”放在一起本身就是工程问题的正确打开方式提示词决定模型行为的上限幻觉治理决定产出能不能直接投入使用。这份资料在讲什么一句话概括——教你用一套可复现的方法让DeepSeek在真实任务里少编、少漏、少翻车。它适合所有拿着DeepSeek做正式产出的人写文案、做代码、跑数据、搭Agent。网传的PDF版本往往图文并茂但真到了落地的时候你手上真正缺的是一套顺手的话术结构、几个防幻觉的硬性约束以及遇到问题时的排查路径。下面这些内容就是我把这套方法论拆开之后的“可执行版本”。2. DeepSeek提示词设计先把“角色、任务、格式”三件事说清楚2.1 分清你用的是“通用对话”还是“推理模式”拿到DeepSeek之后第一件事不是研究怎么写提示词而是先搞清楚你要用它的哪种能力。DeepSeek开放平台和官方对话入口通常区分两类模式一类是通用的对话模型响应快、风格灵活适合写作、改写、分类、抽取这类“一次成型”的任务另一类是推理增强模式会在内部做多步推导适合数学、逻辑、代码排错这类需要“想清楚再答”的任务。这两类模式下的提示词设计策略完全不同。通用模型需要你替它把步骤想好提示词里尽量给出清晰的路径和格式推理模式恰恰相反你给它的约束越细它的内部推导空间就越小反而容易答错。我见过不少人在推理模型里写“请你一步一步思考”或者强行套思维链模板结果模型生成了大量与任务无关的中间推理速度慢了一半答案也没变好。与其迷信这类技巧不如把提示词设计看成三件事角色、任务、格式。角色告诉模型“你是谁、你在替谁干活”但别指望一句“你是专家”就能改变事实准确性。任务用一两句话说清楚输入是什么、输出是什么、边界在哪里。格式把输出的结构固定下来包括字段、顺序、长度和不允许出现的东西。2.2 一套能直接抄的System Prompt结构我常用的System Prompt不是一段长篇大论而是按固定结构拼出来的。下面这段结构可以直接套用里面每一个字段都有对应作用system_prompt # 角色 你是一名资深技术资料编辑擅长从原始材料中提取结构化信息。 # 任务背景 用户会提供一段技术文档片段。你的任务是从中提取模型名称、适用场景、限制条件三项信息。 # 输出要求 - 严格按 JSON 输出不要输出任何 Markdown 代码块标记。 - 如果原文缺失某项信息对应字段填 null不要自行推测。 - 禁止添加原文中不存在的技术名词或型号。 # 输出示例 {model: DeepSeek, scenario: 长文本摘要, restriction: null} # 处理流程 1. 先通读原文标记与模型相关的句子。 2. 逐字段提取确认每一项都能在原文中找到依据。 3. 输出前检查一遍字段值是否都能溯源到原文。 这段结构的核心不是让模型“表现好”而是把答案空间压缩到一个可控范围内。“输出示例”这一步尤其重要它是模型理解格式的最直接锚点比你在提示词里写十遍“请按JSON格式输出”都管用。“处理流程”这一段则是给模型一个轻量级的执行顺序让它不要跳步骤。参数说明如果你是通过API调用建议同时设置temperature0.3、top_p0.9左右。temperature控制的是采样随机性0.3 既保留了少量表达多样性又不至于让输出每次都不一样如果做的是分类、抽取这类确定性任务直接调到 0 或 0.1 都行。top_p我一般固定 0.9 不动除非输出质量明显异常才会去调整它。2.3 温度、上下文长度与“幻觉的温床”之间的一次实测对比提示词写得再好采样参数不对也白搭。下面是我在不同任务上常用的参数对照可以直接作为起点任务类型temperaturetop_pmax_tokens说明分类、抽取、格式化输出0 ~ 0.20.9按需追求确定性抑制随机发挥文案写作、改写润色0.7 ~ 0.90.95略大于输出长度保持表达自然允许适度发散代码生成0.1 ~ 0.30.9按任务预估低温度减少语法幻觉创意头脑风暴1.0 ~ 1.31.0不限高温输出更多灵感但需人工筛选这里我要提醒一个特别容易翻车的地方max_tokens设置太短模型在输出被截断时会强行“收尾”编一个看似完整的结尾——这在幻觉里属于最隐蔽的一种。现象是结果看起来结构完整但后半段细节全是模型自己补的。解决方式很简单任务复杂时给足长度余量或者把大任务拆成几次请求不要让模型在一段输出里“挤着说完”。另一个关键变量是上下文长度。DeepSeek 的上下文窗口很大但检索质量并不会随着上下文长度线性提升。长文档进来之后模型对中间段落的利用率明显低于首尾。因此我在处理超长文本时不会把全文一次性塞进提示词而是先做切片再逐段抽取最后用一次汇总请求把结果合并。这一步做不好你后面的幻觉治理再努力也白搭。3. 幻觉避免从“警告模型别编”到“让流程没法编”3.1 模型为什么会一本正经地编造四个源头先搞清楚幻觉不是模型“坏了”而是它的生成机制本身附带的结果。DeepSeek 和所有大语言模型一样是在做概率性的下一个词预测而不是数据库查询。“一本正经地胡说八道”通常来自四个源头第一是训练数据中本身缺乏对应信息模型只能根据已有模式“猜一个合理答案”第二是解码采样时温度设置过高让低概率词被选中第三是长文本场景下模型对上下文开头和结尾之外的中段内容注意力不足第四是提示词诱导——你有没有在提示词里写过类似“请结合2025年的最新政策”这种带时间但没有任何材料支撑的句子模型为了满足你的要求只能硬编一个。理解了这四个源头你就会发现“请勿编造”这种警告是最没用的抑制手段。它只是在输出层加了一个“不要编”的短期指令模型为了遵守指令最省力的做法是反过来提高自己的语气确定性——说得越肯定越像真的。正确方向是改流程要么给模型提供可追溯的信息源要么让输出结构里带上证据字段要么在工程侧把知识检索和生成分开。3.2 提示词层防幻觉强制溯源、否定式限制、置信度标注在提示词层做防幻觉约束最有用的三个动作是强制溯源、否定式限制、置信度标注。强制溯源要求每个关键结论都带出处引用没有出处就明说否定式限制的价值在于给模型“不答”的合法出口置信度标注则让下游使用者对输出质量有判断依据。structured_output_prompt 请基于我提供的资料片段回答以下问题。 资料片段 {context} 问题{question} 要求 1. 只使用资料片段中出现的信息作答。 2. 每个观点后面用“【依据】”标注对应原文关键句。 3. 如果资料中没有答案直接回复资料中未提供相关信息。 4. 在回答末尾标注置信度取值范围为0到1格式为“置信度0.8”。 5. 禁止使用“可能”“大概”这类模糊词来掩盖信息缺失。 输出格式 回答... 【依据】... 【依据】... 置信度... 这个模板的核心是第 2 条和第 3 条。“依据”字段会在生成时持续提醒模型“你的回答会被追溯”这比单纯说“不要编造”有效得多因为它把幻觉问题从道德约束变成了格式约束。第三条是给模型留了一条“合法退路”很多模型在被迫回答时才会编造给了出口之后它反而会诚实地告诉你缺信息。参数说明使用这个模板时把max_tokens适当放大一点因为多字段输出比纯文本更占空间。我曾用同样的temperature0.2跑了 50 个抽取任务加“依据”字段的那组人工抽检出的错误引用数量少了约六成。注意“依据”字段不要用“根据资料”这类空话开头要逼模型引用原文里的具体短句可验证性会高很多。3.3 工程层治幻觉RAG 检索、结构化输出与外部工具兜底提示词里的约束属于“软约束”它在大多数情况下有效但绝不能依赖它兜底。真正让幻觉率大幅下降的是把生成过程从“模型自己知道”改成“模型查到了再说”。这个过程被称为检索增强生成缩写就是热词里常看到的 RAG。常规做法是先把你的资料库做切片和向量化用户提问时先在库里检索出最相关的片段再把片段和问题一起拼进提示词让模型只基于这部分内容作答。这个流程把模型从“唯一信息源”变成了“信息加工者”。DeepSeek 本身不提供向量检索服务但你可以用开源的向量库或云服务把这块做起来整体链路并不复杂。另一层更硬的约束是结构化输出。DeepSeek 开放平台支持使用 JSON Schema 断言输出格式模型必须严格按照约定的结构返回。这对幻觉治理的价值在于它堵死了“正确但不合规范”和“合规范但语义含糊”的输出路径。下面是一个简单的接入示例from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, temperature0.1, response_format{type: json_object}, messages[ {role: system, content: 你是一个信息抽取器只提取用户问题中提到的信息不补充任何额外内容。}, {role: user, content: 从这句话中提取公司名和金额‘A公司向B公司支付了500万元’} ] ) print(resp.choices[0].message.content)这段代码的逻辑说明通过response_format参数开启 JSON 输出就等于在 API 层面对模型施加了一个“必须返回结构化消息”的约束。你可以在 system 消息里额外声明字段规则也可以把 JSON Schema 放在请求参数里做更强制的校验。注意不是所有模型都支持response_format使用时先确认所使用的模型接口是否支持temperature建议同步调低否则容易出现结构合法但内容反复变换的情况。3.4 用多次采样做一致性探测把模型当黑匣子来测试模型内部是怎么“想”的我们实际上无法完全观测但可以把它当黑匣子来测。一致性探测的原理非常简单同一个问题让模型多回答几次如果答案高度一致说明该信息在模型内部有相对稳固的依据如果每次回答都不一样甚至出现互相矛盾那这些内容大概率是靠猜的。import openai client openai.OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) question DeepSeek的上下文窗口最大支持多少 answers [] for i in range(5): resp client.chat.completions.create( modeldeepseek-chat, temperature0.9, messages[ {role: user, content: question} ] ) answers.append(resp.choices[0].message.content) for idx, ans in enumerate(answers): print(f第{idx1}次: {ans})我把temperature刻意调高到 0.9是为了在采样层面制造足够的随机性。如果高温度下模型多次说出同一个数值那它不太可能是运气。参数上要注意每次探测使用完全相同的提示词单独调整温度即可如果发现答案在关键数字、名称、日期上反复跳跃那就应该把该问题归入“高风险问题”后续要么换用 RAG 方案要么在提示词里强制要求 “无法确认时直接说不知道”。需要明确的是这个方法只能做辅助评估不能证明答案是事实正确的。这里有一个很常见的误区一致性高只能说明模型“稳定地记住了某个模式”不代表模式本身来自真实事实。所以“多轮一致性”要配合“人工抽检”一起用别只看一个维度。这也是我在团队里要求每个人跑回归测试时都要保留原始回答记录的原因——先留证据再谈判断。4. 把DeepSeek放进真实工作流问答、代码与Agent的三种接入方式4.1 文本生产场景资料抽取、写作辅助与长文汇总文本类场景是提示词设计最容易见效的地方因为输入输出都发生在提示词内部不需要额外搭系统。以资料抽取为例我常用的结构是“角色 抽取字段清单 缺失处理策略 输出格式约定”。和 2.2 里的模板相比这里需要特别强调“缺失处理策略”——当原文没有对应字段时模型默认行为是“根据上下文推断”而你要明确禁止这种行为。写作辅助场景则要反过来给模型更大的自由度。我会尽量减少格式约束只固定“语气、受众、篇幅、必须包含的关键信息”四个要素。写提示词的时候有个小习惯把“不要写什么”也告诉模型比如“不要使用‘赋能’‘抓手’‘闭环’这类词汇”或“不要出现数据引用除非你来自原始资料”。这种否定式限制之所以有效是因为它缩小了采样空间把模型从高频套话里拉出来。长文汇总是我见过翻车率最高的一类任务。很多人直接把一篇上万字的材料丢给模型然后要求“总结核心观点”。结果模型往往会漏掉埋在文中段的细节顺带自己补充几个不存在的“重点”——这其实就是第三章讲到的“位置偏置”加“信息缺失补偿”的双重问题。我的处理方式是先分段抽要点再把要点合并成大纲最后按大纲生成摘要。两次请求之间的提示词设计保持一致第二次输入时明确告知模型“下面是第一次抽取的要点禁止新增原文之外的结论”。4.2 代码与工具链场景把DeepSeek接入IDE和自动化流程DeepSeek 在代码生成上的实际表现已经让它成了不少开发者日常工具链里的一环。常见接入方式包括在 IDE 里装上调用 DeepSeek 的插件做补全和解释用脚本调 API 做代码审查或者接入代码托管平台做提交信息生成。热词里频繁出现的“codex接入deepseek”“vscode接入deepseek”本质上都是同一个动作用 OpenAI 兼容协议的 API 地址替换掉原来默认的模型端点。from openai import OpenAI client OpenAI( api_key你的API密钥, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个代码审查助手只标记明确问题不做风格建议。输出格式问题位置 / 问题类型 / 修改建议。}, {role: user, content: 请审查这段代码\ndef calc(a, b):\n return a / b} ] ) print(resp.choices[0].message.content)这个例子里关键的参数是model和base_url。DeepSeek 开放平台提供兼容 OpenAI SDK 的接口意味着你现有的调用代码只需要改这两处就能切换过去。审查类任务的temperature我建议设在 0.2 以下因为代码审查要求确定性风格类建议反而会干扰判断。注意如果你用deepseek-reasoner这类推理模型做审查不要同时开启流式输出和强制 JSON 格式部分场景下会报错或延长等待时间这是不少人第一次接入时踩过的坑。4.3 Agent 场景当模型开始调用工具幻觉的形态也变了把 DeepSeek 接入 Agent 框架之后幻觉问题会换一种更隐蔽的形态出现模型不再单纯“编造答案”而是“编造工具调用”。典型翻车场景是——模型需要查询天气却没有调用天气工具而是直接编了一个温度值或者调用了工具但传给工具的参数是从上下文里“猜”出来的根本不是用户原始输入。这个过程用热能词描述就是tool calls 的输出必须即时返回给模型继续处理。把 DeepSeek 接进 Agent 流程时要特别关注工具调用和输出的协作节奏。如果消息中出现了 tool calls却没有把工具的真实结果以tool角色消息返回给模型整个对话轮次就会中断或卡住日志里常见到“tool calls need immediate results”类的报错。另外在编排 Agent 时我一般会在系统提示词里明确写一句“工具返回空结果时如实描述错误工具返回数据后才能基于数据作答。”没有这句约束模型就会在工具静默失败时用幻觉兜底。如果你要用开源编排框架比如热词里常被提到的 harness把 DeepSeek 编排进多智能体流程有一点要格外留心框架默认的提示词模板是按 OpenAI 或 Claude 编写的直接迁移到 DeepSeek 上可能出现格式解析问题。我的做法是先把框架里每个智能体的系统提示词过一遍删掉与模型绑定紧密的字段要求换成统一的输出协议。这一步处理好了后续调整单个智能体的行为会非常顺手。5. 排查清单提示词与幻觉治理中的 6 个高频坑5.1 加了“不要编造”之后模型反而编得更严重现象System Prompt 里写了“严禁编造、不得虚构”实际回答里却出现了更多语义模糊的表述比如用“据相关资料显示”这种没有指向的话带过。原因否定式指令没有给模型替代路径。模型唯一知道的是“不能瞎说”但它不知道“不知道的时候该说什么”于是只能用高置信度的含糊话术规避违和感。解决把“不要编造”替换成“如果材料中没有明确信息请在回答的第一句写资料未提供该信息。然后停止作答。”给模型一条合法的退出通道它就不会自己硬闯了。5.2 对话轮次较长之后模型开始重复用户的问题内容现象多轮对话进行到第十轮左右模型开始重复用户问题里的措辞甚至有把用户话术原样返回的情况。原因上下文过长导致早期的 System Prompt 权重被稀释模型在“延续对话”和“完成任务”之间失去了优先级。解决把 System Prompt 压缩到最核心的 5 到 8 句话并且把最重要的规则比如输出格式、退路声明放在 System Prompt 的第一段。不要在每轮用户消息里重复规则这会让模型误以为规则只适用于当轮。长期方案是定期做上下文裁剪把已完成的历史轮次摘要化。5.3 调低 temperature 到 0输出依然有随机性现象在 API 请求里设置temperature0连续请求同一问题两次返回结果仍有差异。原因temperature0只是让采样概率分布“几乎确定”但 GPU 的浮点计算本身有细微不确定性尤其在长输出场景下误差会累积另外部分接口还会隐含应用层采样。解决不要指望通过temperature0拿到完全确定性的输出。如果你需要“同一输入必须得到同一结果”的稳定性最佳做法是设置seed参数如果接口支持并且固定top_p、max_tokens、消息顺序完全一致。仍不满足再退一步接受输出的微差异在后处理层面对齐关键字段。这条属于血泪经验越早接受调试时越不内耗。5.4 用“你是行业专家”做开场答案质量反而下降现象给模型指定“你是拥有10年经验的xx领域专家”后回答语气确实自信了但内容开始充斥着套话和泛化结论具体细节反而变少。原因角色标签激发了模型对“专家话术”的概率偏好写作风格上的“确定性”替代了事实上的“准确性”。解决在容易产生幻觉的任务里用“你是信息整理员”替代“你是专家”主动压低模型的输出姿态把专业能力体现在任务描述里比如“按行业术语提取信息”而不是通过身份标签去激发它。身份标签更适合文案类任务不适合事实类任务这一点要按场景而定。5.5 本地部署后效果和 API 版本差一大截现象在自己机器上部署的 DeepSeek 模型同样一段提示词输出质量明显低于开放平台的在线版本。原因本地部署的模型权重版本、量化精度、上下文长度设置和 API 版本不一致另一个大变量是采样参数——本地推理框架的默认temperature往往和 API 默认值不同。解决先在本地复现 API 端的全部参数再对比生成结果。具体来说把temperature、top_p、max_tokens、presence_penalty以及 System Prompt 统一配置一遍逐步排除差异项。如果量化方式是 8bit 或 4bit就要预期语义质量会有一定下降尤其在文本分类和实体抽取这种对细节敏感的任务上。5.6 幻觉治理工具链越加越乱到头来不知道问题出在哪现象提示词、RAG、结构化输出、人工复核全上了但整体效果并没有变好反而因为链路太长出了问题不知道从哪一环查起。原因每一层都在做“尽力而为”的约束但没有建立可观测性。问题出现时你无法判断是提示词指令失效、检索片段不相关、还是输出格式解析出错。解决在链路里给每一层加日志记录。最简单的做法是在每次调用前后打印入参和出参记录检索命中的文档及其相似度分数。排查的顺序固定为先看检索内容是否覆盖答案再看提示词是否遗漏信息最后看解析结果是否被格式问题截断。不要一上来就改提示词先定位故障层再做处理。这个习惯我坚持了很久省下的排查时间远超搭建日志那点成本。6. 进阶验证技巧给 DeepSeek 提示词改动建立回归测试集提示词这个东西最难受的地方在于“改好了 A 场景却弄坏了 B 场景”。我以前经常碰到这种情况把一个抽取任务的模板优化后单测表现很好结果全量跑起来发现日期格式全乱了。直到后来我养成了一个习惯——维护一份固定的小批量回归测试集每次改提示词都先跑一遍再做全量调用。回归测试集不需要大20 条足够。但覆盖要均衡5 条从原始资料里能直接找到答案的“直接命中”问题5 条资料里完全没有答案的“无中生有”问题5 条需要多段信息组合的“推断归纳”问题剩下 5 条放格式敏感型问题比如日期、金额、编号的抽取。每个问题保存一个标准答案或“预期失败模式”每次提示词或参数有改动就把这 20 条跑完用脚本或肉眼比对效果变化。这里有一个很实用的技巧给每条测试样本打上幻觉风险标签。所谓幻觉风险标签就是对每个问题进行三维评估——资料覆盖率是“高/中/低”答案确凿度是“高/中/低”用户追问可能性是“高/中/低”。三高样本属于高风险项需要单独走 RAG 或人工复核。这个标签体系的意义在于它让幻觉治理从一个“整体问题”变成了“局部问题”你不需要在每次改动时全量复盘只看高风险样本的表现就够了。跑回归集的时候我还有一个习惯临时把temperature调高到 0.9 再跑一遍。低温度下通过的高风险样本高温度下往往就会露馅——出现前后矛盾、数值漂移和措辞含糊。这一步相当于压力测试能提前暴露模型在边界情况下的真实水平。跑完压力测试再把参数调回线上值做最终确认。这套流程一开始看起来像给自己找活干但用久了你会发现它就是给提示词改动上的“后悔药”。我现在每次调提示词第一件事不是看新写法多惊艳而是先跑一遍回归集看有没有把旧场景弄丢。这个习惯帮我挡掉了至少十次线上翻车。同样的方法也适用于幻觉治理的验证——别等你把新方案写完了才发现它解决了一个问题、制造了三个新问题。也把这些整理进你自己的项目文档替换里面的示例跑一遍希望你也能少走一些我走过的弯路这算是做这行非常珍贵的经验了。本文还有配套的精品资源点击获取