中物智库 7小时前
AI 抹平的是技能的边界,物业要重写的是分工的逻辑——读清华李宁教授访谈,以及它指向的物业组织改造
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_font3.html

 

朋友转来腾讯科技《沸腾之下》的一篇访谈,一万多字,访谈对象是清华大学经济管理学院的李宁教授、《AI 原生组织》的作者。标题取得挺狠:《中层消失、专家被蒸馏、超级个体单干,公司还需要多少人?》

读完我推荐给了几位同行。

日常推送给我的 AI 稿子,多数是划过去的。谈模型迭代,谈算力,谈某个 Agent 又刷新了什么榜单,看标题就知道内容。这篇不同,它通篇谈的不是技术,是公司—— AI 这样走下去,公司这种运行了两百年的组织形式,还能不能成立。

还有一个原因。这篇文章讨论的三件事——分工的前提、中层的价值、经验的沉淀——在物业身上每一条都对得上。物业是国内分工切得最细的服务业之一,一个项目一张编制表,成本的大头是人,老师傅一辈子攒下的经验从未落到纸上。它们恰好都是 AI 最先触及的部分。

这篇文章记录我读后的理解,也把几个一直悬着的物业问题重新想过一遍。

一、公司为什么存在:分工的前提正在松动

李宁的起点朴素到有点反高潮。他问:公司为什么存在?

然后回到亚当 · 斯密的制针工厂。工序拆开,每人只做一小段,效率就上来了。拆碎的部分如何复原?靠会议、审批、庞大的中层管理。所以现代公司这套制度的底,归纳起来四个字:拆解与粘合。

为什么必须拆?因为一个人不可能学会所有技能。为什么必须粘?因为事情越复杂,需要协调的人就越多。

这套解释在教科书上见过无数遍,却鲜少有人把它当作一个前提来审视。它成立有一个隐含条件:人的能力有边界。

AI 正在抹平的正是这条边界。

他举了一个例子。过去做软件,有人搞设计、有人搞数据库、有人做运营;现在需求讲清楚,AI 能把前后端和数据库一并做完。他的原话是:做前端的人顺手问一句后端怎么搭,AI 就给他做完了。

这句话对服务业的分量不轻。一旦 " 一个人学不会所有技能 " 不再成立,建立在它之上的工种、部门、职级、汇报线,就都要重新解释自己凭什么继续存在。

二、两周的活,一小时干完,什么时候交

访谈里有段对话我反复看了几遍。

李宁在课堂上问学生:老板布置一项任务,两周周期,属于那种非优秀员工不能完成的活。你调用几个 Agent,一小时做完。那么什么时候交?

多数学生答:两周以后。

起初它像个段子,再看是一份诊断书。它解释了这两年一直说不太清楚的一件事:个体层面 AI 提效的体感如此强烈,企业层面的产出却没有发生相应变化。水底的个体早已暗流涌动,水面的组织依旧波澜不惊。

他还讲了另一种浪费的形态。有些事原本不需要十个人完成,但岗位未改、编制未动,十个人各带一个 Agent,产出的东西自然高度雷同。Token 烧掉了,每个人都自认为快了,企业的产出不过是多了一批重复与冗余。

他给的方案却很简单:先想清楚需求。有十个新产品要做,那就组织人去做;如果依旧是这一个产品、这一点客户,只要求大家多用 Token,产出往哪里放?

这句话我想说给物业企业的管理者听。这两年物业在工具、系统、中台上投入不少,但真正回答过 " 多出来的产能往哪儿去 " 这个问题的公司,我见到的不多。

工具是加速器,方向盘在需求那一端。没有新需求,加速器只是让组织在原地转得更快。

三、瓶颈换位置了:从生成到验证

上一段是情绪高点,这一段才是要害。

李宁把任务拆成两个维度看:生成,验证。

过去的分工按工作量切分,因为生成困难。报告要人写,台账要人填,图纸要人画。瓶颈在生成端,所以需要很多人。

