提示词链(Prompt Chaining),把 AI 当成流水线工人

你可能写过这样的提示词:

请阅读下面这份市场报告,总结主要内容,找出三个趋势,分析每个趋势的商业价值,再写一封发给营销团队的邮件。

它看起来很省事,但经常会出现几类问题:

  • 报告总结得还行,邮件却忘了写;
  • 趋势提取错了,后面的分析和邮件一起跑偏;
  • 中间结果没有结构,下一步只能靠模型自己猜;
  • 让它输出 JSON,它夹了一段解释文字;
  • 报告里没有的数据,被它顺手「补」出来了。

这不是某一个提示词写得不够优雅,而是任务形态本身太挤了。你把理解、提取、判断、改写、格式控制和事实约束全塞进一次调用里,AI 很容易顾此失彼。

提示词链要解决的就是这个问题:

把复杂任务拆成多步;
每一步只完成一个明确任务;
前一步的输出,作为后一步的输入;
关键节点可以检查、重试、替换。

它不是把提示词写得更长,而是把 AI 当成流水线上的多个工位来设计。

一、先看一个 before / after

同一个目标:把一份市场报告变成发给营销团队的内部邮件。

做法写法常见结果
一次性提示词总结报告、提炼趋势、分析价值、写邮件全部放在一次请求里输出快,但容易漏要求、编造依据、格式不稳定
顺序提示词先总结,再提趋势,再写建议,最后写邮件每一步更清楚,但中间结果仍可能含糊
带检查的提示词链每一步有固定输出格式、校验条件和失败重试更适合复用,也更容易定位哪一步出错

这张表的重点不是「链越长越好」。提示词链真正有价值的地方,是它把一个模糊的大任务拆成了可以观察、可以替换、可以修复的小任务。

二、提示词链是什么

提示词链的定义很简单:

把一个复杂任务拆成多个步骤,让每一步的输出成为下一步的输入。

比如:

报告全文

报告摘要

趋势 JSON

营销建议

内部邮件

这很像工厂流水线。每个工位只处理自己负责的部分,上一站加工好的半成品,会交给下一站继续处理。

如果某一站出错,你可以只修那一站:

  • 摘要漏重点,就改第 1 步;
  • 趋势缺依据,就改第 2 步;
  • 邮件语气不合适,就改最后一步;
  • JSON 不合法,就在中间加格式校验。

不用每次都把整个任务推倒重来。

三、提示词链的四个动作:拆、接、控、查

提示词链不是把几个提示词随便排在一起。做得稳,通常要处理四件事。

1. 拆:把大任务拆成小步骤

第一步不是写提示词,而是拆任务。

比如「根据报告写一封营销邮件」,可以拆成:

1. 总结报告主要内容
2. 提取值得关注的趋势
3. 判断这些趋势对营销团队有什么价值
4. 转成可执行营销建议
5. 写成一封内部邮件
6. 检查邮件是否清楚、简洁、面向营销团队

拆得好的步骤有一个共同点:每一步都能单独判断好坏。

如果你看不出某一步是否合格,它就还没有拆清楚。

2. 接:让前一步输出成为后一步输入

提示词链的重点是「链路关系」。

不是这样:

提示词 A
提示词 B
提示词 C

而是这样:

第 1 步输出 → 第 2 步输入
第 2 步输出 → 第 3 步输入
第 3 步输出 → 第 4 步输入

例如第 2 步不能重新阅读整份报告自由发挥,而应该基于第 1 步的摘要继续处理。这样做的好处是,后面的任务更窄,错误也更容易定位。

3. 控:规定每一步的输出格式

提示词链最怕中间结果模糊。

如果第一步输出的是:

我觉得这份报告主要是在说用户变化比较大,还有一些关于品牌和消费趋势的东西。

第二步很难稳定继续处理。

更好的方式是让它输出固定结构:

{
  "main_findings": [
    "年轻用户更重视个性化推荐体验",
    "价格敏感型用户比例有所上升",
    "用户对售后响应速度要求提高"
  ]
}

结构越稳定,下一步越容易读取。只要后续步骤要接程序、校验字段或长期复用,就优先考虑 JSON、表格或固定列表。

4. 查:在关键节点做检查

提示词链不是一路往下跑就完事。前一步错了,后面会带着错误继续生成。

常见检查点包括:

  • 摘要是否覆盖原文重点;
  • 趋势是否有依据;
  • JSON 是否能解析;
  • 字段是否完整;
  • 结论是否基于输入;
  • 最终结果是否符合目标读者。
流程图画布 · 115%
Mermaid 流程图加载中...

提示词链真正提升质量的地方,不只是「拆步骤」,还包括每一步可检查、可重试、可替换。

四、什么任务适合提示词链

只要任务满足下面任意一种情况,就适合考虑提示词链:

  • 步骤很多:写报告、做研究、生成方案;
  • 前后依赖明显:先提取信息,再分析,再生成结论;
  • 对格式要求高:抽取字段、生成 JSON、填表;
  • 需要中间检查:事实核对、格式校验、代码审查;
  • 容易跑偏:长文总结、多资料整合、多角色写作;
  • 需要组合 AI 和程序能力:AI 负责理解,程序负责计算和校验;
  • 需要稳定复用:客服工单、文档问答、内容生产流程。

常见应用可以这样理解:

场景链路示例
长文处理提取 -> 总结 -> 归纳 -> 改写
内容创作选题 -> 大纲 -> 初稿 -> 润色 -> 审校
数据抽取识别字段 -> 转成 JSON -> 校验 -> 入库
代码生成理解需求 -> 写伪代码 -> 生成代码 -> Review -> 修复
文档问答检索资料 -> 生成答案 -> 检查引用 -> 输出
客服工单分类 -> 提取订单信息 -> 查询系统 -> 生成回复

提示词链特别适合那些「一句话说不清楚,但拆开以后每一步都不难」的任务。

五、什么时候不要用提示词链

提示词链不是越长越专业。拆链本身也有成本:更多模型调用、更高延迟、更多中间状态、更复杂的调试。

下面这些场景不一定要用提示词链:

场景更合适的做法
简单问答直接问,必要时补充上下文
一次性低风险改写单次提示词足够
需要整体语感的短文不要拆得太碎,否则风格容易断
强实时交互过长链路会增加等待时间
精确计算、排序、去重让程序处理,AI 只负责提取和解释
输入本身很短、目标很明确先用单次调用,失败后再拆链

一个简单判断是:

如果你需要追踪中间结果、控制格式、定位失败原因,就值得拆成链。
如果你只需要一次性得到一个低风险答案,就不要过度设计。

六、完整案例:把一份市场报告变成营销邮件

现在把前面的原则落到一个完整例子里。

目标是:

输入:一份市场报告
输出:一封发给营销团队的简明邮件

如果直接让 AI 完成,任务太大。我们把它拆成四步。

第 1 步:总结报告

先让 AI 只做一件事:读报告,提炼主要内容。

你是一名市场分析助理。
 
请阅读下面的市场报告,并总结主要发现。
 
要求:
1. 不要加入报告中没有的信息;
2. 用 5 条要点输出;
3. 每条不超过 40 字;
4. 只输出要点列表。
 
报告内容:
{{report_text}}

预期输出:

- 年轻用户更重视个性化推荐体验
- 价格敏感型用户比例有所上升
- 可持续消费正在影响品牌选择
- 订阅式服务在部分品类增长明显
- 用户对售后响应速度要求提高

这一步的目标不是写得漂亮,而是把原文压缩成可继续使用的信息。

第 2 步:提取三个趋势

第二步只基于摘要找趋势。

你是一名趋势分析师。
 
请基于下面的报告摘要,提取 3 个值得营销团队关注的趋势。
 
输出 JSON,字段必须包含:
- trend_name:趋势名称
- evidence:摘要中的依据
- why_it_matters:为什么值得关注
 
要求:
1. 只能基于摘要内容;
2. 不要编造数据;
3. 必须输出合法 JSON。
 
报告摘要:
{{summary}}

预期输出:

{
  "trends": [
    {
      "trend_name": "个性化体验需求上升",
      "evidence": "年轻用户更重视个性化推荐体验",
      "why_it_matters": "营销内容需要根据用户偏好进行分层触达"
    },
    {
      "trend_name": "价格敏感度提高",
      "evidence": "价格敏感型用户比例有所上升",
      "why_it_matters": "促销策略和价值表达会影响转化效果"
    },
    {
      "trend_name": "服务体验影响品牌选择",
      "evidence": "用户对售后响应速度要求提高",
      "why_it_matters": "营销不能只强调产品,也要强调服务保障"
    }
  ]
}

这里使用 JSON,是为了让下一步准确读取趋势名称、依据和价值。

第 3 步:转成营销建议

第三步不急着写邮件,而是先把趋势转成可执行建议。

你是一名营销策略顾问。
 
请根据下面的趋势 JSON,为营销团队生成 3 条行动建议。
 
要求:
1. 每条建议对应一个趋势;
2. 建议要具体,不能空泛;
3. 输出 Markdown 列表;
4. 不要重复趋势原文。
 
趋势数据:
{{trends_json}}

预期输出:

- 针对不同用户偏好设计分层营销内容,例如新品推荐、价格优惠、服务保障分别匹配不同人群。
- 在促销活动中突出「性价比」和「限时权益」,降低价格敏感用户的决策成本。
- 在营销页面和邮件中加入售后响应、退换货便利性等服务承诺,增强用户信任。

这一步把「分析结果」变成「业务建议」。

第 4 步:生成邮件

最后一步才写邮件。

你是一名专业但表达自然的商务写作者。
 
请根据下面的营销建议,写一封发给营销团队的内部邮件。
 
要求:
1. 语气简洁、专业、自然;
2. 开头说明背景;
3. 正文列出 3 条建议;
4. 结尾说明下一步动作;
5. 不超过 400 字。
 
