对话流框架梳理及优化方向

为什么要重新设计对话流

先看清楚现在的问题是什么，再讲我们怎么解决。

当前对话流 = 模型执行过程的 1:1 还原展示

现在的 AI 对话流，本质上是把模型的每一步执行细节原封不动地铺给用户看：调了什么工具、搜了什么网页、读了哪个文件、跑了什么命令……全部按时间线一字排开。

当前对话流：模型执行过程的 1:1 回放

核心问题

用户不关心执行细节——调了哪个 MCP、读了几个网页、看了哪个文件的第几行。
任务完成时，用户最关心交付的产物是什么；
任务进行中，用户只关心AI 在往什么方向走，进展到哪一步了。

对话流里有什么

AI 和人交互时，对话流里会出现哪些零件？三大类。

模型内容输出

模型直接产出的文本内容

零件	说明
Thinking	推理过程
Output	面向用户的正文结论
Finish	最终完成总结

产物 Artifacts

AI 生成的可直接操作的最终结果

代码产物

Code Diff Preview Pull Request

文件产物

Doc / PPT / PDF Excel / CSV JSON / XML / YAML

媒体产物

图片

工具调用

AI 执行任务时调用的各类工具，按功能分 6 组

文件操作

Read Edit / Write Delete LS

搜索

Grep / Glob SearchCodebase WebSearch WebFetch

执行

RunCommand OpenPreview

协作

AskUser Browser Use Create PR

扩展

RunMcp Skill RunAgent

管理

TodoWrite Memory InitEnv

这些工具卡片在 UI 上长什么样？→ 查看所有卡片样式一览

这些零件在对话流中长什么样

帮我重构 Header 组件，加上响应式导航

Thinking, Read 3 files, SearchCodebase

分析完成。需要修改 Header 组件的导航逻辑，涉及 3 个文件。接下来按步骤执行。

分析项目结构和依赖

重构 Header 组件

更新样式和测试

最终验证

Editing src/styles/main.css...

Header.tsx +24 -8

确认执行命令

npm run build

Run Reject

对话流 = 这些零件的组合

折叠区块

Thinking + 工具调用序列，默认折叠为一行摘要

正文 Output

模型面向用户的关键输出，是对话流的分段标记

Todo 列表

长任务拆解成步骤，每个 Todo 是独立的折叠容器

工具调用（执行中）

当前正在执行的工具，标题实时切换 + 扫光动画

产物 Artifact

AI 生成的可操作结果：代码变更、预览、PR 等

干预卡片

需要用户确认/操作时，吸附在输入框上方

零件组装

核心是区分：什么是重要的零件，什么是不重要的。
不重要的组装起来折叠掉，重要的以明显的样式直接输出。什么是重要的？进展。

策略 1

不重要的，折叠起来

什么是不重要的？模型的执行明细——推理过程、工具调用、搜了什么网页、读了哪个文件，这些都是执行层的细节，用户不需要逐条看。把它们默认折叠为一个区块，需要时展开即可。

❌ Before — 全部平铺

Thinking

分析用户需求，确定修改范围，梳理涉及的文件和模块依赖关系...

Read

src/components/Header.tsx

Read

src/utils/api.ts

Read

src/styles/main.css

SearchCodebase

"header component usage"

分析完成。需要修改 Header 组件的导航逻辑，涉及 3 个文件。

Edit

src/components/Header.tsx (+12 -3)

Edit

src/utils/api.ts (+5 -1)

RunCommand

npm run build

修改完成，构建通过。导航逻辑已更新。

每一步都平铺展示，信息噪音大

✅ After — 折叠组装

Thinking, Read 3 files, SearchCodebase

Thinking — 分析用户需求，确定修改范围...

Read — src/components/Header.tsx

Read — src/utils/api.ts

Read — src/styles/main.css

SearchCodebase — "header component usage"

分析完成。需要修改 Header 组件的导航逻辑，涉及 3 个文件。

Edit 2 files, RunCommand

Edit — src/components/Header.tsx (+12 -3)

Edit — src/utils/api.ts (+5 -1)

