AI 转型的动力,为什么应该从一线长出来

大多数企业推 AI 的方式是错的——由管理层自上而下拍脑袋决定“哪个场景该用 AI”,定个目标让大家往那个方向走。但 MIT 2025 年的研究显示,约 95% 的企业生成式 AI 试点没有带来有意义的转型,核心原因不是模型不行,而是这些项目脱离一线真实业务、由中心化部门自上而下强推。真正有效的 AI 转型动力必须是自下而上(bottom-up)的:只有身处枪声和战火里的一线人员,才真正知道哪些重复劳动最该被替代、哪些活自己最不愿意干。AI 应用大赛、Demo Day、FDE(前置部署工程师),本质上都是让场景从一线往上涌现的机制,而不是从上往下派发的指令。

领导最擅长定方向,但最不擅长知道哪件重复劳动最该被 AI 干掉。

一、大多数企业推 AI 的方式,一开始就错了

大多数企业推 AI 的方式是自上而下的:管理层或某个数字化部门坐在会议室里,讨论“我们哪个场景应该上 AI”,定一个方向、立一个目标,然后让全公司朝那个方向走。这个方式一开始就错了。

这几乎是我们接触各行业管理者、渠道、销售时看到的默认动作。大家很习惯“拍脑袋”——凭着对业务的整体印象,判断 AI 该用在哪儿,然后自上而下地推。这看起来很合理:领导站得高、看得全,由他来定方向天经地义。

但结果并不好。MIT 在 2025 年发布的《State of AI in Business》研究给出了一个刺眼的数字:企业投入的生成式 AI 试点,约 95% 没有带来有意义的转型。更关键的是它对原因的判断——失败的根源不是模型质量不行,而是这些 AI 项目大多是孤立的、脱离核心业务流程的,由中心化部门自上而下发起,和一线真正每天在做的事对不上。

而那存活下来的 5%,研究发现它们有一个共同点:不依赖中心化的 AI 部门去发掘用例,而是让真正贴近业务的人自己发现问题、自己评估工具、自己主导推广。换句话说,成功的那一小撮,方向是反过来的——不是自上而下,而是自下而上。

二、为什么领导拍脑袋定的 AI 场景,大多不成立?

领导拍脑袋定的 AI 场景大多不成立,是因为存在一个结构性的信息错位:定方向的人离真实的重复劳动最远,而离得最近的人没有定方向的权力。

这不是说领导能力不行。恰恰相反,领导最擅长的是定战略方向——公司该往哪走、资源往哪投,这些必须自上而下。但“哪一件具体的、重复的、琐碎的劳动最该被 AI 干掉”,这是一个完全不同性质的问题,而它恰恰不在领导的视野里。

原因很简单。一个每天要手工核对上百条数据的会计,清楚地知道这件事有多痛、多蠢、多该被自动化;一个每天在几十个群里守着报修消息、生怕漏一条的客服,清楚地知道自己最想摆脱的是哪一段工作。这些“痛”是身体记忆,是只有站在枪声和战火里的人才有的判断。而坐在会议室里的领导,对这些痛只有抽象的、二手的认知。

于是就出现了一个致命的错位:有权决定“AI 用在哪”的人,离真实的痛最远;离痛最近、最知道该用在哪的人,却没有决定权。自上而下的方式,把决策权交给了信息最少的那一端。这就是 95% 失败的结构性原因——不是执行不力,是从一开始就问错了人。

还有一层更微妙的东西。当 AI 场景是被自上而下“派”下来的,一线员工的姿态是被动的、甚至抵触的——这是别人要我用的工具,不是我要用的工具。近来已经能观察到白领对强制性 AI 转型(强制培训、使用配额)的隐性抵制。而当场景是一线自己提出来的,姿态完全不同:这是我自己想解决的问题。动力的来源不同,结果天差地别。

三、Coding 为什么会成为第一个被 AI 跑通的杀手级场景?

Coding 之所以成为第一个被 AI 大规模跑通的场景,不是因为哪个领导规划了它,而是因为它天然满足两个条件:它是高度重复的劳动,且提出需求的人(程序员自己)就是最痛的人——这是一个完美的自下而上案例。

想想看,写代码这件事,本质上包含大量重复劳动:敲样板代码、写重复的函数、查语法、调格式。这些是程序员每天在做、但并不真正创造价值、也谈不上乐趣的部分。

