AI写代码快5倍？公司提速却被这条定律卡住

谈到公司用AI提升效率时，Dario Amodei的表情突然严肃起来。他坐在浅色沙发上，手指轻转话筒，像在准备揭示一个早已看透、却鲜有人懂的真相。

他说，内部模型优化后，工程师能写出两倍、四倍、甚至五倍的代码，所有人都亲眼目睹了。

停顿半秒，他语气一沉，抛出后半句：“但紧接着，你就会看到系统崩了。”

这段约16秒的现场片段，被创业者与投资人Karl Mehta剪辑发布在X平台，配文直指核心：团队误以为编码提速5倍，等于公司整体提速5倍——错了。

"That one is interesting, and again we would go back to our old friend Amdahl's law... you can write two times as many, four times as many, five times as many... But then you see what breaks."

“这一点很关键，我们还得回到老朋友阿姆达尔定律……你可以写出两倍、四倍、五倍的代码……但随后就会发现哪里撑不住了。”

▲ Karl Mehta转发的Code with Claude剪辑：Dario Amodei用阿姆达尔定律解释为何“5倍代码”换不来“5倍公司”。

Karl Mehta的总结更刺痛人心：真正的赢家，不是生成最多代码的团队，而是那些在新瓶颈成为硬约束前，率先发现并解决它的团队。这句话精准击中了每个在软件行业摸爬滚打过的人。

问题来了：阿姆达尔定律，一个诞生于1967年、比多数程序员年纪都大的公式，为何能解释2026年最前沿的AI焦虑？

阿姆达尔定律最初由计算机科学家Gene Amdahl提出一个朴素问题：给机器加再多处理器，程序会等比例变快吗？

答案很现实：不会。程序中总有一部分无法并行，这部分耗时就是死死焊死的天花板，再多算力也撬不动。

▲ 维基百科对阿姆达尔定律的经典表述：优化某部分带来的整体提升，永远受限于该部分占总时间的比例。

翻译成人话，只需记住一句：你能加速的部分占比越小，提升上限就越低，哪怕它被加速到极致。

举两个例子。如果写代码仅占交付流程的20%，哪怕它变得无限快，整体最多快1.25倍，即提升25%，其余80%纹丝不动。若写代码占30%，AI从30秒压到3秒，总耗时从100秒降至73秒，看似提速10倍，公司层面仅快27%。

这套逻辑早在2025年4月就被提出：Windsurf创始人用几乎相同的数字说明，AI写掉大部分代码也替代不了工程师，评审、架构决策依然必不可少，投资回报率反而更高，公司更可能扩招。Dario在台上再次验证了这一点。

Atlassian为团队级场景算了一张直观表格：

数字摆在眼前：一旦协作与流程占去公司80%时间，敲键盘再快也难撬动全局。

抽象公式难引发共鸣，Atlassian讲了一个具体到分钟的故事。

主角是资深工程师Maya。早上9点，她与AI搭档梳理需求，20分钟敲定方案，过去需小半天。9点半，AI辅助搭骨架、写测试，11点PR完成，过去需两天。她状态极佳，11点15分立刻启动下一个需求，下午1点提交第二个PR。这一天，她交出三个PR。

问题出在评审人Tom身上。他一早开会，下午两点才有空审阅，Maya的PR全堆在一起，每条都需他重建上下文，认知负荷飙升。昨日功能还卡在产品经理签核队列，对方整天泡在客户会议里。

下班时，Maya写完三个功能，一个都没上线。个人指标亮眼，团队交付看板却与上周无异。周末，Tom开始“扫一眼就批”，产品经理批量放行，质量悄然流失。同事抱怨，希望她慢点，多拉大家讨论。

Atlassian将这种系统性拥堵，称为“在制品对生产系统发起的拒绝服务攻击”。Milk Road AI说得更尖锐：突然产出三四倍PR，产出不会同步增长，迎面撞上的，是一堆无人评审、无法验证、无人敢信的代码。

▲ Atlassian的团队级阿姆达尔案例：个体指标越亮眼，越可能掩盖系统吞吐停滞的真相。

同一条推文下，一条回复道破本质：

"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不会消灭瓶颈，只会转移瓶颈。起初是写代码，接下来是评审、测试、部署和决策。约束点一直在移动。”

▲ 瓶颈迁移：写代码不再稀缺，稀缺的换了个名字。

瓶颈从未消失，只是换了张脸，堵在下一个环节。

若Maya的故事仍是推演，非营利机构METR用真实数据做了更冷酷的验证。

2025年年中，METR招募16名资深开源维护者，在246个真实issue上做随机对照试验：允许使用最新AI编码工具后，任务完成时间反而平均慢了19%。更讽刺的是，开发者预期快24%，事后仍觉得快了20%。

▲ METR的随机对照试验：资深开发者"感觉更快"，实测却慢了19%，页面注明为2025年初数据快照。

METR也提醒，这是早期工具快照，模型快速迭代，结果不代表永恒。但它揭示了一个更持久的真相：主观速度与客观速度之间，横亘一条鸿沟。这正是阿姆达尔定律预言的部分——加速的是打字，不是理解、验证与信任他人代码，而这才是熟练开发者最耗时的部分。

最耐人寻味的证据，来自Anthropic自家内部。

2025年12月，Anthropic对132名工程师与研究员开展问卷与53场深度访谈。员工自报Claude覆盖工作比例从28%升至59%，自评生产力提升从20%到50%，看似全面胜利，报告却藏着一个沉默数字：能“完全委托”给AI、无需人工复核的工作，占比仍仅为0%至20%。

独立博主Forrest the Woods挖得更深。他发现Anthropic一份内部模型卡：受访技术员工自评生产力提升几何均值约4倍，但研究团队衡量真实进展时，净提升不足2倍。报告估算，要让研究进度翻倍，需在“研究者侧加速”再叠加一个数量级——即40倍个人提速，才换得2倍组织进度。

▲ Forrest the Woods的分析：程序员感受局部提速30倍，但项目净提升被死死压在2倍以下，连Anthropic自身也难逃。

最懂自家模型、算力最足、最愿美化数据的公司，结果仍被同一定律束缚，这比任何外部批评都更具说服力。

省下的时间，也没全变成“更快交付”。Anthropic报告称，约27%的AI辅助工作是“否则根本不会做”的事：修一个懒得修的bug，多跑一次原本不会做的实验。人没把富余时间转化为更短周期，而是做了更多过去顾不上的事：产出变多，不等于交付变快。

时间线回到2026年7月14日。Karl Mehta的剪辑发布同时，另一位用户Ricardo Gonzalez发了一条更干脆的算式帖，像是为整场讨论写下注脚：

"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%。神话在系统层面破灭。”

▲ 现场速算一笔账：5倍编码提速，套入阿姆达尔定律，公司层面最多快19%左右，此为量级估算，非精确值。

这套逻辑早被验证：约束理论讲的正是同一件事——给非瓶颈环节提速，只会让在制品堆积，整体产出仍卡在瓶颈。AI编码相当于突然拉满某个工位产能，当质检与装配跟不上，流水线边堆满半成品，只不过这次的“半成品”换成了PR。

Dario那句“你会看到什么东西崩了”，是给所有沉醉于“5倍代码”幻觉的团队敲响警钟：代码写得快只是起点，能否同步提升评审、安全、验收的产能，才是决定公司真正能快多少的关键。下一个瓶颈已在路上，谁先看见，谁先修复，谁就赢得本轮竞赛。至于那些还在朋友圈晒“AI帮我一天干完一个月活”的团队，不妨先问问评审人：这周，你还活着吗？