企业官网建设流程全解析

简介：一份50页演示文稿系统讲解DeepSeek提示词设计与幻觉避免方法，并延伸介绍Manus智能体，适配职场文档、广告策划、校园备课、日常规划等多种应用场景，适合希望提升提问效率的各类用户。资源为单个pptx演示文稿，压缩包仅约1.05MB，容量不大但内容密度高；从提示词是否仍然重要切入，对比不同推理与非推理模型之间的性格差异，梳理各自适用的提问策略与任务类型。讲解以大量贴近实际案例展开，覆盖工作汇报、设计绘图、作业辅导、旅行规划等，借助角色设定、背景信息补充、六何分析法、少量示例提示、结构化指示等技巧，手把手教读者设计高质量提示词。针对模型幻觉问题，专门总结产生原因与规避手段，强调提供清晰上下文、使用分隔符明确指令结构、避免重复要求逐步思考等无效指示，帮助读者获得更可靠的回答。已有138人学习下载，适合从零开始到需要进阶使用提示词的学习者。

1. 从“50页PPT”这个体量说起：DeepSeek提示词设计到底在解决什么

一份名叫《50页PPT DeepSeek提示词设计幻觉避免与应用》的材料，放在任何一个刚把DeepSeek接进业务的团队里，都是那种“早该有人整理出来”的东西。原因很简单：DeepSeek对话和代码能力都很强，第一次上手很容易误以为“随便问就能问好”，等把回答塞进知识库、报表、客服工单时，才发现模型幻觉直接决定这套系统能不能上线。提示词设计解决“模型有没有听懂”，幻觉避免解决“模型有没有瞎说”，应用解决“这套东西能不能稳定跑起来”。这篇笔记写给三类人：正在做DeepSeek API接入的开发者、用DeepSeek做知识库问答的运营，以及想在本地部署或工具链里复用提示词模板的工程师。后面每一章都按“能照做”的标准写，不绕圈子。

2. 提示词设计先立住：DeepSeek的指令遵循和ChatGPT不是一回事

2.1 为什么说DeepSeek需要“显式边界”，而不是“自由对话”

很多人第一次用DeepSeek，会把以前在ChatGPT上养成的习惯直接搬过来：先来一句“你是一位资深领域专家”，再把问题抛出去。这个做法不能说错，但对DeepSeek来说，效率很低。DeepSeek的训练目标里，指令遵循占了很大的权重，模型更擅长“直接理解任务”，而不是靠角色词进入状态。堆砌“专家”“大师”这类词，反而会稀释真正的任务指令，让模型把注意力放在身份扮演上，输出变得冗长，还更容易在你没给边界的地方自由发挥。

另一个关键差异是DeepSeek的两种模型形态。通过API调用时，deepseek-chat对应通用对话模型，适合指令式任务；deepseek-reasoner对应推理模型，会先产生一段长思维链再给结论。这两种形态对提示词的敏感程度完全不同：chat模型吃“角色+步骤+示例”这套传统配方，reasoner模型则更吃“问题定义+约束条件”，因为它的思维链会自己补推理过程，再去堆角色只会限制它。实际项目里，我的做法是：chat模型跑知识库问答、文案生成、内容分类；reasoner模型跑复杂推理、代码审查、答案校验。

这也引出一个核心结论：给DeepSeek设计提示词，第一原则是“把边界画出来”。你告诉它什么是不能做的，比告诉它应该做什么更有效。原因在于生成模型解码时，Token的概率分布天然倾向“顺着往下写”，如果没有显式边界，它会把最可能的路径当成事实写完整，这就成了幻觉的第一入口。

2.2 一套能直接抄的提示词骨架：角色、任务、约束、输出格式

我自己的项目里，提示词不写成一大段自然语言，而是拆成结构化的四个块。这不是花架子，是为了能版本化管理，也方便后面做自动化评测。四个块分别是对模型身份的限定、具体任务描述、不可逾越的约束、输出格式定义。

常见做法是把它落成一个JSON结构，读进来再拼成最终的system消息：

