跳转到正文

Prompt Engineering 完全指南 ​

"提示词工程正在从一门艺术演变为一门科学。"

— 2025 年 AI 工程趋势

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


📌 与官方课程精读的分工

本文是提示词技术的系统梳理(技巧、模板、平台差异)。 Anthropic 官方课程精读 则从失败模式切入——每条技巧对应它解决的具体问题, 并附一张「已失效 / 依然有效」对照表。两篇互补:想查技巧看本文,想理解某技巧为何存在看那篇。

一、基础原则 ​

1.1 提示词的核心要素 ​

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

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

1.2 黄金法则 ​

三大黄金法则

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

二、基础提示技术 ​

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 推荐使用以下结构来组织专业的系统提示:

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

⚠️ 预填充(Prefill)在新模型上已被移除

在 assistant 轮预填内容以控制格式,是 Claude 3 时代的核心技巧,但在 Claude 4.6 及之后的模型上直接返回 400。

替代方案:用结构化输出 output_config.format 约束格式,或在系统提示词里明确要求「直接给出结果,不要前言」。

这十条结构的完整版本与顺序敏感性说明,见 Anthropic 官方课程精读 · 十元素复杂提示词结构。

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 "做什么" 而非 "不做什么"
长文档放前面对于长文档,将主要指令放在提示末尾
预填充回复⚠️ 已失效:Claude 4.6+ 返回 400,改用 output_config.format
思考标签⚠️ 已过时:思考已是模型原生能力,用 thinking: {type: "adaptive"} + effort 控制

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-shotGemini 强烈推荐始终包含示例
精确简洁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 平台对比总结 ​

特性ClaudeGPT-4Gemini
推荐结构XML 标签分隔符 + 角色分离Markdown 标题
Few-shot有帮助有帮助强烈推荐
长文档处理指令放末尾灵活指令放末尾
推理引导原生自适应思考(标签已过时)"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 调试技巧 ​

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

八、从 Prompt Engineering 到 Context Engineering ​

8.1 演进路径 ​

8.2 Context Engineering 要点 ​

Anthropic 观点

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

方面Prompt EngineeringContext 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 官方文档 ​

平台资源
AnthropicPrompt Engineering Guide
OpenAIPrompt Engineering Guide
GooglePrompt Design Strategies

10.2 推荐阅读 ​

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 知识库