Prompt学习四：为什么复杂任务不能只靠一个 Prompt

发表于 分类于 Disqus：

前三篇我分别在解决三个问题：第一，怎么把任务说清楚；第二，怎么让结果更稳定；第三，怎么把行为边界和输出契约定义清楚。但继续往下学，很快就会撞上第四个问题：如果任务本身就不是单步能完成的，那一个 Prompt 写得再完整，是不是也不够？

这也是我学到 Chain-of-Thought（CoT）和 Prompt Chaining 之后最明显的认知变化。很多 AI 应用的问题，不是 Prompt 写得不够精致，而是你让模型在一次输出里同时承担了太多职责：既要理解任务，又要提取信息，又要判断优先级，还要组织结果。任务一旦变复杂，单个 Prompt 的可控性就会快速下降。

真正复杂的任务，往往不是“一次生成”问题

如果只是简单改写、摘要或者分类，单轮 Prompt 往往已经够用。但真实的 AI 应用里，更常见的是这种链路：

  • 先理解输入
  • 再提取关键信息
  • 再做判断或规划
  • 最后组织成可交付结果

比如一个“根据需求文档生成开发建议”的任务，看起来只是“生成一份输出”，但中间其实至少包含几层不同工作：

  1. 识别业务目标
  2. 提取约束条件
  3. 判断哪些信息缺失
  4. 组织实现方案
  5. 输出给人看或给程序消费的结果

如果这些步骤全塞进一个 Prompt，模型当然有机会答出一个“看起来差不多”的结果，但工程上最麻烦的地方也会跟着出现：

  • 某一步做错了，却不知道错在哪
  • 中间推理不稳定，导致最终结果漂移
  • 输出很长，但信息密度不高
  • 一旦需求稍微复杂一点，结果质量迅速下降

所以这块内容最重要的一个变化，不是学会某个技巧名词，而是建立一个更工程化的判断：

当任务本身包含多个认知阶段时，问题往往不在“Prompt 写得够不够好”，而在“任务有没有被正确拆开”。

CoT 解决的，不是“让模型多说一点”

一开始看到 Chain-of-Thought（链式思维）时，很容易把它理解成：让模型把思考过程写出来。但如果只是停在这个层面，其实很容易学偏。

对我来说，CoT 真正有价值的地方不在于“让模型展开推理文字”，而在于：

当任务需要多个判断环节时，显式地提示模型按步骤处理，往往比让它直接给结论更稳定。

举个非常简单的例子。假设我们要分析一段用户反馈，并判断是否应该升级为高优先级问题。

如果直接写成：

1
请阅读下面的用户反馈，并判断是否为高优先级问题，同时给出原因和摘要。

这当然能得到结果，但这个 Prompt 把几件不同的事揉在了一起：

  • 理解反馈内容
  • 识别问题类型
  • 判断严重程度
  • 解释判断理由
  • 输出总结

这时候模型可能会：

  • 判断结果对了，但理由不稳定
  • 理由讲了很多，但没有真正抓住高优先级标准
  • 摘要和判断标准不一致

如果换成更明确的分步提示：

1
2
3
4
5
6
请按以下步骤处理这条用户反馈：

1. 先提取用户反馈中明确提到的问题
2. 再判断这些问题分别影响什么核心流程
3. 再基于影响范围判断是否属于高优先级
4. 最后输出结论、理由和摘要

这里真正发生的事情，不是 Prompt “更长了”，而是模型被要求先完成中间判断，再汇总到最终结论。

也就是说，CoT 的核心不是“多写推理”，而是把隐藏在任务里的中间步骤显式化。

什么时候该让模型“逐步思考”

并不是所有任务都需要 CoT。

如果一个任务本身很直接，比如：

  • 情感分类
  • 固定字段抽取
  • 简单摘要
  • 格式改写

那强行要求模型逐步展开，可能只会增加 token 和噪声。

但当任务出现下面这些特征时，我会更倾向于考虑 CoT：

  • 需要先分析再判断
  • 需要结合多个条件做结论
  • 需要先找证据再回答
  • 需要处理歧义、冲突或缺失信息
  • 需要保证结论和理由之间可追踪

