AI 写了 60% 的代码，为什么企业研发效率还是没飞起来？
AI 写了 60% 的代码，为什么企业研发效率还是没飞起来？
"AI 代码生成率 50% 以上"这个数字本身就有问题，先把这层皮剥开看看。
所谓 AI 写了 60% 的代码，大部分场景是这样的：开发者写了一行函数签名，Copilot 补全了函数体；写了一行注释，AI 生成了下面十几行实现；写了一个接口定义，AI 把 CRUD 和校验逻辑全填上了。按行数算，确实 AI 贡献了大头。
但写代码这件事本身，从来就不是研发效率的瓶颈。
写代码只是研发流程里最不值钱的环节
一个功能从需求到上线，大概经历这么几个阶段：理解需求和业务背景、设计技术方案、写代码、写测试、Code Review、联调、部署、上线后观察修 bug。
写代码大概占整个周期的 15%-20%。AI 让这个环节的效率提升了两三倍，听起来很猛，但 20% 的环节效率翻倍，对整体周期的影响也就缩短了 10% 左右。你原来一个需求要两周交付，现在快了一两天。用户感受不到什么差异，老板也不会觉得效率飞起来了。
真正耗时间的环节是什么？是需求讨论来回扯皮，是技术方案评审反复修改，是联调的时候对方接口没准备好干等着，是上线之后出了个边界情况要紧急修复。这些环节 AI 目前基本帮不上忙。
这就好比一个工厂的生产线，瓶颈在原材料采购和质检环节，你把中间的组装环节自动化了，产能当然不会有质的变化。
AI 生成的代码多了，但 Review 的负担也多了
这个很多人没意识到。
以前一个开发者一天写 200 行代码，Reviewer 看 200 行。现在有了 AI，一天能产出 500 行，Reviewer 要看 500 行。而且 AI 写的代码跟人写的还不一样——人写的代码 Reviewer 可以根据作者的习惯和水平来预判可能出问题的地方，AI 写的代码风格不固定、上下文理解可能有偏差，Reviewer 需要更仔细地逐行看。
我们团队实际统计过，引入 Copilot 之后，Code Review 的平均时间增加了大约 30%。代码量上去了，但 Review 成了新的瓶颈。有段时间 PR 堆积特别严重，因为写代码快了但 Review 跟不上。
更麻烦的是，很多开发者对 AI 生成的代码有一种"它生成的，看起来没问题就行"的心态。AI 写的代码往往语法正确、风格统一、看起来很专业，但在业务逻辑的边界条件、异常处理、安全性上经常有隐患。这些隐患在 Review 的时候如果没仔细抓出来，就会变成线上 bug。而线上 bug 的修复成本是开发阶段的十倍以上。
"代码生成率"这个指标本身就有误导性
企业喜欢用"AI 代码生成率"来衡量 AI 的价值，这个指标有两个根本问题。
第一，它衡量的是数量不是质量。AI 生成了 500 行代码，其中可能有 100 行是不需要的（AI 过度实现了需求），50 行有潜在问题需要修改，20 行有安全隐患。净贡献可能只有 330 行，但统计的时候算 500 行。
第二，它没有把 AI 带来的额外成本算进去。开发者要花时间写 Prompt 描述需求、审查 AI 的输出、修改不对的地方、理解 AI 生成的代码逻辑以便后续维护。这些时间成本在"代码生成率"这个指标里完全不体现。
我见过一个比较极端的例子：一个开发者用 AI 生成了一个复杂的数据同步模块，大概 300 行。功能基本实现了，但代码结构跟项目里其他模块的风格完全不一样，用的设计模式也不同。后来另一个人接手维护这个模块，花了两天才理清逻辑，然后又花了一天重构成跟项目一致的风格。你说 AI 提高效率了吗？短期看生成阶段确实快了，长期看维护成本反而增加了。
Vibe Coding 为什么让信任感下降
非技术人员用 AI 写代码这个趋势确实在发生，但它带来的问题比解决的问题多。
Vibe Coding 的本质是：用户描述想要什么，AI 直接生成一个可以跑的东西。对于做个原型、写个脚本、搞个内部工具，这个方式效率很高。但一旦要用到生产环境，问题就来了。
生成的代码没有人真正理解它的内部逻辑。非技术人员不理解，写代码的 AI 也不保证逻辑完全正确。出了问题谁来排查？改了一个地方会不会影响另一个地方？没人知道。这不是信任感的问题，这是可维护性的问题。
企业级开发里，代码的生命周期远比写代码的那个下午要长。一个系统可能要维护三五年甚至更久，期间会有不同的人来修改和扩展。如果最初的代码连写它的人都不理解，后面每一次修改都是在冒险。
我观察到一个现象：用 Vibe Coding 做的内部工具，一开始大家觉得很方便很快，但三四个月之后开始出问题了。改不动——因为没人理解代码结构；扩展不了——因为 AI 生成的代码没有考虑扩展性；出了 bug 修不了——因为调试 AI 写的代码比自己重写还慢。最后这些工具要么被废弃，要么由开发者重写。
企业级开发到底卡在哪
如果把 AI Coding 在企业落地的阻力排个序，大概是这样的。
第一个是代码质量和安全合规。企业的代码要过安全扫描、要符合编码规范、不能引入有许可证风险的开源代码。AI 生成的代码经常在这些方面踩坑——用了不合规的开源库、没做输入校验、硬编码了敏感配置。每一个都是安全团队要找你的理由。
第二个是上下文理解的局限。企业的代码库通常很大，几十万行到几百万行，有复杂的模块依赖关系、有历史遗留的特殊处理逻辑、有只有几个老人才知道的潜规则。AI 只能看到你当前给它的上下文，它不知道你三年前为什么要在这里加一个特殊判断。没有这些背景知识，它生成的代码在功能上可能是对的，但放在整个系统里可能会引发意想不到的问题。
第三个是研发流程本身的限制。很多企业的研发流程不是"需求→写代码→上线"这么简单，中间还有分支管理策略、CI/CD 流水线、多环境部署、灰度发布、审批流程。AI 能帮你快速写出代码，但这些流程性的工作一个都省不了。在很多企业里，从代码写完到真正上线，中间的等待和流程消耗的时间比写代码本身要长得多。
第四个是团队协作。AI 是一个人的效率工具，但企业开发是团队协作。一个人用 AI 写得飞快，但代码要跟其他人的模块对接、要符合团队的架构设计、要经过其他人的 Review。AI 没法帮你跟产品经理对齐需求，没法帮你跟前端同事协调接口格式，也没法帮你在架构评审会上说服技术负责人。
这么说 AI Coding 就没用了？
当然不是。AI Coding 确实在提高个人的编码效率，而且提升幅度不小。但它目前的价值更多体现在"减少重复劳动"和"降低入门门槛"上，而不是"缩短整体研发周期"。
写一个 CRUD 接口、补全一段样板代码、生成一个单元测试的框架、快速实现一个自己知道怎么做但懒得手敲的功能——这些场景下 AI 的价值是实实在在的。但如果你期望的是"用了 AI 之后研发周期直接砍半"，那你对研发效率的瓶颈在哪可能有误判。
真正让研发效率飞起来，可能需要的不是"AI 写更多代码"，而是"AI 帮你减少不该写的代码"——更好地理解需求避免返工、更早地发现设计缺陷避免重构、更智能地做测试覆盖避免线上 bug。这些才是研发周期里真正的大头。目前的 AI Coding 工具在这些方向上刚刚起步，还远没到成熟的地步。