干预、纠正与恢复

一个 AI 原生产品不应将失败视为令人尴尬的边缘情况。失败本身就是交互模型的一部分：目标模糊、信源过时、工具失灵、用户改变主意、权限过期、外部系统响应延迟，以及模型介导行为有时会走错路径。

恢复正是产品证明其先前承诺是否诚实的关键时刻。一个宣称“我会为您处理此事”的系统，在出问题时只会道歉并重新生成，这样的系统并未设计出真正的委托工作，它设计的只是充满希望的输出。

产品赢得信任，不是通过假装错误很少发生，而是通过让恢复过程清晰易懂、可控可操作。

核心论点

恢复的用户体验应以事实优先于安慰：展示已知信息、已变化内容、不确定性、仍可撤销或纠正的部分，以及下一步由谁负责。

本章不定义幂等性、补偿、持久执行或事件指挥体系。生产工程负责这些机制。产品与体验负责的是，当这些机制在产品中呈现时，人们能否理解并使用恢复路径。

在危机发生前提供干预能力

用户在以下情况应能进行干预：

目标或范围错误；
系统请求澄清；
提议的行动不可接受；
进展方向错误；
依赖项或策略阻碍工作；
用户更改优先级；
部分结果已足够；
应由其他人接管；
系统已做出有害或令人困惑的举动；或
用户不再希望委托工作继续。

不要将干预入口隐藏在最终失败之后。在实际结果尚未生效之前，纠正的成本更低。OpenAI 的智能体构建文章建议对重复失败和高风险行动进行人为干预（OpenAI, 2026）；产品应使这些干预常态化，而非特例化。

有用的干预时机包括：

时机	用户操作	产品要求
开始之前	编辑目标、范围、权限、预算。	更新委托约定。
规划期间	纠正假设或排除路径。	重新规划并展示无效的工作。
生效之前	拒绝、编辑或批准暂存的操作。	将决策绑定到确切的操作和状态。
执行期间	暂停或取消。	停止新工作并报告进行中的影响。
遇到阻塞时	提供证据、缩小范围或升级处理。	保留阻塞原因和下一步负责人。
获得部分结果后	接受子集或继续执行。	标记剩余义务。
失败后	重试、更改策略、补偿或移交。	仅提供有效的恢复选项。

将纠正视为状态变化

一次纠正应展示：

用户更改了什么；
它取代了什么；
为何重要；
哪些待处理的操作、审批、记忆或假设被无效化；
已完成的工作是否仍然有效；
是否需要重新检查证据；
审批是否需要重新进行；以及
系统下一步将做什么。

如果用户纠正了收款人、金额、截止日期、来源、管辖范围、客户身份或约束条件，产品不应仅仅将纠正内容追加到聊天记录中。它应更新任务状态并展示后果。微软建议在人机交互系统中支持高效纠正和驳回（Amershi et al., 2019）。在支持智能体执行任务的产品中，高效纠正依赖于结构化状态。

示例：

纠正：“使用企业退款政策，而非消费者政策。”

取代：
- 当前建议中的政策假设。
- 草拟的客户消息。
- 退款操作的待审批项。

仍然有效：
- 订单状态和客户身份。

下一步：
- 重新评估资格并准备新的预览。

这条消息比“明白了，我将使用企业政策”更有用，因为它告知用户哪些内容已更改、哪些未更改。

在恢复选项前展示影响状态

当出现问题时，用户需要一个状态模型：

影响状态	产品含义
未开始	操作从未被尝试。
暂存	操作已准备好但未提交。
已提交	操作已生效且存在证据。
已拒绝	操作已被尝试但被拒绝。
部分	部分影响已发生，部分未发生。
未知	系统尚无法判断影响是否已提交。
正在补偿	纠正性的领域操作待处理或正在进行中。
已升级	人员或其他流程已负责解决。

切勿将这些状态一概压成“错误”。在请求发出前取消操作的用户，和消息可能已经发送出去的用户，需要不同的说明和安抚。收到部分结果的用户需要知道剩余义务，而不是一条轻快的成功提示。面临未知支付结果的用户需要核对并纠正，而不是再次发起同一个请求。

