乐于分享
好东西不私藏

Demo能跑不等于能上线:企业AI项目最容易死在这5个验收点

Demo能跑不等于能上线:企业AI项目最容易死在这5个验收点

最近复盘了一个企业AI项目:一个80人研发团队,做内部售后知识库助手。

Demo阶段很顺利。

销售、客服、技术支持都能输入问题,AI能从历史工单、产品手册、FAQ里生成答案。老板现场试了几个问题,效果不错,大家都觉得“这个可以上线”。

但真正进入试运行时,问题开始集中出现:

客服不敢直接用答案,因为不知道依据来自哪份文档;研发质疑答案里的版本信息不准确;测试不知道该怎么判定“回答合格”;安全部门要求限制客户数据访问;运维问了一句:如果模型接口超时,业务流程怎么走?

这时候团队才发现:Demo能跑,只证明“能力存在”;能上线,必须证明“风险可控、结果可验收、责任有人接”。

企业AI项目最容易死,不是死在模型不够强,而是死在下面5个验收点。

一、没有明确业务边界:AI到底替谁做哪一步?

很多AI项目一开始会被描述成:

“做一个智能助手。”“做一个企业知识库。”“做一个自动分析工具。”

这些说法都太大,无法验收。

在项目现场,真正需要验收的不是“AI聪不聪明”,而是它进入了哪个流程节点。

比如售后知识库助手,至少要拆成三个不同场景:

场景
AI负责什么
人负责什么
能否上线
客服首次答复
生成参考话术和依据
客服确认后发送
可以先试点
技术故障判断
汇总相似工单和可能原因
技术支持判断方案
需要灰度
客户承诺口径
直接生成补偿或承诺
业务负责人审批
不建议自动化

如果边界不清,AI就会被默认承担过多责任。

上线前必须问清楚:

AI是给建议,还是做决定?AI的输出是草稿,还是可以直接进入业务系统?哪些场景禁止AI自动处理?哪些结果必须人工确认?出了问题由谁判断、谁修改、谁背责?

很多Demo阶段看起来很惊艳,是因为它绕开了责任边界。真正上线时,责任边界会变成第一道验收门槛。

二、没有可复现评估集:现场试几个问题不算验收

企业AI项目最常见的误判是:领导试了几个问题,觉得“还挺准”。

这不是验收,只是演示。

AI项目必须有一套固定评估集,否则上线前没人说得清楚:

准确率到底是多少?哪些问题经常答错?错误会造成多大风险?下一次模型或提示词更新后,效果是变好了还是变差了?

一个能上线的评估集,至少要包含四类样本:

样本类型
目的
高频问题
验证日常业务效率
高风险问题
验证是否会误导用户
边界问题
验证AI是否知道不能答
历史事故问题
验证是否避开已知坑

更关键的是,每个样本要有标准答案、可接受答案、不可接受答案。

比如:

问题:客户问某型号设备是否支持远程升级。合格答案:指出支持条件、版本限制、操作前提,并引用对应手册。不合格答案:只回答“支持”,但没有版本和风险说明。严重不合格:给出错误升级路径,可能导致设备不可用。

没有这类标准,测试团队就只能凭感觉验收。凭感觉验收的AI系统,上线后很容易变成凭运气运行。

三、没有依据链路:答案对了,也要知道从哪来

很多企业AI Demo看起来效果不错,但一到验收就被卡住:

“这个答案依据是什么?”“它用的是最新版制度吗?”“为什么引用了已经废弃的文档?”“这句话是文档里的,还是模型自己编的?”

企业场景里,AI不是作文工具。它输出的内容必须能追溯。

尤其是知识库、合规、客服、售后、财务、人事、法务类项目,验收时不能只看答案是否顺眼,还要验:

是否引用来源文档;是否显示文档版本;是否标明更新时间;是否能区分事实、推断和建议;是否能拒答超出资料范围的问题。

