AI试点为何不见效：失败早已写进了设计里
试点有一个很少被人说破的属性：按定义，它并不负有改变任何事情的义务。它没有流程责任人，没有与记录系统（system of record）的对接，也没有一个"旧方式到期作废"的日期。它唯一的义务，是证明这项技术能用。
而技术几乎总是能用。这正是为什么讨论总是一次又一次绕回模型和厂商本身，尽管成功与失败之间的差距根本不在那里产生。多数试点的失败，是写在它的设计里的，而不是写在它的内容里。
试点验证的是技术本身，而是否落地的决策需要回答另外三个问题：上线之后谁是流程责任人、结果最终落到哪个系统里、旧流程何时关闭。这三个问题试点一个都不会回答，也不应该回答。修正的方法很简单：不要把试点设计成一场能力演示，而要设计成对一个数字的测量——需要人工返工的结果占比。
试点从来不会回答的三个问题
先把试点真正验证的内容,和它留下不验证的内容分开来看。这份清单很短,但其中每一条对上线结果的影响,都超过模型回答质量本身。
上线之后谁是流程责任人。在试点阶段,拥有者是项目团队,而项目一结束这支团队就解散了。接下来会发现,这个流程根本没有一个人对错误率负责、有权叫停这个场景、能批准规则变更。没有这个人,场景只能撑到第一次严重故障为止。
结果最终落到哪里。在试点阶段,只有参与者能看到结果——这足以评估质量。但到了生产环境上线阶段,结果必须进入公司认定事实的那个系统,也就是记录系统(system of record),否则没有参与请求的人根本看不到它。集成通常不在试点范围之内,因为它比试点本身还贵。
旧流程何时关闭。试点与现有工作并行运行,这本身很正常——这是试点的固有属性。但并行运行不会自己结束:只要旧方式仍然可用且不需要额外成本,一部分工作就会继续走旧路,想要把效果单独剥离出来也就不可能了。
| 问题 | 试点验证了什么 | 留下了什么没有验证 |
|---|---|---|
| 结果质量 | 完全验证 | — |
| 流程责任人 | 未验证 | 谁对错误率和叫停负责 |
| 能否进入记录系统 | 未验证 | 未参与的人能否看到结果 |
| 旧流程关闭 | 未验证 | 工作是否会整体迁移过去 |
| 运营成本 | 部分验证 | 维护、更新、错误排查 |
请注意:试点完美地完成了交给它的那个任务,分毫不差。问题不在试点本身,而在于人们把它的结果当成了回答上线问题的答案。
数据显示AI决策权归属并未被明确指定
责任人缺位不是抽象的说法,而是一个被大规模高管样本测量出来的事实。
35%的受访高管表示,至今仍不清楚谁有权质疑或推翻AI的建议,34%没有稳定的机制来解决人的决策与模型输出之间的冲突。只有15%的企业同时在AI应用和变革管理两方面都达到了成熟水平。
这是一家咨询机构出资委托的研究,其目的是推销一套运营模式重设方案;数据是相关关系,不是因果关系。这个局限是实实在在的。但这个数字本身描述的是一个事实,而不是一个评价:三分之一的高管说不出谁有权推翻系统的决定。这正是试点从来不会问的问题。
为什么成功的AI试点在上线后又会退回原点
有一类研究专门解释了一次性突击努力换来的改善为何会退回原点这一机制——它比当前这一轮技术浪潮早了几十年。
依靠一次性加强关注取得的改善,如果没有嵌入到持续性流程中,会系统性地退回原状:一旦指标好转,人手就会被抽调去做别的事,问题随之卷土重来。作者把这种机制称为能力陷阱(capability trap)。
这项研究与AI无关,写于四分之一个世纪之前——它是一个类比,而不是直接证据,我也正是把它当作类比来用。但其中描述的机制十分精确,能在任何一个试点中辨认出来:团队三个月的高强度关注带来了一个结果,这个结果被归功于技术,而不是归功于这份关注,而它也会随着关注的消失一同消失。
这个机制还有另一面——仅仅因为被观察这件事本身,就会系统性地夸大结果。
对著名照明实验复原后的原始数据重新分析发现,教科书里那种"仅因被观察就带来生产率大幅跃升"的经典描述并不成立:"现有关于所谓显著数据模式的描述,被证明完全是虚构的",尽管确实存在微弱的观察效应迹象。
全文需要付费访问,我使用的是摘要和结果描述——这是一个局限。由此得到的实践结论是双重的,也正因此才有用:不能把"霍桑效应(Hawthorne effect)"当作解释任何试点成功的万能理由,它比通常认为的要弱。但同样不能在不为团队额外关注做修正的情况下,把试点结果直接套用到生产环境——只不过这个修正幅度,比坊间流传的说法要小得多。
该淘汰试点的时候要淘汰,但不能没有验收阈值
这里也有必要摘掉一个错误的框架:大多数实验最终没有走到生产环境上线这一步,这件事本身并不是失败。
机器学习工程师把从实验到生产的路径描述成一个筛选过程:对企业来说,快速原型化大量想法并逐一淘汰它们,直到最好的那个走到工业化使用,是划算的。被广泛引用的"多数模型不会走到生产环境"这一比例,反映的是实验本身的性质,而不是失败。
样本很小——只有18人——在统计上不具代表性,作者自己也承认这一点。但他们的观察消解了一种虚假的担忧:问题不在于十个试点里有九个被关停,而在于淘汰标准从来没有被提前设定。没有标准的时候,被关停的往往不是最差的场景,而是那个赞助人已经失去兴趣的场景。
如何设计一个能预测生产环境结果的AI试点
不需要取消试点——需要改变的,是它所回答的问题。不再是"技术能不能用",而应该是"多大比例的结果需要返工"。
关键在第二个环节。提前定好的阈值,能把试点从一场演示变成一次真正的检验,把关于结果的争论变成与一个数字的核对。没有它,结果就只能靠印象来讨论,谁说得更有说服力,谁就能拍板。
第三个环节同样重要。真实业务流与精心挑选的样例之间的差异,恰恰体现在那些正是推动落地的原因所在的情形上:非标准的表达方式、不完整的数据、少见的情况。用准备好的数据做演示,对这些情况完全没有任何参考价值。关于如何用同样这些指标计算业务效果,可参阅另一篇专题分析。
启动AI试点前需要做的四个决定
指定流程责任人,而不是项目负责人
这个人要在试点结束后留下来,对错误率负责。如果没有这样一个人,试点就没有意义。
在启动前定好验收阈值
多大比例的返工结果算是可以接受的。这个数字要提前定好,并且落在书面记录上。
在真实业务流上测试
不预先挑选样例。恰恰是那些非标准情况,决定了这个场景到底能不能用。
定好旧流程关闭的日期
这个日期不写在试点里,而是写在落地方案里——但必须在试点开始之前就定下来,否则落地永远不会真正完成。
一个没有提前设定阈值的试点,不是在检验一个假设,而是在为一个早已做出的决定寻找论据。
关于AI试点为何失败的常见问题
为什么AI试点走不到生产环境上线?
因为试点验证的是技术本身的质量,而走向生产环境上线需要回答另外三个问题的答案:谁是流程责任人、结果落到哪个系统里、旧的工作方式何时关闭。这三个问题都不属于试点这种形式所涵盖的范围。试点顺利结束,随后就撞上了没人事先准备好的那些决策。
该如何正确设计一个AI场景的试点?
把它简化成对一个指标的测量——需要返工的结果占比——并在启动前就定好验收阈值。测量要在真实业务流上进行,不预先挑选样例。最终得到的是一个数字,而不是一种印象,决策通过与阈值比对来做出,而不是靠争论。
如果结果模棱两可,是否应该关停试点?
应该,而提前设定好的关停标准,是唯一能在不产生冲突的情况下做到这一点的方式。多数实验被淘汰是正常的:这是实验本身的属性,不是失败的标志。不正常的是,被关停的不是最差的场景,而是赞助人已经失去兴趣的场景——这样企业就会失去从自己的尝试中学习的能力。
试点结果能在多大程度上迁移到生产环境?
需要为团队额外的关注做修正,而这份关注在生产环境中会消失。这个修正幅度,比流行版本的观察效应说法暗示的要小——对经典实验的重新分析表明,它其实不大。但也不是零:一个依赖发起人每天亲自参与才能维持的试点,在生产环境中的表现会明显更差。
试点不回答的三个问题清单,以及带有预先设定阈值的试点设计,是作者本人从中俄投资基金(China-Russia Investment Fund)投资组合中技术项目评估实践、以及Alego.Digital的落地实践中总结出的原创归纳。本文没有引用任何内部量化指标:所有数字均来自外部来源,并注明了各自的方法论。这套设计在任何公司文件中都没有正式成文记录;本文是首次对其进行系统阐述。
- IBM Institute for Business Value, Oxford Economics. The AI-Human Operating Model, 2026年6月(对14个国家1,000名高管的调查)。ibm.com
- Repenning N. P., Sterman J. D. Nobody Ever Gets Credit for Fixing Problems that Never Happened. California Management Review, 2001. web.mit.edu
- Levitt S. D., List J. A. Was There Really a Hawthorne Effect at the Hawthorne Plant? NBER Working Paper 15016, 2009. nber.org
- Shankar S., Garcia R., Hellerstein J. M., Parameswaran A. G. Operationalizing Machine Learning: An Interview Study. arXiv:2209.09125, 2022. arxiv.org