简介：这份PPT源自北京大学DeepSeek系列内部研讨，由北大青鸟人工智能研究院、计算机学院元宇宙技术研究所与教育学院学习科学实验室联合出品，聚焦提示词工程与产业实践两大模块，面向希望无需技术背景即可掌握AI提效路径的高校师生、职场人士与AI应用爱好者。内容系统梳理DeepSeek火爆原因、R1模型思考过程可视化等核心优势、官方APP与网页端及API三种直接使用方式，并直面市场对提示词的常见误读，通过技巧代入教育、金融、医疗等垂直场景，帮助读者突破工具表层应用。资源包共1个pptx文件，约808KB，目录涵盖原因分析、提示词技巧、使用方法与常见应用场景四大板块，结构清晰便于按需查阅。目前已有376人学习，适合作为提示词入门与落地实践的参考课件。
1. 提示词工程落地：从一份课件标题看大模型应用的真实门槛
很多人第一次看到“提示词工程和落地场景”这类课件标题，第一反应是“不就是教怎么写 prompt 吗”。但真正在企业里推过大模型应用的人会告诉你，写 prompt 只是最表层的事。一份讲提示词工程与落地场景的课件，背后要回答的核心问题是：怎么把大模型的输出从“偶尔能用”变成“稳定可交付”。这中间涉及提示词结构设计、输出格式约束、上下文管理、效果评测、成本控制，以及最容易被忽略的——业务场景的拆解与匹配。
这份课件标题里“提示词工程”和“落地场景”是并列关系，说明它不只讲技巧，还讲怎么找到适合大模型切入的业务点。适合读的人群很明确：有一定技术基础、正在或准备把大模型能力接入实际产品的开发者、产品经理和技术负责人。如果你只是想知道“怎么让 ChatGPT 帮我写周报”，那不需要工程化；但如果你要让大模型在客服、数据分析、文档处理、代码辅助等场景里稳定跑起来，提示词工程就是绕不过去的基本功。
2. 提示词工程的核心结构：为什么“好好说话”不够用
2.1 从自然语言指令到结构化提示词模板
大多数人写 prompt 的方式是“把需求用自然语言描述一遍”，这在单次对话里够用，但一旦要批量处理、要集成到系统里、要保证输出格式一致，就完全不够了。工程化的提示词需要结构化，常见做法是把提示词拆成几个固定模块：角色定义、任务描述、输入数据、输出格式约束、示例（few-shot）、边界条件。
我一般会用一个模板骨架来组织：
PROMPT_TEMPLATE = """ # 角色 你是一个{role}，擅长{skill}。 # 任务 {task_description} # 输入 {input_data} # 输出要求 1. 输出格式为 JSON，包含以下字段：{fields} 2. 如果输入信息不足以判断，{field_name} 填 null，不要编造。 3. 不要输出任何解释性文字，只输出 JSON。 # 示例 输入：{example_input} 输出：{example_output} """这个模板的关键在于：角色定义让模型收敛到特定领域语气；任务描述要具体到动作和对象；输出格式约束是工程化的核心，没有它下游代码没法解析；示例用来锚定输出风格和粒度；边界条件用来防止模型“自作聪明”。
参数说明方面，role不要写“助手”这种泛称，要写具体职能，比如“电商评论情感分析器”。fields要和下游消费代码的字段名完全一致，不要中途改。example_output必须是合法 JSON，且字段类型要和真实输出一致，否则模型会模仿错误格式。
2.2 输出格式约束：JSON、XML 还是纯文本
输出格式的选择直接决定下游能不能自动化处理。纯文本适合人看的场景，比如生成摘要、写邮件草稿。JSON 适合结构化数据抽取、分类、信息提取。XML 适合嵌套层级较深、需要保留标签语义的场景，比如文档结构化。
常见做法是：如果下游是代码消费，优先 JSON；如果下游还是人看，但需要一定结构，可以用 Markdown 表格或带标题的纯文本。我一般会在提示词里明确写“只输出 JSON，不要用 markdown 代码块包裹”，因为很多模型默认会加 ```json 包裹，导致解析失败。
import json def parse_model_output(raw: str) -> dict: # 去掉可能的 markdown 代码块包裹 cleaned = raw.strip() if cleaned.startswith("```"): # 去掉第一行和最后一行 lines = cleaned.split("\n") cleaned = "\n".join(lines[1:-1]) try: return json.loads(cleaned) except json.JSONDecodeError as e: # 记录原始输出用于排查 print(f"解析失败，原始输出：{raw[:200]}") raise这段代码的逻辑是：模型输出经常带 markdown 包裹，直接json.loads会翻车。先做清洗再解析，解析失败时打印原始输出前 200 字符，方便定位是格式问题还是模型根本没按格式输出。参数上，raw[:200]的截断长度可以按需调整，但不要打印全量，避免日志爆炸。
2.3 少样本示例的数量与选择策略
Few-shot 示例是提升输出稳定性的有效手段，但不是越多越好。常见经验是 2 到 5 个示例足够，超过 5 个后边际收益递减，而且会占用大量上下文窗口，增加成本。示例的选择要覆盖边界情况：正常输入、空输入、模糊输入、多义输入。
我一般会按这个比例配：2 个正常示例、1 个空输入示例、1 个模糊输入示例。空输入示例告诉模型“信息不足时不要编造”，模糊输入示例告诉模型“不确定时输出 null 或默认值”。这比写一堆“不要幻觉”的指令管用得多，因为示例是行为锚点，指令只是文字要求。
提示：示例的输入输出对必须真实且一致，不要为了凑数编造示例。模型会模仿示例里的错误，比如示例里 JSON 字段名拼错了，输出也会跟着错。
3. 落地场景拆解：哪些业务适合用提示词工程解决
3.1 信息抽取与结构化：从非结构化文本到数据库字段
信息抽取是最容易落地、收益最直接的一类场景。典型需求是：从合同、邮件、工单、评论里提取指定字段，写入数据库或表格。这类场景的特点是输入格式相对固定、输出字段明确、人工规则难以覆盖所有表达方式。
实现路径是：定义目标字段 → 写抽取提示词 → 用少量标注数据做 few-shot → 批量跑 → 人工抽检 → 迭代提示词。关键参数是 temperature 设为 0 或接近 0，保证输出稳定。max_tokens 根据字段数量估算，一般 500 到 1000 够用。
EXTRACT_PROMPT = """ 从以下文本中提取信息，输出 JSON。 字段定义： - company_name: 公司全称，没有则 null - contact_person: 联系人姓名，没有则 null - phone: 联系电话，没有则 null - amount: 金额数字，单位元，没有则 null 文本： {text} 只输出 JSON，不要解释。 """逻辑说明：字段定义要写清楚“没有则 null”，否则模型会编造。金额字段要指定单位，避免模型输出“一万元”这种非数字格式。text变量直接拼接用户输入，注意长度控制，超长文本要先截断或分段。
3.2 分类与打标：多级标签体系的提示词设计
分类场景的难点不在模型能力，而在标签体系的设计。如果标签之间边界模糊，模型输出就会摇摆。常见做法是：先定义一级标签，再定义二级标签，每个标签给一句判定标准，最后用 few-shot 锚定。
我一般会要求输出标签 ID 而不是标签名称，因为名称可能有歧义，ID 是唯一的。同时要求输出置信度，低于阈值的人工复核。这样即使模型不确定，也能通过置信度过滤出来。
CLASSIFY_PROMPT = """ 将以下用户反馈分类到最合适的标签。 标签体系： - L1: 产品质量问题 - L2: 物流配送问题 - L3: 客服服务问题 - L4: 其他 判定标准： - L1: 涉及产品功能、外观、材质、耐用性 - L2: 涉及发货速度、包装破损、配送错误 - L3: 涉及客服态度、响应速度、解决方案 - L4: 无法归入以上任何一类 输出 JSON：{"label": "L1", "confidence": 0.95} 反馈内容：{feedback} """参数说明：confidence是模型自评的置信度，不是真实概率，但可以用来做粗筛。阈值一般设 0.7 到 0.8，低于阈值的走人工。标签数量不要超过 10 个，超过后模型准确率明显下降，需要拆成多级分类。
3.3 内容生成与改写：约束条件下的可控输出
内容生成场景最容易翻车，因为“好”的标准很主观。工程化的做法是把主观标准拆成可检查的约束：字数范围、语气风格、必须包含的关键词、禁止出现的表达、输出结构。
常见做法是：先让模型生成，再用规则或第二个模型做校验，不通过就重试或人工介入。重试时把校验失败的原因拼回提示词，让模型针对性修改。
REWRITE_PROMPT = """ 将以下文本改写成{style}风格。 要求： 1. 字数在{min_words}到{max_words}之间。 2. 必须包含以下关键词：{keywords} 3. 禁止使用以下表达：{forbidden} 4. 保持原意不变，不要添加原文没有的信息。 原文： {original_text} 改写结果： """逻辑说明：style要具体，比如“正式商务”“轻松口语”“技术文档”，不要写“好一点”。keywords和forbidden用列表传入，拼接时用顿号分隔。字数约束要合理，太窄会导致模型反复重试，太宽则失去约束意义。
4. 避坑与排查：提示词工程落地中最容易翻车的五个点
4.1 输出格式不稳定，下游解析频繁失败
现象：模型有时输出 JSON，有时输出 markdown 代码块包裹的 JSON，有时在 JSON 前后加解释文字。
原因：提示词里没有强制约束输出格式，或者约束不够明确。模型在训练时见过大量带解释的输出，默认行为就是“多说几句”。
解决：在提示词里明确写“只输出 JSON，不要输出任何其他文字”，同时在代码侧做容错清洗。如果仍然不稳定，用 few-shot 示例锚定，示例里只放纯 JSON。极端情况下可以用 API 的 response_format 参数强制 JSON 模式（如果模型支持）。
4.2 模型编造不存在的信息
现象：抽取字段时，原文没有的信息被模型“补全”了，比如原文没写电话，输出里却有一个电话号码。
原因：提示词里没有明确“没有则 null”，或者 few-shot 示例里没有空值示例。模型倾向于给出“完整”答案，而不是承认信息缺失。
解决：在字段定义里逐条写“没有则 null”，并加一个空输入示例。同时在代码侧做校验，比如电话号码格式校验，不通过就标记为可疑。对于关键字段，可以要求模型输出原文片段作为证据，没有证据的字段直接丢弃。
4.3 长文本截断导致关键信息丢失
现象：输入文本超过模型上下文窗口，被截断后关键信息丢失，输出结果不完整或错误。
原因：没有做输入长度预估和分段处理。很多开发者直接拼接全文，超出后模型自动截断，但截断位置不可控。
解决：先估算 token 数，超长文本按段落或语义单元分段，每段单独抽取后再合并。合并时注意去重和冲突处理。如果必须整篇处理，用支持长上下文的模型，但仍然要控制输入长度，留出输出空间。
4.4 提示词迭代没有版本管理，效果回退无法定位
现象：改了一版提示词后效果变差，但不知道改了什么，也无法回退到之前可用的版本。
原因：提示词直接写在代码里，改了就覆盖，没有版本记录和效果对比。
解决：把提示词抽成独立文件或配置项，每次修改记录版本号和修改原因。上线前用固定测试集跑一遍，对比准确率、格式合规率等指标。我一般会用简单的表格记录：版本号、修改内容、测试集准确率、上线时间。这样出问题能快速回退。
4.5 忽略成本与延迟，批量任务跑不起
现象：单次调用效果很好，但批量跑几千条时成本超预算，或者延迟太高无法接受。
原因：没有估算 token 消耗和调用次数。few-shot 示例太长、输出 max_tokens 设太大、重试次数过多都会推高成本。
解决：先算一笔账：单次输入 token 数 × 调用次数 × 单价。优化方向包括：压缩 few-shot 示例、缩短输出长度、合并批量请求、用更小的模型处理简单任务。延迟方面，可以并发调用，但要注意速率限制。我一般会先跑 100 条做成本预估，再决定是否全量上线。
5. 效果验证与迭代：怎么判断提示词方案值不值得继续投入
5.1 用固定测试集做回归验证
提示词工程最怕“感觉还行”。我一般会先建一个 50 到 100 条的测试集，覆盖正常、边界、异常三类输入，人工标注正确答案。每次改提示词后跑一遍，看准确率、格式合规率、空值率三个指标。准确率低于基线就不上线，格式合规率低于 95% 就要继续调格式约束。
测试集的构建不需要很复杂，用表格就行：输入文本、期望输出、实际输出、是否通过。通过率按字段拆开看，哪个字段错得多就针对性优化。
5.2 线上抽检与反馈闭环
测试集通过不代表线上没问题。上线后要保留抽检机制，按比例随机抽样人工复核，把错误案例收集起来，定期补充到测试集里。这样测试集会越来越贴近真实分布，提示词也会越来越稳。
我一般会设一个简单的反馈入口：运营或客服发现输出有问题时，点一下标记，后台记录输入输出和错误类型。每周汇总一次，看错误集中在哪些场景，然后决定是改提示词还是加规则兜底。
5.3 什么时候该放弃提示词方案
提示词工程不是万能的。如果出现以下情况，说明该换方案了：测试集准确率长期低于 80%，且优化提示词没有明显提升；输出格式始终不稳定，下游解析成本高于收益；任务需要复杂推理或多步计算，模型单次输出无法完成；成本或延迟远超预算，且没有优化空间。
这时候可以考虑微调小模型、用规则引擎兜底、或者把任务拆成多个子任务分别处理。提示词工程适合的是“模型有能力做，但需要引导”的场景，不是“模型根本做不了”的场景。
我自己的习惯是：任何提示词方案上线前，先问自己三个问题——测试集过了吗？成本算过了吗？出问题能回退吗？三个都 yes 才推全量。这个习惯帮我省了很多后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
