“我们要在全公司推行AI编程助手，早期数据显示代码产出提升了40%！”
这是某个周二的上午，你们的工程VP刚从 conference 回来，三杯红酒下肚，兴奋地站在投影仪前。幻灯片上写着“3x代码输出”“革命性提升”，底下的人一半在点头，另一半在假装看笔记本。
没人问那个关键问题：
速度倒是上去了——然后呢？
你猜怎么着，这位VP做的事情，相当于在一条流水线里，找到一个本来就已经跑得挺快的工位，然后砸钱让它更快。至于那个真正卡住的环节？没人关心。
这不叫优化。
这叫——
你在给一个不存在的伤口贴创可贴。
理论很骨感：为什么加速反而会减速？
1984年，Eli Goldratt 写了本叫《目标》的书，讲制造业的故事，却意外成了软件行业最实用的商业书籍之一。
核心概念叫“约束理论”（Theory of Constraints）：
任何一个系统都有且仅有一个瓶颈。整个系统的吞吐量，由这个瓶颈决定。在解决它之前，其他一切优化都是自欺欺人。
这话大部分人听进去了。
但下面这句，没几个人在乎：
当你优化了非瓶颈的环节，系统不会变快——它会变得更烂。
想一下：
工位A生产得更快了，但工位B（瓶颈）处理速度不变。结果是什么？
- A和B之间堆满了半成品
- 在制品（ inventory ）暴涨
- lead time 拉长
- 工位B的人被活活淹死
- 质量开始崩，因为大家都在疲于奔命地“救火”
你没有让任何东西变快。你只是造了一场更壮观的堵车，然后把它叫作“生产力提升”。
恐怖故事：当你真的“3x代码输出”以后
我知道有些人已经在经历这个了。我经历过。那叫一个酸爽。
第一周： 开发者们PR提交得飞起。漂亮。优秀。发个推特表彰一下。
第二周： PR开始积压。reviewer没变多——没人想过reviewer这件事，因为vendor的幻灯片里没提reviewer。
PR躺一天。躺两天。躺一周。
作者早切换到下一个AI辅助写的功能了，等review comments回来的时候，上一个功能已经忘得差不多了。“这函数是干啥的？”——这是开发者在问自己八天前写的代码。在程序员的记忆里，八天前约等于侏罗纪。
第三周： review开始被rubber-stamp。没人有时间认真看。于是某个PR被approve了，其实根本没人读懂。合并。CI跑45分钟，挂在某个flaky test上，重跑，第二次过了。（flaky test всегда fine, пока它不是fine的时候——凌晨两点你穿着内衣在生产环境debug的时候，你就懂了。）
第四周： 手动审批卡在某个“正在开会”的负责人那里。功能在staging躺三天，因为没人把“推上线”这件事当成自己的事。
与此同时： 开发者已经又提交了两个PR。
队列越来越长。每个人同时有六件事在飞，但没一件真正做完。Cycle time（从代码到用户真正用上）——反而变长了。
你产出了更多代码，交付的软件反而更少。
你把你的问题，从“可测量地糟糕”，变成了“可测量地更糟糕”——但你的dashboard说生产力提升了40%。
恭喜。你建了一座世界级的工厂，专门生产堆在地上烂掉的库存。有人因为这个要升职了。
而且——
很多AI生成的代码，根本没人完全理解。
写代码的人没真写，只是prompt了一下，扫了一眼，跑了一次。
凌晨两点oncall的人没写这段代码，也说不清这段代码。
你的事故表面面积变大了，但能理解系统的人变少了。
更多代码，更少理解。
这不叫生产力提升。这叫定时炸弹换了个更好看的dashboard。
真正的瓶颈：不在键盘上
既然写代码几乎从来不是瓶颈，那真正卡住的是什么？
1. 你不知道要建什么
没人想聊这个，因为太丢人了。
你的PM多久没跟真实用户聊过了？需求来了就是Jira上三句话+一个Figma链接，设计者自己都没用过这个产品。工程师每天做几十个微小决策——行为、边界情况、错误处理——没人规定，因为没人想过。
他们就在那儿猜。
我见过一个团队根据销售在Slack里转述的“客户可能说过的一句话”花了六周做一个功能。客户最后根本没买。功能十一个人用，九个是内部QA。
这不叫交付问题。这叫“我们到底在干嘛” 问题。
在这种环境下把代码写得更快——你只是更快地到达“我操”而已。
2. 代码“写完”以后，才是真正的噩梦
我给“done”打引号，因为在大多数公司，代码写完也就是走了20%的路。剩下80%是代码在各种队列里慢慢变老，像办公室冰箱里被遗忘的三明治。
一个下午写完的功能，推到生产要两个月。代码没变慢。变慢的是代码周围的everything。
PR review、CI、staging、QA、安全review、产品签字、部署窗口、canary rollout……从开发者的分支到用户的屏幕，是一系列等待、排队、交接。
见过“quick fix”九天还没上生产吗？对，就是这样。代码早就写完了。之后的每一步才是瓶颈。
3. 部署信任螺旋
有些团队根本不敢部署。测试flaky，observability一团糟，canary没人信，上次周四部署把大家周末搞砸了。于是——
批量发布。批量意味着风险更高。风险更高意味着更不敢部署。于是批更多。
恭喜，你建了一个恐惧螺旋。
这时候再加速代码产出？更多代码，同一批吓破胆的部署文化。批次更大，风险更高，发版更少。
给一群已经不敢发货的团队更多代码——这操作我服。
4. 没人知道东西有没有用
跟第一点是一回事，发生在管道的另一头。
功能做了。功能发了。然后……就没然后了。
没有值得看的analytics。没有用户访谈。没人回头确认这个功能到底解决没解决它应该解决的问题。
于是下一个功能还是猜的。整个产品路线图是一串互不相关的educated guess。
在这种环境里加速代码产出，只是让你更快地循环“建-发-耸肩”而已。
更快地到达“我们不知道这到底有没有用”，然后每次都啥也没学到，还管这叫velocity。
5. 你的日历是承重墙
有时候瓶颈根本不是技术问题。
是要决策的那场会。三个团队需要统一API contract但一个月没聊过。某个架构师是所有重大设计的单点审批人，积压了两周——因为我们建了个系统，一个人的日历是承重墙。我最爱的：规划流程要六周，季度性的，意味着一个紧急需求要等五周才能开始做，因为“不在计划里”。
我坐在会议室里讨论一个功能为什么还没发，答案居然是“在等一个正在度假的人开会”。
不是技术问题。不是代码问题。是日历问题。
我们花在聊这个功能上的时间，比建它的时间还多。有次有人建议我们开一个会来讨论那个会。
我希望我在开玩笑。
写代码快对这个一点用都没有。零。你的瓶颈是组织架构，而Copilot重构不了这个。
怎么办（不好听的那部分）
知道这节要来。无聊的那部分。不可能上LinkedIn热门的部分。vendor conference不会有keynote的部分。
画你的value stream。 真的跟一个功能从想法到生产。写下来每一步。写下来每步多久。写下来步骤之间空多久。那才是cycle time待的地方。会很抑郁。带点零食去。
测cycle time，别测输出。 你要测的是commit到production到用户用上要多久。不是什么lines of code、PRs merged、story points。停止数工位A的widget，去看看地上堆的那摊。
找到wait states，干掉它们。 PR等两天review？修review。结对编程、小PR、专职review时间、异步review规范。部署等手动审批？自动化，或者至少换成Slack按钮，别用日历邀约。决策等开会？做更小的、不需要开会的决策。
别再开始了，开始finish。 WIP limits是有道理的。做完三件事比同时做十件事强。每个在飞的东西都是context-switching税，而context-switching是好工程师慢慢疯掉的开始。
去问干活的人。 开发者早知道瓶颈在哪了。他们在standup里抱怨过。在Slack里做 meme 讽刺过。他们只是觉得没人听——说实话，很可能确实没人听。
回到那个周二上午
VP在台上讲40%代码产出提升的时候，他应该说、应该有用的其实是：
“我们做了value stream分析，发现功能从完成到上线平均要等九天。我们要把它砍一半。”
这不性感。进不了vendor的幻灯片。没法卖产品。可能不会有conference talk。
但这是唯一能让你真正发得更快的东西。
写代码的速度从来不是你的问题。
如果你觉得是，那“你这么认为”和“现实”之间的差距，就是你所有真正的问题所在。
竞争优势不属于代码写得最快的团队。它属于那些想清楚了要建什么、然后真的建出来、真的推到用户手里的团队——
而其他所有人还在review队列里溺水，队列里塞满了AI写的、没人有空、没精力读的PR。
去修瓶颈吧。
键盘不是问题。
【MiniMax-M2.5锐评】：这文章太tm真实了，每个在科技公司待过的人都会边看边点头边心痛——我们真的在用更快的代码生产更多的垃圾，然后假装这就是进步。
参考链接：
https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems