大语言模型在面对需要一次性完成过多任务的要求时，往往会表现不佳。如果你把一份五十页的 PDF 丢进聊天窗口，要求它同时进行结构化分析、风险评估和撰写执行摘要，结果通常是内容单薄、逻辑混乱或完全错误。更好的方法是机械化的。将任务拆分为离散的阶段。将第一阶段的输出直接传递给第二阶段，以此类推。Anthropic 将这种模式称为提示词链 (prompt chaining)。Google 则称之为顺序流水线 (sequential pipeline)。这两个名称描述的是同一件事：一条每个工位处理一种特定转换任务的装配线。

实际应用中的样子

与其使用一个巨大的提示词，不如构建一系列小而集中的步骤。想象一个处理供应商安全评估的合规团队。第一步从扫描的 PDF 中提取原始文本。第二步识别所有关于加密标准和访问控制的提及。第三步将这些发现与内部清单进行比对。第四步为安全负责人起草一份简短的备忘录。一个智能体将 PDF 转换为文本，下一个智能体从该文本中提取特定数据，最后一个智能体根据该数据编写摘要。这些步骤都不算多么光鲜，而且它们都不进行多任务处理。每个部分都只做好一件事情。

这就是为什么“装配线”这个比喻非常贴切。在工厂里，不会由一名工人组装整辆汽车。专业化分工能保持高质量并缩小故障模式。同样的逻辑也适用于语言模型。一个只要求 JSON 提取的提示词，比一个同时要求观点和格式化的提示词更不容易产生幻觉。

构建校验关口，而非凭空猜测

任何链条中最薄弱的环节都是交接。模型可能会返回礼貌的拒绝、一段 Markdown 而不是 JSON，或者一个截断的响应。如果这些垃圾数据流入第二步，整个链条就会崩溃。解决方法是设置一个“关口” (gate)。

关口不是模型调用，而是简单的代码。你在步骤之间编写一段短小的脚本。它可以检查输出长度以确保其不为空；它可以运行 JSON schema 验证以确认键值是否符合第三步的预期；正则表达式检查可以在构建下一个提示词之前，验证电子邮件地址或日期字段是否确实存在。这可以在你浪费金钱处理错误输出之前拦截错误。一个关口仅消耗微秒级的计算资源，而一次失败的下游 LLM 调用则会消耗 Token、增加延迟，并让你抓狂。

把这想象成工厂车间的质量检查点。你不需要 AI 来数零件，你需要的是一把尺子。

何时使用链式，何时停止

提示词链并不适用于所有问题。当工作流程具有固定、可重复的步骤时，请使用它。月度财务报告、标准化的合同审查和日志分析流水线都是很好的例子。如果你能将流程写成清单，那么你可能就可以使用链式处理。当你需要对复杂工作进行高精度处理时，也应该考虑使用链式。将问题分解为多个阶段，会迫使模型一次只处理一个逻辑层。最后，链式结构比单体提示词更容易调试。当摘要出错时，你可以检查提取过程；当提取出错时，你可以检查源文本。你拥有可以检查的中间产物。

当你无法预先确定步骤时，请避免使用提示词链。探索性研究、开放式头脑风暴或调查性任务并不遵循直线逻辑。如果速度是你的唯一优先级，也请跳过它。链式是串行的；第一步不完成，第二步就无法开始。如果你的步骤互不依赖，请改为并行运行。没有理由对同一份文档进行三次独立的翻译并进行链式处理。

僵化陷阱

这种结构化带来的权衡是僵化。固定的链条无法适应新情况。如果供应商发送了一个包含六个字段的表单，而你的 schema 校验关口预期的是五个，那么流水线就会停止。如果用户上传的是 Word 文档而不是 PDF，第一步就会出错，链条的其余部分也将无从下手。

更糟糕的是，错误会传播。早期发生的错误会流经整个链条。如果 PDF 提取器在财务数字中丢失了一个负号，下游的每一个步骤都会将那个错误的数字视为