Prompt Engineering 完全指南

"提示词工程正在从一门艺术演变为一门科学。"
— 2025 年 AI 工程趋势

Prompt Engineering（提示词工程） 是设计和优化自然语言提示词的技术，用于引导大语言模型（LLM）生成准确、高质量的响应。随着模型能力的提升，这项技能正从单纯的"写提示词"演进为更系统化的 Context Engineering。

一、基础原则

1.1 提示词的核心要素

一个有效的提示词通常包含以下要素：

要素	说明	示例
任务（Task）	清晰描述你希望 AI 做什么	"翻译以下文本为英文"
角色（Role）	定义 AI 应扮演的角色	"你是一位资深软件架构师"
上下文（Context）	提供背景信息	"用户是一位 Python 初学者"
输出格式（Format）	指定期望的输出结构	"以 JSON 格式返回"
约束（Constraints）	设定限制条件	"回答控制在 200 字以内"
示例（Examples）	提供参考样本	Few-shot 示例

1.2 黄金法则

三大黄金法则

清晰具体：避免模糊表达，明确告诉模型你想要什么
提供上下文：给模型足够的背景信息来理解任务
迭代优化：提示词工程是一个持续实验和改进的过程

二、基础提示技术

2.1 Zero-Shot Prompting（零样本提示）

直接给出任务，不提供示例，依赖模型的预训练知识。

将以下句子翻译成法语：
"The quick brown fox jumps over the lazy dog."

适用场景	优势	局限
简单直接的任务	快速、Token 消耗少	对复杂任务效果有限
事实性问答	无需准备示例	格式控制较弱
通用翻译、摘要	适合快速测试	依赖模型内置知识

2.2 Few-Shot Prompting（少样本提示）

通过提供少量示例来引导模型理解任务格式和风格。

将情感分类为正面、负面或中性：

文本: "这家餐厅的食物太美味了！"
情感: 正面

文本: "服务很慢，体验一般。"
情感: 负面

文本: "今天的天气还可以。"
情感: 中性

文本: "这款产品完全超出了我的预期！"
情感:

2025 年研究发现

Few-shot 的效果并非普遍有效。研究表明：

示例的质量比数量更重要
某些高级推理模型上，Few-shot 反而可能降低性能
建议：始终进行 A/B 测试来验证效果

2.3 Chain-of-Thought（思维链提示）

引导模型逐步推理，显著提升复杂问题的解答能力。

简单版本：

请一步一步思考，然后回答：

问题：一个商店有 23 个苹果，卖出了 15 个，又进货了 8 个，现在有多少个苹果？

详细版本：

请按以下步骤分析这个问题：

1. 首先，识别已知信息
2. 然后，确定需要进行的计算
3. 接着，逐步执行计算
4. 最后，给出最终答案

问题：...

场景	提升效果
数学推理	显著提升
逻辑分析	显著提升
多步骤任务	明显提升
简单事实查询	无明显提升

注意

Chain-of-Thought 对 100B+ 参数 的大模型最有效。小模型可能产生不连贯的推理链。

三、高级提示策略

3.1 Tree-of-Thought（思维树提示）

探索多个推理路径，适合需要创造性或多角度思考的问题。

请从三个不同角度分析这个问题，每个角度独立推理，然后综合得出最佳答案：

角度 1：从技术可行性分析
角度 2：从商业价值分析
角度 3：从用户体验分析

问题：我们是否应该在产品中引入 AI 功能？

3.2 Self-Consistency（自一致性）

生成多个回答，选择最一致的结果，适合有明确正确答案的任务。

请用三种不同的方法解决这道数学题，然后比较三个答案，给出最可能正确的结果：

题目：...

3.3 Role Prompting（角色提示）

为模型分配特定身份，获得更专业、更有针对性的回答。

text

你是一位拥有 20 年经验的 Python 架构师，专注于高并发系统设计。
请以这个身份审查以下代码，指出潜在的性能问题和改进建议：

[在此处粘贴需要审查的 Python 代码]

3.4 Meta-Prompting（元提示）