现在生成变得极其廉价。他自己的团队现在一天能出一篇论文,用他的话说,根本看不过来。过去咨询公司是一批初级员工负责搜索、撰写,最后由专家与客户洽谈;以后报告可以很快写出来,问题在于专家有没有时间看。

瓶颈因此从生成移到了验证。

这也解释了为什么数学和代码走在前头,因为可验证。给一个明确的奖励函数,它知道自己在变好还是变差,就能持续改进。而 " 一篇文章怎样才算好 ",除语言、语法之外还有品味,标准不容易设定。

顺着这条线,他给出了全文最关键的一句判断:组织的分工逻辑,正在从按工作量切分,转向按认知带宽切分。

为什么是认知带宽?因为人的注意力成了新的上限。你花十分钟交代一个想法,AI 干一整天,中途回来请你决策;等待期间你开第二个项目,开到第五六个,很多人就开始说:我没有想法了,想不出还能让 AI 做什么。

一个项目可以让几百个 Agent 并行运行,但它们解决的是工作量,解决不了人的判断与注意力。

这一部分若换成物业的语境,大致如下:

这张表最后一行,是这篇访谈对物业最实在的一条提醒。

四、物业的三层结构性矛盾

第一层,按人头分工。

保安、保洁、客服、工程、绿化,一个岗位一个定义,一张编制表,服务费按人头测算。这套做法运行多年而无人质疑,因为在 " 一个人学不会所有技能 " 的前提下,它是成立的。

脆弱之处也正在这里:它的边界是被技能划定的,而技能恰恰是 AI 最先抹平的对象。

当一个人带着 Agent 能够跑完客服工单、报表台账、合同归档、催费提醒,编制表就不能只用 " 岗位 " 这一个维度去解释。这不是说物业明天能少一半人,而是这套表的底层逻辑需要重写。

项目经理、片区经理、品质督导,日常在做什么?开会、协调、催报表、追进度、处理扯皮。李宁那句 " 以前很多中层是在处理摩擦 ",放在物业格外准确。

不好听但必须说:物业的项目经理层里,相当一部分人存在的理由就是传递信息。总部下达、项目上报、现场拍照、台账回填。AI 抹掉的第一样东西是摩擦,而摩擦恰恰构成这一层最主要的价值来源。

并非危言。片区层面的报表、巡场、稽核向工具迁移,已有企业在做。工作量没有减少,专门传递信息的岗位却开始松动。

第三层,也是最难的一层:经验从未沉淀。

干了二十年的工程主管,听水泵的声音就知道哪一台即将损坏,也清楚哪几台还能再撑一个季度;老管家知道哪几户必须先打电话再上门,哪几户一条消息就够。

这些东西有记录吗?没有。全部留在这两个人的脑子里。

而 AI 时代最大的红利,恰恰是把这类隐性经验 Skill 化。所以物业最该做这件事,也最难做成。因为访谈里那句话会原样兑现:让员工把经验写成 Skill,就像让卤肉师傅按普通月薪交出祖传秘方。

换成物业的说法:你让项目经理把催费的话术、投诉处置的套路、能耗调节的参数整理成公司标准,凭什么?凭那份工资?

反蒸馏、留一手、影子 AI,李宁提到写字楼里已经开始出现这些现象。员工做一部分,把最关键的判断藏起来,工具留在自己的电脑里,只为自己服务。公司的知识资产没有建立起来,个体的议价能力反而抬高了。

这一层,我认为是物业目前最该警惕、而讨论最少的一件事。

五、总部这一层,剩下的价值是什么

访谈往下推进,会遇到一个作者追问了、但李宁没有给出完整答案的问题:组织培养出超级个体之后,往往是组织需要他,他不太需要组织了。公司靠什么留住这样的人?

他给的线索是把员工变成合伙人。律所没有多少固定资产,最宝贵的就是人才,所以合伙制在这些行业已经走通。也不只是钱,还包括这群人愿不愿意一起,做一件认为值得做的事。

