12 Prompt Engineering 入门：提示词为什么会影响模型行为？

在上一篇文章中，我们详细解释了 In-Context Learning。

In-Context Learning 的核心现象是：大语言模型在不更新参数的情况下，只通过 prompt 中的任务说明和少量示例，就可以临时适应一个任务。

例如：

复制代码

句子：这部电影太无聊了。
情感：负面

句子：演员演技很好，剧情也很感人。
情感：正面

句子：这本书内容清晰，非常适合入门。
情感：

模型可能会继续输出：

复制代码

正面

这说明 prompt 不只是"随便问一句话"，而是模型执行任务时最直接的输入接口。由此就引出了一个非常重要的方向：Prompt Engineering，也就是提示词工程。所谓 Prompt Engineering，并不是简单地"写一句更好听的问题"，而是：

通过设计输入文本的任务说明、上下文信息、示例、输出格式和约束条件，引导大语言模型产生更符合目标的输出。

这一章我们重点回答一个问题：

为什么提示词会影响模型行为？

一、Prompt 到底是什么？

从用户角度看，prompt 是我们输入给模型的一段话。

例如：

复制代码

请解释一下什么是 Transformer。

或者：

复制代码

请把下面这段英文翻译成中文：
Attention is all you need.

但从模型角度看，prompt 不是普通"问题"，而是一个 token 序列。模型接收到 prompt 后，会不断预测下一个 token。也就是说，大语言模型的基本行为仍然是：

其中：

是模型要预测的下一个 token；
是前面所有 token，也就是当前上下文。

当我们修改 prompt 时，本质上是在修改：

复制代码

模型看到的上下文 x_<i

上下文变了，模型预测下一个 token 的概率分布也会变。

例如，输入：

复制代码

请解释一下 Transformer。

模型可能输出一段通俗解释。

如果输入：

复制代码

请用适合初中生理解的方式解释 Transformer。

模型会倾向于输出更通俗、更少术语的解释。

如果输入：

复制代码

请用论文综述的语气解释 Transformer，并包含核心公式。

模型会倾向于输出更学术、更正式的内容。所以，prompt 影响模型行为的根本原因是：

Prompt 改变了模型的上下文条件，从而改变了模型生成下一个 token 的概率分布。

二、为什么同一个问题，换种问法结果会不同？

大语言模型不是从数据库中检索一个固定答案，而是根据上下文生成最可能的后续文本。因此，同一个任务，不同 prompt 可能会让模型进入不同的生成模式。例如任务都是"解释 Transformer"。

Prompt A：

复制代码

Transformer 是什么？

Prompt B：

复制代码

请用一篇 CSDN 技术博客的风格，详细解释 Transformer 的 Encoder、Decoder、Self-Attention 和 Position Encoding，并配合公式说明。

两者都会问 Transformer，但模型看到的上下文完全不同。Prompt A 只告诉模型：

复制代码

需要解释 Transformer

Prompt B 额外告诉模型：

复制代码

输出风格：CSDN 技术博客
详细程度：详细解释
内容范围：Encoder、Decoder、Self-Attention、Position Encoding
表达方式：配合公式说明

因此，Prompt B 给了模型更明确的生成约束。这就是为什么好的 prompt 通常包含更多任务信息，而不是只写一个模糊问题。

可以简单理解为：

复制代码

模糊 prompt → 模型自由发挥空间大
明确 prompt → 模型输出更接近目标

例如：

复制代码

写一下 BERT。

这个 prompt 太宽泛，模型不知道你要：

复制代码

简短介绍？
论文精读？
代码解析？
公式推导？
优缺点总结？
CSDN 博文？
学术论文段落？

更好的 prompt 是：

复制代码

请写一篇 CSDN 博文，题目是"BERT 论文精读：双向 Transformer 如何学习语言表示？"。要求先解释 BERT 想解决的问题，再讲输入表示、MLM、NSP、下游微调方式，最后总结 BERT 和 GPT 的区别。

这个 prompt 明确了：

复制代码

