Prompt/Context工程

熊135

436人浏览 · 2026-05-07 21:14:30

熊135 · 2026-05-07 21:14:30 发布

PE（Prompt Engineering，提示词工程），写好指令、话术、格式
（Context Engineering，上下文工程），把资料、历史、知识库、工具按流程喂给模型，有料可依

Prompt Engineering（提示工程）指的是通过精心设计和优化输入给大模型的文本指令（Prompt），来引导模型生成更准确、更符合预期的输出。它的核心是“问得好”，让模型理解你的意图。

Context Engineering（上下文工程）则更侧重于管理和组织提供给模型的背景信息（Context）。这包括系统指令、历史对话、知识库片段等，核心是“喂得好”，为模型提供充足且结构化的参考信息。

Prompt Engineering 是“怎么问”，Context Engineering 是“给什么背景”。

在实际开发中，如果混淆了这两个概念，很容易导致项目效果不佳。我总结了几种常见的“踩坑”场景：

过度依赖长Prompt，忽视上下文管理很多新手开发者喜欢把所有的规则、示例、知识都塞进一个超长的系统提示词（System Prompt）里，以为这样模型就能记住一切。结果往往是：

Token消耗剧增：每次对话都重复发送大量固定信息，成本高昂。
模型注意力分散：关键指令被淹没在海量背景信息中，模型可能“抓不住重点”。
问题：这本质上是把本该由Context Engineering解决的“背景信息提供”问题，错误地用Prompt Engineering（堆砌长Prompt）来处理。

将动态上下文误当作静态Prompt 在构建聊天机器人时，需要将历史对话作为上下文传递给模型，以实现连续对话。常见的错误是：

没有对历史对话进行有效的清洗、总结或截断，导致上下文很快超出模型的窗口限制（Context Window）。
当上下文超长时，简单粗暴地丢弃最旧的信息，可能丢失重要的对话主线。
问题：没有对动态变化的上下文（Context）进行工程化管理和优化，而是将其视为一个固定的、无需处理的Prompt部分。

试图用Prompt解决知识检索问题当需要模型基于特定知识库（如产品手册、公司制度）回答问题时，新手可能会尝试将整个知识库压缩成一段提示词。这几乎是不可能的，因为：

知识库通常远超模型上下文长度。
Prompt无法实现精准的“按需索取”信息。
正确做法：这应该通过Context Engineering中的检索增强生成（RAG）技术来解决，即先根据用户问题从知识库中检索出最相关的片段，再将片段作为上下文提供给模型。

提示词工程，或称Prompt Engineering，是一种专门针对语言模型进行优化的方法。它的目标是通过设计和调整输入的提示词（prompt），来引导这些模型生成更准确、更有针对性的输出文本。

在与大型预训练语言模型如GPT-3、BERT等交互时，给定的提示词会极大地影响模型的响应内容和质量。提示词工程关注于如何创建最有效的提示词，以便让模型能够理解和满足用户的需求。这可能涉及到对不同场景的理解、使用正确的词汇和语法结构，以及尝试不同的提示策略以观察哪种效果最佳。

使用分隔符清晰地表示输入的不同部分
要求一个结构化的输出，可以是 Json 、HTML 等格式
要求模型检查是否满足条件
提供少量示例
指定完成任务所需的步骤
指导模型在下结论之前找出一个自己的解法

明确具体：加入场景要求、具体任务

提供上下文：正确的区分不同的部分的内容（指令与背景信息使用符号区分）

正确的语法：使用正确的语法和拼写，避免使用过于技术性或不常见的术语

分步询问：复杂任务分步进行，提供引导或者示例

输出要求：提供输出要求，比如，结构化的输出

基础Prompt结构，公式

指令 + 输入数据 + 背景 + 输出要求

Prompt技巧

设定大模型的角色
为自己设定角色
明确问题并提供背景信息
限制回复长度与精确度
分阶段提问，让LLM 一步步思考
明确你的要求和目的
系统化设计你的自定义指令

Prompt框架

Co-STAR框架

Context（上下文）
首先，我们要了解的是“C”，也就是Context（上下文）。在这一部分，你需要告诉AI你为什么要写这个提示词。是为了提升工作效率？还是希望通过AI生成更吸引人的内容？把背景讲清楚，可以让AI更好地理解你的需求，从而提供更符合期待的回答。

Objective（目的）
接着是“O”，Objective（目的）。这个部分非常直观，你需要明确告诉AI，你通过这个提示词想要解决什么问题。无论是生成会议纪要，还是创作一篇热门文章，明确的目标能帮助AI更准确地定位其回应的方向。

Style（风格）
然后是“S”，即Style（风格）。这里可以选择你希望文本呈现的风格，比如现代简洁风、复古文艺风，或是国潮风格等。风格的选择将直接影响AI输出内容的形式和感觉。

Tone（语气）
“T”代表Tone（语气）。这一点也非常关键，它决定了AI回答的“声音”。是轻松幽默，还是正式严肃？根据你的场景和需要选择合适的语气，可以让AI的回复更加贴切。

Audience（受众）
接下来是“A”，Audience（受众）。你的目标读者是谁？是专业人士，还是普通大众？你的内容是为了教育、销售还是娱乐？了解你的受众，能帮助AI调整其内容的深度和风格，使之更加吸引目标读者。

Response（回应形式）
最后，“R”代表Response（回应形式）。这里你可以具体指定希望AI如何回答你的问题——是一篇详尽的文章，还是一个简明的列表？或者你有具体的字数要求？清晰的指示会让AI的输出更符合你的实际需求。

##Context（上下文）
在互联网营销的竞争中，吸引用户注意力是关键。为此，我们需要一个能快速生成创意且引人注目的营销文案的工具，以提高点击率和转化率。

##Objective（目的）
创建一款爆款文案生成器，帮助营销人员和内容创作者快速产生吸引眼球的广告文案，从而在激烈的市场竞争中脱颖而出。

##Style（风格）
文案风格需现代、年轻、充满活力，符合主流社交媒体平台的语言习惯，能够引起年轻用户的共鸣。

##Tone（语气）
语气积极向上，带有鼓励和启发的元素，同时兼具趣味性和亲和力，能够激发用户的好奇心和购买欲。

##Audience（受众）
主要面向互联网营销人员、自媒体运营者和小企业主，他们急需通过有效的文案来推广产品或服务。

##Response（回应形式）
希望AI能够提供多种格式的文案选项，包括但不限于标题、正文、和口号。每个文案建议包含500字范围内，以便于在各种广告平台上灵活使用。

RTF框架

RTF(Role-Task-Format)框架是一个非常简单通用的Prompt提示框架，我们和任意大模型对话场景下都可以使用该规范进行改进输出。

● R-Role(角色)：指定大模型担当固定角色(程序员、数据分析师、讲解员、记者等等)
● T-Task(任务): 任务，告诉大模型需要为我们做的事情
● F-Format(格式)：大模型最终结果的返回格式(比如：表格、Markdown、英文等等)

主要优点：
● 简单、方便。
● 指定Role角色，可以让大模型在当前的角色范围内回答知识，这在一些特定的领域中非常有效。
● 指定Role角色也能让工程上检索知识能够确定边界范围，配合元数据所发挥的威力会更强。
● 如果结合RAG知识内容检索，那么上下文回答的内容会让用户感觉更加是顺畅。

思考链模式

通过这种模式来逐步改善大模型的推理能力，非常适合一些复杂的任务处理。例如：
● 分析型或者逻辑推理型的任务
● 决策
● 解决问题(比如程序员根据错误日志找Bug)

而要使用这种模式，只需要在末尾添加”让我们逐步思考”即可。例如：

# 数据源（与指令区分）
user_datasource = """XXX……""" 

prompt1 = """分析一下在人工客服服务场景下，'''{user_datasource}'''中客户有哪些诉求。用一句话概括。"""
prompt2 = """分析一下在人工客服服务场景下，'''{user_datasource}'''中客户有哪些诉求。用一句话概括。让我们逐步思考。"""

# 模型输出结果
output1：在人工客服服务场景下，客户主要诉求为：微信账号存在安全风险导致无法添加好友、单点拦截、下载安装微信出现问题等，寻求客服协助解决问题。
output2：在人工客服服务场景下，客户主要诉求为：微信账号存在安全风险导致无法添加好友，以及因违规行为被限制登录，客户希望客服能够尽快处理这些问题。

# 分析结果
output1中的”单点拦截”并不是用户的诉求，而output2显然更加正确

RISEN框架

● R-Role:大模型扮演的角色
● I-Instructions: 指示命令，和Task-任务差不多
● S-Steps: 步骤
● E-End Goal: 最终目标
● N-Narrowing(Constraints): 缩小范围(约束条件)，和RTF框架中的Format有异曲同工之妙，一个是格式的约束，而这里的约束可以是任意方面，比如回答的内容(特定领域)、字数限制等等方面

该框架主要适合：
● 撰写具有特定约束的任务(例如博客文章)
● 有明确指导方针的任务（例如商业计划）

RODES框架

● R-Role: 角色
● O - Objective: 目标
● D - Details: 详细的细节
● E - Examples: 示例
● S - Sense Check: 感官检查

密度链模式

密度链模式Prompt是Salesforce、麻省理工学院和哥伦比亚大学的研究人员推出的一种新提示，它非常的高效，使用递归来创建越来越好的输出的提示，与普通提示生成的 GPT-4 摘要相比，它生成的摘要更加密集且更适合人们理解。

适合：
● 总结
● 改进您最喜欢的提示
● 通过递归生成可用的长格式内容

Prompt技术

1、零样本提示（Zero-Shot Prompting）

