文章目录前言一、瓶颈不在节点在边1. Amdahl定律你的天花板早就被写死了2. Brooks法则加人只会让项目更晚3. 约束理论堵车的永远是最窄的那条路三条定律同一个结论二、把等回复变成自己动手传统协作模式同步阻塞Skill化协作模式异步自助新旧模式对比具体怎么落地如果你是Leader如果你是个人开发者关于70分陷阱三、写在最后一句话总结P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01前言—— 本质是个分布式系统问题但咱们换个姿势聊周五下午五点产品经理在群里甩了一句“这个文案能今天出吗”设计回“今天排不上最快下周一。”消息就挂在那儿像博物馆里的文物没人敢碰。直到下周一它才被重新挖出来。 这一幕过去一年里每个用上AI的团队都见过。区别只是以前等三天现在有了AI个人效率飙升了十倍但——你猜怎么着——等的还是三天。就像你买了辆法拉利然后发现堵在高速上旁边那辆五菱宏光跟你并驾齐驱。速度不存在的大家一起看尾灯。这半年我聊了七八个AI-native创业团队和大厂内部的人答案出奇一致个人workflow被AI加速了3到10倍但整个团队的产出周期几乎纹丝不动。有的团队更惨多了一层review AI产出的环节交付周期反而变长了。这就好比你请了个保姆结果每天多了一项检查保姆有没有把碗洗干净的工作净增负收益。 十年前我读《人月神话》和分布式系统论文觉得那是给程序员看的。现在发现把团队换成分布式系统把人换成节点把部门墙换成网络延迟——好家伙原封不动直接套用。Brooks老爷子要是活到今天估计会拍大腿“我当年写的不是软件工程是预言书啊”今天聊两件事为什么人均10x组织却只有1.2x以及具体能干点啥一、瓶颈不在节点在边把一个组织想象成一张有向图。每个人是一个节点。每一次review、对齐、审批是连接节点的一条边。给每个人配AI干的是啥是把节点的处理速度提升了10倍。但边呢完全没动。 这就好比你去健身房练出了八块腹肌但每天上班还是坐那辆挤成沙丁鱼罐头的地铁。你个人很强但通勤时间一分没减。公司不是没变强是强的部分和慢的部分不在同一个次元。组织的整体吞吐量恰恰是由边决定的不是由节点决定的。下面三条老定律能把这个判断精确量化。1. Amdahl定律你的天花板早就被写死了先说结论哪怕个人被加速到无穷快组织整体的加速比也有一个数学上的硬天花板。这个天花板由必须靠协作完成、不能一个人搞定的那部分工作占比决定。S(n) 1 / [(1-p) p/n]其中p是可并行部分一个人能独立完成的占比n是AI加速倍数。关键在极限lim S(n) 1/(1-p)当 n→∞也就是说无论n多大整体加速比永远冲不破1/(1-p)这条线。 举个例子review、对齐、跨部门审批占了40%的时间p0.6。那就算你个人被AI加速到光速组织整体加速比封顶在2.5倍。注意这是理论上限实际情况通常更惨。就像你买了张头等舱机票结果飞机延误八小时你坐在真皮沙发上跟经济舱的兄弟一起刷手机殊途同归。p0.5协作占50%整体加速比封顶在2倍附近。p0.7协作占30%封顶在3.3倍附近。p0.9协作占10%封顶在10倍附近。这才是人均10x组织仅1.2x背后的数学真相。 有个朋友跟我说他们团队给全员配了Copilot结果季度复盘发现交付速度只快了15%。老板脸都绿了质问我花这么多钱就这点回报工程师默默打开Amdahl定律的公式说老板这不是预算问题这是数学问题。老板沉默了三秒说“那数学能打折吗”但这里有个容易被忽略的角度p不是天生固定的。AI真正厉害的地方可能是把原本必须跨部门商量的事变成一个人可以独立判断完成的事——也就是提高p本身而不只是加速n。这也是为什么后面讲的给上下游做skill本质上是在做提高p这件更难但更有效的事。2. Brooks法则加人只会让项目更晚Fred Brooks在《人月神话》里讲过一个反直觉的结论给一个delay的项目加人只会让它更晚交付。原因是n个人之间的沟通路径数是n(n-1)/2呈平方增长。 3个人的团队沟通路径是3条。10个人的团队是45条。50个人的团队是1225条。这就是为什么大公司开会像联合国大会——每个人都要发言每个人都要听懂时间就这么没了。你以为加人是在加生产力其实是在加微信未读消息的数量。AI让单个节点算得更快但n(n-1)/2条沟通边一条没少。你配了AI只是让每个人发微信的速度变快了但微信的数量没变。3. 约束理论堵车的永远是最窄的那条路高德拉特在《目标》里的核心结论优化非瓶颈资源只会在瓶颈前堆积更多在制品不会提升系统整体吞吐。如果评审节点是瓶颈给上游的人配AI只会让待评审队列变长。 这就好比高速收费站只有一个窗口开着你前面那段路修成了八车道。车是跑得更快了但到了收费站全堵在那儿。八车道的意义只是让堵车的地方看起来更有气势。你坐在车里看着旁边车道的大哥大家相视一笑都是天涯沦落人。怎么找到真正的瓶颈最朴素但最有效的方法花一周给每个跨团队协作环节记一笔——这件事发出去之后等了多久才收到第一次回应。不是处理时长是等待时长。把数字摆在一起最长的那几项几乎无一例外就是真正的瓶颈。 我试过一次记录了一周。结果发现我们团队最大的瓶颈不是技术评审不是测试是等法务看合同。平均等待时长72小时。技术评审平均等待时长4小时。那一刻我明白了我们以为自己在做互联网产品其实做的是法务周边产业。三条定律同一个结论定律结论对应现象Amdahl定律加速比被不可并行部分封顶Review/对齐天然串行个人AI碰不到Brooks法则协作成本按n(n-1)/2增长配AI没有消除任何一条协作边约束理论吞吐量瓶颈吞吐量加速非瓶颈只会在瓶颈前堆积队列AI要真正提升组织效率得作用在边上——也就是人与人之间的依赖——而不是继续往节点上加码。 这就跟减肥一样。你练出了肱二头肌但体脂率没变穿衣服还是显胖。公司也一样每个人都很强但协作链路还是那坨脂肪。减脂比增肌难因为增肌是自己能控制的减脂得改变整个生活方式。如果你在的是几个人的小团队不涉及跨部门审批这套框架依然成立——只是边从部门之间的协作依赖变成了你自己脑子里在开发、设计、运营几个角色之间来回切换的成本。个人身兼数职时真正拖慢你的往往不是任何单项工作本身变慢了而是切换角色、等外部反馈的那些空隙。二、把等回复变成自己动手“给上下游做skill”说到底是一次很具体的改造把一次没有约定规则的等待改造成一个有明确输入输出的自助接口。传统协作模式同步阻塞“设计团队做需求 → 排期 → 交付”这条链路本质上是市场团队发出请求后原地等待。响应时间取决于对方的排期和优先级完全不可控。 这就像你去餐厅点菜厨师说今天太忙了你的菜最快下周上。你问能不能自己做厨师说厨房重地闲人免进。于是你坐在那儿一边刷手机一边等顺便给这家店打了一颗星。职场版的一星差评就是离职。Skill化协作模式异步自助破解办法业内早有成熟路径——把能力服务化让请求方自己动手而不是排队等对方动手。拆开看几个例子都是同一件事的不同实例设计团队给市场团队一个能自助出物料的skill → 把设计能力变成自助接口研发团队给设计团队一个能做高保真原型的skill → 把前端渲染能力变成自助接口数据团队给业务方一个能自助查数建看板的skill → 把数据查询能力变成自助接口 这不是在削弱上游团队的专业价值是在把上游的能力接口化。就像星巴克把咖啡机做成自助点单机你依然需要咖啡师来拉花但点单这件事你自己就能搞定。咖啡师终于不用一边做咖啡一边回答有WiFi吗了。二十年前亚马逊做过一次几乎相同的事。2002年贝索斯发了一份内部备忘录后来被称为Bezos API备忘录要求所有团队必须通过标准接口对外暴露功能不允许团队间私下绕过接口沟通违反者会被解雇。这次改造后来演化出了AWS。 贝索斯当年的逻辑很简单如果两个团队不能通过API沟通那他们就不该沟通。听起来很霸道但效果拔群。今天不一样的是当年靠CEO强制令才能推动的服务化改造现在写一个skill的边际成本已经低到可以自发去做。你不需要等一份行政命令你只需要一个周末、一个Cursor账号、和一颗不想继续等回复的心。新旧模式对比传统模式Skill化模式市场团队发起需求设计团队发布Skill / Agent进入设计团队排期队列排队3天市场团队自助调用即时响应等待设计团队处理延迟未知Agent产出70分结果交付物料是否需要专业判断是→设计团队Review否→直接交付核心变化把排队等别人做变成自己动手专业判断兜底。 70分的结果对很多场景够用了。市场团队要的是今天能用的海报不是明年能得红点奖的设计。如果事事都要100分那你的组织速度就永远卡在100分的那个节点上。先让火车跑起来再考虑要不要换头等座。具体怎么落地如果你是Leader识别高频阻塞点统计过去一个月团队花在等别人上的时间占比。超过30%的优先考虑skill化。定义清晰的输入输出一个合格的skill必须有明确的输入格式和输出标准。模糊的需求只会产出模糊的结果。设置质量闸门不是完全放手而是先自助后review。把review从必经之路变成质量保险。 有个技术Leader跟我吐槽说团队做了skill结果业务方用得一塌糊涂产出质量参差不齐。我问他你写文档了吗他说写了在Confluence里。我问业务方会看Confluence吗他沉默了。Confluence在大部分公司里的作用跟图书馆的绝版书差不多——存在但没人翻。如果你是个人开发者给自己做skill把重复性的工作写周报、整理会议纪要、生成测试数据封装成skill减少上下文切换。给上下游做skill如果你发现别人总在等你主动提供一个自助接口。这看起来是在给自己增加工作量实际上是在减少未来的沟通成本。接受70分不是每件事都需要做到100分。先完成再完美。完美是完成的敌人也是效率的杀手。 我认识一个全栈工程师给自己写了一个需求转技术方案的skill。产品经理丢过来一句话需求skill自动输出技术方案草稿、接口定义、甚至测试用例。他说“以前一个需求我要跟产品经理来回扯三天现在三小时出初稿剩下的时间用来争论’这个按钮到底放左边还是右边’——至少争论的是具体的事不是空气。”关于70分陷阱很多人担心skill产出的质量不够高会不会反而增加review成本答案是会但前提是你没有设置质量闸门。正确的做法是明确哪些场景可以用70分版本直接交付内部海报、临时数据看板、非核心文案明确哪些场景必须走人工review对外品牌物料、关键数据口径、法律相关文本让skill自己告诉你这个请求超出了我的能力范围建议转人工 这就跟自动驾驶一样。L2级别辅助驾驶你依然需要手扶方向盘但它确实减少了你的疲劳。你不能因为它不能帮你洗澡就说它没用。Skill也是一样它不能替代专业判断但能把专业判断从每单必做变成抽检即可。三、写在最后人均配AI但没变快不是因为AI不够强是因为我们还在用旧地图走新路。分布式系统的三条老定律告诉我们加速节点是加法减少边是乘法。而组织效率的提升从来不是靠加法。 最后讲个真事。有个团队全员配了AI半年后复盘发现个人效率确实提升了但团队交付周期没变。老板问为什么工程师说因为我们把省下来的时间用来开了更多会。老板问什么会工程师说AI使用经验分享会。老板当场石化。这就是典型的技术解决了旧问题人类创造了新问题。而且新问题还自带PPT。给上下游做skill不是在削弱谁的价值是在重新定义协作的边界。让该自助的自助让该专业的专业。把等待变成接口把阻塞变成异步。这才是AI时代组织效率的真正解法。一句话总结个人加速是买跑车组织加速是修高速。跑车再快没路也是白搭。与其继续给每个人换更贵的跑车不如先把协作链路从羊肠小道修成高速公路。 当然如果你非要一边堵车一边在车里用AI写PPT那至少你堵车的时候生产力提高了。这也是一种胜利只是比较心酸。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01