在客户面前避免可避免的失败
AI 系统在处理大量语言和判断任务时，会出现一些错误输出。问题不在于是否会发生错误，而在于第一次错误出现时，是否有人立即思考如何应对。
大多数团队是在发生事件后才发现自己的应急流程。某人截图了一个错误答案，然后传给经理，经理问谁负责这个问题，但答案需要两天才能出来。到那时，客户已经向其他人讲述了这一情况。由于没有人有权关闭系统，所以系统一直保持开启状态。
这是完全可以避免的失败，而且是管理层而不是技术层面的失误。
在部署前明确“错误”的等级
并非所有错误答案都需要相同的处理方式。在发布前对错误进行分级，用普通语言说明，并标明每个级别负责的人员。
例如：
- 语气问题— 系统过于简洁或不够友好，这是下周发布后的培训问题。
- 事实错误— 关于政策、价格或交付日期的错误，需要即时修复，并联系客户。
- 涉及金钱、安全、法律承诺或个人数据的错误— 这是停止系统的事件：功能需要关闭，直到你了解发生了什么。
为这三类错误设置所有者、响应时间和明确的系统禁用权限。能够拉插电源的人不应该需要先找高层。如果你的唯一“杀断开关”是在部署时，那你就没有杀断开关。
向客户提供人，而非循环
AI 服务中最有害的模式是闭环：客户与系统发生分歧，系统自我解释，但客户无法找到退出方式。人们可以原谅一个错误答案，但他们不会原谅被困住的感觉。
每一次与 AI 交互都需要一条路线，以便客户在第一请求时就能联系到人类，而不是第三个请求后。将这条路线显示在界面中，而不是隐藏在帮助页面中。确保联系的人能看到客户刚才的完整对话，这样客户就不需要重述。并跟踪升级率作为关键指标— 一个从不升级的系统通常没有人能找到退出方式。
设置一个触发人类主动介入的阈值。如果客户重复自己两次，或对话持续过长时间，或话题涉及退款或投诉，直接移交处理而不等待请求。
道歉是一个商业决策
当你联系客户讨论错误答案时，三个方面至关重要：速度、具体性以及你打算如何避免再次出现类似问题。在没有压力下提前起草模板。
- 说明系统出错的地方以及正确的立场。
- 说明你将采取哪些措施来避免再次出现问题。
- 不要指责模型，也不要解释架构，更不要使用“AI 幻觉”这样的词语与客户交谈— 这听起来像一家公司为自己无法控制的事情找借口。
然后提前制定补救政策。如果系统报出的价格错误，你是否会按照该价格执行？如果它承诺的交付日期无法满足，你将提供什么？在房间里一次性讨论这些问题，而不是每种情况下都根据压力做出决定。保持一致的政策成本通常低于临时应变。
记录你希望后来能拥有的信息
审计线索是将争论转变为调查的机会。从第一天开始就记录这些信息，因为你无法稍后重建它们：
- 输入和输出的确切内容、时间戳和客户可以引用的对话 ID
- 产生错误的模型和版本，以及当时使用的提示或配置
- 系统检索的文档或记录，以便区分坏来源和坏答案
- 每一次人类干预：谁升级了、谁覆盖了、他们改变了什么
- 结果— 解决了、退款了、投诉了、流失了客户
同时制定保留和访问规则。决定保存对话多长时间，谁可以阅读它们，以及当客户行使数据权利时如何提供清晰的答案。提前进行法律审查比在投诉后进行审查便宜。
一次演练
在上线前进行三十分钟的演练。选择一个可信的错误答案，演示检测、升级、客户联系和修复过程。你会立即发现漏洞：周末没有负责人，无法关闭特定功能而需要关闭所有功能，缺少记录哪个提示版本正在使用等。
以上所有内容都是平凡的，但它们决定了第一次错误答案是否能得到妥善处理。我们在发布前而不是发布后几周才建立这些路径— 提前规划更容易承载重量。