企业官网建设流程全解析

简介：这份PPT围绕DeepSeek提示词设计、幻觉避免与实战应用展开，共50页，面向希望通过DeepSeek提升工作、学习与创作效率的读者，核心回答“AI越来越聪明，提示词是否还重要”。PPT先对比DeepSeek-R1与V3模型的不同“性格”，理清推理型与非推理型模型各自的提问策略；随后给出六何分析法、Few-shot少量样本提示、结构化提示词等可直接套用的实用技巧，并结合让DeepSeek生成炫酷图表与动画、手机故障排查等场景，说明如何减少幻觉、提升输出质量。资源还延伸介绍了近期爆火的Manus智能体，帮助读者理解从对话回答到自主执行的新趋势。资源包共1个pptx文件，大小约1.05MB，轻量精简，便于快速浏览或二次编辑；目前已有76人学习下载。适合希望系统提升DeepSeek提问水平、规避错误输出的入门及进阶学习者。

1. 从“一本正经胡说八道”说起：DeepSeek提示词设计到底要解决什么

用 DeepSeek 做知识问答的人，大概率都遇过这种场景：你问一个具体数字或引用，它回答得流畅笃定，但你一核对原文，发现出处不存在，数字也是推算出来的。这种“一本正经的胡说八道”就是幻觉。提示词设计这件事，表面上是在调整措辞，实际是在给模型的输出画边界——告诉它哪些话能说、哪些话不能说、拿什么作为说的依据。像《DeepSeek提示词设计幻觉避免与应用》这类50页PPT，讲的就是把“边界意识”翻译成一套可复用的提示词套路。

这篇笔记我从幻觉的成因开始拆，给出一套最少够用的反幻觉提示词模板，再讲在 DeepSeek API 调用、上下文约束和验证环节怎么落地。适合正在做提示词优化、AI应用交付，或者被模型“嘴硬”坑过的人。你不需要懂训练细节，但需要带着自己手头的实际用例来对照。

2. 先看清问题：DeepSeek的幻觉从哪来，提示词为什么会背锅

2.1 三类常见幻觉：事实编造、逻辑跳跃、出处错配

先给幻觉分个类，因为后续所有提示词设计手段，本质上都是针对某一种幻觉做抑制。我通常把 DeepSeek 在对话里暴露的幻觉分成三类。

第一类是事实性幻觉。模型在训练数据里见过相似问题，却没有记住准确答案，于是按概率“补全”了一段听起来合理的内容。典型表现是：编造不存在的论文标题、虚构某公司的高管名字、给一个未公开的产品参数一个“较新版本”。这类幻觉最危险，因为它的表达通常非常流畅，而且会主动给出具体数字，让没有核验习惯的人直接采信。

第二类是逻辑性幻觉。模型在需要多步推理的任务里，跳过关键步骤或者把前提条件偷换了。比如让它分析“A比B高，B比C高，谁最高”，它可能直接答C最高，因为它把“B比C高”理解成“C高于B”。在业务数据分析场景里，这类幻觉表现为“原因分析过度自信”：把相关性当因果、把单一事件当成趋势。提示词如果只给出问题不给出推导路径，模型更容易偷步。

第三类是出处错配。模型确实用到了你给的上下文材料，但张冠李戴，把材料中“客户对退款流程的意见”当成“客户对产品功能的赞扬”。严格说这不是编造，而是信息定位失败。它通常发生在上下文材料很长、或同类信息多次出现时。提示词里如果没有“引用并核对出处”的要求，模型只会挑它认为重要的内容，而不会去确认对应关系。

这三类幻觉用一张表可以看得更清楚。

为什么要先分类？因为“避免幻觉”这个目标太大，不分类就只能在提示词里写“请准确回答”，这种空洞的要求模型根本无从执行。分类之后，你就能对症下药：事实性幻觉靠“限定依据”和“未知说不知”控制，逻辑性幻觉靠“分步推理”打断，出处错配靠“强制引用”约束。后面两章给的模板，就是把这三类药放在一个提示词框架里。

2.2 提示词是放大还是抑制幻觉，取决于这4个机制

不管是 DeepSeek 还是其他大模型，提示词对幻觉的影响都绕不开四个机制。理解这些机制之后，你就不会再把提示词设计当成“写作文”，而是当成“设参数”。

