Prompt Engineering 完全实践指南

基于 Transformer 架构原理 + 学术研究 + Anthropic/OpenAI 官方最佳实践整合
更新于 2025年5月

1. 理解底层：为什么 Prompt 的结构和位置影响输出

这不是玄学，是 Transformer 架构的数学特性。

1.1 U 形注意力曲线（Lost in the Middle）

LLM 对 prompt 不同位置的关注度不均等，呈现出「U 形曲线」：

关注度
  高 ██████                          ██████
  中     ██                      ██
  低         ████████████████
            开头   [中间区域]   结尾

研究数据：当关键信息从第 1 个文档位置移动到 20 个文档中的第 10 个位置时，准确率下降超过 30%。

三个架构根源：

1.2 两阶段处理模型

Transformer 的信息处理分两个阶段：

• 前 2/3 层（信息提取阶段）：从上下文中汇聚信息，此阶段对 token 表示的改变极为敏感

• 后 1/3 层（内部处理阶段）：对前序 token 的依赖减弱，更多内部加工

实践含义：角色设定、规则约束等高权重指令应放在 prompt 开头，让模型在信息提取阶段就「锁定」基调。

1.3 注意力分配与 Q-K-V 机制

prompt 的清晰度和结构完整性，直接影响 Q（查询）和 K（键）之间的注意力分数分布。结构越清晰，注意力越集中在核心意图上，而非分散在噪声上。

2. 黄金结构：Prompt 的推荐摆放顺序

基于注意力分布规律，推荐如下黄金排布：

┌─────────────────────────────────────────┐
│  【开头】System / 角色 / 核心规则         │  ← 首因效应加持，奠定基调
│         （高权重，必须出现在前）           │
├─────────────────────────────────────────┤
│  【中前段】背景信息 / 少量示例             │  ← 提供上下文，尽量精简
├─────────────────────────────────────────┤
│  【中段】参考资料 / 文档内容               │  ← 中间死区，非关键内容放这里
├─────────────────────────────────────────┤
│  【结尾】核心任务指令 / 输出格式要求        │  ← 近因效应加持，直接影响生成
│         最重要的约束 / 具体问题            │
└─────────────────────────────────────────┘

推荐的 System Prompt 内部结构

<role>
  你是一位 [具体角色]，擅长 [核心能力]。
</role>

<rules>
  1. [最关键的约束]
  2. [次要约束]
  3. 如不确定，说"我不确定"，不要编造
</rules>

<output_format>
  [期望的输出格式说明]
</output_format>

User Prompt 内部结构

[背景/上下文（如有）]

<task>
  [具体任务描述]
</task>

<examples>
  [1-3 个示例（如有）]
</examples>

[最重要的具体指令，放在最后]

3. 基础技法：写好每一个 Prompt 的核心原则

3.1 从模糊到精确的四级清晰度

精确 Prompt 的五个要素（What/Why/How/Format/Constraint）：

What：   明确任务目标（做什么）
Why：    说明用途/受众（给谁看、为什么）
How：    期望的方式/风格（怎么做）
Format： 输出格式（长度、结构、媒介）
Limit：  边界约束（不要做什么、范围限制）

3.2 正向指令优于负向指令

LLM 更擅长遵循「要做什么」，而非「不要做什么」。

负向（容易失效）：
   不要使用项目符号，不要太长，不要用专业术语

正向（更稳定）：
   用连贯的段落写作，控制在 200 字以内，使用高中生能理解的语言

3.3 使用 XML 标签隔离语义区域

XML 标签是目前最可靠的 prompt 结构化手段，尤其对 Claude 有效（其训练数据中大量使用了 XML 结构）：

<instructions>
  分析以下合同中的风险条款
</instructions>

<contract>
  [合同正文内容...]
</contract>

<output_format>
  以 JSON 格式输出：{"risks": [...], "severity": "high/medium/low"}
</output_format>

XML 标签使用原则：

• 标签名语义清晰（<examples>, <context>, <task>, <rules>）

• 全程保持一致，不要换标签名

• 在指令中引用标签名：「请基于 <contract> 标签中的内容...」

• 支持嵌套：<documents><document><source>...</source><content>...</content></document></documents>

3.4 让 LLM 镜像你的语气与风格

LLM 会自然延续对话的风格和语气。

你的 prompt 是学术语气 → 输出倾向于正式、引用式
你的 prompt 是对话语气 → 输出倾向于轻松、口语化
你的 prompt 使用中文 → 输出默认中文（切换语言需显式声明）

实践：想要什么风格的输出，就用那种风格写 prompt。

4. 进阶技法：撬动 LLM 推理能力的提示策略

