AI流式回复不能只设计“文字逐个出现”的动效。至少要区分等待首段、正在生成、用户停止、生成完成和意外中断，并约定部分内容是否保留、重试是否产生新版本、用户向上阅读时页面是否继续滚动。
以知识助手解释报销规则为例，先用墨刀原型连接回答中的不同状态，演示停止、重试与回看历史。原型用于表达预期行为；网络流、中止请求和真实回答生成由应用实现，不能用打字动画证明后端已经支持这些能力。
先为一条消息写清生命周期
用户发出“出差报销需要什么材料”后，助手可能还在检索，尚未输出正文。此时展示“正在查找相关规则”比让空白气泡一直闪烁更容易理解，但只有确实在检索时才能这样写，不能编造模型正在执行的步骤。
| 状态 | 用户看到什么 | 可以做什么 |
|---|---|---|
| 等待首段 | 已收到问题，等待响应 | 取消本次等待 |
| 生成中 | 已到达内容和持续生成标记 | 停止生成、回看历史 |
| 已停止 | 保留已生成内容，标明未完成 | 重新生成或编辑问题 |
| 已完成 | 完整回答及可用的后续动作 | 复制、继续提问、查看依据 |
| 意外中断 | 部分内容和明确失败信息 | 重试，不必重新输入原问题 |
“已停止”不应画成错误红框，这是用户主动做出的选择。相反，连接断开也不能悄悄显示成完成，尤其回答只有半句话时。状态标签要与正文一起保留，避免用户稍后回来把未完成回答当成最终结论。
停止按钮承诺的是哪一件事
停止显示文字、停止接收流和停止后端生成，并不天然是一回事。设计交付需要明确点击后客户端发出什么请求、已在途片段怎样处理、服务端是否确认终止。若系统仍在结束处理中，按钮可先进入“正在停止”，确认后才固定为“已停止”。
Carbon AI Chat的消息配置把停止流式回复按钮的显示时机作为独立设置。这说明停止控制应当单独约定，不能附带在一般加载动画里。本文采用的知识助手规则是：生成开始后持续提供停止入口，点击后保留已有内容。
还要把“停止这次回答”和“取消真实业务动作”分开。若智能体已经提交了一张报销单，停止聊天不一定能撤回报销。此类执行任务应另按智能体权限与人工接管规则展示真实执行状态，不能把所有后果塞给同一个停止按钮。
重新生成时，别让旧回答凭空消失
对本例的知识问答，可以把重试设计为同一问题下的新回答版本：旧回答保留为“未完成”，新版本生成时显示明确状态，完成后允许切换查看。这样用户能比较结果，也不至于刚复制了一半内容，页面就把来源覆盖。
如果采用直接替换，点击前应说明替换范围。用户手动修改过的回答、选中的文本和附带批注都需要决定如何保留。产品可以不提供多版本功能，但必须让“再生成一遍”的后果可预测。
连续点击重试只应建立一次新的生成请求，或明确拒绝新的请求；不能在同一气泡交错显示两份回答。交互说明中给每次生成一个请求标识，有助于研发把迟到的旧片段归回原消息，而不是追加到新回答末尾。
滚动跟随要服从阅读动作
用户停在对话底部时，可以随新内容保持底部可见；一旦主动向上滚动，自动跟随就应暂停。此时显示“有新内容”或“回到最新”，让用户决定何时回去。否则每次生成一段文字都把人拉到底部，复制旧信息会非常困难。
不要用固定的像素距离作为所有设备的唯一判断依据。字号、视口、输入框高度都会变化。实现可以按是否接近底部判断，但原型交付应写清行为原则：主动回看不被抢走，主动回到底部后再恢复跟随，输入框展开不遮住最后一段。
键盘焦点也不能追着每个新字移动。发送消息后保留可预期的焦点，停止按钮可通过键盘到达；对读屏用户，避免把逐字更新全部连续播报。可在开始、停止、完成时给简短状态，并让用户主动浏览回答。具体实现需结合产品的无障碍方案测试。
格式与引用要等到它们真的可用
代码围栏、表格和链接可能在流的中途还没有闭合。呈现策略应避免页面反复大幅跳动，也不能提前把尚未形成的地址变成可点击链接。完整段落到达后再稳定渲染复杂结构，通常比每个字符都重建整段内容更容易控制。
回答引用的文档在生成途中可能尚未确定。引用编号应与最终来源对应，不能先出现看似可靠的编号，最后却没有可打开的材料。用户点击引用时，最好能进入相关文档和对应片段；若只能到文档首页，入口文字应反映这个实际去向。
评审时故意在不顺利的时刻停下来
用同一问题走四条路径：首段到达前取消；生成到一半主动停止；正在回看上一条消息时继续收到内容；连接断开后重试。分别记录部分文字、滚动位置、焦点和请求归属。正常回答完成只是其中一条路径。
可以先复用AI对话界面的基础模板，再把上述状态补齐。真正需要评审的不是助手看起来多“聪明”，而是用户能否控制阅读和后续动作，并准确知道这份回答有没有完成。