prompt = { "role_identity": "你是一个严谨的技术文档撰写助手，只基于用户提供的资料输出内容。", "task": "根据下面的对话历史，整理出一份操作手册，步骤要可执行。", "constraints": [ "禁止使用对话历史之外的信息。", "如果资料中缺少某个步骤，明确写\"未提供\"，不要推测。", "不要使用\"大概\"\"可能\"\"一般来说\"等模糊表达。", "所有数字、参数必须与资料原文一致。" ], "output_format": { "标题": "一级标题格式", "步骤": "数字编号列表，每步一句话", "参数": "表格格式，三列：参数名、取值、说明" } } system_message = "\n".join([ prompt["role_identity"], "任务：" + prompt["task"], "约束：" + "\n".join(f"{i+1}. {c}" for i, c in enumerate(prompt["constraints"])), "输出格式要求：" + str(prompt["output_format"]) ])

逻辑说明：这里把“身份、任务、约束、格式”分开，是为了让模型在解码时每一层都能被约束框住。身份控制语气，任务控制方向，约束控制事实来源，格式控制落地形态。四个块如果揉在一起，模型很容易只记住最后两句，前面的边界被当成背景噪声。

参数说明：constraints列表是最值得花时间的地方。写约束时尽量用“禁止式+兜底式”，比如“禁止使用资料之外的信息”是禁止式，“如果缺失，写未提供”是兜底式。两条配合，才能让模型在不确定时有明确的出口，而不是硬编——这就是幻觉防御的提示词基础。

2.3 与提示词配合的三个请求参数：temperature、top_p、max_tokens

提示词不是唯一变量。同样一段提示词，temperature从0调到1，结果可能从“保守复述”变成“自由发挥”。我在DeepSeek API调用里，三个参数基本是固定的套路：

参数说明：temperature控制采样随机性，值越大Token分布越平，越容易跳出常规路径。事实类任务必须有低随机性，这是硬性的血泪经验。top_p是核采样，只从累计概率达到阈值的Token里采样，它和temperature同时调会产生不可预期叠加，我一般只动temperature。max_tokens要重点说：如果输出长度限制不够，生成过程被强行截断，有些模型会尝试“把没说完的话结束掉”，此时编造风险极高。宁可给足长度，再用后处理截断，也不要让模型自己收尾。

还有一个容易被忽略的点：DeepSeek API支持在messages里使用system角色，但system与user之间的边界没有ChatGPT那么强。如果你发现system里的约束没生效，把它们重复写进user消息的末尾，效果好很多。这个现象在DeepSeek上比较常见，后面避坑章节还会展开。

3. 幻觉避免：把模型的“脑补”关进约束的笼子里

3.1 幻觉是从哪里来的

模型幻觉不是“坏掉了”，而是解码机制在特定条件下必然出现的表现。我把DeepSeek产生幻觉的路径拆成四条。第一条是训练数据里的“常见路径补全”：模型见过大量“问题-答案”对，遇到相似问题时会直接激活记忆中最高频的答案模板，而不是从现场信息里推理。第二条是解码随机性：temperature设高后，模型的Token选择开始发散，发散路径里容易混入训练数据碎片，拼出来像模像样的段落。第三条是上下文冲突：多轮对话里用户自己给了错误信息，模型会把用户的话当成事实前提，顺着错误前提往下推。第四条是生成长度压力，响应太长时注意力衰减，尾部内容开始“糊”。

理解了来源，防御才有针对性。提示词不是万能药，但它能把前两条路堵住大半，后面两条要靠流程约束。实际项目中，把幻觉率从20%压到5%以下，靠的往往不是单个提示词写得多完美，而是“提示词边限 + 低temperature + 输出自检”三层叠加。

3.2 提示词级别的三条防御：限定范围、强制引用、允许说不知道

第一条防御是“范围限定”：在提示词里明确告诉模型，你的知识边界就是当前上下文。写法模板如下。

你只能根据下面提供的[文档片段]回答问题。 [文档片段]中不存在的细节，一律不要提及。 如果问题涉及[文档片段]之外的内容，请直接回答：该信息不在给定文档中。

这条防御的原理是给解码过程一个“非此不可”的候选集。模型在每一步生成Token时，如果看到“只能根据文档片段”，它会优先从条件概率上选择与文档词汇相关的路径，而不是从全局语言模型记忆中抽取。实际效果上，对“文档里有没有这个数据”这类判断，能减少大半编造。

