用 AI 整理一份资料，第一次结果看起来流畅，仔细读却发现日期不对。这时用户需要的，通常不是一句更热情的道歉，而是知道错在哪里、能不能改、之前的工作会不会丢。兰亭妙微这次分享 Tushar Deshmukh 关于算法错误与信任的文章。我们借这个问题，把注意力放到日常工具的界面上：下面的资料摘要和文件整理均为假设场景，讨论的是交互设计的补救方法，不涉及医疗、金融等专业决策。
一段排版整齐的摘要很容易产生完成感。问题在于，文字越顺畅，用户越可能忘记它仍需要核对。设计上可以让依据更容易到达：重要日期旁边保留来源入口，摘要与原始资料能并排查看，存在缺漏的信息明确标出来。这样用户发现问题时，能沿着界面找到线索，不必重新从文件夹翻找。
AI概念示意：用于说明本节设计思路，非原文案例截图或实际客户项目。
以会议纪要为例，任务负责人和截止日期比一般描述更容易影响后续行动。可以把这些字段做成可编辑的信息块，点击后查看对应记录，而不是让它们埋在长段落里。没有依据的字段，不宜用醒目颜色装作已确认，也不要展示缺少解释的精确置信数字。概念图呈现的是一种核对布局；真正落地时，来源能否定位到对应片段、资料更新后引用是否同步，都需要产品和工程一起验证。
还可以把“找不到依据”和“依据互相冲突”区别呈现。前者需要补充资料，后者需要人参与判断，不能用同一句笼统提醒全部带过。用户知道缺的是什么，才容易决定是上传新文件、修改问题，还是暂时停止使用这项结果。
很多失败提示只提供“再试一次”。但用户可能已经改过标题、删掉无关段落，或者补充了自己的备注。如果重试把这些内容全部覆盖，错误带来的损失就不只是一次等待。恢复设计应先区分哪些是系统生成内容，哪些是用户编辑，再决定更新范围，而不是把整个页面清空重来。
AI概念示意：用于说明本节设计思路，非原文案例截图或实际客户项目。
一种可讨论的方案，是保留当前版本，将新结果作为另一版呈现，并让用户选择是否替换。若只想修改摘要中的一段，也可以只对选中部分重新生成。这里的按钮文案需要明确：“重新生成整篇”和“修改这一段”不是同一个动作。用户发起操作前应知道影响范围，返回后能看懂发生了什么变化。这样的设计不保证答案永远正确，却能减少用户为了纠正系统而反复劳动的情况。
反馈入口也不宜只剩一个赞和踩。对摘要工具而言，“信息遗漏”“引用不符”和“表达不清”指向不同问题，可以在不打扰主要任务的前提下提供简短选项，再允许补充说明。选择反馈后给出明确回执，避免用户不知道意见是否已经提交。
生成一份建议，与直接改变用户的资料，是两种不同的交互承诺。假设工具能批量给文件改名，系统可能理解错命名规则，或者把同一客户的文件分进不同目录。如果结果直接执行，用户需要逐个追查；如果先展示旧名称与新名称，很多问题在提交之前就能被发现。
AI概念示意：用于说明本节设计思路，非原文案例截图或实际客户项目。
预览界面不必复杂。按行列出变化，标出可能冲突的名称，允许取消某一项，再清楚写明即将处理的数量，就足以支持一次有针对性的检查。确认按钮附近应交代动作，而不是泛泛写“继续”。对于可撤销的操作，还可以保留修改记录和恢复入口。配图只是命名流程的概念，不代表文件操作天然安全；实现时仍要确认重名、权限和中途中断怎样处理，不能让预览与实际执行走两套规则。
如果错误发生在连续多步任务里，恢复范围尤其需要说清楚。重新处理当前文件，和重新处理整个文件夹，工作量及结果都不同。操作文案可以直接带上对象和数量，让人不必依靠记忆判断；确认以后，也应保留可查看的处理记录。
用户重新打开页面时，往往不记得上一轮到底成功了哪一步。只显示“任务失败”，既不能说明影响范围，也不能帮助继续。可以把过程拆成容易理解的阶段：资料已读取，摘要已生成，导出未完成。状态需要反映真实结果，让人知道已有成果还在，接下来只需处理哪一部分。
AI概念示意：用于说明本节设计思路，非原文案例截图或实际客户项目。
如果提供反馈或人工帮助入口，最好能携带当前任务的信息，减少用户再次描述的负担；同时让他知道哪些内容会被提交，避免把整份资料默认附上。页面语言也应克制：确认错误后说明问题，仍未查明时不要编造原因。我们可以用一段完整的失败任务检查界面：用户是否知道现在的情况，是否找得到补救方式，是否能继续完成原本的目标。这些具体问题，比把提示写得更像真人更值得先解决。
好的错误体验并不靠许诺“绝不出错”。它让人有依据可查，有修改入口，也有恢复的余地。AI 功能越多，越需要把这些看似普通的交互细节做扎实。
