你写了一个 prompt，让模型 (1) 总结客户邮件、(2) 分类情绪、(3) 起草回复、(4) 必要时标记升级、(5) 写一条内部 Slack 消息。结果 task 1 做得不错，task 2 给了个通用答案，task 4 直接跳过，task 3 只写了半截回复，task 5 根本没碰。你追问”5 个都做”，得到的还是同样的形态，只是漏掉的地方稍微不同。
最快的修法：把这一摞任务拆成”一个任务一个 prompt”。互相独立的并行跑，真正有依赖的才串起来。单个 prompt 会逼模型用一份输出预算去做所有任务，而靠后的任务总是只能拿到剩下的边角。下面讲清楚：哪些任务该拆、哪些该串，以及怎么确认每个任务真的都做完了。
为什么会这样（不是你的错）
这是被实测出来的效应，不是你措辞的问题。2025 年一项覆盖六个 NLP 任务、多个模型家族的研究（MDPI《Electronics》）发现：把多个任务捆进一个 prompt，准确率的下降幅度高度依赖模型——有的模型相对单任务基线只掉了约 3.7%，有的却崩了约 38.8%；其中一个细粒度任务（情绪分类）在被和别的任务捆在一起后，准确率从 31.1% 掉到了 1.5%。结构化任务（抽字段、返回 JSON）扛捆绑的能力，比细粒度语义任务（情绪、语气、判断）强得多。
截至 2026 年 6 月，实操结论是：不存在一个”安全”的任务数量上限。任务越偏语义、越需要判断，被共享一个 prompt 时受的伤就越重，而且你没法单凭模型大小预测这个损失。
常见原因
1. 为省事叠任务
你之所以批量，是觉得写 5 个 prompt 太浪费。结果是一个 prompt 把 5 件事都做糟，而不是 5 个 prompt 各做好一件。
如何判断：prompt 里有 3 个以上编号任务。
2. 输出预算用完了
模型的输出是有限的。5 个任务塞进一个回答，等于每个都在抢同一份 token 预算，哪怕有的任务需要很大一块才能做好。靠后的任务被截断或跳过，是因为模型还没轮到它们，预算就已经”花光”了。
如何判断：靠后的任务更短、被截断、或干脆没了。
3. 早任务给模型定了”状态”
task 1 用正式语气答完后，task 2 会继承这个语气，哪怕换个语域更合适。在单个回答内部，模型是路径依赖的：它已经吐出的 token，会带偏后面的 token。
如何判断：靠后的任务不恰当地沿用了前面任务的语气、格式或框架。
4. 没有给每个任务定成功标准
你说”5 个都做”，却没说每一个做成什么样算成功。模型就挑最容易满足的做，剩下的悄悄丢掉。
如何判断：prompt 只有一个成功标准，被 5 个任务共用。
5. 任务之间有隐性依赖
task 3 依赖 task 2 的输出。模型按顺序处理，但 task 2 的答案次优，于是 task 3 把错误级联放大了。
如何判断：一个任务出错，会污染下一个。
你属于哪一种
动手重写前，先用这张表判断该拆、该串、还是该批。
| 信号 | 大概率原因 | 修法 |
|---|---|---|
| 3 个以上编号任务，彼此无关 | 为省事叠任务 | 一任务一 prompt，并行跑（Step 2） |
| 末尾任务被截断或空白 | 输出预算耗尽 | 拆开，让每个任务独占输出（Step 1） |
| 后任务沿用前任务语气/格式 | 路径依赖的状态 | 拆成独立 prompt 或 planner 拆分（Step 3、5） |
| 所有任务共用一条成功标准 | 没有每任务标准 | 编号标号 + 每任务成功标准（Step 4） |
| 修好 task 2 就修好了 task 3 | 隐性依赖 | 顺序串联，显式 handoff（Step 3） |
动手前先确认
- 列出你叠的每个任务，数一数总共几个。
- 标出哪些任务真正独立、哪些依赖另一个任务的输出。
- 给每个任务写一行：正确答案长什么样。
- 决定并行（独立）还是顺序（依赖）。
- 决定每个任务能不能独占一次请求，还是共享一个 system prompt、每轮只做一个任务。
最短修复路径
Step 1：列任务，默认”1 prompt = 1 任务”
任务 1：总结邮件。
任务 2：分类情绪。
任务 3：起草回复。
任务 4：标记升级。
任务 5：内部 Slack 消息。默认就是 5 个 prompt。只有当存在真实依赖、或这个工作流里 token 成本确实压过质量时，才批量。
Step 2：独立任务并行跑
平台支持的话，把独立的几个 prompt 当作并发 API 调用一起发出去。每个都拿到完整的输出预算，而总延迟是最慢的那一个调用，而不是所有调用之和。PARALLELPROMPT 基准测试发现，独立子任务能干净地并行，最高约 5x 提速，且在高创意类工作之外几乎不损质量。
import asyncio
results = await asyncio.gather(
call_model(prompt_1),
call_model(prompt_2),
call_model(prompt_3),
call_model(prompt_4),
call_model(prompt_5),
)如果你不是在自己的代码里、而是在单个 agent 循环内，可以让模型在一轮里发出多个独立的 tool call。截至 2026 年 6 月，OpenAI 通过 parallel_tool_calls 标志默认开启这一行为（设为 false 可强制串行调用），Claude 在判断工具彼此独立时会在一个回答里返回多个 tool_use 块（见 Anthropic 的 parallel tool use 文档）。你的运行器会一次性把它们派发出去，等全部结果回来再进入下一步推理。
Step 3：依赖任务顺序串联，显式 handoff
Pass 1：总结邮件。 -> <summary>
Pass 2：给定 <summary>，分类情绪。 -> <sentiment>
Pass 3：给定 <summary> 和 <sentiment>，起草回复。 -> <reply>
Pass 4：给定 <summary>、<sentiment>，决定是否升级。 -> <bool>
Pass 5：综合以上，写 Slack 消息。 -> <message>把每一步的结果作为命名变量往下传，既保住质量、又把依赖链摆明，这样上游一旦答错，下一步还没被污染前就能抓出来。
Step 4：必须批量，就清晰标号 + 给每任务成功标准
处理下面这封邮件。对每个编号任务，输出一个带标签的分块。
不要跳过任何任务。若某任务不适用，输出标签并写 "N/A"。
任务 1：SUMMARY（最多 30 词）
任务 2：SENTIMENT（positive | neutral | negative | frustrated）
任务 3：REPLY_DRAFT（50-100 词、第二人称、不带 emoji）
任务 4：ESCALATION（yes/no + 一句话理由）
任务 5：SLACK_MSG（少于 40 词、口语化）
严格按这些标签输出：
TASK 1: ...
TASK 2: ...
TASK 3: ...
TASK 4: ...
TASK 5: ...明确的标签、硬性的长度上限、再加一条”不要跳过”的指令，能削弱那种”做着做着没劲了”的形态。准确率要紧时，把需要判断的任务（情绪、升级）排除在批量之外——研究显示，正是这类细粒度任务在被捆绑时掉得最狠。
Step 5：复杂多任务用 planner / executor 拆
Planner prompt：给定输入 X，产出一份分步计划。对每一步，
说明它的目标，以及它必须返回的确切输出 schema。
然后把每个计划好的步骤当作独立 prompt 来跑，
只把下一步需要的东西往下传。这把庞大、模糊的工作分解成 scope 清晰的子 prompt。它背后正是 least-to-most prompting 那类分解思路——prompt engineering 综述把它记录为多步推理上一个可靠的准确率收益。
Step 6：审完成度
跑完后，用程序检查每个任务的输出都存在且良构（例如断言每个预期标签都存在且非空）。哪个任务漏了，就只重跑那一个，而不是整摞重来。
怎么确认已经修好
- 每个任务都有完整输出，不只是 task 1。
- 每个任务的输出都过它在 Step 4 里的成功标准。
- 最后一个任务的深度，和第一个相当。
- 同事看输出，说不出哪个任务先跑。
- 总质量胜过批量版本，代价只是多几个调用或几次串联。
如果还是没修好
- 任务之间的依赖可能比你以为的多。把它们排序串起来（Step 3）。
- 模型可能背了太多任务。砍掉价值最低的那个。
- 把最重要的任务路由到更强的模型，其余的用便宜的。
- 高风险工作就别批量。永远 1 prompt 1 任务。
常见问题
一个 prompt 塞几个任务算太多？ 没有固定数字。2025 年的 MDPI 研究发现，下降幅度取决于模型和任务类型——语义任务（情绪、分类、判断）比结构化任务（抽取、格式化）崩得早得多。把任何含 3 个以上任务的 prompt 都当成风险点，信任它之前先和单任务基线对比测一下。
拆成很多 prompt 是不是更贵？ 通常只贵一点点。每次调用会多付一点输入开销，但你避免了重跑一整摞砸掉的批量，而且独立任务并行调用不增加实际墙钟时间。如果成本是真正的瓶颈，就只把便宜的结构化任务批在一起，把需要判断的任务单拆出来。
让模型”慢慢来、5 个都做”能解决吗？ 不能。这个失败是结构性的，不是态度问题。模型仍然在共享一份输出预算，仍然在回答内部路径依赖。带硬性上限的每任务标号（Step 4）有帮助，但拆开 prompt 帮助更大。
用自己的并行 API 调用，还是用一个能发并行 tool call 的 prompt？
代码在你手里、任务又独立时，用你自己的并行调用。在单个 agent 循环里时，用原生并行 tool call。截至 2026 年 6 月，OpenAI 的 parallel_tool_calls 默认开启，Claude 在判断工具独立时会发出多个 tool_use 块。
为什么每次跳过的都是同一个靠后的任务？ 一旦模型把前面的分块都吐完，剩下的输出预算和这段回答的”惯性”都会催它收尾。靠后的任务、尤其是开放式的，最先被砍掉。把 prompt 拆开、或把被跳过的任务挪到最前面，很快就能验证这一点。
预防建议
- 默认规则：1 prompt = 1 任务。
- 批量工作流用 planner + executor 模式，配显式子 prompt。
- 给自己留一条反模式检查：“我又叠任务了吗？” 发送前过一遍。
- 审生产管线。任何含 3 个以上任务、尤其是语义任务的 prompt，都算风险。
- 把”批量省 token”当成一种气味，除非质量已被经验证明等价。
- 反问自己”如果中途失败，哪些是可恢复的？” 批量 prompt 是半完全失败。