简介一份由厦门大学软件与人工智能专家程希冀主讲的PDF学习材料聚焦DeepSeek提示词设计、推理型与非推理型模型的提问策略以及幻觉成因与规避方法如限制知识来源、明确时间边界、检索增强RAG。内容兼顾职场文档、图表动画生成、学习辅导等落地场景并简要介绍了Manus智能体的特点适合AI研究人员、开发者及对提示工程感兴趣的各类使用者兼具理论讲解与实操启发。文件为单个PDF共1个文件压缩包大小约2.27MB便于直接阅读和保存。目前已有248人学习资料以讲座式要点梳理为主具体覆盖DeepSeek-R1与V3的性格差异、思维链CoT解题逻辑、六何分析法、少量样本提示和结构化提示等实用技巧可帮助读者建立与DeepSeek高效交互的系统方法减少对AI产出可靠性的误判。1. 一份标着“2025厦门大学”的PDF为什么值得停下来读做内容自动化这半年我收到的“DeepSeek提示词设计、幻觉避免与应用”资料不少大部分是培训机构攒出来的拼凑稿。但看到标着2025厦门大学这份PDF时我还是认真翻了。不是因为头衔而是它把三个问题串起来了提示词怎么设计才不靠碰运气幻觉怎么从机制上压制应用层怎么把对话能力变成可用服务。这三个点正好是生产环境里最卡流程的地方。这篇笔记把我自己跑通的方案、参数和踩坑记录写出来给同样在搭提示词的人一个可复制的底稿。新手能跟着走熟手能直接对参数。2. 提示词设计先理解DeepSeek怎么“听”指令2.1 指令遵循的边界为什么提示词不是玄学是工程很多朋友问我DeepSeek提示词到底有没有标准写法。我的回答是别把它当人把它当做一个读过很多书、但偶尔会自作聪明的实习生。它经过指令微调确实能听懂指令但“听懂”本身是概率性的。同一个提示词多问两次措辞和侧重点可能完全不同你把约束写得越清晰它越不会自由发挥。也就是说提示词设计的本质不是“写出让模型喜欢的句子”而是“压缩生成空间把不确定性降下来”。我见过最典型的反面案例是用户一上来就说“帮我写个文章”模型立刻回一句“好的请告诉我主题、字数、目标读者”。这一来一回看似礼貌实际浪费一次请求。在API调用里每次请求都花钱而且下游流程根本没法写死。所以生产环境里我们不允许模型反问必须用提示词把问题边界全部堵死。有人问我用不用DeepSeek Harness这类工作流工具。我的观点是工具只解决“流程编排”不解决“提示词质量”。你先得能徒手写出一条稳定的提示词再考虑把它塞进harness里跑多轮。顺序反了只会得到一个自动化翻车管道。2.2 可复用模板任务、背景、约束、格式四段式我自己常用的模板是四段式如下面这段。它不是一个花哨的提示词框架而是把生产环境必需的信息都占住位避免遗漏。# 任务 写一篇600字公众号推文主题是“如何用DeepSeek降低客服成本”。 # 背景 读者是中小企业主不懂技术关心成本和易用性。 不要让读者觉得要学编程重点放在接入成本和维护难度。 # 约束 1. 只能使用下面给出的三点优势 a) 接入简单无需自建模型 b) 相比人工客服成本更低 c) 支持7*24小时在线响应 2. 不要编造统计数据。如果你要引用数据用“据行业反馈”代替具体数字。 3. 如果某个卖点你没有把握直接跳过不要展开。 # 输出格式 标题不超过18字 正文按“为什么现在客服贵-DeepSeek怎么省钱-怎么开始”结构写这段提示词里最容易被忽略的是“背景”。背景决定了模型的用词深度给普通用户写的文案和给技术总监写的方案完全是两种表达。你不给背景模型默认按通用读者或最高频场景写结果往往不是你要的。“约束”部分也有讲究。我写“只能使用下面给出的三点优势”这比“不要写别的”要强得多。原因是大模型对正向指令的遵循概率远高于负向指令。你告诉它能用什么它就不太敢越界你只告诉它不能干什么它反而会试探边界。另外第2条要求“没有把握就跳过”这也是幻觉避免的第一道防线。2.3 三大采样参数temperature、top_p、max_tokens的调法提示词写对了还要参数配合。DeepSeek API兼容OpenAI风格最常用的三个参数是temperature、top_p、max_tokens。它们的默认值在不同版本里略有差别但调参思路是通用的。参数作用推荐设置temperature控制随机性越低越稳定越高越发散事实整理/代码0.2~0.4创意写作0.8~1.0top_p核采样控制候选词累计概率相当于另一种随机性控制一般保持0.8~0.9和temperature不要同时调太猛max_tokens限制输出最大长度公众号文章1500~2000问答500左右实际项目中我习惯固定top_p为0.9只调temperature。比如写产品介绍想要风格自然又不跑偏设0.5如果做知识库问答要求严格跟原文一致就设0.2。曾经有同事把temperature拉到1.5结果同一篇产品稿里前半段像销售后半段像学术论文这就是随机性过大模型状态在漂移。提示不要天真地以为temperature调低就万事大吉。低温度会让输出更稳定但如果提示词本身带了错误前提模型照样会顺着错误生成只是错误变得更有“逻辑性”。所以参数只是辅助核心还是提示词。2.4 什么时候加少样本示例如果四段式模板仍然不够稳可以塞2到3个示例这就是少样本few-shot提示词。示例的作用是给模型一个模仿锚点。举个例子你要模型把长段落压缩成一句话摘要光说“压缩成一句话”可能得到各种奇怪版本。但你给两条示例摘要模型输出的格式会立刻回归。任务把文本压缩成一句话摘要。 示例1 文本公司原定于周一的发布会因台风改期至周三地点从滨江馆换成国际会展中心。 摘要公司发布会改期至周三并更换场地。 示例2 文本项目组已完成第一轮测试发现3个bug其中2个已修复1个仍在定位。 摘要项目第一轮测试发现3个bug已修2个剩1个排查中。 现在请处理 文本... 摘要注意示例不是越多越好。我的经验是2~3个足够超过5个反而占用上下文还有可能让模型学到示例里的噪声。另外示例之间要拉开差异不要都一个句式。比如一个示例是有因果关系的一个示例是并列关系的这样模型才能学到“压缩”的逻辑而不是只抄句式。3. 幻觉避免让模型敢说“不知道”3.1 幻觉从哪来知识截止、锚定与诱导幻觉不是DeepSeek特有所有大模型都有。要压制它先得知道它从哪来。第一个来源是知识截止。模型训练语料有时间边界在那之后发生的事它没有“见过”。但模型不知道它不知道它会用语言模型的“平滑补全”能力把不存在的新闻、数据、事件填得像真的。比如你问“2025年厦门大学发布的DeepSeek指南里写了什么”如果训练数据里没有它可能会编一本不存在的目录这是典型的幻觉。第二个来源是锚定偏差。提示词里如果带着错误前提模型会沿着这个前提推理。比如你写“我已经用LangChain接好了知识库为什么检索老是返回无关结果”模型会自动假设你真的接好了然后给出“可能是embedding模型不匹配”这类分析而不是提醒你“你目前没有文件加载器”。这不能全怪模型是提示词自己把答案引向了错误方向。第三个来源是诱导性提问。模型是被训练成“给出有帮助的回答”的这导致它对“你能否解释一下某某”这类问题若没有把握也会硬着头皮解释。再加上采样随机性就给了幻觉空间。3.2 四招压制幻觉限定来源、要求置信度声明、显式拒答、后校验针对上面几个来源我总结了四招顺序按成本从低到高。第一招限定来源。在提示词里直接贴资料声明“只能使用资料中的信息”。这属于直接从源头切断。限定来源时资料越结构化越好比如用“编号事实”的列表比一大段粘贴更好。第二招要求置信度声明。让模型不确定的时候明说。比如在约束里写“如果某项信息你没有把握在回答开头加【不确定】”。这招的好处是保留模型的生成能力只是给它一个“退路”它就不太会硬编。第三招显式拒答。更严格一点直接命令“如果问题不在你的知识范围内回复‘无法确认’不要解释”。适合客服场景适合回答准确率优先的B端场景。第四招后校验。这是工程兜底不依赖提示词自觉。把模型输出的关键事实、数字、实体抽出来用代码和知识库比对不匹配就丢弃或提示人工复核。这招成本最高但效果最稳定。后校验我没法给你一套通用代码因为知识库千差万别。但思路是这样先让模型输出结构化字段例如用JSON格式输出“事实列表”然后用正则或数据库查询逐一比对。比如提取所有金额数字如果知识库里不存在就认为该项疑似幻觉重写或拦截。这种做法适合对准确率要求高的B端场景成本高但可靠。3.3 一个“防幻觉”提示词片段的设计过程我们拿一个真实场景演练想做一个“产品客服QA”机器人回答基于官方FAQ。系统你是XX产品的客服助手。请严格根据下方FAQ片段回答用户问题。 FAQ [Q1] 产品支持哪些支付方式 A支付宝、微信、银行卡。 [Q2] 发货时效是多久 A付款后48小时内发出。 [Q3] 退款政策 A7天无理由退货退回运费由买家承担。 回答规则 1. 如果用户问题在FAQ中找不到对应条目回复“这个我不太确定已转人工”不要猜测。 2. 不要扩展FAQ之外的功能介绍。 3. 如果用户问的是实时价格告知“价格以官网为准”。这个片段的设计逻辑先把FAQ结构化贴进去相当于限定来源回答规则里第1条就是显式拒答第3条处理知识截止导致的实时性问题。如果你把这段提示词设temperature0.2再跑一百次它几乎不会编出FAQ里没有的信息。注意不要以为把“不要编造”写在提示词里就完了。模型不是执行布尔规则是概率生成。你必须给它“不编造时说什么”的具体话术它才知道该怎么表现。这就是“显式拒答”比“不要乱说”有效的原因。我们再看一个不设防的对照组。同样的问题“有哪些支付方式”如果提示词里没有FAQ限定模型可能回答“支付宝、微信、银行卡、Apple Pay、PayPal”。这看起来很全面但其中有至少两个是编的。加了限定后它会回答“根据FAQ支持支付宝、微信和银行卡”如果用户问Apple Pay它就说“FAQ中没有提到”。这就是为什么我把“拒答话术”放在生产提示词的强制项里。很多AI客服翻车截图本质上不是模型笨而是提示词没给它说“不知道”的胆量。4. 避坑提示词工程里最容易翻车的5个场景这一章是给已经上手、但总在某个地方反复失败的人看的。每一条都是我实际踩过或帮同事排过的坑。4.1 模型总反问不直接给结果现象你输入“帮我写一个活动方案”模型返回“好的请问活动主题是什么预算多少有多少人参加”看上去很贴心但在脚本化调用里这一步就是灾难因为下游不会处理它的反问。原因提示词信息不足模型默认进入“澄清模式”。大模型在训练时学会了主动提需求但你没告诉它“不要问”。解决在提示词里显式加一句“如果以下信息缺失按常见场景默认处理不要反问”。比如写一个30人的部门团建方案预算5000元。 如果信息不够采用默认设定周六举办地点在城市周边活动类型为户外拓展。 不要反问直接输出方案。这招简单但极其有效。我后来把所有自动化调用脚本的提示词末尾都加了“不要反问”输出稳定率直接提了一截。4.2 temperature调太高输出发散跑题现象写营销文案时temperature设为1.2结果第一段写得很好第二段突然开始押韵第三段上升到哲学。前后风格割裂。原因过大的temperature让模型在高概率词之间随机跳跃token序列的“粘性”不够。解决创作类任务也不要超过1.0事实类任务0.2~0.4。如果既要风格又要稳可以在提示词里加一句“保持全文语气一致不要变换表达风格”。另外top_p保持0.9不要和temperature同时拉满否则双重随机性更难控制。4.3 多轮对话中上下文被挤掉现象用API连续对话第一轮设定了“你是严谨的审稿人”第二轮用户发来论文模型忘了审稿人角色变成普通读者。原因请求消息列表里历史消息太长系统消息和角色设定被顶出上下文窗口或权重降低。解决两种方式。第一把角色设定放进每一轮user消息的开头重复强调。第二每轮先压缩历史摘要再拼接当前问题。这里有个很实用的经验当DeepSeek到达对话上限之后新对话不会自动承接上一个对话。你需要主动把前一轮的结论、约束、用户意图提炼成一段摘要放进新对话的system消息里。比如“你一直在帮用户改周报用户是设计师语气要温和上一轮已经确定要将本周完成的三项任务列在开头现在继续”。这样新对话就“想起”了旧对话。4.4 提示词里带了错误前提模型照单全收现象我问“为什么在DeepSeek API中同时设置temperature和top_p会导致报错”模型长篇大论解释了参数冲突的机制。实际上API并不会因为同时设置两者而报错。原因模型缺乏“纠错”意识它会顺着用户的错误假设编造一个合理的解释。这属于锚定偏差。解决在提示词里加一句“如果我描述中存在错误前提请先指出”。也可以拆开问先问“temperature和top_p能否同时设置”拿到基础事实后再叠加问题。更安全的做法是别把“事实”置于提问之前而是把已知事实放入“背景”让模型先判断。4.5 本地部署和API表现不一致现象同一个提示词同一套temperature在API上生成内容通顺换到本地vLLM部署的量化模型上输出变短且语气生硬。原因本地量化精度损失采样参数默认值不同甚至模板拼接方式不同。vLLM的采样参数有自己的默认值比如top_p可能和API不一致。另一个容易忽略的是API会自动使用厂商的system提示词模板本地部署不一定加载同样模板。解决在本地推理代码里显式传入temperature、top_p、max_tokens不要依赖默认值。同时确认模型tokenizer的chat模板。如果量化后幻觉更严重就把提示词里的拒答指令写得更具体比如“如果你不确定直接回答‘我无法确认’”不要只写“不要编造”。5. 应用落地从API调用到公众号自动生成流水线5.1 用DeepSeek API实现可控的提示词调用先把最核心的代码贴出来。假设你已经有API Key用Python的requests库即可不需要专门装SDK。import requests API_URL https://api.deepseek.com/v1/chat/completions API_KEY sk-你的密钥 prompt # 任务 写一篇600字的公众号推文主题是“如何用DeepSeek降低客服成本”。 # 背景 读者是中小企业主不懂技术关心成本和易用性。 # 约束 1. 只写以下三点接入简单、成本更低、7*24小时响应。 2. 不要编造统计数据如果要举例用“我们可以想象一个场景”开头。 3. 不确定的卖点直接跳过。 # 输出格式 标题不超过18字 正文口语化用小标题分段 payload { model: deepseek-chat, messages: [ {role: system, content: 你是企业服务领域的资深文案写作时会自动检查每条表达是否有依据。}, {role: user, content: prompt} ], temperature: 0.3, top_p: 0.9, max_tokens: 2000, stream: False, } resp requests.post(API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload) if resp.status_code 200: data resp.json() print(data[choices][0][message][content]) else: print(错误码, resp.status_code, resp.text)代码逻辑把四段式提示词放在user消息里把“角色自查要求”放在system消息。这样分工的好处是system负责稳定人设user负责每次动态任务。参数里temperature0.3是为了让推文风格稳定max_tokens2000保证600字正文不会被截断。top_p0.9是保守设置留一点用词多样性。如果你要批量生成不要每篇文章都写死一个prompt变量建议把prompt抽成模板用字符串format替换主题、字数等。例如def build_prompt(topic: str, words: int 600): return f# 任务 写一篇{words}字的公众号推文主题是“{topic}”。 ...这样后续改提示词只需要改函数内部调用方不用动。这是把提示词当代码管理的起点。注意API错误码主要有401鉴权失败、429限流、400参数不合法。遇到400优先检查messages参数是不是标准数组、temperature有没有超过范围。遇到429不要立刻重试加退避sleep。5.2 基于扣子Coze搭公众号文章生成工作流不少人问“我想通过扣子制作一份能够自动生成公众号文章的能力该怎么设计提示词”。我拿一个实际工作流给你拆解。在扣子里你不需要写Python拖节点就行。我的配置是三段式第一步内容采集节点。输入一个链接或一段文本用插件提取核心事实。这里的关键是采集插件输出的是“事实清单”不是原文。让数据先结构化后面提示词才有的放矢。第二步生成节点。把上一节点的输出放进“背景”变量然后使用四段式模板。扣子里有一个“人设”字段我就把system角色写在那里把动态任务写在用户输入里。生成节点的温度建议设在0.3到0.5之间。第三步审校节点。接入另一个模型调用提示词写“只修改事实错误和不通顺的句子不要改动风格不要新增内容。”这一步就是前文说的后校验。扣子的价值不是“生成”而是把生成和审校串成流水线让每次发布前都过一遍质检。需要注意扣子发布成bot后每次用户对话都是新会话模型不会记住上一次的约束。所以开场白里要重复一遍提示词核心要求比如“我会根据你提供的主题生成公众号文章字数默认600如果你没给背景我会假设读者是普通大众。”5.3 本地部署与vLLM推理时的提示词一致性如果你数据敏感需要内网部署DeepSeek可以用vLLM起一个兼容OpenAI的推理服务。这里有一个常见误区直接用openai库调用本地服务但模型名字、base_url、提示词模板都要改。用vLLM加载模型的代码from vllm import LLM, SamplingParams llm LLM( model/data/models/deepseek-7b-chat, trust_remote_codeTrue, dtypehalf, ) prompt ( 你是一位严谨的客服助手回答时只能依据FAQ。若不确定直接说无法确认。\n 用户问题退款多久能到账\n 客服回答 ) params SamplingParams( temperature0.2, top_p0.9, max_tokens1024, ) outputs llm.generate([prompt], params) print(outputs[0].outputs[0].text)这里的prompt拼接是按该模型自己的chat模板手动拼的。不同的模型tokenizer有自己的模板有的要求特定标签包裹。如果你直接用OpenAI风格的消息列表本地端不一定认。一个更稳妥的办法是把消息列表转换成tokenizer的apply_chat_template再把转换后的字符串传给LLM接口。另一个问题是量化。本地部署经常用AWQ或GPTQ量化到4位以节省显存。量化的代价是输出质量和API有差距尤其temperature设低时可能会出现重复token。我的做法是把提示词里的“防止重复”写得更明确比如要求“每个要点不要重复表达两遍”并适当提高temperature到0.4让生成有更多选择。6. 验证提示词把单次成功变成可回归的测试集假设你已经跑通了一条“公众号生成”的提示词接下来最该做的不是继续调文采而是建一个测试集。我的做法很朴素准备10个输入样例覆盖“事实型”“建议型”“吐槽型”三类每样固定验收标准。每次改提示词或参数先跑一遍测试集看有没有变差。比如事实型用例“DeepSeek的API支持哪些参数” 验收标准关键词必须包含temperature、top_p、max_tokens。如果新提示词过滤掉了参数列表那就是回归。建议型用例“推荐一个500元以内的咖啡机” 验收标准不能出现“买贵的就行”这类空话。这个测试集可以是一个JSON文件你自己维护。不要追求自动评分人工看5分钟就够了。重点是用它拦住“改好一个例子改坏一片”的情况。我在这方面吃过亏有次为了消去AI味在提示词里加了“少用首先然后”结果所有输出都变成了短句碎片整体可读性反而下降。如果早跑一遍测试集立刻就发现了。把提示词当代码管给版本号不要覆盖保存。我现在的习惯是prompt_v12_fact_check.txt。虽然土但真能救命。希望帮到你。本文还有配套的精品资源点击获取