提示链工程

单个提示词在复杂工作上失败，原因是可以预测的：你让同一次模型调用去检索信息、推理它、再验证结果，而大多数模型在单一指令下，这三件事里有一件擅长的、有两件勉强的，很少三样都强。提示词链工程，就是把这项工作拆成一个个离散的步骤，每一步都有自己的提示词，然后把上一步的输出接进下一步的输入。做得好的话，链式提示能提升准确率、让失败变得可读，还能让你在步骤之间插入校验。这篇指南用一个具体的构建案例、你会撞上的失败模式，以及决定"什么时候值得做链"的成本账，带你走一遍这套方法。

为什么单一提示词会在真实任务上崩掉

崩掉的往往不是答案，而是通向答案的路。用一句提示词让模型"总结这份合同里的风险，并起草一封给客户的函"，它就得在同一个上下文里同时握住合同、做法律分析、切换成函件语气、再格式化输出。这对一次调用来说太多了，而且劣化很隐蔽：摘要在漂移，函件听起来像摘要，你根本分不出是哪一步。链式拆解把认知拆开，让每一步只干一件事，出问题时你能精确知道是哪一环断了。

还有一层上下文预算的理由。冗长的单一提示词会烧很多 token 去重复指令和中间内容。一条链只带去下一步需要的东西，这让每次调用更便宜，也让靠后的步骤能跑在一个干净、紧凑的输入上，而不是一份臃肿的抄本。成本节省在你要反复跑的任务上是会复利的。

一条两步链的解剖

最小可用的链有一个转换步骤和一个校验步骤。转换把原始输入变成结构化的东西；校验在一切往下游流之前，拿转换的结果去对输入。设想一个邮件分诊任务。第一步拿一个未分类的收件箱，把每条消息分成紧急、常规、噪音，并输出一个带主题、发件人和一句话理由的结构化列表。第二步只拿那个列表，为紧急项起草回复。第三步校验每封紧急项是不是都有回复、有没有任何回复跟源邮件矛盾。每个提示词都短、聚焦、好调试：如果回复错了，你能立刻知道是分类那步还是起草那步造成的。

校验步正是多数人会跳过的那一步，也恰恰是让链可信的那一步。没有了它，你只是把错误挪了个地方而没有接住它。有了它，一条链就变成一道带闸门的小流水线，而不是一个黑盒。

构建你的第一条链：一个完整示例

我们来搭一条"内容精炼链"，把粗糙的研究笔记变成一份结构化简报。分段一：抽取。把原始笔记喂给模型，要求它返回一个带来源标签的声明列表，用 JSON 输出。分段二：结构化。把声明列表喂进去，要一份按主题分组的提纲；这个提示词看到的是干净数据，不是乱糟糟的笔记。分段三：起草。把提纲变成草稿，并明确指示不得捏造声明之外的事实。分段四：校验。把草稿跟声明列表比对，标出任何一句在来源列表里没有的陈述。这条链是四个短提示词，每个都便宜、每个都可测。如果简报里出现一个编造的事实，校验步会指名道姓，你只去修抽取或起草那步，而不是对着一个巨石提示词发呆。

在跑之前先把每一步的期望输出写下来。链之所以散架，原因往往是某一步假设了上一步实际没产出的格式。一开始就定好 JSON 键、段落名和校验规则，你的链就会变得可复现，而不是靠运气。

成本与延迟：决定是否做链的那笔账

链式用简单性换控制，而这个交换是有价格的。每一环都是一次独立的 API 调用，所以一条四步链要付四轮延迟，四份框架提示词外加 payload token。用于交互场景这能加上好几秒。反方向节省的是：每一步发出去的是更小、更干净的输入，也避免了在一个巨型提示词里反复解释整桩任务的浪费。是否划算取决于你的任务。对一次性、便宜、宽容的任务，单一提示词胜出。对重复、对错误敏感的流水线，链的控制权值得那多出来的调用。

在实践中好用的经验法则是：如果你没法清楚而客观地写出单一提示词的期望输出，你其实更适合做链，因为你正需要那个中间结构来定义"成功"。如果能写出来，就从单一开始，只拆那个一直失败的那一步。下表对比了团队构建和运行链的几种常见方式，好让你挑一条符合团队"搭建投入 vs. 控制权"容忍度的路径——从纯代码到可视化编排都有。

常见的链式失败与有效修复

第一种失败是格式漂移：某一步返回了散文，而下一步期望 JSON。修法是显式 schema、提示词里放一个一次性示例，以及一个带重试、能拒收畸形输出的解析步骤。第二种是错误放大：早期步骤的一个错误被烙进下游所有内容。修法是给风险最高的步骤之后建一道校验门，而不是放到最后。第三种是上下文坍缩：靠后的步骤只拿到一份摘要，丢掉了任务需要的细微之处。修法是传相关的那个切片，而不仅是摘要。第四种是过度拆分：把任务拆得太后，延迟和成本膨胀，准确率却毫无提升。修法是重新合并那些从来没有独立失败过的步骤。

