AI写了60%代码，研发效率还是没飞？拆解企业级AI编程的核心矛盾

有网友在知乎上提问：“AI 写了 60% 的代码，为什么企业研发效率还是没飞起来？”

乍一看，AI 代码生成率都飙到 50% 以上了，研发周期却纹丝不动，这似乎很反直觉。其实，问题就出在——程序员每天真正花在“写代码”上的时间，可能连 30% 都不到。对外行人来说这个说法匪夷所思，但干过活的都知道这是常识。

底层研发的大部分精力其实花在了需求澄清、跨团队沟通、排查线上故障、写设计文档、等待测试环境等等环节上。如果你技术级别再高一些，还得腾出手来搞架构设计、评 PPT 大会这类事。可以说，软件开发的整个链路里，编码只占很小一块，而 AI 目前只能加速其中这一块。至于需求梳理、流程协作这些隐性成本，基本纹丝未动——就算编码速度翻几倍，最终对整体交付周期的拉动也必然远低于高管的想象。

打个比方，这就是变种的木桶效应：有一块板子长得离谱，但你盛的水还是由最短的板决定。

从我自己最近的研发体验来看，代码评审反而成了新的瓶颈。研发效率确实因 AI 编码提上来了，但评审却比以前更头疼。以前是巴不得 AI 多生成点，好让自己少敲键盘；现在呢，反而有点怕它产出的太多了——几分钟就能吐出成百上千行代码，我却要花好几个小时去读逻辑、排查异常 case。当然，你要说直接拿来就用，那你是勇士，当我没说 。

所以，真想让企业研发效率“飞”起来，光给编码环节提速远远不够。不改造原有的研发流程，就好比给马车硬塞了一台 V12 发动机——东西是好东西，但跑不起来。

至少，需求评审、测试验证、安全审计、层层审批这些配套环节都得跟着变一变。我前司字节的 TRAE 团队做过一次实践：团队超过 90% 的代码由 AI 产出，最终人均需求吞吐率提升了 60%，而不是大家预期中的 90%。

为什么只到 60%？核心原因就是只做了代码提效，却在需求澄清、代码理解、测试生成、评审辅助、日志分析这些链路上的环节没有同步改进。即便这样依然拿下 60% 的提升，已经非常了不起了。

代码永远只是工具，只能提效，无法替代真正的决策者。这些现实难题，在云栈社区的技术讨论中也经常被拿出来切磋。