提示词编写 SOP：从白皮书到可执行流程
基于 Google《Prompt Engineering》白皮书整理 · 技术博客
本文根据 Prompt Engineering（Lee Boonstra 等，2025）整理出一套可复用的提示词编写标准作业流程（SOP），便于在选模型、写提示、调参与文档化时按步骤执行，减少无效尝试并提高输出质量。
一、SOP 总览
提示工程是迭代过程：目标不清、配置不当或提示含糊都会导致输出模糊、偏离预期。建议按以下顺序执行：
- 明确目标与输出形式
- 选择模型并配置输出参数
- 选择并应用提示技巧
- 撰写提示（简洁、具体、多用示例）
- 文档化与回归测试
二、明确目标与输出形式
在写提示前先确定：
- 任务类型：分类、抽取、摘要、生成、翻译、代码生成、推理等。
- 输出格式：纯文本、JSON、XML、固定标签（如 POSITIVE/NEGATIVE）、段落数量等。
- 长度与风格：是否需要「一句话」「一段话」「三条要点」等；语气是正式、口语还是技术文档。
白皮书建议：多用「指令」说明要做什么，少用「约束」罗列不要做什么；对抽取、分类等任务可要求返回 JSON，以降低幻觉、便于解析。
三、选择模型并配置输出参数
不同模型和配置会显著影响结果。至少关注以下项：
3.1 输出长度（Token Limit）
限制生成 token 数可控制成本与延迟。注意：限制的是「何时停止生成」，不会自动让模型更简洁；若需要简短输出，需在提示中明确说明。
3.2 Temperature（温度）
- 低（如 0～0.2）：更确定、一致，适合分类、抽取、有唯一答案的任务。
- 高（如 0.8～1）：更多样、创意，适合写作、头脑风暴。
- 数学/逻辑等单一正确答案：建议先用
temperature=0（贪婪解码）。
3.3 Top-K 与 Top-P
与 Temperature 一起控制采样范围：Top-K 取概率最高的 K 个 token，Top-P（核采样）按累积概率截断。一般起点可设为：
- 偏确定：temperature≈0.1，top-P≈0.9，top-K≈20。
- 偏创意：temperature≈0.9，top-P≈0.99，top-K≈40。
若出现重复、车轱辘话（repetition loop），可适当调整 temperature 与 top-K/top-P 的平衡。
四、选择并应用提示技巧
按任务复杂度与是否需要「推理」来选技巧：
| 技巧 | 适用场景 |
|---|---|
| Zero-shot | 任务简单、模型已能理解，只给任务描述与输入 |
| One-shot / Few-shot | 需要固定输出格式或模式；一般 3～5 个示例，分类任务需混合不同类别 |
| System / Role / Context | System 定整体能力与目的；Role 定身份与口吻；Context 提供当前任务相关背景 |
| Step-back | 先让模型回答一个更抽象、原则性问题，再把答案作为上下文回答具体问题 |
| Chain of Thought (CoT) | 需要推理、数学、多步决策；加「Let's think step by step」或给 1～2 个带推理过程的示例 |
| Self-consistency | 同一提示多次采样，取多数答案以提高正确率（代价为成本与延迟） |
| ReAct | 需要调用工具、搜索、API 的智能体式任务 |
CoT 使用建议：将最终答案放在推理步骤之后；若只关心最终答案，temperature 设为 0；在工程上需能从输出中稳定解析出「推理」与「答案」两部分。
五、撰写提示的通用原则
- 简洁清晰：自己都绕的表述，模型更难用好；多用动词（Act, Classify, Extract, Summarize, Translate 等）明确动作。
- 具体说明输出：例如「生成 3 段、每段 2～3 句的博客」「仅返回 POSITIVE/NEUTRAL/NEGATIVE」。
- 多用示例：One-shot / Few-shot 对格式、风格、边界情况最有效；示例需高质量、无错误。
- 变量化：将城市、产品、日期等抽成变量（如
{city}），便于在应用内复用同一提示模板。 - 结构化输出：抽取、分类、解析类任务可要求 JSON/XML 并给出 schema，有利于减少幻觉、便于下游处理。
六、文档与迭代
白皮书强调：提示会经历多轮修改，且不同模型、版本、采样设置下表现可能差异很大，因此需要系统化记录每次尝试。推荐用表格记录至少以下字段：
| 字段 | 说明 |
|---|---|
| Name / Version | 提示名称与版本号 |
| Goal | 一句话描述本次尝试的目标 |
| Model | 模型名称与版本 |
| Temperature / Top-K / Top-P / Token Limit | 所用配置 |
| Prompt | 完整提示内容 |
| Output | 代表性输出或多次输出的摘要 |
| Result | OK / NOT OK / SOMETIMES OK |
| Feedback | 备注、待改进点 |
在代码中：将提示与业务逻辑分离（如独立配置文件或模块），便于维护；对关键提示做自动化测试与回归，以观察模型或配置变更后的表现。
小结
一套可执行的提示词编写 SOP 可归纳为：先定目标与输出形式 → 选模型与调参 → 选提示技巧 → 按「简洁、具体、示例、变量、结构化」原则撰写 → 文档化并迭代测试。白皮书中关于 LLM 输出配置、各类提示技巧与代码场景（写代码、解释、翻译、调试）的细节，可作为本 SOP 的延伸阅读，按任务类型进一步细化。
参考：Prompt Engineering (February 2025), Lee Boonstra et al., Google. 见本站 resource/Prompt Engineering.pdf。