第一个机制是上下文锚定。模型会极力让输出和已有上下文保持一致。如果提示词里已经写了一句“根据行业惯例，这类问题的答案通常是……”，模型就会顺着这句话向下圆，哪怕后面的推理链条是空的。反过来，如果提示词明确写出“材料中没有的信息不要输出”，这就等于在上下文里给了一个强锚点，模型更容易执行“不回答”这个动作。所以提示词里出现的每一个“事实性断言”都会被模型当作依据来对齐，写的时候要特别小心，别把你自己的猜测写进去。

第二个机制是角色激发。模型被赋予“资深专家”“多年从业者”这类角色时，回答会更流畅、更肯定，但也更容易编造细节。原因不难理解：扮演专家本身意味着“我知道答案”，所以遇到知识空白时，模型会倾向用概化陈述补上，而不是承认不知道。实际使用时，我会把角色设定成“分析员”而不是“专家”，并且给一个具体的任务姿态，例如“你负责审核材料并指出证据缺口”。这既保留了专业性，又降低“表演型胡说”的概率。

第三个机制是示例传染。如果你在提示词里给了示例，模型会默认示例的格式和内容风格都是标准答案。示例里如果存在隐性错误，模型会刻意模仿。有些团队为了统一样式，在 few-shot 示例里写“正确的答案：无法判断”，结果后续回答反而频繁出现“无法判断”而牺牲了有用性。示例设计要保证每一条都是你想让模型重复的理想输出，尤其是反例，要么不给，要么给得极其明确。

第四个机制是解码参数。温度（temperature）和 top_p 直接控制随机性。温度越高，模型越倾向探索概率尾部，幻觉和发散会增多；温度越低，输出越保守，但也可能陷入同一措辞的重复。事实问答类任务我一般把 temperature 调在 0.1~0.3 之间；开放式写作则放到 0.7~1.0。很多人在提示词里反复强调“不要胡说”，却没有调低 temperature，结果模型在概率上仍然有大量编造空间，这就是提示词替解码参数背锅的典型情况。

这四个机制叠加起来，就解释了为什么“同样一句话，换个人设，效果截然不同”。提示词设计不是咒语，而是在理解这四个机制的前提下，把约束提前写进模型的决策上下文。这里给出一个简单的判别方法：任何提示词，如果它不包含“材料不足时怎么办”的兜底回答，那么它一定存在幻觉窗口。你可以在自己的测试用例里故意问一个材料中没有答案的问题，看模型是不是硬答。如果硬答，说明提示词的边界还没有立住，需要回到前面的三类幻觉逐一排查。

还有一个容易被忽视的点：上下文长度。DeepSeek 的上下文窗口很大，但模型对中间位置的注意力相对弱，开头和末尾最容易影响输出。如果你在 50k 字符材料的中段埋了一条“不要引用XX”的约束，模型未必能执行。我的习惯是把最重要的约束放在 system prompt 或 user prompt 的开头，并把材料放在中间，回答要求放在末尾。这也算提示词设计的一部分，但常常被忽略。另外，有时候幻觉不是模型产生的，是用户提问预置的。比如“以下哪个选项正确”本身就是诱导。这种诱导性提问会让模型默认选项里有一个是对的，哪怕全是错的。提示词设计时要把问题本身改成开放性的，例如“这些选项中有没有正确描述，如果有，是哪个；如果没有，请指出错误”。这些细节在下一章的模板里会进一步成型。

3. 把提示词做成“施工图纸”：一套最少够用的反幻觉提示词模板

3.1 结构化提示词的7个组成部分

依赖“请准确回答”这种话，不如把提示词拆成七个固定槽位。我一般这样组织：

1. 角色与任务。一句话说清模型是什么角色、在做什么事。
2. 输入材料。给模型可以依据的内容，用显式分隔符包起来。
3. 推理要求。需要几步、每一步做什么，例如“先判断材料是否充分”。
4. 禁止行为。用正面替代句说明不能做什么，例如“不要猜测，应回答‘信息不足’”。
5. 输出格式。规定结构，比如“用编号列表，每条附出处”。
6. 示例。可选，给一个理想回答样例。
7. 边界声明。说明如果材料不足该怎样反馈。

