惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Apple Machine Learning Research
Apple Machine Learning Research
J
Java Code Geeks
博客园 - 聂微东
Microsoft Azure Blog
Microsoft Azure Blog
量子位
T
Tailwind CSS Blog
Vercel News
Vercel News
I
InfoQ
Stack Overflow Blog
Stack Overflow Blog
U
Unit 42
Engineering at Meta
Engineering at Meta
L
LangChain Blog
大猫的无限游戏
大猫的无限游戏
D
Docker
博客园_首页
P
Proofpoint News Feed
月光博客
月光博客
T
The Blog of Author Tim Ferriss
MyScale Blog
MyScale Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
Martin Fowler
Martin Fowler
腾讯CDC
N
Netflix TechBlog - Medium
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
你的员工都在用AI了,为什么组织生产效率没变?
常超 · 2026-03-26 · via 人人都是产品经理

AI时代个体效率的爆发式增长与组织效率的停滞形成鲜明对比,这让人想起电气革命初期的生产力悖论。从福特流水线的历史经验到现代企业AI应用的困境,本文深入探讨当执行成本骤降时,组织如何重构工作流程与管理模式,才能避免成为『装着电动机的蒸汽机工厂』。关键洞察在于:定义问题与对齐目标的能力,正取代执行力成为新的核心竞争力。

最近一个月,身边越来越多人感慨奇点到来了。LLM和Agent成熟之后,用好的人效率提升很夸张。

夸张到什么地步呢?OpenClaw这个开源项目,近40万行代码、GitHub近20万Star,一个人3个月写出来的。

放到24年,一个20人的研发团队干3个月也不一定有这个产出。

但我也遇到一个真实的困惑:

个体效率确实飙升了,但组织的产出效率,远远达不到预期。

带着这个困惑,我去翻了一段历史,电气革命。发现一百多年前,人们踩过一模一样的坑。

01. 电气革命里被浪费的几十年

1880年代,电动机开始进入工厂。

当时人们觉得,电力比蒸汽高效太多了,未来一定属于电力。

结果呢?到了1900年,电动机只占美国工厂机械动力的不到5%。

不是电动机不好用。是大部分工厂做了一件看起来特别合理的事:把蒸汽机拆了,装上电动机,其他啥也没改。

工厂布局没动,还是围绕一个中央动力源设计的,所有机器靠传动轴和皮带连在一起。岗位分工没动。管理方式没动。

工人是轻松了一些,但整体产量就那样。

经济史学家Paul David专门研究过这个现象,管它叫生产力悖论:技术明明到了,生产力就是不涨。

02. 像不像你们公司现在的样子?

我自己观察下来,现在绝大多数公司做的事情,本质上就是「给员工发一个AI账号」

Cursor 买了,Claude 会员开了。员工确实快了,代码写得快了,文案出得快了,PPT做得快了。

然后呢?

说句不太好听的:效率提升省出来的时间,很大一部分变成了摸鱼时间,甚至人变懒了,有些人AI用的不好,导致质量还下降了。

岗位职责没变,协作流程没变,汇报关系没变,绩效考核没变。个体快了,但组织的瓶颈还卡在那。

以前,写代码贵、出设计贵、做PPT贵,所以组织的核心工作是:把执行任务分配好、协调好、管理好。

AI来了以后,执行变得很便宜了。一个人加AI能写以前五个人的代码。

那什么变贵了?

我觉得是想清楚做什么

定义一个有价值的问题、想清楚该怎么解决、让团队理解并对齐。这些能力突然变得比执行重要得多。

但大部分组织的结构,还是为「管理执行」设计的。

层层审批是为了管执行质量,细化分工是为了管执行效率,周报月报是为了管执行进度。

当执行不再是瓶颈的时候,这些东西不只是多余,可能还在挡路。

跟一百年前的工厂一样:换了个动力源,生产线还是老样子。

03. 当年福特做对了什么?

电气革命里,第一个真正吃到红利的是福特。

1913年,福特在Highland Park工厂搞出了流水线。

这条流水线能成,不是因为福特的电动机比别人好。是因为他想明白了一件事:电动机和蒸汽机有一个本质区别。每台机器可以有自己独立的电动机,不用再通过传动轴串在一起。

蒸汽机时代,工厂的布局是被动力传输方式决定的。所有机器必须围着中央蒸汽机转,用传动轴和皮带把动力送过去。怎么排机器、工人站哪里,不是按效率来的,是按「离动力源近不近」来的。

福特反过来想:既然每台机器可以独立供电了,那设备可以完全按照生产流程来排。于是他从零设计:设备顺着流程排,传送带连接每个工位。