4.1 Zero-Shot / Few-Shot / Many-Shot 提示

Few-Shot 最佳实践：

• 例子数量：3-5 个为最优，兼顾效果和 token 成本

• 多样性：例子要覆盖边界情况，不要都是「简单正例」

• 位置：放在具体任务描述之前（让模型先看到模式再执行）

• 一致性：格式严格一致，不要让例子之间有结构差异

<examples>
  <example>
    <input>客户反馈：送货太慢了，等了两周</input>
    <output>{"sentiment": "negative", "category": "logistics", "priority": "high"}</output>
  </example>
  <example>
    <input>客户反馈：产品质量很好，下次还会购买</input>
    <output>{"sentiment": "positive", "category": "product", "priority": "low"}</output>
  </example>
</examples>

现在处理：客户反馈：{customer_feedback}

4.2 Chain-of-Thought（CoT）思维链提示

让 LLM 逐步推理，而非直接输出答案。研究证明 CoT 在数学推理任务上能将准确率从 17.7% 提升至 78.7%。

三种触发方式：

方式一：简单触发（Zero-Shot CoT）
在 prompt 末尾加：
"请一步一步地思考。"
"Let's think step by step."

方式二：结构化思考（推荐）
请先在 <thinking> 标签中梳理你的推理过程，再在 <answer> 标签中给出最终答案。

方式三：Few-Shot CoT（最强）
在 few-shot 例子中展示完整的推理链：
问题：...
思考：首先...其次...因此...
答案：...

适用场景：数学计算、逻辑推理、多步骤分析、代码调试、法律/医疗判断。

注意：对于小模型（<7B 参数），CoT 可能反而降低性能，复杂性引入了噪声。

4.3 Self-Consistency（自洽性采样）

同一个问题生成多条推理路径，取「多数票」作为最终答案。

请对以下问题进行 3 次独立分析，每次从不同角度思考，
最后综合三次分析给出你最确信的答案。

问题：[...]

研究数据（Google Brain）：在 GSM8K 数学推理上提升 +10%，MultiArith 上提升 +24%。

适用：高风险决策、数学/逻辑题、需要高准确率的判断任务。

4.4 Tree-of-Thought（思维树）

将问题拆解为树状结构，探索多条路径，支持「回溯」。适合需要规划和搜索的复杂任务。

请像解决这道题一样：
1. 先列出 3 种可能的解题方向
2. 对每种方向，评估可行性（1-5分）和风险
3. 选择最优方向，继续深入推导
4. 如果遇到死路，回退到步骤 1 重新选择

问题：[...]

适用：创意写作规划、战略决策、复杂架构设计、需要探索空间的问题。

4.5 ReAct（推理 + 行动）

用于有工具调用的 Agent 场景，模型在「思考」和「行动」之间交替：

Thought: 我需要先了解用户当前的账单周期
Action: query_billing_system(user_id=123)
Observation: 当前周期为 2025-05-01 至 2025-05-31，已消费 $45.20
Thought: 用户询问的是超额费用，需要查看使用明细
Action: get_usage_details(user_id=123, period="2025-05")
...

4.6 Prompt Chaining（提示链）

将复杂任务拆成多个串行 prompt，每步输出作为下一步输入。

步骤 1 Prompt：从以下文章中提取所有关键观点，每条一行
         ↓ 输出：观点列表
步骤 2 Prompt：基于以下观点列表，识别哪些观点互相矛盾
         ↓ 输出：矛盾分析
步骤 3 Prompt：基于以下矛盾分析，写一篇平衡的综述文章

优点：每步专注单一任务，错误可溯源，可并行优化各步骤。

4.7 元提示（Meta-Prompting）

让 LLM 帮你写/优化 prompt：

我需要一个高质量的 prompt，用于让 LLM 完成以下任务：
[描述任务]

请设计一个专业的 prompt，要求：
- 包含清晰的角色定义
- 包含 2-3 个示例
- 包含明确的输出格式要求
- 使用 XML 结构化标签

4.8 自我反思提示（Reflection Prompting）

请先给出你的初步答案。
然后，扮演一个挑剔的评审者，指出这个答案的 2-3 个潜在问题或改进点。
最后，基于这些反思，输出一个修订后的更好版本。

5. 格式控制：让输出稳定、可解析、可复用

5.1 强制 JSON 输出

<task>
  分析以下用户评论的情感和主题
</task>

<comment>
  {user_comment}
</comment>

请严格按照以下 JSON 格式输出，不要有任何额外文字、代码块标记或前言：
{
  "sentiment": "positive" | "negative" | "neutral",
  "score": 0.0-1.0,
  "themes": ["主题1", "主题2"],
  "summary": "一句话摘要"
}

