人均配了AI, 为什么公司还是没变快? 🤔 本质还是分布式系统问题

HiSt
0 阅读14分钟

一句话概括:给个人配AI能加速3到10倍,但组织整体的产出周期几乎不变——问题不在"人"这个节点上,在"人和人之间的协作依赖"这条边上。这篇文章用三条分布式系统的老定律讲清楚原因,再给一套不管你是leader还是个人开发者都能上手的具体做法。

周五下午五点，一个产品经理在群里发了句"这个文案能今天出吗"，

设计说"我这边今天排不上，最快下周一"。

这条消息挂在那里，没人 catch，直到下周一。这一幕，大概是过去一年里，每个用上了 AI 的团队都见过的场景——只不过它发生的频率，并没有像大家期待的那样，随着人均效率的提升而降低。

这不是个例。这半年问了几个 AI-native 创业公司和大厂内部团队，答案高度一致：个人的 workflow 被 AI 加速了 3 到 10 倍，但整个团队的产出周期几乎没有变化。有的团队甚至因为多了一层"review AI 产出"的环节，交付周期反而更长了。

这件事让我想起十几年前读《人月神话》和分布式系统论文时学到的几条老定律。

当时觉得那是讲"软件项目管理"的，现在发现，

  • 把"团队"换成"分布式系统"；
  • "人"换成"节点"；
  • "部门墙"换成"网络延迟"；

这几条定律几乎可以原封不动地套用在今天的 AI 组织效率问题上。

这篇文章想讲清楚两件事：为什么人均 10x 换不来组织 2x，以及具体应该怎么办。

一、瓶颈不在节点，在边

把一个几千人的组织想象成一张有向图：每个人是一个节点，每一次 review、对齐、审批，是连接节点的一条边。给每个人配 AI，做的事是把节点的处理速度提升了 10 倍，但完全没有动边。而组织的整体吞吐量，恰恰是由边决定的，不是由节点决定的。这个判断，可以用三条经典定律精确量化。

截屏2026-07-03 12.13.39.png

1. Amdahl 定律：加速比被不可并行部分死死封顶

结论先说：哪怕个人被加速到无穷快，组织整体的加速比也有一个数学上的天花板，这个天花板由"不能被个人独立完成、必须靠协作完成"的那部分工作占比决定。

想看推导的可以展开这一段，只想要结论的可以直接跳到下一条定律。

Amdahl 定律给出的加速比公式是：

S(n)=1(1−p)+pnS(n) = \frac{1}{(1-p) + \dfrac{p}{n}}

其中 pp 是任务里可以被个人独立完成、可并行加速的部分，nn 是这部分被 AI 加速的倍数。关键在于极限：

lim⁡n→∞S(n)=11−p\lim_{n\to\infty} S(n) = \frac{1}{1-p}

举个例子：如果 review、对齐会议、跨部门审批占了工作总时长的 40%（即 p=0.6p=0.6），那无论个人被 AI 加速多少倍，组织整体加速比封顶在 2.5 倍——这还是理想情况，实际很多团队的不可并行部分远超 40%。

Amdahl定律.png

这里有个容易被忽略的角度，值得多想一层：pp 不是天生固定的常数。

AI 真正厉害的地方，恰恰可能是把原本必须跨部门商量的事，变成一个人可以独立判断完成的事，也就是提高 pp 本身，而不只是加速 nn。这也是为什么本文后半段讲的"给上下游做 skill"，本质上是在做提高 pp 这件更难但更有效的事，而不是继续在 nn 上加码。

2. Brooks 法则：协作成本按组合数增长，不是按人数线性增长

Fred Brooks 在《人月神话》里讲过一个反直觉的结论：给一个 delay 的项目加人，只会让它更晚交付。

原因是 nn 个人之间需要维护的沟通路径数是 n(n−1)2\dfrac{n(n-1)}{2}，呈平方增长。

这条定律解释了为什么"给个人配 AI"根本没碰到问题的根——AI 只是让单个节点算得更快，节点之间要维护的 n(n−1)/2n(n-1)/2 条沟通边，一条没少。

3. 约束理论：系统吞吐量，等于瓶颈的吞吐量

高德拉特在《目标》里的核心结论是：优化非瓶颈资源，只会在瓶颈前堆积更多在制品，不会提升系统整体吞吐。如果某个评审节点是瓶颈，给瓶颈上游的人配 AI，只会让"待评审队列"变长——上游产出速度上去了，下游处理速度没变，队列积压，整体交付周期不但没缩短，有时反而更长。

怎么找到那个真正的瓶颈？ 最朴素但最有效的方法，是花一周时间，给团队里每个跨团队协作的环节记一笔：这件事发出去之后，等了多久才收到第一次回应。不是处理时长，是等待时长。把这些数字摆在一起，排在最长的那几项，几乎无一例外就是真正的瓶颈——它们往往不是你以为的那个环节。

