提示链模式（Prompt Chaining）
将复杂任务分解为一系列更小、更聚焦的步骤，是构建可靠AI系统的关键。
🎯 什么是提示链？
提示链（Prompt Chaining），也称为管道模式（Pipeline Pattern），是一种处理复杂任务的强大范式。
核心思想
与其期望大语言模型用单一步骤解决复杂问题，不如采用分而治之策略：
复杂问题 → 步骤1 → 输出1 → 步骤2 → 输出2 → 步骤3 → 最终答案
↑ ↑ ↑
专注提示 专注提示 专注提示| 特征 | 说明 |
|---|---|
| 顺序执行 | 每一步按顺序执行，前后依赖 |
| 单一职责 | 每个提示只专注于一个具体任务 |
| 结果传递 | 上一步的输出成为下一步的输入 |
| 逐步推进 | 像接力赛一样，一棒传一棒 |
⚠️ 单一提示的五大缺陷
当你试图用一个复杂提示让模型一次性完成所有事情时：
| 问题 | 说明 | 比喻 |
|---|---|---|
| 指令遗忘 | 模型会忽略部分指令 | 同时布置10件事，只记住3件 |
| 上下文漂移 | 处理过程中逐渐偏离目标 | 写着写着就跑题了 |
| 错误放大 | 早期小错误在后续被放大 | 第一步错了，后面全盘皆输 |
| 信息不足 | 上下文窗口超限 | 文章太长，只能看到一部分 |
| 幻觉增加 | 认知负担过重导致胡编乱造 | 脑子一团乱，只好瞎编 |
失败案例
假设你给模型这个提示：
"请分析这份市场研究报告，总结核心发现，识别三大新兴趋势并附上具体数据，然后给市场团队写一封邮件。"
结果：总结可能还行，但提取精确数据时开始出错，写邮件时格式和语气可能完全不对。
✅ 提示链如何解决问题
顺序分解策略
将上面的任务拆解为三个独立步骤：
第一步（总结）：
"请总结以下市场研究报告的核心发现：[报告全文]"
第二步（识别趋势）：
"基于以上总结，请识别出三大新兴趋势，并提取支持每个趋势的具体数据：[第一步的输出]"
第三步（写邮件）：
"请起草一封简洁的邮件给市场团队，概述以下趋势及其支持数据：[第二步的输出]"
优势对比
| 优势 | 说明 |
|---|---|
| 降低认知负荷 | 每一步任务简单明确 |
| 易于调试 | 出错时可精确定位是哪一步 |
| 模块化 | 每一步可独立优化 |
| 可控性强 | 可在任意步骤介入修正 |
🎭 角色分配技巧
为每一步分配不同角色，提升专业性：
| 步骤 | 角色 | 作用 |
|---|---|---|
| 第一步 | 市场分析师 | 专业的报告总结 |
| 第二步 | 行业分析师 | 精准的趋势识别 |
| 第三步 | 专业文档撰写人 | 得体的邮件格式 |
📊 结构化输出：链条的润滑剂
为什么需要结构化输出？
如果第一步输出是模糊的自然语言：
"报告显示AI个性化很流行，大概70%多的消费者喜欢这样..."
传递给下一步时会：丢失精确数据、产生歧义、难以解析。
解决方案：使用JSON
{
"trends": [
{
"trend_name": "AI驱动的个性化",
"supporting_data": "73%的消费者更愿意与使用个人信息来提升购物体验的品牌合作"
},
{
"trend_name": "可持续与道德品牌",
"supporting_data": "ESG相关产品的销售额在过去五年增长了28%"
}
]
}好处：数据精确、机器可读、无歧义传递。
🔬 实战案例：智能文档分析助手
场景描述
用户上传一份技术文档，希望AI助手：
- 理解文档内容
- 提取关键概念
- 生成学习笔记
- 创建测验题目
单一提示方式（不推荐）
请阅读以下技术文档，理解其内容，提取所有关键概念并解释，
然后生成一份结构化的学习笔记，最后根据内容创建5道测验题目。
[文档内容...]问题：模型很可能在后半部分出错，概念解释不完整，测验题目质量低下。
提示链方式（推荐）
步骤1：文档理解与摘要
角色：你是一位技术文档分析专家
任务：请仔细阅读以下技术文档，生成一份结构化摘要。
要求：
- 识别文档主题
- 概括核心内容（3-5句话）
- 列出文档的主要章节
输出格式：JSON
{
"topic": "文档主题",
"summary": "核心内容摘要",
"sections": ["章节1", "章节2", ...]
}
文档内容：
[原始文档...]步骤2：概念提取
角色：你是一位技术概念分析师
任务：基于以下文档摘要，提取并解释所有关键技术概念。
输入：[步骤1的JSON输出]
要求：
- 识别5-10个关键概念
- 为每个概念提供简明解释
- 标注概念之间的关系
输出格式：JSON
{
"concepts": [
{
"name": "概念名称",
"explanation": "概念解释",
"related_to": ["相关概念1", "相关概念2"]
}
]
}步骤3：生成学习笔记
角色：你是一位教育内容创作者
任务：基于以下概念列表，生成结构化的学习笔记。
输入：[步骤2的JSON输出]
要求：
- 使用清晰的标题层级
- 包含概念定义、要点和示例
- 添加学习提示
输出格式：Markdown步骤4：创建测验题目
角色：你是一位考试出题专家
任务：基于以下学习笔记，创建测验题目。
输入：[步骤3的Markdown输出]
要求：
- 创建5道选择题
- 覆盖核心概念
- 提供答案和解析
输出格式：JSON
{
"questions": [
{
"question": "题目",
"options": ["A", "B", "C", "D"],
"answer": "正确选项",
"explanation": "解析"
}
]
}流程图示
┌─────────────────────────────────────────────────────────────────┐
│ 智能文档分析助手 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [原始文档] │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 步骤1：文档摘要 │ 角色：文档分析专家 │
│ │ 输出：JSON │ → 主题、摘要、章节 │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 步骤2：概念提取 │ 角色：概念分析师 │
│ │ 输出：JSON │ → 概念、解释、关系 │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 步骤3：学习笔记 │ 角色：教育内容创作者 │
│ │ 输出：Markdown │ → 结构化笔记 │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 步骤4：测验题目 │ 角色：出题专家 │
│ │ 输出：JSON │ → 题目、答案、解析 │
│ └────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘🔄 提示链 vs 上下文工程
什么是上下文工程？
上下文工程（Context Engineering）是一门系统性学科，研究如何在AI模型生成之前，为其构建一个完整的信息环境。
核心区别
| 维度 | 提示链 | 上下文工程 |
|---|---|---|
| 关注点 | 任务如何分解和执行 | 信息如何组织和提供 |
| 核心问题 | "怎么做？" | "知道什么？" |
| 比喻 | 流水线工序 | 厨师的备料台 |
| 层次 | 执行层（How） | 信息层（What） |
详细对比
提示链关注的是：
任务A → 任务B → 任务C → 结果
↓ ↓ ↓
分步执行 顺序传递 逐步构建- 如何将复杂任务拆解为简单步骤
- 如何串联各个步骤
- 如何传递中间结果
上下文工程关注的是：
┌─────────────────────────────────────┐
│ 完整的上下文 │
├─────────────────────────────────────┤
│ 系统提示：定义角色和规则 │
│ 检索文档：外部知识库内容 │
│ 工具输出：API调用的实时数据 │
│ 隐式数据：用户历史、身份、偏好 │
└─────────────────────────────────────┘
│
▼
[模型生成]- 模型知道什么信息
- 何时获取这些信息
- 如何使用这些信息
上下文工程的信息层次
| 信息类型 | 说明 | 示例 |
|---|---|---|
| 系统提示 | 定义AI运行参数 | "你是技术文档撰写者，语气正式精准" |
| 检索文档 | 主动获取的外部知识 | 项目规范、历史邮件 |
| 工具输出 | API返回的实时数据 | 日历空闲时间、天气 |
| 隐式数据 | 用户身份、历史、环境 | VIP客户、之前的对话 |
两者的关系
提示链是「怎么做」，上下文工程是「用什么做」。
它们是互补的：
- 提示链定义了任务的执行流程
- 上下文工程确保每一步都有充足的信息
实际应用对比
场景：帮用户安排会议
仅用提示链：
步骤1：理解用户需求 → 步骤2：生成会议邀请 → 步骤3：发送邮件问题：不知道用户日程、参会者关系、会议室可用性。
结合上下文工程：
┌─────────────────────────────────────┐
│ 上下文准备 │
│ ├─ 用户日历（工具输出） │
│ ├─ 参会者职级关系（隐式数据） │
│ ├─ 会议室预订系统（工具输出） │
│ └─ 过往会议纪要（检索文档） │
└─────────────────────────────────────┘
│
▼
步骤1：分析最佳时间 → 步骤2：生成个性化邀请 → 步骤3：预订并发送结果：生成的会议邀请高度相关、个性化、实用。
核心洞察
即便是最先进的模型，如果提供给它的运行环境视图是有限或结构不良的，其表现也会大打折扣。
上下文工程将任务重点从「回答问题」转变为「为智能体构建完整的操作全貌」。
📋 应用场景
适用场景
| 场景 | 说明 |
|---|---|
| 信息处理工作流 | 文档提取→总结→实体识别→报告生成 |
| 复杂问答 | 分解问题→分别研究→整合答案 |
| 内容创作 | 大纲→初稿→润色→排版 |
| 代码生成 | 需求分析→架构设计→代码实现→测试 |
何时使用提示链？
✅ 任务过于复杂，单个提示难以胜任
✅ 涉及多个独立的处理步骤
✅ 需要在步骤间与外部工具交互
✅ 构建需要多步推理的智能体系统
🔧 工具支持
| 框架 | 说明 |
|---|---|
| LangChain/LangGraph | Python生态，丰富的链式调用支持 |
| Google ADK | 谷歌智能体开发套件 |
| Semantic Kernel | 微软的AI编排框架 |
| FastMCP | 轻量级MCP协议实现 |
📝 核心要点
| 要点 | 说明 |
|---|---|
| 分而治之 | 将复杂任务分解为更小、更聚焦的步骤 |
| 依赖链 | 每一步的输出成为下一步的输入 |
| 可靠性提升 | 降低认知负荷，减少错误 |
| 结构化输出 | 使用JSON确保数据传递无歧义 |
| 角色分配 | 每一步分配不同角色提升专业性 |
🔗 相关阅读
参考资源：