文章形式
标题
内容结构
重点范围
比较对象
输出目标

模型自然更容易生成符合预期的内容。

三、Prompt Engineering 的核心组成

一个好的 prompt 通常不是一句简单问题，而是由多个部分组成。可以概括为：

复制代码

任务目标
背景信息
示例
输出格式
约束条件
评价标准

下面分别解释。

1. 任务目标

任务目标告诉模型要做什么。例如：

复制代码

请总结下面这篇文章。

请把下面代码改写成更高效的版本。

请判断下面评论的情感是正面还是负面。

任务目标越明确，模型越容易理解。

2. 背景信息

背景信息告诉模型任务发生在什么场景下。例如：

复制代码

我正在写一篇面向初学者的 CSDN 博文。

这段内容用于 SCI 论文，需要语言正式、简洁。

这个函数用于处理配电网馈线和配变数据。

背景信息可以帮助模型选择合适的术语、语气和细节深度。

3. 示例

示例是 In-Context Learning 的核心。例如：

复制代码

输入：这部电影很好看。
输出：正面

输入：剧情太拖沓。
输出：负面

输入：演员表现不错。
输出：

示例会告诉模型：

复制代码

输入长什么样
输出长什么样
标签有哪些
任务映射关系是什么

GPT-3 论文系统展示了 zero-shot、one-shot 和 few-shot prompting 的差异，其中 few-shot setting 通过在上下文中提供 demonstrations 来引导模型完成任务，但不进行参数更新。

4. 输出格式

输出格式告诉模型答案应该长什么样。例如：

复制代码

请用表格输出。

请只输出 JSON，不要解释。

请按照"问题---原因---解决方案"的结构回答。

输出格式非常重要。同一个问题，如果不约束格式，模型可能输出一大段自然语言；如果明确要求 JSON，模型就会倾向于输出结构化结果。

5. 约束条件

约束条件告诉模型不要做什么，或者必须满足什么要求。例如：

复制代码

不要使用太多专业术语。

不要改变原文意思。

每个小节控制在 300 字以内。

只使用我提供的材料，不要补充外部信息。

这些约束会减少模型自由发挥空间。

6. 评价标准

有时候可以直接告诉模型什么样的答案是好的。例如：

复制代码

要求逻辑清晰、适合初学者、每个公式都要解释变量含义。

或者：

复制代码

要求回答简洁、可执行，不要泛泛而谈。

评价标准能帮助模型更接近目标输出。

四、常见 Prompt 类型

Prompt Engineering 中常见的提示方式有很多。这里先介绍最基础、最常用的几类。

1. Zero-shot Prompting

Zero-shot prompting 是不给示例，只给任务说明。例如：

复制代码

请判断下面句子的情感是正面还是负面：

这家餐厅环境很好，服务也不错。

模型直接输出：

复制代码

正面

这种方式简单，但对于复杂任务可能不够稳定。Prompting Guide 将 zero-shot prompting 定义为不在 prompt 中提供示例或 demonstrations，而是直接让模型完成任务。

2. Few-shot Prompting

Few-shot prompting 会在 prompt 中提供少量示例。例如：

复制代码

句子：这个产品很好用。
情感：正面

句子：质量太差了。
情感：负面

句子：物流很快，包装也不错。
情感：

模型会根据前面示例输出：

复制代码

正面

Few-shot prompting 的优势是可以让模型更清楚任务格式、标签空间和输入输出映射。GPT-3 正是系统展示了 few-shot prompting 在多任务上的能力。

3. Role Prompting

Role prompting 是给模型指定一个角色。例如：

复制代码

你是一名深度学习课程老师，请用适合本科生理解的方式解释 Self-Attention。

或者：

复制代码

你是一名 SCI 论文润色专家，请帮我精修下面这段 Introduction。

角色设定会影响模型的语气、内容选择和专业程度。但要注意，角色设定不能代替具体任务说明。只写：

复制代码

你是专家。

通常不如明确写出：

复制代码

你是深度学习教师，请用通俗语言解释公式，并给出直观例子。

