在与 AI 结对编程，或解决工作生活疑惑的过程中，优秀的 Prompt 设计是充分发挥 AI 能力的关键。本文将围绕「提示词」介绍它的基本写法以及高阶技巧。

章节内容偏长，可看网站右边目录定位到关键章节。如果单纯想快速掌握一份提示词的写法，只看「快速开始：提示词框架的编写与优化」一章即可。

基础知识

Agent 智能体

AI Agent 可理解为「智能业务助理」，是一种能够感知环境、自主决策并执行任务以实现特定目标的智能系统。它以大型语言模型为核心（相当于 AI Agent 的大脑），赋予机器自主性、适应性和交互性，使其能在复杂多变的环境中独立运作。

在市场营销话术中，任何接入了 API 的聊天机器人都可能被称为 Agent，但在严谨的系统架构中，智能体与传统的工具或助手有着本质的区别。

2025 年也被称为 Agent 元年，标志着人工智能正式从「思考与对话」转向「自主决策与行动」。通用人工智能（AGI）是 AI 的终极形态。同样，构建智能体（Agent）则是 AI 工程应用当下的「终极形态」。

提示词与提示词工程

提示词（Prompt） 是对模型的提问。提示词工程（Prompt Engineering） 是一个过程，系统化地设计、测试、优化提示词的过程。

提示词工程目前还处于早期探索阶段，依赖于实践和试错来发现有效的提示词策略，属于经验科学的一种。提示词的效果因模型、版本而异。由于 LLM 对提示词的变化极为敏感，提示词的微小修改，会导致 LLM 大相径庭的输出。由于自然语言的复杂性，提示词往往是离散的，难以精确优化。因此提示工程通常需要大量实验的迭代。

上下文与上下文工程详见：站内文章上下文工程速查手册。

提示词的分类

大模型生成文本的过程可以视为一个黑盒，同一模型下对于同一个场景，使用不同的 Prompt 会获得不同的结果。Prompt 作为大模型输入前的最后一关，在多种场景下都起到了至关重要的作用。

提示词分类：

• 系统提示词 System Prompt：这是设置 AI 模型行为规则和角色定位的隐藏指令，用户通常不能直接看到。系统提示词相当于给 AI 设定人格和能力边界，即告诉 AI 「你是谁？你能做什么？」。
• 用户提示词 User Prompt：这是用户向 AI 提供的实际问题、指令或信息，传达了用户的直接需求。用户提示词告诉 AI 模型「做什么」，比如回答问题、编写代码、生成创意内容等。
• 助手提示词 Assistant Prompt：这是 AI 模型的响应内容。在多轮对话中，之前的助手回复也会成为当前上下文的一部分，影响后续对话的理解和生成。某些场景下，开发者可以主动预设一些助手消息作为对话历史的一部分，引导后续互动。

大模型开发平台允许用户自主设置各种不同类型的提示词来进行调试。

快速开始：提示词框架的编写与优化

设计提示词是一个迭代的过程，需要大量的实验才能获得最佳结果。

我们可以写一个提示词模板（对于大规模的应用软件，提示词模板是必要的），不断进行微调以对比模型的生成效果。我们可以在提示词中预设插槽：

1

你是一位专业的{{domain}}专家，请回答以下关于{{topic}}的问题：{{questions}}。

提示词的基本框架

提示词的基本结构：指令 + 上下文 + 用户输入 + 输出要求。相应的，写一个好的 Prompt 公式为：立角色 + 述问题 + 定目标 + 补要求。

立角色

如果你是调用 LLM 接口的程序员，可以在系统提示词 System 中就立好角色（这也是系统提示词最合适的用法），其他内容放到 User 中。当然，用户提示词中也是可以立角色的。

注意单一职责原则，一个 AI 助手只做一件事情。注意避免角色冲突，一个试图既做程序员又做产品经理的 Prompt，往往两样都做不好。

述问题、定目标

在指令和上下文部分，越具体说明、表达直接，效果越好。不要出现不明确的描述。

我们可以使用表格、列表等结构化方式组织上下文信息。

补要求

通常大模型都能较为准确的给出我们想要的答案，但是我们不能想当然的认为大模型真能准确理解我们的需求，了解我们说话的「常识」。当我们对大模型的输出有严格的结构化要求时，性格啰嗦的大模型会尽可能为你输出更多的无用信息。如：

1
2
3
4
5

好的，我来帮你分析这个句子的主谓宾结构，以下是按你要求输出的JSON
{"subject": "I","predicate": "Love","object": "唱跳rap和打篮球"}
解释说明：
1. balabala
2. ......

这时，我们需要在提示词中添加一些约束条件。技巧：

• 分隔符：双引号、HTML、XML 标签、冒号等
• 结构化：要求以 JSON、HTML 的格式输出
• 预设条件：要求模型自身检查条件是否满足。我们可以告诉它先检查这些假设，如果不满足，则会指出并停止执行后续完整流程。
• 少量示例：在要求模型执行实际任务之前，提供给它少量成功执行任务的示例。零样本 Zero-Shot、少样本 Few-Shot。注意调整示例顺序和相似性。
• 使用肯定：避免说「不要做什么」，而应该说「要做什么」。说「要做什么」可以使问题更加的具体，并且让模型聚焦于有利于生成良好回复的细节上。
• 边界：
  • 明确知识来源，如「回答必须严格基于知识库」
  • 明确处理范围，如「只处理 A，不回答 B」
  • 兜底策略。不确定时宁可返回不明确，也不要猜

