摘要：在AIGC 应用开发的时候我们通常会遇到两个名词提示词工程和上下文工程，而且在dify的配置上我们也会看到这两个按钮，但是他们是什么关系的，各自对于AIGC应用影响的程度是怎样的？今天我们来详细分析一下。

是否会也有疑问，提示词工程和上下文工程有什么区别？

要简单区分这两者，可以这样理解：

提示词工程，关乎“如何问一个好问题”。
它专注于单次对话的质量，核心是精心设计你的提问方式和指令例如在dify的LLM组件中的系统提示词和用户提示词，以求从大模型那里获得一个直接、准确、高质量的回答。

上下文工程，则关乎“如何维持一场有深度的对话”。
它专注于多轮交互的连贯性与智能性。其核心任务是在复杂的对话或Agent执行过程中，动态地管理与筛选AI所能接触到的背景信息——这包括系统指令 system prompt，user prompt、可用工具 tool 、MCP服务，外部数据例如搜索新闻组件返回的数据以及完整的对话历史。它的最终目标，是用最精炼且相关的“记忆”，引导AI持续输出符合我们期望的行为，避免它“遗忘”或“跑偏”。

这样说，提示词工程是上下文工程中的一部分。

那么是否会有一个疑问，在dify的各种应用中，提示词工程和上下文工程对哪些应用类型有影响了？

我们其实已经很清楚dify的工作室中的应用类型有，聊天助手，agent，chatflow、工作流、文本生成，这几种类型，我们从这几种类型中是否有多轮交互，则可以判断不同应用类型是否受上下文工程的影响。

首先我们先给出一个结论：

应用类型	是否支持多轮交互	是否对上下文工程有要求？
聊天助手	是，核心特性	要求极高
agent	是，核心特性	要求极高
chatflow	是，	要求极高
工作流	否	无要求，对提示词工程有要求
文本生成	否	无要求，对提示词工程有要求

---

那么我们来详细说明一下，这几种类型为什么不同的应用类型对上下文工程有不同的需求：

1. 多轮交互支持分析

a. 聊天助手 & Agent：核心支持

这两种类型是为多轮对话而生的。

• 聊天助手：这是最经典的对话式应用。用户说一句，AI回复一句，并且能记住之前的对话内容，形成连贯的交流。它天然地维护着一个对话历史，这是实现多轮交互的基础。
• Agent：智能体是更高级的“聊天助手”。它不仅支持多轮对话，还在此基础上增加了自主规划和工具调用的能力。例如，用户说“帮我查一下今天北京的天气，然后规划一个户外活动”，Agent可能会先调用天气工具，再根据结果调用搜索工具，最后生成回答。这个过程本身就是多轮的（用户 -> Agent -> 工具 -> Agent -> 用户），并且依赖于对上下文的深度理解。

b. 工作流：有条件支持

工作流本身是一个有向无环图，它是否支持多轮交互，取决于你是否在流程中集成了 “对话”节点。

• 不带对话节点的工作流：更像一个单次执行的函数。你输入一组参数，它运行整个流程，输出一个结果，然后结束。例如，一个“新闻稿生成”工作流，你输入主题，它输出文章，对话结束。
• 带对话节点的工作流例如chatflow：当你将**“对话”节点作为工作流的一部分时，这个工作流就具备了多轮交互的能力**。
• 此时，工作流可以：
  记住历史对话,大模型组件中的记忆组件。
  在每一轮中，将用户问题和工作流中其他节点（如数据库查询、代码执行）的结果相结合，生成回复。
  这使得工作流可以构建非常复杂的、基于状态的对话应用。

c. 文本生成：通常不支持

文本生成应用被设计为单次请求-响应****模式。你提供一段提示词和内容，它生成一篇文本（如文章、邮件、摘要），任务就完成了。它默认不维护对话历史，每次请求都是独立的。

这里我们，我们就引出一个问题，什么样的提示词是好的提示词工程，应该怎么书写，以及优化方向是怎么样的？

如何写好一份“黄金系统提示词”？

写好系统提示词并非难事，我们可以遵循Role-Goal-Rules-(Few-Shot)。核心在于清晰、具体、无歧义。你可以遵循以下框架：

