4.1 复杂任务分解

4.1 复杂任务分解

为什么需要任务分解

单次提示词的能力边界比多数人想象的更近。当任务出现以下任一信号，就该考虑分解：

• 多阶段推理："分析数据→定位原因→设计方案→评估方案"无法在一次生成中保质完成
• 能力异构：任务的不同部分需要不同的温度、角色、甚至不同的模型
• 超长产出：要求输出5000字以上时，后半段质量肉眼可见地滑坡
• 强依赖中间结果：后续步骤的输入必须由你确认后才能进行

强行单次调用的代价是隐性且昂贵的：模型会跳过推理步骤、在中途悄悄改变口径、产出"每段都对但整体失控"的内容。分解不是把简单事搞复杂，而是承认复杂度守恒——复杂度不会消失，只会转移到你选择让它出现的地方。

分解范式一：提示词链（Prompt Chaining）

提示词链是最基础也最实用的分解形式：把任务拆成串行的多次调用，前一步的输出作为后一步的输入。

经典链路：写作任务四段链

链1【大纲】"为《新员工入职指南》生成大纲，5个H2章节，
    每章列出要点。只输出大纲。"

链2【审定】人工审阅大纲，调整结构（这一步在链外，但决定链的质量）

链3【逐章展开】"基于以下大纲展开第3章正文，800字。
    上下文：{大纲+已完成的第2章末段，保持衔接}"

链4【润色】"通读以下全文，统一术语与语气，只修改明显不一致处，
    输出修改清单+最终稿。"
​

对比单次生成"写一篇完整入职指南"，四段链的每一步都在可控范围内做到最好，且每一步的产物都可检查、可回滚——发现第3章跑偏时，只需重跑链3，成本是一次调用而不是整个任务。

链设计的两条铁律

铁律一：每链只做一件事。如果发现某个环节的提示词里出现"并且"，警惕——它可能该拆成两链。"分析数据并给出建议"应拆为"分析"与"建议"两链，中间的衔接处正是你施加控制的位置。

铁律二：链间传递要"摘要化+结构化"。全量传递上一步输出会引入噪音与上下文污染；传递格式良好的摘要（结论+关键依据+待定项）让下一链轻装上阵。

分解范式二：先规划后执行（Plan-and-Execute）

当任务结构不确定（你不知道该拆成几步）时，让模型先产出计划：

【规划阶段】
"任务：{原始任务}
请先输出执行计划：
1. 需要哪几个步骤（每步一句话说明产出物）
2. 步骤间的依赖关系
3. 你认为哪一步风险最高、为什么
不要执行任何步骤，只输出计划。"

【人工校准】审查计划，砍掉多余步骤，修正方向

【执行阶段】按计划逐步执行，每步单独调用
​

规划阶段的价值不仅是拆解本身：它让模型的"解题思路"显式暴露，你在执行前就有机会纠偏。计划里发现"风险最高的一步"，往往正是实际执行中会翻车的地方。

分解范式三：分支聚合（Map-Reduce）

处理批量同构对象（100份评论、50个文件）时的标准结构：

Map阶段：对每份评论独立提取"情绪/问题类型/紧急度"（结构化输出）
Reduce阶段：聚合全部结构化结果 → 统计分布 → 提炼Top问题 → 生成报告
​

Map阶段每次调用只面对一份材料，提取质量远高于"请分析这100条评论"；Reduce阶段面对的是干净的结构化数据而非原始噪音。先结构化、再聚合，是这个范式的心法——绝不要让最终汇总的调用直接面对原始材料。

拆解粒度的判断标准

分解不是越细越好——每条链都是一次调用成本与一次信息损耗。粒度判断的实用标准：

一个经验法则：拆到"每一步失败时，我愿意为重跑这一步付费"为止。拆得过细时，重跑虽然便宜，但拼接管理成本反而上升。

完整示例：竞品调研任务链

原始任务："调研三个竞品的定价策略并给我建议。"（信息量大、多阶段、强依赖中间结果）

链1[规划]  生成调研框架：需要哪些维度的信息？
链2[Map×3] 每个竞品独立调研：按框架提取，缺失信息标"数据缺口"
链3[聚合]  三家对比矩阵 + 差异点提炼（输入为链2的结构化结果）
链4[反证]  扮演反方：该对比矩阵中最可能不成立的结论是什么？
链5[建议]  基于链3+链4输出建议，每条注明所依赖的发现
​

五条链各司其职，任何一环的质量问题都被隔离在局部。这个结构同时用上了本章全部三个范式——先规划（链1）、分支聚合（链2/3）、串行深化（链4/5）。

常见问题 FAQ

Q1：链式调用比单次调用贵好几倍，值得吗？
算总账而不是单次账：单次调用产出不可用时，返工是整任务重跑；链式调用只在出问题的环节重跑。对于质量敏感的任务，链式的总成本通常更低。质量不敏感的短任务，单次调用即可。

Q2：链间传递的信息越传越失真怎么办？
三个手段：①传递结构化摘要而非自然语言转述（JSON优于段落）；②关键约束在每条链的提示词中重复声明，不能指望"上一条链说过"；③长链超过5节时插入一次"共识快照"——让模型复述当前已确认的全部结论，作为后续链的权威上下文。

Q3：模型自己拆解自己执行（agent模式）和人工设计链有什么区别？
控制权与可预测性的区别。人工设计的链：步骤确定、可控可审计，适合稳定的生产流程。模型自主拆解（ReAct类）：灵活但路径不可预测，适合探索性任务。工程上常见组合是"规划由模型生成、执行链由人确认后运行"。

Q4：怎么知道我的链设计得好不好？
看两个指标：单链成功率（每链输出是否达到该链的验收标准）与整体返工率。单链频繁失败说明该链职责过重该再拆；返工集中在某条链说明该链的提示词质量或输入质量有问题。

Q5：有没有不需要分解的复杂任务？
有——推理深度浅但表面复杂的任务。比如"把这篇文档翻译成英文"字数很长但每段的难度独立，一次调用（或按段并行）即可，强行拆链反而破坏全文一致性。判据：任务是否真的存在阶段间的依赖与转换，只有这种复杂度才需要链来管理。

最佳实践与避坑

• 避坑一：拆解后不做人工检查点，把链式调用当全自动流水线。链的价值恰恰在于中间的确认机会，全跳过等于花钱买了一台更快出错的机器；
• 避坑二：链与链之间只传自然语言。养成传结构化摘要的习惯，自然语言转述是信息损耗的重灾区；
• 实践：把稳定的任务链固化为脚本（代码串联各次调用），既省去手工复制粘贴，也让整条链可版本管理、可回归测试；
• 实践：为每条链写验收标准（哪怕一句话）。没有验收标准的链是流水线上的盲区，它的劣化你永远最后一个知道。

本节小结

任务分解的三个范式覆盖了三类复杂度：提示词链管理阶段依赖，先规划后执行应对未知结构，分支聚合处理批量同构对象。判断拆解粒度的标准是"重跑成本"，链间传递的纪律是"结构化摘要"。掌握分解，你就能处理任何规模的任务——因为再大的任务也只是链的延长。下一节处理另一个维度的复杂度：时间——多轮对话的优化。

📌 实践建议：把一个你最近"一次提问搞砸"的复杂任务，按本章范式拆成任务链跑一遍，体会每个检查点带来的掌控感差异。