第 90 天设一道闸：把 AI 试点变成制度的三件事

据埃森哲中国数字化转型指数（2026 年 7 月发布），跨过先进 AI 应用试点阶段的受访中国企业占比已从上一年的 46% 升至 88%，而实现生产效率、收入和利润提升等显著成果的企业只从 9% 升至 14%，着手进行运营与业务系统性重构的只有 18%。

三个数摆在一起，说的是同一件事：开始很容易，接下来那一步没人走。

而"接下来那一步"通常死在一个很具体的时刻——不是第 7 天，不是第 30 天，是试点跑到第三个月的时候。它不是突然崩掉的，是慢慢没人提了：发起的那个人换了别的项目，用它的两个同事回到了原来的做法，账单还在扣，但已经没有人打开它。

本文给的处方是：在第 90 天设一道闸。 闸门之前的第 61 到第 90 天，必须完成三件事；过不了闸，就在第 90 天关掉，不要再给三个月。

一、先把「第 90 天」这个说法的底交代清楚

这一节放在最前面，因为它决定了后面的话该怎么读。

我没有见到任何一份调研给出过"AI 项目在第 90 天死亡"的统计。这个天数是本文提出的一个管理节奏，不是研究结论。 如果你在别处看到有人把"90 天"说成一条被统计出来的规律，那份调研值得你去找原文——站上另有一篇专门拆过一个被引用了整整一年、却从头到尾被读错了三层的百分比，方法是一样的：找原文、看主语、看样本。

那为什么选 90 天。三条理由，全部是可核对的日历事实，不是任何调研的结论：

第一，90 天是第三张完整的月账单。 这一条最硬，第三节会展开：只有到第三个月，用量才接近常态，单位成本才第一次算得出意义。

第二，90 天通常跨过一次季度考核。 一个没被写进任何人考核表的东西，在第一次季度复盘上会被自然地跳过。跳过一次之后，它在公司里就正式变成"那个谁在弄的东西"。

第三，90 天是多数公司立项汇报的第一个节点。 三个月要汇报一次，是绝大多数中小企业的惯例。你要么在这一天拿出可以被制度化的东西，要么在这一天体面地关掉它。

再回到开头那三个数。据同一份指数，上一年的口径是 46% 跨过了先进 AI 应用试点阶段、9% 拿到显著成果，2026 年这两个数变成了 88% 和 14%。跨过试点这一格翻了近一倍，拿到显著成果这一格只挪了 5 个百分点。

有一个减法我不做：88 − 14 = 74，这个 74 不能读成"74% 的企业失败了"。它们是同一份指数同一年的两个指标，但一个数的是"已经跨过试点阶段的企业"、另一个数的是"拿到显著成果的企业"，口径不同，相减得到的不是一个有含义的失败率，只能说明"铺开"和"兑现"之间存在很大的距离。这一步我停在这里，不往下算。

同一份指数里还有一句值得抄下来的原文，它写在新增障碍那一栏：「调用词元产生持续性成本支出」。这一句是这篇文章后半段的支点。

二、这道闸拦的是什么：试点和制度的三条差别

试点跑得好，不等于它离制度近。它们之间隔着三件事，每一件都不是靠"用得更多"能自然跨过去的。

差别一：试点由人推动，制度由触发条件推动。

试点期里，那件事之所以发生，是因为有个人在推：他记得、他提醒、他在群里贴结果。制度不需要这个人——制度写的是"当 X 发生时，先走它"。

判断自己在哪一侧的方法很省事：把发起人调走一周，看它还跑不跑。

差别二：试点的成本挂在项目上，制度的成本挂在科目上。

这一条对应埃森哲那句「调用词元产生持续性成本支出」。传统的软件采购是一次性的许可费或固定的年费，签完就定了，用多用少一个价；而这类支出随调用量走，它不会随试点结束而结束，只会随着用的人变多而变多。

于是出现一种很典型的状态：项目已经"结束"了，账单还在每月扣，而没有任何一个科目对它负责。第 90 天是第一次能把这笔钱看清楚的时刻，理由在第三节。

