为什么需要 Prompt Chaining
我们已经讲过 CoT（线性推理）、ToT（多路搜索）、Step-back（退一步思考）。它们都在单次对话内增强推理，但有一个共同上限：
所有思考都在一个 Prompt 里完成，受上下文窗口、目标冲突、中间结果不可复用三大限制。
举个真实场景：用户要"调研 10 款 AI 编程工具，输出对比报告并生成中文摘要"。塞进一个 Prompt 会有三个问题：
- 上下文爆炸：10 款工具的资料 + 对比逻辑 + 摘要生成，轻松超过 8K token
- 目标冲突：对比要客观中立，摘要要突出卖点，两个目标在一个 Prompt 里互相干扰
- 不可复用：如果想只重新生成摘要，必须把整个 Prompt 重跑一遍
Prompt Chaining 的解法：把任务拆成多个独立 Prompt 串联，每步只做一件事，输出喂给下一步。
Step 1: 调研工具 → 输出 JSON 列表
Step 2: 逐个分析 → 输出结构化对比
Step 3: 生成摘要 → 输出中文文案
每步独立可调试、可复用、可并行。
Chaining vs CoT/ToT 的本质差异
| 维度 | CoT / ToT | Prompt Chaining |
|---|---|---|
| 执行边界 | 单次对话 | 多次对话串联 |
| 上下文 | 共享一个窗口 | 每步独立窗口 |
| 中间结果 | 隐式（在思维链里） | 显式（结构化输出） |
| 可复用 | ❌ | ✅ |
| 可并行 | ❌（线性/树形） | ✅（DAG 编排） |
| 可调试 | ❌（黑盒） | ✅（每步可单独跑） |
| 适合任务 | 推理题 | 复杂工作流 |
关键区别：CoT/ToT 是"让模型想得更深"，Chaining 是"把工作流工程化"。前者是 Prompt 技巧，后者是系统架构。
三类经典链式模式
模式 1：线性链（Pipeline）
最简单的串联，每步输出喂给下一步：
[用户输入] → [Step1: 提取] → [Step2: 分析] → [Step3: 摘要] → [输出]
适用场景：数据处理、文档摘要、翻译润色。
示例：长文摘要
Step 1: 把长文按章节切块，每块 ≤ 2000 token
Step 2: 对每块生成摘要（可并行）
Step 3: 把各块摘要合并，生成总摘要
模式 2：扇出-汇聚（Fan-out / Fan-in）
一个任务拆成多个并行子任务，最后合并：
┌→ [Step A1: 调研工具1] ┐
[输入] ─┼→ [Step A2: 调研工具2] ┼→ [Step B: 合并对比] → [输出]
└→ [Step A3: 调研工具3] ┘
适用场景：多源调研、A/B 测试、多视角分析。
示例：竞品对比
Step A1-A5: 并行调研 5 个竞品（独立 Prompt）
Step B: 把 5 份调研结果合并为对比表
Step C: 基于对比表生成推荐结论
模式 3：路由-分发（Router）
先用一个 Prompt 判断任务类型，再路由到不同处理链：
[输入] → [Router: 判断类型] ─┬→ [链 A: 技术问题处理]
├→ [链 B: 闲聊处理]
└→ [链 C: 工具调用]
适用场景：客服机器人、多技能助手、意图识别。
示例：智能客服
Step 1 (Router): 判断用户意图（技术/商务/投诉）
Step 2: 根据意图路由到不同专家 Prompt
Step 3: 统一格式化输出
链路设计五原则
原则 1：每步只做一件事
❌ Step 1: 调研工具 + 对比 + 写摘要
✅ Step 1: 调研工具（输出 JSON）
Step 2: 基于JSON对比（输出表格）
Step 3: 基于表格写摘要（输出文案）
合并多个目标会让模型顾此失彼，输出质量下降。
原则 2：用结构化数据传递
❌ Step 1 输出: "Cursor 是一个 AI IDE，支持..."
Step 2 输入: 上面这段自然语言（歧义多）
✅ Step 1 输出: {"name":"Cursor","type":"IDE","features":["AI补全","Composer"]}
Step 2 输入: 上面这个 JSON（无歧义）
JSON 是 Prompt Chaining 的"通用语言"。
原则 3：高风险步骤加人工审核
Step 1: 生成邮件草稿
Step 2: 人工审核（yes/no）
Step 3: 若 yes → 发送；若 no → 回到 Step 1 修改
涉及发送、删除、支付的步骤，必须有人工 gate。
原则 4：能并行就并行
❌ Step 1 → Step 2 → Step 3 → Step 4 → Step 5（串行 5 分钟）
✅ Step 1 → (Step 2 | Step 3 | Step 4 并行) → Step 5（总 2 分钟）
并行能把链路耗时从 O(n) 降到 O(log n)。
原则 5：每步可独立调试
每个子 Prompt 都能单独运行、单独测试。如果某步输出异常，能精确定位到是哪个 Prompt 的问题，而不是整个链路重跑。
实战示例：用 Prompt Chaining 做内容生产
任务："写一篇关于 MCP 协议的技术博客"
Step 1: 生成大纲
输入: "写一篇 MCP 协议技术博客"
Prompt: "生成大纲，含 5-7 个章节，每章 2-3 个要点"
输出: JSON 格式大纲
Step 2: 扩写各章（并行）
输入: Step 1 的大纲
Prompt: "基于这个章节大纲，扩写为 800 字正文"
输出: 每章一段 Markdown
Step 3: 合并润色
输入: Step 2 的各章正文
Prompt: "合并为一篇文章，加过渡句，统一语气"
输出: 完整 Markdown
Step 4: 生成摘要与标题
输入: Step 3 的完整文章
Prompt: "生成 100 字摘要和 3 个备选标题"
输出: {summary, titles:[]}
Step 5: SEO 优化
输入: Step 4 的摘要 + Step 3 的正文
Prompt: "提取 5 个 SEO 关键词，优化 meta description"
输出: {keywords, metaDescription}
整个链路产出：大纲 + 正文 + 摘要 + 标题 + SEO 元数据，每步可独立复用。
常见误区
- 误区 1：链路过长。超过 7 步的链路调试成本爆炸，建议拆成多个子链。
- 误区 2：每步都用最强模型。简单步骤（如格式转换）用便宜模型，复杂步骤才用 GPT-4。
- 误区 3：不缓存中间结果。每步输出存数据库，避免重跑全链。
- 误区 4：把 Chaining 当 CoT 用。Chaining 是工程方案，不是推理技巧，别把它塞进单次对话。
- 误区 5：忽视错误传播。Step 1 的错误会传到 Step 5，必须在关键步骤加校验。
进阶技巧
- 条件分支：用 if/else 路由，如"若 Step 1 输出包含 error，跳到 Step 5 重试"
- 循环迭代：Step 3 输出质量分 < 8 分，回到 Step 2 重写
- 多模型混用：Step 1 用 Claude（理解强）、Step 2 用 GPT-4（生成稳）、Step 3 用 Haiku（便宜快）
- 结合 RAG：某些步骤挂知识库，让模型"查着答"
- 可视化编排：用 LangGraph、Dify、n8n 把链路画成 DAG 图
主流编排工具
| 工具 | 特点 | 适合 |
|---|---|---|
| LangChain LCEL | 代码式编排，灵活 | 开发者 |
| LangGraph | 状态机 + 图编排 | 复杂 Agent |
| Dify | 可视化拖拽 | 非技术用户 |
| n8n | 通用工作流 + AI 节点 | 跨系统集成 |
| 自写脚本 | 完全可控 | 定制需求 |
与其他 Prompt 技巧的叠加
Chaining 是容器，可嵌入其他技巧：
| 组合 | 效果 |
|---|---|
| Chaining + CoT | 每步内部用 CoT 推理 |
| Chaining + Step-back | 某步先退一步抽象 |
| Chaining + ReAct | 某步调用工具 |
| Chaining + Self-Consistency | 某步多次采样取多数 |
小结
Prompt Chaining 不是"想得更深"，而是"做得更稳"——把复杂任务工程化为可调试、可复用、可并行的流水线。当你发现单个 Prompt 力不从心、任务有多个子目标、或需要多次迭代时，就是把任务拆成链路的时候。
本系列下一篇将进入 少样本学习：Few-shot Prompting，看如何用 2-3 个示例让模型快速学会新任务。