换句话说，是否要引入 CoT，判断标准不是“这个技巧高级不高级”，而是：

这个任务的最终结果，是否依赖一串中间判断。

如果依赖，那把这串判断显式化，通常就比让模型“一步到位”更可控。

Prompt Chaining 才是真正接近系统设计的地方

如果说 CoT 还是在单个 Prompt 内部做“步骤展开”，那 Prompt Chaining（提示词链）就更进一步了：

不是让一个 Prompt 包办所有事，而是把复杂任务拆成多个前后衔接的小步骤。

这是我学到 Prompt Chaining 之后，最有工程感的一部分。

因为一旦开始把任务拆成链路，你思考问题的方式就会明显变化。你不再问：

  • 有没有一个更厉害的 Prompt 可以一次解决？

而开始问：

  • 哪一步先做更合理？
  • 哪一步应该产出中间结构？
  • 哪一步需要校验再继续？
  • 哪一步应该由模型做，哪一步应该由程序做？

这已经很像常规软件工程里的流水线设计了。

例如“基于长文档回答问题”这个任务，一个更合理的链路往往不是：

1
请阅读这篇长文档，并回答下面的问题。

而是拆成：

  1. 先抽取和问题相关的片段
  2. 再整理这些片段里的关键证据
  3. 最后基于证据生成回答

这样做的好处非常直接：

  • 每一步目标更单一
  • 每一步更容易调试
  • 可以替换某一步而不重写全流程
  • 更容易做评估和对比
  • 更容易接上检索、工具调用或程序逻辑

所以 Prompt Chaining 真正带来的，不是“Prompt 花样更多了”，而是你开始从“写一句话”转向“设计一条工作流”。

一个典型例子：长文章生成，为什么应该先提纲再扩写

这块内容里，一个很容易感受到差异的例子就是长文章生成。

如果直接写：

1
请围绕 AI 应用开发工程师的成长路径，写一篇 3000 字文章。

模型也能写，但常见问题通常包括：

  • 结构不稳定
  • 前后重复
  • 中段跑偏
  • 后半部分开始空泛

因为模型在一次生成里，同时承担了：

  • 想结构
  • 定重点
  • 排顺序
  • 写细节
  • 控篇幅

这些事情本来就不是一个认知层级。

如果改成两步：

第一步：只做提纲

1
2
3
4
5
6
7
请围绕“AI 应用开发工程师的成长路径”生成一份文章提纲。

要求：
1. 文章面向有软件开发背景、刚接触大语言模型的工程师
2. 控制在 5 个一级部分以内
3. 每个部分写一句说明它要解决什么问题
4. 不展开正文

第二步：按提纲扩写

1
2
3
4
5
6
7
8
9
10
请基于下面这份提纲扩写成正文。

要求：
1. 保持结构顺序不变
2. 每部分先解释问题，再解释为什么重要
3. 避免重复前文观点
4. 结尾回到“为什么这是一条工程化能力路径”

提纲：
{{outline}}

这时候，你得到的不只是“好像更顺一点”的结果，而是整个过程变得更可控了：

  • 提纲阶段负责定结构
  • 扩写阶段负责填内容
  • 两个阶段的验收标准也被分开了

这其实就是 Prompt Chaining 最朴素也最实用的价值。

再举一个更贴近 AI 系统的例子：先抽证据，再回答问题

另一个很典型的场景，是文档问答。

如果直接问模型：

1
请根据下面文档回答问题：这个功能为什么要增加人工兜底？

只要文档稍微长一点，问题就会冒出来：

  • 模型找错段落
  • 模型凭经验补全没写过的内容
  • 回答里有结论，但证据链不清楚

更好的链路通常会拆成两步：

第一步：抽取证据

1
2
3
4
5
6
请只从下面文档中抽取和“人工兜底”相关的原文证据。

要求：
1. 只保留原文中明确提到的内容
2. 每条证据附带一句简要说明
3. 如果找不到，明确返回“未找到相关证据”

第二步：基于证据回答

1
2
3
4
5
6
7
8
9
请基于下面证据回答问题：这个功能为什么要增加人工兜底？