4. Format Prompting

Format prompting 是明确要求输出格式。例如：

复制代码

请用 Markdown 表格比较 BERT、GPT 和 T5。

或者：

复制代码

请按如下 JSON 格式输出：
{
  "问题": "",
  "原因": "",
  "解决方案": ""
}

格式约束对于写代码、数据抽取、表格生成、结构化分析非常重要。

5. Chain-of-Thought Prompting

Chain-of-Thought prompting 通常用于推理任务。它不是只给答案，而是引导模型生成中间推理过程。

例如普通 prompt：

复制代码

小明有 3 个苹果，又买了 5 个，一共有几个？

CoT prompt：

复制代码

小明有 3 个苹果，又买了 5 个。请一步一步推理，一共有几个？

或者 few-shot CoT：

复制代码

问题：小明有 3 个苹果，又买了 5 个，一共有几个？
推理：原来有 3 个，又买了 5 个，所以 3 + 5 = 8。
答案：8

问题：小红有 4 本书，又借了 6 本，一共有几本？
推理：

Chain-of-Thought 论文表明，通过提供中间推理步骤作为示例，可以显著提升大语言模型在复杂推理任务上的表现，尤其是在足够大的模型上更明显。

五、为什么输出格式会显著影响结果？

很多时候，prompt 的效果差，不是因为模型完全不会，而是因为输出格式没有定义清楚。例如你问：

复制代码

请分析这段代码。

模型可能不知道你要分析什么：

复制代码

功能？
复杂度？
bug？
可读性？
优化建议？
安全风险？

如果改成：

复制代码

请从以下四个方面分析这段代码：
1. 功能说明
2. 可能存在的问题
3. 时间复杂度
4. 优化建议

模型输出会更稳定。这是因为输出格式给模型提供了一个清晰的生成框架。

可以理解为：

复制代码

没有格式约束：模型需要自己决定回答结构
有格式约束：模型只需要填充指定结构

对于复杂任务，格式约束尤其重要。例如论文解读可以指定：

复制代码

一、论文解决的问题
二、核心方法
三、关键公式
四、实验结果
五、优缺点总结

代码审查可以指定：

复制代码

问题位置
问题原因
修改建议
修改后代码

数据抽取可以指定：

复制代码

{
  "实体": [],
  "关系": [],
  "时间": "",
  "地点": ""
}

输出格式越明确，模型越容易生成可用结果。

六、为什么示例会影响模型行为？

示例 demonstrations 是 Prompt Engineering 中最强的工具之一。因为示例不仅告诉模型"做什么"，还告诉模型"怎么做"。

例如只写任务说明：

复制代码

请判断下面句子的情感。
句子：这个产品体验一般。

模型可能输出：

复制代码

这句话的情感偏中性。

但如果给示例：

复制代码

句子：这个产品很好用。
情感：正面

句子：质量很差。
情感：负面

句子：这个产品体验一般。
情感：

模型更可能输出：

复制代码

中性

或者如果示例只包含正面和负面：

复制代码

句子：这个产品很好用。
情感：正面

句子：质量很差。
情感：负面

句子：这个产品体验一般。
情感：

模型可能被迫在正面和负面中选择。这说明示例会影响：

复制代码

标签空间
输出格式
判断标准
任务边界

示例选择也很重要。如果示例和待预测输入领域差异很大，效果可能下降。例如用电影评论示例去判断医学文本情感，就不一定合适。所以 few-shot prompt 的一个基本原则是：

示例要和目标任务同格式、同领域、同标签体系。

七、Prompt Engineering 常见错误

Prompt Engineering 不是越复杂越好。很多失败的 prompt 都有一些共同问题。

1. 任务目标不明确

例如：

复制代码

帮我看看这个。

模型不知道你要它：

复制代码

总结？
修改？
翻译？
找错误？
提出建议？

更好的写法是：

复制代码

请检查下面这段论文文字是否存在语法问题，并给出修改后的版本。

2. 输出要求不清楚

例如：

复制代码

