本课目标
- 用"交接文档"的视角重新理解 Prompt
- 掌握四要素 Prompt 框架，写出稳定可复现的提示
- 搞懂 Few-shot、Chain-of-Thought、角色设定这些技巧真正在做什么
提示工程被吹得神乎其神，各种"咒语""魔法提示词"满天飞。但剥掉外衣，它就是一个特别简单的东西：你跟一个聪明但缺乏背景的同事，做一次高质量的工作交接。 你不会在工作交接里写咒语，你会写清楚任务、背景、约束和示例。对模型也完全一样。
核心内容
Prompt 就是一份工作交接文档
一个完整的 Prompt 包含四个要素：
- 任务：要做什么。别写"帮我分析一下这个数据"，写"从这份销售数据中找出销售额同比下降超过 20% 的产品线，列出产品名称、下降幅度和可能的原因"。
- 上下文（背景）：为什么要做、之前的讨论、相关的业务知识。这是最容易被省略但最重要的部分——模型不会读心，你不告诉它的它不知道。
- 约束（格式）：输出格式、长度限制、禁止事项。这是工程师的生命线——没有格式约束，模型的输出就没法被代码解析。
- 示例（Few-shot）：给 2-3 个输入→输出的正确范例。这是最强大的格式控制手段——一个例子抵得上一百字的描述。
试一个思维实验：把你写的最好的 Prompt 和你的工作交接邮件放在一起对比。结构是不是惊人地相似？如果是，说明你已经懂了。
Few-shot：用示例取代描述
描述"简短、专业、带数据支撑"不如给三个符合这个标准的示例。模型从示例中学习的效率远超从指令中学习。
一个合格的 Few-shot 示例包含：真实的输入、对应的正确输出、以及一个不能偷懒的前提——示例必须多样。给三个"正面的"示例和一个"该拒绝的"反例，比给四个正面示例效果好得多。
Chain-of-Thought：让模型"想出声"
给复杂任务的 Prompt 里加一句"让我们一步一步思考"——不是魔法，是改变了模型的生成路径。当模型先生成推理过程再给结论时，它相当于给自己搭建了一座通往正确答案的桥。
对多步推理、数学问题、逻辑判断效果显著。对简单的事实查询反而多余——别问"今天天气怎么样"之前还要它写篇分析。
2026 年的推理模型（o-series、R-series）已经内置了 CoT，你不需要手动写——但理解原理才能判断什么时候该用。
角色设定：一个被低估的精度锚
"你是一个资深后端工程师"不是一个花哨的装饰——它锚定了模型回答的分布空间。后端的术语、工程习惯、踩坑经验都会体现在回答里。"你是一个友善的生活教练"会把同样的知识包装成完全不同的表达。
关键是你设定的角色要在模型的训练语料中有真实映射。设一个虚构角色也行，但大概率不如"资深后端工程师"有效。
角色设定 = 给模型的回答圈一个范围。范围越小，回答越精准。
动手练习
把你上周写的最不满意的一次 Prompt 拿出来，用四要素框架重写一遍。对比两次输出——格式约束和 Few-shot 通常是最立竿见影的改进点。