RunCommand — npm run build

修改完成，构建通过。导航逻辑已更新。

执行细节折叠为工具调用摘要

右侧折叠区块可点击展开/收起

策略 2

重要的，用正文输出

关键节点通过模型正文 Output 嵌在对话流中。折叠区块之间的 Output 就是分段标记，告诉用户当前进展。

❌ 没有正文 — 黑箱

Thinking, WebSearch ×3

WebFetch ×4, Read 2 files

Edit 3 files, RunCommand

Edit 5 files, RunCommand

一堆灰块，完全不知道在干什么

✅ 有正文 — 进展清晰

Thinking, WebSearch ×3

已搜集到 12 篇行业报告素材，涵盖市场规模、竞品数据、用户画像三个方向。接下来整理核心数据。

WebFetch ×4, Read 2 files

数据整理完成。现在开始组装 PPT，按「现状→问题→方案→数据支撑」四段结构。

Edit 3 files, RunCommand

PPT 主体框架已生成（18 页）。接下来调研视觉风格，优化排版。

Edit 5 files, RunCommand

同样的执行过程，有正文 Output 的版本让用户随时知道：做了什么、发现了什么、下一步干什么

策略 3

长任务，用 Todo 拆解

常规任务靠前两个策略就够了：不重要的折叠，重要的用正文呈现。

但长任务不一样——执行过程有大量上下文输出，即使折叠 + 正文分段，信息量仍然很大，用户很难快速定位进度。

这时候需要把过程上下文按 Todo 聚合分类。
每个 Todo 是一个独立的折叠容器，用户想看哪个阶段的细节，展开对应的 Todo 即可。

❌ 无 Todo — 平铺

Thinking, Read 5 files

先看看项目结构...

SearchCodebase, Grep

找到了相关代码...

Edit 3 files

修改了组件...

Edit 2 files, RunCommand

更新了样式，运行测试...

Read, Edit, RunCommand

修复了一个测试问题...

↕ 内容很长，难以定位

✅ 有 Todo — 结构化

分析项目结构和依赖

Thinking, Read 5 files

先看看项目结构...

SearchCodebase, Grep

找到了相关代码...

重构 Header 组件

Edit 3 files

修改了组件...

更新样式文件

Edit 2 files, RunCommand

更新了样式，运行测试...

运行测试并修复问题

Read, Edit, RunCommand

修复了一个测试问题...

最终验证和清理

↕ 点击 Todo 展开详情

AI 干活时的状态反馈

状态反馈的核心是回答用户最关心的一个问题：目前干到哪一步了。
从微观到宏观，三个层次。

策略 1

工具轮播，表达当前进展

最小颗粒度的反馈：当某个工具正在执行时，标题实时轮播切换当前动作。
不需要展开细节，扫一眼就知道现在在做什么。

Thinking, Read 3 files, SearchCodebase

分析完成，开始修改文件。

Editing src/Header.tsx...

正在执行 · 自动切换步骤

策略 2

Todo 下的实时日志流，感受整个 Todo 流程的推进

每个 Todo 下方挂一个流式输出区块，展示当前阶段的执行日志。
最新的行最清晰，旧的渐隐——扫一眼就知道「还在跑、没卡住」。

运行测试并修复问题

流式输出 · 最新行最清晰

策略 3

Todo 状态，总览全局进度

从最宏观的层面：哪些做完了、当前在做什么、后面还有几步。
三种状态一目了然——done / progress / pending。

分析项目结构

安装依赖包

重构核心组件

编写单元测试

运行 CI 验证

自动循环演示中

用户干预

核心思路：把操作区域和信息区域分离。

核心问题

操作不应该散落在对话流中

以前操作和信息混在一起，需要用户确认的卡片嵌在对话流正文里。
随着对话滚动，操作区域可能被滚出视野，用户注意不到需要操作；也容易出现滚动条嵌套等体验问题。

现在把所有需要用户干预的操作收敛到一个固定位置——输入框上方。
无论是删除文件、执行命令、还是工具调用授权，只要需要用户确认，都在这个稳定入口出现。
用户始终有预期：需要我操作的东西，就在那个位置。

