AI 编码工具正在席卷整个行业，诸如“代码产出提升 40%”、“研发效率翻倍”的宣传层出不穷。许多团队一拥而上引入 AI 工具，结果却发现代码越写越多，交付反而越来越慢，线上问题不减反增，工程师也变得更加疲惫。
原文链接：https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems
周二早上，工程副总裁（VP）站在会议室前展示一份 PPT，兴奋之情溢于言表。他刚从某个会议或厂商晚宴回来，带着“重磅消息”宣布：
“我们要在全团队推行 AI 编码助手。初步数据显示代码产出会提升 40%，这将彻底改变我们的研发速度。”
于是，会议室里出现了“经典”一幕：一半人点头附和，另一半人则突然对自己的笔记本电脑产生了浓厚兴趣。至于资深工程师，他们脸上露出了那个熟悉的表情——你懂的，就是那种在心里盘算：是现在站出来说点什么，还是晚点直接更新 LinkedIn 简历算了。
但自始至终，没人问出那个最关键的问题：所谓的速度提升，到底是朝着什么目标的速度？
事情的本质其实很简单：这位 VP 看了一眼整个软件交付流程，找到了一个本来就很快的环节——写代码，然后决定让它更快。
这就像在流水线上，挑了一个并非瓶颈的工位疯狂加速，还往里面砸钱。如果你稍微了解一点系统理论，就会知道——这不仅不会让系统变快，反而会让一切变得更糟。
1984 年的理论，今天依然适用
1984 年，Eli Goldratt 写了一本小说——《目标（The Goal）》。虽然讲的是制造业，但对软件工程也出奇地适用。
这本书最核心的思想是约束理论（Theory of Constraints）：
- 每个系统都有且只有一个瓶颈
- 整个系统的吞吐量，由这个瓶颈决定
- 在解决瓶颈之前，优化其他地方毫无意义
很多人理解到这里就停了。但真正关键、也最危险的一点是：如果你优化的不是瓶颈，你不仅不会得到更快的系统，反而会得到一个更加“崩溃”的系统。
以流水线举例就很直观：A 工位生产得飞快，但 B 工位（瓶颈）的处理能力没变。而你在 A 和 B 之间塞了一堆未完成的任务，导致工作量暴涨、交付周期变长、B 工位的人被淹没、优先级混乱、质量暴跌——因为所有人都在忙着“救火”，根本没时间思考。
结论就是：你没有提速，你只是制造了一场“交通堵塞”，然后管它叫“生产力提升”。
真实噩梦：当你把代码产出“提升 3 倍”之后
我相信，很多人已经在经历这一切了。我也经历过，感受就是三个字：糟透了。
开发者提交 PR 的速度前所未有地快。嗯，很好，很棒，给你发个奖，但然后呢？这些 PR 进入 Review 队列，而负责 Review 的人数并没有变成 3 倍——VP 看到的那份厂商 PPT 里根本没提到 Review 这个问题。
于是 PR 开始积压：一天、两天、一周。
然而，开发者早就被 AI 辅助推着搞下一个需求了，等 Review 意见回来时，他看着自己 8 天前写的代码，跟看侏罗纪化石没区别：“你能解释下这个函数是干嘛的吗？”
在这种情况下，Review 开始变成走过场盖章，因为实在太多，根本没法认真看。有人审批了自己根本没细看的 PR（大家都干过吧），然后合并、CI 跑 45 分钟、不稳定用例失败、重跑、第二次通过。
接着，部署流程需要手动审批，而审批的人正在开“关于开会的会”。所以功能在测试环境躺了三天，没人对“上线”这件事有紧迫感。与此同时，开发者又提交了两个 PR。队列越来越长，待办事项逐渐爆炸，每个人手里同时挂着 6 件事，却没一件能真正做完，周期时间（真正衡量你给用户交付价值速度的指标）反而变得更差。
你产出了更多代码，却上线了更少的软件。 明明现状变得更糟了，仪表盘上却写着：生产力提升了 40%——而搞出这一切的人，很可能要升职了。
这样的剧本，我在三家不同公司亲眼见过：仪表盘数据好看了，上线速度却变慢了。没人把两者关联起来，因为仪表盘是给董事会看的，而董事会不懂什么是周期时间，也没人愿意做那个出来解释真相的人。
而更让我睡不着的是：很多 AI 生成的代码，根本没人能完全懂。因为写代码的人没有真正去“写”，只是提示、粗略浏览、跑一遍。凌晨 2 点线上出 Bug 时，值班的人没写过，写提示的人又解释不了。 结果呢？你只是扩大了故障面，同时减少了能理解系统的人。
显然，这不是生产力提升，这只是一颗包装得更好看的“定时炸弹”。
那么，真正的瓶颈到底在哪？
问题来了：如果写代码从来都不是瓶颈，那真正的瓶颈到底在哪？
答案很简单：顺着价值流走一遍。跟着一个功能，从“一个想法”到“用户真正用到”，我保证你会发现瓶颈在疯狂向你招手。
（1）你根本不知道该造什么
这是所有人都羞于谈论的真相：产品经理两个月没跟真实用户聊过天；需求是 Jira 里三行字加一个 Figma 链接，设计是从没用过产品的人拍板的；工程师每天要做 50 个关于行为、边界、异常处理的微决策——因为根本没人定义过，所有人都在猜。
我见过一个团队，花了 6 周，根据销售在 Slack 里转述的“客户可能在电话里大概说过”的需求，做了一个功能，而最后客户根本没买。这个功能只有 11 个人用过，其中 9 个是内部测试。
这不是交付问题，这是“我们到底在干嘛”的问题。在这种环境下提升代码速度，写得再快，也只是更快地做错事而已。
（2）代码“写完”之后的所有事情
我给“写完”打引号，是因为在大多数公司，代码写出来可能只占整个流程的 20%。另外 80%，是你的代码在各种队列里等待的时间。
我见过这样一种情况：代码一下午就写完了，而上线花了两个月。代码本身没变慢，是代码周围的一切在挡路——PR 评审、CI、测试环境、QA、安全评审、产品验收、发布窗口、灰度……从开发者分支到用户屏幕，是一长串交接、等待、排队。
大多数时候，你的代码都一动不动：等人看、等流程跑、等某人点头放行。你以为慢的是开发，其实真正慢的是“等待”。
（3）发布恐惧症
我数不清有多少团队都害怕发布。用例不稳定、可观测性一团糟、没人信灰度流程、上次周四发布毁了所有人的周末……于是他们怎么做？把变更攒成更大的包，但更大就更危险，更危险就更不敢发，更不敢发就攒得更多。
恭喜，你形成了一个完美的“发布恐惧循环”。现在，还要再加上“更快的代码产出”：更多代码，但同样恐惧发布的文化，导致包更大、风险更高、发布更慢——你给一个本来就不敢上线的团队，增加了更多不敢上线的理由。
（4）发布了，但没人知道有没有用
这和“不知道造什么”是同一种病，只是在流程另一端。你做了、你上线了，然后…… 没了。没有像样的数据分析、没有上线后的用户访谈、没人回头看这个功能到底有没有解决问题。于是，你的下一个功能继续猜。
整个路线图就是一连串“有根据的推测（educated guess）”，中间没有任何反馈闭环。在这种环境下加快代码速度，只是让你“做→上线→无所谓” 的循环转得更快。你更频繁地得到 “我们不知道这东西有没有用”，每次都学不到任何东西，还莫名其妙把这叫做“速度”。
（5）真正的瓶颈：组织本身
所以，有时候瓶颈根本不是技术，而是：
- 要等一个会才能做决策
- 三个团队要定接口契约，但一个月没互相聊过
- 架构师是所有重大设计的唯一审批人，流程至少要积压两周
- 季度规划要做 6 周，紧急需求要再等 5 周，因为“不在计划里”
我参加过一个讨论会，当时全场都在问 “为什么这个功能没上线”，最终答案简直离谱：“我们在等一个正在休假的人开会。”
所以，不是技术问题，不是代码问题，是组织结构的问题。我们讨论功能的时间，比写功能还长，甚至还有人提议：开个会，讨论一下那个会怎么开——我真希望这只是个玩笑。
这些是协作问题、人的问题、政治问题、没人愿意背锅的问题。AI 写代码更快又怎样？这对这些问题毫无作用。你的瓶颈在组织架构里，再强的 Copilot 也重构不了它。
正确但“无聊”的解法
这些方法没人愿意讲，因为它们不酷、不 AI、不好卖，但确实有效。
（1）盘一下你的价值流
从想法到上线，一步步记下来，每一步耗时、每两步之间等待多久。等待的 gap，就是你周期时间的杀手。过程可能会很抑郁，但还是要做。
（2）关注周期时间，而不是代码量
如果你在统计代码行、合并 PR 数，却不看从提交到用户用上要多久，你就是在优化错误指标。
（3）消灭等待状态
PR 等两天？做结对编程、更小 PR、固定评审时间。发布要等手动审批？自动化，或至少做成 Slack 按钮，别总靠会议。决策靠开会？拆成小决策，让很多决策不需要开会。
（4）少开工，多完工
WIP 限制是有原因的。做完 3 件事，比 10 件事都做到一半要强得多。并行任务就是切换成本，而优秀工程师就是这么慢慢精神内耗掉的。
（5）听一线工程师的
一线工程师早就知道瓶颈在哪，他们每天 standup 在吐槽、还在 Slack 发梗图——只是没人听。
最后想说的
回到开头说的那个周二早上。副总裁站在台上说“代码产出提升 40%”，但他真正该说、且真正有用的话应该是：
“我们分析了整个交付流程，发现功能平均有 9 天在等待。接下来，我们要把它砍半。”
这句话并不酷炫、放不进厂商 PPT、做不成产品，也很难成为大会演讲题目，但它却能让你真正地快速交付。
所以，写代码的速度从来都不是你的问题。 如果你以为它是，那么这个“认知与现实的差距”，才是你真正的问题所在。
真正的竞争优势，从不属于写代码最快的团队，他们反而容易被淹没在 AI 生成的 PR 队列里，而那些能想清楚要造什么、造得出来、并快速交到用户手里的，才是真正成功的团队。关于如何构建高效协作的团队文化，在云栈社区的技术讨论区，你或许能找到更多来自一线开发者的真实洞察。
发表于 1 小时前
|
查看: 1|
回复: 0
