是什么让 AI 文本对话感觉自然：打字速度还是交互节奏？
对于 AI 文本对话而言，令人信服的交互与其说取决于文字出现的速度，不如说取决于对话的每个阶段是否合乎逻辑：用户能够感知系统已收到消息、回复以易读的分块形式呈现，以及完成或中断状态清晰明确。单靠打字动画无法营造出这种节奏。围绕有用的反馈和用户控制权来设计界面，并将模拟打字视为一种可选的视觉效果，而非证明另一端是真人的依据。
打字动画是一种信号，而非对话本身
跳动的省略号或“正在输入”标签可以表明回复正在准备中。Visa 的聊天设计指南将输入指示器描述为发出活跃响应信号的一种方式，并将其与生成式 AI 工作期间使用的进度指示器区分开来。这种区分很有用：“正在输入”暗示有人在撰写；而“正在处理”或“正在生成”则更直观地描述了系统进程。对于 AI 助手，请选择能够准确命名状态的措辞，而不是暗示人类身份或人类打字模式。（Visa 产品设计系统：Chat）
固定的停顿加上模拟逐字显示的效果，可能会让界面看起来像即时通讯应用，但它并不能告诉用户请求是否已被接收、系统是否仍在处理，或者回复是否已完成。它还可能让简短、简单的回答显得被无谓地拖延。真正有用的设计问题不是“每个字符应该花费多少毫秒？”，而是“用户在等待、阅读或决定下一步行动时需要知道什么？”
从用户的任务和等待成本出发
首先识别消息背后的工作量。对于简单明了问题的简短回答，可能只需要短暂的处理提示和完整的回复。而需要较长操作的响应（例如检查提供的文档），可能会受益于更具描述性的状态以及诚实的预估时间（如果有的话）。当耗时未知时，请使用不确定进度指示器，切勿编造倒计时。Apple 的进度指南区分了确定进度（可测量持续时间或进度）与不确定活动，并建议提供准确的进度反馈，以及在可行时提供停止工作的方法。（Apple 人机界面指南：Progress Indicators）
一个实用的顺序是确认收到请求，若有明显的等待则显示工作正在进行，然后在准备就绪时呈现答案。这些是独立的状态，即使紧凑的界面将其中一些合并也是如此。“已发送”状态确认了用户的操作；活动提示传达了等待状态；生成的消息则包含结果。避免在工作停止后仍将提示留在屏幕上，或在未明确说明答案已完成的情况下将其移除。如果请求失败，请解释原因并提供可操作的下一步，例如重试。Visa 的聊天指南同样建议在消息发送失败时提供清晰的错误消息和重发选项。（Visa 产品设计系统：Chat）
利用消息分块辅助用户阅读
在词语或短语可用时以流式传输呈现，可以在生成完全结束前让响应可见。这与以人工打字速率播放已完成答案的动画截然不同：流式传输反映了输出的实际到达，而逐字显现动画则是在文本已经存在后增加了人为延迟。OpenAI Responses 流式传输参考文档记录了用于响应创建、文本更新和已完成文本的事件。这些事件展示了在进行中的响应与已完成文本之间有用的界面区分；它们并未规定统一的显示速度或分块大小。（OpenAI API 参考：Streaming events）
为了实现易读的对话，请尽可能显示连贯的短语或句子大小的块，保留段落换行，并避免内容到达时消息发生跳动。这是源于阅读任务的设计建议，而不是关于理想分块长度的硬性规则。如果答案很长，可以先显示简短的导语或首个实用部分，其余部分则在稳定的布局中陆续跟进。切勿拆分得过于细碎导致读者看到闪烁不定的碎片流，也不要仅仅为了模仿人类打字而扣留完整、可用的答案。当界面支持时，保持停止或重新生成等控件易于查找。
让等待反馈准确且成比例
当工作需要耗费时间时，指示器应该描述系统实际获知的信息。仅在可以有效测量进度时使用确定性进度条或百分比。否则，简单的活动指示器即可传达工作仍在继续的信息，而无需假装能够预测完成时间。Apple 建议保持进度报告准确、解释停顿原因，并在可行时允许用户中止处理。同样的原则也适用于聊天：如果处理过程停滞，请从无休止播放动画的“处理中”状态切换为有用的消息，例如“响应已中断。请重试。”
避免反复更改状态文案来制造活跃的假象。诸如“正在思考……”、“仍在思考……”和“马上就好……”这样的序列，只有在每条消息都反映了真实状态并能帮助用户决定该怎么做时才有用。否则，一个明确的状态引起的干扰更小。特别是，除非系统有可靠的依据支持该说法，否则不要说“即将完成”。一个简短、真实的提示，会比生动却毫无信息量的动画让人感觉更贴心。
将“完成”视为一种真实的状态
用户需要知道响应何时完成，特别是当他们想要复制内容、提出后续问题或打断正在进行的输出时。生成结束时移除或替换活动提示，并确保最终消息保持稳定，成为用户可以阅读和交互的消息。如果输出可能不完整地结束或被取消，请传达该状态，而不是将部分答案呈现为已完成。流式 API 参考将文本更新与完成事件进行了区分，并指出完成事件也可能伴随中断或不完整的响应；因此，界面应该表现其真正收到的结果。（OpenAI API 参考：Streaming events）
“完成”状态也需要传达给不依赖视觉动画的人群。W3C 指南解释说，状态消息可以在不移动用户焦点的情况下传达等待、进度、成功或错误，并且这些更新应该能被辅助技术通过编程方式识别。MDN 的活动区域（live region）指南介绍了针对重要非紧急更新的礼貌播报（polite announcements），并警告频繁的断言式播报（assertive announcements）可能会打扰用户。在实践中，应播报有意义的状态变化——例如响应可用或请求失败——而不要把每个 token 或动画帧都变成语音播报。（W3C WAI：Understanding Status Messages；MDN：ARIA live regions）
让用户掌控节奏
自然流畅的交流会留给用户行动的空间。在可行的情况下允许用户停止响应，并明确停止是终止生成还是仅仅暂停显示。如果响应是流式传输的，请保持可见文本易于阅读，并允许用户继续浏览对话。当完整答案能迅速就绪时，避免强加戏剧性的停顿；当实际处理需要更长时间时，说明工作仍在进行中。目标是配合用户的时间节奏，而不是引导他们进行更长时间的等待。
这也有助于将界面的对话风格与关于“谁或什么在回应”的虚假陈述区分开来。AI 系统可以使用简洁、友好的措辞和消息样式的呈现方式，同时仍然准确地表明自身身份。“正在准备回复”描述的是系统活动；而“我正在输入”可能会被理解为真人在打字。在选择标签时请考虑到可能产生的理解，尤其是在用户很容易将指示器误认为是人类参与者的产品中。
选择模式的简单决策法则
仅在打字风格的动画能提供清晰、简短的提示且不暗示有人类操作员时才使用它。当系统正在执行耗时超出用户即时操作的工作时，请使用进度指示器。当提前展示输出有助于完成任务时，流式传输易读的消息分块，并在响应实际完成时标记完成。在中断可能且有用时添加相应控件。对于任何重要的状态变化，请确保在不单纯依赖动作或颜色的情况下也能被感知到。
快速的设计审查可以提出四个问题：用户的操作触发了什么？系统真正处于什么状态？用户在等待时可以做什么？用户将如何知道结果已完成——或者出了问题？如果答案明确，那么交互无需伪造人类打字节奏即可让人感到响应灵敏。这种品质来自协调的反馈、易读的交付和控制权，而不是来自那些圆点的跳动速度。