用逐步骤日志来诊断链式失败。给每一环都记上输入和输出，这样你能重放一次失败的运行，精确看到信号在哪一环劣化了。这正是让任何可复现工作流都可调试的那种纪律，它也是"一条你信任的链"和"一条你盼着它别出事的链"之间的差别。

跨多模型的链式

一旦你对单模型链熟了，自然的延伸就是按步选模型。抽取和分类往往用便宜快速的模型就够了；起草受益于更强的生成器；校验可以挑一个被认为"指令遵循"更可靠、或用更便宜的模型做 sanity check。把步骤路由到不同模型，能同时降本提质，但也增加了配置和供应商面。先单向多模型跑，测出逐步骤失败率，再考虑换一种模型是否真的移动了指标。一次只移一步，这样你能归因变化。

链式和"评估提示词"的重叠

这里有个值得点破的摩擦：要构建一条好链，你需要那种课程的评估心态，而很多人会抄近道把它跳过。一门结构化 提示词工程课程 灌输的那种评分循环，正是你公平评判每一环所需要的东西。如果你是提示词新手，先打好底子再去链化，因为链会把一个薄弱核心放大成很多个失败点。一份实用的 提示词工程基础 会给你判断每一环所需的基线评估回路。更重要的是你要按序学会更深的技巧；知道 高级提示词工程 里的哪些模式该用在哪，能帮你别把一条本来一个好提示词就搞定的链，过度工程化。

让链可持续维护的工具

你可以在笔记本里用普通 API 调用飞快地原型化一条链，但生产链需要编排：重试、超时、结构化日志，以及每个提示词的版本管理。轻量包装器和工作流工具给你循环、条件判断（校验失败时重试、按输出类型分支）、以及存放提示词版本的地方。哪怕是一个只给每步记输入输出的薄包装，也会在第一次链在生产里失败、你需要知道为什么会这样时，立刻回本。链的目录结构跟工作的结构一样：把每一步的提示词、期望 schema 和测试用例放到一起，这样链既可审计又可重置。

一条已上线的链，以及它的教训

设想一个客服分诊团队，跑一条链去分类、总结、路由进来的工单。第一版是一个单一提示词，路由时常跑偏、把解法混进了总结。拆成分类、总结、路由，外加一道复核路由规则的校验门之后，错误路由大幅下降，团队也能在出漏子时精确指向某一步。两个能推广的教训：校验门接住了分类器漏掉的，拆分让失败变得可读而不是神秘。这就是提示词链工程的全部价值主张——不是更聪明的文字，而是可控、可检视的结构。

常见问题

提示词链值得那多出来的 API 成本吗？

只对错误敏感或重复的任务值得。一条四步链比单一提示词付更多调用和延迟，所以对便宜、宽容、一次性的工作不值得。对一条你天天跑、静默错误要赔钱赔口碑的流水线，校验门和可读的失败就让多出来的成本值了。算一下一次未被发现的错误让你损失多少，就得了盈亏平衡点。

一条提示词链应该有几步？

能少就少。从转换加校验开始，只有当一个可测量的失败明确指向某一步时才加。每一额外环都增加成本、延迟和一个新的失败模式，所以最优链是"逐步骤错误率你能检视并控制"的最短那条。如果某一步从没独立失败过，就把它并回邻居。

对重复工作流，链比微调更好吗？

它们解决的是不同问题。链给你可控性、可校验和逐步骤调试，不需要重训练，业务规则一变改个提示词就能跟上。微调会永久改变模型行为，还需要数据和重训。对大多数重复业务工作流，一条经评估的链比微调模型更好维护、改起来更安全，所以先做链，只有当某一步需要提示词管不住的一致风格时才去微调。

开始做提示词链最大的错误是什么？

还没学会两步链就先搭五步链。大家跳过校验步骤、用没命名的输出 schema，然后分不清是哪一环造成的失败。最大的错误是让你的第一条链长到超出了你能调试它的能力。把做那活儿的最短链搭起来，每步都记日志，只有当一次实测的失败逼你时才扩展。

校验步骤该和生成器用同一个模型吗？

不一定。用另一个模型做校验，能抓到生成器自己容易犯的错误，因为两个模型很少共享同一个盲区。实务上，审校常挑一个为指令遵循调优的模型，或用更便宜的模型做 sanity check。如果你的校验步什么都没发现，先试试换掉校验模型，再下结论说生成器很完美。

延伸阅读

想进一步掌握 AI 提示工程？这些同站中文指南能帮你深入：

• 提示工程课程
• 提示注入防御
• LLM 应用开发