这条线索对物业的启发,我认为不在分配形式,而在组织结构的重心——公司这一层,得提供项目自己造不出来的东西。

物业的组织形态一直很特别。项目高度分散,彼此之间几乎没有协作;总部离现场很远,主要靠报表和稽核维持控制。这种结构之所以能长期运转,是因为信息只能靠人往上送,总部是唯一能看见全局的地方。

AI 改变的是这个理由。当片区报表、巡场记录、工单统计可以由工具自动汇总,当总部能实时看到任何一个项目的现场," 我掌握信息 " 就不再是总部的价值来源。

那么总部剩下什么?我看是三样,而这三样恰好指向组织结构的三个调整方向:

第一,标准。生成变得廉价之后,真正稀缺的是 " 什么样的现场算合格 "。这件事项目自己做不了——每个项目都会给自己找理由,只有站在全局的位置,才知道什么是及格线。

第二,数据与场景。一个管家再能干,他手上只有一个小区的数据。能耗曲线怎么调、催费话术哪一句有效、哪几个季度是设备的高故障期,这些判断的质量取决于样本量,而样本量只存在于公司这一层。

第三,专业能力池。电梯大修、消防整改、法务函件、能耗审计,这些事单个项目一年遇不上几次,养不起专人,需要的时候又必须有人。它们天然应该留在中台,按需求调用。

反过来看,如果总部这一层只剩下收报表、催进度、打分排名,那它确实没有存在的必要——因为这些恰好是 AI 最先接管的部分。

所以我的判断是这样:未来三到五年,物业行业最硬的一道分水岭,可能不是管理规模,而是总部这一层到底在给项目提供什么。它提供的如果是项目造不出来的东西,组织就立得住;提供的如果只是监督,那这层结构迟早要被压缩。

落到执行层面,大致是四件事:

四条之中最难的是第三条。前两条属于流程调整,第四条属于职责转换,第三条则要求组织承认一件事——老师傅脑子里那套东西是公司资产,而资产从来不会自动从个人手里走出来。

这一节收尾时想起李宁一句话,我认同:过去效率高、成本低就是竞争优势,如今大家的工作方式已经趋同,大屏幕、语音输入,一台电脑挂五六个项目,差别在于能不能找到新需求。

六、AI 的需求要从一线来,而不是从总部下去

这一节单独说一件事,因为它容易被前面的组织讨论盖过去:物业企业手里握着的,不只是成本和编制。

首先是服务的界面。业主的门口、楼道、车场、设备房,物业是少数能够天天进入这些位置的机构。其次是场景——每天真实发生的报事、投诉、巡检、收费、设备运行,构成了一个高密度、连续、带时间戳的行为现场。

更关键的是场景里的生产要素:一线的员工,长期积累的服务标准,以及把人和标准组织起来的管理动作。这三样,是任何一家技术公司都不具备的,也是物业真正的家底。

我的看法是,把这些简单地让渡出去,是很可惜的。

眼下不少企业的做法仍沿袭传统路径:总部立项,寻找或者孵化一个 " 成熟的 AI 场景解决方案 ",然后培训、推广、考核使用率。这条路的假设是,需求在总部这一端被定义清楚,项目端负责执行。

问题出在这个假设上。总部能说清楚的通常是流程,说不清楚的恰恰是现场最耗时也最磨人的那部分——哪几户必须上门、哪台设备该提前换、哪句话在催费时最好使。这些判断分散在一线的人身上,也只有在具体场景里才成立。

于是自上而下推下去的工具,一线的感受往往不是提效,而是又多了一套要填的系统。使用率靠考核维持,考核一停就回落。

另一条路径正在被一些企业尝试:不在总部定义需求,而是从场景里把需求激活出来。

绿城的灯塔计划是一个例子。它的做法不是采购一套现成的系统,而是把真实项目开放出来,让智慧化公司带着技术进来,在真实场景里验证,再谈合作机制。这一步的价值在于把 " 选型 " 变成了 " 共同试 "。