产品语言应冷静且精确：

退款请求已发送，但支付提供商未返回最终状态。
请勿立即重试。我正在使用相同请求 ID 检查操作状态。

或：

邮件未发送。它仍作为草稿暂存，您可以编辑或放弃。

或：

五条记录中的两条已更新。其余三条未通过策略检查，未被更改。

提供符合现实的恢复选项

常见的恢复操作包括：

编辑并继续；
重试相同操作；
更改输入后重试；
更改策略；
接受部分结果；
撤销可逆操作；
补偿不可逆的影响；
核对并纠正未知影响；
升级给人员处理；
开启支持工单；
导出证据；
停止并保留当前状态；以及
使用选定的产物开始新任务。

仅显示系统能够兑现的选项。当领域只支持补偿时，不应出现“撤销”。当上一次写入的结果未知且再次尝试可能导致重复时，不应出现“重试”。“重新开始”应说明现有的记忆、草稿、审批、审计记录和外部影响是否保留。

Google 的 People + AI Guidebook 建议为错误和平稳降级进行设计，而不是将 AI 输出呈现为绝对正确（Google PAIR）。平稳降级不是模糊的道歉，而是可用的下一步行动。

区分重试、重新生成、重新规划、撤销和补偿

这些选项在 AI 界面中常被混为一谈，但含义不同：

选项	含义	使用时机	不应使用时
重新生成	请求另一个模型样本。	低风险的草稿或创意备选。	失败原因在于权限不足、状态过时或外部影响不确定。
重试	在重试策略下再次尝试相同操作。	失败是暂时的，且重复影响可控。	结果未知或请求无效。
重新规划	选择不同的路线或约束条件。	证据表明当前策略无法奏效。	相同规划仅需一次临时重试。
撤销	逆转可逆操作。	领域真正支持恢复原状。	影响不可逆或仅部分可逆。
补偿	执行新的纠正性领域操作。	精确撤销不可能，但可提供修复。	产品语言暗示原操作从未发生。
升级处理	将责任移交给有能力的负责人或流程。	权限、专业知识、争议或影响超出系统范围。	无人接手。

界面应通过标签和后果让用户理解这些差异。“再试一次”是不够的。“重试状态检查”和“发送另一笔退款请求”的风险截然不同。

保留部分结果，但不伪装成完成

由智能体执行的工作在失败前往往已经产生了一些有用内容：

一份研究简报，包含两个已核实来源和三个未解决的声明；
一个可编译但留下失败测试的补丁；
一份准备好的支持回复，但未提交退款；
一份无法预订会议的计划提案；
一个已清洗的数据集，并列出排除的行；或
一个未获授权修复的操作诊断。

部分结果的体验应说明：

哪个子集是可用的；
哪些成功条件仍未满足；
哪些证据支持已完成的部分；
哪些影响已提交、暂存、拒绝或未知；
用户下一步可以做什么；
继续是否需要新的权限、数据、时间或成本；以及
部分结果将如何存储或移交。

不要因为最终消息听起来完整，就将部分结果转换为成功。部分价值之所以有用，恰恰是因为它诚实。

使用负责任的语言

良好的恢复语言：

说明发生了什么；
区分已核实的事实与不确定性；
避免因模型歧义而责备用户；
指明下一个安全操作；
保留证据链接；
在需要等待时给出时间或责任人；
解释限制而不夸大声称；以及
使用与产品状态相同的术语。

应避免：

“我无法完成那件事”，而实际上系统已更改了某些状态；
“别担心，我修好了”，而补偿仍在进行中；
“再试一次”，而相同条件仍会导致失败；
“已取消”，而仅收到停止请求；
“撤销”，而产品正在执行一个新的纠正操作；以及
“完成”，而仍需人工确认或回读证据。

道歉在适当时候是合适的，但不应取代操作真相。用户需要知道工作是否已保存、已发送、已丢失、已排队、部分完成、结果未知或已升级处理。

设计接管与移交

当用户或操作员接管时，应提供一揽子信息：

原始目标和当前范围；
当前状态和待处理工作；
重要证据和来源；
已采取的举措；
审批及其限制；
未知或部分影响；
纠正内容和已被取代的假设；
生成的文件、产物、草稿或记录；
剩余的截止日期和预算；
建议的下一个选项；以及
当前任务的负责人。