差别三：试点允许没有兜底，制度不允许。

试点期出错，大家会说"还在试嘛"。制度化之后同一个错误就是事故，因为已经有人按它的输出去做了下一步动作。所以制度化这一步真正要写下来的不是"它能干什么"，是"它给不出结果的时候，转给谁"。

再放一句旁证，只取一个数，不展开：MIT NANDA 那份被广泛引用的报告里，有一组漏斗——约 60% 的组织评估过、约 20% 进入试点、约 5% 进入生产，试点转产率约 25%。这份报告的样本、限制和它被读错的三层，站上另有一篇专门拆过，本文不重复，也不把这个 25% 当成你的概率。它在这里只说明一件事：从试点到生产之间，确实有一道明显的落差，而这道落差不是靠模型变强能跨过去的。

三、第 61 到第 90 天，必须完成的三件事

三件事，顺序不能换。第一件不做，第二、三件没有对象；第二件不做，第三件没人接。

第一件 · 把跑得最顺的那几条，写成触发条件

第 1 步。从试点期里挑出跑得最顺的 1 到 3 条，不许超过 3 条。

判据是"这三个月里它没出过需要事后补救的错"，不是"它最省时间"。省时间但偶尔翻车的那条，留在试点里继续跑，不进这一批。

第 2 步。每一条写成一行，格式是：当 X 发生时，先走它；它给不出结果时，转给 Y。

X 必须是一个可以被观察到的事件（"收到一份询价单""对账单出现差额"），不是一个状态（"需要提高效率"）。Y 必须是一个具体的接手动作，不是一句"人工处理"。

第 3 步。这一行写进已经存在的那份文档的正文里，不许新建文档。

写进现有的作业指导书、岗位说明书、值班手册——哪份是这条线上的人本来就会打开的，就写进哪一份。新建的文档，三个月之后没人打开。 这一条是本文的判断，理由很朴素：新文档需要一个让人想起它的理由，而现有文档已经有了。

第 4 步。做一次发起人离场测试。 让推动这件事的人一周之内不回答任何相关问题（休假是最好的窗口）。一周之后看那 1 到 3 条还在不在跑。这是第 90 天唯一有意义的一次验收——它验的不是效果，是"这件事还需不需要一个特定的人活着"。

第二件 · 把钱接上一个科目和一个上限

第 5 步。给它一个固定的费用科目，不要挂在"项目费用"下面。

挂在项目费用里的支出，会随着项目结项而失去归属，然后变成一笔每月都在扣、每月都没人看的钱。给它一个科目，等于给它一个每月会被人扫一眼的位置。

第 6 步。在供应商后台设一个月度上限。

上限值我的建议是：前三个月实际支出的中位数 × 1.5。这个系数是本文给的建议值，不是任何规范。设它的目的不是省钱，是让异常暴露——某个月突然打满上限，通常意味着有人写了一段会重复调用的东西，或者有人把整批历史数据一次性喂了进去。没有上限，这两件事你只会在下个月的账单上知道。

第 7 步。第 90 天要能报出一个数：单位成本。

分子分母都要先定死并写下来：

• →分子 = 这三个月的接口调用费 + 那个每周花时间看它的人的工时折算。第二项经常被漏掉，而它常常比第一项大。
• →分母 = "完整走完"的条数。中途转给人的那些算不算、算半条还是不算，你必须先定一个口径并写在纸上，因为下个季度还要用同一个口径再算一次，两次口径不同，比较就没有意义。

为什么要等到第 90 天才算这个数：前两个月的用量里有大量试用性质的调用——同一件事被反复试三遍、有人在测边界、有人在给别的同事演示。第三个月才接近常态。这是本文的判断，你也可以自己验证：把三个月的调用量按月画出来，如果第三个月和第二个月的差距远小于第二个月和第一个月，就说明它开始进入常态了。

第三件 · 把人从"发起人"换成"日常负责人 + 每月十五分钟"

