简介这份PDF资料面向希望系统掌握DeepSeek的普通用户与内容创作者覆盖从注册使用到高阶提示词设计的完整路径。内容围绕智能问答、内容生成、数据分析、任务管理与学习助手等核心功能展开并延伸到日常生活、家庭育儿、职业发展与个人投资等7大场景配套50余个具体案例与三段式、BROKE、COAST等提示词模版还涉及与即梦图像生成器、Mermaid图表工具、硅基流API的联合使用方式。资源包为1个PDF文件共112页大小约11.48MB目录按功能认知、提示词技巧、场景应用分层组织便于按需查阅。目前已有537人学习。读者可借此快速建立提示词思维掌握演讲稿撰写、旅游攻略制定、会议纪要整理、单词记忆、投资策略分析等实操方法并了解复杂文本处理与敏感话题下的使用边界。1. 112页干货拆开看DeepSeek 7大场景50大案例到底在解决什么问题很多人第一次看到“112页DeepSeek 7大场景50大案例全套提示词”这类标题第一反应是收藏第二反应是吃灰。我一开始也这样直到有次赶一个智能问答的内部工具deadline 压到三天才逼着自己把这套东西拆成能跑的结构。拆完发现它真正值钱的不是那 112 页而是背后那套“场景 → 案例 → 提示词”的三层组织方式7 大场景负责圈定边界50 个案例负责给出可抄的输入输出样例全套提示词负责把大模型的随机性压到可复现。这套结构对做 AI 工具、智能问答、内容生成的人特别友好因为它把“提示词工程”从玄学拉回到了工程。下面我就按自己落地的顺序把 DeepSeek 从入门到精通这条路上真正要动手的部分讲清楚包括怎么选场景、怎么写提示词、怎么调 API、怎么避坑以及最后怎么验证效果。适合已经会用 DeepSeek 聊天、但想把它接进自己业务流程的从业者也适合刚接触大模型提示词、想找一套能照着练的框架的新手。2. 把 7 大场景拆成可执行清单先定边界再写提示词2.1 7 大场景的常见划分与选型理由虽然我手里没有那份 112 页的原稿但按一线做 DeepSeek 落地的常见做法7 大场景基本会覆盖这几类智能问答与知识库、内容创作与改写、代码辅助与审查、数据分析与报表解读、办公文档处理、营销文案与电商详情、教育辅导与题目解析。这个划分不是拍脑袋它对应的是大模型能力边界最清晰、最容易做出稳定效果的几个方向。选场景的核心原则是输入输出格式越固定提示词越容易写稳越依赖实时事实或复杂推理越要谨慎。比如智能问答适合接 RAG代码辅助适合给足上下文和约束营销文案适合给风格样例。我一般会先拿一个场景做最小闭环跑通再复制到其他场景而不是七个一起上。2.2 用一张场景-输入-输出表锁定需求动手前先填一张表把每个场景的输入类型、输出格式、失败容忍度写清楚。这张表直接决定后面提示词怎么写、参数怎么设。场景典型输入期望输出失败容忍度是否需外部知识智能问答用户自然语言问题带出处的答案低是建议 RAG内容创作主题风格要求成稿段落中否代码辅助代码片段报错修改建议解释低否数据分析表格问题结论计算过程中否办公文档长文指令摘要/改写中否营销文案产品卖点多版本文案高否教育辅导题目学生答案分步讲解中否填完这张表你会发现失败容忍度低的场景必须加校验步骤比如智能问答要给出处、代码辅助要跑测试。这一步不做后面提示词写得再漂亮也会翻车。2.3 从 50 个案例里挑出可复用的 5 个模板50 个案例不用全看按“输入输出结构”归类通常能收敛到 5 类模板分类模板、抽取模板、生成模板、改写模板、推理模板。每类挑一个案例改造成自己的。比如抽取模板原案例可能是从简历里抽技能你改成从合同里抽条款结构不变。我一般会把这 5 个模板存成独立文件每个文件里放角色设定、任务描述、输入占位符、输出格式、一个正例、一个反例。这样后面调 API 时直接读文件拼 prompt不用每次重写。# 以抽取模板为例保存为 prompt_extract.txt # 角色你是一名信息抽取助手 # 任务从下面的文本中抽取{字段列表}以 JSON 输出 # 输入{text} # 输出格式{字段名: 值} # 正例输入张三电话13800000000 → {姓名:张三,电话:13800000000} # 反例不要输出解释不要输出多余文字逻辑说明把角色、任务、输入、输出、正反例固定成模板变量用花括号占位。参数说明{字段列表}和{text}是运行时替换的正反例用来约束模型不要自由发挥。这个模板跑通后换字段就能复用到其他抽取任务。3. 全套提示词怎么写才不玄学角色、约束、格式三件套3.1 提示词工程与上下文工程的区别很多人把提示词工程和上下文工程混着说其实落地时区别很大。提示词工程管的是“这一次怎么问”上下文工程管的是“模型能看到什么”。DeepSeek 这类大模型单轮提示词写得再好如果上下文里塞了一堆无关内容效果照样崩。我一般把上下文分成三层系统层放角色和全局约束任务层放当前指令和样例数据层放检索到的或用户输入的内容。三层之间用明确分隔符隔开比如### 系统、### 任务、### 数据。这样模型不容易把数据和指令搞混也方便排查是哪一层出了问题。3.2 角色设定、约束条件、输出格式的写法角色设定不要写“你是一个 helpful assistant”太泛。要写具体身份和边界比如“你是一名有 10 年经验的合同审查律师只依据中国法律不确定的条款必须标注‘需人工复核’”。约束条件要可检查比如“输出不超过 200 字”“必须用 JSON”“禁止使用‘可能’‘也许’这类模糊词”。输出格式最好给一个空模板让模型填空而不是让它自由生成。我常用的结构是### 系统 你是{角色}只做{任务范围}超出范围回答“不在服务范围”。 ### 任务 根据### 数据中的内容完成{具体动作}。 ### 约束 1. 输出格式为 JSON字段为{字段列表} 2. 不确定的字段填 null不要编造 3. 不要输出任何解释性文字 ### 数据 {用户输入}逻辑说明系统层锁角色和范围任务层说清动作约束层把可检查的规则列出来数据层放原始输入。参数说明{角色}、{任务范围}、{具体动作}、{字段列表}按场景替换。这个结构在智能问答和抽取任务里特别稳因为模型没有空间去“发挥”。3.3 用 few-shot 样例压住输出波动DeepSeek 对 few-shot 样例很敏感给一两个正例就能明显压住波动。但样例不是越多越好超过 5 个反而容易让模型照抄样例内容。我一般给 2 个正例加 1 个反例反例用来告诉模型“不要这样”。样例要覆盖边界情况比如空输入、超长输入、格式错误的输入。下面是一个分类任务的 few-shot 写法prompt ### 系统 你是一个文本分类器只输出类别标签不输出其他内容。 ### 类别 咨询、投诉、建议、其他 ### 样例 输入你们这个功能怎么用 → 咨询 输入我买的商品坏了没人管 → 投诉 输入希望增加夜间模式。 → 建议 输入今天天气不错。 → 其他 ### 任务 输入{user_input} 输出 逻辑说明样例覆盖了四个类别最后一个“其他”用来兜底。参数说明{user_input}是运行时替换的用户输入。注意样例里的输入要短、要典型不要用真实业务数据避免泄露。这个 prompt 跑分类任务准确率比零样本高不少而且输出稳定。4. 从聊天到 APIDeepSeek 本地部署与接口调用的落地步骤4.1 本地部署的常见路径与硬件门槛想把 DeepSeek 接进内部系统常见做法有两种调云端 API或者本地部署。本地部署适合数据不能出内网的场景但硬件门槛不低。按我踩过的坑7B 级别的模型量化后大概需要 8GB 显存14B 需要 16GB 以上再大就要多卡。部署工具常见的是 Ollama、vLLM、llama.cpp 这几类。Ollama 最省事适合快速验证vLLM 吞吐高适合做服务llama.cpp 适合 CPU 或低显存环境。我一般先用 Ollama 跑通确认提示词效果再换 vLLM 上生产。下面是一个 Ollama 拉取和运行的例子# 拉取 DeepSeek 模型具体 tag 以实际可用为准 ollama pull deepseek-r1:7b # 运行并进入交互 ollama run deepseek-r1:7b # 以服务方式启动供 API 调用 ollama serve逻辑说明ollama pull下载模型ollama run进入交互测试ollama serve启动本地 HTTP 服务默认端口 11434。参数说明模型 tag 按显存选7b 适合 8GB 显存量化版本更省。注意本地部署的模型能力通常弱于云端满血版提示词要写得更细约束要更硬。4.2 调用 DeepSeek API 的最小可用代码如果数据可以出内网调 API 是最省事的。常见做法是用 OpenAI 兼容的接口格式把 base_url 指向 DeepSeek 的地址。下面是一个 Python 最小调用示例import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com # 以实际文档为准 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一名严谨的合同审查助手只依据中国法律。}, {role: user, content: 请审查以下条款并指出风险点{条款内容}} ], temperature0.2, max_tokens800 ) print(resp.choices[0].message.content)逻辑说明system消息放角色和全局约束user消息放具体任务。temperature设低是为了稳定max_tokens控制成本和长度。参数说明api_key从环境变量读不要硬编码base_url和model以官方文档为准temperature在抽取、分类任务里建议 0~0.3在创作任务里可以到 0.7~1.0。这个代码跑通后把messages换成前面写的模板就能复用到各个场景。4.3 参数怎么调temperature、top_p、max_tokens 的取舍这三个参数是调 API 时最常动的。temperature控制随机性越低越确定top_p控制候选词范围一般和 temperature 二选一调max_tokens控制输出长度设太小会截断设太大浪费。我的经验是抽取、分类、代码审查用 temperature 0~0.2top_p 0.9内容创作、营销文案用 temperature 0.7~1.0top_p 0.95智能问答用 temperature 0.3top_p 0.9。max_tokens按任务预估比如摘要给 300长文给 2000。调完记得固定下来写进配置文件不要每次手改。5. 避坑与排查DeepSeek 提示词落地最常见的 5 个翻车现场5.1 输出格式忽好忽坏JSON 解析频繁失败现象同样的提示词有时输出标准 JSON有时前面带一句“好的以下是结果”导致解析报错。原因模型把解释性文字当成了任务的一部分约束不够硬。解决在系统层加“只输出 JSON不要任何解释”在约束层加“第一个字符必须是 {最后一个字符必须是 }”并在代码里做容错比如用正则先提取花括号内容再解析。如果还不行加一个反例明确写“不要输出‘好的’‘以下是’”。5.2 长文本输入被截断关键信息丢失现象输入一份长合同或长报告模型回答漏掉了后面的条款。原因模型有上下文窗口限制超长输入会被截断或者注意力被前面内容分散。解决先做分块把长文本按段落切分每块单独处理再汇总或者用检索的方式只把相关段落塞进上下文。我一般会先算 token 数超过窗口的 70% 就分块。分块时保留重叠部分避免切断关键句。5.3 模型编造事实智能问答给出假出处现象问一个内部知识库里的问题模型给了一个看起来很像但实际不存在的文档编号。原因模型在缺乏依据时会“补全”这是大模型的通病。解决在提示词里加“只依据### 数据中的内容回答数据中没有的写‘未找到’”并且在数据层给出明确出处。如果做 RAG检索结果要带原文片段和来源让模型引用。另外temperature 调低也能减少编造。5.4 本地部署显存爆了服务起不来现象ollama run或 vLLM 启动时报 OOM或者跑几个请求就崩。原因模型太大、量化不够、并发太高。解决换更小的量化版本比如 4bit 量化限制并发数用 vLLM 的gpu_memory_utilization参数控制显存占用。如果还是不够考虑 CPU 推理或换更小的模型。我一般会先跑一个请求测显存再逐步加并发。5.5 提示词越写越长效果反而变差现象为了覆盖各种情况提示词写到上千字结果模型开始忽略部分约束。原因上下文里指令太多模型注意力被稀释而且互相冲突的约束会让它无所适从。解决把提示词拆成系统层和任务层系统层只放全局不变的约束任务层放当前指令。冲突的约束要合并或删掉。我一般会把提示词控制在 500 字以内超过就考虑拆成多轮调用。6. 验证与进阶用一套评分表把提示词效果量化提示词写完不是结束得验证。我一般会建一个小测试集每个场景 20~50 条覆盖正常、边界、异常输入。然后按四个维度打分格式正确率、内容准确率、约束遵守率、响应时间。格式正确率看输出能不能直接解析内容准确率看关键信息对不对约束遵守率看有没有违反禁止项响应时间看是否满足业务要求。下面是一个简单的评分表维度计算方式合格线优化方向格式正确率可解析条数/总条数≥95%加约束、加反例内容准确率关键信息正确条数/总条数≥85%补样例、调 temperature约束遵守率未违反禁止项条数/总条数≥98%系统层强化响应时间平均耗时按业务定换模型、减 max_tokens跑完评分表你会清楚知道哪条提示词该改哪里。我自己的习惯是每次改提示词都跑一遍测试集记录分数不要凭感觉。另外DeepSeek 这类模型更新较快提示词效果可能随版本变化所以测试集要保留换模型时重跑。进阶用法上可以试试把多个提示词串成工作流比如先抽取再分类再生成每步单独校验。也可以把提示词和 RAG 结合用检索结果约束生成。最后说一句血泪经验别指望一套提示词打天下场景变了、数据变了、模型变了提示词就得跟着调。把测试集和评分表建起来比收藏 112 页干货有用得多。希望帮到你。本文还有配套的精品资源点击获取
DeepSeek 7大场景+50大案例：从提示词工程到API落地的实战指南
简介这份PDF资料面向希望系统掌握DeepSeek的普通用户与内容创作者覆盖从注册使用到高阶提示词设计的完整路径。内容围绕智能问答、内容生成、数据分析、任务管理与学习助手等核心功能展开并延伸到日常生活、家庭育儿、职业发展与个人投资等7大场景配套50余个具体案例与三段式、BROKE、COAST等提示词模版还涉及与即梦图像生成器、Mermaid图表工具、硅基流API的联合使用方式。资源包为1个PDF文件共112页大小约11.48MB目录按功能认知、提示词技巧、场景应用分层组织便于按需查阅。目前已有537人学习。读者可借此快速建立提示词思维掌握演讲稿撰写、旅游攻略制定、会议纪要整理、单词记忆、投资策略分析等实操方法并了解复杂文本处理与敏感话题下的使用边界。1. 112页干货拆开看DeepSeek 7大场景50大案例到底在解决什么问题很多人第一次看到“112页DeepSeek 7大场景50大案例全套提示词”这类标题第一反应是收藏第二反应是吃灰。我一开始也这样直到有次赶一个智能问答的内部工具deadline 压到三天才逼着自己把这套东西拆成能跑的结构。拆完发现它真正值钱的不是那 112 页而是背后那套“场景 → 案例 → 提示词”的三层组织方式7 大场景负责圈定边界50 个案例负责给出可抄的输入输出样例全套提示词负责把大模型的随机性压到可复现。这套结构对做 AI 工具、智能问答、内容生成的人特别友好因为它把“提示词工程”从玄学拉回到了工程。下面我就按自己落地的顺序把 DeepSeek 从入门到精通这条路上真正要动手的部分讲清楚包括怎么选场景、怎么写提示词、怎么调 API、怎么避坑以及最后怎么验证效果。适合已经会用 DeepSeek 聊天、但想把它接进自己业务流程的从业者也适合刚接触大模型提示词、想找一套能照着练的框架的新手。2. 把 7 大场景拆成可执行清单先定边界再写提示词2.1 7 大场景的常见划分与选型理由虽然我手里没有那份 112 页的原稿但按一线做 DeepSeek 落地的常见做法7 大场景基本会覆盖这几类智能问答与知识库、内容创作与改写、代码辅助与审查、数据分析与报表解读、办公文档处理、营销文案与电商详情、教育辅导与题目解析。这个划分不是拍脑袋它对应的是大模型能力边界最清晰、最容易做出稳定效果的几个方向。选场景的核心原则是输入输出格式越固定提示词越容易写稳越依赖实时事实或复杂推理越要谨慎。比如智能问答适合接 RAG代码辅助适合给足上下文和约束营销文案适合给风格样例。我一般会先拿一个场景做最小闭环跑通再复制到其他场景而不是七个一起上。2.2 用一张场景-输入-输出表锁定需求动手前先填一张表把每个场景的输入类型、输出格式、失败容忍度写清楚。这张表直接决定后面提示词怎么写、参数怎么设。场景典型输入期望输出失败容忍度是否需外部知识智能问答用户自然语言问题带出处的答案低是建议 RAG内容创作主题风格要求成稿段落中否代码辅助代码片段报错修改建议解释低否数据分析表格问题结论计算过程中否办公文档长文指令摘要/改写中否营销文案产品卖点多版本文案高否教育辅导题目学生答案分步讲解中否填完这张表你会发现失败容忍度低的场景必须加校验步骤比如智能问答要给出处、代码辅助要跑测试。这一步不做后面提示词写得再漂亮也会翻车。2.3 从 50 个案例里挑出可复用的 5 个模板50 个案例不用全看按“输入输出结构”归类通常能收敛到 5 类模板分类模板、抽取模板、生成模板、改写模板、推理模板。每类挑一个案例改造成自己的。比如抽取模板原案例可能是从简历里抽技能你改成从合同里抽条款结构不变。我一般会把这 5 个模板存成独立文件每个文件里放角色设定、任务描述、输入占位符、输出格式、一个正例、一个反例。这样后面调 API 时直接读文件拼 prompt不用每次重写。# 以抽取模板为例保存为 prompt_extract.txt # 角色你是一名信息抽取助手 # 任务从下面的文本中抽取{字段列表}以 JSON 输出 # 输入{text} # 输出格式{字段名: 值} # 正例输入张三电话13800000000 → {姓名:张三,电话:13800000000} # 反例不要输出解释不要输出多余文字逻辑说明把角色、任务、输入、输出、正反例固定成模板变量用花括号占位。参数说明{字段列表}和{text}是运行时替换的正反例用来约束模型不要自由发挥。这个模板跑通后换字段就能复用到其他抽取任务。3. 全套提示词怎么写才不玄学角色、约束、格式三件套3.1 提示词工程与上下文工程的区别很多人把提示词工程和上下文工程混着说其实落地时区别很大。提示词工程管的是“这一次怎么问”上下文工程管的是“模型能看到什么”。DeepSeek 这类大模型单轮提示词写得再好如果上下文里塞了一堆无关内容效果照样崩。我一般把上下文分成三层系统层放角色和全局约束任务层放当前指令和样例数据层放检索到的或用户输入的内容。三层之间用明确分隔符隔开比如### 系统、### 任务、### 数据。这样模型不容易把数据和指令搞混也方便排查是哪一层出了问题。3.2 角色设定、约束条件、输出格式的写法角色设定不要写“你是一个 helpful assistant”太泛。要写具体身份和边界比如“你是一名有 10 年经验的合同审查律师只依据中国法律不确定的条款必须标注‘需人工复核’”。约束条件要可检查比如“输出不超过 200 字”“必须用 JSON”“禁止使用‘可能’‘也许’这类模糊词”。输出格式最好给一个空模板让模型填空而不是让它自由生成。我常用的结构是### 系统 你是{角色}只做{任务范围}超出范围回答“不在服务范围”。 ### 任务 根据### 数据中的内容完成{具体动作}。 ### 约束 1. 输出格式为 JSON字段为{字段列表} 2. 不确定的字段填 null不要编造 3. 不要输出任何解释性文字 ### 数据 {用户输入}逻辑说明系统层锁角色和范围任务层说清动作约束层把可检查的规则列出来数据层放原始输入。参数说明{角色}、{任务范围}、{具体动作}、{字段列表}按场景替换。这个结构在智能问答和抽取任务里特别稳因为模型没有空间去“发挥”。3.3 用 few-shot 样例压住输出波动DeepSeek 对 few-shot 样例很敏感给一两个正例就能明显压住波动。但样例不是越多越好超过 5 个反而容易让模型照抄样例内容。我一般给 2 个正例加 1 个反例反例用来告诉模型“不要这样”。样例要覆盖边界情况比如空输入、超长输入、格式错误的输入。下面是一个分类任务的 few-shot 写法prompt ### 系统 你是一个文本分类器只输出类别标签不输出其他内容。 ### 类别 咨询、投诉、建议、其他 ### 样例 输入你们这个功能怎么用 → 咨询 输入我买的商品坏了没人管 → 投诉 输入希望增加夜间模式。 → 建议 输入今天天气不错。 → 其他 ### 任务 输入{user_input} 输出 逻辑说明样例覆盖了四个类别最后一个“其他”用来兜底。参数说明{user_input}是运行时替换的用户输入。注意样例里的输入要短、要典型不要用真实业务数据避免泄露。这个 prompt 跑分类任务准确率比零样本高不少而且输出稳定。4. 从聊天到 APIDeepSeek 本地部署与接口调用的落地步骤4.1 本地部署的常见路径与硬件门槛想把 DeepSeek 接进内部系统常见做法有两种调云端 API或者本地部署。本地部署适合数据不能出内网的场景但硬件门槛不低。按我踩过的坑7B 级别的模型量化后大概需要 8GB 显存14B 需要 16GB 以上再大就要多卡。部署工具常见的是 Ollama、vLLM、llama.cpp 这几类。Ollama 最省事适合快速验证vLLM 吞吐高适合做服务llama.cpp 适合 CPU 或低显存环境。我一般先用 Ollama 跑通确认提示词效果再换 vLLM 上生产。下面是一个 Ollama 拉取和运行的例子# 拉取 DeepSeek 模型具体 tag 以实际可用为准 ollama pull deepseek-r1:7b # 运行并进入交互 ollama run deepseek-r1:7b # 以服务方式启动供 API 调用 ollama serve逻辑说明ollama pull下载模型ollama run进入交互测试ollama serve启动本地 HTTP 服务默认端口 11434。参数说明模型 tag 按显存选7b 适合 8GB 显存量化版本更省。注意本地部署的模型能力通常弱于云端满血版提示词要写得更细约束要更硬。4.2 调用 DeepSeek API 的最小可用代码如果数据可以出内网调 API 是最省事的。常见做法是用 OpenAI 兼容的接口格式把 base_url 指向 DeepSeek 的地址。下面是一个 Python 最小调用示例import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com # 以实际文档为准 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一名严谨的合同审查助手只依据中国法律。}, {role: user, content: 请审查以下条款并指出风险点{条款内容}} ], temperature0.2, max_tokens800 ) print(resp.choices[0].message.content)逻辑说明system消息放角色和全局约束user消息放具体任务。temperature设低是为了稳定max_tokens控制成本和长度。参数说明api_key从环境变量读不要硬编码base_url和model以官方文档为准temperature在抽取、分类任务里建议 0~0.3在创作任务里可以到 0.7~1.0。这个代码跑通后把messages换成前面写的模板就能复用到各个场景。4.3 参数怎么调temperature、top_p、max_tokens 的取舍这三个参数是调 API 时最常动的。temperature控制随机性越低越确定top_p控制候选词范围一般和 temperature 二选一调max_tokens控制输出长度设太小会截断设太大浪费。我的经验是抽取、分类、代码审查用 temperature 0~0.2top_p 0.9内容创作、营销文案用 temperature 0.7~1.0top_p 0.95智能问答用 temperature 0.3top_p 0.9。max_tokens按任务预估比如摘要给 300长文给 2000。调完记得固定下来写进配置文件不要每次手改。5. 避坑与排查DeepSeek 提示词落地最常见的 5 个翻车现场5.1 输出格式忽好忽坏JSON 解析频繁失败现象同样的提示词有时输出标准 JSON有时前面带一句“好的以下是结果”导致解析报错。原因模型把解释性文字当成了任务的一部分约束不够硬。解决在系统层加“只输出 JSON不要任何解释”在约束层加“第一个字符必须是 {最后一个字符必须是 }”并在代码里做容错比如用正则先提取花括号内容再解析。如果还不行加一个反例明确写“不要输出‘好的’‘以下是’”。5.2 长文本输入被截断关键信息丢失现象输入一份长合同或长报告模型回答漏掉了后面的条款。原因模型有上下文窗口限制超长输入会被截断或者注意力被前面内容分散。解决先做分块把长文本按段落切分每块单独处理再汇总或者用检索的方式只把相关段落塞进上下文。我一般会先算 token 数超过窗口的 70% 就分块。分块时保留重叠部分避免切断关键句。5.3 模型编造事实智能问答给出假出处现象问一个内部知识库里的问题模型给了一个看起来很像但实际不存在的文档编号。原因模型在缺乏依据时会“补全”这是大模型的通病。解决在提示词里加“只依据### 数据中的内容回答数据中没有的写‘未找到’”并且在数据层给出明确出处。如果做 RAG检索结果要带原文片段和来源让模型引用。另外temperature 调低也能减少编造。5.4 本地部署显存爆了服务起不来现象ollama run或 vLLM 启动时报 OOM或者跑几个请求就崩。原因模型太大、量化不够、并发太高。解决换更小的量化版本比如 4bit 量化限制并发数用 vLLM 的gpu_memory_utilization参数控制显存占用。如果还是不够考虑 CPU 推理或换更小的模型。我一般会先跑一个请求测显存再逐步加并发。5.5 提示词越写越长效果反而变差现象为了覆盖各种情况提示词写到上千字结果模型开始忽略部分约束。原因上下文里指令太多模型注意力被稀释而且互相冲突的约束会让它无所适从。解决把提示词拆成系统层和任务层系统层只放全局不变的约束任务层放当前指令。冲突的约束要合并或删掉。我一般会把提示词控制在 500 字以内超过就考虑拆成多轮调用。6. 验证与进阶用一套评分表把提示词效果量化提示词写完不是结束得验证。我一般会建一个小测试集每个场景 20~50 条覆盖正常、边界、异常输入。然后按四个维度打分格式正确率、内容准确率、约束遵守率、响应时间。格式正确率看输出能不能直接解析内容准确率看关键信息对不对约束遵守率看有没有违反禁止项响应时间看是否满足业务要求。下面是一个简单的评分表维度计算方式合格线优化方向格式正确率可解析条数/总条数≥95%加约束、加反例内容准确率关键信息正确条数/总条数≥85%补样例、调 temperature约束遵守率未违反禁止项条数/总条数≥98%系统层强化响应时间平均耗时按业务定换模型、减 max_tokens跑完评分表你会清楚知道哪条提示词该改哪里。我自己的习惯是每次改提示词都跑一遍测试集记录分数不要凭感觉。另外DeepSeek 这类模型更新较快提示词效果可能随版本变化所以测试集要保留换模型时重跑。进阶用法上可以试试把多个提示词串成工作流比如先抽取再分类再生成每步单独校验。也可以把提示词和 RAG 结合用检索结果约束生成。最后说一句血泪经验别指望一套提示词打天下场景变了、数据变了、模型变了提示词就得跟着调。把测试集和评分表建起来比收藏 112 页干货有用得多。希望帮到你。本文还有配套的精品资源点击获取