还有一种做法是面向一线的引导与共创。已经有企业在项目层面组织这样的活动:不先给工具,先问问题——你手上哪件事最烦、最耗时、最没把握;然后一起看这些事里,哪些环节可以先交给 Agent 试一试。

这两种做法的共同点在于把出题权交回给离场景最近的人。

这跟前面几节是连着的。生成不再是瓶颈之后,稀缺的是提出问题的能力;而在物业这个行业里,提出问题的能力主要长在一线。总部要做的不是给答案,是把这些答案接住、沉淀下来、变成公司标准。

七、一个边界:AI 替代不了 " 到场 "

推荐这篇文章,不等于接受它的全部结论。

李宁的整套推演建立在 " 可验证 " 三个字上。数学、代码之所以走在前头,因为有明确的对错。这正是数字世界的特征。他自己也说,农业、制造业同样有设计、有信息流,但还有土地、生产这些部分,AI 可以优化,不等于可以替代。

到了物业,这条边界更硬。

物业的多数工作在物理世界完成。门锁坏了要人到场,电梯困人要人到场,老人摔了要人扶起来,邻里起了争执得有人坐下来谈。这些事里最贵的不是信息流,是那一刻有人站在那里。

所以我的结论是两句话。

物业不会压缩成一家没几个人的公司。

但会被压缩成人少很多、每个人担子重得多的公司。

前一句听着像安慰,后一句才是警告。真正值得担心的从来不是还需要不需要我们,而是留下来的人扛不扛得住被撑大之后的岗位。

八、AI 腾出来的人手,往哪里放

访谈临近结束,聊到一个沉重的问题:如果只需要少量超级个体就能达成想要的收益,剩下的人怎么办。

李宁没有回避。他给的答案乐观,我认同:现在的产品和服务真的饱和了吗?如果企业永远只做眼前这些业务,那确实不需要这么多人。但画一个圈出去,圈外是不是还有很多可以做的事?医疗、教育,大量需求尚未被满足。

他还举了一个小例子。某样东西火了,有人专门帮人安装,这些人未必写得来代码;后来出现安全问题,又有人做卸载服务,还打五折。他由此得出结论:并非人人都能做出突破性创新,但只要创新在持续发生,原有的组织与个人就有机会转向新的方向。

这一段,我想替物业接一句。

这几年行业反复在谈规模见顶、收缴下滑、成本刚性、调价困难,谈到最后是两条默认路径:增收靠多种经营,降本靠减员提效。两条路本身没有错,但减到最后会发现,物业手上压着一摞早就该做、一直人手不足的事——独居老人的日常照看、设施设备的主动养护、社区闲置空间的运营、能耗的精细调节、业主之间那些不上报就无人知晓的小摩擦。

这些事过去没人做,不是因为没有需求,而是抽不出人手,也算不过来账。

AI 最先替物业腾出来的,恰恰就是人手。

所以这篇访谈对物业的意义,我最后想说的不是 AI 会让物业减员,而是这么一句:AI 把每个人的能力边界都往外挪了一截,问题在于你打算让他去干什么。

这不是技术问题,是经营问题。落到人身上,最终是怎么分钱的事。

原文链接:腾讯科技《沸腾之下》第 06 期《中层消失、专家被蒸馏、超级个体单干,公司还需要多少人?|清华李宁》(作者:博阳,2026 年 10 月 21 日)

如果也有兴趣聊,评论区分三件事:你们的项目经理一天有多少时间花在开会与协调上;你们总部这一层有多少人,其中多少在做报表和稽核;以及,明天给你五个 Agent,你会先让它们干什么。

智客推

智客推

ZAKER 智客推 GEO | AI 时代的品牌认知解决方案

一起剪

一起剪

ZAKER旗下免费视频剪辑工具

相关标签

ai 李宁 腾讯科技 技能 数据库
相关文章
评论
没有更多评论了
取消

登录后才可以发布评论哦

打开小程序可以发布评论哦

12 我来说两句…
打开 ZAKER 参与讨论