简介北京大学DeepSeek系列研讨课件聚焦提示词工程与落地场景面向零技术背景的普通用户、AI爱好者与培训讲师。内容围绕DeepSeek-R1的推理能力、开源低成本国产化优势展开介绍模型思考过程可视化、训练成本与推理成本降低等关键突破并梳理官方网页、手机应用与接口调用三种使用途径。重点讲解提示词技巧覆盖教育、金融、医疗等垂直领域与日常生活场景帮助读者避开常见误读掌握简单有效的交互方法。资源共1个pptx演示文稿容量约808KB内含讲座目标、目录、原理拆解、使用方式与场景案例等完整模块便于直接参考或二次整理。已有376人浏览学习适合希望快速上手并落地应用DeepSeek的各类人群。1. 为什么提示词工程在 DeepSeek 上是刚需而不是加分项开门见山标题里的“提示词工程和落地场景”其实说的是同一件事——如果你拿到了 DeepSeek 这杆好枪提示词就是膛线。同样是调用同一个模型接口有人三行提示词拿到结构化的 JSON有人写一大段描述拿到一篇正确的废话。原因不只在模型而在你把意图翻译成指令的能力。提示词工程Prompt Engineering就是这套翻译方法论怎么设角色、怎么下指令、怎么给约束、怎么放示例让 DeepSeek 一次到位而不是你来来回回打补丁。这篇文章写给两类人一类是用 DeepSeek API 做应用或自动化流程的开发者一类是天天泡在对话界面里写文案、改代码、抽数据的运营和产品。下面不聊玄学只聊能复现的套路、参数和踩过的坑。2. 结构化提示词的四块地基角色、指令、约束、示例2.1 角色设定为什么排在第一位DeepSeek 这类指令模型的输出风格很大程度上由 system prompt 里的角色决定。常见做法是在 API 调用时先给系统消息立人设而不是让用户消息直接裸奔。from openai import OpenAI client OpenAI( api_key你的DeepSeek API Key, base_urlhttps://api.deepseek.com/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一名资深Python后端工程师擅长写生产可用的代码输出代码必须包含异常处理和类型注解。}, {role: user, content: 写一个从CSV批量读取数据并写入SQLite的函数。} ], temperature0.3 ) print(resp.choices[0].message.content)这里 base_url 是 DeepSeek 兼容 OpenAI 的接口路径api_key 从开放平台控制台复制。system 消息里“资深 Python 后端工程师”是角色后面两句话是约束条件的预埋——异常处理和类型注解——这两点会在生成代码时被模型当作默认要求执行。如果不设角色同一个提问可能得到教学风格的演示代码而不是生产可用代码这是新手最容易忽略的差别。2.2 指令清晰化动词开头、分步编号、指明输出格式一段合格的用户指令应该是可以直接执行的操作列表而不是散文。指令的写法遵循三条规则每条指令以具体动词开头生成、改写、提取、比较、翻译、压缩复杂任务拆成带编号的步骤让模型逐步执行最后显式声明输出格式Markdown 表格、JSON、代码块、纯文本请按以下步骤处理用户输入的日志文本 1. 提取所有包含 ERROR 或 WARN 的行保留原始时间戳 2. 按时间戳排序 3. 统计每个模块的 ERROR 出现次数 4. 以 Markdown 表格输出模块名、错误次数、示例行最多3条 以下是日志文本 [输入日志]把这套指令模板用起来之后输出的解析成本会明显下降。原因在于 DeepSeek 对“先做什么、再做什么”的显式步骤敏感度很高分步编号相当于给模型一条推理路径避免它在中间步骤跳步。很多人在 Chat 界面里翻车的场景——让它分析日志它直接给结论不给过程——就是因为指令里没有步骤感。实际测试里同一个日志分析任务分行编号的 prompt 比整段描述的 prompt 在格式合规率上高出不少这是一笔稳赚的改造。2.3 约束条件是模型的安全带约束条件通常放在指令尾部格式类似“不得……”“必须……”“如果……则……”。约束不是越多越好关键约束写三条以内写太多模型会顾此失彼。常见的有效约束长度约束输出控制在 500 字以内代码只输出函数体不输出解释内容约束不编造数据每条结论标注置信度结构约束只输出 JSON不要 Markdown字段名必须与给定的 schema 一致一个必须注意的边界约束和“破甲词”不是一回事。网上流传的各种所谓“无限制词、破甲词”是在诱导模型绕过自身的安全规则生产环境里沾这个轻则输出不可控重则账号被封完全没必要。规则设定要做的是让模型在合理范围内输出更规范而不是去挑战模型的底线。把“输出禁止包含敏感建议”“无法回答时明确说不知道”这类约束写清楚比任何花哨的越狱词都更能提升可用性。2.4 示例few-shot比描述更管用模型对“像这样”的理解远好于“要那样”。给一到三个输入输出对很多抽象描述可以省掉。prompt f 任务将用户描述转换成标准JSON字段为name, age, city, job。 示例 输入张三28岁上海程序员 输出{{name: 张三, age: 28, city: 上海, job: 程序员}} 输入王工程师说他住在杭州今年35做安全研究 输出 示例的价值在于让模型对齐“抽取口径”上面例子告诉模型 age 输出数字类型而不是字符串city 提取居住地而不是出生地。实际使用中两个示例比一个示例在稳定性上提升更明显但超过三个示例收益就开始递减可以按这个经验设置。这里有个容易忽略的细节示例要和真实输入的句式接近如果示例全是“某人是某地人”的句式模型对口语化输入的对齐能力就会下降所以示例最好从真实数据里剪几段来用。3. DeepSeek 的 API 参数调优温度、采样和上下文设计3.1 五个必调参数与推荐区间DeepSeek API 兼容 OpenAI 格式常用参数按重要性排序temperature、max_tokens、top_p、frequency_penalty、presence_penalty。下面是我在文本生成和代码生成两种场景里的推荐区间。参数代码生成推荐创意文案推荐说明temperature0.1 ~ 0.30.8 ~ 1.2越低越稳定越高越多样top_p0.5 ~ 0.80.9 ~ 1.0与 temperature 二选一调max_tokens视任务而定视任务而定代码任务要留足余量frequency_penalty0.1 ~ 0.30.3 ~ 0.6抑制重复词presence_penalty00.2 ~ 0.4鼓励新话题注意temperature 和 top_p 不要同时大改保持一个固定、只调另一个更容易判断效果。我一般固定 top_p0.7 只调 temperature因为每次只动一个变量才能定位输出漂移的来源。如果发现代码生成偶尔出现逻辑跳跃先把 temperature 从 0.3 降到 0.1 试试多数情况下问题出现在采样随机性上而不是提示词写得不够好。3.2 上下文窗口用多大、怎么算DeepSeek 支持长上下文但长上下文的真实可用长度受两个因素限制一是输入 token 数会吃成本二是过长的历史信息会稀释当前指令的权重。通用经验是关键指令放在对话的最后离问题最近的位置历史对话按“最近 N 轮”裁剪N 一般取 8 到 15 轮长文档用摘要 原文分块的方式注入不要整篇塞进 contextdef build_messages(system: str, history: list, user: str, max_history: int 10): 裁剪历史对话确保最近指令不被淹没 messages [{role: system, content: system}] messages.extend(history[-max_history:]) messages.append({role: user, content: user}) return messages这个裁剪函数解决“对话到达上限之后怎么让新对话承接上一个对话”的问题把前文历史做摘要压成一条 system 消息带到新对话里旧对话就可以关掉。具体承接方案是新对话的 system prompt 里写入“上一轮我们分析了 XXX结论是 YYY现在继续处理 ZZZ”。这样既绕开了无状态 API 的限制又不丢失关键信息。提示上下文裁剪不是简单的“删掉前面的消息”如果第 N 轮的回复是第 N1 轮提问的前提就要把结论做摘要保留否则新对话里模型会不知道来龙去脉。3.3 接入形态API、本地部署还是走聚合平台三种方式按场景选API 直连适合生产应用成本随量走官方定价体系稳定接入最快vLLM 本地部署适合数据敏感、需要离线运行的场景需要准备显卡和模型权重聚合平台 / 三方网关适合先验证功能、不想折腾部署的阶段用 vLLM 部署 DeepSeek 的常见启动命令这里用通用形式具体模型名和路径以你下载的权重为准pip install vllm vllm serve 你的DeepSeek模型路径 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --served-model-name deepseek-local启动后即获得一个兼容 OpenAI 格式的本地端点base_url 改成 http://localhost:8000/v1 即可。gpu-memory-utilization 0.85 的含义是给 KV Cache 留了更多显存空间上下文越长越需要调大这个值如果部署机器是单卡 24G建议先压到 0.7 避免 OOM等跑顺了再往上加。本地部署的优点是把数据留在内网缺点是版本升级和算子适配要自己维护适合有算法工程师的团队不适合只有应用开发者的团队。这是部署的“后悔药”问题先想清楚运维能力再决定要不要本地化不然权重下载、量化、推理加速每一步都可能翻车。4. 把提示词工程套进三个真实落地场景代码生成、数据抽取、内容去AI味4.1 场景一AI 写代码 规则设定让输出直接可提交程序员用 DeepSeek 写代码最常见的翻车点是“代码能跑但不符合团队规范”。解法是把团队规范写进 system prompt而不是每次在提问里重复。这也正好对应热词里“AI 写代码 规则设定 提示词工程”的组合——规则设定不是临场发挥而是沉淀成固定模板。SYSTEM_CODE_RULES 你是团队里的资深工程师生成代码必须遵守以下规则 1. Python代码必须包含类型注解和docstring 2. 所有文件读写操作必须捕获异常并记录日志 3. 禁止使用全局变量 4. 输出只给代码块不给解释 5. 数据库操作必须使用参数化查询 def generate_code(task_desc: str) - str: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: SYSTEM_CODE_RULES}, {role: user, content: f需求{task_desc}} ], temperature0.2 ) return resp.choices[0].message.content注意 client 沿用前文定义的 DeepSeek 客户端。这套“规则前置 温度压低”的做法就是把规则设定做成团队统一模板。温度 0.2 保证每次生成的结构高度一致规则里第 4 条“只给代码块”是防止模型输出大段解释、污染后续的代码解析流程。如果模型偶尔不遵守第 4 条可以在用户消息末尾追加一句“再次提醒只输出代码不输出任何文字”多数情况下能救回来。更进一步可以在 CI 流程里做一次代码规范检查不通过的输出直接让模型重写形成闭环。4.2 场景二从非结构化文本里抽结构化数据数据抽取场景要求输出严格 JSONprompt 里要给出目标 schema 和填充规则。prompt 从下面的退保工单里抽取字段输出严格JSON不要Markdown不要注释不要多余字段。 schema: { user_name: str|客户姓名, policy_id: str|保单号以字母P开头, reason: str|退保原因40字以内, amount: float|退保金额单位元转成数字 } 工单原文 【客户】李女士来电称因资金周转需要要求退掉保单P20240315保费总额8900.5元希望尽快处理。 输出 输出解析时有一道保险让 API 返回 JSON 后先做 json.loads 校验失败就重试一次并附带错误信息。实际运行里模型偶尔会在 JSON 外套一层代码块标记加一个清洗函数就能解决import json, re def parse_json_response(text: str) - dict: text re.sub(rjson|, , text).strip() try: return json.loads(text) except json.JSONDecodeError: # 截取第一个{到最后一个}之间的内容 obj text[text.index({): text.rindex(}) 1] return json.loads(obj)Prompt 里要求字段名和说明分离能显著降低模型自造字段的概率。清洗函数是兜底真正的主力还是约束写法——“只输出 JSON”这句话要放在指令尾部且独立成句不要和别的约束挤在一起。这是我从多次数据管道事故里总结出来的模型对指令尾部 30 个字左右的注意力最强把最重要的格式要求放在最后一句成功率立刻提升。字段说明里“以字母P开头”也是一种约束它让模型在拿不准时按照前缀规则判断而不是猜。4.3 场景三批量生成内容并去 AI 味热词里“去 AI 意味”是内容运营和报告撰写的高频需求。做法分两步第一步用 DeepSeek 生成初稿第二步用另一个提示词做去 AI 味改写。rewrite_prompt 你是一名有十年行业经验的编辑。请把下面的文本改写成自然的人类写作风格要求 1. 删除所有首先、其次、最后、综上所述等过渡词 2. 打散排比句长短句交错 3. 加入具体细节、数据和口语化表达但不要编造事实 4. 保留原意不增加新观点 5. 输出三段每段不超过120字 原文 [待改写文本] 去 AI 味的核心不是换词而是打散结构。大模型生成文本有强烈的“总分总”倾向找到这种结构并打散比替换任何高频词都有效。运营团队可以把这套改写提示词接到 DeepSeek API 后面做成批量处理脚本。值得提醒的是“去 AI 味”不等于“伪造人类”逻辑上它只是帮你把机械化表达改成自然表达别用它去欺骗需要透明披露的场合。另外改写时让模型充当“编辑”而不是“作者”效果通常更好因为这个角色切换会让模型更倾向于审校和修改而不是从头起草输出会保留更多原文里的信息量。5. 避坑DeepSeek 提示词与落地最常见的 6 个坑5.1 坑一上下文过长导致模型“忘记”最近指令现象把长文档整段塞进上下文之后模型开始答非所问甚至重复文档原文。原因上下文里的关键指令被海量文本稀释注意力权重被文档内容占满。解决把长文档切成 1000~2000 token 的块按块检索后再拼进 prompt同时把指令放在 user 消息的最末尾。如果遇到“对话到达上限之后怎么让新对话承接上一个对话”的问题就用摘要压缩法让 DeepSeek 先把旧对话压缩成 300 字摘要然后在新对话的 system 里引用它让新对话直接建立在上文结论之上。5.2 坑二输出格式不稳定JSON 解析失败现象要求输出 JSON返回了带 Markdown 标记的 JSON或者带注释的 JSON。原因模型的格式服从性受 temperature 影响temperature 过高时格式漂移率明显上升。解决代码生成类任务 temperature 压到 0.2 以下JSON 输出任务额外在 prompt 里标注“不要注释不要 Markdown”并写一个正则兜底函数。升级模型版本后要重新跑一遍格式测试用例因为不同版本对“只输出 JSON”的服从度有差异这是模型迭代带来的不确定性只能靠回归测试去兜住。5.3 坑三规则写了一大堆模型反而变笨现象system prompt 超过 800 字任务越简单模型表现越差。原因约束之间互相矛盾或约束优先级不明确模型在约束上耗费了大量注意力反而不知道哪条是重点。解决把规则分成三档——红色规则必须遵守、黄色规则默认遵守可被用户指令覆盖、蓝色规则风格偏好。红色规则放最前面示例放在后面。我自己的模板里通常红黄蓝各控在 2~3 条效果最稳。规则之间的冲突要在写模板时就排除比如既要求“输出不超过500字”又要求“每条结论都附完整数据表”这两个约束天然矛盾模型只能随机选一个执行。5.4 坑四本地部署的显存和并发估算拍脑袋现象本地部署 DeepSeek 后还没上生产就 OOM或并发一高就排队。原因gpu-memory-utilization 没调好或者没算清 KV Cache 的显存占用。解决先用官方文档里的显存估算公式粗算再按 0.7 的利用率起跑测试后再往上调。vLLM 的日志里会打印 KV Cache Size 和 Max concurrency以它为准逐步加并发。这一步是血泪经验换来的宁可利用率低一点也不要让服务在凌晨三点 OOM 导致整条链路中断。并发压测要在上线前做不要在线上流量高峰时做否则翻车的不只是模型服务还有你的口碑。5.5 坑五提示词模板没有版本管理现象prompt 今天改一点、明天改一点输出风格漂移问题出现后人找不到对应版本。原因prompt 被当成随手写的草稿直接改没有放进 git。解决把每个 prompt 模板建成一个 Python 文件或纯文本文件纳入 git 管理提交信息写明改动内容。模板里用变量替代可变内容固定段落不要复制粘贴。进阶做法是给模板加版本号注释上线前跑一遍基准测试集。这是投入产出比很高的工程习惯比任何单点技巧都值钱因为它让你在模型输出突然变差时有一条回退路径。5.6 坑六拿“破甲”类玩法当落地需求现象网上流传的“无限制词、破甲词”被一部分用户当成提示词工程的进阶技巧甚至试图用它打通内容生产的所谓“边界”。原因混淆了“规则设计”和“规则攻击”的边界。解决这类内容本质是诱导模型越权轻则输出失控重则账号封禁。落地场景里真正需要的是让模型稳定、合规、可审计地完成任务。凡是需要依赖绕过模型底线才能跑通的流程本身就是不该存在的流程直接剪掉。提示词工程的价值在于把模型的表达能力驯化成生产力而不是测试一个黑匣子的底线在哪。这个问题上不要有任何侥幸心理。这六条坑对应“参数怎么设、坑在哪”的诉求。每一条都是我在实际调用里遇到或看到过的按上面办法处理完大多数场景的返工率能降一截。6. 进阶用提示词模板库和链路拆解把单个技巧变成团队资产单个提示词技巧是点落到团队里需要一张网。这里说两个可执行的进阶做法。第一个做法是建立提示词模板库按照任务类型分目录code-generation、data-extraction、content-rewrite、agent-task。每个模板包含三部分prompt 文本、参数配置、测试用例。测试用例是关键——每次修改模板必须跑一遍固定的输入输出对比对输出是否符合预期。只有让模板具有可回归性才能避免“改完一个场景弄坏另一个场景”。我见过太多团队死于 prompt 的“无序改良”最后连前几天能稳定输出的模板都找不回来了。第二个做法是任务链路拆解把一个复杂任务拆成多个模型调用而不是试图用一个大 prompt 一次完成。以“分析用户投诉并生成工单摘要”为例拆成两步第一步用 temperature0.1 抽取事实字段第二步用 temperature0.7 生成摘要文本。事实抽取用低温度保证稳定文案生成用高温度保证自然。这和直接写一个大 prompt 的区别是中间产物可以检查和修正哪一步出问题就重跑哪一步不用从头再来。链路里每一步输出都留一份原始记录作为后续调试的对照样本。验证方法上我留一个习惯每季度把线上跑着的 prompt 全部跑一遍基准测试集用 diff 方式观察输出变化。模型版本更新后这一步尤其重要因为新模型的指令服从度可能和旧模型有差异同样的 prompt 输出风格会漂。这算是给提示词工程留的一个“后悔药”机制——基准测试集就是回退的依据。社区热词里提到的各种 harness、插件类工具本质上也是在帮你做这类过程管理但工具只是外壳先有模板库和链路拆解的思维再用工具承载效率顺序不能颠倒。如果你刚开始做这个方向别急着追新工具链先把第 2 章的四块地基、第 3 章的两个参数区间沉淀下来再挑一个场景跑通闭环。我自己从“随手写 prompt”到“按模板工程化管理”最大的转变就是开始记录每次改动前后模型的输出差异用过一段时间后你会发现提示词工程本质上是把人和模型之间的沟通方式固化下来而不是什么玄学。希望帮到你。本文还有配套的精品资源点击获取