让 AI 帮助优化提示词本身。

我想让 AI 帮我写产品描述。以下是我目前的提示词：

"写一段产品描述"

请帮我优化这个提示词，使其更加具体、结构化，能够产生更好的输出。

3.5 Recursive Self-Improvement（递归自我改进）

让模型生成初稿，然后自我批评和改进。

第一步：请生成一份关于可持续发展的报告大纲

第二步：现在请以批评者的身份审视这个大纲，指出不足之处

第三步：根据批评意见，生成改进后的版本

四、系统提示设计

4.1 系统提示的结构

Anthropic 10 组件框架

Anthropic 推荐使用以下结构来组织专业的系统提示：

任务上下文：定义 AI 的角色和任务
语气上下文：指定沟通风格
背景资料：提供必要的参考信息
详细任务描述与规则：明确要求和约束
示例：Few-shot 参考
对话历史：相关的历史交互
即时任务描述：当前需要完成的具体事项
思考步骤：引导逐步推理
输出格式：定义输出结构
预填充回复：引导开头以控制风格

4.2 系统提示示例

xml

<role>
你是一位专业的技术文档编写专家，擅长将复杂的技术概念转化为清晰易懂的文档。
</role>

<style>
- 使用简洁、专业的语言
- 适当使用类比来解释复杂概念
- 保持一致的术语使用
</style>

<constraints>
- 避免使用过于口语化的表达
- 每个段落不超过 5 句话
- 必须包含实际的代码示例
</constraints>

<output_format>
使用 Markdown 格式，包含：
1. 概述
2. 核心概念
3. 代码示例
4. 常见问题
</output_format>

<thinking>
在回答之前，请先在 <thinking> 标签中思考：
1. 目标读者是谁？
2. 他们可能面临的痛点是什么？
3. 如何组织内容使其最易理解？
</thinking>

五、平台特定最佳实践

5.1 Claude (Anthropic)

技巧	说明
使用 XML 标签	Claude 专门训练来识别 XML 结构，如 `<instructions>`、`<context>`、`<example>`
直接简洁	避免过度复杂的提示，直接说明需求
肯定式指令	告诉 Claude "做什么" 而非 "不做什么"
长文档放前面	对于长文档，将主要指令放在提示末尾
预填充回复	在 assistant 消息中预填内容来控制格式
思考标签	使用 `<thinking>` 标签引导深度推理

Claude 提示示例：

xml

<context>
用户是一位正在学习 React 的前端开发者，有 JavaScript 基础。
</context>

<task>
解释 React Hooks 中 useEffect 的工作原理。
</task>

<requirements>
- 使用类比帮助理解
- 提供 3 个实际使用场景
- 包含代码示例
</requirements>

<output_format>
使用 Markdown 格式，包含标题和代码块。
</output_format>

5.2 GPT-4 (OpenAI)