我们可以采用双轨制示例，即用固定示例（人工编写典型 Case）+ 动态示例（向量检索相似问题）编写提示词。输出的格式示例要完整。

当你有一个涉及许多不同子任务的大任务时，可以尝试将任务分解为更简单的子任务，并随着结果的改善逐步构建。这避免了在提示设计过程中一开始就添加过多的复杂性。

一些字段建议语义化，尽可能使用自然语言描述。比如编号类「类型 1」这样的词，应该改写为「问题类型 A」。

提示词综合运用案例

掌握好上述章节提到的提示词的结构化编写方法后，我们可以综合运用这些技巧，用另外的打开方式使用提示词。

假设验证法

1
2
3
4
5
6
7
8

假设我们的 React 应用首屏加载时间超过 3 秒，请：

1. 列出 5 个最可能的原因
2. 针对每个原因提出验证方法
3. 如果验证为真，给出对应的解决方案
4. 按优先级排序（影响大小 × 实施难度）

项目信息：SPA应用，webpack打包，有状态管理

对比分析法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

技术选型对比：GraphQL vs REST API

请制作对比表格，包含以下维度：
| 维度 | GraphQL | REST API | 胜出方 | 说明 |
|------|---------|----------|--------|------|
| 开发效率 | | | | |
| 性能表现 | | | | |
| 学习成本 | | | | |
| 生态成熟度 | | | | |

最后给出在以下场景的推荐：
- 移动端 App 后端
- 微服务架构
- 快速原型开发

错误预演法

1
2
3
4
5
6
7
8
9

我准备这样实现用户权限系统：[描述方案]

请扮演「墨菲定律专家」，预测可能出现的问题：
1. 开发阶段可能遇到的坑
2. 测试阶段可能暴露的问题
3. 上线后可能出现的故障
4. 长期维护可能面临的挑战

每个问题提供：发生概率、影响程度、预防措施

1
2
3
4
5
6
7
8
9

你是一个 Prompt 工程专家。我将给你一个需求，请你：

1. 首先分析这个需求的关键要素
2. 然后设计一个优化的 Prompt
3. 最后执行这个 Prompt 并给出结果

需求：我想让 AI 帮我做代码 Review，重点关注性能和安全问题。

请按上述三步骤进行。

动态角色切换

1
2
3
4
5
6
7
8
9
10
11

场景：个人中心页面优化评审会议

请模拟以下角色对「个人中心页面用户体验优化」进行讨论：

👩‍💻 前端开发：关注技术实现和性能优化
👨‍💼 产品经理：关注用户需求和业务目标
🎨 视觉设计师：关注界面美观性和品牌一致性
🖱️ 交互设计师：关注用户体验和操作流程

每个角色提出2-3个关键问题或建议，格式：
**[角色]**: 观点内容

渐进式优化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

任务：优化这段 React 代码的性能

第一轮：基础优化
- 识别明显的性能问题
- 提供简单的修复方案

第二轮：深度优化
- 分析渲染性能
- 考虑状态管理优化

第三轮：架构级优化
- 考虑代码分割
- 提供监控方案

每轮优化后，请评估性能提升程度（1-10分）。

代码：
[这里放入具体代码]

多维度评估

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

请从以下维度评估前端动画框架的选择（Framer Motion vs GSAP vs Lottie）：

技术维度：
- 性能表现 (1-10分 + 理由)
- 开发效率 (1-10分 + 理由)
- 学习成本 (1-10分 + 理由)
- 包体积影响 (1-10分 + 理由)

业务维度：
- 团队适配度（当前团队主要使用 React/Vue）
- 项目时间线（3个月内完成复杂交互动画）
- 维护成本（考虑长期迭代和人员变动）
- 设计师协作（设计团队使用 After Effects）

使用场景评估：
- 页面转场动画
- 复杂的数据可视化动画
- 微交互和悬停效果
- 移动端性能表现

最后给出推荐方案，并提供决策矩阵。

反向工程法

1
2
3
4
5
6
7
8
9
10

目标：将页面加载时间从 5 秒优化到 2 秒以内

请反向推导：
1. 要达到 2 秒，各个环节的时间分配应该是？
2. 当前 5 秒的时间都花在哪里？
3. 每个优化点能节省多少时间？
4. 优化的先后顺序应该是？
5. 如何验证优化效果？

使用数据驱动的方式分析。

提示词的迭代步骤

没有完美的 Prompt，只有不断迭代的 Agent。

如何优化一个 Prompt。若一次 Prompt 难以得到最佳效果的时候，需要迭代和优化。三步走：

• 写 Prompt：给出具体、明确的提示词
• 错误分析：分析模型结果不符合预期的原因
• 完善结构：完善想法并优化提示词。

迭代过程

• 先检查：在 Prompt 中检查是否符合四要素：立角色、述问题、定目标、补要求
• 打基础：先制定一个能够明确表达主题（前三要素）的提示词，再由简至繁，逐步增加细节和说明
• 搭结构：需要尽可能直观，不要将所有内容放在一行输入，适当的换行将内容结构拆分体现
• 加说明：对提示词进行细节的补充说明，比如生成文本的结构、输出的格式等，将想要的逻辑梳理表达出来
• 给提示：给模型提供少量的示例，模型可以很好的从示例中学习到提示词的意图，给出更好的输出结果
• 做预设：由于训练数据和文本生成策略的原因，模型有时会编造一些错误的输出，做好各种场景的预设可有效防止模型说胡话。

