AI聊天界面的变化很容易被看见：文字在生成，按钮在切换，侧边栏又增加了一次会话。但看到变化，不等于每个人都知道发生了什么。Eric Bailey在近期文章中，从可访问性角度重新讨论了沉浸式AI聊天体验。兰亭妙微这次把阅读视角放到企业助手的使用过程里：一个人提交材料、等待回答，再回到自己的任务，界面应该怎样接住这些动作。以下包含独立的应用示例与AI概念配图，不是对某款产品的实测结论。
一个典型的企业助手任务，可能从历史会话开始：用户找到上次的问题，添加一份新材料，提出补充要求，核对回复，再复制部分内容。只展示输入框和生成答案，很容易忽略这条路径的前后两端。界面评审可以围绕完整任务展开，看每次切换是否还保留清楚的上下文。
Eric Bailey原文中的多款LLM聊天界面截图拼图，展示这类产品的常见布局。
例如用户从知识库进入聊天页，标题可以继续表达正在处理的事项，附件也应有容易核对的名称。历史会话列表中的选中项、主区域的会话名称和当前材料之间，需要有能够对应的线索。若这些位置各用一种简称，读者就要依赖记忆判断自己有没有进错会话。
一份好的界面说明，也应该交代这些内容从哪里来，而不是只标注它们用了几号字。可以把“来源是历史记录”与“内容是用户本次输入”分开呈现；当系统生成了新的标题，也要看看它是否会让原来的记录突然难以寻找。可理解的结构，往往从这些细小的连续关系开始。
等待不一定需要复杂动画。以整理一份设备巡检材料为例，用户更关心材料是否已经接收、当前是否仍在处理，以及自己能否停止或补充要求。可见的说明应与真实处理阶段对应，不要为了显得忙碌而不断更换没有依据的进度数字，也不要让短暂的安静看起来像页面失去响应。
AI概念示意：等待生成时同时保留可见状态、停止入口与输入区。
同样的信息还需要有非视觉的表达。Eric Bailey提醒，不能只让看得见画面的人知道生成已经开始或结束。设计稿可以记录状态文案和触发时机，再由工程与测试验证实际播报效果。视觉样稿只能说明希望怎样呈现，不能替代辅助技术中的运行检查。
停止和失败也需要分开讨论。用户主动停止以后，已经生成的部分是否保留；处理失败时，原始输入与附件是否还可继续使用；重新尝试会不会覆盖当前内容。这些都应该有明确结果。与其在一个按钮旁放很长的解释，不如让每个阶段对应的动作少而清楚，并在动作以后给出能确认的反馈。
用户阅读答案时，可能会跳回自己的问题，核对附件，再查看某一条建议的依据。可以让消息归属、生成状态和相关操作有稳定的位置，让人不用每次都从头判断哪部分属于自己的输入。对于很长的回答，标题和分段也应服务于内容本身，而不是把所有句子都做成相同的卡片。
AI概念示意：回复归属、完成状态和后续动作的组合；不是屏幕阅读器测试截图。
如果产品提供复制、查看来源或再次生成，需要说明这些操作作用于整段回答还是其中一部分。复制完成的反馈可以靠近刚才的操作；打开来源后，返回时也应能找到原来的阅读位置。边栏虽然可以承接参考资料，但不要让它把主区域挤到无法阅读，也不要在用户正在输入时突然改变布局。
把答案送到下一步，也是可以讨论的界面问题。例如要把摘要带入工单，先让用户核对将要带过去的内容与目标位置，再完成明确的提交。这个假设示例强调的是操作范围，而不是宣称AI答案可靠。漂亮的文字输出与已经核对好的业务结果，是两个需要分别呈现的状态。
只用鼠标点击一遍，很难发现所有导航问题。可以再安排一轮只用键盘的任务：找到某次历史会话，进入正文，回到输入区，提交问题，再定位新回答。观察焦点是否始终可见，有没有突然跳到意外的位置，以及用户是否需要经过大量无关按钮才能继续。
AI概念示意：会话历史、正文和输入区之间的键盘导航设计。
对于已有很多历史记录的助手，还可以加入搜索、长标题和折叠分组的示例。重点不是机械减少所有按键次数，而是让导航规则可预测。某个区域收起以后焦点留在哪里，弹层关闭以后回到哪里，都应在原型与实现里检查，不能只写一句“支持键盘”就结束。
最后把评审发现记成可以复查的问题。例如“回答完成后没有明确的定位方式”，比“可访问性需要加强”更容易分配处理。再分别记录视觉检查、键盘检查和辅助技术验证的结果，避免一种检查通过，就被当成所有体验都已经完成。这种做法同样适用于普通后台的表单、列表和弹层。
AI聊天界面的重点，不应只停在答案怎样出现。等待是否可理解，消息能否回看，操作有没有清楚的作用范围，都影响使用者能否继续完成任务。把这些过程放进设计讨论里，可访问性就不再只是文末的一句要求，而会具体地改变我们怎样组织一个界面。