分析一下 BERT。

这个问题太宽。更好的写法是：

复制代码

请从模型结构、预训练任务、输入表示、下游微调方式和局限性五个方面分析 BERT。

3. 示例格式不统一

例如：

复制代码

好看 -> 正面
句子：太差了。答案是负面
这个不错：好评

这种格式混乱，模型更容易输出不稳定。更好的写法是：

复制代码

句子：好看。
情感：正面

句子：太差了。
情感：负面

句子：这个不错。
情感：正面

4. 约束条件互相矛盾

例如：

复制代码

请详细解释，但控制在 20 字以内。

这种要求本身冲突，模型很难满足。如果要简短，就写：

复制代码

请用 20 字以内概括核心结论。

如果要详细，就不要过度限制字数。

5. 让模型做没有信息支撑的判断

例如：

复制代码

请判断这个人是否可靠。

但没有提供任何背景材料。更好的方式是：

复制代码

根据下面提供的行为记录，判断是否存在风险，并说明依据。

模型需要信息才能做可靠判断。

八、一个实用 Prompt 模板

对于大多数任务，可以使用下面这个通用模板：

复制代码

你要完成的任务是：[任务目标]

背景信息：[任务背景或使用场景]

输入内容：
[需要处理的文本、代码、数据或问题]

输出要求：
1. [格式要求]
2. [长度要求]
3. [风格要求]
4. [不能做什么]

示例：
输入：[示例输入]
输出：[示例输出]

请开始处理。

例如写论文解读：

复制代码

你要完成的任务是：写一篇 CSDN 博文风格的论文精读。

背景信息：读者是深度学习初学者，但有基本 Python 和机器学习基础。

输入内容：
论文标题：BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding

输出要求：
1. 先解释论文想解决的问题
2. 再讲模型结构和预训练任务
3. 公式必须解释变量含义
4. 最后总结贡献和局限
5. 风格通俗但技术细节完整

请开始写。

这个 prompt 比简单写：

复制代码

写一下 BERT。

要稳定得多。

九、Prompt Engineering 的本质

Prompt Engineering 表面上是"写提示词"，本质上是在控制模型的上下文。大语言模型的基本生成逻辑是：

复制代码

根据当前上下文，预测最可能的下一个 token

所以 prompt 的每一部分都会影响模型：

复制代码

任务说明影响模型要做什么
背景信息影响模型采用什么知识和语气
示例影响模型识别任务模式
输出格式影响模型生成结构
约束条件影响模型减少不需要的内容
评价标准影响模型优化回答方向

因此，好的 prompt 不是"神奇咒语"，而是把任务信息表达得更清楚。可以用一句话总结：

Prompt Engineering 的核心不是讨好模型，而是把任务定义、输入信息、输出格式和约束条件清楚地写进上下文。

这也是为什么 prompt 会影响模型行为。它不是改变了模型参数，而是改变了模型生成时所依赖的条件信息。

十、Prompt Engineering 的局限

虽然 Prompt Engineering 很有用，但它不是万能的。首先，prompt 不能弥补模型完全没有的能力。如果模型本身没有学过某种复杂知识，仅靠提示词很难让它真正掌握。其次，prompt 不能保证事实正确。模型可能按照格式生成看似合理但错误的信息。这就是幻觉问题。第三，prompt 对复杂任务稳定性有限。对于长链路任务、多步骤计算、真实业务流程，仅靠一个 prompt 往往不够，可能需要：

复制代码

任务拆解
检索增强
工具调用
代码执行
多轮校验
人工审核

第四，prompt 会占用上下文长度。Few-shot 示例越多，占用 token 越多，留给实际输入和输出的空间就越少。第五，不同模型对同一 prompt 的反应可能不同。一个在 GPT 系列上有效的 prompt，不一定在其他模型上同样有效。所以 Prompt Engineering 很重要，但它只是大模型应用中的一部分。更完整的大模型系统还需要：

复制代码

模型选择
数据检索
工具调用
结果验证
安全约束
任务流程设计