其中第4条是最容易写错的。很多人写“不要编造”，模型收到的是抽象禁令，不知道拿什么替代。正确写法是给替代行为：“如果材料中找不到答案，请直接回答‘信息不足，无法判断’”。这等于给了模型一条安全的逃脱出口，它就不需要为了完成对话而硬编。

第5条也很关键。输出格式约束得越细，模型“即兴发挥”的空间越小。比如要求“答案末尾附上支持原文的摘录”，模型就必须回到材料里面找证据，这会显著拉低出处错配的发生率。反过来，只要格式是“自由段落”，模型的生成自由度就大，幻觉的藏身之处也多。

这7个槽位不是每回都用，但你写提示词时可以逐个过一遍，缺什么补什么。尤其是“边界声明”，在事实问答类任务里几乎是必填项。

3.2 用Python+DeepSeek API跑通最小示例：模板与参数说明

下面这段代码是本地跑通 DeepSeek API 的最小示例，采用 OpenAI SDK 兼容格式。它把上一节的结构化思路直接变成了可执行的 system prompt 和 user prompt。

from openai import OpenAI client = OpenAI( api_key="sk-你的Key", # 从 DeepSeek 开放平台获取 base_url="https://api.deepseek.com" ) system_prompt = ( "你是一个严谨的材料分析助手。\n" "你的任务：只依据用户提供的【材料】回答问题。\n" "规则：\n" "1. 如果【材料】中没有足够信息，必须回答：信息不足，无法判断。\n" "2. 禁止使用训练数据中的知识补全答案。\n" "3. 用编号列表输出，每条结论后标注材料出处。\n" "4. 不要重复材料中的无关内容。" ) user_prompt = """【材料】 2024Q3客服工单共2140条，其中支付相关482条，占22.5%；退款流程相关655条，占30.6%。 工单平均首次响应时长48分钟，其中退款类工单首次响应时长79分钟。 【问题】 退款流程是否是客户投诉的主要集中点？""" response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], temperature=0.2, top_p=0.8, max_tokens=400 ) print(response.choices[0].message.content)

逻辑说明：这里没有在 user_prompt 里写“请准确回答”，而是用几条显式规则定义边界。注意规则2，它告诉模型不要把“训练数据里相似行业的经验”混进来，这在数据问答场景很有用。规则3强制模型回到【材料】里找对应关系，对出处错配是直接抑制。规则1则给了模型“投降”的合法通道，避免它为了完成感而硬编。

参数说明：temperature=0.2 是事实任务保守值，太低（小于0.1）会让模型输出呆板且容易复读，0.2~0.4 是一个平衡区间。top_p=0.8 进一步缩小采样集，能让语句更集中；如果你想保留一点口语化，top_p 可以放宽到 0.9。max_tokens=400 防止回答过长，如果任务需要长分析可以加到 800，但不能无限大，生成长度越大，后半段越容易出现逻辑漂移。另外，不要把 Key 提交到 Git，建议用环境变量读取。

有一点需要提醒：DeepSeek 的对话模型会继承同一会话里的历史消息。如果你发现第二次追问时模型开始“借鉴”上一次的错误信息，最常见原因是历史被带入了。要么每次请求只发送必要的 system 和 user 消息，要么在 user_prompt 开头写明“忽略与本次问题无关的历史信息”。这也是提示词设计的一部分。

3.3 把模板移植到代码生成和文案改写

不是所有任务都需要【材料】。写代码时，任务边界变成了“只使用标准库”或“不引入未验证的API”；写文案时，边界变成了“不要虚构案例和数据”。所以上面7个槽位要按任务裁剪。

code_prompt = """生成一段Python函数完成以下需求。 约束： - 只使用Python标准库。 - 如果某个API你不确定是否存在，在注释里标明需要验证，不要直接使用。 - 函数必须有类型注解。 - 不要额外实现需求之外的逻辑。"""

这里“不确定就标注”就是把“信息不足”通道移植到代码场景。模型宁可把不确定的接口标注出来，也不能假装会写。

rewrite_prompt = """改写下列文本，语气从正式改为口语化。 规则： - 不允许新增原文没有的数据、案例和引用。 - 改写后保留原意。 - 如果原文包含具体数字，必须保留并核对。"""

“不新增案例”其实就是防事实幻觉。常见做法是把改写任务当作“信息无损转换”来做，而不是让模型自由创作。这一点在内容生产场景里特别重要，因为文案一旦被润色得流畅，错误信息也就被包装得更难识别。

4. 把幻觉按死在边界内：上下文约束、检索注入与自洽性检查

4.1 上下文约束：让模型只基于给定材料作答

上下文约束的核心是“隔离”。当材料被显式标记【材料】...【材料结束】，模型更容易区分哪部分是事实依据、哪部分是问题陈述。反过来，如果你先把材料用大段文字贴在 user prompt 里，再跟一句“帮我分析一下”，没有任何分隔，模型需要在混在一起的文字里自行划分边界，出错概率直线上升。

除了分隔符，还有一个有效做法：要求模型在回答前先复述材料中的关键事实。例如在 system prompt 里写“第一步：用三句话概括材料中的关键数据；第二步：再回答问题”。这个“先转述再回答”的过程会逼着模型把注意力放到材料上，而不是从内部记忆中找相似答案。代价是多消耗一些 token，但对高风险任务值得。

另外，上下文长度要控制。DeepSeek 支持很长的输入，但并非每个位置都被同等关注。我一般会把材料按最长 2000~3000 字截取，或做成“摘要+原文片段”组合发送。如果材料太长，可以用检索先把最相关的段落捞出来，再塞进上下文。这就是下一节的检索注入。

4.2 检索注入与分步推理：减少事实幻觉的常见做法

先看检索注入。最简单的做法是先用关键词或向量召回 top-k 片段，然后把片段拼进 prompt。下面给一个关键步骤的 Python 示例，展示如何拼装：

def build_context(query, chunks, top_k=3): scored = [(len(set(chunk.split()) & set(query.split())), chunk) for chunk in chunks] scored.sort(key=lambda x: x[0], reverse=True) selected = [c for _, c in scored[:top_k]] return "\n---\n".join(f"[片段{i+1}]\n{c}" for i, c in enumerate(selected))

逻辑说明：这个简化版以词重叠计分，生产环境建议用向量检索。核心是把最相关片段显式编号，后续要求模型引用片段编号。在完整 system prompt 里，规则会变成“回答中引用到的信息，必须标注来源片段编号”。这等于把“出处错配”又压了一层。

再看分步推理。与其让模型直接给出结论，不如要求它走三步：一，列出回答这个问题需要哪些事实；二，逐条检查这些事实是否在上下文中出现；三，只基于已经确认的事实生成答案。这种做法的目的是打断逻辑性幻觉的跳步。在 API 调用时，可以直接把这些步骤写进 system prompt，让模型一次性输出草稿和最终答案。

分步推理不等于让模型“自言自语”，而是把它的推理过程结构化产出。如果你关心速度，可以在第一步之后先判断材料是否充分，材料不足就直接返回“信息不足”，不需要再做后两步。这就是一个简单的早退机制，能省一部分 token。

在落地时，有几个参数直接影响检索注入的效果。top_k 越大模型越容易淹没在无关片段中，我一般取 3~5，并结合重排序；片段长度控制在 300~600 字，太长的片段反而增加出处错配风险。当检索片段之间存在明显冲突时，提示词里要加一条“如果片段之间存在矛盾，请指出矛盾，不要自行调和”。这一条能避免模型强行把冲突信息揉成一条结论。这种做法的本质是把“材料不足”的判断权交给模型，同时用规则限制它和稀泥的倾向。

5. 避坑指南：DeepSeek提示词设计与幻觉避免的5个踩坑记录

5.1 只写“不要胡说”，模型照样胡说

现象：system prompt 写了“不要编造”，模型给出的回答依然是编造的，而且语气特别肯定。

原因：负面指令给了“不要做什么”，但没有给“做不到时做什么”。模型在对话惯性下，倾向于先回答再自我解释，而不是承认无法作答。它需要的不是禁令，而是一条退路。

解决：把“不要编造”替换为“如果没有依据，必须回答：信息不足，无法判断”，并且在示例里给出一条“信息不足”的标准回答格式。调用 API 时，temperature 降到 0.2 附近，进一步缩小编造空间。

5.2 角色设成“资深专家”，幻觉率反而升高

现象：让 DeepSeek 扮演“十年经验的金融分析师”后，它对不确定的指标也给出了准确数字。

原因：角色自带“我知道答案”的表演压力。模型把扮演角色理解为需要持续输出专业判断，遇到知识空白会用“大概率是”来圆场。

解决：将角色从“专家”改为“分析助手”，任务表述重点放在“陈述依据”而不是“给出判断”。如果确实需要专业形象，可以在角色后追加“所有结论必须引用材料，无引用内容视为分析假设”。

5.3 temperature 调到 0，结果不是更准而是复读

现象：为了压制幻觉，把 temperature 设成 0，模型几轮输出几乎完全一样，且会在无关处重复“根据材料可以得出”这类套话，有时候重复的内容本身就是错的。

原因：温度为 0 时采样变成贪心解码，模型总是走概率最高的路径，反而容易陷入重复模式。低概率的创新被完全禁止，但这并不能消除模型内部已经存在的错误知识。

解决：事实任务 temperature 用 0.2~0.3，保留一点点随机性；真正需要压制幻觉靠的是上下文约束，不是温度归零。如果发现重复严重，可以同时微微升高 top_p 到 0.85~0.9。

5.4 多轮对话把上一轮的错误带进这一轮

现象：用户先问“某某产品价格是多少”，模型答了一个不存在的数字；下一轮问“这个产品性价比如何”，模型直接以上一轮的错误价格为基础做分析。

原因：模型把整个对话历史都当作上下文，上一轮输出如果不够准确，就成了这一轮的“既定事实”。

解决：对需要高准确度的任务，不要做长多轮，直接每次带上知识库片段重新提问。如果必须多轮，可以在每次用户消息前加一条“注意：仅本次消息中的【材料】可作为事实依据，历史消息中的推测不可作为依据”。

5.5 让模型“联网查一下”并不能避免幻觉

现象：对 DeepSeek 说“联网核实一下”，得到的回答仍然与之前一致，有时还会煞有介事地给出一个网页来源，但该网页无法访问。

原因：提示词无法凭空启用联网能力，模型可能只是用“联网”作为修辞来包装自己的输出，并且编造出处来满足格式要求。

解决：在 API 层面不要依赖模型自我声称。要接入实时信息就使用官方支持的工具或知识库检索功能；没有工具时，明确限定“只允许根据已有材料回答”，并把“虚构来源”写进禁止清单。材料不足就返回信息不足，这一步没有捷径。

这5条里，前三条发生在提示词编写阶段，后两条出现在集成和部署阶段。实际经验是：最花时间的往往不是第一条，而是第五条——业务方总觉得接个 API 就能解决实时性问题，但模型能不能联网不是你一句话能决定的。建议把第五条当作需求梳理问题，而不是提示词问题。早期和业务方对齐这一点，能避免后面返工。

6. 最后一招：用“双通道验证”给提示词做体检

上面讲的都是怎么写提示词，但提示词是否真的把幻觉压住了，不能靠感觉。我习惯在每个提示词定稿前，构造一个包含 20 条问题的评估集：10 条是材料中能直接回答的，10 条是材料里没有答案的。然后用同样一套提示词跑两遍，第二遍把问题措辞换一下。最后统计三个指标：

• 幻觉率：在无答案问题上强行回答的比例。
• 准确率：在有答案问题上回答正确的比例。
• 自洽率：同一问题两遍回答的关键信息一致率。

低于 90% 的幻觉率，我一般不敢直接上生产。这不是一个绝对阈值，但很能说明问题。我见过不少提示词，单看几条案例效果很好，放入评估集后幻觉率高达 50%。原因通常是“边界声明”写得含糊，模型在材料不足时仍然硬答。如果把这类测试集固定下来，每次改提示词都回归一遍，能省下很多临时救火的时间。

我个人的习惯是：在测试集里故意放一两条“材料里有一半信息，但问题里包含一个材料没有的子问题”的题目，专门测试模型会不会自作主张补充。这类半覆盖问题最容易被忽略，也是幻觉的重灾区。这个双通道验证方法，本质上是用两次独立采样来暴露模型的随机性。前面说的分步推理、上下文约束，属于在生成前设限定；验证则是在上线前设闸门。两件事配合起来，才算是把幻觉避免从口号变成流程。现在我自己接任何 DeepSeek 相关需求，都会先问对方：你的评估集在哪里？如果没有，我会建议先建一个 20 条的小集子再调提示词，而不是拍脑袋改措辞。希望帮到你。

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