从演示到上线：给 AI 应用补齐失败路径

AI 应用上线，不只是把一次成功演示搬到服务器。真实使用会遇到超时、限流、缺资料、权限变化和结果不确定。

交付标准应该覆盖正常路径，也覆盖这些失败之后用户看到什么、系统保存什么、下一次怎样恢复。

把完成定义到业务结果

文本已经返回，不代表结果可以被使用。需要检查字段、证据、业务约束与必要授权。有写操作时，还要确认外部结果，而不是只确认模型说它完成了。

部署入口也应明确：应用页面、模型服务、任务执行器和数据存储各自在哪里。静态网站可以用于产品介绍与学习内容，但不能在浏览器代码里保存模型服务密钥。

前端与后端的责任拆清楚，才知道哪些故障可以由用户重试，哪些需要服务端恢复。

先列出失败矩阵

失败	用户反馈	系统处理
请求超时	说明未完成，提供安全恢复入口	保存明确状态，限制重试
被限流	说明暂时不可用	尊重等待时间与剩余预算
缺少证据	说明资料不足	不编造，允许补充信息
无权限	说明无法访问	停止操作，不换工具绕过
写操作结果不确定	说明正在核实	查询结果或等待确认，不盲目重复

这些行为可以在没有真实模型请求时，用构造结果测试。把所有失败都变成“稍后再试”，会隐藏不同的恢复条件。

用代码限制重试

下面只演示重试判断，不发网络请求。即使错误可能是暂时的，也要先确认操作可幂等重试、次数与时间预算尚未耗尽。

def can_retry(status, attempts, idempotent, remaining_seconds):
    transient = {408, 429, 500, 502, 503, 504}
    return (
        status in transient
        and idempotent
        and attempts < 3
        and remaining_seconds > 0
    )

assert can_retry(503, 1, True, 10)
assert not can_retry(503, 1, False, 10)
assert not can_retry(401, 1, True, 10)
assert not can_retry(429, 3, True, 10)
assert not can_retry(503, 1, True, 0)
print("Retry boundaries checked")

真实执行还要设置单次超时、退避与总截止时间。对限流尊重接口的等待建议；对副作用操作确认服务端幂等语义，而不只是把布尔值设为真。

做一次有证据的上线验收

检查公开页面与实际路由、HTTPS、不存在页面的状态码和静态资源缓存。用于搜索引擎的文章应能直接返回正文，而不是只有一个需要 JavaScript 才能填充的空壳。

应用侧检查权限、取消、重复请求和进程中断。记录版本与必要指标，让失败可以定位；默认不记录用户正文。

用已有评测集验证模型质量，用构造故障验证恢复行为。两类检查都通过，才说明应用不仅会回答，也知道无法完成时怎样处理。

下一步

为你的应用填一份失败矩阵，逐项触发并观察。把用户反馈、任务状态和恢复动作写成同一条验收条件。

保留发布前的可回退版本。上线后根据真实失败继续修正评测集、权限边界与恢复流程，而不是仅以“服务器启动成功”结束交付。