零样本提示是一种让模型在没有特定任务示例展示的情况下直接处理任务的技术。其原理在于模型经过大量数据训练和指令调整后，自身具备了一定的通用知识和任务理解能力。

prompt = "判断此文本的情感倾向为积极、消极或中性：这部电影情节紧凑，特效惊人。情感："
# 模型会依据自身预训练知识对这个提示进行处理并输出结果

2、少样本提示（Few-Shot Prompting）

少样本提示在零样本提示效果不佳时发挥作用。它通过为模型提供少量任务示例，帮助模型学习任务模式和规律。例如：

prompt = """“whatpu”是坦桑尼亚的一种小型毛茸茸的动物。一个使用 whatpu 这个词的句子的例子是：我们在非洲旅行时看到了这些非常可爱的whatpus。“farduddle”是指快速跳上跳下。一个使用 farduddle 这个词的句子的例子是："""
# 模型会根据前面的示例学习并生成新的句子

通过提供如上述新词汇造句的示例，模型能够模仿示例的结构和逻辑生成新的内容。不过在复杂推理任务中，仍需进一步优化。

3、思维链提示（Chain-of-Thought Prompting）

思维链提示旨在为模型提供清晰的推理步骤引导，从而显著提升其在复杂推理任务中的表现。它通过在提示中展示详细的推理过程，让模型学习如何逐步分析和解决问题。

4、自我一致性（Self-Consistency）

自我一致性技术主要用于优化思维链提示中的推理路径选择。其核心思想是通过提供多个少样本推理示例，让模型从多样的推理结果中筛选出最一致的答案，增强模型在算术和常识推理任务中的可靠性。

5、生成知识提示（Generated Knowledge Prompting）

生成知识提示主要用于解决模型在处理需要额外知识的任务时出现的局限性。它的操作方式是先让模型生成与任务相关的知识，再整合这些知识得出准确答案。

6、链式提示（Prompt Chaining）

链式提示是将复杂任务拆解为多个子任务，通过逐个子任务生成提示并传递结果的方式来实现复杂任务的有序处理。
这种方式提高了任务处理的准确性与可靠性，使得模型能够逐步深入地处理复杂问题。

7、思维树（ToT）

思维树框架是为了帮助模型应对复杂的探索性任务而设计的。它通过维护一棵思维树，让模型在解决问题时能够生成和评估中间思维步骤，并结合搜索算法进行系统性探索。

8、检索增强生成（RAG）

检索增强生成（RAG）技术将信息检索与文本生成相结合，专门用于处理知识密集型任务。它通过检索相关文档来为模型提供额外的知识支持，从而缓解模型的“幻觉”问题。
这有效确保答案基于可靠知识源，在自然问题、事实验证等基准测试中表现卓越。

9、自动推理并使用工具（ART）

自动推理并使用工具（ART）技术使模型能够自动生成包含推理步骤的程序，并在需要时调用外部工具。
在 BigBench 和 MMLU 基准测试中，ART 在多种任务上表现突出，显著超越少样本提示和自动 CoT 等方法，提升了模型解决问题的能力和效率。

10、自动提示工程师（APE）

自动提示工程师（APE）技术能够自动生成和筛选任务指令。它通过利用大型语言模型生成指令候选项，再依据评估分数选择最佳指令，从而提升提示生成的效率与效果。
例如总结新闻文章时，它先利用大型语言模型生成如“提取文章关键人物、事件和时间”“概括文章主要内容并突出重点”等指令候选项，再依据评估分数选择最佳指令，指导模型生成高质量总结。

11、Active-Prompt

Active-Prompt 技术主要用于解决思维链示例有效性的问题。它通过先查询模型生成多个答案，计算不确定度后挑选最不确定的问题由人类注释示例，再用新示例推断其他问题，从而优化模型对不同任务的适应性。

12、方向性刺激提示（Directional Stimulus Prompting）

方向性刺激提示通过训练策略 LM 生成引导提示，增强对模型生成结果的掌控力。

13、PAL（程序辅助语言模型）

PAL（程序辅助语言模型）技术让模型生成程序来解决问题，借助编程运行时提升解决复杂问题的能力。

14、ReAct 框架

ReAct 框架使模型交错生成推理轨迹和操作，提升答案的可靠性与可解释性。

15、自我反思（Reflexion）

自我反思框架包含参与者、评估者和自我反思三个模型，旨在帮助模型从错误中学习并提升性能。

上下文工程（Context Engineering）是一门专注于优化大语言模型上下文窗口使用的技术学科。它涉及如何在扩展的上下文空间中有效地组织、结构化、检索和利用信息，以最大化模型的理解能力和输出质量。

概括来说，Prompt Engineering 更偏“术”——讲究技巧和窍门；而 Context Engineering 则趋于“道”——讲究原理和系统方法。上下文工程将开发者的关注点从编写巧妙提示转移到打造高质量信息环境，本质上是一门关于信息配置和流水线优化的科学。

上下文的获取与生成、上下文的处理和上下文的管理