周二的早上，那位身为工程副总裁的VP，正伫立在会议室的前面，手里展示着一份PPT，其兴奋的模样，跟2017年刚初次发现加密货币的人完全是一个样儿。他才从某个会议或者厂商晚宴归来，先是三杯烈酒喝进肚里，接着看完一场AI演示，此刻便带着“重磅消息”回来了：

我们打算于整个团队之中推行AI编码助手，最初的数据表明代码产出将会提高40%，这会把我们的研发速度从根本上予以改变。

随即，会议室当中呈现出了“经典”的一幕景象：有一半的人点头予以附和，而另一半的人仿佛突然之间对自己使用的笔记本电脑心生了极为浓厚的兴趣。对于资深工程师而言，他们的脸上浮现出了那种众人皆知的表情，也就是那种在内心之中暗自盘算的样子：究竟是当下站出来讲些什么内容呢，还是稍后直接去更新个人简历作罢。

然而，自始至终，没有任何人问出那个最为关键的问题，即，所谓的速度提升，究竟是朝着什么样的目标的速度呢？

整体事情涵盖的本质实际上真的是特别简单，在这一情况里，身为VP的这个人，朝着整个软件交付流程投去了瞧的动作，从中寻觅到了一个原本就具备很快特性的环节，也就是写代码这个环节，紧接着作出了让它变得更加快的决定。

这仿佛于流水作业的生产线上，挑选了一处并非处于瓶颈状态的工作位置，而后极为疯狂地加快速度，并且还朝着其中投入资金。要是你略微知晓一些有关系统的理论，便会清楚——这般作为不但不会促使系统运行得更为快速，反倒会致使所有的情况变得愈发糟糕。

1984 年的理论，今天依然适用

1984年，Eli写出了一本小说，这本小说名为《目标（The Goal）》。这本小说讲的是制造业，然而它对待软件工程的适用性也达到了极为离谱的程度。

这本书最核心的思想是约束理论（ of ）：

每个系统都有且只有一个瓶颈

整个系统的吞吐量，由这个瓶颈决定

在解决瓶颈之前，优化其他地方毫无意义

很多人理解到这里就停了。但真正关键、也最危险的一点是：

假设你所优化的并非是瓶颈所在之处，那么你不但不会获取到更快的系统，而且还会得到一个更趋于“崩溃”的系统。

举例说明以流水线为例会很直观：某个工位生产速度极快，然而与之相比，另一工位即起着瓶颈作用的工位，其处理能力并未发生改变。在这两个工位之间安排增添一系列任务而未曾完成又处于处理中，如此一来工作量如潮水般急剧上涨，交付周期随之变长，出现导致负责瓶颈工位的人员被大量任务彻底淹没，优先级因此陷入混乱状态，质量更是如坐滑梯般暴跌，这是由于所有人都忙于应对紧急状况，完全没有多余时间去进行思考。

那结论便是，你并未实现提速，你仅仅是造就了一场“交通堵塞”，而后将其称作“生产力提升”。

真实噩梦：当你把代码产出“提升 3 倍”之后

我觉着，好多人已然在历经这所有的一切了。我也曾有过这般经历，体会便是三个字：糟糕透顶了。

开发者提交PR的速度，快得突破过往所有记录。嘿，不错哩，很出色，给你颁个奖，可是接下来？这些PR进入队列当中，然而负责的人数并未增至三倍——VP所看到的那份厂商PPT里压根没提及这个问题。

于是 PR 开始积压：一天、两天、一周。

可是呢，开发者早就被 AI 辅助推着去弄下一个需求了，等到意见返回的时候，他瞅着自己 8 天前编写的代码，那感觉就如同看侏罗纪化石一样：“你能不能解释一下这个函数是用来做什么的呀？”。

处于这种状况下，就逐渐演变成走过场盖章了，缘由在于数量实在太过庞大，压根没办法仔细去看。有人审核通过了自己并未详细过目的PR（想必大家都经历过），接着予以合并，CI运行足足45分钟，不稳定的用例出现失败，再次运行，第二次才成功通过。

跟着呢，部署流程得靠手动去审批，然而进行审批这人正在开那个“专有关於开会的会议”。所以呀，这功能在测试环境里闲置了三日，对于“上线”这事压根就没人怀揣紧迫感。于此同时，开发者又递交了两项PR。队列是越来越长，待办事项逐步呈现爆炸态势，每个人手上同时悬着6件事，偏偏没一件能够切实完成，周期时间（此乃真切衡量你向用户交付价值速率的指标）反倒变得越发糟糕。

