复杂任务：拆解、验证与简洁依据
复杂任务为什么容易出错？
一个任务如果同时包含理解输入、选择规则、计算、调用工具和整理输出，任何一步理解错了，后面的答案都可能偏离。
有效的方法不是单纯把“请逐步思考”重复很多次，而是把任务拆成可以检查的阶段，并为每个阶段说明输入、规则和完成条件。
例如，处理一份报销申请，可以拆成：
- 提取申请人明确提供的费用；
- 对照公司政策判断每一项是否符合规则；
- 列出缺少的票据或信息；
- 计算可报销金额；
- 输出结论与需要人工确认的例外。
这种拆解让人可以检查模型究竟在哪一步出错，也更容易把计算或查询交给可靠工具。
不要要求模型展示完整的内部思维链
一些推理模型会在生成最终答案前使用内部推理过程或推理 Token，这些内容不等同于对用户可见的答案。要求模型输出一段很长的“思考过程”，不保证它更真实、更忠实或更正确。
对于用户真正需要检查的内容，应该明确要求：
- 使用了哪些已知事实；
- 采用了什么规则或公式；
- 必要的中间结果是什么；
- 哪些信息仍不确定；
- 最终答案是什么；
- 怎样复核结果。
这是一份面向用户的简洁依据，不是模型未经过滤的内部思维记录。
不要把“输出了很多推理文字”当成正确性的证明。模型也可能生成看起来连贯、实际错误的解释。重要结果仍需使用来源、计算器、代码、数据库或人工复核。
案例：把计算要求写成可验证步骤
问题：
三个人三天喝了三桶水。假设每个人每天喝水量相同，九个人九天喝多少桶水？一个更清楚的 Prompt：
请计算下面的问题。
要求：
1. 先写出“总人天数”和“每人每天用量”两个必要的中间结果；
2. 再计算目标场景的总人天数；
3. 给出最终答案并带单位；
4. 只展示核对答案所需的简洁计算，不要添加无关解释。
问题：三个人三天喝了三桶水。假设每个人每天喝水量相同，九个人九天喝多少桶水？可核验的答案应包含：
原场景总人天数：3 × 3 = 9 人天
每人每天用量：3 ÷ 9 = 1/3 桶
目标场景总人天数：9 × 9 = 81 人天
总用量：81 × 1/3 = 27 桶
答案：27 桶这里真正有帮助的是明确公式和中间结果。即使模型答错，人也能快速找到错误发生在“单位用量”还是“目标总量”。
对不同任务使用不同验证方式
计算任务
要求列出公式和必要中间值，再用计算器或代码复核。不要让语言模型代替精确计算工具。
事实问题
要求给出来源、日期和不确定信息，并打开原始来源核对。引用链接本身也可能出错，不能只检查它“看起来像真的”。
信息提取
要求保留原文依据，对缺失字段使用 null 或“未提供”，再用 Schema 或程序检查字段。
多工具任务
记录的是可以审计的执行轨迹：调用了哪个工具、输入参数、工具返回结果、是否产生副作用，以及最终状态。不要用一段自然语言“思考”代替真实的工具日志。
高风险决定
医疗、法律、财务、人事、安全和对外发送等场景，应设置明确的人工确认和升级条件。任务拆解不能代替专业审核。
一个通用模板
请完成以下任务，并遵守这些要求：
1. 将任务拆成可以独立检查的步骤；
2. 每一步只使用我提供的信息和明确允许的来源；
3. 信息不足时停止并列出缺少的内容，不要猜测；
4. 对计算、引用或工具结果给出必要的可核验依据；
5. 最后单独给出结论、不确定项和建议的复核方式；
6. 只展示完成检查所需的简洁说明，不需要输出完整内部思维过程。
<task>
[在这里放入任务]
</task>本章检查清单
- 是否把复杂任务拆成可检查的阶段；
- 是否说明每一步使用什么输入和规则；
- 是否要求信息不足时停止而不是猜测；
- 是否把精确计算和查询交给合适工具；
- 是否要求必要依据，而不是冗长的“思考过程”；
- 是否定义最终答案、不确定项和复核方式；
- 高风险操作是否设置人工确认。
好的复杂任务提示，不是让模型多说“我正在思考”，而是让任务、依据、结果和验证方式都能够被检查。
