主题
高频面试题
如何使用提示词实现任务分解？
这道题考的是你能否把“拆步骤”落到可执行计划、依赖关系、验证标准和失败恢复，而不是让模型随便列待办。
面试官角度分析，想考什么
- 任务分解 Prompt 应该包含什么？
考目标、约束、子任务、依赖、验收和风险。 - 如何控制拆分粒度？
考是否知道过粗不可执行，过细成本高。 - 任务分解和 CoT 有什么区别？
考推理链与执行计划的边界。 - Agent 中任务分解有什么风险？
考计划幻觉、循环、遗漏和不可验证步骤。
可直接抄走的 30 秒参考答案
text
我会让模型先确认目标、约束、可用工具和交付物，再把任务拆成带 id、输入、输出、依赖和验收标准的子任务。好的任务分解不是列清单，而是每一步都能执行、能验证、能失败恢复。它和 CoT 不同，CoT 是推理链，任务分解是执行计划；在 Agent 里两者会结合使用。面试回答详解，知其所以然
任务分解不是让模型列一个漂亮清单，而是让后续执行能真的推进。
1. 好的任务分解 Prompt
可以使用这样的结构：
text
请把目标拆成可执行任务。
目标：{goal}
约束：{constraints}
可用工具：{tools}
输出每个子任务：
- id
- 目标
- 输入
- 输出
- 依赖
- 验收标准
- 风险或缺失信息这个格式能避免模型只写“调研、分析、总结”这类不可操作步骤。
2. 先定目标和边界
分解前要明确：
- 最终交付物是什么。
- 哪些事情不能做。
- 可用工具和权限是什么。
- 时间、成本、数据范围限制是什么。
- 什么情况下需要追问用户。
目标不清时直接拆任务，很容易得到一串看似合理但方向错误的计划。
3. 控制粒度
子任务粒度要满足两个条件：能独立执行，能独立验收。
- 太粗：
完成系统设计，无法判断下一步。 - 太细：
打开文件 A 第 1 行，调度成本过高。 - 合适：
阅读认证模块入口，梳理登录态来源和失败路径。
面试里可以说：我会把任务拆到“一个模型调用、一个工具动作或一个人工可验证输出”能完成的粒度。
4. 和 CoT 的区别
CoT 是推理过程，重点是如何得到答案。任务分解是执行计划，重点是如何完成目标。
text
CoT: 我为什么这样判断
任务分解: 我接下来要做哪几步在 Agent 里二者会结合：模型先推理目标，再生成计划，然后按计划执行并根据观察结果调整。
5. 风险和兜底
任务分解常见失败：
- 拆出不可执行步骤。
- 忽略关键依赖。
- 编造不存在的工具或数据。
- 计划过长导致成本失控。
- 执行中不更新计划。
生产上要给工具清单、约束预算、最大步骤数、验收标准和重新规划条件。
面试官追问3个问题
追问一：怎么判断任务是否拆得足够细？
- 考察点：执行粒度。
- 回答方向：每个子任务有明确输入输出，能被一个执行单元完成，并能通过验收标准判断完成。
追问二：模型拆错任务怎么办？
- 考察点：反馈闭环。
- 回答方向：执行后根据 observation 更新计划，必要时重规划，并保留 trace 方便审计。
追问三：任务分解和 Workflow 怎么结合？
- 考察点：工程架构。
- 回答方向：固定主流程用 Workflow，开放节点让模型动态分解，关键步骤由规则和人工确认兜底。