为什么 AI 项目卡在 Demo 和生产之间

上线之前，先说明失败后业务怎么继续

演示通常沿着准备好的输入走完一条路径。真实服务还会遇到依赖超时、拥塞、重复点击、用户取消和资料更新。把这些情况写进业务验收，比先承诺某个上线周期更有价值。准备上线的范围应说明谁使用、允许什么动作、何时转人工，以及谁有权暂停服务。

说明用假设例子，非真实客户案例或容量承诺。 假设一个内部助手查询知识库后创建售后工单，试点从 5 位用户扩大到 50 位。逻辑任务 task-42 已在工单系统创建记录，但返回途中断开。用户看到超时后再次点击，随后又点取消。如果系统把每次点击都当成新任务，可能创建重复工单；即使取消按钮变灰，外部记录也不一定被撤回。

用一次失败，把依赖链拆出来

为这条流程画出身份服务、知识索引、模型、任务队列和工单系统。沿同一个任务编号记录排队等待、每段调用耗时、重试、版本和最终状态，日志尽量不保存原始客户内容。先查请求停在哪段，再决定修模型、连接、配额还是业务流程。

出问题的环节	应诊断什么	业务应如何继续
身份或权限服务不可用	身份是否仍可确认，权限是否过期	不能确认权限就停止受保护操作，不默认放行
索引更新失败	源文档与索引版本是否对应	暂停依赖新资料的回答，提供人工核对
模型限流或不可用	配额、并发、等待与重试是否叠加	有限排队/退避，超出任务期限后清楚转交
工单写入结果未知	是否已产生外部记录	先查状态，不直接再创建
突发请求积压	队列年龄、在途任务和最慢依赖	限流、拒绝或延后新任务，不无界排队

从 5 到 50 位用户不等于简单乘算模型容量：一个任务可能有多次调用，重试也会占资源。用代表性并发和慢依赖演练排队、取消、成本及失败行为，先确定允许的队列与任务时限，再决定放量。

重试、重复与取消是不同的问题

给同一逻辑意图分配稳定任务编号，重试沿用相同的幂等标识，并保存请求摘要和结果状态；不能仅按提示词文本去重，否则合法的相似请求也可能被压掉。若外部系统支持幂等，应核对其范围与有效期；不支持时，用状态查询、受控串行或人工核对降低重复风险，不能宣称实现无条件“恰好一次”。

超时只说明客户端没有及时拿到结果，不说明外部操作没发生。task-42 应先查询已创建记录，再决定返回原结果或补偿处理。有限重试和退避的原则可参考 AWS 关于超时与重试的说明。

取消应区分停止等待、停止后续步骤、请求上游取消，以及撤销已经完成的外部动作。保存 cancel_requested 后仍要处理迟到结果；无法确认完成或取消时记录 unknown，进入核对队列。已创建工单需要单独的关闭或补偿流程，不能因为界面显示取消就假装从未写入。

资料更新与回退都要有边界

版本记录应覆盖代码、模型、提示词、索引、权限策略和工具结构。资料负责人批准更新后，验证新版本已入库、旧缓存失效、引用可访问，再重新运行受影响样本。切回旧代码时不能顺带恢复已撤回的权限或失效政策；必要时先关闭受影响功能。

模型回退也要核对处理地区、费用、工具参数和回答行为。没有批准的替代路径，就明确提示稍后再试或转人工。撤回发布之前，应说明在途任务如何暂停、排空或核对，不能只切回页面或提示词；外部副作用由其责任人另行处理。

发布评审可以直接复用的门槛清单

• 业务负责人： 确认允许场景、人工兜底和失败提示，先开放只读，再按验收决定是否增加建议或写入。
• 数据与安全负责人： 确认版本、权限、日志和处理边界；撤权失效、越权读取或未经确认的写入应阻止放量。
• 技术负责人： 演练依赖故障、重复、取消、迟到回调与容量不足，提供任务状态和核对证据。
• 运维负责人： 事先写明暂停条件、可恢复版本、开关与回滚步骤，明确在途任务及外部记录的处理人。
• 共同验收： 约定质量、等待、费用和数据更新门槛；任何关键项没有负责人或可复核结果，就继续限制试点范围。

上线决定应来自这些证据和责任安排，不来自“已经跑通”或固定天数。逐步扩大使用，才有机会在故障影响仍可控制时修正流程。