千问Prompt Chain教程：如何将复杂任务拆解为简单步骤

面对复杂的任务需求，直接向大模型提交冗长的提示词往往效果不佳。模型可能遗漏关键细节、混淆指令逻辑，或试图一次性生成不完整的答案。此时，将复杂任务系统性地拆解为一系列简单、有序的步骤，并通过“提示链”引导模型逐步执行，成为一种高效的工程化解决方案。

这不仅仅是简单分割长文本，而是需要一套严谨的设计方法。接下来，我们将详细解析构建稳健提示链的五个核心环节。

一、定义主任务并识别子任务边界

第一步至关重要：将复杂的最终目标，分解为逻辑清晰、边界明确的子任务。这类似于编程前绘制流程图，旨在理清执行路径与依赖关系。

如何操作？以一个典型需求为例：“根据用户提供的销售数据生成月度分析报告，需包含趋势图表、Top5产品清单及异常数据说明。”

首先，逐项解析指令。其中包含“输入”（销售数据）、“处理动作”（生成、包含）以及多个明确的“输出组件”（趋势图、Top5清单、异常值说明）。

接着，分析组件间的依赖关系。生成“趋势图”需先完成基础数据提取与计算；“异常值说明”则需基于“趋势图”结果来定位偏离正常范围的数据点。而“Top5产品清单”虽可独立计算，但为保持报告整体性，通常也安排在数据提取之后。

由此，依赖关系得以明确。可规划如下子任务序列：1. 数据提取与清洗 → 2. 计算核心指标（为趋势图和Top5做准备）→ 3. 生成趋势图 → 4. 基于趋势图识别并说明异常值 → 5. 列出Top5产品。每个子任务仅依赖前序输出或原始输入，确保每一步目标单一，避免交叉干扰。

二、设计带状态传递的链式 Prompt 模板

任务拆解完成后，需为每一步设计具体提示词。核心技巧在于“状态传递”——让模型清晰知晓“上一步进展如何，当前步骤该做什么”。

为第一个子任务编写独立提示词时，指令必须极其明确。例如：“请从以下JSON格式的销售数据中，提取各产品线的月度销售额，并以纯JSON格式返回，键名分别为product_name与monthly_revenue。”

模型完成此步后，将输出一个JSON。我们不应直接将其原始文本传递至下一步，而需用固定标签进行“封装”，例如转换为…。此封装体即为传递给下一步的“状态”。

因此，第二轮提示词可设计为：“基于中的数据，计算各产品线销售额的环比增长率，结果保留两位小数，返回一个包含product_name与mom_growth_rate键的JSON数组。”

可见，模型接收此指令时，能明确找到这一输入源，并理解需执行“计算增长率”这一单一操作。依此类推，每一步仅聚焦一个微小转换动作，并严格限定输出格式。这种设计显著降低了模型的认知负荷，并使输出结果高度可控、易于后续步骤解析。

三、使用分隔符与角色指令强制阶段隔离

即便传递了状态，模型有时仍会“过度思考”，试图跨步骤预测或总结。为强化每一步的专注度，需引入更强的“隔离”机制。

有效方法之一是在每轮提示词开头插入醒目的阶段标识符，例如“【阶段二：趋势识别】”。这如同为模型提供明确的章节标题，告知它：“请立即开始专注执行第二项任务。”

更进一步，可为每个阶段分配具体“角色”。例如，在需生成趋势图的步骤中，可指令：“你是一名数据可视化工程师，当前任务仅限于将输入的数字序列转换为SVG格式的趋势图描述文本。不进行任何解释，不生成总结，不输出任何其他内容。”

最后，在提示词末尾添加强制性约束：“仅输出SVG描述文本，开头为，除此之外不得包含任何额外字符、说明或标记。”

对于输入的“状态”，也可使用分隔符明确标定其范围。例如，将上一阶段的输出置于“===INPUT===”与“===END_INPUT===”之间。通过这一系列组合策略，模型“偏离轨道”的可能性被降至最低。

四、引入轻量校验反馈机制

链条越长，出错风险越高。某一步的输出格式若不符合预期，可能导致整个后续流程崩溃。因此，在每一步之后加入自动化的“质量检查点”至关重要。

此类检查无需过于复杂，通常为轻量级的格式或关键字段校验。例如，在第一步要求输出JSON后，可立即使用简单的正则表达式或关键词匹配，检查返回文本是否包含“product_name”这一必需键名。

若校验失败，系统不应直接进入下一步，而应自动触发“修正提示”：“检测到上一轮输出未包含product_name字段。请严格按以下模板重写：{‘product_name’: ‘产品名’, ‘monthly_revenue’: 销售额数值}。”

同时，需设置容错上限，例如最大重试2次。若超过次数仍失败，则将该子任务标记为并暂时冻结，同时将此错误状态作为元数据传递给后续步骤。后续步骤可读取此状态，并决定跳过、使用默认值或终止整个流程。如此，整个链条便具备了基础的健壮性。

五、采用函数调用风格封装子任务接口

当上述模式固定后，便可运用更工程化的思维管理整个提示链。一种优雅的思路是将每个子任务视为标准的“函数”。

为每个子任务定义清晰的“函数签名”，包括函数名、输入参数和输出格式。例如：`extract_revenue(data: json) → [{product_name: str, monthly_revenue: float}]`。

设计提示词时，可模仿代码注释风格呈现调用契约：“// 调用extract_revenue函数，输入参数为原始sales_data，输出必须是一个数组，每个元素包含product_name与monthly_revenue字段。”

同时，严格规定所有输入参数必须源自前序函数的返回值或初始传入的全局变量，禁止任何隐式的上下文引用。在链条开始执行前，可预置参数映射表，例如`{sales_data: “…”}`，确保每一步执行时，参数都能被精确注入对应的“函数提示词”模板中。

这样做的好处显而易见：子任务成为可复用、可替换的模块。您可以像调试函数一样单独测试每个提示步骤的效果，也可轻松调整执行顺序，甚至将某个步骤替换为另一个实现相同接口的模型或工具。这使得提示链的开发真正具备了软件工程的特征。

将复杂任务拆解为提示链，本质上是运用结构化方式与大模型协同工作。它通过降低单步复杂度、明确上下文边界、加入自动化校验和标准化接口，最终使那些原本难以一次性可靠完成的任务变得清晰、可控且稳健。这不仅是技术技巧，更是一种值得深入实践的工程方法论。