一次一件任务原则
同一条提示里塞多个任务，会同时带来三个问题：失败无法定位（不知道是抽取错了还是生成错了）、输出互相干扰（分类结论与生成正文混在一段里）、重试代价高（重跑一次要连正确的那部分一起重做）。把任务拆成独立调用后，每一步可以单独验收、单独重试、单独换参数，这也是提示链的基础。
拆与不拆的判断
| 判断标准 | 两个动作能否各自验收——能拆就拆 |
|---|---|
| 收益 | 失败可定位、步骤可重试、单步可换参数与模型 |
| 例外 | 强耦合的子步骤（同一段推理内顺带格式化）可留在同一次调用 |
| 成本 | 调用次数与总延迟上升，短任务不必强行拆链 |
| 传递 | 步骤之间用结构化数据传递，天然形成接口契约 |
典型使用场景
- 邮件处理：先抽字段、再判优先级、后写回复，三步各自可核
- 内容生产：先出大纲、再成文、最后润色，避免写完长文再推翻结构
- 数据处理流水线：抽取与清洗分开，便于定位错误来源
- 客服辅助：意图识别与话术生成分开，话术模板可独立迭代
- 混合任务：分类后按类别走不同规则时，先分类再执行
拆解示例
拆解示例
原始需求：看这封客户邮件，判断优先级，写一封回复，再翻译成英文。
拆成 3 次调用：
1) 抽取：从邮件中提取字段：产品 / 故障现象 / 影响范围 / 期望时限 → JSON
2) 判定：依据「影响范围 + 期望时限」对照规则表输出 P0-P3，并附 1 句依据
3) 生成：按模板写中文回复（引用判定结果），再将回复翻译为英文
# 每步的输入都是上一步的结构化输出，出错可单独重跑常见拆分点
| 混在一起的做法 | 问题 | 拆法 |
|---|---|---|
| 先分类再按类别执行 | 两套规则混用，类别判错后整段作废 | 先输出类别，确认后再调用对应模板 |
| 抽取 + 生成正文 | 字段抽错与文案问题混在一个输出里 | 先抽字段并校验，再基于字段生成 |
| 翻译 + 改写 | 改写意图与译文质量互相掩盖 | 先按原文翻译，再单独做风格改写 |
| 长文生成一次写完 | 中途跑题要整体重来 | 先大纲后逐节展开 |
多步之间用结构化数据传递（JSON），避免在自然语言里夹带中间结论造成串扰。