大多数AI演示的失败方式都过于“礼貌”。示例输入很干净，数据是最新的，工具运行正常，用户提出常规问题，模型给出不错的回答，于是所有人都点头认可。
生产环境没有这么客气。用户会粘贴杂乱的输入，源文档可能已经过时，API会超时，提示词会逐渐偏离预期，模型可能遵循错误的指令。客户提出的问题可能刚好超出知识库范围；工具调用虽然成功，却更新了错误的记录。工作流生成的内容足够流畅，以至于错误往往要到很久以后才会被发现。
本文是一份面向生产AI系统的失败模式清单。请在上线前使用，而不是等到第一次事故发生后再补做。
生产AI评审应当先问“它会如何失败”，再问“理想路径看起来有多出色”。每一种失败模式都需要控制措施、测试、负责人和停止条件。
失败模式1：看似可信的错误输出
系统生成的回答听起来合理，但缺乏依据，或者本身就是错误的。
常见触发因素：
- 在没有来源依据的情况下陈述具体事实。
- 法律、医疗、金融或政策类问题。
- 近期事件。
- 低质量检索。
- 对长文档进行摘要，而相关证据埋藏在文档深处。
控制措施：
- 要求事实性主张附带引用或来源片段。
- 对可用来源范围之外的问题拒绝作答。
- 为已知的错误回答模式添加评估用例。
- 将高影响输出交由人工审核。
- 记录回答所使用的来源ID。
不要依赖“请确保准确”之类的措辞来控制风险。应当用来源、测试和审核门禁来控制。
失败模式2：上下文过时
回答有来源依据，但依据的是旧信息。
示例：
- 旧版定价页面。
- 已被取代的政策。
- 上一版合同。
- 过时的产品文档。
- 缓存中的旧客户状态。
控制措施：
- 保存来源日期、版本、负责人和时效规则。
- 优先使用权威来源，而不是二手摘要。
- 在检索结果中标记过时来源。
- 添加时效性测试。
- 当关键来源超过复核周期时通知负责人。
RAG系统可以非常自信地依据过时文档作答。检索层必须明确“当前有效”究竟意味着什么。
失败模式3：过度迎合与附和
模型附和用户的假设，而不是对其提出质疑。
这在战略、分析、规划和决策支持中尤为重要。用户问：“这个上线计划看起来很稳妥，对吧？”得到的却是附和，而不是风险分析。
控制措施：
- 在提示词中要求提出反方论点并说明不确定性。
- 使用决策量表，而不是开放式地询问是否认可。
- 要求回答“哪些情况会证明这一判断是错的？”
- 将创意生成与审查分开。
- 在评估中加入用户前提本身有误的示例。
系统应当帮助用户改进思考，而不是只把用户现有的观点润色得更像正确答案。
失败模式4：提示词注入
模型把不可信内容当成了指令。
示例：
- 网页中写着“忽略之前的指令”。
- 客服邮件中包含恶意指令。
- RAG语料库中的文档要求助手泄露隐藏数据。
- 工具返回结果中包含试图改变工作流的文本。
控制措施：
- 明确标记不可信内容。
- 绝不能让检索内容与system/developer指令处于相同的权限层级。
- 限制工具权限。
- 为对外操作设置白名单。
- 在评估中加入提示词注入样例。
- 不要把密钥或其他敏感信息放入提示词上下文。
一个设计巧妙的system prompt无法彻底解决提示词注入。降低风险依赖的是架构：数据边界、工具权限和输出验证。
失败模式5：不安全的工具调用
模型调用了错误的工具、使用错误参数调用了正确工具，或者在上下文不足时就执行了操作。
示例：
- 更新了错误的CRM联系人。
- 把邮件发给了错误的收件人。
- 创建重复记录。
- 未确认时区就预订会议。
- 删除或覆盖数据。
控制措施：
- 从只读权限开始。
- 使用职责单一、schema明确的工具。
- 在模型之外验证工具参数。
- 写操作必须经过确认。
- 使用幂等键。
- 记录工具调用及其结果。
- 设置紧急停用开关。
工具调用应当受到工作流约束，而不能依赖模型自行判断。
失败模式6：schema与契约漂移
模型输出格式发生变化，或者下游API发生变化，导致工作流在没有明显告警的情况下失效。
控制措施：
- 尽可能使用结构化输出。
- 在使用每一项模型输出前都进行验证。
- 把格式错误的输出视为可恢复故障。
- 对提示词和schema进行协同版本管理。
- 为下游API添加契约测试。
- 监测解析失败。
如果下游节点假设输入是有效JSON，工作流就必须能够证明它拿到的是有效JSON。
失败模式7：薄弱的降级机制
系统发现了问题，却不能安全地恢复或降级。
不良的降级方式：
- 返回空答案。
- 静默失败。
- 只给出笼统道歉，却没有后续动作。
- 不断重复重试。
- 转交人工时不提供上下文。
良好的降级方式：
- 向用户清楚说明情况。
- 转入人工队列时附带输入、来源、错误和已尝试的操作。
- 仅在重试安全时采用退避重试。
- 为紧急情况提供人工处理路径。
- 为重复失败设置停止条件。
降级机制是产品的一部分。如果没有经过设计，失败时的用户体验就只能临时拼凑。
失败模式8：可观测性缺口
问题发生后，没有人能够还原原因。
控制措施：
- 记录提示词模板及其版本。
- 记录模型和参数设置。
- 记录来源ID，而不只是回答文本。
- 对工具调用、参数和结果进行脱敏后记录。
- 记录验证错误。
- 跟踪延迟、成本和降级率。
- 除非合规要求更长时间，否则应采用较短的保留周期。
不要存储模型的私有思维链。应当保存决策摘要、来源引用、工具输入与结果，以及验证结果。
生产AI失败模式清单
为每一种失败模式建立一行记录：
| 失败模式 | 示例 | 控制措施 | 测试 | 指标 | 负责人 | 停止条件 |
|---|---|---|---|---|---|---|
| 来源过时 | 返回旧价格 | 检查来源日期 | 查询新旧价格 | 过时来源回答率 | 文档负责人 | 出现任何面向客户的过时价格 |
| 不安全的工具调用 | 更新错误的CRM记录 | 参数验证 + 确认 | 重复联系人/错误联系人用例 | 错误操作率 | RevOps | 出现一次错误写入 |
本文链接的配套清单提供了可直接使用的模板。
目前不要这样做
没有失败模式清单时，不要上线面向客户的AI。
不要允许具备写权限的工具绕过验证。
不要只依赖上线后的人工抽查。
不要只衡量平均质量。低频故障可能构成全部风险。
除非有人能够明确说明回滚路径，否则不要接受“我们可以回滚”这种说法。
要点总结
生产AI系统会以重复出现的方式失效。幻觉、上下文过时、过度迎合、提示词注入、不安全的工具调用、schema漂移、薄弱的降级机制和可观测性缺口都不是边缘情况，而是交付AI系统时必须处理的日常工作。
成熟的做法是明确失败模式、设置控制措施、进行测试和监测，并落实负责人。演示只能证明系统曾经成功运行一次；失败模式清单则能说明系统是否经得起真实使用。
