AI 项目从试点到正式上线,中间隔着什么?

演示那天的会议很顺利:准确率不错,老板点了头,大家开始讨论什么时候上线。三个月过去,项目还停在试点环境里——没有人反对它,也没有人推进它。

这种停滞在企业 AI 项目里很常见,而且多数时候不是执行力的问题。试点和生产之间,本来就隔着一段需要专门规划的路;没人规划,项目就停在原地。这篇文章把这段路拆开来讲。

试点的成功,是在被照顾的条件下取得的

先承认一个事实:POC 的环境是被精心照顾过的。数据是挑过的——格式干净、字段齐全的理想样本;跑的是演示路径——绕开了那些一看就麻烦的输入;而且全程有人盯着,出了问题随手就修,修完也不留记录。

生产环境会把这三层保护一次性全部拿走:真实数据里有歪斜的扫描件、缺一半字段的表单、口语化到离谱的描述;异常不再绕路,全量涌进来;凌晨两点系统出错时,旁边没有任何人。所以「试点准确率很高」推不出「上线没问题」——试点证明的是可行性,上线考验的是可靠性,这是两张不同的考卷。

上线之前,至少补齐五件事

从试点走到上线,核心工作就是把「有人照顾」换成「系统自己扛得住」。具体是五件事。

异常兜底与降级方案:AI 处理不了、或者置信度不够的输入,走哪条路?转人工、进待办队列,还是原样退回?降级路径要真的演练过,而不是文档里的一行字。

权限与数据边界:试点图省事,开的往往是宽权限;上线前必须收窄——系统能读哪些数据、能写哪些系统、对外发出的内容要不要人工确认。边界怎么划,可以参考用 AI 处理公司资料前,管理者要定的四条数据边界。

监控与告警:至少三个数要有人随时看得到——处理量、失败率、人工接管率。指标异常要能主动告警;靠用户投诉来发现故障,是生产环境里最贵的发现方式。

运营责任人与 SOP:出错谁处理、资料谁更新、多久复盘一次,写成 SOP,并且落到具体的人名上。「大家一起负责」在生产环境里等于没人负责。

回退方案:如果上线两周发现不行,怎么退回原来的做法?旧流程保留多久、数据怎么衔接?没有回退方案的上线,本质上是一场没有止损线的赌局。

扩量的节奏:一个部门,观察,再一个部门

五件事补齐,也不建议一步切到全量。更稳妥的节奏是灰度:先让一个部门或一类单据走新流程,设一段观察期,期间用事先写好的验收条件说话——怎么把「效果不错」写成可检验的条件,试点验收怎么写里有具体方法。达标,再扩下一个部门。

每次扩量几乎都会暴露新的异常形态:不同部门的填单习惯不同、数据来源不同、例外规则也不同。这不是项目做坏了,是扩量的常态——把处理新异常的时间预留进排期,而不是当成计划外的事故。

多数试点的死因,不在技术

试点死掉,多数不是因为模型不行,而是因为没人认领它上线之后的运营成本。

从澄序元接触到的企业场景来看,常见的剧本是这样的:试点期靠项目组的热情,什么问题都有人兜;要上线了,大家才意识到这个系统需要有人长期喂资料、看告警、处理边角案例——这份工作量立项时没人算过,也不在任何人的绩效里,于是每个部门都觉得它是别人的事。项目没有失败,它只是慢慢没人管了。

修法在立项那一刻:把长期运营写进项目预算——谁负责、每周预计花多少时间、算进谁的考核;答不出来,就先别急着立项。这类问题在决定要不要做一个 AI 项目前,管理者该问的六个问题里有一份完整的清单。

把上线当成中点,而不是终点

回头看,POC 只回答了「这件事技术上行不行」,它是项目的起点;上线也不是终点,只是系统开始接受真实世界检验的中点。真正的回报,来自上线之后被持续运营的那一长段时间。

所以判断一个 AI 项目能不能成,有个朴素的标志:组织愿不愿意为它上线后的运营付成本。愿意,上面五件事只是一张清单;不愿意,再高的演示准确率,也只是一场漂亮的演示。