一个只把用户带回聊天记录的“接管”按钮是不够的。工作空间应让用户无需从对话中重构事实，就能继续工作。在责任重大的地方，接收方应明确接受责任；仅发送通知并不构成移交。

NIST AI 风险管理框架 Playbook 将响应、问责和人工监督视为生命周期问题，而不是界面标签（NIST AI RMF Playbook）。因此，产品移交不应只指明消息接收者，还应指明负责角色、所需决策、传递的证据，以及无人响应时的安全默认行为。

让恢复具有可访问性

WCAG 2.2 的错误相关成功准则要求识别错误、在可能时提供建议，并防止用户提交中的严重错误（W3C, 2023）。AI 原生产品应将同样的精神应用于生成的建议和外部影响。

恢复控件应：

可通过键盘访问；
为辅助技术清晰命名；
附加到受影响的行动或产物；
不依赖颜色或动画即可理解；
在存在超时的情况下提供足够长的审查时间；
明确说明破坏性或不可逆的选择；
在刷新、会话变更和设备切换后仍保持可靠；以及
与工作空间的当前状态保持一致。

不可访问的恢复路径是一个正确性问题。它使得某些用户无法在纠正最关键的时机纠正委托工作。

在必要时升级到自助服务之外

某些失败不应在聊天或工作空间内解决：

可能的数据泄露；
未经授权或存在争议的外部影响；
财务、法律、医疗、就业、福利或安全影响；
重复的自动化故障；
用户投诉或申诉；
无法自动核对并纠正的未知影响；
需要负责人批准的策略例外；
滥用、提示词注入或账户被攻破的迹象；以及
阻止用户控制系统的可访问性障碍。

产品应将这些问题转交给支持、事件响应、治理审查或其他负责流程。自助服务体验不能替代组织责任。

失效模式

仅提供重新生成作为恢复手段

产品将每次失败都视为请求另一个模型样本。真正的问题可能是权限不足、状态错误、信源不佳、策略拒绝或影响已提交。

道歉而不展示状态

系统说抱歉，但没有说明发生了什么、什么待处理或用户能做什么。

虚假的撤销

界面显示“撤销”，但原始影响无法逆转。实际需要的是单独的补偿或支持工单。

纠正丢失

用户纠正了任务，但子运行或待处理操作仍在旧指令下继续。

聊天记录式移交

操作员收到的是数页聊天记录，而不是简洁的状态、证据和行动包。

部分结果伪装成完成

系统完成了一个简单的子集，却隐藏了未完成的义务。

未知结果被扁平化为失败

一次写入在投递后超时，产品显示“失败”，用户重试的方式可能导致重复影响。

本手册的判断

在工作进行中提供干预控件，而不仅仅在失败后。
将纠正视为结构化的状态变更，并展示可见的后果。
在推荐恢复之前展示影响状态。
仅提供系统真正能够兑现的恢复操作。
区分重新生成、重试、重新规划、撤销、补偿和升级处理。
保留部分结果，并说明其限制和剩余义务。
为接管方和移交的接收方提供证据包，而不是成堆聊天记录。
使恢复语言客观、具体、可访问且可操作。

检查清单

参考文献及其使用方式

Google People + AI Research, People + AI Guidebook - Google People + AI Research 发布的设计网页资源，用于支持错误设计、平稳降级、反馈和控制；它不是正式恢复标准。
Microsoft Research, “Guidelines for Human-AI Interaction” - 经同行评审的人机交互论文，支持纠正、驳回、平稳降级、解释和全局控制。
NIST AI Risk Management Framework Playbook - NIST 自愿性风险管理网页资源，用于生命周期响应、监督、问责和升级处理框架；它不是产品恢复认证。
OpenAI, “A practical guide to building AI agents” - OpenAI 面向产品与工程的智能体构建文章，支持针对高风险操作和重复失败进行人为干预。
W3C, Web Content Accessibility Guidelines 2.2 - W3C 推荐标准，用于可访问的错误识别、建议、预防和可操作控件。