AI 动态 UI 里的状态结构太容易失控，我整理了一套分层管理的方法

当你在 AI 动态 UI 里用一堆散乱的 useState 和 useEffect 硬扛状态时，三个月后连自己都看不懂代码的走向。这不是能力问题，是架构缺失的必然结果。

我去年接手过一个 AI 客服面板的重构项目，最初的实现方式是典型的“需求驱动堆砌”——产品说这里要加一个推荐问题列表，就在组件里加几个状态；说要支持多轮对话分支，就再塞几个条件判断。到后来，一个聊天面板组件里塞了 23 个 useState，状态之间的依赖关系全靠 useEffect 的依赖数组硬连，改一个地方崩三处。重构时我整理了一套分层状态管理的方法，核心思路就是把 AI 动态 UI 的状态拆成四个层级：渲染状态、交互状态、数据状态、元状态。每层只关心自己的事，层与层之间通过明确的接口通信。

先把“动态”拆开看：为什么 AI UI 的状态特别容易失控

传统 UI 的状态变化路径相对固定——用户点击按钮，触发事件，更新状态，重新渲染。这条链路是可预测的，因为状态变化的发起方和响应方都是确定的。

AI 动态 UI 不一样。它的状态变化来源多了三个维度：模型输出的不确定性（流式响应的内容长度、结构、类型都未知）、生成内容的多样性（同一段 prompt 可能返回文本、代码块、表格、操作建议），以及交互模式的动态性（AI 可能在对话中途主动插入提问、提供快捷操作、切换上下文）。这三种不确定性叠加在一起，意味着你不能再用“预设所有可能状态”的思路来写代码。

我在那个客服面板里遇到过一个典型的 bug：用户发了一条消息，AI 正在流式返回时，用户又点击了一个推荐问题。原来的代码逻辑是直接覆盖 messageList 状态，导致正在流式渲染的消息被截断，同时新的请求发出后，两条流式响应互相覆盖。修复这个问题不是加个 loading 锁能解决的，因为状态本身就没有区分“正在渲染的内容”和“已确认的内容”。

四层状态模型：每层只对自己的事负责

我把 AI 动态 UI 的状态拆成了四层，这个分层不是拍脑袋想出来的，是在重构那个项目时逐步抽象出来的。

渲染状态层：只负责“屏幕上正在显示什么”

这层的状态生命周期最短，变化频率最高。典型的渲染状态包括：当前正在流式输出的文本片段、打字机效果中已显示的字符数、临时高亮的代码块位置、消息气泡的展开/收起动画进度。

关键原则是：这层的状态不应该被持久化，也不应该被其他层直接依赖。它们是纯展示层的临时快照。

// 渲染状态层示例：流式文本的中间态
interface StreamingState {
  // 当前正在流式输出的消息 ID
  activeMessageId: string | null;
  // 已接收但尚未完全渲染的原始文本块
  pendingChunks: string[];
  // 打字机效果的当前偏移量
  typewriterOffset: number;
}

在实现上，我用了一个独立的 useReducer 管理这层状态，所有 action 都是同步的、无副作用的。流式响应的每个 chunk 到达时，只 dispatch 一个 APPEND_CHUNK action，reducer 里纯函数更新 pendingChunks。打字机效果的定时器只读取 typewriterOffset，不碰其他层的状态。

交互状态层：记录“用户做了什么、正在做什么”

这层状态的生命周期中等，通常是用户操作驱动的。包括：当前选中的对话分支、展开/折叠的工具调用详情、用户手动切换的主题或语言、输入框的草稿内容。

这层有一个容易踩的坑：不要把交互状态和渲染状态混在一起。比如“消息气泡的展开/收起”应该拆成两部分——交互状态记录“用户是否点击了展开按钮”，渲染状态根据这个布尔值计算动画的中间帧。

// 交互状态层：用户意图的持久记录
interface InteractionState {
  // 用户当前选中的对话分支索引
  activeBranchIndex: number;
  // 工具调用详情的展开状态，key 是调用 ID
  expandedToolCalls: Record<string, boolean>;
  // 输入框草稿
  draftInput: string;
  // 用户手动切换的模型参数覆盖
  modelOverrides: Partial<ModelParams>;
}