结果:一辆车的组装时间从12.5小时干到93分钟。1923年,福特一家就占了美国汽车市场60%以上的份额,全球超过一半的注册汽车都是福特。

不是因为他更早用了电动机。是因为他围绕电动机的特性,把工厂重新设计了一遍。

04. 执行便宜了,然后呢?

现在AI对个体的放大已经很夸张了。一个人写40万行代码,一个人做出以前一个团队才能做出的产品。

但大部分组织还在「换动力」,配了AI工具,组织本身纹丝不动。

我最近反复在想的一个事是:AI让「做事」变便宜了,但「想清楚做什么事」并没有变便宜。甚至因为能做的事变多了,选择变难了,这部分反而更贵了。

以前的组织,本质是一台「执行机器」。老板想清楚做什么,然后拆解成任务,分配给不同的人去执行。组织的效率 ≈ 执行的效率。

执行被AI大幅提速了,但「想清楚做什么」这一步没有被提速。甚至因为执行速度快了,能在更短时间内生产出更多的垃圾。

AI时代组织真正需要的能力变了:

  • 以前最重要的是执行力,能不能把想好的事做出来
  • 现在最重要的可能是定义问题,能不能想清楚什么事值得做、问题到底是什么
  • 以及对齐能力,组织能不能让每个人理解为什么做这件事,而不只是分配任务

05. 我自己的一些摸索

我们团队10个人做「月见APP」,AI确实帮了很大的忙。

但我越来越觉得,省下来的「执行时间」有没有变成「思考时间」,才是关键。很多时候没有。大家做得更快了,但不一定想得更清楚了。包括我自己。

所以,我最近打算做一个比较大的调整:取消前端、客户端、后端这样的技术分工,也取消产品和技术的分工。

为什么?因为在AI的加持下,每个人都可以突破自己原来的边界。我是产品经理出身,现在借助AI能做一些基础开发。同样,过去的程序员也完全可以借助AI完成基础的产品工作,比如调研竞品、分析需求、设计方案。

具体一点说,我打算用管理业务的方式来管理团队,每个人都背具体的业务目标。

比如,以前的「前端工程师」,以后的职责不再是「完成产品经理写的需求」,而是「负责APP的分享传播」。他要自己去调研竞品怎么做分享、想清楚我们该怎么做、跟客户端设计协作、自己写分享的H5或小程序。责任不再是把需求做完,而是拿到业务结果。

这背后的逻辑跟前面讲的是一回事:执行便宜了,「想清楚做什么」才是瓶颈。

如果还是老板/产品经理想、员工干,那瓶颈全压在了老板/产品经理身上。让每个人都参与到「定义问题」和「定义价值」里来,组织才能真正用好AI带来的执行效率。

很多先进团队已经这样做了,我已经觉得自己慢了。也在反思,为什么我慢了。因为最开始我有顾虑,要求大家做更多的事,又不涨工资,这似乎不太对。但现在我觉得,如果我不推着大家改变和成长,大家反而会逐渐被这个时代淘汰。那才是真正的不负责。

当然,这也只是我的一种尝试,做下去可能会发现新的问题。但至少方向上,我觉得「让每个人都成为业务的 owner,而不只是执行者」,可能是AI时代组织变革的一个关键。

06. 不会再有40年了

电气革命从1880年代到1920年代福特碾压同行,中间隔了差不多40年。

那时候变化慢,工厂有的是时间慢慢适应。

AI不会给这个时间。技术迭代的速度跟一百年前完全不是一个量级。以前有40年,现在可能只有一两年,甚至是半年。

我觉得最危险的状态不是「没用AI」,而是「用了,但什么都没变」。因为你觉得自己已经跟上了,就不再想这件事了。

就像1900年那些装了电动机的工厂主,觉得自己已经拥抱新技术了。二十年后被福特碾过去的时候,他们可能还没反应过来。

工具到了。但工具解决的是执行。

真正的瓶颈已经悄悄换了。

参考资料

  • Paul David, 「The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox」(电气革命生产力悖论的经典论文)
  • Gains from factory electrification: Evidence from North Carolina, 1905–1926[1]
  • Ford 官方历史:The Model T[2]
  • History.com: Moving assembly line debuts at Ford factory[3]
  • Wikipedia: Ford Model T[4]

References

[1]https://www.sciencedirect.com/science/article/abs/pii/S0014498325000014

[2]https://corporate.ford.com//articles/history/the-model-t/

[3]https://www.history.com/this-day-in-history/moving-assembly-line-at-ford

[4]https://en.wikipedia.org/wiki/Ford_Model_T

作者:常超,月见万物 Founder&CEO ,公众号:常超

本文由 @常超 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Pexels,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务