conversation-flow

name	conversation-flow
description	当系统提示词需要定义 AI 如何分类用户意图、路由到不同处理流程、决定澄清策略和自主度级别时调用此 Skill。适用于多任务型 AI 助手、客服机器人、编程工具、研究助手等需要结构化对话管理的场景。不适用于：纯问答型系统（无任务执行）、单轮交互（无对话状态）、简单的 prompt 模板（无路由逻辑）。当需求仅涉及"输出什么格式"而非"如何决定输出什么"时，应该用 output-formatting 而非本 Skill。
tags	["对话路由","意图分类","澄清策略","自主度控制","工作流生命周期"]
related_skills	["output-formatting","agent-delegation","context-management"]

对话流程与路由设计

R — 原文 (Reading)

跨供应商系统提示词中浮现的对话管理核心模式：先将用户输入二分为"问题"与"任务"（Warp），再按领域路由到专用处理流程（Claude Chrome 的"芯片"机制）。Claude Design 要求新设计至少提问 10 个问题才开工；ChatGPT Agent 则主张"尽可能推进，只在被阻塞时才请求澄清"。Codex 对简单任务跳过规划，Jules 有正式的计划评审步骤。核心张力在于"先问清楚"与"先做了再说"之间的平衡。

I — 方法论骨架 (Interpretation)

1. 意图二分法 — 首先将用户输入分类为"信息查询"（问题）或"任务执行"（动作），触发不同处理管线
2. 领域路由表 — 为每个已识别领域（邮件/文档/代码/搜索等）建立专用处理流程，含输入验证和输出格式
3. 澄清策略谱系 — 从"先问再做"（高澄清）到"假设并继续"（低澄清），按任务复杂度和风险级别选择
4. 自主度分级 — 定义 AI 在多大程度上可以自主推进：低（每步确认）→ 中（关键节点确认）→ 高（完成后汇报）
5. 结构化工作流生命周期 — 提问 → 探索 → 规划 → 执行 → 验证 → 总结，每个阶段有明确的进入/退出条件
6. 简化任务快速通道 — 对预估复杂度低于阈值的任务（如 Codex 的 25% 简单任务），跳过规划直接执行
7. 工具优先原则 — 如果一个请求可以通过工具调用直接解决，立即调用工具，不请求许可（Notion AI）

A1 — 案例分析 (Past Application)

案例: Claude Design 的十问启动流程

• 问题: 设计任务的高度开放性导致 AI 经常基于模糊需求产出偏离用户期望的结果
• 设计模式的使用: Claude Design 系统提示词要求在开始任何新设计前至少提出 10 个澄清问题，涵盖目标用户、设计风格、功能范围、技术约束等维度。工作流为：提问 → 探索 → 规划 → 构建 → 验证 → 总结
• 结论: 强制澄清阶段虽然增加了前置轮次，但显著减少了后期返工率

案例: ChatGPT Agent 的"尽可能推进"策略

• 问题: 频繁请求用户确认导致任务完成效率低下，用户体验碎片化
• 设计模式的使用: ChatGPT Agent 系统提示词要求"尽可能推进，不做不必要的检查"。仅在真正被阻塞时才请求用户澄清，否则使用"假设...并继续"模式自主推进
• 结论: 该策略适合高自主度场景，但对模糊需求的容错率较低，需要在"推进速度"和"方向准确"之间权衡

案例: Warp 的二分路由

• 问题: 混合处理查询和任务导致输出格式混乱——回答问题时给出执行步骤，执行任务时给出理论解释
• 设计模式的使用: Warp 系统提示词将用户输入严格二分为"问题"（→ 简洁指令式回答）和"任务"（→ 直接执行），消除格式歧义
• 结论: 简单的二分路由显著提升了输出一致性，尤其适合终端/CLI 等高效场景

A2 — 触发场景 (Future Trigger) ★

用户在什么情境下需要?

1. 设计多任务型 AI 助手，需要根据用户意图路由到不同处理流程（如客服机器人的工单/FAQ/人工转接）
2. 构建编程/设计工具类 AI，需要在"先问清楚"和"先做再说"之间找到平衡点
3. 优化现有 AI 产品的对话体验——用户反馈"问太多问题"或"不问就做，方向经常跑偏"
4. 为 AI Agent 设计工作流生命周期，需要定义规划→执行→验证的标准流程
5. 实现"快速通道"机制——简单任务跳过规划直接执行，复杂任务走完整流程

语言信号

• "AI 问的问题太多/太少了"
• "不同类型的请求需要不同的处理方式"
• "简单任务不要走复杂流程"
• "需要先规划再执行"
• "用户说了一句话就期望 AI 开始做事"

与相邻 skill 的区分

• 与 output-formatting 的区别: output-formatting 控制输出的"形式"，本 Skill 控制决定"输出什么"的流程逻辑
• 与 agent-delegation 的区别: agent-delegation 管理多代理间的任务分配，本 Skill 管理单代理内的对话路由
• 与 context-management 的区别: context-management 管理信息存储和加载，本 Skill 管理对话决策逻辑

E — 可执行步骤 (Execution)

1. 定义意图分类体系 — 完成标准: 建立至少三级意图分类（如：信息查询 / 简单任务 / 复杂任务），每级有明确的判断标准和示例输入

2. 设计领域路由表 — 完成标准: 为每个支持的领域（至少 3 个）定义专用处理流程，包含输入验证规则、处理步骤、输出格式要求和异常处理路径

3. 建立澄清策略谱系 — 完成标准: 定义至少三档澄清策略（高/中/低），每档明确触发条件（如任务风险级别、信息完整度评分），并给出每档的示例对话模式

4. 设计工作流生命周期 — 完成标准: 定义至少五个阶段（提问→探索→规划→执行→验证），每阶段有明确的进入条件、核心动作、退出条件和可跳过条件

5. 实现快速通道机制 — 完成标准: 定义简单任务的判定标准（如输入长度 < N 且含明确指令动词），以及快速通道的跳过规则（跳过哪些阶段、保留哪些检查点）

B — 边界 (Boundary) ★

不要在以下情况使用

• 单轮问答系统——没有对话状态需要管理，路由是多余的
• 纯 API 服务——请求-响应模式，没有对话流需要设计
• 规则非常固定的自动化流程——不需要 AI 自主决策路由
• 创意对话/闲聊场景——过度结构化会破坏自然感

常见失败模式

• 过度路由：为每种可能的输入都设计专用流程，导致路由表膨胀且难以维护
• 澄清不足：在"尽可能推进"策略下对模糊需求也直接执行，导致方向错误和大量返工
• 澄清过度：在简单任务上强制走完整提问流程，用户体验像填表而非对话
• 快速通道误判：将复杂任务误判为简单任务跳过规划，导致执行失败后不得不回滚
• 忽视上下文连续性：每次输入都重新分类，丢失对话历史中的意图信息