在客服面板重构中，我把“推荐问题列表”的显示逻辑从原来的组件内部状态提升到了这一层。之前的问题是：AI 返回的推荐问题有时会带一个 shouldShow 字段，有时不带，组件里既要判断用户是否手动关闭了推荐面板，又要判断 AI 返回的数据里是否包含有效推荐，两个条件混在一起导致推荐面板时隐时现。拆开后逻辑清晰了：交互状态层只记录 userDismissedRecommendations 这个布尔值，渲染层判断“是否显示”时，条件是 !userDismissed && recommendations.length > 0。

数据状态层：存放“AI 返回了什么、业务的真相是什么”

这是四层里最稳定的一层，也是唯一需要持久化到后端或本地存储的层。数据状态包括：完整的消息列表、每条消息的结构化内容（文本、代码块、工具调用结果）、对话的元数据（session ID、创建时间）、用户偏好设置。

关键约束：数据状态层的更新只能通过明确的、可追溯的 action 触发，不允许在组件里直接 mutate。

// 数据状态层：业务真相
interface DataState {
  sessions: Map<string, Session>;
  currentSessionId: string;
}

interface Session {
  id: string;
  messages: Message[];
  createdAt: number;
  updatedAt: number;
}

interface Message {
  id: string;
  role: 'user' | 'assistant' | 'system' | 'tool';
  content: MessageContent; // 结构化内容，不是纯字符串
  toolCalls?: ToolCall[];
  metadata: MessageMetadata;
}

interface MessageContent {
  text: string;
  codeBlocks: CodeBlock[];
  suggestions: Suggestion[];
  // 其他结构化片段
}

注意这里 Message.content 是结构化的对象，不是纯字符串。这是我从那个项目里学到的血泪教训——最早的消息内容就是 string 类型，前端每次要提取代码块、推荐问题、工具调用信息时，都要用正则去解析 Markdown。AI 模型的输出格式一微调，正则就失效。改成结构化存储后，解析逻辑只在消息入库时执行一次，前端渲染直接读字段。

元状态层：管理“系统本身在做什么”

这层状态描述的是系统的运行状态，与业务无关。包括：WebSocket 连接状态、当前活跃的请求数、错误重试计数、性能指标（首字节时间、流式速率）。

这层的状态不应该影响 UI 的内容渲染，只影响 UI 的 chrome 部分（连接状态指示灯、错误提示条）和系统行为（重试策略、降级逻辑）。

// 元状态层：系统运行状态
interface MetaState {
  connectionStatus: 'connecting' | 'connected' | 'disconnected' | 'reconnecting';
  activeRequests: number;
  retryCount: number;
  lastError: AppError | null;
  metrics: {
    timeToFirstByte: number;
    streamingRate: number; // bytes per second
  };
}

在实际实现中，我用了一个独立的 Zustand store 管理元状态，其他层的状态管理用 Redux Toolkit。两者互不依赖，元状态的更新通过事件总线通知 UI 层，UI 层自行决定是否响应。

层间通信：用事件而非直接引用

四层拆开后，下一个问题是层与层之间怎么通信。最差的做法是让渲染组件直接读取数据状态层的 store，这会让组件在数据状态的任何字段变化时都重新渲染。

我用的方案是事件驱动的订阅模式。数据状态层在消息列表更新时发布一个 message:updated 事件，渲染状态层订阅这个事件，在自己的 reducer 里决定是否需要更新渲染状态。这样渲染层的更新频率可以由自己控制——比如流式输出时，数据状态层每收到一个 chunk 都更新 MessageContent.text 并发布事件，但渲染层可以做 throttle，每 16ms 才更新一次 typewriterOffset。

// 事件总线的最小实现
type EventMap = {
  'message:updated': { messageId: string; content: MessageContent };
  'stream:chunk': { messageId: string; chunk: string };
  'stream:done': { messageId: string };
  'error:occurred': { error: AppError };
};

class TypedEventBus {
  private listeners = new Map<string, Set<Function>>();

