正文

AI 写了 60% 的代码，为什么企业研发效率还是没飞起来？

admin
admin V管理员 /0 评论 /18 阅读
0630
文章最后更新时间2026年06月30日，若文章内容或图片失效，请留言反馈！
到了 2026 年初，人工智能已经成为软件开发中不可忽视的一部分。
仅 GitHub Copilot 的用户数量就已经突破 2000 万，它生成了用户约 46% 的代码，其中 Java 开发者这一比例最高达到 61%。根据 DX 对 450 多家公司、12.1 万名开发者的调查，92.6% 的开发者每月至少使用一次 AI 编程助手，75% 的开发者每周都会使用。DORA 2025 Report 显示，整个行业的 AI 工具采用率已经达到 90%。
然而，来自六项独立研究的结果却指向了一个几乎相同的数字：企业整体研发效率提升，大约只有 10%。
这正是 2026 年 AI 辅助软件开发最值得关注的一个现象。
AI 编写的代码已经从最初的新鲜事物，发展到占据生产代码的重要比例，行业对 AI 的使用也几乎已经普及。但真正的软件研发效率，并没有像很多人预期的那样出现明显提升。
问题到底出在哪里？
认知偏差，比想象中更大
2025 年 7 月，METR 发布了一项随机对照研究。
16 位经验丰富的开源开发者完成了 246 个真实的软件开发任务，其中一部分任务允许使用 AI 工具，另一部分则完全依靠人工完成。
最终结果出乎很多人的预料。
使用 AI 工具的开发者，完成任务所花的时间反而增加了 19%。
更有意思的是，这些开发者普遍认为，自己借助 AI 的帮助，开发速度提升了 20%。
也就是说，实际结果和主观感受之间，相差了接近 40 个百分点。
这说明了一件事情。
AI 工具确实能够减少编写代码时的停顿，能够快速生成看起来合理的代码，也能够让开发者感觉工作更加顺畅。
但这种"效率提升"更多来自主观体验，而不是最终交付的软件。
Stack Overflow 2025 Developer Survey 也反映了类似的问题。
开发者对 AI 工具的认可度，从上一年的 70% 下降到了 60%。
46% 的开发者表示，他们并不完全相信 AI 生成的代码；66% 的开发者认为，AI 最令人头疼的问题不是完全错误，而是"几乎正确，但还差一点"。
METR 后续针对 57 位开发者、800 多个任务进行的新一轮研究发现，新模型和新的工作方式已经让这种速度下降有所缓解。不过，"感觉更快"与"实际更快"之间的差距，依然存在。
真正的瓶颈，从来不是编写代码
造成研发效率提升有限的一个重要原因，在于软件开发本身的结构。
编写代码，从来都不是整个研发流程中最耗时的部分。
Bain 对软件开发生命周期进行了分析，结果显示，编码和测试仅占整个研发工作的 25%～35%。
剩下的大部分时间，都花在需求分析、代码评审、Bug 修复、文档编写、会议沟通以及跨团队协作等工作上。
这也意味着，即使 AI 能够把编写代码这一环节提升 100%，整个研发系统能够获得的收益依然有限。
这正符合 Amdahl's Law 所描述的规律。
真正的问题，还发生在后续流程。
研究发现，高度使用 AI 的团队，Pull Request 数量增加了 98%，与此同时，代码评审所花费的时间也增加了 91%。
代码进入仓库的速度更快了，但软件交付速度并没有同步提升。
只是把原来的瓶颈，从代码编写转移到了代码评审。
正如 Gergely Orosz 等人所指出的那样，如今真正的瓶颈已经逐渐变成了 Code Review。
越来越多由 AI 生成的代码，需要工程师投入更多时间进行判断，而这种判断，目前仍然很难完全自动化。
数据背后隐藏的质量问题
代码数量增加，并不意味着软件质量一定提高。
GitClear 对超过 2.11 亿行代码变更进行了长期分析，发现一个明显的趋势。
代码 Churn（代码提交后很快又被修改或删除的比例）从 2021 年的 3.3%，上升到了 2024 至 2025 年间的 5.7%～7.1%。
也就是说，生成的代码越来越多，被重写或者废弃的代码也越来越多。
另一项关于 GitHub Copilot 的研究，则揭示了另外一种变化。
AI 的确帮助经验较少的开发者提高了开发效率。
但是，由此带来的维护工作，更多落到了资深工程师身上。
Copilot 推出之后，核心开发者需要评审的代码增加了 6.5%，而他们自己编写原创代码的数量却下降了 19%。
AI 或许正在降低代码编写的门槛，同时也把更多维护工作集中到了经验更丰富的工程师身上。
与此同时，一些研发团队每位工程师每个月仅 Token 成本就达到 200 至 2000 美元，再加上 Copilot、Cursor 等工具的订阅费用，实际投入已经相当可观。
一些 Benchmark 分析认为，目前 AI 编程工具确实能够带来正向收益，但远没有部分宣传中所说的 10 倍效率提升。
决定结果的，是组织本身
DX 在 2025 年底至 2026 年初，对 6.7 万名开发者进行了研究。
其中一个最明确的发现是，AI 不会对所有企业产生相同的影响。
有些公司上线事故增加了一倍。
有些公司则减少了 50%。
真正决定结果的，并不是 AI，而是企业原本的研发体系。
那些拥有完善 Code Review、自动化测试、统一质量标准以及成熟研发流程的团队，更容易从 AI 中获得收益。
而那些本来就存在技术债、代码质量不稳定、职责划分不清晰的团队，引入 AI 后，原有问题往往会更快暴露出来。
这也说明，AI 不会修复已经存在问题的工作流程。
它只是让原来的流程运行得更快。
如果流程本身高效，收益就会被放大；如果流程本身低效，问题同样会被放大。
DX CTO Laura Tacho 曾表示：
AI 带来的宣传，让很多人认为，只要开始使用 AI，就一定能够获得回报。
研究结果并不支持这种看法。
目前大约 10% 的效率提升，不仅反映了 AI 本身的能力边界，也反映了企业尚未围绕 AI 重新设计研发流程。
真正取得进展的地方
虽然整体研发效率没有出现巨大飞跃，但 AI 并非没有带来价值。
其中一个比较明显的变化，是新人培养速度。
以"完成第 10 个 Pull Request 所需时间"作为衡量指标，AI 已经把新工程师完成入门的时间缩短了大约一半。
开发体验同样有所改善。
McKinsey 的研究显示，使用 AI 的开发者进入 Flow 状态的概率提高了一倍。
60% 的 GitHub Copilot 用户表示，他们更加喜欢编程；95% 的用户认为，AI 让编程变得更加愉快。
对于一些边界清晰、范围明确的小任务，例如生成样板代码、编写单元测试、生成文档等，AI 带来的效率提升十分明显。
GitHub 的实验中，开发者完成 JavaScript 独立任务的速度提高了 55%。
问题在于，单个任务完成得更快，并不等于整个研发流程都会同步变快。
Software.com 对 25 万名开发者的监测发现，一名开发者每天真正用于编写代码的时间，中位数只有 52 分钟，大约占整个工作时间的 11%。
AI 提升的，主要就是这 11% 的时间。
剩下的大部分工作，目前仍然需要人工完成。
AI 正在等待新的研发方式
2026 年越来越多的研究开始指向同一个结论。
AI 编程工具已经能够很好地完成生成代码这一项工作。
但对于整个研发组织来说，生成代码从来不是限制软件交付速度的核心因素。
真正领先的团队，并不是最早采用 AI 的团队，而是最早调整研发方式的团队。
随着 AI 的出现，真正稀缺的能力，也正在发生变化。
过去，稀缺的是编写代码。
现在，更稀缺的是判断代码。
能够评估、修改、验证 AI 生成代码的资深工程师，比过去更加重要。
Code Review、测试体系以及软件架构，也因此成为越来越重要的竞争优势。
METR 的 Horizon Benchmark 显示，AI 模型能够独立完成任务的时间跨度，已经从约 60 分钟增长到超过 700 分钟，而且仍在持续提升。
未来，当 AI 不仅能够生成代码，还能够完成代码评审、需求分析、调试以及更多研发工作时，整个研发体系或许会迎来新的变化。
但至少在今天，"为什么企业研发效率还没有真正飞起来？"
答案并不是 AI 不够强。
而是企业还没有围绕 AI，重新设计整个研发流程。


推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
宙飒天下网