最近系统看了一遍 Google 发布的《Prompt Engineering》白皮书（作者 Lee Boonstra，2024），里面对"如何和大语言模型打交道"有一套比较完整、可操作的思路。这篇文章把其中几个具有代表性的重点整理出来，方便大家在实际工作中参考使用。
全文只基于这份白皮书本身，不额外添加其他立场和观点。
一、Prompt 工程是一套持续迭代的"工程方法"
白皮书一开始就强调：
Prompt 工程不是随手写几句提示词，而是一套需要持续迭代的工程方法。
它包含几个核心环节：
- 明确任务与目标
- 设计初始提示
- 配置模型参数（如温度、最大输出长度等）
- 观察输出效果
- 根据结果调整提示或参数
- 在产品中集成和维护
白皮书指出，提示文本、模型本身以及模型配置，是共同决定输出质量的三个关键因素。同一个提示，在不同模型版本或不同参数下，表现可能完全不同。
此外，文中还特别提醒：
- 模型会不断更新
- 训练数据也会变化
- 旧提示随时间可能不再适配新的模型行为
因此，白皮书建议把提示当作一类需要维护的"配置资产"，要记录：
- 使用的模型及版本
- 对应的提示内容
- 当时的参数设置（温度、Top-P、最大输出 tokens 等）
- 效果是否满足预期
这样在模型升级或场景变化时，可以有依据地进行调整，而不是从零开始摸索。
二、示例比长篇说明更有效：Few-shot 提示的价值
在提示具体写法上，白皮书对多种方式进行了对比：零示例（zero-shot）、单示例（one-shot）、少示例（few-shot）等。其中few-shot 提示被反复强调为非常重要的实用手段。
白皮书的核心观点可以概括为：
- Zero-shot：只给任务说明，模型有时能正确完成，但不稳定
- One-shot：提供一个示例，可以一定程度上引导模型模仿
- Few-shot：提供多组示例（常见是 3--5 个），整体效果往往显著更好
特别是在分类、结构化输出、格式转换等任务中，few-shot 示例既能展示输入形式，又能给出期望的输出格式，相当于为模型提供了一个小型"任务说明书"。
白皮书还提出一个容易被忽略的细节：
在少示例分类任务中，示例中各个类别的出现顺序应尽量打乱，而不是固定顺序。
原因是，如果每次提示里类别顺序完全一致，模型可能会过度依赖"列表顺序"，而不是从内容本身去抽取判别特征。通过打乱示例顺序，可以降低这种风险，让模型更多依赖真正有用的信息。这一点在实际设计提示时非常有操作性：不仅要准备高质量示例，还要注意示例本身的排列方式。
三、让模型"慢一点想"：Chain-of-Thought 与 Step-back 提示
对于推理复杂、步骤较多的任务，白皮书重点介绍了思维链（Chain-of-Thought, CoT）和Step-back Prompting 两种思考方式。
1. Chain-of-Thought（思维链）
白皮书指出，传统做法往往直接让模型给出最终答案，而 CoT 的思路是：
- 在提示中明确要求模型"逐步思考"
- 让模型先写出中间推理步骤，再给出结论
例如，在题目后增加类似语句：
"Let's think step by step."
在白皮书的例子中，这种方式可以显著提升模型在数学题、逻辑题、多步骤推理任务上的表现。优点包括：
- 无需额外训练或微调
- 不改变模型结构
- 增强结果的可解释性（用户能看到中间步骤）
这是一种成本极低、收益明显的提示方式。
2. Step-back Prompting（后退式思考）
另外，白皮书还介绍了一种更偏"宏观思考"的提示方式：Step-back Prompting。
它的做法是先引导模型从更高层次、更抽象的角度重新审视问题，例如：
- 先让模型总结当前任务的本质要素
- 再基于这些抽象要素来给出方案或回答
这种方法特别适合：
- 涉及策略规划的任务
- 问题本身较为模糊，需要先澄清目标的任务
- 需要从多个角度综合考量的情景
白皮书将 CoT 与 Step-back 视为重要的进阶提示技巧：前者侧重细致的"步骤推理"，后者强调在回答前进行"整体抽象"。
四、清晰的输出格式能显著提升可靠性
白皮书在"最佳实践"中反复强调：必须在提示中明确期望的输出形式。
常见的格式包括：
- 按段落分结构化回答
- 使用项目符号列表（bullet points）
- 严格遵守某种模板
- 输出符合 JSON 或 XML 的结构化数据
文中指出，当任务本身就是：
- 信息抽取
- 分类与打标
- 文本解析与重组
- 数据整理
这类场景时，如果能够在提示中明确写出"需要哪些字段、字段之间是什么关系、输出格式示例是什么样的"，通常可以显著减少：
- 输出冗长但无结构的文本
- 字段遗漏
- 随意添加未要求信息
对于开发场景来说，白皮书特别推荐让模型输出 JSON 等机器易解析的格式，并在提示中给出字段名称和示例结构，要求模型"严格遵守此结构输出"。这类格式化要求，并不是额外负担，实际上是稳定性的重要来源。
五、模型参数与提示设计要一起考虑
在介绍提示技巧的同时，白皮书也花了篇幅讲解采样控制参数 与输出长度设置对结果的影响，例如：
- Temperature（温度）
- Top-K
- Top-P
- 最大输出 tokens（output length）
白皮书的整体原则是：
- 对于需要稳定、可复现答案的任务（如分类、解析、规则型回答），可以将温度设得较低，使输出更确定
- 对于追求多样性和创造性的任务（如文案生成、创意内容），可以适当提高温度或调整 Top-P，让模型有更多探索空间
- 同时要限制最大输出长度，避免出现过长、不聚焦的回答，也能节省资源
文中把这些设置看作提示工程的一部分，而不是与提示无关的"附属配置"。换句话说：在白皮书的视角里，Prompt = 文本 + 上下文 + 模型配置。
六、提示需要文档化与版本管理
在白皮书的后半部分，专门提到提示工程在团队与产品场景中的实践建议，其中有几点非常值得注意：
-
为提示建立版本记录
- 每次修改提示内容时，记录时间、修改原因、对应模型版本
- 标记当前版本在各类用例中的表现（较好、一般、不符合预期）
-
将提示从代码中抽离
- 不直接把提示"写死"在代码里
- 通过配置文件、外部存储等方式管理
- 便于在不改动代码的前提下更新提示
-
把提示纳入测试流程
- 对关键提示配套测试用例
- 在模型更新或参数调整后，重新跑这些用例
- 以此评估提示是否仍然可用
这些建议都来自白皮书本身，目标是让提示工程真正融入产品开发流程，而不仅停留在"临时尝试"的阶段。
结语
整体来看，Google 这份《Prompt Engineering》白皮书提供的，不是一组零散的技巧，而是一条相对完整的思路链：
从"把提示当作可以迭代的工程对象"，
到"通过示例、思维链、格式约束等手段提高输出质量"，
再到"在团队和产品层面建立提示的文档化与测试机制"。
如果需要与大语言模型长期协作，这些做法都具有较高的参考价值。
以上内容全部基于白皮书中的论述进行整理，希望对你在设计和优化提示时有所帮助。