穆胜：AI摧毁职能体系？呵呵

最近网上若干知识博主有一种观点——认为业务AI化、打造智能体，不应该以职能为单位，甚至认为这种思维方式是太局限、“老登化”的。在任何一个新兴领域，“颠覆式观点”总是能够引起广泛共鸣，一时间，不少人都举双手支持。

但我要说的是，这又是一种“技术可以穿越组织”的妄念。今天把这个问题再掰碎了谈谈。

01 技术能否穿越组织？

我和穆胜咨询的观点是——若干开源平台的确提供了低代码重构工作流的可能性，但依然需要通过职能领域的一次次重构才能达到AI化的效果，如果AI穿越了职能，也仅仅是以API接口的方式进行连接。

这句话有三层“残酷的现实”，足以打破“技术可以穿越组织”的妄念。

其一，“低代码重构工作流”的本质是，重构的“门槛”降了，但“手术”免不了。

开源低代码平台确实让搭建AI应用变成了像拼接乐高积木一样的“拖拽组件”，但这只是“装修工具”的普及，它并不会带来组织的自动进化。真正的难点在于“砸掉承重墙”，即对现有业务流程进行“脱胎换骨”的梳理。比如，把原来靠Excel传递的“报销审批流”，重构为“AI实时抓取发票数据+自动比对预算+智能风控”的新闭环。如何实现这种变化？工具只是提供了可能性，关键还是要由设计师来操刀流程重构，这意味着，必须由懂该职能的人去“一步一步”操刀手术，去拆解现有流程，再进行拼接。低代码解决不了“该拆哪里”“拆了如何拼接”的决策问题。

其二，“通过职能领域的一次次重构”的本质是，这种重构是“搬砖”，不是“魔术”。

“一次次”这个词是我们字斟句酌的结果。这意味着，AI化的本质不是一次性替换，而是“颗粒度拆解”。举例来说，一个HR招聘流程，要拆成“JD生成、简历初筛、面试问答、背景调查、薪资谈判”等十几个节点，如果要重构，就需要把每个节点分别AI化，一个个进行试错，失败一个再调，调完再拼。这个“搬砖”的过程，没有任何捷径，只能靠领域专家和工程师一遍遍磨。

其三，关于“AI穿越职能，仅以API接口连接”，说的是AI产生“智能体”或“数字员工”的底层逻辑。

很多外行幻想AI像一个“超级大脑”直接统管全公司，正如很多老板把AI当做许愿池，幻想未来AI可以替代所有人。但现实是，AI无法“消化”职能，只能“调用”职能。这背后是AI时代初期，外围观众对于其运作原理并不清楚。

我们再举一个例子，一个“智能供应链”AI判断需要补货，它不会自己去写采购单，而是通过API调取ERP（企业资源计划系统）的“创建采购订单”接口；它发现库存异常，也是通过API调取WMS（仓储管理系统）的数据。AI是“神经中枢”发号施令，但“手脚”（各职能系统）依然是独立的旧系统，通过API这根“神经纤维”连接。

02 AI？企业需要什么AI？

当前很多企业动辄提AI，但实际上对自己需要什么AI，AI如何来解决问题一无所知。企业买的不是模型，甚至也不是数字员工，他们买的是在业务场景里解决问题的“轻快系统”。

就算回到大多企业认为“AI化”就是“AI换人”的简单思路，我们也能够梳理出其中的原理。

一个“智能体”或“数字员工”，一般是基于开源大模型打造的，大模型的开发本来就是“烧钱的游戏”，更适合作为AI时代的底层设施（和算力一样），由OpenAI、Anthropic、Deepseek这类企业通过资本的助力来完成。当然，也有不少企业开始尝试闭源大模型，但前景方面依然是前途未卜。

大模型是一颗聪明的大脑，它不能解决企业的实际问题，因为它“有脑无手”。这就意味着，要基于这颗大脑开发出“智能体”或“数字员工”，就需要低代码开发平台。它就像一套“标准化肢体组件”，让“大脑”（大模型）能快速“长出手脚”来执行具体任务。这些平台通常提供可视化、拖拽式的开发环境，让开发者（甚至业务人员）无需从零写代码，就能把大模型的能力和企业现有的系统、数据“连接”起来。

目前提供这类工具的主要有三股力量：

一是大模型厂商，如OpenAI等，他们会附带提供低代码开发平台；

二是以云服务为基因的厂商，如阿里云、AWS等，他们因为云服务的业务属性，天然就是提供低代码开发平台的有力竞争者；

三是第三方低代码平台，如OutSystems、Mendix等，他们深耕业务场景，能与多家模型及云厂商集成，他们是最具低代码开发平台基因的企业。

对于大多企业而言，他们只需要基于开源大模型提供的“大脑”，再基于低代码开发平台提供的“肢体”，对自己的业务流进行重塑即可，犹如拼接乐高积木。业务流重塑的同时，自然也就涉及对组织进行变革。这就是“AI化”相对传统的“数字化转型”在技术上更有希望的地方。