你编写了更多的代码，然而上线的软件数量却更少了。明明当前的状况变得愈发糟糕了，可是仪表盘上却显示着：生产力提升了40%——而造成这所有情况的人，极有可能要获得升职了。

这般的剧本，我先后在三家各异的公司亲身目睹过：仪表盘所显示的数据变得好看了起来，然而上线的速度却转而慢了下去。没有任何人将这两者相互关联在一起，原因在于仪表盘乃是给董事会进行查看的，可是董事会对此之中所提及的周期时间并不了解，并且也不存在愿意成为那个站出来阐明真相的人。

更让我难以入眠的是，存在着许多由AI生成的代码，完全没有人能够彻底理解。

致使写代码之人并非切实去“写”，仅仅是进行提示、skim、跑上一回。于凌晨2点线上出现Bug之际，值班之人未曾写过，而写提示之人又无法作出解释。最终如何呢？你不过是拓展了故障范围，与此同时削减了能够理解该系统的人员数量。

显而易见，这并非生产力得到提升，这仅仅是一个包装得更为好看的“定时炸弹”而已。

那么，真正的瓶颈到底在哪？

问题来了：如果写代码从来都不是瓶颈，那真正的瓶颈到底在哪？

答案十分简易：沿着价值流顺次走一回。跟随一项功能，从“一个念头”起始，直至“用户切实使用”，我断言你定会发觉瓶颈正急切地向你示意。

（1）你根本不知道该造什么

这是一个真相，所有人都对其羞于谈论：产品经理有两个月未曾与真实用户进行聊天；需求源于 Jira 里的三行文字以及一个 Figma 链接，设计则是由从未使用过产品的人作出决定的；工程师每日都要做出 50 个有关行为、边界、异常处理的微小决策，原因在于根本没有人进行过定义，所有人都只能去猜测。

我曾目睹一个团队，耗费六周时间，依据销售于Slack里所转述的、客户在电话中大概表述的需求，制作了一项功能，然而最终客户压根就未购买。此功能仅有十一个人使用过，其中九个是内部展开测试的。

这不是交付问题，这是“我们到底在干嘛”的问题。

于这般环境里提高代码速度，即便写得极为迅速，那也不过是更加快速地做错事情罢了。

（2）代码“写完”之后的所有事情

我把写下完成加上引号，原因在于，于相当多公司而言，所书写出的代码，兴许仅在整个流程里占据百分之二十。另外的百分之八十呢，是你所编写的代码于各类队列里等候的时长。

我目睹过问这么一种情形，代码在一下午的时间里便给写完了，然而上线却耗费了两个月，代码自身并没有变迟缓，是代码四周的所有事物在阻碍前行，诸如PR评审、CI、测试环境、QA、安全评审、产品验收、发布窗口、灰度等等事项环节，从开发者分支直至用户屏幕，呈现的是一长串的交接、等待以及排队的情况。

多数情形下，你的代码始终处于静止状态，等待他人查看，等待流程运转，等待某人点头予以放行。

你以为慢的是开发，其实真正慢的是“等待”。

（3）发布恐惧症

我难以确切数出究竟有多少团队，它们全都惧怕发布。用例处于不稳定状态，可观测性糟糕至极，没人相信灰度流程，上次周四发布致使所有人的周末都被毁掉……那么他们采取了怎样的做法呢？将变更积攒成规模更大的包，然而更大就意味着更具危险性，更具危险性便更加不敢发布，更加不敢发布就会积攒得更多。

恭喜，你形成了一个完美的“发布恐惧循环”。

当下，得再添上“更快的代码产出”这一项：有着更多代码，然而却是同样惧怕发布的文化氛围，致使包变大、风险变高、发布速度更慢了——你给一个原本就没胆量上线的团队，增添了更多不敢上线的缘由。

（4）发布了，但没人知道有没有用

这跟“不清楚要造啥”属于同一种病，只是处于流程的另一端而已。你进行了操作，你将其上线了，接着呢……就没后续了。既没有像回事儿的数据分析，也没有上线后的用户访谈，更没有人回过头去看看这个功能究竟有没有把问题给解决掉。于是乎，你接下来要做的功能依旧只能靠猜。

整个路线图，是一连串有着依据的推测，也就是“guess”，其中间不存在任何反馈闭环。

是在这样的环境当中去加快代码的速度，仅仅是使得你那“做→上线→无所谓”的循环转动得更为快速而已。你更为频繁地获取到“我们不清楚这东西有没有用处”，每一次都无法学到任何东西，还莫名其妙地将其称作“速度”。

