AI 功能上线的失败模式

演示掩盖了运维表面

精致的演示证明模型能在精心挑选的条件下产出有用结果。上线则证明同一套系统在流量混乱、延迟预算紧张、组织必须从错误答案中恢复且不拖垮支持时，仍然有用。

把生产第一周当作系统测试。你要验证检索新鲜度、工具可靠性、降级路径、成本上限，以及捕捉自动化遗漏的人工流程。若这些未定义，功能并未就绪——就绪的只是演示。

没有负责人，质量就会漂移

模型供应商会改默认值。提示词会堆例外。检索索引会腐烂。这些都不会用红色部署来宣告自己。没有明确质量负责人就上线 AI 的团队，往往几周后才从客户投诉中发现回归。

像对待可用性 SLO 一样分配所有权。定义重要属性，采样生产流量，并在属性变动时要求具名审阅者。漂移不可避免；无人负责的漂移是产品失败。

• 将提示词、检索配置与评估套件一并版本化
• 告警拒绝率、升级率与纠正率——而不只是错误
• 保留可关闭 AI 而不关闭产品的回滚路径
• 在宣布成功前为上线后分流预留时间

降级路径是功能的一部分

当模型不可用、过慢或置信度低时，用户仍需完成任务的路径。空白态或礼貌道歉不是降级。降级是确定性流程、缓存答案、搜索结果或人工交接，以保留进度。

在上线前设计降级，并在预发环境演练。衡量触发频率。若测试中罕见而生产中常见，则置信阈值或依赖假设有误。

发布标准必须包含成本与风险

通过少量黄金提示词既必要又不足。以关键属性回归、每次成功结果的成本、p95 延迟，以及支持与信任团队的就绪程度作为发布门禁。高风险操作需要比低风险起草辅助更严格的门槛。

健康的 AI 上线显得无聊：渐进暴露、清晰的熔断开关、可观测的质量，以及能在出错时解释变更的团队。那种无聊，正是工程掌控了风险，而非寄望于模型的信号。