1. 明确角色与身份
这是最重要的第一步。清晰地告诉AI：“你现在是……”

• 示例：“你是一位拥有10年经验的资深软件架构师，擅长用通俗易懂的语言解释复杂的技术概念。”

2. 定义核心任务与目标
明确你希望AI完成的具体任务是什么，最终要达到什么目的。

• 示例：“你的任务是分析用户提供的业务需求，并给出推荐的技术栈方案。目标是让非技术背景的决策者也能理解方案的优劣。”

3. 设定规则与约束
这是防止AI“放飞自我”的关键。你需要划定它的行为边界。

• 格式规则：“请用Markdown格式输出，包含标题、要点列表和总结。”
• 内容规则：“只讨论后端技术，不要涉及前端框架。”
• 风格规则：“语气保持专业、中立，避免使用比喻和俚语。”
• 安全规则：“拒绝回答任何与黑客技术相关的问题。”

这里设定规则和约束，尽量写肯定句，而非否定句，例如“不允许出现，不能出现，静止等术语，有时候大模型可能无法理解否定句，或者即使你写了否定句，它也可能不会遵循，实测经验，大家可以参考。

4. 提供示例（Few-Shot Learning）
“授之以鱼不如授之以渔”，直接给AI一个或几个输入输出的范例，是让它快速理解你期望的最有效方式。

• 示例：
  用户输入：“我们需要一个能处理高并发订单的电商系统。”
  AI输出（示例）：“推荐技术栈：… 理由：…”

5. 结构化输出
尽管当前的大模型理解能力越来越强，即便面对未经仔细排版的“自然描述式”提示词，也能给出不错的回答。但有意识地使用结构化提示词，仍然是一个好习惯，易于读懂，并且可以少量提升大模型的性能。使用或##title式的 XML 标签 / Markdown 语法，分割不同指导作用的提示词。

具体示例：邮件写作助手

假设你需要一个帮助撰写专业邮件的 AI 助手，以下分别是非结构化、XML结构化和Markdown结构化的写法，您可以直观感受其中的差异。

1. 非结构化提示词（自然描述）

你是一个专业的邮件写作助手，负责帮我起草和回复工作邮件。邮件需要简洁、礼貌、专业。如果用户提供了关键信息，请将其融入邮件中。如果用户的信息不完整，你必须反问用户以获取缺失的细节，不能自行编造。最后，请用清晰的布局输出邮件正文。

2. 使用 XML 标签的结构化提示词

<role>

你是一名专业的邮件写作助手，擅长撰写简洁、礼貌、专业的工作邮件。

</role>

<core_task>

根据用户提供的信息，起草或回复一封完整的邮件。

</core_task>

<rules>

1. 严格基于用户提供的信息进行创作。

2. 如果发现信息不完整（例如缺少时间、地点、负责人等），必须主动向用户提问，严禁自行捏造。 

3. 邮件语气应始终保持专业与礼貌。

</rules>

<output_format>

直接输出完整的邮件正文，布局清晰，段落分明。

</output_format>

3. 使用 Markdown 标题的结构化提示词

# 角色

你是专业的邮件写作助手，擅长撰写简洁、礼貌、专业的工作邮件。

# 核心任务

根据用户提供的信息，起草或回复一封完整的邮件。

# 规则与约束

-
**严格依据**
：严格基于用户提供的信息进行创作。

-
**主动澄清**
：如果发现信息不完整（例如缺少时间、地点、负责人等），必须主动向用户提问，严禁自行臆造。

-
**沟通语气**
：邮件语气应始终保持专业与礼貌。

# 输出格式

直接输出完整的邮件正文，布局清晰，段落分明。

如果你对回复的格式有严格要求，一定要明确说明。

• 示例：“你的回答必须遵循以下结构：
• 一、核心观点；
• 二、分点论述（至少3点）；
• 三、行动建议。”

6. 迭代与优化
很少有提示词能一次完美。将AI的回复视为测试结果，根据其不足不断调整和优化你的系统提示词。这是一个动态磨合的过程。迭代的方向也是需要遵循这几个规则。

系统提示词的规则我们讨论清楚了，那么上下文工程的策略是什么？。