一个比较实用的上线标准是:

AI可以生成答案,但必须同时输出“依据卡片”。

依据卡片至少包括:

资料名称;文档版本;命中段落;更新时间;置信等级;是否需要人工复核。

这件事看起来像产品细节,实际上是信任结构。

没有依据链路,业务人员不敢用;没有版本信息,研发和法务不敢签;没有拒答机制,系统迟早会在边界问题上翻车。

四、没有接入真实流程:工具能用,不代表业务能跑

很多AI项目的Demo是在一个干净页面里完成的:

上传文档,输入问题,生成答案。

但企业上线不是这样。

真实流程里会有账号权限、客户数据、业务状态、审批节点、异常处理、日志留痕、工单系统、CRM、IM、邮件、知识库、监控平台。

AI如果只是一个孤立页面,最后往往会变成“大家都觉得不错,但没人每天打开”。

上线验收要看它是否进入真实工作流:

客服是否能在工单页面直接调用?研发是否能在PR或缺陷单里看到AI摘要?测试是否能把AI生成的用例纳入测试管理系统?管理者是否能看到使用率、采纳率和风险项?异常结果是否能回流成知识库更新任务?

这里有一个判断标准:

如果用户为了使用AI,需要额外打开一个新系统、复制一堆上下文、再手动贴回业务系统,这个项目大概率只会停留在试点。

AI真正上线,不是多一个入口,而是少一段重复劳动。

五、没有回滚和监控:上线后没人知道它什么时候坏了

传统系统上线,大家会关心接口、日志、告警、回滚。

但AI项目上线时,很多团队只盯着“回答效果”,忽略了运行风险。

企业AI系统至少要监控这些指标:

风险项
要看什么
准确性
低置信回答、人工纠正率、用户差评
稳定性
超时率、失败率、降级次数
成本
单次调用成本、日调用总成本、异常暴涨
安全
敏感信息输入输出、越权访问、外发风险
业务影响
采纳率、节省时长、返工率、投诉率

更重要的是,必须提前定义回滚机制。

模型效果下降怎么办?知识库更新后答案变差怎么办?外部模型接口不可用怎么办?发现高风险错误后,是否能一键关闭某个场景?是否能回退到人工流程?

AI项目不是上线那一刻最危险,而是上线后悄悄变差时最危险。

因为它不像传统系统那样直接报错。很多时候,它会继续输出一段看起来很像真的答案。

这才是企业AI项目最需要警惕的地方。

一张AI项目上线前验收表

如果你是技术负责人、研发负责人、测试负责人或交付负责人,可以在上线前拿这张表过一遍。

验收点
必须回答的问题
没回答清楚的后果
业务边界
AI替谁做哪一步,哪些不能做?
责任不清,出错后互相甩锅
评估集
用什么样本证明效果可复现?
Demo好看,上线不稳定
依据链路
答案来自哪里,版本是否可信?
业务不敢用,合规不敢放
流程接入
是否嵌入真实系统和工作流?
工具闲置,试点无法推广
监控回滚
坏了怎么发现,怎么停,怎么退?
风险扩大,影响线上业务

我建议每个企业AI项目上线前,都不要只问一句:“效果怎么样?”

而是换成五个更具体的问题:

  1. 这个AI能力服务哪个明确流程节点?
  2. 它的输出由谁确认、谁采纳、谁负责?
  3. 我们用什么评估集证明它稳定可用?
  4. 它的依据、权限、日志和异常是否可追溯?
  5. 它上线后如何监控、降级和回滚?

能回答这五个问题,AI项目才开始从Demo进入工程化交付。

最后

Demo阶段看的是能力,上线阶段看的是责任。

企业AI项目真正要交付的,不是一个“会回答问题的模型”,而是一套可验收、可上线、有人负责、风险可控的业务系统。

这句话可以转给团队:

AI项目不要只验“能不能跑”,要验“错了谁知道、谁处理、怎么退”。