一段16秒的现场视频，最近在硅谷刷屏。
画面里,Anthropic 首席执行官 Dario Amodei 坐在浅色沙发上，语气轻松地说:内部模型加速之后，工程师能写出两倍、四倍、甚至五倍的代码。
这正是所有人烧钱买 AI 编程工具想要的结果。
但话没说完，他顿了一下，又添了一句:
"But then you see what breaks."
“但接着，你就会看到哪里崩了。”
创业者与投资人 Karl Mehta 把这段话剪出来发上 X,并将这个反常识的现象浓缩成:团队以为编码提速5倍，就等于公司提速5倍。
阿姆达尔定律说，系统里没被加速的部分，才是真正的天花板。
这背后藏着一件更大的事，一条1967年算处理器该不该多加的老公式，正被拿来解释2026年最烧钱的技术焦虑:AI明明让写代码快了这么多，公司为什么感觉不到?
阿姆达尔定律到底在算什么
计算机科学家 Gene Amdahl 在1967年提出这条定律，回答的问题很朴素:给机器多加几个处理器，程序会不会等比例变快?
答案是冷水:不会。
程序里总有一部分工作没法并行，那部分卡多久，整个程序就得等多久，加多少处理器都救不了它。
公式写出来是:
S_{\text{overall}} = \frac{1}{(1-p) + \frac{p}{s}}
(p) 是能被加速的工作占比,(s) 是这部分被加速的倍数。
翻译成人话:整体能快多少，取决于你没碰过的那一块占了多大比例，能加速的部分做到无限快也没用，没碰过的那块，原样卡在原地。
代入数字最直观:写代码若只占交付链路20%,AI把它压缩到瞬间完成，整体也最多快到 (1/0.8=1.25) 倍，即约25%。
把"处理器并行"换成"AI写代码",公式几乎原样成立。
可加速的是脚手架、样板代码、简单重构、草稿文档;难加速的是架构取舍、代码评审、集成测试、安全合规、产品签核。
AI把前半段捶得飞快，后半段那种"卡脖子"的感觉，立刻就冒了出来。
一个工程师的一天，亲眼看着"提速"变成"堵车"
数字还是抽象的。 Atlassian 工程管理团队讲过一个具体到分钟的故事，把定律还原成日常恐怖片。
主角叫 Maya,资深工程师，全程用 AI 辅助工作。
上午9点她与AI敲定技术路线，只用20分钟，放在AI之前得花半天。
9点半AI搭好代码骨架、写好测试,11点前一个PR已躺进评审队列，放在AI之前通常要两天。
Maya 感觉状态爆棚。
问题是，评审人 Tom 昨天的队列还没清完，里面已有两条也来自Maya,他整个上午都在开会。
Maya开始下一个功能，下午1点第二个PR又提交，一天之内三条评审同时压进队列。
下午2点Tom总算坐下评审，每一条都要重新拼凑上下文，来回切换认知负担层层叠加。
下午4点，昨天那个功能还卡在产品经理的签核队列里，对方一整天都在开会。
一天结束,Maya写完三个功能，一个都没上线。
她的代码行数、PR数量好看得不像话，团队看板的系统级指标却纹丝不动。
一周后更难看:Tom开始"扫一眼就批",产品经理批量放行，质量悄悄流失，吞吐量和上季度一样。
Atlassian给这个场景起了个狠名字，"生产系统正遭受一场拒绝服务攻击",发起攻击的，恰恰是Maya自己的产能。
Atlassian 的示意表印证了这条定律的冷酷:个体工作若只占流程的20%,即便被AI加速到"瞬间完成",系统上限也只在1.25倍附近;占比到50%,同样的加速倍数才能把系统拉到1.8倍以上。
买再快的键盘，买不来协作队列的空间。
证据链:这套逻辑，业内已经反复验证了一年多
Dario 这句"但接着你会看到哪里崩了",背后压着一年多攒下来的证据。 往回翻，同一条逻辑已在业内反复被验证。
，非营利机构 METR 做了一次不留情面的对照实验:16名资深开源维护者,246个真实issue,允许使用当时最新的AI工具。
结果是，完成任务平均慢了19%。
开发者事前以为会快24%,做完后依然坚信自己快了20%，主观感觉和客观耗时差出近40个百分点。
2025年11到12月，轮到 Anthropic 自己交作业。
分析约10万条真实 Claude 对话，任务层面时间节省确实可观，但外推到美国劳动生产率时，年化增益只有约1.8%，和"5倍代码"完全不在一个量级。
同期调研显示,132名工程师和研究员中，自报生产力提升普遍在20%到50%,可能被完全托管、不需要人再看一眼的工作，占比仍只有0%到20%。
加速是真的，盯着看也是真的。
最扎心的补刀来自2026年4月的一篇技术博客，引用了 Anthropic 自家模型卡的数字:内部技术员工自报生产力提升，几何平均约4倍，换算成实际研究进度净提升却不到2倍。
更要命的是，若想让净研究进度真正翻倍，可能还需把研究者端加速再拉高一个数量级，也就是再乘10倍。
自报4倍，实测不到2倍，想要2倍还得再加10倍马力，这组数字比任何比喻都冷。
瓶颈不会消失，它只是换了个地方排队
把这些证据串起来，一条因果链浮现出来。
AI最先打穿个体、局部、上下文清晰的那段活，脚手架、样板代码、单测草稿、小重构，确实变快了。
但交付链路里还有大片串行的协作与信任环节，代码评审、安全合规、产品签核、跨团队对齐，靠人的判断和责任归属撑着，不会因为代码写得快就自动消失。
加速非瓶颈，只是把压力更快推给真正的瓶颈:评审队列变长,PR体积变大,"几乎正确但不完全正确"的代码需要别人先读懂再修，生成端省下的时间，又被验证端原样吃掉。
同一条主帖下，有条回复把这套机制概括得比论文还精炼:
"AI doesn't eliminate bottlenecks. It moves them. First it was writing code. Next it's reviews, testing, deployment, and decision-making. The constraint keeps shifting."
“AI不会消灭瓶颈，只会移动瓶颈。起初是写代码，接下来是评审、测试、部署和决策。约束点一直在转移。”
赢家画像:先看见天花板的那群人
时间线绕回2026年7月。 同一天的时间线上，还有一条更短的帖子，把整套算术压缩成一行:
"AI makes coding 5x faster, but coding is only 15-20% of delivery. Amdahl's Law caps total improvement at 19%. The myth fails at the system level."
“AI让写代码快5倍，但写代码只占交付的15%到20%。按阿姆达尔定律，整体提升上限大约只有19%。神话在系统层面就破了。”
Dario 没有否认AI正在让写代码变快，他提醒的是一个更冷的事实:公司的真实模样，是一条多阶段流水线，每一站都算数。
你把哪一环踩得越猛，压力就越原样地甩给还没被踩过的那一环。
接下来真正拉开差距的，不会是谁的AI写出了最多补丁。
是谁先看见下一块要崩的天花板，并在它变成硬约束之前，把它修掉。
热门跟贴