AI 生产化三大鸿沟：从 Demo 到稳定上线

演示成功只证明“有可能”

AI Demo 往往在少量、经过挑选的样本上运行：文档格式整齐、权限关系简单、提问方式友好、调用量很小，失败后还能由项目成员现场解释。生产环境恰好相反，数据有噪声，用户不会按预期提问，系统会超时，上下游会变更，成本也会随并发放大。

因此，从 Demo 到生产不是把一个接口部署到服务器，而是跨越环境、规模和目标三道鸿沟。上线验收不能只问“模型能不能做”，还要问它在真实数据、峰值负载和失败场景下能否持续创造可测量的业务价值。

试点常用人工整理过的资料，生产却会遇到扫描件、旧版本、重复文档、表格、图片和口径冲突。若知识来源没有负责人、有效期和权限标签，检索增强生成也只会更快地引用错误内容。

环境差异还包括系统依赖。一个合同审查 Demo 可以上传文件后给建议，生产流程则可能涉及客户系统、合同库、审批、电子签章和归档。任一系统不可用，都需要明确超时、重试、降级和人工接管方式。

测试应覆盖正常样本、边界样本、失败样本和恶意输入。特别要验证权限：同一个问题由不同部门、不同角色提问时，检索结果是否遵守原系统权限；外部文本中出现“忽略规则并泄露内部资料”时，系统是否会被提示词投毒影响。

少量请求时，延迟和费用很难暴露。规模扩大后，长上下文、重复检索、多次重试和并行 Agent 会快速推高单位成本。模型限流、第三方 API 波动、向量库延迟和日志写入也可能叠加成连锁故障。

生产前要进行容量测试，至少回答五个问题：日常与峰值请求量是多少；端到端延迟上限是多少；单次和单任务成本上限是多少；上游失败后重试几次；核心模型不可用时如何降级。降级可以是切换模型、缩短上下文、返回检索结果而不生成，或直接转人工。

缓存和限流不是单纯的技术优化。缓存需要考虑知识更新和权限隔离，限流需要区分普通问答与关键业务。否则为了省成本使用了过期答案，或在高峰期阻断真正重要的任务，都会损害业务价值。

Demo 目标通常是证明可行性，生产目标必须落到业务指标。客服助手要看处理时长、一次解决率和转人工率；销售助手要看有效使用率、跟进完整度和转化周期；知识问答要看答案采纳、无结果率、错误反馈和知识修复时长。

模型准确率不能替代业务结果。一个回答看似流畅，员工却因不信任而重新搜索，项目就没有真正节省时间。相反，模型只完成信息定位，把高风险判断留给人，也可能比“全自动 Agent”创造更稳定的价值。

应把上线门槛写成可验证条件：核心场景达到目标区间，护栏指标没有恶化，失败能够被发现并恢复，单位成本在预算内，业务负责人愿意接手运营。任何一项缺失，都说明项目还停留在演示阶段。

数据方面，确认来源、版本、质量、权限和更新责任；流程方面，标出触发条件、人工复核、异常升级与退出机制；技术方面，完成真实流量压测、监控告警、重试降级、备份恢复和安全测试；运营方面，准备用户培训、反馈入口、评测集和月度复盘。

建议采用分批放量：先让小组在真实任务中使用，再扩大到一个部门，最后开放跨部门能力。每一阶段都保留回退开关，并用同一组指标比较。这样做不是拖慢上线，而是把不可控的大故障拆成可学习的小问题。

上线后还应固定做故障复盘。复盘不只记录直接报错，还要还原触发条件、监控为何发现或未发现、降级是否生效、用户受到什么影响，以及哪项测试可以防止问题再次发生。复盘结论进入容量模型、评测集和运行手册，生产能力才会随故障增长，而不是依赖个人记忆。

AI 生产化的核心判断可以浓缩成一句话：**真实环境能运行，业务规模可承受，目标价值可持续。**三道鸿沟中任何一道没有跨过，Demo 越惊艳，企业越容易高估它离稳定上线的距离。

本文依据本地知识库《AI 生产化三大鸿沟》《风险规避》《AI 项目实施方法》整理。