跳到主要内容

AI 项目从 Demo 到上线，中间到底差了什么

· 阅读需 7 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-24 21:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

我发现 AI 项目最容易产生错觉的阶段，就是 Demo 成功之后。团队通常会在那一刻异常兴奋：模型能答、流程能跑、页面也有了，于是大家很自然地认为“离上线不远了”。可真正做过几轮交付之后就会知道，从 Demo 到上线，中间隔着的不是几个小优化，而是一整层工程现实。

Demo 的目标是证明“这件事有可能”；上线的目标是证明“这件事在真实流量、真实错误、真实业务约束下还能稳定工作”。前者看效果，后者看系统。

所以我现在评估一个 AI 项目，往往不会问“Demo 是否惊艳”，而是问：这个功能在失败时会发生什么，在高峰时会发生什么，在知识变旧时会发生什么，在模型波动时会发生什么，在业务追责时又该怎么解释。

Demo 阶段通常解决了什么​

大多数 Demo 至少能帮团队回答三件事：

1. 模型能力够不够​

例如能不能完成总结、抽取、分类、问答、改写、生成草稿等核心任务。

2. 交互是否成立​

用户输入这种问题，系统给出这种结果，业务方是否愿意接受这种产品形态。

3. 投入是否值得继续​

做一轮样例之后，大致能看出这个方向是不是完全没戏。

这三件事都很重要，但它们依然是“可行性验证”，不是“生产能力验证”。

真正缺的通常不是效果，而是这 7 个层面​

1. 输入和上下文没有被标准化​

Demo 里常常用的是精心挑过的样本，用户问题相对干净，上下文也比较完整。但上线之后会出现：

  • 用户输入不完整
  • 夹杂口语、省略和错别字
  • 多轮上下文断裂
  • 同一问题在不同入口表达完全不同

如果没有输入清洗、意图识别、上下文补全和兜底逻辑，模型即使本身能力够，也会被脏输入拖垮。

2. 输出没有契约​

很多 Demo 只要求“看起来答对了”，上线后才发现结果要进入数据库、表单、搜索索引、审批流、工单系统。这时最先出问题的就是输出格式。

所以从 Demo 到上线，一定要补上结果契约：

  • 返回哪些字段
  • 字段类型是什么
  • 缺字段怎么办
  • 枚举值怎么约束
  • 校验失败后怎么回退

只要输出没有契约，AI 功能就只能停留在展示层，进不了业务层。

3. 观测缺失​

很多团队上线前最容易忽略的是日志。结果功能一旦出现波动，大家只能靠截图和口头描述排查。

我现在会把这些信息当成最低配：

  • 请求 ID
  • 用户输入摘要
  • 命中的 Prompt/模型版本
  • 检索到的上下文片段
  • 工具调用过程
  • 结构化校验结果
  • 最终返回内容
  • 耗时与错误类型

没有这些信息，AI 项目会非常难维护。

4. 评估没有闭环​

Demo 阶段大家通常凭感觉说“这次效果不错”。但上线需要的是可持续评估，而不是一次性的主观印象。

至少要建立三种机制：

  • 样本集：固定一批代表性问题
  • 指标：正确率、拒答率、格式通过率、耗时、成本
  • 回收：线上失败样本定期归档

只有这样，你才能知道一次改 Prompt、换模型、改检索策略，到底是进步了还是退步了。

5. 回退路径没有设计​

AI 功能不是传统接口，波动性更大，所以更需要明确回退路径。

例如：

  • 模型超时时返回什么
  • 检索为空时返回什么
  • 输出校验失败时返回什么
  • 高风险动作是否必须转人工

真正能上线的 AI 项目，不是“永远正确”，而是“出错时也不至于把用户和系统一起带沟里”。

6. 版本管理不完整​

Prompt 改一版、模型换一个、知识库重建一次，效果都可能变。Demo 阶段这种变化没关系；上线之后，如果没有版本记录，后续根本无法回放问题。

我会要求至少能追踪：

  • Prompt 版本
  • 模型版本
  • 检索索引版本
  • 样本集版本
  • 上线时间点

这样才能知道“是哪一次变更把结果弄坏了”。

7. 组织协作没跟上​

很多 AI 项目最后不是死在技术上，而是死在协作上。

比如：

  • 业务方以为 AI 能完全替代人工
  • 研发以为模型波动可以接受
  • 运营以为内容质量问题归研发管
  • 风控和法务太晚才介入

一个真正上线的 AI 项目，必须提前把责任边界说清楚：谁定义目标、谁审核结果、谁负责异常、谁决定回滚。

我会怎么拆 Demo 到上线的路径​

如果让我从头带一个 AI 功能，我一般会拆成四步：

第一步：功能可行​

目标是确认模型能不能完成核心任务。这个阶段允许手工补数据、手工看结果，重点是判断方向值不值得继续。

第二步：接口可接​

把输入、输出、工具调用、错误返回这些基础契约定下来。做到这一层，功能才能接进系统。

第三步：链路可观测​

补日志、埋点、样本回收、版本记录。做到这一层，功能才具备维护条件。

第四步：业务可托管​

补人审、回退、灰度、权限、运营流程。做到这一层，才算真的能上线。

很多项目最大的问题，是第一步做完就想直接跳到第四步。

一个最小上线清单​

下面这张清单，是我最近更常用的“上线前自查”：

  • 输入是否有异常兜底
  • 输出是否有结构化校验
  • 是否能追踪 Prompt/模型版本
  • 是否记录失败样本
  • 是否有超时和降级策略
  • 是否有人工审核或人工接管路径
  • 是否有灰度发布能力
  • 是否清楚单次调用成本
  • 是否定义了成功指标
  • 是否准备好了回滚方案

只要这个清单有一半空着，我一般不会建议直接放生产。

一个更接近生产的示意​

async function handleAiTask(input, user) {
  const traceId = createTraceId()
  const normalized = normalizeInput(input)

  try {
    const context = await loadContext(normalized)
    const result = await callModel({
      promptVersion: 'v3',
      model: 'main-model',
      input: normalized,
      context,
    })

    const checked = validateResult(result)
    if (!checked.ok) {
      return fallbackToHuman(traceId, checked.reason)
    }

    await saveLog({ traceId, normalized, checked })
    return checked.data
  } catch (error) {
    await saveErrorLog({ traceId, error: String(error) })
    return fallbackReply()
  }
}

这段代码没有炫技，但它比很多 Demo 更接近生产，因为它考虑了：

  • 输入标准化
  • 版本可追踪
  • 输出校验
  • 异常记录
  • 人工兜底

我最常见到的三个误区​

1. 只看效果，不看波动​

一轮演示表现很好，不代表线上 1000 次请求都稳。

2. 只看模型，不看系统​

很多问题最后都不是模型层的问题，而是检索、规则、权限、超时、缓存或日志的问题。

3. 只想着自动化，不想着接管​

AI 功能越靠近业务主流程，越应该先设计“接管路径”，而不是只设计“自动化路径”。

总结​

AI 项目从 Demo 到上线，中间差的从来不是“再改一版 Prompt”这么简单。真正的差距，在于你有没有把它从一个展示能力，变成一个有契约、有评估、有回退、有责任边界的系统能力。

Demo 证明模型能做事；上线证明团队能把这件事托住。后者，往往比前者难得多。