Prompt Engineering 提示工程
提示工程的定义、要素与常见技巧。
Prompt Engineering (提示工程) 是围绕 模型输入 进行设计、组织和迭代的方法。
其目标是在一次调用的上下文中，通过任务说明、背景信息、约束条件、示例、输出格式和工具说明，让模型更稳定地完成目标任务。
简单地说，提示工程是在上下文中设计任务接口，使模型更容易产生符合目标的输出。
1. 基本定义
1.1 Prompt 是什么
Prompt (提示词) 指一次模型调用中提供给模型的输入内容。
对聊天模型而言，它通常不是一段单纯文本，而是一组带角色的消息，例如 system、user、assistant、tool 等。
一个简单的 prompt 可能只包含用户问题：
解释一下 KV Cache。
一个工程化 prompt 通常会包含更多结构：
系统规则：你是一个严谨的技术文档助手。
任务：解释 KV Cache 的作用。
受众：有基础编程经验，但不了解大模型推理。
要求：说明它解决的问题、基本机制和工程代价。
输出格式：使用三段文字，不使用口语化比喻。
用户问题：解释一下 KV Cache。
这两种写法都属于 prompt，但后者给出了更清晰的任务边界、受众假设和输出约束。
从 Token 与概率 的角度看，prompt 的作用是改变下一个 token 的概率分布。
好的 prompt 不是简单地"命令模型怎样"，而是把任务、信息和约束组织成模型更容易遵循的形式，使正确输出序列的概率更高。
1.2 Prompt 与上下文
一般来说，Prompt 只是上下文的一部分。
一次模型调用中，进入上下文的内容可能包括：
| 内容 | 作用 |
|---|---|
| System prompt | 定义全局行为规则、安全边界和角色定位 |
| Developer / instruction prompt | 定义应用侧任务规则、格式要求和工具使用约束 |
| 用户输入 | 当前任务、问题、补充材料和用户偏好 |
| 对话历史 | 多轮任务中已经确认的信息和前文 |
| RAG 检索结果 | 检索得到的外部材料、来源和引用信息 |
| 工具定义 | 工具名称、参数 schema、描述和调用边界 |
| 工具结果 | 搜索、数据库、命令、浏览器或业务系统返回内容 |
因此，提示工程不能只理解为"写一句提示词"。
在真实应用中，它更接近上下文装配：决定哪些信息进入模型、以什么顺序进入、哪些内容作为规则、哪些内容作为证据、哪些内容必须被忽略。
1.3 提示工程解决什么问题
提示工程主要解决"如何让已有模型在当前任务中表现得更稳定、更可控"的问题。常见目标包括：
- 明确任务类型，例如总结、分类、抽取、翻译、问答、代码生成或规划。
- 限定回答范围，避免模型补充无关信息。
- 控制输出格式，例如 JSON、Markdown 表格、列表或固定字段。
- 提供必要背景，减少模型猜测。
- 给出示例，使模型复用期望的模式。
- 处理边界条件，例如信息不足、输入冲突、格式异常。
- 约束工具调用、RAG 证据使用和多轮对话行为。
提示工程不能让模型获得其本身不具备的能力，也不能可靠替代权限控制、事实检索、评估系统或后训练。它更适合在模型已有能力范围内，提高任务表达的清晰度和执行一致性。
2. Prompt 的组成结构
好的 prompt，一般由下面一些结构组成：
2.1 任务说明
任务说明用于告诉模型要完成什么工作。它应该明确任务类型、输入对象和完成标准。
较弱的写法：
看看这段内容。
更明确的写法：
阅读下面的会议纪要，提取已确认的决策、待办事项、负责人和截止时间。
任务说明越含混，模型越需要根据语言模式猜测用户意图；任务说明越明确，输出越容易稳定。
2.2 背景与输入材料
背景信息用于减少歧义，输入材料用于提供模型完成任务所需的事实依据。
背景和材料应当与任务相关。无关材料越多，越容易消耗上下文预算，并干扰模型判断。对于事实性任务，提示工程应尽量把“要求模型回答什么”和“模型可以依据什么回答”分开。
例如 RAG 场景中，应明确区分用户问题和证据：
用户问题：
...
可用证据：
[证据 1]
来源：...
内容：...
[证据 2]
来源：...
内容：...
这样做可以降低模型把用户问题、系统规则和外部证据混在一起理解的风险。
2.3 约束条件
约束条件用于定义回答边界。常见约束包括：
- 只依据给定材料回答。
- 信息不足时说明无法判断。
- 不输出未经证据支持的推测。
- 保持术语一致。
- 避免某些内容、风格或格式。
- 控制回答长度和细节粒度。
约束应尽量具体、可执行、可检查。过于抽象的要求，例如"回答要好"、"尽量专业"、"不要乱说"，通常不如明确规定判断依据、输出字段和不确定性处理方式有效。
2.4 输出格式
输出格式用于降低后处理难度。常见格式包括自然语言段落、Markdown 表格、JSON、XML、YAML、代码块和函数参数。
如果系统需要机器读取输出，不应只依赖自然语言提示"请严格输出 JSON"。更稳妥的方式是结合 schema、parser、JSON mode、结构化输出或 tool / function calling。
例如：
{
"summary": "一句话摘要",
"risks": ["风险 1", "风险 2"],
"missing_info": ["缺失信息 1"]
}
格式要求不仅影响可读性，也会改变模型的生成路径。明确字段名、字段类型和是否允许为空的情况，通常比单纯要求"结构化输出"更可靠。
2.5 示例
示例用于向模型展示期望模式。少量示例可以显著改善分类、抽取、改写、格式转换和风格迁移任务。
常见形式包括：
| 类型 | 说明 |
|---|---|
| Zero-shot | 不给示例，只给任务和约束 |
| One-shot | 给一个输入输出示例 |
| Few-shot | 给少量输入输出示例 |
示例应覆盖典型场景和关键边界，而不是只展示最简单样本。
示例中的格式、术语和判断标准会强烈影响后续输出，因此示例质量比示例数量更重要。
3. 常见技巧
3.1 明确角色与任务边界
角色设定的价值不在于制造"人格"，而在于定义回答立场、知识边界和输出规范。例如：
你是一个面向工程团队的技术文档编辑。你的任务是把草稿改写为严谨、清晰、可发布的知识库文章。
这类角色设定应服务于任务，而不是替代任务说明。只写"你是专家"通常不足以带来稳定效果；必须同时给出任务、受众、材料范围和输出标准。
3.2 分解复杂任务
复杂任务通常包含多个子目标。如果一次 prompt 同时要求模型理解材料、抽取事实、比较证据、形成判断、生成最终文案，模型容易遗漏步骤或混淆优先级。
更稳妥的做法是显式分阶段：
- 先识别任务类型和输入范围。
- 再抽取事实、约束和缺失信息。
- 然后组织推理或比较结构。
- 最后生成符合格式的输出。
分阶段可以写在同一次 prompt 中，也可以拆成多次模型调用。对于高风险或高复杂度任务，多次调用通常更可控，也更容易评估每一步质量。
3.3 使用示例约束模式
Few-shot 示例适合模型需要学习某种稳定映射的场景，例如：
- 将客服反馈分类为固定标签。
- 从合同条款中抽取字段。
- 将错误日志整理为排障步骤。
- 将自由文本转换为结构化 JSON。
- 按既定风格改写文档。
示例应尽量与真实输入分布一致。如果真实输入很长、噪声多、格式不稳定，而示例都非常干净，模型在线上仍然可能失效。
3.4 明确不确定性处理
事实性任务中，提示词应规定信息不足、证据冲突或输入异常时的处理方式。例如：
如果证据无法支持结论，请输出"无法判断"，并列出缺失信息。不要用常识或外部知识补全。
这类约束对 RAG、合规审查、投研分析、医疗法律类文档处理尤其重要。模型默认倾向于生成完整回答，如果不明确允许“不知道”或“无法判断”，它更容易用语言模式补齐缺失事实。
3.5 控制上下文预算
Prompt 越长，不一定效果越好。过长的系统规则、重复示例、无关历史和低质量检索片段会增加成本、延迟和注意力干扰。
提示工程需要与上下文管理结合：
- 当前任务强相关内容优先。
- 硬约束和原始证据优先。
- 示例要少但全面而典型。
- 可检索材料不必长期常驻上下文。
- 长工具结果应先过滤、摘要或结构化。
4. 与其他方法的关系
4.1 提示工程与指令跟随
指令跟随 是模型通过后训练获得的能力，提示工程是使用这种能力的方法。
可以这样区分：
| 概念 | 关注点 | 例子 |
|---|---|---|
| 指令跟随 | 模型是否具备理解和执行任务指令的能力 | 能否遵循 system / user 角色、格式要求和安全边界 |
| 提示工程 | 如何把当前任务写成模型更容易执行的输入 | 如何描述任务、组织材料、设置约束和示例 |
如果模型本身指令跟随能力弱，再精细的 prompt 也只能有限改善。相反，指令跟随能力强的模型，也需要清晰 prompt 才能在复杂业务中稳定执行。
4.2 提示工程与 RAG
RAG 提供外部知识，提示工程规定这些知识如何被使用。
RAG 解决的是"模型应该依据哪些材料回答"；提示工程解决的是"模型应如何阅读这些材料、如何处理证据不足、如何输出结论和引用"。
典型组合方式是：
- RAG 负责检索、重排序、去重和提供来源。
- Prompt 明确证据边界、引用方式和不确定性处理。
- 评估系统检查答案是否被证据支持。
因此，长 prompt 不能替代 RAG；RAG 也不能自动保证回答可靠。二者需要共同设计。
4.3 提示工程与微调
微调、提示工程和 RAG 都能改善模型效果，但改变的对象不同：
| 方法 | 改变的对象 | 适合解决的问题 |
|---|---|---|
| 提示工程 | 输入上下文 | 快速约束任务、格式、角色和步骤 |
| RAG | 外部知识上下文 | 提供最新资料、私有文档和可追溯事实 |
| 微调 | 模型参数或适配器参数 | 固化稳定行为、领域风格和任务模式 |
如果：
- 问题是"模型不知道新文档内容"，优先考虑 RAG。
- 问题是"模型偶尔没有按指定格式回答"，先优化 prompt、schema 和后处理。
- 问题是"同类任务大量出现，且提示词很长仍然不稳定"，再考虑微调。
4.4 提示工程与 Agent
Agent 场景中的提示工程不仅是写系统提示词，还包括工具说明、状态表示、任务分解、错误恢复和子任务交接。
需要注意的是，Agent 的稳定性不能只依赖提示词。权限控制、工具 schema、状态机、guardrails、日志审计和评估同样重要。稳定规则应尽量进入代码、工具接口和可测试流程，而不是全部堆进 system prompt。
5. 常见误区
把提示工程等同于“写咒语”
提示工程不是寻找某个神秘短句，而是对任务接口进行结构化设计。有效 prompt 通常来自清晰任务定义、可验证输出格式、合适示例和持续评估，而不是固定模板的堆叠。
Prompt 越长越好
不一定。长 prompt 可能包含更多规则和背景，也可能引入重复、冲突和噪声。工程上应关注信息密度和任务相关性，而不是长度本身。
只靠提示词保证安全和合规
不可靠。提示词可以表达规则，但不能替代权限、隔离、审核、日志、guardrails 和人工复核。对于工具调用、数据访问和高风险决策，必须有系统层控制。
用提示工程替代评估
提示词改动必须通过评估验证。没有固定样本、指标和失败案例分析，很难判断改动是否真的提升了质量，还是只改善了少数主观样例。
用提示工程替代所有模型优化
提示工程适合快速迭代和任务约束，但不是万能方法。外部知识应由 RAG 提供，长期稳定行为可以考虑微调，复杂流程需要工作流和 Agent 架构，线上质量需要评估和监控。
小结
提示工程是在模型输入上下文中设计任务接口的方法。
它通过任务说明、背景材料、约束条件、输出格式、示例和工具说明，影响模型的生成分布，使模型更稳定地输出符合目标的结果。
理解提示工程时，应把握几个要点：
- Prompt 不只是用户一句话，而是一次调用中的任务、规则、材料和格式组织。
- 好的 prompt 应明确任务、证据、约束、输出格式和不确定性处理。
- 示例可以改善稳定性，同时示例质量比数量更重要。
- 提示工程需要与上下文管理、RAG、结构化输出和评估结合。
- 提示工程不能替代模型能力、外部知识、权限控制、微调和系统工程。
对工程实践而言，提示工程的核心是把任务表达成模型、程序和评估系统都能共同处理的清晰接口。