---
name: Conversation Flow
slug: conversation-flow
category: AI Engineering
description: Conversation Flow defines how an AI classifies user intent, routes requests into task-specific paths, and chooses when to ask clarifying questions versus proceed autonomously. Use it for multi-step assistants and agents that need structured dialogue management.
github: "https://github.com/kangarooking/system-prompt-skills/tree/main/conversation-flow"
stars: 182
forks: 40
install: "npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/conversation-flow ~/.claude/skills/conversation-flow"
installs_to: ~/.claude/skills/conversation-flow
source_path: conversation-flow/SKILL.md
collection_size: 15
category_size: 3278
collection_url: "https://dirskills.com/collections/kangarooking/system-prompt-skills"
added: 2026-09-06T05:21:03.411Z
last_synced: 2026-09-06T05:21:03.411Z
canonical_url: "https://dirskills.com/skills/conversation-flow"
---

# Conversation Flow

Conversation Flow defines how an AI classifies user intent, routes requests into task-specific paths, and chooses when to ask clarifying questions versus proceed autonomously. Use it for multi-step assistants and agents that need structured dialogue management.

**Install:**

```bash
npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/conversation-flow ~/.claude/skills/conversation-flow
```

## README

# 对话流程与路由设计

## 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 自主决策路由
- 创意对话/闲聊场景——过度结构化会破坏自然感

### 常见失败模式

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