p304. 防御性 UX：为非确定性系统而设计

AI 产品有两个传统软件不存在的固有特征：非确定性（同一输入可能产生不同输出，且输出可能是错的）和高延迟（生成过程远慢于数据库查询）。防御性 UX 的目标是在不改变这些技术限制的前提下，通过产品设计弥补体验落差。

3.4.1 对抗高延迟

流式输出（Streaming）的心理学

流式输出的价值不在于减少客观等待时间（总生成时间不变），而在于利用心理学效应减少感知等待时间。

三个心理学机制：

首字节响应：用户在 1–2 秒内看到第一个字开始出现，心理上就从”等待”切换到”阅读”状态。即使完整回答需要 10 秒，用户体验到的也不是”等了 10 秒”
进展感：逐字出现的文字给用户”正在产出”的感觉，类似进度条。没有流式输出时用户面对的是”什么都不知道的等待”，焦虑感更强
提前决策：用户在生成过程中就可以开始阅读和判断，如果方向不对可以提前停止（Stop 按钮），节省时间和成本

TTFT 的 3 秒法则：TTFT（首字延迟，c05 §5.1）超过 3 秒，用户会开始怀疑系统是否挂了。这个数字来自 UX 研究——3 秒是人类感知”即时反馈”和”明显延迟”的分界线。超过 3 秒 TTFT 的产品必须配合骨架屏或状态文案来弥补。

TPOT 的流畅度感知：TPOT（每 token 生成时间，c05 §5.1）决定了文字出现的节奏。太慢（> 100ms/token）会导致”一字一顿”的阅读体验；理想速度约等于人类阅读速度（250 字/分钟 ≈ 60–80ms/token）。

骨架屏与过程状态外显

当延迟不可避免时（例如 Agent 执行多步骤任务），不要给用户一个旋转的 loading icon——那传达的信息量为零。

替代方案：

状态文案：显示 AI 当前正在做什么——

正在搜索相关文档... → 正在分析 3 篇文章... → 正在整合回答...

每一步的状态切换都给用户”在进展”的感觉。这是 System 2 思维过程外显（c11 §11.6）的产品化实现。

骨架屏（Skeleton Screen）：在回答区域预先渲染灰色的占位块，暗示即将出现的内容结构。Perplexity 在搜索时先展示来源卡片的骨架，再逐步填充内容，用户能提前看到”答案大概会是什么结构”。

预计时间：如果可以估算生成时间，显式告知用户（“预计需要 30 秒”）。不确定性比等待本身更令人焦虑——一个明确的等待时间比一个无限期的 loading 好得多。

Agent 的异步 UI 设计

System 2 模型（o1/R1）的长时间思考（c11 §11.4）需要从根本上重构 UI：

旧范式：实时对话（问题 → 等待 → 答案，全程阻塞）
新范式：异步任务提交 + Dashboard 监控（提交 → 可以做别的事 → 收到通知 → 查看结果）

设计细节：

“提交”后立即显示”任务已接受，预计 X 分钟后完成”
提供任务列表视图，让用户同时管理多个进行中的任务
完成时通过通知（站内信、邮件、push）告知用户
结果页提供执行日志——AI 做了什么、看了什么资料、为什么做这个判断

3.4.2 应对幻觉与不确定性

关于幻觉的技术根源，见 c13 和幻觉与校准。本节聚焦产品侧的应对设计。

预期管理（上线前就要做的事）

在用户第一次使用之前，就清晰地设定”AI 可能犯错”的预期：

产品入口处的简明声明：“AI 生成的内容可能存在错误，请核实关键信息”
不要过度包装——产品名称、文案、视觉设计不应暗示”全知全能”。“AI 助手”比”AI 专家”更安全
实际上，谦逊的预期设定往往提升长期留存：用户对”差但诚实”的系统容忍度高于”好但偶尔狂妄”的系统

溯源引用（Citations / Source Attribution）

让用户能验证 AI 的说法来自哪里——不是要求用户验证每句话，而是在用户产生怀疑时有据可查。这是 RAG 系统（c09 §9.5 可溯源设计）在产品层的直接体现。

实现层次（由低到高）：

层级	实现方式	代表产品
基础	在回答末尾列出信息来源	大多数 AI 产品
中等	回答中标注内联引用标记 [1][2]，点击跳转	ChatGPT with Browse
最佳	每条声明旁嵌入来源标签，鼠标悬浮预览原文片段	Perplexity

置信度外显

当模型对输出不确定时（logit 分布熵值高，c08 §8.1 解码参数和校准问题），在 UI 上给出视觉信号。

实现方式：

直接标注：“⚠️ 此回答基于有限信息，建议人工核实”
颜色编码：高置信度内容用正常颜色，低置信度内容用浅灰或虚线下划线
分段置信度：同一回答中不同段落可能有不同的置信度，分段标注

工程前提：需要后端将模型的 logprobs（token 概率分布）暴露给前端。这是一个需要 PM 和工程团队协商的接口需求——同样的功能，有没有 logprobs 支持，产品表达能力差距极大。

优雅降级（Graceful Degradation）

当 AI 无法给出满意回答时，不应该生硬地报错。

降级层次：

① AI 自信地回答                → 正常展示
② AI 有部分答案但不完整        → 展示已有信息 + 标注"以下部分信息不足"
③ AI 完全不确定               → 明确告知"我不确定" + 提供替代路径
   ("你可以尝试搜索…"或"要不要转接人工？")
④ AI 系统故障                 → 预设的离线回答 + 错误上报 + 预计恢复时间

关键原则：永远不要让用户陷入死胡同。即使 AI 无法回答，也应该给用户下一步的路径。

3.4.3 纠错交互设计

AI 会犯错是既定事实。问题不是”如何避免所有错误”，而是”用户发现错误后，纠正过程有多简单”。

分段确认（Partial Confirmation）

不要让用户面对一个 500 字的回答做全局的”接受/拒绝”二元选择。让用户能对回答的不同部分做独立的判断：

文档生成：分段展示，每段有独立的”接受""修改""重新生成”按钮
代码生成：diff 视图，逐行接受或拒绝修改（Cursor 的核心交互模式）
数据分析：每个分析结论可独立标记为”正确”或”需修正”

行内编辑（Inline Editing）

用户应该能直接在 AI 的输出上做修改，而非必须回到输入框重新描述需求。

文本输出：直接在回答文字上修改（像编辑文档一样）
代码输出：直接在代码块中修改
结构化输出（如表格）：点击单元格直接编辑

数据价值：用户的每一次行内编辑都是极高质量的监督信号——它精确地告诉系统”这个地方错了，应该改成什么”，是最高信息密度的训练数据（详见 p306 §3.6.1 编辑式反馈）。

局部重新生成（Partial Regeneration）

用户不满意回答的某一段时，能只重新生成那一段，而非重新生成整个回答。这节省了用户的等待时间和系统的计算成本（m209 成本控制）。

相关概念卡：幻觉与校准、RAG、Agent、System 2 TTC 模块一关联：c05 TTFT/TPOT、c08 logprobs、c11 异步 UI、c13 幻觉根因模块二关联：m209 成本控制、m207 Agent 失败兜底上一章：p303 空白画布综合症下一章：p305 信任架构

p304 - 防御性 UX：对抗延迟与幻觉