为什么 AI 试点总停在演示阶段

演示跑通了，上线还差什么

很多 AI 试点的演示都很顺：一封询价邮件发进去，几秒后出来一份报价草稿，规格、数量、交期都对。会议室里大家点头，项目就停在了这里。

演示用的是挑过的样例数据，走的是最顺的一条路，旁边还有工程师看着。换成每天真实发生的业务，问题会一个接一个冒出来：

• 数据：询价散在邮件、微信和 Excel 里，客户用简称，型号偶尔写错，最新的价格表在某个同事的电脑上。
• 权限：ERP 的接口没开，开了也只能读不能写，审批要走好几周。
• 例外：急单、老客户特价、缺货换型号，这些情况演示里一次都没出现过。
• 习惯：销售习惯在微信里直接报价，新系统多出来的每一步都会被绕过去。

卡住项目的，很少是技术本身

上面这些问题单看都不大，和模型能力关系也不大。它们只在真实业务里出现，所以只能在真实业务里解决。

我做 ERP 实施的那些年，项目卡住的地方也很少是软件装不上，多半卡在数据、权限和人。AI 项目在这一点上没有变，只是演示做得更快、更漂亮，让人更容易以为离上线不远了。

先挑一个每天都在发生的流程

第一个流程不必最炫。经营驾驶舱、全公司的知识大脑听起来都很好，可它们牵涉的系统和人太多，几周之内很难看出结果。更适合起步的，是那种每天都在发生、大家都嫌麻烦的流程，比如询价到报价，或者把订单同步进 ERP。

挑的时候可以对照这几条：

• 每天或每周都在发生，做好了，团队马上能感觉到。
• 有一位业务负责人，能拍板流程怎么改、做到什么程度算好。
• 输入和输出说得清：数据从哪里来，最后要变成什么。
• 出错有人兜底：报价、对外发送这类动作，发出去之前有人确认。

上线标准，动手之前写下来

“试点成功”如果没有写成标准，最后只能凭感觉。而感觉往往是：演示时挺好，用起来一般。

上线标准不用复杂，几个数字加一个签字的人就够了。常用的指标是处理时长、差错率和实际使用率。最后一个最容易被忽略：系统做出来没人用，前两个数字再好看也没有意义。

定标准大致分四步：

1. 记录现状
2. 约定目标
3. 约定怎么量
4. 负责人确认

• 现状要量真实的数字：处理一单要多久，一个月错几单，有多少人在用现在的做法。不先量一次，做完也无从比较。
• 目标由业务负责人来定，工程师提供判断依据。
• 怎么量也要先说好，用哪一段时间、哪一类单子来算，免得事后各说各的。
• 最后由业务负责人签字确认，这份标准就是验收依据。

进驻的几周，每周看一件事

进驻冲刺通常是四到八周。时间不长，所以每周都要拿出一样能运行、看得见的东西，而且用真实数据来跑。流程编排、统一登录这类通用部分，我会直接用现成的开源组件，比如 n8n 中文版和 JetAuth，把时间留给这家企业特有的部分。

下面四步大致对应前后几周，但顺序比日期重要。第一周如果接不上真实数据，后面的进度都要打折扣；权限和接口的问题，暴露得越早越好办。

1. 接上真实数据
2. 跑通主路径
3. 补上例外和确认
4. 业务人员用到达标

每周演示，用他们自己的单子

每周的演示主要是给业务负责人看的。看到自己团队的单子，他们的判断会准确得多，提出的修改也更具体。

演示时也回头检查上周提的问题有没有解决，新功能放在后面看。问题拖过两周没人管，通常说明流程里有一处没人负责，这比功能做慢了更值得早点说出来。

交接：工程师撤出后，系统照常运转

试点算不算成功，有一个很直接的检验：工程师撤出以后，系统还能不能照常用下去。

所以交接不能等到最后一天开个培训会。从进驻开始，就要让企业里的人参与进来，下面这些事都要落到一个具体的人和一份写下来的说明上：

• 日常谁看运行状态，出错了先看哪里。
• 报价规则、产品资料在哪里改，改完怎么验证。
• 账号和权限由谁管理，人员变动时怎么调整。
• 什么情况需要回头找工程师，怎么联系。

如果项目已经停在演示阶段

先回头看两件事：它跑的是不是真实数据，上线标准有没有写下来、有没有人签字。

这两件事补上之前，换模型、加功能都帮不了太多。补上之后，下一步该做什么，通常会清楚很多。