第二条防御是“强制引用”：要求模型在给出事实性内容时标注来源编号。这在知识库问答里是最有效的做法，因为它迫使模型把输出与输入建立显式指针关系。模板示例：

回答中涉及文档中的具体数据、定义、结论时，在句末用[序号]标注，序号对应文档片段编号。 如果没有对应片段，标注[无来源]。

加了这条，模型输出就能做程序化验证：凡是标了[无来源]的句子，直接降权或拦截；凡是没标注的数字，说明模型没把来源当回事，人们重新审一遍也容易很多。

第三条防御是“允许说不知道”。有趣的是，很多模型在提示词没有明确允许的情况下，倾向于“猜测到底”。原因在于训练数据里的问答对很少出现“不知道”这种终止式回答，模型学到的模式是“有问必有答”。要让DeepSeek接受“我不知道”是一个合理出口，需要在约束里显式写出，而且给它一个标准化的输出文本，比如：

当你不确定、或信息不在给定上下文中时，请直接输出“无法确定”四个字，不要解释，不要猜测。

这条我在实际项目中加过之后，无根据猜测明显减少。注意一个细节：是“直接输出‘无法确定’四个字”，不是“输出：无法确定”，也不是“回答说不知道”。指令越机械，模型执行越稳定，这是DeepSeek指令遵循的一个特性——它对“精确输出”的遵守比对“意图理解”的遵守要好得多。

3.3 输出自检：让模型给答案做“事实体检”

提示词防的是生成阶段，自检验证防的是输出阶段。我常用两轮法：第一轮让模型给出正式答案，第二轮把它的答案再交给模型进行“事实核对”。核对时用一个独立的提示词，不要让模型“回头看自己的答案”，而是让它像阅卷老师一样打分。

verify_prompt = """请对下面这段回答进行事实性审查。 审查规则： 1. 逐句判断，回答中的每个事实性陈述是否能在给定文档中找到依据。 2. 判断标准：有依据的标记[有据]，无依据的标记[猜测]，与文档矛盾的标记[矛盾]。 3. 输出格式：每行一条，格式为：序号 | 原句摘录 | 判定 | 理由。 待审查回答： {answer} 给定文档： {reference} """

逻辑说明：这个自检提示词利用了reasoner模型的推理能力，视角从“写答案”切换成“审答案”，相当于让模型的解码路径换了一条。对于DeepSeek，deepseek-reasoner在这个场景下表现比chat模型好，因为它的思维链会先内部检索证据再判定，不会轻易放过矛盾点。如果你用同一段上下文跑两轮chat模型，模型对“自己的答案”往往过度自信，这是模型没有真正“审查”能力，只是“补全”了另一个答案。

参数说明：自检任务的temperature设0，让判定尽可能确定。reference字段要放与第一轮完全一致的上下文，不要做摘要，摘要会引入新的信息损失。实际跑下来，两轮法能把知识库问答的最终幻觉率再压一个量级。代价是响应时间翻倍、Token消耗翻倍，所以自检只用在正式输出、而不是每一轮对话。

4. 从提示词到应用：模板化、API接入与幻觉率评测

4.1 把提示词模板化：变量、版本、回退

提示词一旦投入使用，就不再是“写得好不好的问题”，而是“能不能管理起来的问题”。我见过太多团队把提示词写在聊天记录里，什么时候改过、为什么改、影响是什么，完全没有记录。结果就是模型偶尔抽风，没人知道是哪次改提示词引起的。

我的做法是把提示词当成代码来管理。核心是一个模板文件和一个渲染脚本。模板可以是一条消息，也可以是一组消息序列。示例如下：

templates = { "qa_with_source": { "version": "1.3.0", "system": "你是一个严格的问答助手，只依据给定上下文回答。", "user": """上下文： {context} 问题：{question} 要求： 1. 严格依据上下文回答，禁止引入外部知识。 2. 涉及具体数据时，句末标注来源片段编号。 3. 上下文没有答案时，输出“无法确定”。 4. 回答控制在{max_words}字以内。""", "fallback": "qa_basic", "params": ["context", "question", "max_words"] } }