技巧：在 system prompt 中说明「你只输出 JSON，不输出其他任何内容」，比在 user prompt 中更稳定。

5.2 Prefilling（预填充开头）

通过预填充 assistant 的回复开头，强制引导输出格式（Claude API 特有功能）：

messages = [
    {"role": "user", "content": "分析这段代码的问题"},
    {"role": "assistant", "content": "```json\n{\"issues\": ["}  # 预填充，强制 JSON 输出
]

5.3 输出格式说明模板

输出要求：
- 格式：[Markdown / JSON / 纯文本 / 表格]
- 长度：[字数范围 / 段落数 / 条数]
- 语言：[中文 / 英文 / 双语]
- 语气：[专业 / 口语 / 学术]
- 结构：[必须包含的章节/字段]
- 禁止：[不要出现的内容]

5.4 分隔符的使用

用分隔符清楚区分「指令」和「数据」，防止注入混淆：

请总结以下文本，只输出摘要，不要重复原文：

---
[用户提供的文本内容]
---

6. 角色与人格：用 Persona 锚定输出风格

6.1 角色设定的层次

层次 1（弱）：你是一个助手，帮我写代码
层次 2（中）：你是一个 Python 专家
层次 3（强）：你是一位有 10 年经验的 Python 后端工程师，
              专注于性能优化和可维护性，习惯用类型注解和
              单元测试，代码风格遵循 PEP8

角色越具体，输出越有专业纵深感。

6.2 有效的角色设定公式

你是一位 [职位/身份]，
拥有 [年限/具体经验] 的经验，
专注于 [专业领域]，
你的工作方式是 [方法论/风格]，
你的受众是 [目标用户]。

示例：

你是一位有 15 年经验的产品经理，曾在字节跳动和美团主导过多个亿级用户的 0-1 产品。
你擅长从用户心理和商业逻辑出发分析问题，表达简洁有力，不用行话，
善于用数据和类比解释复杂概念。你的受众是初创公司的创始人团队。

6.3 角色一致性维护

在长对话中，可以在每轮 user prompt 中简短重申角色关键词，防止角色漂移：

[作为上述产品经理的角色] 现在帮我分析这个功能的优先级...

7. 长上下文处理：应对 Lost in the Middle 问题

7.1 关键信息的摆放策略

推荐：关键信息放开头或结尾
避免：将关键文档、关键指令埋在大量无关内容中间

7.2 多文档处理

<documents>
  <document index="1">
    <source>合同甲方条款.pdf</source>
    <content>...</content>
  </document>
  <document index="2">
    <source>合同乙方条款.pdf</source>
    <content>...</content>
  </document>
</documents>

<task>
  基于以上文档，识别双方责任不对等的条款。
  请先从每个文档中引用相关原文，再进行比较分析。
</task>

「先引用原文再分析」这个指令可以有效对抗 Lost in the Middle，强迫模型回溯文档内容。

7.3 长文档分块策略

当文档超长时，通过提示引导模型分段处理：

这是一份长文档，我会分段发送。
每收到一段，请：1）提取关键观点  2）记录页码/段落
最后我会发送"分析完毕"，届时请综合所有段落给出整体分析。

7.4 注意力引导技巧

在处理完整文档后，请重点关注第 3 节和第 7 节的内容来回答我的问题。

以下是参考资料，其中最重要的是 <key_doc> 标签中的内容：
<key_doc>
  [最关键的文档]
</key_doc>

<supplementary>
  [补充资料...]
</supplementary>

8. 反模式清单：这些错误会悄悄降低输出质量

常见失效模式

高级反模式

过度依赖 LLM 处理格式逻辑：能用代码做的 formatting、数值计算，不要让 LLM 做。正如 Anthropic 高级 Prompt 工程师 Zack Witten 所说：「如果不用去问 Oracle（模型），就别去问」。

提示词泄露风险：不要在 user message 中描述整个 system prompt 的结构，攻击者可能借此构建逃逸提示。

9. 场景化模板库：开箱即用的 Prompt 框架

9.1 通用分析模板

<role>你是一位资深分析师，擅长结构化问题分解</role>

<task>
  请分析：{topic}
</task>

<output_format>
  1. 核心发现（3条，每条不超过2句话）
  2. 风险/挑战（2-3条）
  3. 建议行动（按优先级排序）
  4. 置信度说明（你对此分析有多确定，有哪些前提假设）
</output_format>

请先思考，再输出。如有不确定之处，明确说明而非猜测。

9.2 代码审查模板