营销建议:
{{marketing_suggestions}}

预期输出:

主题:关于近期用户趋势的营销建议
 
各位好,
 
根据近期市场报告,用户在个性化体验、价格敏感度和服务保障方面的关注明显提升。建议后续营销内容重点调整三个方向:
 
第一,针对不同用户偏好设计分层内容,让新品推荐、优惠信息和服务保障分别匹配不同人群。
 
第二,在促销活动中更突出性价比和限时权益,帮助价格敏感用户更快做出决策。
 
第三,在营销页面和邮件中加入售后响应、退换货便利性等服务承诺,增强用户信任。
 
建议下一步结合现有用户分层,选择一个活动页面先做小范围测试。

这条链路的优势是:每一步都清楚、可检查、可替换。

如果趋势提取不好,只改第 2 步。如果邮件语气不合适,只改第 4 步。不用推翻整个流程。

七、用伪代码理解提示词链

面向小白,不需要一开始就上复杂框架。先看伪代码就够了。

def prompt_chain(report_text):
    summary = ai_call(
        prompt="请把报告总结成 5 条要点",
        input=report_text
    )
 
    trends_json = ai_call(
        prompt="请基于摘要提取 3 个趋势,并输出 JSON",
        input=summary
    )
 
    suggestions = ai_call(
        prompt="请基于趋势生成营销建议",
        input=trends_json
    )
 
    email = ai_call(
        prompt="请基于建议写内部邮件",
        input=suggestions
    )
 
    return email

这段代码表达了提示词链最核心的结构:

AI 调用不是一次,而是多次;
每次调用只负责一个明确步骤;
中间结果被保存下来,并传给下一步。

如果要更稳,可以加入检查:

def safe_prompt_chain(report_text):
    summary = ai_call("总结报告,输出 5 条要点", report_text)
 
    if not summary:
        return "摘要生成失败,请检查输入内容"
 
    trends_json = ai_call("提取趋势,输出合法 JSON", summary)
 
    if not is_valid_json(trends_json):
        trends_json = ai_call("重新输出合法 JSON,不要解释", summary)
 
    suggestions = ai_call("基于趋势生成营销建议", trends_json)
    email = ai_call("基于建议写内部邮件", suggestions)
 
    return email

在真实工程里,这些检查非常重要。AI 输出不稳定是正常现象,系统要有能力兜住它。

八、从简单链到生产链

提示词链看起来简单,但要做得稳定,不能只靠「感觉」。一个可用于真实业务的链路,通常需要处理下面几件事。

设计点要解决的问题简单做法
单步职责一步做太多,容易漏要求每一步只产出一种结果
结构化输出下一步读不准上一步结果用 JSON、表格或固定列表
格式校验模型没有严格按格式输出检查 JSON、字段、长度
事实约束模型基于常识补内容要求每个结论带 evidence
重试机制一次失败就中断失败时带错误原因重试
日志记录出错后不知道哪一步坏了保存 step、input、output、status
人工确认高风险节点不能全自动在关键决策前暂停确认

例如日志至少可以记录:

{
  "step": "extract_trends",
  "input": "报告摘要内容",
  "output": "趋势 JSON",
  "status": "success"
}

这些日志能帮你回答:

  • 哪一步最容易失败?
  • 是输入不清楚,还是提示词不清楚?
  • 模型输出有没有格式漂移?
  • 哪个步骤最耗时、最贵?
  • 是否需要增加检查或重试?

如果要画成流程,一个更稳的提示词链通常长这样:

流程图画布 · 115%
Mermaid 流程图加载中...

这时你设计的已经不只是几个提示词,而是一条可维护、可检查、可优化的 AI 工作流。

九、提示词链和上下文工程是什么关系

提示词链经常和「上下文工程」一起出现。这两个概念容易混在一起,但关注点不同。

提示词链关注流程:

先做什么?
后做什么?
哪一步依赖哪一步?
中间结果怎么传?

上下文工程关注信息:

这一步需要哪些资料?
需要用户历史信息吗?
需要检索文档吗?
需要工具返回结果吗?
需要格式规范吗?

可以这样理解:

流程图画布 · 115%
Mermaid 流程图加载中...

提示词链是骨架,决定任务怎么走。上下文工程是材料,决定每一步给 AI 什么信息。

一个稳定的 Agent 系统,通常两者都需要。

十、最后给一份检查清单

设计提示词链时,可以按这份清单扫一遍:

1. 这件事真的需要拆链吗?
2. 每一步是否只做一件事?
3. 每一步的输入来自哪里?
4. 每一步的输出格式是否固定?
5. 哪些输出需要校验?
6. 校验失败后是重试、回退,还是交给人处理?
7. 哪些地方必须保留日志?
8. 哪些节点不能完全自动化,需要人工确认?
9. 最终结果是否回到了原始目标读者?

提示词链的核心不是「多写几个 prompt」,而是把 AI 工作拆成可观察的过程。

一旦过程能被观察,它就能被检查;一旦能被检查,它就能被修复和复用。