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

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

基础知识

Agent 智能体

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

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

特征维度	工具 (AI Tools)	助手 (AI Assistants)	智能体 (AI Agents)
触发机制	被动：由人类明确调用	响应式：响应用户查询	主动/半主动：基于目标自主规划
决策权	无：仅执行预定义逻辑	低：建议行动，由人决策	高：自主决定步骤、工具选择与执行顺序
状态与记忆	无状态（Stateless）	短期会话记忆	长期持久化状态，跨会话记忆
环境交互	单向输出	文本交互为主	感知环境 -> 推理 -> 行动 -> 观察结果 -> 循环
典型示例	图像识别 API、摘要生成器	ChatGPT 网页版、客服机器人	自主软件工程师（Devin）、自动驾驶系统

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

提示词、提示词工程、上下文、上下文工程

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

工程、软件工程

工程（Engineering）：一项精心计划和设计以实现一个特定目标的单独进行或联合实施的工作。

软件工程（Software Engineering）：研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

Prompt 与 AGI

Prompt 在人工智能，特别是 AGI 时代，扮演着至关重要的角色。它不仅是用户与 AI 模型如 ChatGPT 交互的桥梁，更是一种全新的「编程语言」，用于指导 AI 模型产生特定的输出。Prompt 工程成为了 AGI 时代的「软件工程」。

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

经验科学

又称实征科学，源自经验主义，其建立在经验证据的基础上，能够由其他研究者在相同条件下检验其有效性。

上下文（Context） 不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息，这些信息包括系统提示词、用户输入的问题、当前对话的历史消息、系统对你的历史记忆、工具返回的信息等等。

构建上下文的过程是完全动态的，并不是按照设计好的工作流去收集上下文，而是模型自己根据当前上下文状态去自主动态的调用工具收集上下文，并且不同的任务需要调用的工具也不一样。

sequenceDiagram
    participant Human
    participant Interface
    participant LLM
    participant Environment

    Human ->> Interface: Query

    loop Until tasks clear
        Interface ->> LLM: Clarify
        LLM ->> Interface: Refine
    end

    Interface ->> LLM: Send context
    LLM ->> Environment: Search files
    Environment ->> LLM: Return paths

    loop Until tests pass
        LLM ->> Environment: Write code
        Environment ->> LLM: Status
        LLM ->> Environment: Test
        Environment ->> LLM: Results
    end

    LLM ->> Interface: Complete
    Interface ->> Human: Display

上下文工程的概念也正是在 AI Agent 爆发的背景下诞生的。原来单纯靠提示词工程已经无法满足 AI Agent 产品的需求了，AI Agent 需要的更多的是为系统设计好工具、定义好工具和模型之间交互的数据格式、有效组织上下文信息提供给模型（内容长了要不要压缩、怎么压缩）等等。

上下文工程（Context Engineering），是一门为 AI 设计和构建动态上下文的学科，为大语言模型提供恰当的信息和工具，帮助模型高效完成任务。它是提示词工程的演进，体现了一种更宏大、更系统化的方法。

提示词的分类

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

提示词分类：

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

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

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

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

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

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

提示词的基本框架

提示词的基本结构：指令 + 上下文 + 用户输入 + 输出要求。

写一个好的 Prompt 公式：立角色 + 述问题 + 定目标 + 补要求。

好提示词	解释	示例
立角色	安上一个专家的头衔	- 你现在是一个小红书的运营 - 你现在是专业软件需求分析师与应用架构师
述问题	告诉它你的问题、背景、要完成的任务和实际情况	- 请帮 XX 公司汽车体验撰写 5 个问题
定目标	告诉它你希望它为你做什么，让大模型理解意图和目标	- 输出一份需求文档大纲
补要求	有什么需要它特别注意的	- 要求用法语输出

立角色

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

尝试使用不同的角色

对于相同的数据，数据科学家可能会看到与营销策略师不同的见解。而专门为世界 500 强公司进行客户洞察分析的数据科学家可能会产生又一种不同的结果。

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