要求：
1. 只能依据证据回答
2. 如果证据不足，明确说明
3. 先给结论，再给依据

证据：
{{evidence}}

这样拆开的好处是，你不再把“检索证据”和“组织回答”混成一个黑盒步骤。问题一旦出错，也更容易知道：

  • 是证据没找对？
  • 还是证据找对了，但回答环节组织错了？

这正是工程里最重要的一种可调试性。

Self-Consistency 给我的提醒：不要只盯着单次结果

这一部分里我还顺带看了 Self-Consistency。它不一定是我当前最常用的手段，但它给了我一个很重要的提醒：

对复杂任务，不要只看某一次答案像不像对，而要看同样的问题在多次推理下是否收敛。

这个思路其实和前面讲“稳定性”是连着的。

如果一个复杂任务在不同推理路径下，总能落到接近的结论，那说明你的任务拆分、提示边界和中间步骤设计，大概率是比较健康的。

反过来，如果每次答案都很像“有道理”，但路径和结论漂移很大，那通常说明：

  • 任务定义仍然有歧义
  • 中间步骤没有被说清楚
  • 最终结论依赖了过多模型自由发挥

所以 Self-Consistency 对我的价值，不只是一个技术名词，而更像是一种验收视角：

复杂任务的质量，不该只看一次成功，而要看多次执行是否收敛。

我现在会怎么判断：该用单个 Prompt，还是该拆链路

学完这块之后，我会用一组更清楚的问题来判断任务该怎么设计：

  1. 这个任务是不是本质上包含多个认知阶段？
  2. 最终结果是否依赖中间判断？
  3. 如果结果错了，我能不能快速定位错在哪一步？
  4. 输出是否需要中间结构来支撑下游流程？
  5. 这一步应该由模型完成，还是更适合交给程序规则处理？

如果这些问题里，前 3 个的答案都是“是”，那我通常就不会再执着于“一个 Prompt 解决全部”，而会优先考虑：

  • 先用 CoT 显式化步骤
  • 再看是否应该进一步拆成 Prompt Chaining

这背后的判断其实很简单：

单个 Prompt 更像一次调用，Prompt Chaining 更像一条流程。

任务越复杂，越应该用流程思维，而不是继续往一次调用里堆要求。

这一块真正让我开始“像工程师一样思考 AI”

回头看这部分内容，我觉得它最重要的收获不是掌握了 CoT、Self-Consistency、Prompt Chaining 这些术语，而是思维方式变了。

以前更容易把 Prompt 问题理解成“这句话怎么写更好”；现在我会更自然地先想：

  • 这个任务有没有拆错层次？
  • 哪些步骤应该单独拿出来？
  • 哪些结果应该先产出中间对象再继续？
  • 哪些环节应该加入校验或证据约束？

一旦这么想，Prompt 学习就开始从“输入写法”走向“流程设计”。

而这一步，正是 AI 应用开发和普通聊天用法之间非常关键的一条分界线。

结语

第一篇我在学怎么把任务说清楚，第二篇我在学怎么让输出更稳定，第三篇我开始把 Prompt 理解成模型与系统之间的接口。到了第四篇，我真正开始意识到：

很多复杂任务的问题，已经不是 Prompt 句子怎么写，而是任务流程怎么拆。

CoT 让我学会把中间判断显式化，Prompt Chaining 让我开始按步骤设计工作流，Self-Consistency 则提醒我不要只盯着单次结果，而要关注复杂任务在多次执行中的收敛性。

如果说前三篇更多是在打 Prompt 这层输入和接口基础，那这一篇开始让我第一次真正进入 AI 系统设计的思路：一个 Prompt 干不完的事，就不要硬塞给一个 Prompt。

接下来继续往下学，我会进入工具调用、上下文设计和更完整的系统协作方式。到那时，Prompt 就不再只是“写给模型的话”，而会越来越像一套围绕模型展开的工作流设计。

参考文档

  • Prompt Engineering Guide - Chain-of-Thought Prompting
  • Prompt Engineering Guide - Self-Consistency
  • Prompt Engineering Guide - Prompt Chaining
  • Prompt Engineering Guide - 提示词示例