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 Thought，CoT）分析问题，界面上通常显示"思考中..."，输出时也会附带解题思路。DeepSeek-V3 则属于非推理型，和 GPT-4.5 这类模型类似，响应速度极快，像知识渊博的老朋友直接给出答案，没有那层"草稿纸"演算过程。

很多人以为推理型和非推理型只是"多想一步"和"少想一步"的区别，实际差别远不止速度。推理模型把你的提示词当题面，自己在草稿纸上往下推演，它关注的是"题目本身是什么"；非推理模型则直接从训练过的知识里做模式匹配，你说的每句话都是检索线索。同一段提示词在这两类模型眼里，信息权重完全不同。

这就解释了为什么在 R1 上照搬 V3 的提示词容易翻车：V3 需要你把背景、角色、格式细节全部填满，R1 反而会被这些冗余信息干扰，甚至出现过度解释。PPT 里的对照表讲得很清晰，我直接摘出来：

这张表是整份 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_key="sk-你的密钥", base_url="https://api.deepseek.com" ) def ask_deepseek(model: str, prompt: str, temperature: float = 0.2): resp = client.chat.completions.create( model=model, # "deepseek-reasoner" 或 "deepseek-chat" messages=[{"role": "user", "content": prompt}], temperature=temperature, max_tokens=4096 ) 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.04，Python 3.10，pandas 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 lang="zh-CN"> <head> <meta charset="UTF-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 id="countdown">02: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_key="sk-你的密钥", base_url="https://api.deepseek.com") def stream_chat(prompt: str, model: str = "deepseek-chat"): resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], stream=True, temperature=0.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 生成重要内容，都强制走一遍"提示词设计 → 生成 → 校验 → 修正"的闭环，尤其是幻觉校验那一步，从不跳过。这个习惯帮我省下的返工时间，远远超过写提示词本身花费的时间。希望帮到你。

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