AI写了60%的代码，你的研发周期却没变短？

先讲一个反直觉的事实：绝大多数软件项目里，纯写代码的时间不到20%。也就是说，你每天加班到深夜敲的那些键盘，在整条研发流水线上占的比重，小得可怜。

然后你再想想——AI把“写代码”这一段从一周压到了一天，你的交付周期变短了吗？

大概率没有。

这不是AI不行，是你对“写代码”这件事的理解出了问题。

一、你优化的从来就不是瓶颈

黄仁勋去年在红杉的一场对话里说过一句话，特别适合拿来当这问题的引子。他说招软件工程师的时候，没有哪家公司会对候选人说“来，给我演示一下你几秒钟能打多少字”。写代码从来不是工程师的工作，解决问题才是。

这句话点破了一个被很多人忽视的常识：敲键盘从来就不是研发周期的瓶颈。

你把一个本来就不堵的环节提速了三倍，整条流水线的吞吐量当然不会跟着涨三倍。这就像你给一条高速公路的入口收费站装了ETC，结果发现堵车的永远是出口匝道——你把入口疏通一万遍，出口该堵还是堵。

一个需求从提出到上线，真正吃时间的环节是什么？把模糊的业务诉求翻译成清楚的技术问题、拆解、选架构、评审、联调、把新代码安全地塞进一套已经跑了五年谁也不敢乱动的旧系统。这些环节里，写代码占的比重小得可怜。

AI把“写”这一段的效率拉满了，结果就是——下游全被淹了。

最直接的就是代码评审。一个人一天能让AI产出三千行代码，但他一天读不完也判断不完这三千行。AI生成的代码往往是大块大块的变更，不像人类开发者习惯做小而原子的提交。审查者面对一堆没人真正理解过的代码，认知负荷直接拉满。

METR的一项研究印证了这个困境：AI编程助手反而让资深开发者的生产力降低了19%——开发者本以为AI能把周期缩短20%，结果实际完成时间拉长了19%。研究还发现，75%的开发者会阅读每一行AI生成的代码，100%的人都表示AI代码需要修改。

你写得越快，我审得越慢。这不是工具的错，是流水线的设计压根没考虑过“生成端可以这么快”。

二、OpenAI自己先意识到了这个问题

有一个很诚实的信号值得注意。

OpenAI Codex团队现在专门做了一个“先出计划”的模式——让agent动手之前先把要做什么列成一份计划，问你同不同意再开工。负责人Embirikos的判断是：到了agent时代，“计划评论”会比“代码评论”更重要。

这背后的逻辑很清晰：当生成端快到一定程度，瓶颈就从“写得出来吗”彻底转移到“我敢信吗、我审得过来吗”。

换句话说，OpenAI自己在做的事情，是把人类的角色从“代码生产者”往“系统决策者与审计员”的方向推。他们知道，代码生成这件事AI已经干得够快了，真正需要人盯的，是“这个计划对不对”“这个架构行不行”“这个方案有没有坑”。

三、“Vibe Coding”的信任危机，恰恰是专业判断在起作用

最近有个词很火——Vibe Coding，大意是“跟着感觉让AI写代码”。非研发人员用它写出了能跑的小工具，但研发团队对AI生成代码的信任感却在下降。

这矛盾吗？一点都不矛盾。

OpenAI管Codex的Theo举过一个很精准的例子：你用Vibe Coding搞出一个收录300个最常用英语单词的小应用，写得很完美；可一旦想扩展到1000个词，那套架构就立刻不够用了。Vibe Coding在原型和小范围分享里几乎无敌，但“如果你想扩展到成千上万人，你还是需要技术人才参与”。

OpenClaw的创始人Peter Steinberger说得更直接——“Vibe Coding是个谎言”。他自己天天用AI写代码，但做判断时“仍然用老式方法”。他想说的不是AI不行，而是：能跑的代码和能维护、能扩展、能让人放心的代码，是两回事。

所以信任感下降，下降的不是对AI能力的信任，是对“这段代码没有任何一个活人真正理解过”的不安。它现在能跑，但三个月后要改一个边界条件时，没人说得清当初为什么这么写。

研发团队不是不信AI写得对，是不敢把一堆没人兜底的代码堆进核心系统。这种不安完全合理——它恰恰是专业判断还在起作用的证据。

四、效率提升，从来不会变成“更短的周期”

还有一个更底层的逻辑，被大多数人忽略了。

Anthropic的CFO提过一个反直觉的观察，她管它叫“劳动力版的杰文斯悖论”。原话是：AI让员工的生产力暴涨之后，公司反而招了更多人，因为“要做的事情永远做不完”。她自己的体感是，以前忙着对账、结账，现在省下来的时间全花在想“我们怎么把这些再投资到业务里去”。

杰文斯悖论是19世纪经济学家提出的一个观察：蒸汽机效率提升之后，英国的煤炭消耗量非但没减少，反而暴涨了。原因很简单——效率越高，使用的场景越多，总需求反而越大。

这条规律套到研发上就是：效率省出来的空间，不会变成“同样的活提前两周交”，而是被“做更多的活、把标准提得更高”吸收掉。

以前没精力写的测试现在补上了，以前不敢碰的重构现在动手了，以前砍掉的需求现在排进来了。周期没变短，是因为你在同样的时间里塞进了更多事情。从产出看是飞起来了，从“交付周期”这个单一指标看却毫无变化。

用周期长短来衡量AI的研发收益，本身就量错了对象。

五、真正的差距，在流程重构上

Claude Code的负责人Boris Cherny经济学出身，他特别爱引一个老案例：上世纪90年代企业把电脑铺满了办公室，统计上的生产率却纹丝不动。原因后来大家想明白了——光把新工具塞进旧流程没用，得等组织和流程围着新工具重新长一遍，红利才出来。

他给的数据是，Claude让Anthropic内部工程师的人均产出涨了大概250%，但他反复强调，这个增长不是“给每个人发一个AI”堆出来的，是组织和协作方式重构出来的。

绝大多数企业卡在这一步。好工具买回去，等于把一台更快的发动机装在原来的车架上——车架的承重和转弯半径没变，跑不快是必然的。

AI写了60%的代码，可你的需求评审、排期、测试、上线审批全套流程一个字没改。那60%省下来的时间，就被卡在旧流程的各个关节里耗光了。

总结一下。

AI写代码这件事，干的是黄仁勋说的“任务”，没动到“工作”。它把研发的瓶颈从“写”往下游的“想”和“审”狠狠推了一把。多数企业只换了工具没换流程，红利卡在旧流水线里。省下来的时间又被新增的工作和拔高的标准吃掉了。

四件事叠在一起，“60%的代码”和“周期没变短”就一点都不矛盾了。

真正会拉开差距的，是谁先动流程而不是谁先买工具：把人从打字里腾出来，压到判断、架构和评审这些AI还兜不住的环节上去。

黄仁勋那句“你不会输给AI，你会输给那些善用AI的人”，落到企业身上就是——你不会输给会写代码的AI，你会输给那些先把流程重构成AI原生、再让AI进来的对手。

继续把AI当一台更快的打字机，代码生成率从60%涨到80%也没用。

周期还是那个周期。