🍎
Wen’s Blog
About

AI流式加载的UX设计反思：从"等待页面"到"就地生成"

状态
Tags
Tech_Tag
Created
Sep 1, 2025 02:19 AM
在开发”manitodo"这款显化+任务管理应用时，我们遇到了一个看似简单但实际复杂的问题：如何设计AI任务生成的加载体验？这个过程让我们深刻理解了现代AI应用中流式交互的设计原则。

问题的起源：传统思维的陷阱

最初的设计思路

当我们决定集成Kimi API来生成个性化任务时，很自然地采用了传统Web应用的思维模式：
  1. 用户输入目标和愿景
  1. 跳转到专门的加载页面
  1. 显示进度条和生成状态
  1. 完成后跳转到任务列表页面
这种设计看起来合理，也符合我们对"加载"概念的直觉理解。我们甚至实现了一个相当完整的AIGenerationLoadingView：
struct AIGenerationLoadingView: View {
    let progress: Int
    let partialTasks: [Task]

    var body: some View {
        VStack {
            // 进度条
            ProgressView(value: Double(progress), total: 100.0)

            // 已生成的任务预览
            ForEach(partialTasks) { task in
                // 任务卡片预览
            }

            // 等待中的占位符
            // 降级选项...
        }
    }
}

用户测试中暴露的问题

然而，在实际使用中，我们发现了几个严重的体验问题：
1. 体验断裂感强烈 用户从任务定制界面突然跳转到加载页面，再跳回任务列表，整个流程感觉像是"被中断了"。
2. 进度条的"谎言" 我们设计的0-100%进度条实际上是基于网络响应块数计算的，但AI生成本身是不可预测的。用户会感觉进度条在"撒谎"。
3. 缺乏控制感 在专门的加载页面中，用户除了等待什么都做不了，这与他们在ChatGPT、Claude等应用中习惯的"边生成边查看"体验形成强烈反差。

认知转变：重新理解"流式交互"

现代AI应用的启示

深入分析ChatGPT、Claude、GitHub Copilot等成功的AI产品后，我们发现了一个关键模式：它们从不使用专门的加载页面。
  • ChatGPT在对话框中逐字显示生成内容
  • Claude在同一界面流式展示回答
  • GitHub Copilot在代码编辑器中实时显示建议
这些应用的共同特点是"就地生成"——在用户的工作上下文中直接显示AI的输出，而不是跳转到其他页面。

用户心理模型的变化

传统的"加载"概念来自于文件下载、页面跳转等场景，用户的心理预期是"等待→完成→使用"。
但AI生成的心理模型完全不同：
  • 用户期待看到"思考过程"
  • 希望能实时查看和修改结果
  • 需要保持工作流的连续性

重新设计：从状态机到交互流

状态设计的核心洞察

我们原来的状态机设计：
.idle → .generating → .completed
存在一个根本问题：它把AI生成当作一个独立的"过程"，而不是任务定制功能的"增强"。
重新设计后的状态机：
enum TaskCardState {
    case skeleton      // 等待生成
    case generating    // 生成中
    case completed     // 生成完成，可编辑
    case editing       // 用户编辑中
}
这个设计的关键改进：
1. 颗粒度更细：每个任务卡片有独立状态，而不是整个页面一个状态
2. 状态隔离：正在编辑的任务不会被新的AI输出覆盖
3. 并发友好：支持"一边生成一边编辑"的使用场景

界面架构的重构

原来的架构（问题方案）：
TaskCustomizationView → AIGenerationLoadingView → TaskList
新的架构（改进方案）：
TaskCustomizationView {
    TaskCard(state: .skeleton)
    TaskCard(state: .generating)
    TaskCard(state: .completed)
    // 用户可以随时编辑任意卡片
}

技术实现的关键决策

1. 真实的进度反馈

我们放弃了误导性的百分比进度条，改用更诚实的反馈方式：
// 替换: "45% 完成"
// 使用: "正在生成第3个任务..."
Text("正在生成第\(currentIndex + 1)个任务...")

2. 流式数据的处理策略

关键是要让UI响应真实的数据流，而不是模拟的进度：
for await update in aiGenerator.generateTasks() {
    switch update {
    case .partialTask(let task):
        // 立即显示新任务，不等待全部完成
        tasks.append(task)
    case .completed(let allTasks):
        // 最终同步
        tasks = allTasks
    }
}

3. 降级策略的重新思考

原来我们把"降级到模板"当作失败处理，现在把它设计为"用户选择"：
  • 15秒后显示"使用推荐模板"按钮
  • 30秒后自动填充剩余位置，但保持已生成的任务
  • 始终允许用户自由编辑

学到的核心原则

1. 上下文连续性原则

用户的工作流不应该被技术实现打断。AI生成应该感觉像是当前任务的"增强"，而不是"切换"到另一个流程。

2. 透明度胜过美观

真实的、不确定的进度指示比美观但虚假的进度条更能建立用户信任。

3. 并发交互设计

现代用户期待能够"一边等待一边工作"。界面应该支持同时进行多个操作，而不是强制串行。

4. 状态的精细化管理

将状态管理的粒度细化到具体的UI组件级别，而不是页面级别，能提供更灵活和响应式的用户体验。

对其他AI产品设计的启示

这次重构让我们意识到，AI产品的交互设计需要一套全新的设计语言：
传统软件设计原则：
  • 操作→等待→结果
  • 状态明确、边界清晰
  • 错误处理基于失败/成功二元模式
AI产品设计原则：
  • 操作→协作→持续优化
  • 状态流动、边界模糊
  • 错误处理基于降级和恢复

具体的设计模式

1. 就地生成模式 在用户的工作上下文中直接展示AI输出，避免页面跳转。
2. 渐进式揭示模式 内容准备好一部分就显示一部分，而不是等待全部完成。
3. 双向协作模式 用户可以在AI生成过程中进行编辑，AI也会基于用户的编辑调整后续输出。

结语：重新定义"加载"

这次重构让我们深刻理解了一个道理：在AI时代，"加载"的概念需要重新定义。
它不再是"等待某个过程完成"，而是"与AI协作创造内容"的过程。用户不应该是被动的等待者，而应该是主动的参与者。
这种认知转变不仅改善了我们的产品体验，也为我们后续的AI功能设计提供了重要的指导原则。当我们把AI当作"合作伙伴"而不是"工具"来设计交互时，整个用户体验会发生质的改变。
Copyright 2022 Wen Jiaqi