企业官网建设流程全解析

简介：这是一份由厦门大学软件和人工智能专家程希冀主讲的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调用，建议同时设置temperature=0.3、top_p=0.9左右。temperature控制的是采样随机性，0.3 既保留了少量表达多样性，又不至于让输出每次都不一样；如果做的是分类、抽取这类确定性任务，直接调到 0 或 0.1 都行。top_p我一般固定 0.9 不动，除非输出质量明显异常，才会去调整它。

2.3 温度、上下文长度与“幻觉的温床”之间的一次实测对比

提示词写得再好，采样参数不对也白搭。下面是我在不同任务上常用的参数对照，可以直接作为起点：

这里我要提醒一个特别容易翻车的地方：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适当放大一点，因为多字段输出比纯文本更占空间。我曾用同样的temperature=0.2跑了 50 个抽取任务，加“依据”字段的那组，人工抽检出的错误引用数量少了约六成。注意“依据”字段不要用“根据资料”这类空话开头，要逼模型引用原文里的具体短句，可验证性会高很多。

3.3 工程层治幻觉：RAG 检索、结构化输出与外部工具兜底

提示词里的约束属于“软约束”，它在大多数情况下有效，但绝不能依赖它兜底。真正让幻觉率大幅下降的，是把生成过程从“模型自己知道”改成“模型查到了再说”。这个过程被称为检索增强生成，缩写就是热词里常看到的 RAG。

常规做法是：先把你的资料库做切片和向量化，用户提问时先在库里检索出最相关的片段，再把片段和问题一起拼进提示词，让模型只基于这部分内容作答。这个流程把模型从“唯一信息源”变成了“信息加工者”。DeepSeek 本身不提供向量检索服务，但你可以用开源的向量库或云服务把这块做起来，整体链路并不复杂。

另一层更硬的约束是结构化输出。DeepSeek 开放平台支持使用 JSON Schema 断言输出格式，模型必须严格按照约定的结构返回。这对幻觉治理的价值在于，它堵死了“正确但不合规范”和“合规范但语义含糊”的输出路径。下面是一个简单的接入示例：

from openai import OpenAI client = OpenAI( api_key="你的API密钥", base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", temperature=0.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_url="https://api.deepseek.com" ) question = "DeepSeek的上下文窗口最大支持多少？" answers = [] for i in range(5): resp = client.chat.completions.create( model="deepseek-chat", temperature=0.9, messages=[ {"role": "user", "content": question} ] ) answers.append(resp.choices[0].message.content) for idx, ans in enumerate(answers): print(f"第{idx+1}次: {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_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-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 请求里设置temperature=0，连续请求同一问题，两次返回结果仍有差异。原因：temperature=0只是让采样概率分布“几乎确定”，但 GPU 的浮点计算本身有细微不确定性，尤其在长输出场景下误差会累积；另外部分接口还会隐含应用层采样。解决：不要指望通过temperature=0拿到完全确定性的输出。如果你需要“同一输入必须得到同一结果”的稳定性，最佳做法是设置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 再跑一遍。低温度下通过的高风险样本，高温度下往往就会露馅——出现前后矛盾、数值漂移和措辞含糊。这一步相当于压力测试，能提前暴露模型在边界情况下的真实水平。跑完压力测试，再把参数调回线上值做最终确认。

这套流程一开始看起来像给自己找活干，但用久了你会发现，它就是给提示词改动上的“后悔药”。我现在每次调提示词，第一件事不是看新写法多惊艳，而是先跑一遍回归集看有没有把旧场景弄丢。这个习惯帮我挡掉了至少十次线上翻车。同样的方法也适用于幻觉治理的验证——别等你把新方案写完了才发现它解决了一个问题、制造了三个新问题。也把这些整理进你自己的项目文档，替换里面的示例跑一遍，希望你也能少走一些我走过的弯路，这算是做这行非常珍贵的经验了。

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