按照这个逻辑，老板们当然希望“上个AI”就能解决所有的问题，但问题是，这个“AI”不是一个“一步到位的全案式解决方案”，更应该是“持续迭代的复杂系统”。它来源于对于每个职能的切割、改造、拼接，再成熟的系统，也需要随着市场变化而持续迭代。

03 AI再强，也要遵循组织原理

现实是，如果有个“AI系统”穿越了职能，那么，首先是每个职能都进行了“AI化”，而后才是用最合理的方式组合成“系统”。

横向分工还在，协作还在；纵向集权还在，授权还在；流程还在，节点还在；考核还在，激励还在……组织的逻辑并没有改变。正如从上古时代的猛犸象，到现代的金钱豹，敏捷性提升了，但生物学知识并没有被颠覆，细胞、器官还是基本的构建。谈什么“技术穿越组织”，有点low。

要说AI推动了组织重构，当然可以，但仅仅是“推动”。但金字塔组织里的部门墙、隔热层、流程桶、KPI真空罩，不是本来就应该被变革吗？企业需要打破金字塔组织，走向平台型组织（
Platform-basedOrganization），一早就是我们提及的趋势。AI只是提供了技术的便利性，而且因为这个技术的强大，让组织变革变得更加容易。但妄想AI自动带来组织变革，还是有点草率了。

我们可以举出无数的例子，金字塔组织里加载AI，依然不会带来组织效率的提升。我们以前的研究也得出了明确结论——“平台型组织+AI技术=智能体组织”。但时至今日，大量老板还是想用AI技术绕过自己不愿面对的组织变革，这实在让人有点哭笑不得。

回到本文开始的问题。我们坚持认为——AI不会取代职能系统，AI只是给职能系统装上了一副“智能眼镜”。它看得更准了，但干活的还是职能里那一双双手，连接处只能是API。

当然，我们也需要强调一点，尽管职能系统不会改变，但企业的业务流或流程会更加灵活。API连接只是“读写”权限，未来的核心壁垒在于“事件驱动”。在上面采购的例子里，当AI通过API写完采购单后，ERP系统自动触发的“审批流”是否能反过来通过API回调AI进行“多轮协商”。这才是“穿越”的高级形态，但本质上依然是API对API的对话。

04 职能专家，还有价值吗？

如果职能系统不会被AI技术废掉，那么“AI化”就需要重构每个职能，这甚至要从重构职能里的每个“子职能”开始。所以，我在以前就提出，未来职能部门的产出应该是“智能体”或“数字员工”。

这引出了另一个关键问题。既然重构职能领域这么“苦”且“慢”，那么，究竟是“懂业务的老员工学会用低代码”更快，还是“懂AI的极客去蹲点摸透业务痛点”更快？这决定了CTO或CIO该在“AI化转型”的项目里，把预算花在培训还是招聘上。

我的建议是，如果预算只够押一边，请毫不犹豫地押在“懂业务”上。原因极其简单，AI技术正在疯狂“白菜化”，但业务认知的“壁垒”却越来越厚。我有三个具体的理由：

其一，工具平权，业务直觉无法平权。

OpenAI、DeepSeek、Llama 3的性能差距正在急剧缩小，低代码平台让“调API”变得像“开关灯”一样简单。这意味着，“怎么调用AI”已经不值钱了。但“什么节点该调用AI”“调用来解决什么具体痛点”“输出结果该怎么解释给老板听”等问题，完全取决于对那条供应链、那本财务报表、那个客户心理的深度理解。这种“直觉”是AI无法馈赠的，只能靠年复一年的浸泡。

其二，懂AI的人只会问“能不能”，懂业务的人才能判“该不该”。

让一个AI极客去财务部蹲点三个月，他确实能听懂“发票验真”和“三单匹配”这些词，但他很难感知到“月底关账时财务总监那种火烧眉毛的焦虑感”，也很难预判“税务稽查时哪些数据是真正的红线”。而一个懂业务的老员工，哪怕只会用最基础的低代码拖拽，他构建出来的工作流是“带着防弹衣”的，是真正能落地且不出合规事故的。AI极客做出来的东西往往在实验室跑得通，一到复杂现实的“脏数据”里就崩盘。

其三，变革的阻力不是技术，是“人的惯性”。

这是最容易被忽视的一点。推动AI化，最难的不是写代码，而是让销售部那帮“老油条”愿意把客户跟单记录填进系统，让生产线班长允许AI修改排期。懂业务的人知道谁是大嗓门、谁是关键决策者、该请谁吃饭来推动试点。不得不说，这种“组织润滑”能力，AI极客花十年也学不会。这也是我们这类深耕组织变革的咨询机构的看家本领。

当然，我还必须补充一句——我们重用的“懂业务”的人，必须是“懂数字化业务”的，而不是“懂纸质化业务”。那些抵制数字化、抵制AI的业务能手，首先就应该被排除在未来的组织名单之外。