述问题、定目标

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

测试你的问题是否足够具体和清晰的方法

让一个对任务了解很少的人展示你的提示词，并尝试让他们按照指示操作。如果它们感到困惑，那么说明你的提示词不够清晰。

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

补要求

技巧：

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

少样本 Few-Shot

使用 3-5 个多样化、相关的示例提示 LLM。对于复杂任务，示例越多，模型回答越好。使用示例能保证模型的准确性、一致性以及性能。

为了获得最大的效果，请确保示例是相关的、多样的（包含边缘情况和潜在挑战）、清晰的（使用一定的标签或分隔符以保持清醒的结构）。

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

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

不同类型的提示词

角色提示词 Role Prompting：角色提示对回答问题的性能上并不会有明显影响，但可能会在回答的文本风格这些因素上发生改变。如果想 hack 大模型，通常是个必不可少的手段。
风格提示词 Style Prompting：通过指定回复的风格、语调来调整模型的输出风格。与角色提示类似，对模型性能并不会造成影响。
情绪提示词 Emotion Prompting：将与人类心理相关的短语，例如「这对我的职业生涯很重要」告诉大模型。这可能会提高 LLM 在基准测试和开放式文本生成方面的性能。

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

提示词综合运用案例

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

假设验证法

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

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

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

对比分析法

技术选型对比：GraphQL vs REST API

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

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

错误预演法

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

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

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

元提示（Meta-Prompting）

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

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

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

请按上述三步骤进行。

动态角色切换

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

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

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

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

渐进式优化

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

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

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

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

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

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

多维度评估

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

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

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

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

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

反向工程法

目标：将页面加载时间从 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 自圆其说。

Role	内容
User	从这段产品描述中提取名称、尺寸、价格和颜色，并以 JSON 对象的形式呈现： `<description>` SmartHome Mini 是一款小巧的智能家居助手，有黑色和白色可选，售价仅为 49.99 美元。其宽度仅为 5 英寸，无论您将其放置在家中的何处，都能通过语音或应用程序控制灯光、恒温器和其他联网设备。这款经济实惠的小型集线器为您的智能设备带来了便捷的免提控制。 `</description>`
Assistant （预填充）	`{`
Assistant（来自大模型的回答）	`"name": "SmartHome Mini","size": "5 inches wide","price": "$49.99","colors": ["black","white"]}`

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

Role	内容
User (与 AI 扮演的夏洛克·福尔摩斯的第 50 轮对话)	你从这只鞋能推断出它的主人是怎样的人吗？ `<image>muddy_shoe.jpg</image>`
Assistant （预填充）	`[夏洛克·福尔摩斯]`
Assistant（来自大模型的回答）	哈！瞧瞧我们发现了什么？华生，这可是个稀罕物件！让我们用专业的眼光来审视这只鞋。你看这泥，并非伦敦常见的黏土，而是那种独特的红褐色——这种富含铁质的土壤，只有在汉普斯特德荒野一带才能找到。然而，鞋底的磨损痕迹却表明，它的主人走路的步伐……步态嘛，更像是惯于踩在白教堂区的鹅卵石上，而非荒野那平缓的坡地……

思维链 Chain-of-Thought

Wei et al., (2022)

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

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

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

使用思维链，可以：

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

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

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

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

少样本思维链

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

零样本思维链

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

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

引导式提示

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

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

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

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

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

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

结构化提示

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

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

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

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

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

自我一致性 Self-Consistency

Wang et al., (2022)

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

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：

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

当我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 应用的透明度，增加控制性和可靠性。这意味着您可以更容易地定位模型中的问题，分析并改进需要提高的不同阶段的性能。

链式提示的调试

如果 LLM 遗漏了某个步骤或表现不佳，将该步骤单独放在一个提示中。这样你可以微调有问题的步骤，而无需重做整个任务。

链式提示方法：

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