AI 编程工具做的,恰恰是把这部分重复劳动接管掉——尤其是在处理重复性编码任务上。程序员不必再一个字一个字地码那些机械的东西,而是可以把注意力集中到真正重要的地方——我到底要解决什么问题。这带来的不只是效率提升,更是一种成就感的回归:你从一个“打字员”变回了一个“解决问题的人”。

而这件事是怎么发生的?不是哪家公司的 CTO 开会决定“我们要用 AI 写代码”,是程序员自己涌向了这些工具。因为最痛的人就是提出需求的人,最懂这件事该怎么被替代的人就是每天在做这件事的人。场景、需求、验证,全部从一线自然长出来。这是一个教科书级别的自下而上案例,也解释了为什么它能成为第一个被大规模跑通的杀手级应用。

任何行业想找到自己的“杀手级 AI 场景”,都可以从这个案例里读出规律:去找那些高度重复、且做这件事的人自己最想摆脱的劳动。而这两个条件,只有一线人员自己能准确指出来。

四、那么,场景到底应该怎么被发现?

场景不应该被“决定”,而应该被“发现”——具体做法是搭建让一线痛点自然涌现、竞争、被验证的机制,而不是自上而下派发指令。有三种行之有效的方式:AI 应用大赛、Demo Day、以及基于真实场景的 FDE。

第一,AI 应用创新大赛。与其让领导猜哪个场景值得做,不如把问题抛给一线:你最想用 AI 解决自己工作里的哪件事?让员工自己提出场景、自己搭出原型。大赛的价值不在于评出名次,而在于它让几十上百个真实痛点同时浮出水面——这些痛点,没有一个是领导拍脑袋能想全的。

第二,Demo Day。让一线做出来的东西被看见、被使用、被反馈。一个真正解决了痛点的小工具,会自己传播——同岗位的人看到了,会说“这个我也要”。这种自发的扩散,比任何自上而下的推广培训都有效,因为它是需求拉动的,不是指令推动的。

第三,FDE(前置部署工程师),而且 FDE 本身就是基于场景的。(什么是真正的 FDE、它和驻场外包差在哪,我们专门写过一篇《什么是 FDE》。)FDE 的方法,是让工程师走进一线的真实工作现场,亲眼看、亲耳听那里的人每天在为什么而痛,再把这些痛点翻译成能真正解决问题的方案。这套方法的精髓——把一线的真实痛点翻译成方案,而不是把预设的方案硬套给一线——本质上也是自下而上的。它和拍脑袋最大的区别在于:FDE 是去现场找问题,而不是在会议室里定答案。

这三种方式形式不同,但内核是同一个:让场景从一线往上涌现,让最痛的人来指认最该被解决的事,再用机制去筛选、验证、放大它。这才是发现 AI 场景的正确姿势。

五、这不是要架空领导,而是要重新分工

自下而上不等于架空领导。正确的分工是:领导负责定方向、给资源、搭机制、扫清障碍(这些必须自上而下),一线负责发现具体场景(这些必须自下而上)。两者不是对立,而是各司其职。

需要说清楚,自下而上不是“不要领导”或“一切听一线的”。恰恰相反,它对领导提出了更高、但不同的要求。

领导要做的,不再是替一线决定“该用 AI 干什么”——那是他做不好、也不该做的事。领导要做的,是搭建让一线痛点能够涌现的机制(办大赛、办 Demo Day、引入 FDE)、给一线试错的资源和空间、以及在一个场景被验证有效后,用组织力量把它推广开、扫清跨部门的障碍。

方向和资源,自上而下;场景和需求,自下而上。

这才是 AI 转型正确的双向结构。领导定“我们要成为一家什么样的公司”(这是战略,可以参考《物业管理的下半场,到底该走向哪里?》),一线定“我这件重复的活该怎么被 AI 干掉”(这是场景)。前者没有后者,是空中楼阁;后者没有前者,是一盘散沙。

所以,回到最初。为什么那么多企业投了钱、开了会、立了目标,AI 却推不动?因为它们把最该问一线的问题,留在了会议室里自己拍脑袋回答。AI 转型真正的动力,从来不在战略 PPT 里,而在那个每天被重复劳动折磨、最想摆脱它的一线人员心里。你要做的,不是替他决定,而是给他一个把痛点说出来、并亲手解决掉的机会。