  on<K extends keyof EventMap>(event: K, handler: (payload: EventMap[K]) => void) {
    const key = event as string;
    if (!this.listeners.has(key)) {
      this.listeners.set(key, new Set());
    }
    this.listeners.get(key)!.add(handler);
    return () => this.listeners.get(key)?.delete(handler);
  }

  emit<K extends keyof EventMap>(event: K, payload: EventMap[K]) {
    this.listeners.get(event as string)?.forEach(handler => handler(payload));
  }
}

在客服面板的重构中，这个事件机制解决了一个具体的性能问题：之前的实现里，消息列表中的每一条消息都订阅了整个 Redux store，导致流式输出时整个消息列表每秒重渲染 30 次以上。改成事件订阅后，只有当前正在流式输出的那条消息组件订阅 stream:chunk 事件，其他消息组件完全不感知流式过程。

处理 AI 特有的状态难题：分支、回退与修正

分层模型能解决大部分结构问题，但 AI 动态 UI 还有几个特有的状态场景需要单独处理。

对话分支：当用户可以选择不同的 AI 回复方向时（比如“请详细展开”和“换种说法”），数据状态层需要支持树形结构。我在 Session 里加了一个 branches 字段，用 parentMessageId 和 branchId 维护对话树。交互状态层的 activeBranchIndex 决定当前展示哪条分支。切换分支时，渲染状态层做退出动画，数据状态层不丢数据。

消息回退与重新生成：用户点击“重新生成”时，不是简单地把最后一条 assistant 消息删掉再发请求。数据状态层应该保留历史版本，交互状态层记录用户正在查看哪个版本。这样用户可以随时切换回之前的版本，不会丢失内容。

// 支持多版本的消息结构
interface Message {
  id: string;
  role: 'assistant';
  versions: MessageVersion[];
  activeVersionIndex: number; // 交互状态层的引用
}

interface MessageVersion {
  id: string;
  content: MessageContent;
  createdAt: number;
  modelParams: ModelParams;
}

工具调用的中间态：当 AI 决定调用一个工具时，UI 需要展示“正在调用工具 A...”、“工具 A 返回结果”、“基于结果生成回复中”这三个阶段。我把工具调用的生命周期建模为数据状态层的一个状态机，渲染状态层根据状态机的当前状态决定展示什么 UI。

type ToolCallStatus = 
  | { type: 'pending' }
  | { type: 'executing'; startedAt: number }
  | { type: 'completed'; result: unknown; duration: number }
  | { type: 'failed'; error: string; duration: number };

常见问题

这个分层模型对简单的 AI 应用来说是不是过度设计了？

如果应用只有单一对话流、不涉及分支和工具调用，确实不需要完整四层。但至少要把渲染状态和数据状态分开——哪怕只是把流式输出的临时文本和最终确认的消息内容放在不同变量里。这个拆分几乎零成本，但能避免流式输出中断、消息覆盖等基础 bug。我见过太多项目一开始觉得“一个 useState 就够”，到第三个月需求叠加时再重构，成本远高于一开始就分层。

事件总线会不会让数据流变得难以追踪？

比“所有组件直接读写全局 store”好追踪得多。事件总线的问题是异步跳转，但可以通过两个约束解决：一是事件名必须语义明确、携带完整 payload（不要用字符串拼凑的通用事件名），二是在开发环境对每个事件的发布和订阅做 console 日志。我在项目里加了一个 devtools 中间件，把所有事件流可视化成时间线，调试体验不差于 Redux DevTools。

数据状态层的结构化内容怎么设计 schema 才能适应不同 AI 模型的输出？

不要试图设计一个能容纳所有模型输出的万能 schema，这会让字段变成“大杂烩”。正确的做法是定义核心字段（text、codeBlocks、suggestions），其他模型特有的输出放到 metadata 这个 flexible 字段里。解析器按模型类型注册，各管各的格式。换了模型只要换解析器，数据结构不用动。我在客服面板里同时接入了 GPT-4 和 Claude，解析器不同，但写入的 MessageContent 结构完全一致。