链式工作流示例

多步骤分析：参见下面的法律和商业示例。
内容创作流程：研究 → 大纲 → 草稿 → 编辑 → 格式化。
数据处理：提取 → 转换 → 分析 → 可视化。
决策制定：收集信息 → 列出选项 → 分析每个选项 → 推荐。
验证循环：生成内容 → 审查 → 改进 → 重新审查。

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

提示 1：

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

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

输出 1：

<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：

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

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

{{输出1}}

输出 2：

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

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 将生成及评估思维的能力与搜索算法（如广度优先搜索和深度优先搜索）相结合，在系统性探索思维的时候可以向前验证和回溯。

检索增强生成 RAG

Lewis et el. (2021)

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

RAG 把一个信息检索组件和文本生成模型结合在一起。RAG 可以微调，其内部知识的修改方式很高效，不需要对整个模型进行重新训练。RAG 会接受输入并检索出一组相关/支撑的文档，并给出文档的来源（例如维基百科）。这些文档作为上下文和输入的原始提示词组合，送给文本生成器得到最终的输出。这样 RAG 更加适应事实会随时间变化的情况。这非常有用，因为 LLM 的参数化知识是静态的。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 我需要搜索科罗拉多造山带，找到科罗拉多造山带东段延伸的区域，然后找到该区域的海拔范围。
操作 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)

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

Perspective-Taking，首先让大模型从上下文中提取出跟这个人有关的信息。
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#

深度思考模型下的提示词

应用场景

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

标准模式	深度思考模式
- 一般内容生成 - 基本编程辅助 - 常规代理任务 - 计算机使用指导 - 大多数对话应用	- 复杂分析：涉及多个参数和因素的金融、法律或数据分析 - 高级 STEM 问题：数学、物理、研究与开发 - 长上下文处理：处理和综合来自大量输入的信息 - 约束优化：具有多个相互竞争需求的问题 - 详细数据生成：创建全面的表格或结构化信息集 - 复杂指令遵循：具有复杂系统提示和需要考虑多种因素的聊天机器人 - 结构化创意任务：需要详细规划、大纲或管理多个叙事元素的创意写作

标准模式

深度思考模式

- 一般内容生成
- 基本编程辅助
- 常规代理任务
- 计算机使用指导
- 大多数对话应用

- 复杂分析：涉及多个参数和因素的金融、法律或数据分析
- 高级 STEM 问题：数学、物理、研究与开发
- 长上下文处理：处理和综合来自大量输入的信息
- 约束优化：具有多个相互竞争需求的问题
- 详细数据生成：创建全面的表格或结构化信息集
- 复杂指令遵循：具有复杂系统提示和需要考虑多种因素的聊天机器人
- 结构化创意任务：需要详细规划、大纲或管理多个叙事元素的创意写作

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

Prompt 的变化

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

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

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

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

问题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+ 字），请要求提供详细的大纲，包括段落级别的字数。然后要求深度思考模型将其段落索引到大纲中并保持指定的字数

案例：

