企业官网建设流程全解析

简介：一份由厦门大学软件与人工智能专家程希冀主讲的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。它们的默认值在不同版本里略有差别，但调参思路是通用的。

实际项目中，我习惯固定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] 退款政策？ A：7天无理由退货，退回运费由买家承担。 回答规则： 1. 如果用户问题在FAQ中找不到对应条目，回复“这个我不太确定，已转人工”，不要猜测。 2. 不要扩展FAQ之外的功能介绍。 3. 如果用户问的是实时价格，告知“价格以官网为准”。

这个片段的设计逻辑：先把FAQ结构化贴进去，相当于限定来源；回答规则里第1条就是显式拒答；第3条处理知识截止导致的实时性问题。如果你把这段提示词设temperature=0.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": f"Bearer {API_KEY}", "Content-Type": "application/json" }, json=payload) 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负责每次动态任务。参数里temperature=0.3，是为了让推文风格稳定；max_tokens=2000，保证600字正文不会被截断。top_p=0.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_code=True, dtype="half", ) prompt = ( "你是一位严谨的客服助手，回答时只能依据FAQ。若不确定，直接说无法确认。\n" "用户问题：退款多久能到账？\n" "客服回答：" ) params = SamplingParams( temperature=0.2, top_p=0.9, max_tokens=1024, ) 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。虽然土，但真能救命。希望帮到你。

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