提问组件嵌在对话流中间，容易被滚动遮盖

交互演示

干预卡片吸附在输入框上方

所有需要用户确认的场景，都以卡片形式出现在输入框上方。
操作完成后卡片消失，回到正常对话流。

Solo AI Chat

Thinking, Read files

正在分析你的项目，需要执行一个命令来安装依赖。

Editing files...

确认执行命令

npm install --save-dev typescript

输入消息...

点击按钮或等待自动切换不同场景

覆盖场景

覆盖的操作场景

以下所有场景都通过输入框上方的干预卡片统一处理。

💬 AskUser 提问

▶️ RunCommand 确认

🗑️ Delete 确认

🔌 MCP 权限

🔀 Code Merge

🌐 Browser Use

🔔 Notify 通知

下个版本

三个方向：继续收缩过程、按场景精细化、让 AI 自己决定怎么呈现。

方向一

过程信息进一步收缩——结果的重要性远大于过程

核心逻辑：用户关心的是结果，不是过程。随着模型能力增强，用户对执行细节的关注会越来越少。

当前方案已经把工具调用折叠了，但折叠区块仍然在对话流中占位。下一步可以更激进——把过程态从对话流中彻底剥离，用独立容器承载。

对话流只保留结果和关键节点输出，过程细节收进一个独立的侧边面板或抽屉。用户想看随时能看，但默认不打扰主线阅读。

当前：过程折叠在对话流中

帮我重构这个组件

Thinking, Read, Edit 3 files

已完成组件拆分，提取了 3 个子组件。

Thinking, Edit, RunCommand

类型检查通过，重构完成。

未来：过程剥离到独立容器

帮我重构这个组件

已完成组件拆分，提取了 3 个子组件。

类型检查通过，重构完成。

执行细节

Thinking

Read 5 files

Edit Header.tsx

Edit Nav.tsx

Edit App.tsx

RunCommand

...

左：当前方案，折叠区块仍在对话流中 → 右：未来方案，对话流只留结果，过程收进独立面板

方向二

按场景精细化——特殊任务需要特殊呈现

当前的信息分级策略是通用的：折叠过程、突出结果、Todo 拆解。这套方案覆盖了大多数常规任务。

但有些场景天然需要更细粒度的过程展示。比如 PPT 生成——用户等待时间长，非常想知道每一页的进度；而且每渲染完一页就可以先展示出来，不用等全部完成。

类似的还有长文档生成、批量图片生成等。这类任务的共同特征是：产物可以分片交付，用户对每一片的进度都有预期。

未来可以针对这些场景做专属的呈现方案，而不是用通用策略一刀切。

PPT 等特殊场景：逐页交付，完成一页展示一页，用户随时能看到已完成的部分

方向三

生成式 UI（研发先探索）——让 AI 决定怎么呈现过程

前面两个方向本质上还是人在定规则：哪些折叠、哪些展示、哪些场景特殊处理。

更远一步的思路是：让 AI 自己判断什么信息值得呈现、用什么形式呈现。

打个比方：就像下属给老板汇报，不是把所有工作日志念一遍，而是挑出关键的推演过程和决策节点来讲。哪些过程值得展开说、哪些一笔带过、哪些根本不用提——这个判断应该由 AI 来做。

这就是生成式 UI 的核心逻辑：AI 不仅生成内容，还生成内容的呈现方式。过程信息不再是固定的折叠/展开模板，而是 AI 根据当前任务的上下文，动态决定用什么结构、什么粒度来呈现执行过程。

AI 自主决定呈现方式

场景 A · 简单任务

AI 判断：过程无关紧要，直接给结果

💬 修复这个 typo

已修复 utils.ts 第 42 行的拼写错误。

场景 B · 复杂决策

AI 判断：决策过程有价值，主动展示推演

💬 选一个状态管理方案

对比了三个方案：

Zustand — 轻量，适合当前体量
Redux — 过重，团队没有使用经验
Jotai — 原子化，但生态较小