<role>
  你是一位高级软件工程师，专注于代码质量、安全性和可维护性。
  你直接、简洁，只指出真正重要的问题。
</role>

<context>
  语言：{language}
  用途：{purpose}
  审查重点：{focus_areas}
</context>

<code>
{code_here}
</code>

<task>
  请审查以上代码，按以下结构输出：
  - 严重问题（必须修复）
  - 改进建议（可选但推荐）
  - 值得保留的做法
  
  每条反馈说明：问题是什么、为什么有问题、如何修复（附代码片段）。
</task>

9.3 内容创作模板

<role>
  你是一位专业内容创作者，文字简洁有力，擅长用故事和类比解释复杂概念。
</role>

<brief>
  主题：{topic}
  受众：{audience}
  目的：{goal}
  字数：{word_count}
  语气：{tone}
</brief>

<examples>
  [可选：提供 1-2 个风格参考]
</examples>

<task>
  请按以上 brief 创作内容。
  先写一个 100 字以内的大纲给我确认，确认后再展开全文。
</task>

9.4 数据分析模板

<role>你是一位数据分析师，擅长从数据中发现业务洞察</role>

<data>
{data_or_description}
</data>

<task>
  请完成以下分析：
  1. 数据概览（关键统计指标）
  2. 主要趋势和异常
  3. 最重要的 2-3 个业务洞察（需说明依据）
  4. 数据局限性说明
</task>

<output>
  以 Markdown 格式输出，数值保留两位小数，
  关键数字用**加粗**标注。
</output>

9.5 决策辅助模板

<context>
  决策背景：{background}
  可选方案：{options}
  约束条件：{constraints}
  决策标准：{criteria}
</context>

<task>
  请帮我分析这个决策：
  
  步骤一：先列出我可能遗漏的重要考量因素
  步骤二：对每个方案，从{criteria}角度打分（1-5）并说明理由
  步骤三：给出你的推荐及核心理由
  步骤四：说明你的推荐依赖于哪些前提假设，如果这些假设不成立，结论会如何变化
</task>

9.6 执行官简报模板

角色：战略分析师
目标：为{audience}撰写关于{topic}的执行摘要
输出：5 条核心洞察 + 3 个风险 + 3 个下一步行动（不超过 200 字）
约束：避免行话；如引用数据需注明来源
评估标准：清晰度、有据可查性、可执行性

10. 迭代调优：像工程师一样打磨 Prompt

10.1 调优流程

1. 定义评估标准（什么叫"好的输出"？）
        ↓
2. 建立测试集（覆盖典型用例 + 边界情况）
        ↓
3. 跑基准测试（记录当前输出）
        ↓
4. 假设-修改-测试（一次只改一个变量）
        ↓
5. 记录每次变更及效果
        ↓
6. 达标后，再压测稳定性（多次运行是否一致）

10.2 常见调优方向

10.3 版本管理建议

prompt_v1.0_baseline.txt
prompt_v1.1_added_cot.txt
prompt_v1.2_xml_structure.txt
prompt_v2.0_few_shot.txt

每个版本记录：修改内容、修改原因、测试结果、决定保留/回退。

10.4 使用 LLM 自动优化 Prompt

以下是我的当前 prompt 和它产生的问题：

当前 prompt：
[...]

问题描述：
[...]

失败案例：
输入：[...]
期望输出：[...]
实际输出：[...]

请分析失败原因，并提供 3 个改进版本，说明每个版本的改进思路。

快速参考卡

┌──────────────────────────────────────────────────────────────┐
│                    Prompt 黄金法则速查                        │
├──────────────────────────────────────────────────────────────┤
│ 位置  │ 关键指令放开头+结尾，背景资料放中间                    │
│ 结构  │ 用 XML 标签隔离指令/数据/示例/格式                     │
│ 指令  │ 正向描述期望行为，而非否定禁止内容                     │
│ 示例  │ 3-5个多样化示例 > 无示例；示例放任务之前               │
│ 推理  │ 复杂任务加「请一步一步思考」触发 CoT                   │
│ 格式  │ 明确指定长度/结构/语气/格式，不留歧义                  │
│ 角色  │ 具体角色 > 泛化角色；包含经验/风格/受众描述            │
│ 迭代  │ 一次只改一个变量；建立测试集；记录版本                  │
│ 反思  │ 高风险任务用自洽性或自我反思提示增加准确率              │
└──────────────────────────────────────────────────────────────┘

参考：Anthropic / OpenAI 官方 Prompt 工程文档，以及 Lost in the Middle、Chain-of-Thought、Self-Consistency、Tree of Thoughts 等论文。