逻辑说明：这个结构里，version字段对应版本管理，fallback字段对应降级方案。当新模板在评测集上效果变差时，自动回退到旧版本。params字段声明了这个模板需要哪些外部变量，渲染前校验缺不漏。把它变成代码的好处是，每次改动都可以走Git提交，和后台发布系统联动。API层出问题时，排查路径从“玄学找模型问题”变成“先查模板版本”。

4.2 DeepSeek API接入的最小可运行代码

提示词设计最终要落到程序里。DeepSeek的API兼容OpenAI的消息格式，HTTP请求最小示例如下：

import requests import time def call_deepseek(prompt, temperature=0.3, max_tokens=512, retries=3): url = "https://api.deepseek.com/chat/completions" headers = { "Authorization": "Bearer sk-你的APIKey", "Content-Type": "application/json" } payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": prompt["system"]}, {"role": "user", "content": prompt["user"]} ], "temperature": temperature, "max_tokens": max_tokens, "stream": False } for attempt in range(retries): try: resp = requests.post(url, headers=headers, json=payload, timeout=60) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except Exception as e: if attempt == retries - 1: raise time.sleep(2 ** attempt) # 指数退避重试

逻辑说明：请求体里只传了model、messages、temperature、max_tokens四个核心字段，messages里前两条分别是system和user，正好对应第2章搭建的提示词骨架。返回体里取choices[0]["message"]["content"]，这就是模型生成文本。stream设为False，简单场景不流式输出，省去解析event的复杂度；需要打字机效果时再改成True。

参数说明：retries=3加上指数退避，处理的是突发限流和服务端瞬时错误。timeout=60要重视，reasoner模型在长思维链场景下响应可能超过30秒，设短了会误报超时。如果你调用的是deepseek-reasoner，返回里会比chat多一个reasoning_content字段，是思维链原文，生产环境不要直接暴露给用户，一方面Token消耗大，另一方面思维链里可能有未经整理的信息。

4.3 用评测集量化幻觉率：给提示词做回归测试

提示词改得好不好，不能靠感觉，要跑评测集。我维护一个固定的测试集，大约50到100条，每一条都是一个“上下文+问题+标准答案”三元组。评测逻辑很简单：模型输出后，人工或规则脚本判断它是否与标准答案冲突、是否包含上下文中不存在的事实。把“包含无来源事实”的定义搞严谨，幻觉率就变成一个可追踪的数字。

evaluation = [ {"context": "客户A的合同金额为120万，付款周期为30天。", "question": "客户A的付款周期是多长？", "expected": "30天", "strict": True}, {"context": "服务器B的CPU规格为32核。", "question": "服务器B的磁盘容量是多少？", "expected": "无法确定", "strict": True} ] def is_hallucination(answer, expected, strict): if strict: # 严格模式：答案必须与标准答案一致，或与上下文无冲突 return expected not in answer # 宽松模式：只要答案没有与expected冲突，就算通过 return False

逻辑说明：严格模式适合知识库问答，模型一旦答错就算幻觉。宽松模式适合文案生成，只要没编造关键数字就算合格。每次改提示词，跑一遍整个集合，记录幻觉率和通过率。你会发现很多“感觉变聪明了”的改动，在评测集上其实是幻觉率上升。

参数说明：strict标记很关键，它定义了“什么是错误”。我做评测时会把三类错误分开统计：答案缺失、答案错误、答案自创。自创是最危险的幻觉形式，它会给出一个看似完整但实际上无依据的数值或结论。评测集本身也要定期扩充，把线上用户真实问过的高频问题加进去，否则你测的是“提示词在理想情况下的表现”，而不是“在生产环境的表现”。

5. DeepSeek提示词设计与幻觉的避坑排查：现象、原因、解决

5.1 同样提示词，今天答对明天答错

现象：提示词一字未改，第一天测试结果正常，第二天同一个问题输出变了，甚至开始编数据。多数团队第一反应是“模型被切走了”，但实际原因往往有两个。

原因：第一是temperature没有设为0，只要采样存在随机性，同样的输入就有不同输出；第二是DeepSeek服务端模型版本会更新，官方不会提前通知，而这恰好很难察觉。

解决：关键路径强制temperature=0，降低随机性方差。同时给每次请求记录模型返回的model字段和当时的时间，建立自己的“输出行为日志”。如果两次返回里model字段不一致，说明服务端路由变了，需要重新回归测试。这是个没办法完全控制的变量，收集数据至少能让你快速定位问题。