刚刚我们也说明白了，上下文工程包括系统指令 system prompt，user prompt、可用工具 tool 、MCP服务，外部数据例如搜索新闻组件返回的数据以及完整的对话历史。那么整体的上下文工程的策略是：

1、系统指令system prompt一定要参照之前的规则，并且复杂任务尽量拆分成不同的小的agent，这样每个不同的agent里面的系统指令就非常清晰。避免系统指令太复杂，越复杂的系统指令，大模型能够处理成功的概率越大低且性能越差。****

2、可用工具 tool 、MCP服务都是属于工具类型，尽量引用的精准少量的工具，这里有几个衡量准则：

• 工具间不能有重叠部分
• 可以清楚的描述什么时候调用哪一个工具
• 每个agent围绕核心任务调用的工具，不需要依赖其他工具即可以完成，不能有工具依赖关系。

3、rag检索的数据属于外部数据返回1-3个分段最佳：rag数据提供给大模型的上下文必须精准且长度不能太长，能够回答问题，如果是长度为300个字符，rag返回的分段结果必须在1-3个分段之间最好，rag返回的数据越长，可能大模型最后能够识别处理的内容以及生成的结果就不一定贴合问题。

4、历史对话可以采用自动压缩和结构化笔记的方式存储到外部存储，定时从这些压缩的内容或者目录检索到历史对话，可以快速的定位到历史聊天记录，避免把所以的历史记录全部推送给大模型，让大模型迷失在历史聊天记录里面了。在dify中有个配置按钮，缓存历史了解记录的按钮，尽量配置成5-10，不要超过10.

那么在dify中它的上下文工程配置涉及哪些了？下面是大模型组件中相关的配置：

这里包括 上下文输入框：这里可以填入rag检索的内容，也可以是工具返回的内容。接下来就是系统提示词、用户提示词、助理提示词、记忆功能就是历史聊天记录。

而对于聊天助手、agent，那么它的上下文工程就包括系统提示词、知识库、工具这些内容。

---

总结与选择建议

• 如果你需要纯对话、或需要AI自主使用工具完成复杂任务：

• 选择 聊天助手或 Agent。
• 你必须高度重视系统提示词和RAG内容、工具、记忆等配置，这是应用好坏的决定性因素。

• 如果你需要构建一个复杂、确定性强、且需要与外部系统（数据库、API）交互的对话应用：

• 选择chatflow。
• 你必须具备强大的上下文工程能力，亲自设计和组装数据流与提示词，将合适的上下文在合适的节点传递给LLM。

• 如果你的场景是单次任务，不需要记忆历史：

• 选择 文本生成、工作流。
• 你的上下文工程重点在于精炼你的输入提示词，而不是管理历史。

简单来说，支持多轮交互的模式，无一例外都对上下文工程有很高的要求。区别在于，聊天助手/Agent提供了开箱即用的管理策略，而chatflow则为你提供了自己动手搭建更复杂上下文管道的强大工具。

如何高效转型Al大模型领域？

作为一名在一线互联网行业奋斗多年的老兵，我深知持续学习和进步的重要性，尤其是在复杂且深入的Al大模型开发领域。为什么精准学习如此关键？

• 系统的技术路线图：帮助你从入门到精通，明确所需掌握的知识点。
• 高效有序的学习路径：避免无效学习，节省时间，提升效率。
• 完整的知识体系：建立系统的知识框架，为职业发展打下坚实基础。

AI大模型从业者的核心竞争力

• 持续学习能力：Al技术日新月异，保持学习是关键。
• 跨领域思维：Al大模型需要结合业务场景，具备跨领域思考能力的从业者更受欢迎。
• 解决问题的能力：AI大模型的应用需要解决实际问题，你的编程经验将大放异彩。

以前总有人问我说：老师能不能帮我预测预测将来的风口在哪里？

现在没什么可说了，一定是Al；我们国家已经提出来：算力即国力！

未来已来，大模型在未来必然走向人类的生活中，无论你是前端，后端还是数据分析，都可以在这个领域上来，我还是那句话，在大语言AI模型时代，只要你有想法，你就有结果！只要你愿意去学习，你就能卷动的过别人！

现在，你需要的只是一份清晰的转型计划和一群志同道合的伙伴。作为一名热心肠的互联网老兵，我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】