（5）真正的瓶颈：组织本身

所以，有时候瓶颈根本不是技术，而是：

要等一个会才能做决策

三个团队要定接口契约，但一个月没互相聊过

架构师是所有重大设计的唯一审批人，流程至少要积压两周

6周的时间需求用于做季度规划，紧急需求还得再等5周，原因是“不在计划里”。

我曾参与过一场讨论会，那时全场都在询问，“为何这个功能没有上线”，而最终给出的答案简直荒诞不经，是“我们正在等待一个正在休假的人来开会”。

因此，并非是技术方面的问题，并非代码相关的问题，而是组织结构所引发的状况。我们针对功能进行探讨的时长，比用于编写功能的时间还要漫长，而且竟然还有人提出建议：召开一场会议，去商议一下那场会议该如何召开——我真心希望这仅仅只是一个玩笑罢了。

这些属于协作之问题、人之问题、政治之问题、无人甘愿后背锅之情状。AI编写代码 此又能如何呢？这对于这些问题全然无作用。你的瓶颈处于组织架构当中，再强势之事物亦无法重塑它。

正确但“无聊”的解法

这些方法，没人愿意去讲，究其原因在于codejock 17，它们既不酷，又不 AI，还不好卖，然而，却确实是有效的。

（1）盘一下你的价值流

把从想法起始直至上线的整个进程，逐一详细记录下来，明确每一步所耗费的时间。还要清楚间隔两步之间所等待的时长，那个等待的间隙，乃是你周期时间的致命杀手所在。虽然整个过程或许会令人十分抑郁，然而却依旧得去开展。

（2）关注周期时间，而不是代码量

要是你正从事统计代码行的工作，同时还在进行合并PR数的操作，然而却不去关注从提交开始一直到用户能够使用所耗费的时长，那么你此刻所做的便是针对错误的指标展开优化行为。

（3）消灭等待状态

两天之后等 PR？进行结对编程，提交更小的 PR，设定固定的评审时间。发布需要等待手动审批吗？实现自动化，或者至少做成 Slack 按钮，不要总是依赖会议。靠开会来做决策吗？将其拆分成小决策，使得很多决策无需开会。

（4）少开工，多完工

是存在缘由的，WIP 限制。做完三件事情，相较于十件事项都只完成一半，要强出许多。并行任务其实就是切换成本，优秀工程师正是如此，慢慢地陷进精神内耗之中的。

（5）听一线工程师的

处于一线的工程师，早就清楚瓶颈究竟在何处，他们每日都在进行吐槽，并且还会在Slack上发布梗图，然而却只是没有人去倾听。

最后想说的

周二早上，回到开头提及的那个时候。副总裁站于台上宣称“代码产出提升 40%”，然而他真正应当讲出的、且切实具备效用的话语却是：

我们针对整个交付流程做了剖析，从中察觉到功能平均存在着九天处于等待状态的情况，紧接着，我们要将这个等待时长削减为原来的一半。

这句话谈不上极其炫酷，没办法收入厂商的PPT之中，无法制作成产品，而且也很难成为大会演讲所采用的题目然而却能够使你切实地速速完成交付给予了。

所以，写代码的速度从来都并非是你的问题。要是你觉得它是你的问题，那么，这个“认知与现实的差距”，才是你真正的问题所在。

真正具备竞争优势的，从来都不属于写代码速度最快的团队，他们反倒极易被淹没在人工智能生成的公关队列之中，而那些明确知道要打造什么，能够成功打造该项事物，并且能迅速交到用户手中的团队，才是真正获得成功的团队。

【活动分享】，历经48小时，同50多位大厂技术决策者，一起去共同探寻AI落地的真正路径。

“全球机器学习技术大会”，原本是由CSDN跟奇点智能研究院联合举办的，现在正式升级成为了“奇点智能技术大会”。

2026 奇点智能技术大会，将于 4 月 17 日至 18 日，在上海环球港凯悦酒店正式召开，大会聚焦大模型技术演进，聚焦智能体系统工程，聚焦生态实践，聚焦 AI 行业落地等十二大专题板块，特邀来自 BAT 的codejock 17，来自京东的，来自微软的，来自小红书的，来自美团等头部企业的 50 多位技术决策者分享实战案例。

这不单单是一场有关技术的盛宴，更是决策者用以把握2026这一AI拐点的战略机会，对这场盛宴而言是如此，对决策者而言亦是如此。

如有侵权请联系删除！