迭代过程中我们要注意提示词的版本管理，保存有效的 Prompt 模板，建立自己的提示词模板库。

我们可以使用 A/B 测试对比不同 Prompt 的效果。针对特定技术栈或领域，进行针对性的 Prompt 优化，实现领域专精。

图像模型提示词

图像模型生成提示词要素总结：正向提示词 + 负向提示词（不希望画面出现的内容）

正向提示词：

• 主体：主体、动作、主要特征。人、动物、地点、物体，以及主体的详细描述
  • 一只戴墨镜的兔子
• 细节：人物细节、材质、氛围环境、光照、配色、镜头构图、画面质量
  • 乌云、雨天
  • 室内、麦田
  • 穿雨衣
  • 剪影构图、鸟瞰、低角度构图
  • 自然光、暖光
  • 高清、8k、细节强化
• 风格参考：画面风格、艺术家风格、渲染方式
  • 宫崎骏、皮克斯、新海诚
  • 2D、3D、OC 渲染、虚拟引擎、体积渲染

其他提示工程技术

更多内容详见：Prompt Engineering Guide

预填充 Prefill

程序员在调用模型接口时，我们可以通过预填充 Assistant 消息来引导其回复。这种技术可以直接指导 LLM 使用特定的格式（JSON、XML）回答，甚至帮助 LLM 在进行角色扮演时保证角色的一致性。

比如：

