AI专栏 | Prompt Engineering [附篇: 大模型视角下的单一任务是什么?]

难度系数：★★☆☆☆

本章知识：

• 从 LLM 视角判断「单一任务」的四个维度
• 回到原例：“新闻查询 + 信息格式化”为何通常是单一任务？
• 何时会“退化”为多任务？
• 一个实用的快速判断法则
• 工程实践中的关键认知

上一章节我们介绍了Prompt Engineering的高能建议，其中有一条值得展开说说。

在 Prompt Engineering 中，“单一任务”常被误解为“只做一件事”。但对大模型而言，关键不在于动作数量，而在于目标是否统一。

下面以"新闻查询并格式化输出"为例

结论先行：
单一任务 ≠ 只执行一个操作，而是指模型在一次推理中，只围绕一个清晰、稳定的目标进行优化。

因此：

• ✅ “新闻查询 + 信息格式化”在大多数场景下 属于单一任务
• 前提是：格式化仅作为结果的交付形式，而非独立的判断或决策目标

一、从 LLM 视角判断「单一任务」的四个维度

1️⃣ 是否只有一个“主要目标”？

• 单一任务特征：
  • 仅有一个成功标准
  • 其他步骤仅为达成该目标的必要手段
• 多任务特征：
  • 每个子任务有独立评价维度
  • 模型需同时处理不同类型的问题（如检索 + 分析 + 决策）

📌 判断关键：模型是否需要在多个独立目标之间切换或权衡？

2️⃣ 子步骤是“手段”，还是“目的”？

这是一个实用的工程判断法。

✅ 典型单一任务示例：

“查询某公司近期新闻，并以 JSON 格式输出”

• 查询新闻 → 获取内容（核心目标）
• JSON 格式 → 输出协议（交付形式）

模型真正要解决的问题只有一个：如何把查询结果按指定结构交付。
格式化本身无业务意义，仅是载体。

❌ 典型多任务示例：

“查询新闻，分析其情感倾向，并给出投资建议”

包含三个独立认知任务：

1. 信息检索（正确性）
2. 情感判断（分析能力）
3. 投资建议（决策能力）

3️⃣ 是否要求模型切换“认知模式”？

不同任务调用不同的模型能力：

任务类型	对应的认知模式
查询 / 回忆 / RAG	上下文提取与整合
格式化输出	结构化生成
分析 / 判断 / 建议	推理与决策

若整个 Prompt 只激活一种主导认知模式（如“提取+结构化”），其余为约束条件，则仍属单一任务。

4️⃣ 聚合目标是否具有收敛性？

• ✅ 收敛于同一逻辑实体 → 单一任务

  例：从多个网页聚合“张三的个人履历”

• ❌ 发散至多个无关实体 → 多任务

  例：同时聚合“张三的简历”和“YYY公司的财报”

二、回到原例：“新闻查询 + 信息格式化”为何通常是单一任务？

因为在模型视角中：

• 主目标：提供准确、可用的新闻内容
• JSON 格式：仅是结果的结构化表达方式

这本质上等同于：

“请用指定的数据结构返回结果”

而非：

“请完成两件彼此独立的事”

三、何时会“退化”为多任务？

以下情况会使看似简单的 Prompt 变得不稳定：

❌ 情况一：格式化隐含判断逻辑

“查询新闻，并按重要性筛选后，以 JSON 输出”
→ “重要性筛选”是独立决策任务。

❌ 情况二：输出结构过于复杂

• 过深嵌套
• 动态字段、条件规则
• 强 Schema 约束 + 业务语义
  → 模型需同时兼顾内容生成与协议对齐，注意力分散。

❌ 情况三：明确声明多个任务

“请完成以下两个任务：1. 查询新闻；2. 设计 JSON 结构”
→ 已是显式多任务指令。

四、一个实用的快速判断法则

问自己：如果删除其中一个步骤，另一个是否仍有业务价值？

• 删除“格式化” → 新闻查询仍有价值 ✅
• 删除“新闻查询” → JSON 结构毫无意义 ❌

→ 说明格式化依附于主目标，属于单一任务。

五、工程实践中的关键认知

在 RAG 或 Agent 系统设计中，应牢记：

单一任务 ≠ 单一 Prompt
而是：一次推理只解决一个不可再拆的业务决策点

更稳健的系统架构通常是：

• 每个 Prompt 聚焦单一目标
• 通过多个节点串联多个单一任务

这样既能保证模型专注度，又便于调试、评估与迭代。

---

关注本专栏，让我们一起掌握方法、实践落地、共同发展。