AI 最大的体验风险不是偶尔说“我不知道”，而是信息不足时仍然生成一个非常完整、非常确定的答案。失败状态要帮助用户判断结果是否可靠，并提供继续前进的方法，而不是只在底部放一句“AI 可能犯错”。
01 先承认 AI 错误是正常状态，而不是边缘异常
Microsoft HAX 将 18 条指南专门分出“When Wrong”一组，包括方便修正、不确定时缩小服务范围和解释行为。Google PAIR 也有 Errors + Graceful Failure 独立章节。
这说明 AI 产品不能只设计成功 Demo。错误、模糊目标、数据不足和模型能力边界都是主流程的一部分。
02 意图不清时先问，而不是替用户决定
用户说“把这个整理一下”，可能是总结、改格式、提取行动项。系统可以给两个三个最可能选项，或者问一个关键澄清问题。
HAX 的 Disambiguate before acting 模式正是针对这种情况。尤其 Agent 要执行动作时，猜错目标的成本更高。
03 没有证据时明确说“当前资料无法支持”
企业知识库里找不到某政策，不应该用常识补一段像公司制度的答案。可以说明未找到相关文档，并建议换关键词、上传资料或联系负责人。
这种“无答案”比幻觉更有价值，因为它保持系统边界。
04 置信度不是一定要显示一个 82% 数字
模型内部概率并不总能直接映射为用户可理解的事实可靠度。错误使用精确百分比会产生虚假科学感。
可以根据任务使用“已由 3 个内部来源支持”“存在冲突来源”“基于有限信息推断”等更可解释信号。
05 失败时给用户一个比“重试”更具体的恢复方法
文件太大可以建议拆分，权限不足可以申请访问，数据字段缺失可以指出需要哪一列。
重试只有在错误可能是暂时性的情况下才有意义。如果输入本身无法完成，让用户重复点击不会改变结果。
06 系统可以降级，而不是全有或全无
无法完成“自动生成并发送报告”时，可能仍能生成草稿；无法读取某个数据源时，可以继续处理其余来源并标注缺失。
Graceful Failure 的关键是保留仍然有价值的部分，并让用户知道哪些没有完成。
07 错误后的修正要影响后续行为
用户指出“这个客户名称错了”，下一轮 AI 还继续使用旧名称，会让纠错失去意义。
HAX 强调高效修正和传达用户操作如何影响未来行为。系统应该在合理范围内利用修正，并说明是只影响本次对话还是长期偏好。
08 免责声明不能替代错误设计
页面底部一句“AI 可能生成不准确信息，请自行核实”是必要提醒的一部分，但不能成为产品不做来源、澄清和恢复机制的理由。
真正的可信 AI 不是声称永远正确，而是在不确定、错误和数据不足时仍能诚实、可控地继续任务。
09 错误提示要区分模型能力、数据问题和系统故障
“我无法完成”可能是模型不支持视频、没有访问文件权限、外部 API 超时或安全策略阻止。不同原因需要不同下一步。
统一错误文案会让用户错误地重试、重新上传或怀疑自己的输入。
10 高风险结果可以要求用户主动确认关键事实
例如合同摘要完成后，界面突出金额、日期、责任方，要求用户在导出前快速核对，而不是默认整篇都可信。
这种设计不是把所有责任推给用户，而是把人工注意力集中在最关键事实。
11 产品应该记录失败类型而不是只统计“失败率”
检索无结果、用户取消、工具权限不足、模型拒绝、输出格式不合格，都需要不同修复。
一张总失败率曲线无法告诉团队该优化模型还是 OAuth。细分错误是产品迭代的基础。
常见问题
AI 是否应该显示置信度百分比？
只有指标经过校准且用户能正确理解时才适合；很多场景使用证据和不确定性描述更可靠。
AI 不知道答案时是不是体验很差？
明确“不知道”并提供下一步，通常比编一个确定答案更好。
什么时候应该向用户追问？
当缺失信息会显著改变结果或行动后果时，而不是所有输入都机械澄清。
“重试”按钮什么时候有用？
网络、服务暂时失败等可恢复错误有用；能力或数据不足则应提供具体修正方法。
免责声明能解决 AI 幻觉问题吗？
不能。还需要来源、范围说明、纠错、澄清和高风险控制。
相关服务与进一步咨询
链接复制成功