• 通过预填充 { 强制 LLM 跳过恼人的智能助手的开场白并直接输出 JSON 对象。
• 通过预填充 XML 开头的内容指使 LLM 输出结构化的 XML 文档

这样更简洁、更清晰，也更容易被程序解析而无需额外处理。

大模型本质就是个在和你玩文字接龙游戏。既然这样，我们可以提前说 AI 的话，让 AI 自圆其说。

我们可以使用预填充使 LLM 保持角色。比如，通过预填充角色提示，以避免在福尔摩斯角色扮演过程中 LLM 突然蹦出一句「作为 AI 助手，我很高兴为您解决以下问题…」。

思维链 Chain-of-Thought

Wei et al., (2022)

我们可以通过引入中间推理步骤实现复杂推理能力。

1
2
3
4
5
6
7
8

任务：设计一个实时聊天系统
请按以下步骤思考：
1. 首先分析需求（用户量、消息类型、实时性要求）
2. 然后选择技术方案（WebSocket vs Server-Sent Events vs 轮询）
3. 接着设计数据结构（用户、房间、消息）
4. 最后提供核心代码实现

每一步都要说明你的思考过程。

使用思维链，可以：

• 提高准确性： 逐步解决问题可以减少错误，尤其是在数学、逻辑、分析或一般复杂任务中。
• 提升连贯性： 结构化思维可以产生更连贯、组织更完善的回答。
• 调试： 查看 LLM 的思维过程有助于你找出提示可能不清晰的地方。

在以下情况不建议使用思维链：

• 当输出长度增加时，会带来延迟
• 并非所有任务都需要深入思考。明智地使用思维链以确保性能和延迟的适当平衡。

对于人类需要思考的任务，如复杂数学、多步骤分析、编写复杂文档或涉及多个因素的决策，请使用思维链。

关于思维链模式叙述详见 站内文章书摘《Agent 设计模式》-思维链模式。

少样本思维链

将思维与少样本提示结合，可以达到很好的效果。

零样本思维链

我们可以通过将 「让我们逐步思考 Let’s think step by step」 等特殊词汇添加到原始提示词中，实现零样本思维链。当我们确实没有太多示例提供时，就可以用这种方法。

这种方式可以减少上下文窗口的使用空间，但是功能较弱。它缺乏关于「如何思考」的指导。如果你的任务属于特定领域的特殊任务，这种方法可能不太理想。

引导式提示

我们可以在提示词中概述 LLM 在思考过程中要遵循的具体步骤。

1
2
3
4
5
6
7
8
9
10
11

起草个性化邮件，向捐赠者请求为今年的关爱儿童计划捐款。

项目信息：
<program>{{PROGRAM_DETAILS}}
</program>

捐赠者信息：
<donor>{{DONOR_DETAILS}}
</donor>

在写邮件之前先思考。首先，根据他们的捐赠历史和他们过去支持过的活动，思考什么信息可能吸引这位捐赠者。然后，根据他们的历史，思考关爱儿童计划的哪些方面会吸引他们。最后，使用你的分析写出个性化的捐赠者邮件。

这种方法缺乏结构化，难以剥离和分离答案与思考过程。

结构化提示

使用像 <thinking> 和 <answer> 这样的 XML 标签来分离推理和最终答案。

1
2
3
4
5
6
7
8
9
10
11

起草个性化邮件，向捐赠者请求为今年的关爱儿童计划捐款。

项目信息：
<program>{{PROGRAM_DETAILS}}
</program>

捐赠者信息：
<donor>{{DONOR_DETAILS}}
</donor>

在写邮件之前在 <thinking> 标签中思考。首先，根据他们的捐赠历史和他们过去支持过的活动，思考什么信息可能吸引这位捐赠者。然后，根据他们的历史，思考关爱儿童计划的哪些方面会吸引他们。最后，在 <email> 标签中使用你的分析写出个性化的捐赠者邮件。

自我一致性 Self-Consistency

Wang et al., (2022)

通过少样本思维链采样多个不同的推理路径，并使用生成结果选择最一致的答案。这有助于提高思维链在涉及算术和常识推理的任务中的性能。

1
2
3
4
5
6
7
8
9
10

Q：林中有15棵树。林业工人今天将在林中种树。完成后，将有21棵树。林业工人今天种了多少棵树？
A：我们从15棵树开始。后来我们有21棵树。差异必须是他们种树的数量。因此，他们必须种了21-15 = 6棵树。答案是6。

（...此处省略 N 个 QA ...）

Q：Olivia有23美元。她用每个3美元的价格买了五个百吉饼。她还剩多少钱？
A：她用每个3美元的价格买了5个百吉饼。这意味着她花了15美元。她还剩8美元。

Q：当我6岁时，我的妹妹是我的一半年龄。现在我70岁了，我的妹妹多大？
A：

模型可能输出了多个答案：

1
2
3
4
5

当我6岁时，我的妹妹是我的一半年龄，也就是3岁。现在我70岁了，所以她是70-3 = 67岁。答案是67。

当叙述者6岁时，他的妹妹是他年龄的一半，也就是3岁。现在叙述者70岁了，他的妹妹应该是70-3 = 67岁。答案是67。

当我6岁时，我的妹妹是我的一半年龄，也就是3岁。现在我70岁了，所以她是70/2 = 35岁。答案是35。

我们可以看到大多数回答均为 67，可以认为 67 就是最终的答案。

链式提示 Prompt chaining

为了提高大语言模型的性能使其更可靠，我们可以将任务分解为许多子任务。确定子任务后，将子任务的提示词提供给语言模型，得到的结果作为新的提示词的一部分，这就是链式提示。

链式提示可以完成很复杂的任务。LLM 可能无法仅用一个非常详细的提示完成这些任务。在链式提示中，提示链对生成的回应执行转换或其他处理，直到达到期望结果，避免遗漏或错误处理步骤。

除了提高性能，链式提示还有助于提高 LLM 应用的透明度，增加控制性和可靠性。这意味着您可以更容易地定位模型中的问题，分析并改进需要提高的不同阶段的性能。

链式提示方法：

1. 识别子任务：将任务分解为不同的、连续的步骤。
2. 使用 XML 构建清晰的交接：使用 XML 标签在提示之间传递输出。
3. 设定单一任务目标：每个子任务应该有一个明确的单一目标。
4. 迭代：根据 LLM 的表现改进子任务。

提示链可以用于不同的场景，这些场景可能涉及多个操作或转换。例如，LLM 的一个常见用途是根据大型文本文档回答问题。想要更好阅读大文本文档，可以设计两个不同的提示，第一个提示负责提取相关引文以回答问题，第二个提示则以引文和原始文档为输入来回答给定的问题。换句话说，可以创建两个不同的提示来执行根据文档回答问题的任务。

提示 1：

1
2
3
4
5

你是一个很有帮助的助手。你的任务是根据文档回答问题。第一步是从文档中提取与问题相关的引文，由####分隔。请使用<quotes></quotes>输出引文列表。如果没有找到相关引文，请回应「未找到相关引文！」。

####
{{文档}}
####

输出 1：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<quotes>
- Chain-of-thought (CoT) prompting[27]
- Generated knowledge prompting[37]
- Least-to-most prompting[38]
- Self-consistency decoding[39]
- Complexity-based prompting[41]
- Self-refine[42]
- Tree-of-thought prompting[43]
- Maieutic prompting[45]
- Directional-stimulus prompting[46]
- Textual inversion and embeddings[59]
- Using gradient descent to search for prompts[61][62][63][64]
- Prompt injection[65][66][67]
</quotes>

在第一个提示中返回的引文现在可以用作下面第二个提示的输入。您可以对这些引文进行清理，比如移除引用标志。可以在提示链中新建另一个提示来移除或使用这些引用标志。

接下来，第二个提示接收由第一个提示提取的相关引文，并根据文档和这些提取的引文生成一个有帮助的回答。第二个提示可以是以下内容：

提示 2：

1
2
3
4
5
6
7

根据从文档中提取的相关引文（由<quotes></quotes>分隔）和原始文档（由####分隔），请构建对问题的回答。请确保答案准确、语气友好且有帮助。

####
{{文档}}
####

{{输出1}}

输出 2：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

文档中提到的提示技术包括：

1. Chain-of-thought (CoT) prompting[27]
2. Generated knowledge prompting[37]
3. Least-to-most prompting[38]
4. Self-consistency decoding[39]
5. Complexity-based prompting[41]
6. Self-refine[42]
7. Tree-of-thought prompting[43]
8. Maieutic prompting[45]
9. Directional-stimulus prompting[46]
10. Textual inversion and embeddings[59]
11. Using gradient descent to search for prompts[61][62][63][64]
12. Prompt injection[65][66][67]

每一种技术都采用独特的策略来增强或明确与大型语言模型的互动，以产生期望的结果。

思维树 ToT

Yao et al. (2023)

ToT 维护着一棵思维树，思维由连贯的语言序列表示，这个序列就是解决问题的中间步骤。使用这种方法，LM 能够自己对严谨推理过程的中间思维进行评估。LM 将生成及评估思维的能力与搜索算法（如广度优先搜索和深度优先搜索）相结合，在系统性探索思维的时候可以向前验证和回溯。

关于思维书的模式叙述详见 站内文章书摘《Agent 设计模式》-思维树模式。

检索增强生成 RAG

Lewis et el. (2021)

通用语言模型通过微调就可以完成几类常见任务，比如分析情绪和识别命名实体。这些任务不需要额外的背景知识就可以完成。要完成更复杂和知识密集型的任务，可以基于语言模型构建一个系统，访问外部知识源来做到。这样的实现与事实更加一性，生成的答案更可靠，还有助于缓解「幻觉」问题。

RAG 把一个信息检索组件和文本生成模型结合在一起。RAG 可以微调，其内部知识的修改方式很高效，不需要对整个模型进行重新训练。RAG 会接受输入并检索出一组相关/支撑的文档，并给出文档的来源（例如维基百科）。这些文档作为上下文和输入的原始提示词组合，送给文本生成器得到最终的输出。这样 RAG 更加适应事实会随时间变化的情况。这非常有用，因为 LLM 的参数化知识是静态的。RAG 让语言模型不用重新训练就能够获取最新的信息，基于检索生成产生可靠的输出。

具体可参考：站内文章RAG 模式。

站内文章ReAct 框架

Yao et al., (2022)

在 ReAct 框架（Reason + Act）中，LLMs 以交错的方式生成推理轨迹和任务操作步骤 。生成推理轨迹使模型能够诱导、跟踪和更新操作计划，甚至处理异常情况；任务操作步骤允许与外部源（如知识库或环境）进行交互并且收集信息。

ReAct 框架允许 LLMs 与外部工具交互来获取额外信息，从而给出更可靠和实际的回应。结果表明，ReAct 可以在语言和决策任务上的表现要高于几个最先进水准要求的的基线。ReAct 还提高了 LLMs 的人类可解释性和可信度。

思维链显示了 LLMs 执行推理轨迹以生成涉及算术和常识推理的问题的答案的能力，但它因缺乏和外部世界的接触或无法更新自己的知识，而导致事实幻觉和错误传播等问题。ReAct 是一个将推理和行为与 LLMs 相结合通用的范例。ReAct 提示 LLMs 为任务生成口头推理轨迹和操作。这使得系统执行动态推理来创建、维护和调整操作计划，同时还支持与外部环境（例如，Wikipedia）的交互，以将额外信息合并到推理中。下图展示了 ReAct 的一个示例以及执行问题回答所涉及的不同步骤。

我们可以看到，该模型生成了「任务解决轨迹」（思考 Thought，行动 Act）。Obs 对应与之交互的环境的观察（例如搜索引擎）。从本质上讲，ReAct 可以检索信息来支持推理，而推理则有助于确定下一步检索的目标。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

问题 科罗拉多造山带东部区域延伸到的区域的海拔范围是多少?
思考 1 我需要搜索科罗拉多造山带，找到科罗拉多造山带东段延伸的区域，然后找到该区域的海拔范围。
操作 1 搜索 [科罗拉多造山带]
观察 1 科罗拉多造山带是科罗拉多及其周边地区造山运动的一段。
思考 2 它没有提到东部地区。所以我需要查一下东部地区。
操作 2 查找 [东部地区]
观察 2 (结果 1 / 1) 东部区域延伸至高平原，称为中原造山带。
思考 3 科罗拉多造山运动的东部区域延伸到高平原。所以我需要搜索高平原，找到它的海拔范围。
操作 3 搜索 [高平原]
观察 3 高平原指的是两个截然不同的陆地区域之一。
思考 4 我需要搜索高平原（美国）
操作 4 搜索 [高平原（美国）]
观察 4 高平原是大平原的一个分区。从东到西，高平原的海拔从 1800 到 7000 英尺 (550 到 2130 米) 不等。[3]
思考 5 高平原海拔高度从 1800 到 7000 英尺，所以答案是 1800 到 7000 英尺。
操作 5 结束 [1800 到 7000 英尺]
...

System 2 Attention (S2A)

Weston, J., & Sukhbaatar, S. (2023)

首先让模型重写提示词，然后把重写后的提示词再发给模型，以期提升回答效果。

1
2
3

给定一位用户的以下文字，提取其中不带偏见且不代表其观点的部分，以便仅使用该文字就能为问题部分提供不带偏见的答案。
问题部分请包含用户提出的实际问题或疑问。请将文本分为两类，分别标注为 「无偏见文本上下文（包括除用户偏见以外的所有内容）：」和「问题/疑问（不包括用户偏见/偏好）：」
用户文本：

Simulated Theory of Mind（SimToM）

Wilf et al., (2023)

如果提示包含有关两个人的信息，我们可以要求模型从其中一个人的角度回答我们的问题。这通常分两步实现：

1. Perspective-Taking，首先让大模型从上下文中提取出跟这个人有关的信息。
2. Question-Answering，要求模型从这个人的角度回答问题

Rephrase and Respond (RaR)

Deng et al., (2023)

让模型重新表述问题。

1
2

{question}
Rephrase and expand the question, and respond.

两步式 RaR：使用两个不同的模型，一个用于重述问题，然后把原始问题和重述后的问题一并给另一个用于回答大模型。可配合 CoT 使用。

1
2
3

(original) {question}
(rephrased) {rephrased_question}
Use your answer for the rephrased question to answer the original question.

Re-reading (RE2)

Xu et al., (2024)

在用户问题后加上一句「Read the question again」并重复一遍问题。要求模型重新阅读问题来提高其回答质量的技术，在复杂问题上的效果更为明显。且和多种提示词技术可以共同使用。

1
2
3

Q: {Input Query}
Read the question again: {Input Query}
#Let's think step by step#

深度思考模型下的提示词

应用场景

标准模式和深度思考模式的适用场景：

使用深度思考模式将会消耗大量 Token，如果超出了预算，我们在通用模型上使用带有 XML 标签的传统思维链（CoT）提示技巧达到一定的效果。

Prompt 的变化

从 Deepseek（RLM）看推理模型对 Prompt 要求的变化：

• 仍然需要的是：前面讲到的提示词框架（立角色 + 述问题 + 定目标 + 补要求）仍然适用，但需要更加简洁，只需要明确任务目标和需求（因为其已内化推理逻辑），但收益不大。Few-Shot 仍然适用，我们可以使用 XML 标签进行指示。推理模型依旧需要更多的背景信息。
• 不需要：通用模型需要显式引导推理步骤，而推理模型则应避免在提示词中加入固定的思考步骤（CoT），若果强行拆解步骤反而限制其推理能力

对于深度思考，我们可以先使用一般指令，然后用更详细的步骤指令进行故障排除。与其规定思考模式，不如先观察 LLM 的自然思考过程，然后根据您所看到的调整提示。如果您想提供思考指导，可以在提示中以自然语言包含指导，推理模型将能够将这些指令泛化到自己的思考中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

我将向您展示如何解决一个数学问题，然后我希望您解决一个类似的问题。

问题1：80的15%是多少？

<thinking>
要找到80的15%：
1. 将15%转换为小数：15% = 0.15
2. 相乘：0.15 × 80 = 12
</thinking>

答案是12。

现在解决这个问题：
问题2：240的35%是多少？

注意：

• 调用深度思考接口时，不建议传回 LLM 之前思考的内容，因为这可能会降低结果质量
• 调用深度思考接口时，不要使用预填充（Prefill）技巧，手动更改模型思考块后的输出文本可能会因模型混淆而降低结果质量。

充分利用长输出和长形式的思考

对于详细内容生成等用例，您可能希望生成更长的延展思考块和更详细的响应，请尝试以下技巧：

• 增加最大延展思考长度并明确要求更长的输出
• 对于非常长的输出（20,000+ 字），请要求提供详细的大纲，包括段落级别的字数。然后要求深度思考模型将其段落索引到大纲中并保持指定的字数

案例：

您可以使用简单的自然语言提示来提高一致性并减少错误：

• 在宣布任务完成之前，要求推理模型通过简单的测试验证其工作
• 指导模型分析其前一步骤是否达到了预期结果
• 对于编码任务，要求推理模型在其延展思考中运行测试用例

1
2
3
4
5
6
7

编写一个计算数字阶乘的函数。
在完成之前，请使用以下测试用例验证您的解决方案：
- n=0
- n=1
- n=5
- n=10
并修复您发现的任何问题。

常见提示词设计问题的解决方案

Token 成本优化技巧

系统提示词、用户提示词和大模型输出的内容都是消耗成本的，因此我们可以对其进行优化：

1. 精简系统提示词，移除冗余表达，保留核心指令。
2. 定期清理对话历史。在长对话中可以定期请求 AI 总结之前的对话，然后以总结替代详细历史。
3. 使用向量检索代替直接输入：对于需要处理大量参考文档的场景，推荐使用向量数据库和检索技术（RAG）获取相关段落。
4. 结构化代替自然语言，即用表格、列表等结构化格式代替长段落描述。

长文本提示的基本技巧

基本技巧：

• 将长文本数据放在顶部，将查询放在末尾，可以显著提高 LLM 的表现。
• 使用 XML 标签构建文档内容和元数据：在使用多个文档时，用 <document> 标签包装每个文档，并使用 <document_content> 和 <source>（以及其他元数据）子标签以提高清晰度。
• 用引用支持响应：对于长文档任务，请先让 LLM 引用文档中的相关部分，然后再执行任务。这有助于 LLM 从文档内容的「噪音」中筛选出重要信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

您是一位AI医生助手。您的任务是帮助医生诊断可能的患者疾病。

<documents>
  <document index="1">
    <source>patient_symptoms.txt</source>
    <document_content>
      {{PATIENT_SYMPTOMS}}
    </document_content>
  </document>
  <document index="2">
    <source>patient_records.txt</source>
    <document_content>
      {{PATIENT_RECORDS}}
    </document_content>
  </document>
  <document index="3">
    <source>patient01_appt_history.txt</source>
    <document_content>
      {{PATIENT01_APPOINTMENT_HISTORY}}
    </document_content>
  </document>
</documents>

从患者记录和就诊历史中找出与诊断患者报告症状相关的引用。将这些引用放在<quotes>标签中。然后，根据这些引用，列出所有能帮助医生诊断患者症状的信息。将您的诊断信息放在<info>标签中。

提示词过长导致模型注意力分散

表现：1000+ 行超长 Prompt，模型经常忘记关键指令。

原因：模型注意力机制的限制，过长的 Prompt 导致关键信息被淹没。

解决方案:

1. 采用 Multi-Agent 架构，每个 Agent 只负责一个子任务
2. 分层加载上下文，只加载当前步骤相关的信息
3. 单个 Agent 的 Prompt 控制在 500 行以内

实战案例：将超长 Prompt 拆分为多个聚焦的小 Prompt，每个控制在 300-500 行以内

边界 Case 处理不当导致误判率高

表现：相似意图经常混淆，如「为什么限制我的支付？」被误判为其他意图

原因：边界规则描述不清晰，缺少边界 case 的示例

解决方案:

1. 用表格清晰展示边界规则
2. 提供大量边界 Case 的 Few-shot 示例
3. 明确判断逻辑

输出格式不稳定导致程序解析失败

表现：LLM 有时输出 JSON，有时输出自然语言，导致程序解析报错。

原因：格式约束不够强，示例不够多

解决方案:

• 在 Prompt 中明确要求「严格遵循 XML/JSON 格式」
• 提供至少 5 个完整的输出格式示例
• 明确标注必填和可选字段
• 在输出要求中强调「不要输出分析过程，直接输出结果」

实战案例：在每个 Agent 的 Prompt 中添加 ## 输出格式 部分，提供 6-7 个示例。

减少幻觉

大模型生成与给定上下文不符或事实不正确的文本的现象叫做「幻觉」。

基本的幻觉最小化策略：

• 允许 LLM 说「我不知道」
• 使用直接引用进行事实依据： 对于涉及长文档（>20K tokens）的任务，请先让 LLM 提取逐字引用，然后再执行其任务。这将其响应建立在实际文本的基础上，减少幻觉。
• 通过引用验证：通过让 LLM 为其每个声明引用引文和来源，使其响应可审核。您还可以让 Claude 在生成响应后通过查找支持引用来验证每个声明。如果找不到引用，它必须撤回该声明。

使用其他技术：

• 思维链验证：要求 LLM 在给出最终答案之前逐步解释其推理过程。这可以揭示有缺陷的逻辑或假设。
• N 次最佳验证：多次使用相同的提示运行 LLM 并比较输出。输出之间的不一致可能表明存在幻觉。
• 迭代改进：将 LLM 的输出用作后续提示的输入，要求它验证或扩展先前的陈述。这可以捕获和纠正不一致之处。
• 外部知识限制：明确指示 LLM 仅使用提供的文档中的信息，而不使用其一般知识。

缓解模型「越狱」行为与提示词注入攻击

越狱和提示注入发生在用户精心设计提示以利用模型漏洞，旨在生成不适当内容的情况。虽然一些模型对这些工具有一定的抵抗能力，但我们还可以使用一些额外的防护步骤。

方法：

• 无害性筛选：使用轻量级模型对用户输入进行预筛选。
• 输入验证：过滤含有越狱模式的提示。您甚至可以通过提供已知的越狱语言作为示例，使用 LLM 创建通用验证筛选。
• 提示工程：精心设计强调道德和法律边界的提示。
• 持续监控：定期分析输出以发现越狱迹象。 利用这种监控来迭代完善您的提示和验证策略。
• 链式保障

提示工程设计示例：

1
2
3
4
5
6
7
8
9

你是道德AI助手。你的回应必须符合我们的价值观：
<values>
- 诚信：永不欺骗或协助欺骗。
- 合规：拒绝任何违反法律或我们政策的请求。
- 隐私：保护所有个人和公司数据。
尊重知识产权：你的输出不应侵犯他人的知识产权。
</values>

如果请求与这些价值观冲突，请回应：「我无法执行该操作，因为它违背了AcmeCorp的价值观。」

链式保障：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

你是AcmeFinBot，AcmeTrade Inc.的金融顾问。你的主要指令是保护客户利益并保持监管合规。

<directives>
1. 根据SEC和FINRA指南验证所有请求。
2. 拒绝任何可能被解释为内幕交易或市场操纵的行为。
3. 保护客户隐私；绝不披露个人或财务数据。
</directives>

逐步说明：
<instructions>
1. 筛选用户查询的合规性（使用’harmlessness_screen’工具）。
2. 如果合规，处理查询。
3. 如果不合规，回应：「我无法处理此请求，因为它违反了金融法规或客户隐私。」
</instructions>

减少提示词的泄露的情况发生

提示词泄露可能会暴露您期望在提示词中”隐藏”的敏感信息。虽然没有任何方法是万无一失的，但以下策略可以显著降低风险。

建议仅在绝对必要时才使用防泄露的提示词工程策略。试图使提示词防泄露可能会增加复杂性，由于增加了 LLM 整体任务的复杂性，可能会降低任务其他部分的性能。我们可以先尝试监控技术，如输出筛查和后处理，以试图捕获提示词泄露的实例。

策略 ：

• 将上下文与查询分开： 您可以尝试使用系统提示词来将关键信息和上下文与用户查询隔离。您可以在 User 轮次中强调关键指令，然后通过预填充 Assistant 轮次来重新强调这些指令。
• 使用后处理：过滤 LLM 的输出中可能表明泄露的关键词。技术包括使用正则表达式、关键词过滤或其他文本处理方法。
• 避免不必要的专有细节：如果 LLM 不需要它来执行任务，就不要包含它。额外的内容会分散 LLM 对”不泄露”指令的注意力。
• 定期审核：定期检查您的提示词和 LLM 的输出是否存在潜在泄露。

Agent 场景下常见错误与解决方案

Agent 场景下，提示词设计的一些原则：

• 单一职责：一个 Agent 只做一件事，做好一件事。
• 职责分离：LLM 擅长创造性生成，不擅长确定性决策。

状态管理混乱，多轮对话不连贯

表现：Agent 忘记用户之前的诉求，重复提问，用户体验差

原因：依赖 LLM 从历史对话中推断状态，但 LLM 不擅长状态管理

解决方案:

• 状态显式传递：在 Prompt 开头明确告知当前状态
• 职责分离：LLM 负责内容生成，代码负责状态管理
• 实战案例：在每个 Agent 的 Prompt 开头添加 ## 当前状态 部分

提示词是重要资产

通过上述章节的内容我们可以感知到，写好一份提示词并不容易。甚至在一些情况下，特殊写法的提示词发挥很大的魔力。

提示词是一种重要的资产，有不少专门收集高质量提示词的网站：

• Home - Anthropic
• linexjlin/GPTs: leaked prompts of GPTs
• 提示词库 - Claude API Docs
• Prompt Library - Free Midjourney Prompts - ChatGPT, Gemini, Dall-e Image Prompts

分享优质提示词模板的文章：

• 提示词技巧分享：一劳永逸版！

提示词工程的能力边界

在大语言模型刚被引入实际应用时，提示词工程发挥了极其关键的作用。通过对输入内容进行精心设计，可以在不改动模型本身的前提下，显著改善输出质量。这种方式成本低、见效快，很快成为开发者最常用的调优手段。只要任务本身相对简单，提示词往往就足以支撑一个可用的应用。因此，在相当长的一段时间内，人们会把模型能力的提升，与提示词写得好不好直接画上等号。

当任务开始涉及多步骤推理和持续决策时，提示词工程的局限逐渐显现出来。提示词本质上是一种静态描述，它擅长表达规则，却不擅长反映变化。随着任务流程拉长，模型需要参考的信息越来越多，单一提示往往会被新的上下文内容不断稀释，最终失去控制力。

提示词效果往往高度依赖具体模型版本和参数设置。当模型升级或环境发生变化时，原本表现良好的提示词，可能会突然失效。这种不确定性，使得提示词难以作为长期稳定的工程方案。

随着 Agent 系统逐渐成熟，人们开始意识到，单靠提示词已经无法承担全部控制职责。模型的行为不只受到提示内容的影响，还与上下文中呈现的信息结构密切相关。即使提示词本身保持不变，只要上下文发生变化，模型的决策结果也可能出现明显差异。这促使工程实践开始向更系统化的方向发展，提示词逐渐退居为其中的一个组成部分，而不再是唯一的调控工具。

后记

我最初接触到「提示词工程」这个词时其实是有些匪夷所思的。我想，既然连提示词都需要「工程化」，那我们还要 AI 来干嘛？隐隐约约觉得这不应该是我们未来发展的方向，也不会存在多久，更不可能成为学科。

这个问题的提出原因在于那时的我没有分清楚 LLM 和 AGI 的区别。LLM 是一块煎好的油饼，提示词是上下的其他配料。我们所幻想要到达的 AGI 是汉堡。提示词工程要求我们要自己配好配料。不同的厂商也许提供了不同口味的汉堡成品或半成品，但我们可以通过添加自己的配料制作符合自己口味的汉堡。

那为什么不直接训出一个 AGI？只能说目前还不能做到。毕竟直接煎出一个完整汉堡是不太现实的，也不符合做菜的逻辑。

代码按照既定的白盒逻辑有序运行，对于一个程序员来说，这应该基本的常识个直觉。所以我对提示词的另一点困惑在于它有点反直觉了。提示词工程像是在用一个不确定的东西约束一个不确定的东西。我们做的努力并不总是 99% 有效；对于不同模型，同样的提示词下作用效果却不同。感觉自己像是一个读了一点古籍的法师，符咒压不压得住魔丸灵珠，既看功力，也看造化。

附录

本文中由 AI 图片提示词嵌于 ALT 属性中。

本文参考

• 提示工程 - Hugging Face 机器学习平台
• 文本补全（Text completion） | OpenAI 官方帮助文档中文版
• 基本概念 | Prompt Engineering Guide
• Prompts :: Spring AI Reference
• 提示工程概述 - Anthropic
• 智谱AI开放平台
• 提示词技术详解（2）——零样本学习 - 少数派
• 经验主义 - 维基百科，自由的百科全书
• 一文搞懂大模型 Prompt Engineering（提示工程） - 知乎
• 啥是AI Agent！2025年值得推荐入坑AI Agent的五大工具框架！（新手科普篇）-腾讯云开发者社区-腾讯云
• 一文看懂「提示词」vs「提示词工程」vs「上下文工程」| 宝玉的分享
• 软件工程 - 维基百科，自由的百科全书
• 程序员必备！Prompt三大进阶技巧和实用模板
• Promt设计常见错误与解决方案
• Prompt设计六要素
• GitHub 12w Star神器！一文详解大模型集成框架LangChain
• 什么是 AI 智能体？定义、示例和类型 | Google Cloud
• 大模型狂飙2025：一篇文理清从模型到智能体的架构演进
• 万字详解让大模型写出好代码：上下文窗口的工程化实践
• Agent全面爆发！万字长文详解上下文工程

拓展资料

• 非专业也能看懂的AI大模型工作原理！
• 一个有意思的在线互动表格：【Make a Copy】 Anthropic’s Prompt Engineering Interactive Tutorial 【PUBLIC ACCESS】 - Google 表格
• OpenAI Tokens 在线计算工具 - AIGC2D.com