三条定律指向同一个结论：

定律结论对应现象
Amdahl 定律加速比被不可并行部分封顶Review/对齐天然串行，个人 AI 碰不到这部分
Brooks 法则协作成本按 n(n−1)/2n(n-1)/2 增长配 AI 没有消除任何一条协作边
约束理论吞吐量=瓶颈吞吐量加速非瓶颈只会在瓶颈前堆积队列

AI 要真正提升组织效率，得作用在边上——也就是人与人之间的依赖——而不是继续往点上加码。

如果你在的是一个几个人的小团队,不涉及跨部门审批,这套框架依然成立——只是"边"从"部门之间的协作依赖",变成了"你自己脑子里,在开发、设计、运营几个角色之间来回切换的成本"。个人身兼数职时,真正拖慢你的往往不是任何单项工作本身变慢了,而是切换角色、等外部反馈(客户回复、甲方确认)的那些空隙,道理是一样的。

二、把"等回复"变成"自己动手"：一次服务化改造

"给上下游做 skill"，说到底是一次很具体的改造：把一次没有约定规则的等待，改造成一个有明确输入输出的自助接口。

"设计团队做需求 → 排期 → 交付"

这条链路，本质上是市场团队发出一个请求后，原地等待——响应时间取决于对方的排期和优先级，完全不可控。这是效率问题里最常见的一种模式：请求方没有选择，只能等。破解它的办法，业内早就有成熟路径——把能力服务化，让请求方可以自己动手，而不是排队等对方动手。

原文里几个例子，拆开看都是同一件事的不同实例：

  • 设计团队给市场团队一个能自助出物料的 skill，等于把"设计能力"变成了一个自助接口
  • 研发团队给设计团队一个能做高保真原型的 skill，等于把"前端渲染能力"变成了自助接口
  • 数据团队给业务方一个能自助查数建看板的 skill，等于把"数据查询能力"变成了自助接口

这不是在削弱上游团队的专业价值，是把上游的能力接口化了。

二十年前，亚马逊就用行政命令做过一次几乎相同的事——2002 年，贝索斯给全公司发了一份内部备忘录（后来在业内被称为"Bezos API 备忘录"），要求所有团队必须通过标准接口对外暴露功能，不允许团队间私下绕过接口沟通，违反者会被解雇。这次改造，后来演化出了 AWS。

今天不一样的地方是：当年靠 CEO 的强制令才能推动的服务化改造，现在写一个 skill 的边际成本已经低到很多团队可以自发去做，不需要等一份行政命令。

截屏2026-07-03 12.56.35.png

大型组织很难一夜转型成"按 loop 组织"的结构，但有一条更现实的路径：不用先推翻组织架构，先让局部团队之间产出服务化的接口，协作路径会先在局部变成自助的样子，组织结构会被这些实际跑起来的路径，慢慢"拽"着重排。不需要等一次自上而下的重组，先把接口发出去，重排就已经开始了。

这个思路和 Shrivu Shankar 在《The Transposed Organization》里提出的"loop"概念一脉相承——他把这种组织形态定义为"一个人拥有从问题到部署方案的完整决策链"，专家的角色从直接执行转向把判断力编码进 agent 可用的规范里。这和本文说的"上游从工单处理者变成规范所有者"，讲的其实是同一件事的两种说法。

三、"教会同事，会不会取代自己"

这是推行这件事时最大的心理阻力，值得单独讲清楚机制，而不只是给一句"别担心"。

传统协作是一个工单模式：下游发一张工单，上游按队列处理，处理完关单。这个模式里，上游的价值等价于"处理了多少张工单"——人力越稀缺，价值越显性，但也越容易在流程被标准化之后，第一个被自动化替代。

Skill 把这个模式换成了 PR 模式：下游直接调用 skill，自己先把事情做到七十分，上游不再是"从零处理请求的执行者"，而是规范的所有者——定义准则、审核关键改动、决定要不要把新的判断规则合并进主干。Anthropic 内容设计团队做的 Clontent（一个专门协助生成产品内容文案的内部 agent），走的就是这条路：团队成员每周投票决定要不要把新规则写进 agent 的长期记忆，agent 遇到"起名字"这类超出内容团队职责的事，会主动叫人来判断——这不是执行者会做的事，是规范所有者才会做的事。

维度工单模式（旧）PR 模式（新）
上游角色请求处理者规范/接口的所有者
价值体现方式处理了多少张工单定义了多少条被下游复用的规则
稀缺性来源人力有限判断力稀缺
对自动化的抵抗力弱强

这也是为什么 Chelsea Larsson（Anthropic 内容设计团队的成员，Clontent 项目的主要推动者之一）会说，因为 Clontent，公司内部有远比以前多的人了解了"内容设计"这个职能——她没有把自己变成一个被工单吞掉的执行者，而是把自己升级成了内容规范背后的那个人。下游用得越多，规范制定者的存在感和影响力就越强，不是越弱。

