简介面向希望在职场汇报、教学备课、自媒体创作中用好 DeepSeek 的读者这份 50 页 PPT 围绕提示词设计、幻觉避免与应用展开并兼谈 Manus 智能体的价值定位。内容先回应“AI 越来越聪明提示词是否还重要”的疑问再对比 DeepSeek-R1 与 V3 的推理型/非推理型性格差异说明两类模型适合的任务场景和提问策略同时结合 5W1H 信息补充、少样本示例、结构化提示词与“草稿纸”式思维链等方法可帮助读者减少事实幻觉、提升回答稳定性。课件还梳理了角色设定、背景信息、分隔符、重复“逐步思考”等注意事项方便对照自查。压缩包内仅有 1 个文件为 PPTX 课件大小约 1.05MB便于直接翻阅和二次修改。目前已有 76 人学习适合希望系统掌握 DeepSeek 提问技巧、规避常见大模型陷阱的入门到进阶用户。1. DeepSeek 提示词模型越聪明提问越要讲究为什么说说人话还不够DeepSeek 系列模型的推理能力已经有目共睹但提示词设计这件事在模型越来越聪明的今天反而更讲究了。很多人以为只要说人话就能让 AI 完全理解实际用下来却发现同一个问题换一种问法DeepSeek-R1 和 V3 给出的答案质量能差出好几个量级幻觉问题更是在文档写作、数据分析这类场景里让人不敢直接使用。这份《DeepSeek 提示词设计、幻觉避免与应用》PPT 把两条主线讲得很透第一R1 和 V3 是性格完全不同的两个模型提问策略必须分开第二六何分析法、Few-shot、分隔符这些技巧能显著压低幻觉率让 DeepSeek 真正进入生产环境。下文按实操角度拆解关键结论覆盖推理模型提问策略、可视化生成、幻觉排查与智能体场景适合正在做提示词工程、知识库问答或智能体应用的工程师和内容从业者。2. 先分清 DeepSeek-R1 和 V3推理模型的草稿纸与非推理模型的直觉PPT 开篇用了一个非常形象的比喻推理模型像有草稿纸的学生解题过程看得见非推理模型像知识丰富的朋友张口就来。这个比喻直接决定了你的提示词该往哪个方向写。2.1 思维链CoT改变的不只是答案还有提问方式DeepSeek-R1 属于推理型模型与 OpenAI o1/o3 系列、Kimi K1.5 系列同一阵营。这类模型在给出最终答案之前会先通过思维链Chain of ThoughtCoT分析问题界面上通常显示思考中...输出时也会附带解题思路。DeepSeek-V3 则属于非推理型和 GPT-4.5 这类模型类似响应速度极快像知识渊博的老朋友直接给出答案没有那层草稿纸演算过程。很多人以为推理型和非推理型只是多想一步和少想一步的区别实际差别远不止速度。推理模型把你的提示词当题面自己在草稿纸上往下推演它关注的是题目本身是什么非推理模型则直接从训练过的知识里做模式匹配你说的每句话都是检索线索。同一段提示词在这两类模型眼里信息权重完全不同。这就解释了为什么在 R1 上照搬 V3 的提示词容易翻车V3 需要你把背景、角色、格式细节全部填满R1 反而会被这些冗余信息干扰甚至出现过度解释。PPT 里的对照表讲得很清晰我直接摘出来对比维度推理型DeepSeek-R1非推理型DeepSeek-V3响应方式思维链分析后给出答案直接直觉响应提示词要求目标清晰即可少干预需要背景、角色、样本适用任务数学、编程、逻辑推理知识问答、闲聊、日常文本时间敏感性不敏感可以等追求快速响应准确性取向对准确性和逻辑性敏感对准确性要求宽松这张表是整份 PPT 的地基。后面所有提示词技巧本质上都在回答同一个问题当前任务该喂多少信息、用什么方式喂。新手最容易犯的错就是拿一套提示词通吃两个模型。2.2 提问策略分水岭推理型要克制非推理型要喂饱对 R1 这类推理模型最忌讳的三件事是过多解释、手把手教步骤、反复强调请逐步思考。R1 自带 CoT 能力你越是教它先分析 A 再分析 B它越容易把同一段逻辑翻来覆去地讲最后输出的是一篇注水长文。正确做法是只给任务边界、输入数据和输出约束让模型自己在草稿纸上推。比如排查一段 Python 报错直接贴代码和堆栈信息就够了不需要在前面加一句请你扮演资深 Python 工程师按照错误类型、调用栈、变量作用域三个维度逐步分析——这些它自己会做你替它规划了分析路径反而限制了它的推理空间。对 V3 这类非推理模型策略完全反过来角色设定要给样本要给背景要给足。它没有草稿纸你就是那个把答案从它记忆里钓出来的人。我自己的习惯是固定一套模板角色 背景 任务 输出格式。例如让 V3 写一份运营周报我会说你是互联网公司运营主管本周完成了 A/B 测试、渠道投放调整、用户访谈三项工作请写一份面向 VP 的周报要求先结论后过程500 字以内。这个模板在 V3 上跑得非常稳几乎不需要二次返工。PPT 里提到的充分提供背景信息本质就是人类沟通中的预先默契——同事之间一句话能懂是因为共享了大量上下文AI 没有这些默契所以提示词的作用就是把这些上下文显式注入。六何分析法就是系统化注入上下文的方法我在第 3 章详细展开。这里先记住结论推理模型的提示词要瘦身非推理模型的提示词要增重。2.3 场景选型与 API 参数什么任务该走哪个模型PPT 给了一个很实际的场景划分辅导孩子数学、调试程序代码、对准确性敏感的逻辑任务走 R1日常闲聊、知识问答、追求快速响应的场景走 V3。这个划分在 API 调用层面同样成立因为两个模型在接入方式和参数建议上完全不同。常见做法是通过 DeepSeek 官方兼容接口切换 model 参数代码大概这样from openai import OpenAI client OpenAI( api_keysk-你的密钥, base_urlhttps://api.deepseek.com ) def ask_deepseek(model: str, prompt: str, temperature: float 0.2): resp client.chat.completions.create( modelmodel, # deepseek-reasoner 或 deepseek-chat messages[{role: user, content: prompt}], temperaturetemperature, max_tokens4096 ) return resp.choices[0].message.content # 推理模型温度压到 0.1保证思维链的确定性 print(ask_deepseek(deepseek-reasoner, 用 Python 写一个原地快速排序, 0.1)) # 非推理模型温度放到 0.8适合创意文案 print(ask_deepseek(deepseek-chat, 为咖啡产品写 200 字小红书文案, 0.8))代码逻辑不复杂但两个参数值得展开。temperature 控制随机性推理模型建议压到 0.3 以下因为 CoT 链上任意一步的随机波动都会被后续步骤放大温度一高逻辑就开始发散非推理模型做创意任务可以放到 0.7 以上。max_tokens 在推理模型上要留足余量因为 deepseek-reasoner 的输出附带思考内容4096 只是起步值复杂推理任务很容易截断。另外提醒一句reasoner 的 API 响应里reasoning_content 字段单独存放思考过程最终答案在 content 字段第一次接入的人经常看错字段解析出来全是思维链文本。本地部署是另一个话题。用 vLLM 部署 DeepSeek-R1 系列模型时思维链会显著拉高显存占用显存不足时推理过程会静默中断——不报错只是输出突然变短。我在 7B 级别模型上踩过这个坑排查了半天才发现是显存瓶颈。所以本地部署前先按模型参数量 × 2.5 倍预估显存预留 CoT 的额外开销别指望 Offload 机制兜底。3. 提示词设计的两把抓手六何分析法和少量样本提示PPT 把提示词技巧总结为两个核心工具六何分析法5W1H和少量样本提示Few-shot。一个管问什么一个管怎么示范配合使用能让 DeepSeek 的输出质量稳定上一个台阶。3.1 六何分析法5W1H把模糊需求变成可执行指令六何分析法就是常说的 5W1H何事What、何故Why、何时When、何人Who、何处Where、何以How。PPT 里给了一个完整的职场案例为了提升销量何故公司决定在自媒体上做 X 产品推广何事时间定在中秋节期间何时目标人群是 18-35 岁年轻白领何人主要平台是小红书何处要求输出 500 字口播文案、完播率高、不生硬、植入软广、结合节日需求何以。同一个需求不交代六何和交代六何V3 的输出质量是两个层次。我见过太多失败的提问只说了帮我写个推广文案模型只能靠猜猜出来的东西自然处处是幻觉——它会脑补产品卖点、渠道特征、目标人群而这些脑补内容大部分是错的。六何分析法的本质是帮模型划定事实边界边界内的内容生成起来有依据边界外的不让它碰。PPT 里还有一个对比案例非常直观直接问为什么我的手机屏幕突然变暗了模型给出的是自动亮度调节、省电模式、软件问题、硬件问题这种通用排查清单但如果你补充背景最近天气很热经常 40℃ 以上苹果手机在太阳下晒一会儿屏幕自动变暗调也调不亮并加一句扮演我的同事用简洁语气回答模型的回答就会精准落到温度保护机制上。差别就在于信息是否充分。这个套路同样适用于技术场景。让 DeepSeek 排查问题时我习惯把六何浓缩成四要素环境、操作、现象、期望。比如Ubuntu 22.04Python 3.10pandas 2.0 环境用 pd.read_excel 读取 20 万行 .xlsx 文件内存涨到 4GB 后被 OOM killer 杀掉请给出不改变数据内容的内存优化方案。这样丢给 R1它一次就能定位到 dtype 推断和内存映射问题。如果只问pandas 读大文件内存爆了怎么办它会先跟你确认环境、数据规模、代码写法来回扯皮好几轮。如果你在做知识库问答六何分析法的信息注入可以由 RAG 知识库自动完成——检索到的相关文档片段拼到提示词里相当于替用户把背景填好。但要注意RAG 片段和用户原始问题之间要加分隔符隔开否则模型分不清哪些是参考资料、哪些是待回答的问题。3.2 Few-shot 少量样本提示给模型抄作业的模板六何分析法解决信息够不够的问题Few-shot 解决格式对不对的问题。非推理模型自由发挥时输出格式千奇百怪给它几个标准样例它就会照着样例的样子组织答案。这就是 PPT 里说的举些例子。Few-shot 的关键不在于例子多而在于例子准。我给 V3 做评论分类时就用过这个技巧prompt 请判断以下用户评论属于哪个类别质量、价格、物流、客服、其他。 示例1 评论这双鞋穿三天就开胶了 类别质量 示例2 评论双十一买贵了客服也不给补差价 类别价格 示例3 评论等了十天还没发货仓库睡着了吗 类别物流 现在判断 评论昨天咨询售后回复慢得像蜗牛 类别 result ask_deepseek(deepseek-chat, prompt, 0.1) print(result) # 期望输出客服这段代码有三点值得展开。第一示例数量控制在 2-5 个太少模型学不到规律太多会稀释当前任务的注意力还挤占上下文窗口。第二示例要覆盖边界情况——物流示例特意选了带情绪指责的句子而不是中性的快递什么时候到这样才能教会模型区分情绪和类别归属。第三示例的输出格式要和正式提问完全一致模型在 Few-shot 里学的其实是输入长什么样、输出就长什么样的映射关系格式不一致会直接带偏。实际使用中还有一种更省事的玩法利用 DeepSeek 的对话继承能力把上一轮的问答格式作为隐式示例。先让模型在修正模式下输出一次标准格式后续所有轮次都会跟着那个格式走。这比每次手写 Few-shot 效率高前提是对话上下文没有被截断长会话里记得用第 4 章的方法维护上下文。3.3 结构化模板与分隔符长提示词的工程化写法当提示词超过 300 字信息结构就会开始打架。角色设定、背景材料、任务要求、输出格式混在一起模型分不清哪些是约束、哪些是内容。这时候需要用分隔符做区块隔离。我用得比较顺手的格式是标签加分隔prompt # 角色 你是资深的供应链仓库管理系统工程师。 # 背景 我们仓库有 3 万个 SKU使用 RF 扫码枪进行出入库最近盘点差异率从 0.2% 上升到 0.8%。 # 任务 分析盘点差异率上升的可能原因并给出 3 条可落地的改进措施。 # 参考信息不是任务本身仅说明当前作业流程 当前流程扫码枪扫描货位 - 系统更新库存 - 每日凌晨跑批对账 # 输出格式 按原因分析和改进措施两部分输出措施部分每条不超过 100 字用数字编号。 result ask_deepseek(deepseek-reasoner, prompt, 0.2) print(result)核心逻辑是用标签把不同信息类型分块# 角色定义身份# 背景提供上下文# 任务划定目标# 参考信息用于区分参考资料和待办事项# 输出格式约束答案结构。第四个标签是我自己加的——很多人忽略参考信息和任务的区别结果模型把参考资料当成了要执行的任务输出完全跑偏。分隔符的使用有一个选词技巧标签名要选模型训练语料里出现频率极高的词。角色背景任务语义稳定换成拟态对象上下文集合这种生僻说法模型理解成本上升输出质量反而下降。另外要注意分隔符和正文冲突的问题——如果提示词正文里本身含有# 任务这样的字符串模型会混淆嵌套结构。发请求之前扫一眼正文有冲突就换分隔符。4. 幻觉避免与排查DeepSeek 高频翻车场景的五个实测记录幻觉是 DeepSeek 落地时绕不开的坎。PPT 里明确提醒DeepSeek 并非完美搞清优点和缺陷。下面五条是我和团队在实际使用中踩过的坑按现象、原因、解决三步写清楚。4.1 编造数据源与引用看似权威实则无中生有现象让 DeepSeek 写行业分析报告里面出现一串很具体的统计数字比如2024 年国内某品类市场规模达 372 亿元同比增长 17.3%。追问数据来源它给出一份看似合理的《XX 行业白皮书2024》但实际搜索并不存在这个文件。原因这是典型的模型幻觉。非推理模型在训练中见过大量市场规模 百分比 白皮书的文本搭配生成时按模式补齐并不真正检索数据。更麻烦的是模型对引用的理解是格式层面的不是事实层面的——它知道引用长什么样但不知道引用指向的内容是否真实。解决第一步在提示词里显式声明所有数据必须标注来源来源不明确的数据用约字标注这能显著减少无中生有的精确数字。第二步对输出做专门的数据验证——把生成内容里的数字全部摘出来逐一核对。这个验证可以交给 DeepSeek 自己完成一半把数字清单丢回去让它标注每个数据的可信度和可能来源人工只核查低可信度部分。别指望一次生成就是干净数据AI 生成内容的数据环节必须单独过一遍验证。4.2 推理模型被手把手教学带偏过度干预让思维链失控现象在 deepseek-reasoner 上排查 SQL 问题提示词里写了请先检查索引再检查 join 条件最后检查数据类型。结果模型输出了一大段思维过程反复在索引和 join 之间绕圈最终结论是怀疑数据库配置有问题完全没提到真正的原因——字段字符集不一致。原因推理模型有自己的 CoT 路径外部施加的过程性指令会干扰推演节奏。你给的步骤一旦和它内部规划的路径冲突模型会试图兼容两套思路推理链变得混乱最终答案质量下降。PPT 里也强调了这一点推理型模型不太需要提示词过多干预反而起反作用。解决逻辑类任务先把我猜应该怎么做的念头压下去。提示词只给目标、输入和约束不给步骤。上面的 SQL 场景改成以下 SQL 查询结果比预期多 30% 的行请定位原因。表结构如下[DDL]。当前查询如下[SQL]。R1 自己会决定先看 DDL 还是先看 SQL结果反而更准。如果一定要引导方向用问句形式代替祈使句是否可能与字符集相关把它当作提示而不是命令模型的推理链就不会被打断。4.3 上下文超长后的记忆漂移前言不搭后语现象多轮对话中连续让 DeepSeek 修改一份文档改到十几轮之后模型突然把第 3 轮已经明确删除的段落又写回来了或者把某处修改应用到错误的位置前后矛盾。原因模型对上下文的注意力是衰减的离当前位置越远的内容生成时的有效权重越低。当上下文接近窗口上限早期约束和中期修改都可能漂移出注意力范围模型只能基于最近的片段做补全于是出现记忆回退。解决第一长任务拆短会话每个会话只做一件事。修改文档时让模型每轮只处理一个章节处理完立刻把结果存成文件下一轮带着新文件继续而不是在同一会话里反复修改同一份长文档。第二关键约束重复写入。每轮提示词开头都带一句注意第三轮已确认删除第二节不要恢复。看起来冗余但能有效对抗注意力衰减。第三对接 API 时定期截断历史消息只保留最近 10 轮加一份最终约定摘要用摘要代替全量历史。4.4 角色设定与知识冲突身份暗示压过了事实现象让 DeepSeek 扮演特定领域的权威专家然后问一个基础问题模型给出了与事实不符的答案。比如让 V3 扮演免疫学教授问吃维生素 C 可以预防感冒吗它给出长篇理论支持结论是可以有效预防与主流医学共识相悖。原因角色设定会拉高模型对领域自信的输出倾向。扮演权威角色时模型倾向于给出更绝对、更详细的回答来匹配角色预期事实约束在角色引导下被弱化。角色设定给得越夸张幻觉风险越高。解决角色设定必须有边界。不要只给身份要同时给允许做什么、不允许做什么。把上面的提示词改写成你是医学领域的科普作者请以循证医学为标准回答。如果不确定直接说证据不足。这等于给角色加了护栏。对事实性要求高的任务我习惯再加一行输出前自查你给的每个结论是否能在权威医学指南中找到依据找不到就标注存疑。这一步能有效把模型从扮演自信专家拉回实事求是。4.5 结构化输出字段幻觉字段随意发明解析端直接崩现象让 DeepSeek 输出 JSON 用于程序解析它给出的 JSON 里出现了一个提示词里完全没有的字段或者字段命名风格和示例不一致。比如要求输出 {name: xxx, score: 0.9}它多给了一个 confidence: high解析代码直接报错。原因这类问题多发生在非推理模型的自由输出模式下。模型在训练中见过大量 JSON 数据生成时会按惯性补充它认为合理的字段。提示词里的 JSON 示例只是它参考的众多模式之一不是硬约束。解决三个层次。第一层提示词里给完整 JSON 示例并指定只输出 JSON不要包裹 markdown 代码块标记。第二层对输出做运行时校验解析失败自动重试一次重试时把第一次的输出作为反例丢回去上次输出包含多余字段请严格按示例格式重新输出。第三层对关键字段做类型检查比如 score 必须是 0-1 之间的浮点数不合规就走重试逻辑。我在服务端还会加一道 JSON Schema 校验——把模型不可靠当成系统设计的基本假设而不是期望它永远输出正确。5. 让 DeepSeek 出图出动画提示词驱动的可视化产物闭环PPT 里专门有一节讲设计提示词让 DeepSeek 做炫酷图表和动画。这部分内容不是噱头——把提示词工程和前端输出结合起来DeepSeek 完全可以作为可视化产物的生成引擎。5.1 图表生成一句话让 DeepSeek 写出可渲染的图表代码最常见的需求是把一段数据变成图表。我让 DeepSeek 生成 ECharts 配置而不是图片因为 ECharts 是 JSON 配置驱动的模型容易理解也方便后续手动微调。提示词层面数据、图表类型、样式偏好、交互要求一次性说清。prompt 用 ECharts 生成一个柱状图展示以下数据 月份1月到6月销量[320, 452, 501, 634, 780, 912] 要求 1. 使用 option 配置对象直接输出完整 JSON 2. x轴显示月份y轴标题为销量件 3. 柱状图颜色用渐变 (#4F86F7 到 #2B5AE8) 4. 在数据最高的 6 月柱子上添加 label 显示具体数值 5. 只输出 JSON不要 markdown 代码块标记 result ask_deepseek(deepseek-chat, prompt, 0.3) print(result)这里的关键参数是 temperature 0.3。图表生成容错率很低温度高了 ECharts 配置结构容易写歪——series 类型拼错、图表类型张冠李戴都是真实发生过的事。温度压到 0.3 以下模型会更保守地按训练中见过的标准结构输出。另一个细节是只输出 JSON这个约束不加的话模型经常包一层 json 代码块标记前端解析时还要多做一步清洗。拿到 JSON 后直接塞给 ECharts 初始化函数即可。我一般先在本地跑一个最小 HTML 验证页把模型生成的 option 粘贴进去确认渲染效果再集成到正式项目。这个流程把返工成本压到了最低。5.2 HTML 动画页面纯提示词生成可执行的动效文件图表之外PPT 提到的动画更值得玩。DeepSeek 写单文件 HTML CSS JavaScript 动画的能力已经到了直接出成品的程度。我让它做过产品发布会倒计时页面效果相当能打。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title产品发布倒计时/title style body { font-family: sans-serif; display: flex; justify-content: center; align-items: center; height: 100vh; background: #0f172a; color: #fff; } #countdown { font-size: 4rem; letter-spacing: 0.15em; text-shadow: 0 0 20px rgba(79, 134, 247, 0.6); } /style /head body div idcountdown02:59:59/div script let total 3 * 3600 59 * 60 59; // 初始 02:59:59 setInterval(() { if (total 0) { total--; const h String(Math.floor(total / 3600)).padStart(2, 0); const m String(Math.floor((total % 3600) / 60)).padStart(2, 0); const s String(total % 60).padStart(2, 0); document.getElementById(countdown).textContent ${h}:${m}:${s}; } }, 1000); /script /body /html这段代码是我用一段提示词生成的原文大概是做一个全屏深色背景的倒计时页面显示时分秒带发光效果初始时间 02:59:59。注意两个关键点一是明确要求输出一个完整的 HTML 文件二是给足视觉方向深色、发光比让它写个好看的倒计时靠谱得多。拿到 HTML 直接保存成 .html 文件双击就能跑不需要任何构建工具。这是 DeepSeek 做原型验证最高效的方式想验证一个交互想法是否成立让模型出单文件 HTML浏览器跑一下就知道结果。我在做内部工具原型时经常走这个流程一天能验证七八个想法翻车成本几乎为零。5.3 提示词工程落地到接口参数配置与流式输出前面的例子都在聊提示词内容但真正接入生产环境代码侧还有两个细节不能忽略。第一是响应解析deepseek-reasoner 的响应带 reasoning_content要分字段提取。第二是流式输出长文档生成场景用流式更稳用户能提前看到首屏内容也规避了请求超时。from openai import OpenAI client OpenAI(api_keysk-你的密钥, base_urlhttps://api.deepseek.com) def stream_chat(prompt: str, model: str deepseek-chat): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], streamTrue, temperature0.3 ) collected for chunk in resp: if chunk.choices[0].delta.content: collected chunk.choices[0].delta.content print(chunk.choices[0].delta.content, end) return collected text stream_chat(写一篇 800 字的产品发布公告, deepseek-chat)流式接口有两个注意事项。deepseek-reasoner 使用流式时思考过程会逐段返回调用方需要同时处理 reasoning_content 和 content 两路文本分别拼接否则界面显示会乱。另外流式响应的超时设置要放宽——推理模型的思考时间从几秒到几十秒不等HTTP 客户端的默认超时很容易触发建议设置 120 秒以上。6. 从提示词到智能体Manus 场景下的方法论迁移与输出校验PPT 最后提到了当时爆火的 Manus 智能体。Manus 这类工具的定位是任务代理你给它目标它自己规划步骤、调用工具、处理文件、交付结果。很多人以为智能体时代提示词就不重要了恰恰相反——你给 Manus 的任务描述本质上就是一个超长提示词。六何分析法、Few-shot、分隔符的规则全部适用只是书写对象从对话模型变成了任务代理。6.1 Manus 与 DeepSeek 如何分工Manus 在实际使用中通常扮演编排者DeepSeek 扮演执行者。你向 Manus 描述目标Manus 拆解出子任务再把子任务分发给模型执行。这就要求初始描述必须足够结构化目标是什么、输入数据在哪、输出格式是什么、有哪些限制。我写这类任务描述时直接套用第 3 章的分隔符模板把# 角色换成# 任务目标把# 背景换成# 可用资源。一个典型的写法是# 任务目标分析销售数据并生成月度报告# 可用资源/data/sales_2025.csv包含订单号、金额、日期三列# 输出格式Markdown 报告含数据概览、趋势分析和异常提醒三个部分# 限制不要修改原始数据文件。这些约束写清楚智能体跑出来的结果基本不用二次加工。6.2 输出校验三招交叉提问、反向验证与格式检查智能体自动执行时没有人工干预的机会幻觉风险比单次对话更高。我给自己定了三条铁律全部写进任务描述里。第一交叉提问同一任务用两种措辞各问一次两次结论一致才采信不一致先标红。第二反向验证让模型为自己的结论写出验证过程数值型结论必须给出计算公式和原始数据引用。第三格式检查结构化输出必须过 JSON Schema 校验失败自动重试最多三次。这些规则写进智能体的任务描述比事后人工校对省力得多。智能体的优势是自动执行劣势是错误也会自动放大所以提示词里加验证环节是必须的。特别是涉及金额、日期、数量这类可校验字段的场景交叉提问基本能挡住大部分数据层面的幻觉。从那以后我每次用 DeepSeek 生成重要内容都强制走一遍提示词设计 → 生成 → 校验 → 修正的闭环尤其是幻觉校验那一步从不跳过。这个习惯帮我省下的返工时间远远超过写提示词本身花费的时间。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 1:22:00 · 阅读 1.2k DeepSeek提示词设计与幻觉避免：R1与V3实战策略
简介面向希望在职场汇报、教学备课、自媒体创作中用好 DeepSeek 的读者这份 50 页 PPT 围绕提示词设计、幻觉避免与应用展开并兼谈 Manus 智能体的价值定位。内容先回应“AI 越来越聪明提示词是否还重要”的疑问再对比 DeepSeek-R1 与 V3 的推理型/非推理型性格差异说明两类模型适合的任务场景和提问策略同时结合 5W1H 信息补充、少样本示例、结构化提示词与“草稿纸”式思维链等方法可帮助读者减少事实幻觉、提升回答稳定性。课件还梳理了角色设定、背景信息、分隔符、重复“逐步思考”等注意事项方便对照自查。压缩包内仅有 1 个文件为 PPTX 课件大小约 1.05MB便于直接翻阅和二次修改。目前已有 76 人学习适合希望系统掌握 DeepSeek 提问技巧、规避常见大模型陷阱的入门到进阶用户。1. DeepSeek 提示词模型越聪明提问越要讲究为什么说说人话还不够DeepSeek 系列模型的推理能力已经有目共睹但提示词设计这件事在模型越来越聪明的今天反而更讲究了。很多人以为只要说人话就能让 AI 完全理解实际用下来却发现同一个问题换一种问法DeepSeek-R1 和 V3 给出的答案质量能差出好几个量级幻觉问题更是在文档写作、数据分析这类场景里让人不敢直接使用。这份《DeepSeek 提示词设计、幻觉避免与应用》PPT 把两条主线讲得很透第一R1 和 V3 是性格完全不同的两个模型提问策略必须分开第二六何分析法、Few-shot、分隔符这些技巧能显著压低幻觉率让 DeepSeek 真正进入生产环境。下文按实操角度拆解关键结论覆盖推理模型提问策略、可视化生成、幻觉排查与智能体场景适合正在做提示词工程、知识库问答或智能体应用的工程师和内容从业者。2. 先分清 DeepSeek-R1 和 V3推理模型的草稿纸与非推理模型的直觉PPT 开篇用了一个非常形象的比喻推理模型像有草稿纸的学生解题过程看得见非推理模型像知识丰富的朋友张口就来。这个比喻直接决定了你的提示词该往哪个方向写。2.1 思维链CoT改变的不只是答案还有提问方式DeepSeek-R1 属于推理型模型与 OpenAI o1/o3 系列、Kimi K1.5 系列同一阵营。这类模型在给出最终答案之前会先通过思维链Chain of ThoughtCoT分析问题界面上通常显示思考中...输出时也会附带解题思路。DeepSeek-V3 则属于非推理型和 GPT-4.5 这类模型类似响应速度极快像知识渊博的老朋友直接给出答案没有那层草稿纸演算过程。很多人以为推理型和非推理型只是多想一步和少想一步的区别实际差别远不止速度。推理模型把你的提示词当题面自己在草稿纸上往下推演它关注的是题目本身是什么非推理模型则直接从训练过的知识里做模式匹配你说的每句话都是检索线索。同一段提示词在这两类模型眼里信息权重完全不同。这就解释了为什么在 R1 上照搬 V3 的提示词容易翻车V3 需要你把背景、角色、格式细节全部填满R1 反而会被这些冗余信息干扰甚至出现过度解释。PPT 里的对照表讲得很清晰我直接摘出来对比维度推理型DeepSeek-R1非推理型DeepSeek-V3响应方式思维链分析后给出答案直接直觉响应提示词要求目标清晰即可少干预需要背景、角色、样本适用任务数学、编程、逻辑推理知识问答、闲聊、日常文本时间敏感性不敏感可以等追求快速响应准确性取向对准确性和逻辑性敏感对准确性要求宽松这张表是整份 PPT 的地基。后面所有提示词技巧本质上都在回答同一个问题当前任务该喂多少信息、用什么方式喂。新手最容易犯的错就是拿一套提示词通吃两个模型。2.2 提问策略分水岭推理型要克制非推理型要喂饱对 R1 这类推理模型最忌讳的三件事是过多解释、手把手教步骤、反复强调请逐步思考。R1 自带 CoT 能力你越是教它先分析 A 再分析 B它越容易把同一段逻辑翻来覆去地讲最后输出的是一篇注水长文。正确做法是只给任务边界、输入数据和输出约束让模型自己在草稿纸上推。比如排查一段 Python 报错直接贴代码和堆栈信息就够了不需要在前面加一句请你扮演资深 Python 工程师按照错误类型、调用栈、变量作用域三个维度逐步分析——这些它自己会做你替它规划了分析路径反而限制了它的推理空间。对 V3 这类非推理模型策略完全反过来角色设定要给样本要给背景要给足。它没有草稿纸你就是那个把答案从它记忆里钓出来的人。我自己的习惯是固定一套模板角色 背景 任务 输出格式。例如让 V3 写一份运营周报我会说你是互联网公司运营主管本周完成了 A/B 测试、渠道投放调整、用户访谈三项工作请写一份面向 VP 的周报要求先结论后过程500 字以内。这个模板在 V3 上跑得非常稳几乎不需要二次返工。PPT 里提到的充分提供背景信息本质就是人类沟通中的预先默契——同事之间一句话能懂是因为共享了大量上下文AI 没有这些默契所以提示词的作用就是把这些上下文显式注入。六何分析法就是系统化注入上下文的方法我在第 3 章详细展开。这里先记住结论推理模型的提示词要瘦身非推理模型的提示词要增重。2.3 场景选型与 API 参数什么任务该走哪个模型PPT 给了一个很实际的场景划分辅导孩子数学、调试程序代码、对准确性敏感的逻辑任务走 R1日常闲聊、知识问答、追求快速响应的场景走 V3。这个划分在 API 调用层面同样成立因为两个模型在接入方式和参数建议上完全不同。常见做法是通过 DeepSeek 官方兼容接口切换 model 参数代码大概这样from openai import OpenAI client OpenAI( api_keysk-你的密钥, base_urlhttps://api.deepseek.com ) def ask_deepseek(model: str, prompt: str, temperature: float 0.2): resp client.chat.completions.create( modelmodel, # deepseek-reasoner 或 deepseek-chat messages[{role: user, content: prompt}], temperaturetemperature, max_tokens4096 ) return resp.choices[0].message.content # 推理模型温度压到 0.1保证思维链的确定性 print(ask_deepseek(deepseek-reasoner, 用 Python 写一个原地快速排序, 0.1)) # 非推理模型温度放到 0.8适合创意文案 print(ask_deepseek(deepseek-chat, 为咖啡产品写 200 字小红书文案, 0.8))代码逻辑不复杂但两个参数值得展开。temperature 控制随机性推理模型建议压到 0.3 以下因为 CoT 链上任意一步的随机波动都会被后续步骤放大温度一高逻辑就开始发散非推理模型做创意任务可以放到 0.7 以上。max_tokens 在推理模型上要留足余量因为 deepseek-reasoner 的输出附带思考内容4096 只是起步值复杂推理任务很容易截断。另外提醒一句reasoner 的 API 响应里reasoning_content 字段单独存放思考过程最终答案在 content 字段第一次接入的人经常看错字段解析出来全是思维链文本。本地部署是另一个话题。用 vLLM 部署 DeepSeek-R1 系列模型时思维链会显著拉高显存占用显存不足时推理过程会静默中断——不报错只是输出突然变短。我在 7B 级别模型上踩过这个坑排查了半天才发现是显存瓶颈。所以本地部署前先按模型参数量 × 2.5 倍预估显存预留 CoT 的额外开销别指望 Offload 机制兜底。3. 提示词设计的两把抓手六何分析法和少量样本提示PPT 把提示词技巧总结为两个核心工具六何分析法5W1H和少量样本提示Few-shot。一个管问什么一个管怎么示范配合使用能让 DeepSeek 的输出质量稳定上一个台阶。3.1 六何分析法5W1H把模糊需求变成可执行指令六何分析法就是常说的 5W1H何事What、何故Why、何时When、何人Who、何处Where、何以How。PPT 里给了一个完整的职场案例为了提升销量何故公司决定在自媒体上做 X 产品推广何事时间定在中秋节期间何时目标人群是 18-35 岁年轻白领何人主要平台是小红书何处要求输出 500 字口播文案、完播率高、不生硬、植入软广、结合节日需求何以。同一个需求不交代六何和交代六何V3 的输出质量是两个层次。我见过太多失败的提问只说了帮我写个推广文案模型只能靠猜猜出来的东西自然处处是幻觉——它会脑补产品卖点、渠道特征、目标人群而这些脑补内容大部分是错的。六何分析法的本质是帮模型划定事实边界边界内的内容生成起来有依据边界外的不让它碰。PPT 里还有一个对比案例非常直观直接问为什么我的手机屏幕突然变暗了模型给出的是自动亮度调节、省电模式、软件问题、硬件问题这种通用排查清单但如果你补充背景最近天气很热经常 40℃ 以上苹果手机在太阳下晒一会儿屏幕自动变暗调也调不亮并加一句扮演我的同事用简洁语气回答模型的回答就会精准落到温度保护机制上。差别就在于信息是否充分。这个套路同样适用于技术场景。让 DeepSeek 排查问题时我习惯把六何浓缩成四要素环境、操作、现象、期望。比如Ubuntu 22.04Python 3.10pandas 2.0 环境用 pd.read_excel 读取 20 万行 .xlsx 文件内存涨到 4GB 后被 OOM killer 杀掉请给出不改变数据内容的内存优化方案。这样丢给 R1它一次就能定位到 dtype 推断和内存映射问题。如果只问pandas 读大文件内存爆了怎么办它会先跟你确认环境、数据规模、代码写法来回扯皮好几轮。如果你在做知识库问答六何分析法的信息注入可以由 RAG 知识库自动完成——检索到的相关文档片段拼到提示词里相当于替用户把背景填好。但要注意RAG 片段和用户原始问题之间要加分隔符隔开否则模型分不清哪些是参考资料、哪些是待回答的问题。3.2 Few-shot 少量样本提示给模型抄作业的模板六何分析法解决信息够不够的问题Few-shot 解决格式对不对的问题。非推理模型自由发挥时输出格式千奇百怪给它几个标准样例它就会照着样例的样子组织答案。这就是 PPT 里说的举些例子。Few-shot 的关键不在于例子多而在于例子准。我给 V3 做评论分类时就用过这个技巧prompt 请判断以下用户评论属于哪个类别质量、价格、物流、客服、其他。 示例1 评论这双鞋穿三天就开胶了 类别质量 示例2 评论双十一买贵了客服也不给补差价 类别价格 示例3 评论等了十天还没发货仓库睡着了吗 类别物流 现在判断 评论昨天咨询售后回复慢得像蜗牛 类别 result ask_deepseek(deepseek-chat, prompt, 0.1) print(result) # 期望输出客服这段代码有三点值得展开。第一示例数量控制在 2-5 个太少模型学不到规律太多会稀释当前任务的注意力还挤占上下文窗口。第二示例要覆盖边界情况——物流示例特意选了带情绪指责的句子而不是中性的快递什么时候到这样才能教会模型区分情绪和类别归属。第三示例的输出格式要和正式提问完全一致模型在 Few-shot 里学的其实是输入长什么样、输出就长什么样的映射关系格式不一致会直接带偏。实际使用中还有一种更省事的玩法利用 DeepSeek 的对话继承能力把上一轮的问答格式作为隐式示例。先让模型在修正模式下输出一次标准格式后续所有轮次都会跟着那个格式走。这比每次手写 Few-shot 效率高前提是对话上下文没有被截断长会话里记得用第 4 章的方法维护上下文。3.3 结构化模板与分隔符长提示词的工程化写法当提示词超过 300 字信息结构就会开始打架。角色设定、背景材料、任务要求、输出格式混在一起模型分不清哪些是约束、哪些是内容。这时候需要用分隔符做区块隔离。我用得比较顺手的格式是标签加分隔prompt # 角色 你是资深的供应链仓库管理系统工程师。 # 背景 我们仓库有 3 万个 SKU使用 RF 扫码枪进行出入库最近盘点差异率从 0.2% 上升到 0.8%。 # 任务 分析盘点差异率上升的可能原因并给出 3 条可落地的改进措施。 # 参考信息不是任务本身仅说明当前作业流程 当前流程扫码枪扫描货位 - 系统更新库存 - 每日凌晨跑批对账 # 输出格式 按原因分析和改进措施两部分输出措施部分每条不超过 100 字用数字编号。 result ask_deepseek(deepseek-reasoner, prompt, 0.2) print(result)核心逻辑是用标签把不同信息类型分块# 角色定义身份# 背景提供上下文# 任务划定目标# 参考信息用于区分参考资料和待办事项# 输出格式约束答案结构。第四个标签是我自己加的——很多人忽略参考信息和任务的区别结果模型把参考资料当成了要执行的任务输出完全跑偏。分隔符的使用有一个选词技巧标签名要选模型训练语料里出现频率极高的词。角色背景任务语义稳定换成拟态对象上下文集合这种生僻说法模型理解成本上升输出质量反而下降。另外要注意分隔符和正文冲突的问题——如果提示词正文里本身含有# 任务这样的字符串模型会混淆嵌套结构。发请求之前扫一眼正文有冲突就换分隔符。4. 幻觉避免与排查DeepSeek 高频翻车场景的五个实测记录幻觉是 DeepSeek 落地时绕不开的坎。PPT 里明确提醒DeepSeek 并非完美搞清优点和缺陷。下面五条是我和团队在实际使用中踩过的坑按现象、原因、解决三步写清楚。4.1 编造数据源与引用看似权威实则无中生有现象让 DeepSeek 写行业分析报告里面出现一串很具体的统计数字比如2024 年国内某品类市场规模达 372 亿元同比增长 17.3%。追问数据来源它给出一份看似合理的《XX 行业白皮书2024》但实际搜索并不存在这个文件。原因这是典型的模型幻觉。非推理模型在训练中见过大量市场规模 百分比 白皮书的文本搭配生成时按模式补齐并不真正检索数据。更麻烦的是模型对引用的理解是格式层面的不是事实层面的——它知道引用长什么样但不知道引用指向的内容是否真实。解决第一步在提示词里显式声明所有数据必须标注来源来源不明确的数据用约字标注这能显著减少无中生有的精确数字。第二步对输出做专门的数据验证——把生成内容里的数字全部摘出来逐一核对。这个验证可以交给 DeepSeek 自己完成一半把数字清单丢回去让它标注每个数据的可信度和可能来源人工只核查低可信度部分。别指望一次生成就是干净数据AI 生成内容的数据环节必须单独过一遍验证。4.2 推理模型被手把手教学带偏过度干预让思维链失控现象在 deepseek-reasoner 上排查 SQL 问题提示词里写了请先检查索引再检查 join 条件最后检查数据类型。结果模型输出了一大段思维过程反复在索引和 join 之间绕圈最终结论是怀疑数据库配置有问题完全没提到真正的原因——字段字符集不一致。原因推理模型有自己的 CoT 路径外部施加的过程性指令会干扰推演节奏。你给的步骤一旦和它内部规划的路径冲突模型会试图兼容两套思路推理链变得混乱最终答案质量下降。PPT 里也强调了这一点推理型模型不太需要提示词过多干预反而起反作用。解决逻辑类任务先把我猜应该怎么做的念头压下去。提示词只给目标、输入和约束不给步骤。上面的 SQL 场景改成以下 SQL 查询结果比预期多 30% 的行请定位原因。表结构如下[DDL]。当前查询如下[SQL]。R1 自己会决定先看 DDL 还是先看 SQL结果反而更准。如果一定要引导方向用问句形式代替祈使句是否可能与字符集相关把它当作提示而不是命令模型的推理链就不会被打断。4.3 上下文超长后的记忆漂移前言不搭后语现象多轮对话中连续让 DeepSeek 修改一份文档改到十几轮之后模型突然把第 3 轮已经明确删除的段落又写回来了或者把某处修改应用到错误的位置前后矛盾。原因模型对上下文的注意力是衰减的离当前位置越远的内容生成时的有效权重越低。当上下文接近窗口上限早期约束和中期修改都可能漂移出注意力范围模型只能基于最近的片段做补全于是出现记忆回退。解决第一长任务拆短会话每个会话只做一件事。修改文档时让模型每轮只处理一个章节处理完立刻把结果存成文件下一轮带着新文件继续而不是在同一会话里反复修改同一份长文档。第二关键约束重复写入。每轮提示词开头都带一句注意第三轮已确认删除第二节不要恢复。看起来冗余但能有效对抗注意力衰减。第三对接 API 时定期截断历史消息只保留最近 10 轮加一份最终约定摘要用摘要代替全量历史。4.4 角色设定与知识冲突身份暗示压过了事实现象让 DeepSeek 扮演特定领域的权威专家然后问一个基础问题模型给出了与事实不符的答案。比如让 V3 扮演免疫学教授问吃维生素 C 可以预防感冒吗它给出长篇理论支持结论是可以有效预防与主流医学共识相悖。原因角色设定会拉高模型对领域自信的输出倾向。扮演权威角色时模型倾向于给出更绝对、更详细的回答来匹配角色预期事实约束在角色引导下被弱化。角色设定给得越夸张幻觉风险越高。解决角色设定必须有边界。不要只给身份要同时给允许做什么、不允许做什么。把上面的提示词改写成你是医学领域的科普作者请以循证医学为标准回答。如果不确定直接说证据不足。这等于给角色加了护栏。对事实性要求高的任务我习惯再加一行输出前自查你给的每个结论是否能在权威医学指南中找到依据找不到就标注存疑。这一步能有效把模型从扮演自信专家拉回实事求是。4.5 结构化输出字段幻觉字段随意发明解析端直接崩现象让 DeepSeek 输出 JSON 用于程序解析它给出的 JSON 里出现了一个提示词里完全没有的字段或者字段命名风格和示例不一致。比如要求输出 {name: xxx, score: 0.9}它多给了一个 confidence: high解析代码直接报错。原因这类问题多发生在非推理模型的自由输出模式下。模型在训练中见过大量 JSON 数据生成时会按惯性补充它认为合理的字段。提示词里的 JSON 示例只是它参考的众多模式之一不是硬约束。解决三个层次。第一层提示词里给完整 JSON 示例并指定只输出 JSON不要包裹 markdown 代码块标记。第二层对输出做运行时校验解析失败自动重试一次重试时把第一次的输出作为反例丢回去上次输出包含多余字段请严格按示例格式重新输出。第三层对关键字段做类型检查比如 score 必须是 0-1 之间的浮点数不合规就走重试逻辑。我在服务端还会加一道 JSON Schema 校验——把模型不可靠当成系统设计的基本假设而不是期望它永远输出正确。5. 让 DeepSeek 出图出动画提示词驱动的可视化产物闭环PPT 里专门有一节讲设计提示词让 DeepSeek 做炫酷图表和动画。这部分内容不是噱头——把提示词工程和前端输出结合起来DeepSeek 完全可以作为可视化产物的生成引擎。5.1 图表生成一句话让 DeepSeek 写出可渲染的图表代码最常见的需求是把一段数据变成图表。我让 DeepSeek 生成 ECharts 配置而不是图片因为 ECharts 是 JSON 配置驱动的模型容易理解也方便后续手动微调。提示词层面数据、图表类型、样式偏好、交互要求一次性说清。prompt 用 ECharts 生成一个柱状图展示以下数据 月份1月到6月销量[320, 452, 501, 634, 780, 912] 要求 1. 使用 option 配置对象直接输出完整 JSON 2. x轴显示月份y轴标题为销量件 3. 柱状图颜色用渐变 (#4F86F7 到 #2B5AE8) 4. 在数据最高的 6 月柱子上添加 label 显示具体数值 5. 只输出 JSON不要 markdown 代码块标记 result ask_deepseek(deepseek-chat, prompt, 0.3) print(result)这里的关键参数是 temperature 0.3。图表生成容错率很低温度高了 ECharts 配置结构容易写歪——series 类型拼错、图表类型张冠李戴都是真实发生过的事。温度压到 0.3 以下模型会更保守地按训练中见过的标准结构输出。另一个细节是只输出 JSON这个约束不加的话模型经常包一层 json 代码块标记前端解析时还要多做一步清洗。拿到 JSON 后直接塞给 ECharts 初始化函数即可。我一般先在本地跑一个最小 HTML 验证页把模型生成的 option 粘贴进去确认渲染效果再集成到正式项目。这个流程把返工成本压到了最低。5.2 HTML 动画页面纯提示词生成可执行的动效文件图表之外PPT 提到的动画更值得玩。DeepSeek 写单文件 HTML CSS JavaScript 动画的能力已经到了直接出成品的程度。我让它做过产品发布会倒计时页面效果相当能打。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title产品发布倒计时/title style body { font-family: sans-serif; display: flex; justify-content: center; align-items: center; height: 100vh; background: #0f172a; color: #fff; } #countdown { font-size: 4rem; letter-spacing: 0.15em; text-shadow: 0 0 20px rgba(79, 134, 247, 0.6); } /style /head body div idcountdown02:59:59/div script let total 3 * 3600 59 * 60 59; // 初始 02:59:59 setInterval(() { if (total 0) { total--; const h String(Math.floor(total / 3600)).padStart(2, 0); const m String(Math.floor((total % 3600) / 60)).padStart(2, 0); const s String(total % 60).padStart(2, 0); document.getElementById(countdown).textContent ${h}:${m}:${s}; } }, 1000); /script /body /html这段代码是我用一段提示词生成的原文大概是做一个全屏深色背景的倒计时页面显示时分秒带发光效果初始时间 02:59:59。注意两个关键点一是明确要求输出一个完整的 HTML 文件二是给足视觉方向深色、发光比让它写个好看的倒计时靠谱得多。拿到 HTML 直接保存成 .html 文件双击就能跑不需要任何构建工具。这是 DeepSeek 做原型验证最高效的方式想验证一个交互想法是否成立让模型出单文件 HTML浏览器跑一下就知道结果。我在做内部工具原型时经常走这个流程一天能验证七八个想法翻车成本几乎为零。5.3 提示词工程落地到接口参数配置与流式输出前面的例子都在聊提示词内容但真正接入生产环境代码侧还有两个细节不能忽略。第一是响应解析deepseek-reasoner 的响应带 reasoning_content要分字段提取。第二是流式输出长文档生成场景用流式更稳用户能提前看到首屏内容也规避了请求超时。from openai import OpenAI client OpenAI(api_keysk-你的密钥, base_urlhttps://api.deepseek.com) def stream_chat(prompt: str, model: str deepseek-chat): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], streamTrue, temperature0.3 ) collected for chunk in resp: if chunk.choices[0].delta.content: collected chunk.choices[0].delta.content print(chunk.choices[0].delta.content, end) return collected text stream_chat(写一篇 800 字的产品发布公告, deepseek-chat)流式接口有两个注意事项。deepseek-reasoner 使用流式时思考过程会逐段返回调用方需要同时处理 reasoning_content 和 content 两路文本分别拼接否则界面显示会乱。另外流式响应的超时设置要放宽——推理模型的思考时间从几秒到几十秒不等HTTP 客户端的默认超时很容易触发建议设置 120 秒以上。6. 从提示词到智能体Manus 场景下的方法论迁移与输出校验PPT 最后提到了当时爆火的 Manus 智能体。Manus 这类工具的定位是任务代理你给它目标它自己规划步骤、调用工具、处理文件、交付结果。很多人以为智能体时代提示词就不重要了恰恰相反——你给 Manus 的任务描述本质上就是一个超长提示词。六何分析法、Few-shot、分隔符的规则全部适用只是书写对象从对话模型变成了任务代理。6.1 Manus 与 DeepSeek 如何分工Manus 在实际使用中通常扮演编排者DeepSeek 扮演执行者。你向 Manus 描述目标Manus 拆解出子任务再把子任务分发给模型执行。这就要求初始描述必须足够结构化目标是什么、输入数据在哪、输出格式是什么、有哪些限制。我写这类任务描述时直接套用第 3 章的分隔符模板把# 角色换成# 任务目标把# 背景换成# 可用资源。一个典型的写法是# 任务目标分析销售数据并生成月度报告# 可用资源/data/sales_2025.csv包含订单号、金额、日期三列# 输出格式Markdown 报告含数据概览、趋势分析和异常提醒三个部分# 限制不要修改原始数据文件。这些约束写清楚智能体跑出来的结果基本不用二次加工。6.2 输出校验三招交叉提问、反向验证与格式检查智能体自动执行时没有人工干预的机会幻觉风险比单次对话更高。我给自己定了三条铁律全部写进任务描述里。第一交叉提问同一任务用两种措辞各问一次两次结论一致才采信不一致先标红。第二反向验证让模型为自己的结论写出验证过程数值型结论必须给出计算公式和原始数据引用。第三格式检查结构化输出必须过 JSON Schema 校验失败自动重试最多三次。这些规则写进智能体的任务描述比事后人工校对省力得多。智能体的优势是自动执行劣势是错误也会自动放大所以提示词里加验证环节是必须的。特别是涉及金额、日期、数量这类可校验字段的场景交叉提问基本能挡住大部分数据层面的幻觉。从那以后我每次用 DeepSeek 生成重要内容都强制走一遍提示词设计 → 生成 → 校验 → 修正的闭环尤其是幻觉校验那一步从不跳过。这个习惯帮我省下的返工时间远远超过写提示词本身花费的时间。希望帮到你。本文还有配套的精品资源点击获取