示例	说明	标准提示	增强提示
复杂的 STEM 问题	复杂的 STEM 问题需要推理模型建立心智模型、应用专业知识并通过连续的逻辑步骤工作——这些过程受益于更长的推理时间。示例中的复杂的 4D 可视化挑战充分利用了长时间的延展思考，因为推理模型需要处理数学和编程的复杂性。	编写一个 Python 脚本，实现一个在正方形内弹跳的黄色球，确保正确处理碰撞检测。让正方形缓慢旋转。	编写一个 Python 脚本，实现一个在四维超立方体（tesseract）内弹跳的黄色球，确保正确处理碰撞检测。让四维超立方体缓慢旋转。确保球始终保持在四维超立方体内。
约束优化问题	约束优化挑战要求推理模型同时满足多个相互竞争的要求，这在允许长时间延展思考时效果最佳，使模型能够有条不紊地解决每个约束。有多个约束需要平衡，当给予更多空间来思考如何最佳地满足所有要求时，推理模型自然会表现得最好。	计划一个为期一周的日本度假。	计划一个 7 天的日本之旅，满足以下约束条件： - 预算 2,500 美元 - 必须包括东京和京都 - 需要适应素食饮食 - 偏好文化体验而非购物 - 必须包括一天徒步旅行 - 每天在不同地点之间的旅行时间不超过 2 小时 - 每天下午需要空闲时间打电话回家 - 必须尽可能避开人群
思考框架	结构化思考框架为推理模型提供了一种明确的方法论，当推理模型有足够的延展思考空间来遵循每个步骤时，这种方法可能效果最佳。通过指定必须按顺序应用的多个分析框架，思考时间自然会增加，因为推理模型需要有条不紊地处理每个框架。	为微软在 2027 年前进入个性化医疗市场制定一个全面战略。	为微软在 2027 年前进入个性化医疗市场制定一个全面战略。首先进行： 1. 蓝海战略画布分析 2. 应用波特五力模型识别竞争压力接下来，基于监管和技术变量进行四种不同未来的情景规划练习。对于每个情景： - 使用安索夫矩阵开发战略响应最后，应用三地平线框架来： - 绘制过渡路径 - 识别每个阶段的潜在颠覆性创新

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

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

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

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

Token 成本优化技巧

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

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

长文本提示的基本技巧

基本技巧：

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

您是一位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 导致关键信息被淹没。

解决方案:

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

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

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

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

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

解决方案:

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

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

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

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

解决方案:

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

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

减少幻觉

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

基本的幻觉最小化策略：

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

使用其他技术：

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

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

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

方法：

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

提示工程设计示例：

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

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

链式保障：

你是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 开头添加 ## 当前状态 部分

提示词是重要资产

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

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

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

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

后记

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

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

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

搞 Prompt 如同巫术，也许上帝不会回应你，但 AI 之神会。

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

从「确定性编程」到「概率系统工程」

如今，LLM 的工程生态已经完成了一次蜕变，但更大的挑战在于「人」的思维转型。对于算法研究员和应用开发者而言，全面拥抱 AI 和 LLM 新时代，意味着必须完成从传统软件思维到智能体思维（Agentic Thinking）的深刻跨越……

开发者习惯了 if-else 的确定性逻辑，但 LLM 本质上是概率性的。新的挑战在于如何在一个不确定的核心（LLM）之上构建可靠的系统。这要求我们掌握提示词工程（Prompt Engineering）来引导模型，利用评估驱动开发（Evaluation-Driven Development）来量化效果，并设计鲁棒的容错与回退机制。代码不再只是指令的集合，而是对模型思考过程的编排。

——微信公众号 @腾讯云开发者《大模型狂飙2025：一篇文理清从模型到智能体的架构演进》

本文参考

本文参考：

拓展资料：

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

Prompt 编写手册

基础知识

Agent 智能体

提示词、提示词工程、上下文、上下文工程

提示词的分类

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

提示词的基本框架

立角色

述问题、定目标

补要求

提示词综合运用案例

假设验证法

对比分析法

错误预演法

元提示（Meta-Prompting）

动态角色切换

渐进式优化

多维度评估

反向工程法

提示词的迭代步骤

图像模型提示词

其他提示工程技术

预填充 Prefill

思维链 Chain-of-Thought

少样本思维链

零样本思维链

引导式提示

结构化提示

自我一致性 Self-Consistency

链式提示 Prompt chaining

思维树 ToT

检索增强生成 RAG

ReAct 框架

System 2 Attention (S2A)

Simulated Theory of Mind（SimToM）

Rephrase and Respond (RaR)

Re-reading (RE2)

深度思考模型下的提示词

应用场景

Prompt 的变化

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

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

Token 成本优化技巧

长文本提示的基本技巧

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

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

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

减少幻觉

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

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

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

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

提示词是重要资产

后记

本文参考