截屏2026-07-03 12.56.50.png

这里有个容易被忽略的前提：PR 模式能跑起来，是因为它不要求每一次都做到满分。

七十分的草稿，加一个足够便宜的人工合并机制，吞吐量会远高于追求满分但需要排队等待的处理方式。这也是为什么"agent 只要做到七十分就有价值"这句话，不是在降低标准，而是在换一种更高效的质量控制方式。

四、什么时候不该做 skill 化

前面讲的都是这件事的好处，公允地说，它也有明确的边界，不是所有环节都值得投入。

判断依据、而不是执行动作的环节，先别急着 skill 化。 比如涉及价值判断、需要为结果承担责任的决策（要不要发布一个有争议的功能，要不要为一个客户破例），这类环节的核心难点不是"处理速度慢"，是"谁来负责这个判断"，skill 在这里帮不上什么忙，硬做只会制造一种"看起来自动化了、实际责任更模糊"的假象。

协作频率本身很低的环节，投入产出比不划算。 如果某个协作节点一个月只发生两三次，花精力做一个 skill、维护它的边界 case，成本可能比它节省的时间还高。这条建议看起来朴素，但恰恰是很多团队推行 skill 化时最容易忽略的一步——先看频率，再决定值不值得做。

没人维护的 skill，会比没有 skill 更糟。 skill 不是做完就一直好用的东西，业务规则会变，边界 case 会累积，如果没有人持续更新它，几个月后它给出的答案会开始悄悄地错，而且因为大家已经习惯了自助调用、不再走人工审核，这种错误反而更难被发现。这是所有"自助化"改造共同的风险，值得在推行之初就想清楚谁来维护、多久 review 一次。

五、具体怎么落地

这套框架不管你在什么角色上,都能找到能立刻上手的动作,按角色拆成了两份清单。

如果你是 leader / 有组织决策权

  • 先测等待时长，再决定做哪个 skill。 花一周记录每个跨团队协作环节的等待时长，排在最长的那几项，才是真正值得优先做的。
  • skill 的目标是七十分，不是一百分。 覆盖最常见、最标准化的场景就够了，剩下需要专业判断的部分，保留一个"主动喊人"的机制。
  • 把这件事变成明确的工作产出，不是隐性劳动。 给上下游做 skill 这件事，大概率不在任何人的 KPI 里，容易被一拖再拖。靠自己自上而下推动，或者设一个专门的角色去做这件事，比指望个人自发靠谱得多。
  • 定一个维护节奏。 哪怕只是每月看一次 skill 的输出有没有开始跑偏，这个动作决定了它是长期有用，还是三个月后变成一个没人敢关但也没人信的黑箱。

如果你是个人贡献者 / 小团队,没有组织决策权

  • 先从"自己"开始,不用等公司推动。 找出你自己每周被同一个人/同一个环节反复卡住的那件事(比如总是要等设计师改文案排版,或者总是要手动导一份数据表),先做一个只服务你自己的最小化 skill——一个脚本、一个 prompt 模板、一份填空式文档都算。
  • 做完一次,就把它变成一个"能复用的东西"。 哪怕只有你和身边两三个同事在用,只要它把"等对方回复"变成了"自己动手",这件事的性质就已经从"个人小技巧"变成了一个雏形接口——这正是本文说的"边"被拆掉的最小单位。
  • 不用追求完美,先解决自己的问题。 不需要一开始就想着"给全公司做标准化工具",能稳定省下你自己每周几小时的等待时间,这件事就已经值得做,后面自然会有人来问你"这个东西能不能也给我用"。

结语

节点与边.png

人均 10x 没有换来组织 10x，不是因为 AI 不够强，是因为我们把 AI 用在了错误的地方——用在了点上，而组织真正的瓶颈，一直都在边上。

给自己配 AI，优化的是一个节点；

给上下游做 skill，拆的是一条边。

这件事不需要等一次自上而下的组织重组才能开始——不管你是团队 leader 还是个人开发者，现在就可以先把自己的一部分能力，变成一个别人可以自己动手用的接口。

那条消息不用再挂在群里等到下周一了。这才是真正的开始。

六、参考文档

  • Fred Brooks, The Mythical Man-Month（人月神话），1975
  • Gene Amdahl, "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities", 1967
  • Eliyahu M. Goldratt, The Goal（目标），约束理论（Theory of Constraints）出处
  • Shrivu Shankar, The Transposed Organization，Shrivu's Substack, 2026.03 —— 本文第二节"按 loop 组织"部分的概念来源
  • Anthropic Clontent / Chelsea Larsson 相关案例来源
avatar
文章
阅读
粉丝