5.2 一本正经地编造不存在的参数和案例

现象：问答场景中，模型给出一个看起来特别具体的答案：“根据统计，国内XX行业市场规模约为472亿元。”但给定的上下文里根本没有这组数据。

原因：这是“常见路径补全”。训练数据里关于这类问题的回答经常出现“市场规模”模板，模型看到问题关键词“行业+市场”，直接激活了模板，数字是Template里最常见的那一个，而不是真实信息。

解决：把约束从“请准确回答”改成“你只能使用以下文本中的事实，文本中不存在的数字、名称、结论均属编造”。更彻底的做法是在提示词里加一条：“如果回答中需要数字，必须在数字后立即标注来源片段编号；无法标注时，将数字替换为‘未提供’。”这一条能比较大程度堵住模板补全，因为模型被强制建立数字到来源之间的指针，建立不了指针它就会选择放弃而不是硬编。

5.3 长任务做到一半开始丢步骤

现象：给reasoner模型一个完整的分析任务，包含5个步骤，它前3步输出规范，后面2步开始含糊，甚至跳过了其中一个步骤。

原因：这与上下文长度有关。当输入很长或思维链很长时，注意力靠后的部分信息衰减，模型对早期指令的遵守度降低。DeepSeek的上下文窗口虽然足够大，但“窗口够大”和“全部内容都被有效关注”是两回事。

解决：把长任务拆成多个短调用，每个调用只负责一个步骤，上一步的输出作为下一步的输入。比如先让模型整理要点，再基于要点生成详细内容，而不是让它一口气完成。每小步的max_tokens不要设太大，保证输出在模型注意力健康区间内完成。拆分后的代价是响应时间变长，但这比丢步骤重跑整个任务划算得多。

5.4 多轮对话里模型被“带偏”

现象：对话前几轮用户纠正了模型一次，后面的回答模型开始附和用户的错误说法，甚至把用户的错误当成事实依据继续推理。

原因：多轮对话中，用户消息和系统消息在模型眼里都是“上下文事实”，模型没有能力区分“用户陈述的事实”和“用户给出的纠正指令”。用户说“应该是这样”，模型就把它当成新的历史事实吸收了。

解决：在system提示词中显式加一条分级规则：“用户消息中的主观判断、猜测、纠正性表达，不作为回答的事实依据；回答必须以系统提示词和初始问题限定条件为准。”如果业务场景对准确性要求高，就采用单轮模式：每轮请求只传初始上下文和当前问题，不传历史对话。这会让体验损失一些，但准确率提升非常明显，知识库问答一般选单轮。

6. 把提示词沉淀成你自己的“50页PPT”：验证方法与进阶玩法

一个方向值不值得长期投入，要看它能不能沉淀。我会把项目中形成的提示词骨架、幻觉防御规则、评测集、失败案例整理成一个团队内的知识库，形式上有点像标题里那本“50页PPT”——不是做一套花哨的幻灯片，而是把这些经验结构化，让新成员一天就能接手。

验证方法上，我给自己定了一条硬规定：任何提示词改动必须先在评测集上跑出对比数据，幻觉率下降才能上线，否则保持旧版本。这项工作初看费时间，但效果是可以测试的：A/B跑两周后，线上知识库的“答非所问”标注量明显下降。

进阶玩法分两支。一支是工具调用：DeepSeek API支持function calling，可以把提示词里的“检索”“计算”“查库”动作交给外部工具，模型只负责生成查询参数和解读结果。这一改动相当于把幻觉的高发区——记忆——整个外包出去。另一支是多智能体编排：社区里常见的做法是利用harness这类编排工具把提示词拆成多个智能体，各自负责生成、校验、总结，配合Playwright等工具还能做端到端操作验证。单个智能体的幻觉率虽不完美，但用“生成智能体”和“校验智能体”两套提示词相互制衡后，整体就能控制住。

我的个人习惯是：每次线上出一次幻觉事故，就往评测集里加一条类似用例，然后重新跑全量回归。能让幻觉用例从评测集里真正消失的改法，才是有效改法，而不是靠调一版提示词后手动验证两个例子就上线。这个过程没有捷径，但每一步都走得踏实。希望帮到你。

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