技巧	说明
System/User 角色分离	用 system 定义行为边界，user 提供具体查询
使用分隔符	用 `"""` 、``` 或 XML 标签分隔不同部分
明确且坚定的指令	GPT-4.1 严格遵循指令，明确的指令效果最佳
递归提示	让模型用自己的输出作为输入来改进结果
避免歧义	保持提示聚焦，避免多个混淆的指令

GPT-4 提示示例：

System: 你是一位资深的代码审查专家。你的任务是审查代码，找出潜在问题并提供改进建议。始终保持建设性和教育性的语气。

User: 请审查以下 Python 代码：

"""
def calculate_average(numbers):
    total = 0
    for n in numbers:
        total = total + n
    average = total / len(numbers)
    return average
"""

请按以下格式输出：
1. 发现的问题
2. 建议的改进
3. 改进后的代码

5.3 Gemini (Google)

技巧	说明
必须使用 Few-shot	Gemini 强烈推荐始终包含示例
精确简洁	Gemini 3 偏好逻辑性而非冗长表述
统一格式	在单个提示中保持一致的结构（XML 或 Markdown，不要混用）
关键指令置顶	将行为约束和角色定义放在开头
长上下文技巧	先提供所有上下文，最后放指令，用过渡语连接
多模态一致性	处理多模态输入时，确保指令清晰引用每种模态
控制输出详细度	Gemini 3 默认简洁，需要详细输出时明确说明

Gemini 提示示例：

text

# Identity
你是一位高级解决方案架构师。

# Constraints
- 不使用外部库
- 仅使用 Python 3.11+ 语法

# Output format
返回单个代码块，附带简短注释。

# Examples
输入: "创建一个函数计算阶乘"
输出:

    def factorial(n: int) -> int:
        """递归计算阶乘"""
        return 1 if n <= 1 else n * factorial(n - 1)

# Task
根据上述要求，创建一个函数来验证 email 格式。

5.4 平台对比总结

特性	Claude	GPT-4	Gemini
推荐结构	XML 标签	分隔符 + 角色分离	Markdown 标题
Few-shot	有帮助	有帮助	强烈推荐
长文档处理	指令放末尾	灵活	指令放末尾
推理引导	`<thinking>` 标签	"Think step by step"	逐步分解
多模态	支持	支持	原生优化
输出格式控制	预填充回复	明确指令	默认简洁

六、输出格式控制

6.1 常用格式指定

格式	指令示例	适用场景
JSON	"以 JSON 格式返回，包含 name、value 字段"	API 集成、结构化数据
Markdown	"使用 Markdown 格式，包含标题和代码块"	文档、报告
表格	"以表格形式展示，列包括..."	对比分析
列表	"以编号列表形式列出"	步骤说明、清单
XML	"使用 XML 格式输出"	数据交换、Claude 输出

6.2 JSON 输出最佳实践

请以 JSON 格式返回分析结果，严格遵循以下 schema：

{
  "summary": "string - 一句话总结",
  "key_points": ["string - 关键要点数组"],
  "sentiment": "positive | negative | neutral",
  "confidence": "number - 0 到 1 之间的置信度"
}

不要包含任何其他文本，只返回有效的 JSON。

Claude 2025 API 新特性

Claude 支持 should_write_json=true 参数和 JSON Schema 指定，可保证输出为有效 JSON。

七、常见问题与解决方案

7.1 常见问题

问题	原因	解决方案
输出过于冗长	未指定长度约束	添加 "简洁回答" 或字数限制
偏离主题	上下文不足或指令模糊	提供更多背景，细化指令
格式不一致	未明确格式要求	提供格式模板或示例
幻觉（虚假信息）	模型过度自信	要求引用来源，添加 "如不确定请说明"
推理错误	任务过于复杂	使用 Chain-of-Thought，分解任务

7.2 调试技巧

从简单开始：先用最简提示测试，逐步添加复杂性
隔离变量：每次只改变一个要素
查看推理过程：要求模型展示思考过程
使用边界测试：用极端案例测试提示的鲁棒性
记录实验：保存每次迭代的提示和结果

八、从 Prompt Engineering 到 Context Engineering

8.1 演进路径

8.2 Context Engineering 要点

Anthropic 观点

Context Engineering 不仅包括 prompt engineering，还包括系统指令中使用的 few-shot 示例、附加的用户背景、检索系统拉取的知识、工具返回的信息，以及模型条件作用的所有其他内容。

方面	Prompt Engineering	Context Engineering
关注点	单次提示的措辞	整个上下文窗口的信息组织
范围	静态文本	动态系统（工具、记忆、检索）
技能类型	写作技巧	系统设计
优化目标	单次响应质量	多轮交互和长任务表现

九、实用模板库

9.1 通用分析模板

<role>
你是一位 [领域] 分析专家。
</role>

<task>
请分析以下 [主题/数据]：
[内容]
</task>

<analysis_framework>
1. 概述：总结主要发现
2. 优势：列出正面因素
3. 劣势：列出需要改进的方面
4. 建议：提供可行的行动建议
</analysis_framework>

<constraints>
- 基于事实分析，避免主观臆断
- 每个要点用 1-2 句话说明
- 总字数控制在 500 字以内
</constraints>

9.2 代码生成模板

<task>
创建一个 [功能描述] 的 [编程语言] 函数/模块。
</task>

<requirements>
1. 功能需求：[详细描述]
2. 输入：[参数说明]
3. 输出：[返回值说明]
4. 错误处理：[异常情况]
</requirements>

<style_guidelines>
- 遵循 [语言] 最佳实践
- 添加清晰的注释
- 包含类型提示（如适用）
</style_guidelines>

<example>
# 类似功能的参考示例
[示例代码]
</example>

9.3 内容创作模板

<role>
你是一位专业的 [内容类型] 创作者，目标受众是 [受众描述]。
</role>

<task>
创作一篇关于 [主题] 的 [内容类型]。
</task>

<requirements>
- 语气：[正式/轻松/专业/友好]
- 长度：[字数范围]
- 结构：[期望的结构]
- 关键信息：[必须包含的要点]
</requirements>

<brand_voice>
[品牌调性描述，如适用]
</brand_voice>

<examples>
[风格参考示例]
</examples>

十、持续学习资源

10.1 官方文档

平台	资源
Anthropic	Prompt Engineering Guide
OpenAI	Prompt Engineering Guide
Google	Prompt Design Strategies

10.2 推荐阅读

Prompting Guide — 社区维护的提示词工程综合指南
Learn Prompting — 系统化的提示词工程教程
Anthropic Engineering Blog — Anthropic 技术博客，包含最新实践

10.3 论文与研究

论文	关键贡献
Chain-of-Thought Prompting (2022)	思维链提示的奠基论文
Self-Consistency (2022)	多路径推理取多数投票
Tree of Thoughts (2023)	探索式推理框架
Chain of Draft (2025)	简洁版 CoT，降低成本

十一、2025-2026 趋势

趋势	说明
Prompt as Code	提示词工程正变得更像编程，可模块化、测试、版本控制
自动提示优化	AI 可以自动生成和优化提示词
Context Engineering 崛起	从单次提示扩展到系统级上下文管理
多模态提示	结合文本、图像、代码的复合提示
模型自适应	模型越来越善于理解自然语言，降低"技巧"依赖
工具集成提示	为 Agent 设计工具调用提示成为核心技能

记住

最佳的提示词工程师不是最擅长"技巧"的人，而是最了解自己用例、最善于迭代实验的人。

← 返回 AI 知识库

Prompt Engineering 完全指南 ​

一、基础原则 ​

1.1 提示词的核心要素 ​

1.2 黄金法则 ​

二、基础提示技术 ​

2.1 Zero-Shot Prompting（零样本提示） ​

2.2 Few-Shot Prompting（少样本提示） ​

2.3 Chain-of-Thought（思维链提示） ​

三、高级提示策略 ​

3.1 Tree-of-Thought（思维树提示） ​

3.2 Self-Consistency（自一致性） ​

3.3 Role Prompting（角色提示） ​

3.4 Meta-Prompting（元提示） ​

3.5 Recursive Self-Improvement（递归自我改进） ​

四、系统提示设计 ​

4.1 系统提示的结构 ​

4.2 系统提示示例 ​

五、平台特定最佳实践 ​

5.1 Claude (Anthropic) ​

5.2 GPT-4 (OpenAI) ​

5.3 Gemini (Google) ​

5.4 平台对比总结 ​

六、输出格式控制 ​

6.1 常用格式指定 ​

6.2 JSON 输出最佳实践 ​

七、常见问题与解决方案 ​

7.1 常见问题 ​

7.2 调试技巧 ​

八、从 Prompt Engineering 到 Context Engineering ​

8.1 演进路径 ​

8.2 Context Engineering 要点 ​

九、实用模板库 ​

9.1 通用分析模板 ​

9.2 代码生成模板 ​

9.3 内容创作模板 ​

十、持续学习资源 ​

10.1 官方文档 ​

10.2 推荐阅读 ​

10.3 论文与研究 ​

十一、2025-2026 趋势 ​