# 1. 如何设计 idle、streaming、awaiting-tool、awaiting-confirmation、error、success 等消息状态及转换 A 用多个布尔标志（isStreaming、isError）组合即可，简单且不易出错 B 用显式状态机把状态转换收敛到单一事件处理，可避免标志互相矛盾并便于测试与恢复 ✓ 正确答案 C 状态机应允许任意状态间自由转换，便于灵活扩展 D 状态机只在渲染层使用，与数据层和请求层无关
# 2. 流式 Markdown、代码块、引用和工具进度如何安全渲染，并避免未闭合结构导致页面抖动 A 应容忍未闭合结构并做净化，同时增量更新 DOM 避免每 token 重建 ✓ 正确答案 B 整块重建 innerHTML 是保证 DOM 稳定的最佳方式 C 直接 innerHTML 渲染累积文本即可，模型输出是可信的 D 未闭合代码块必须要求用户手动点击闭合才能继续
# 3. 编辑重试、分支对话、停止生成、反馈和重新生成应怎样维护消息树与请求关联 A 对话用线性数组即可，重新生成时直接覆盖旧消息 B 用树模型建模分支，用 requestId 关联请求，便于取消、重试与审计 ✓ 正确答案 C 反馈信息应挂在用户会话上，与具体消息无关 D 停止生成只需要取消请求，不需要更新消息状态
# 4. 对话消息树（thread tree）应如何建模分支、回滚与重新生成，状态同步如何避免冲突 A 用版本号做乐观并发控制，冲突时提示或用规则合并，比盲目覆盖更安全 ✓ 正确答案 B 消息树无需版本号，后写覆盖先写即可 C 所有场景都必须用 CRDT 才能保证一致 D 分支和回滚不影响状态同步，无需考虑
# 5. 流式回答中“工具调用”与“文本回答”应如何在 UI 上视觉区分（图标、颜色、标签） A 工具调用应直接拼进正文文本，保持单一气泡 B 视觉区分只影响美观，不影响用户理解 C 工具调用不需要展示，只要最终文本即可 D 用独立工具卡片（图标、颜色、标签），可折叠，与正文文本区分 ✓ 正确答案
# 6. 前端如何把模型输出中的引用（citations）渲染为可点击链接并跳转到原文（带位置锚点） A 直接把模型输出的 URL 渲染为 href，不做校验 B 引用携带来源与锚点，点击前校验协议（禁 javascript:），失效时展示失效状态 ✓ 正确答案 C 引用只能以纯文本展示，不能做成链接 D 锚点失效时应当抛错提示用户
# 7. 乐观 UI 与服务端工具执行结果冲突时，如何回滚并明确展示事实状态 A 记录快照/撤销操作，冲突时精确回滚到服务端事实值并明确标注差异 ✓ 正确答案 B 乐观 UI 永远以用户输入为准，忽略服务端结果 C 冲突时直接整页刷新重置 D 乐观 UI 不需要回滚机制
# 8. 高风险工具确认卡应固定展示哪些参数、影响和权限，为什么不能由模型自由生成按钮行为 A 确认按钮的行为可由模型自由生成，以适应不同场景 B 确认卡展示参数、影响与权限，按钮行为由可信代码固定绑定 ✓ 正确答案 C 高风险工具无需确认，直接执行可提升效率 D 确认卡只展示工具名，不展示参数与权限
# 9. 长回答中的引用如何定位原文、展示失效状态，并防止钓鱼链接和 javascript: 协议 A 只允许 http/https 并校验域名，失效时展示失效状态，防止钓鱼与 javascript: 协议 ✓ 正确答案 B 引用 URL 允许任意协议，只要能打开 C 引用失效时直接跳转，无需检测 D 钓鱼链接无法通过协议校验，无需额外处理
# 10. 停止生成按钮的响应延迟应控制在多少毫秒以内，前端如何立即取消 Provider 请求 A 响应延迟 1 秒以内即可，无所谓 B 停止按钮无需更新消息状态 C 前端取消请求即可保证服务端立即停止计费，无需服务端配合 D 应控制在 100ms 以内，用 AbortController 立即取消请求并同步更新 UI 状态 ✓ 正确答案
# 11. 为何不直接展示 CoT/thinking tokens，怎样用步骤状态和证据摘要替代 A 应直接展示完整思维链，充分透明 B 展示高层步骤状态与证据摘要，兼顾透明度与安全/成本 ✓ 正确答案 C CoT 展示与否对安全无影响 D 不展示 CoT 就没有任何方式让用户理解过程
# 12. 聊天 UI 中“重新生成”应保持哪些配置（模型、参数、工具） A 重新生成应清空上下文，当作新对话 B 重新生成必须更换模型 C 保持上下文、模型、参数与工具，只重生成该条消息，并保留旧分支 ✓ 正确答案 D 重新生成不保留任何参数
# 13. 长回答（>5k 字）滚动与阅读体验应如何设计（TOC、章节折叠、进度条） A 长回答应单页平铺，无需任何导航 B 用 TOC 锚点跳转、章节折叠与进度条提升可寻址性，并配合稳定滚动锚点 ✓ 正确答案 C 进度条只装饰，无实际作用 D 长回答必须拆成多页刷新
# 14. 输入框应支持哪些快捷键（Cmd+Enter 发送、Shift+Enter 换行、Cmd+K 清空） A Enter 和 Shift+Enter 都发送消息，无差别 B 快捷键无需处理浏览器冲突 C 用 Cmd+Enter 发送、Shift+Enter 换行，统一约定并处理浏览器冲突与无障碍 ✓ 正确答案 D 快捷键应和浏览器默认完全一致，不做自定义
# 15. 消息反馈（点赞、点踩）应如何既便于用户反馈又不打扰正常对话流程 A 反馈按钮应常驻大尺寸，醒目提醒用户 B 反馈后必须弹出详细问卷 C 反馈按钮 hover 显现、交互轻量，点踩可选跟进且不强制打断 ✓ 正确答案 D 反馈数据与消息无关，无需关联
# 16. 对话历史应保留多久、按用户/项目隔离，前端 IndexedDB 缓存策略如何设计 A 历史应永久保留，无需隔离 B 缓存无需加密 C IndexedDB 是权威数据源，无需服务端 D 按用户/项目隔离，设容量上限与过期清理，IndexedDB 仅为本地缓存且权威在服务端 ✓ 正确答案
# 17. AI 回复中包含 Markdown 表格、列表、代码块时，复制到剪贴板应保留原始格式吗 A 一律复制纯文本，避免格式问题 B 保留 Markdown/富文本结构，代码块复制为代码，并可提供纯文本选项 ✓ 正确答案 C 表格无法复制，只能截图 D 复制格式无需考虑
# 18. 聊天 UI 中“加载历史消息”应如何避免请求风暴（分页、虚拟列表、IndexedDB 缓存） A 一次性加载全部历史即可 B 游标分页 + 虚拟列表 + IndexedDB 缓存，避免大量请求与 DOM ✓ 正确答案 C 虚拟列表与请求无关，只影响渲染 D 缓存会导致数据不一致，应禁用
# 19. 为什么聊天应用不应仅依赖客户端渲染，对 SEO 友好的初始 HTML 应如何服务端预渲染 A 对公开内容用服务端预渲染出可索引的初始 HTML，再客户端 hydration 接管交互 ✓ 正确答案 B 聊天应用纯客户端渲染即可，无需 SEO C SSR 会破坏所有交互，应避免 D SSR 与 SEO 无关
# 20. 多模态输入（图像、文件、语音）的 UI 应如何与文本输入统一到同一消息流 A 多模态输入应单独处理，与文本消息无关 B 附件不需要预览与上传状态 C 用结构化 content 数组把图像/文件/语音统一为消息附件，与文本同气泡渲染并管理上传状态 ✓ 正确答案 D 多模态只能放到新消息，不能与文本同消息