第 8 步。把日常负责人写进岗位说明书，写到岗位，落到具体的人。

这个人不需要懂模型，需要的是每天会打开这条业务线的人。发起人可以是他的顾问，但不能继续是他。

第 9 步。每月一次复核，十五分钟，只做三件事。

看有没有断（这个月有没有连续几天一条都没走）、看单位成本有没有跳（和上个月比，超过某个幅度就要找原因）、看那 1 到 3 条触发条件有没有被绕过（有人图省事直接走了老路）。

十五分钟是上限不是下限。 超过十五分钟，说明前两件事没做完——多出来的时间一定花在了"翻记录找数"上，而那些数本该在第 7 步就已经有了固定口径。

四、第 90 天的三条判据，以及什么时候该在这一天关掉它

三条判据，全部问"能不能"，不问"好不好"：

判据一：发起人离场一周，那几条还在跑吗？

判据二：你能报出单位成本吗？ 报得出一个带口径说明的数就算过，数字难看不算不过。

判据三：上个月有没有至少一次，是它给不出结果、按写下来的那一行转给了人？

第三条最容易全军覆没，而它的失效方式很反直觉：一次转人工都没发生，通常不是因为它太强，是因为没人在用它。 一个真正在跑的自动化环节，一定会有它接不住的输入。一条兜底路径三个月零触发，先去查调用量，再下结论。

三条里过不了两条，我的建议是在第 90 天关掉，而不是再给三个月。

理由就是差别二那一条：这类支出随调用量持续发生，再给三个月不改变任何结构，只是把成本延长一倍，同时让更多人开始绕着它工作。第 90 天关掉的代价是三个月；第 365 天关掉的代价是一年，外加一批已经形成的习惯要再改回来。

关掉不等于失败。关掉的时候要留下三样东西，它们是这三个月真正的产出：那份写下来的流程（哪怕最后不由机器跑，它也是一份 SOP）、那个单位成本的口径、以及那份"它接不住哪几类输入"的清单。下一次再启动的时候，从这三样开始，比从零开始快得多。

接下来是代价，三条，得先接受再开工。

第一，制度化会让一部分人失去"不用它"的自由，摩擦是真的。 而且这个摩擦恰好会在第 61 到第 90 天集中爆发——因为在此之前它是可选的。这正是要设一道闸而不是让它自然生长的原因：摩擦早晚要来，你可以选择它在一个有准备的时间点来。

第二，那几行写进文档的触发条件，改一次要走文档流程。 所以第一版只写最稳的那 1 到 3 条。贪多的结果是三个月后有六条要改，而没有人愿意为它启动一次文档评审。

第三，第一次算出来的单位成本通常很难看，因为分母小。 要接受它难看，不要为了好看去改口径——口径一改，下个季度就没有可比的基准了。

什么时候不该走这套，三种情况。

第一种：这条流程一个月跑不到 20 次。 分母太小，单位成本算不出意义，那 1.5 倍的上限也没有参考价值。这类就让它停在试点，用着，但别制度化——制度化的成本会超过它省下来的。

第二种：团队还在等一个"更好的模型"再定型。 这个理由在技术上经常是成立的，但它在管理上是无限期的。折中办法：把闸期从 90 天延到下一个季度末，但必须明写延到哪一天，并写进同一份文档。不许出现"等下一版出来再说"这种没有日期的延期。

第三种：只有一个人的公司。 第三件事（把人从发起人换成日常负责人）不成立，因为发起人就是唯一的人。那么这套退化成两件：写触发条件、算单位成本。第三件换成另一个动作——把那 1 到 3 条触发条件写在一个你三个月后一定会打开的地方，比如报价单模板的第一行。

最后回到开头那三个数。88% 已跨过试点阶段、只有 14% 拿到显著成果、只有 18% 做过系统性运营重构——中间那道坎不在模型侧，在第 61 到第 90 天没人做的那三件事上。

上线之后的运维和成本控制怎么排，完整的做法在《数字员工搭建实战》第 6 课。