AI把开发速度提高了10倍，企业上线为什么反而更慢了？

企业AI落地｜代码生成提速，不等于软件交付提速

上午，AI一次生成了8个功能的代码。

下午，8个Pull Request同时等待评审，测试环境排起了队。

三天后，业务还在确认需求，安全团队刚开始检查权限，运维说本周发布窗口已经关闭。

管理层看到的是：过去一个星期才能完成的代码，现在一天就能生成。

业务看到的却是：需求并没有更早上线，返工、等待和协调甚至更多了。

这并不矛盾。AI优化的是软件交付链条中的一个环节——编码；企业需要交付的却是一项经过需求确认、架构评审、测试验证、安全检查、变更审批和生产观测的业务能力。

01

“10倍”首先是编码实验，不是企业交付承诺

OpenAI在2026年公布了一项Agent优先的软件工程实验：团队从空仓库开始，使用Codex生成应用逻辑、测试、CI、文档和可观测性代码，并估算特定内部产品大约只用了传统手写代码十分之一的时间。

这个结果很有启发，但不能被简单翻译成“所有企业的软件上线速度都会提高10倍”。

编码速度 ≠ 需求交付速度

开发完成 ≠ 可以发布 ≠ 业务产生结果

OpenAI的实践同时强调，工程师的工作重心需要转向设计环境、表达意图和建立反馈回路。真正支撑速度的，不只是模型，还包括仓库知识、架构边界、自动化测试和持续清理。

02

企业交付速度，由最慢的环节决定

假设一次需求交付原来需要10天：

需求确认：2天

设计与编码：3天

评审与测试：2天

安全与变更审批：2天

等待发布窗口：1天

AI把3天编码压缩成几个小时，总周期也不会自动从10天变成1天。更可能出现的是：代码提前到达评审和测试环节，后面的处理能力没有变化，队列开始增长。

如果团队又因为“开发更快”同时启动更多需求，系统里的在制品就会增加。每一项工作都在等待别人确认，整体交付时间反而被拉长。

AI消除了编码瓶颈
也会把下一个瓶颈暴露得更明显

03

第一个瓶颈：业务还没有把需求说清楚

编码变快以后，模糊需求的代价会被放大。

过去，开发人员要花几天实现功能，期间可能逐步发现边界条件；现在，AI几个小时就能生成一个“看起来完整”的版本。业务看到页面后才意识到审批规则、数据范围和异常流程没有讨论。

于是代码不是少写了，而是更早、更快地进入返工。

需要升级的不是Prompt，而是需求入口：

目标用户是谁，解决什么业务问题；

正常流程、异常流程和禁止流程分别是什么；

涉及哪些角色、应用、数据和权限；

用什么验收场景证明需求已经完成。

AI可以把明确需求快速变成代码，也可以把模糊需求快速变成一大批错误代码。

04

第二个瓶颈：代码评审跟不上代码生成

一个开发人员过去每天提交一两个小变更，现在可以同时让多个Agent实现不同任务。代码产出增加了，资深工程师的注意力却没有增加。

评审者不仅要看语法，还要判断：

需求是否被正确理解；

修改是否破坏既有架构和数据契约；

是否重复实现已有能力；

异常、并发、幂等和回滚是否完整；

AI生成的测试是否真的覆盖业务风险。

如果一次提交包含几十个文件和大量自动生成代码，评审者很容易只检查表面问题。代码合并更快了，风险却被推迟到测试和生产环境。

正确方向：减少批量、限制变更范围、由Agent先做自检和专项评审，把人的注意力留给需求、架构、安全和不可逆决策。

05

第三个瓶颈：测试环境和测试方法没有扩容

代码生成能力提高以后，测试需求会同步增加。可很多企业仍然依赖共享测试环境、手工回归、固定测试窗口和少数测试人员。

多个需求同时进入测试，环境数据互相污染；一个版本占用环境，其他版本只能等待；测试人员没有时间理解大量新代码，只能优先验证主流程。

AI时代的测试能力至少要同步升级：

每个变更拥有可重复创建的隔离环境；

接口契约、权限边界和核心业务状态自动验证；

缺陷修复必须增加能够复现问题的回归测试；

测试结果、日志、截图和追踪自动形成发布证据。

测试不能只是代码完成后的一个阶段，而要成为Agent每次修改都能快速调用的反馈系统。

06

第四个瓶颈：安全、合规与权限仍在最后排队

AI能够快速接入数据库、外部API和企业工具，也更容易在无意中扩大权限范围、记录敏感信息或引入未经审核的依赖。

如果安全检查仍然发生在上线前一天，代码越多，等待安全团队处理的队列就越长。发现问题后再回到开发阶段，返工范围也更大。

安全需要进入生成过程：

Agent默认使用最小工具权限和隔离执行环境；

依赖、密钥、权限和数据流在提交阶段自动扫描；

高风险动作要求业务、安全和数据负责人共同审批；

审批对象绑定代码差异和版本，变更后自动重新验证。

安全左移不是让安全团队更早开会，而是把重复规则转化为开发过程中的自动门禁。

07

第五个瓶颈：企业还在使用固定发布窗口

很多企业一周或两周统一发布一次。代码提前完成，也只能等待下一次窗口；多个变更被打包进同一版本，测试范围和回滚难度随之增加。

AI提高产出以后，如果发布机制不变，企业很容易进入一种反常状态：

代码完成得越来越早

等待发布的变更越来越多

单次上线反而越来越危险

真正需要的是小批量、可独立验证、可灰度、可快速回退的持续交付能力，而不是让AI生成更多代码后继续等待“大版本列车”。

08

DORA的发现：AI是放大器，不是修复器

Google Cloud公布的2025年DORA报告基于近5000名技术专业人员的调查和超过100小时的定性研究。

报告观察到，AI采用已经与软件交付吞吐量和产品绩效的改善呈正相关，但仍与软件交付稳定性下降相关。

DORA给出的解释很直接：AI会加速软件开发，但加速也会暴露下游薄弱环节。没有强自动化测试、成熟版本控制和快速反馈回路，变更数量增加就会带来不稳定。

流程清晰的团队：AI放大标准化、自动化和快速反馈。

流程混乱的团队：AI放大返工、等待、技术债和生产风险。

因此，企业不能只采购AI编码工具，然后用原来的交付体系承接数倍增长的变更。

09

不要再用代码数量衡量AI价值

生成了多少代码、完成了多少任务、创建了多少Pull Request，这些指标都容易让团队误判效率。

代码不是最终产品。更多代码还会增加评审、测试、维护和安全成本。

衡量AI工程效果，应该回到端到端结果：

交付时间：从需求确认到生产可用用了多久。

等待时间：变更在评审、测试、审批和发布队列停留多久。

变更失败率：上线后有多少变更需要修复、回滚或产生事故。

恢复时间：出现问题后多久能定位并恢复。

业务结果：功能是否真正减少成本、提高收入或改善用户体验。

如果编码时间下降了80%，端到端交付时间却没有变化，说明企业只是把瓶颈从开发环节搬到了其他地方。

10

企业需要从“AI编程”升级为“AI交付系统”

AI交付系统不是再部署一个聊天机器人，而是重新连接需求、代码、测试、安全、变更和运行数据。

1. 结构化需求：每项开发任务都有目标、范围、验收条件、影响对象和回滚要求。

2. 小批量变更：限制单次修改范围，减少同时进行的工作，避免大型PR堆积。

3. 自动化反馈：Agent随时可以运行构建、契约、集成、安全和回归测试。

4. 风险分级：低风险变更自动流转，高风险变更触发专项检查和人工审批。

5. 渐进式发布：使用特性开关、灰度、金丝雀和自动回滚降低单次发布风险。

6. 生产闭环：把告警、用户反馈和业务指标关联回具体变更，驱动下一轮修复。

目标不是让每个环节都忙得更快，而是让一项业务价值以更小批量、更少等待和更低风险流过整个系统。

11

ITSM与CMDB要成为AI交付的控制面

传统ITSM经常只在上线审批时出现。到了AI开发阶段，它应该更早进入整个变更生命周期。

任务系统：记录需求、责任人、验收条件和Agent执行计划。

CMDB：识别代码关联的应用、微服务、数据库、接口和业务服务。

变更流程：根据影响范围和风险自动选择测试、审批与发布策略。

证据链：保存代码差异、测试结果、安全扫描、审批记录和发布状态。

事件闭环：生产告警自动关联变更，辅助定位、回滚和复盘。

这样，AI生成的不是一堆等待人工搬运的代码，而是一项带有上下文、风险、证据和运行反馈的可交付变更。

结语

AI把编码从稀缺能力变成了高速能力，但企业真正稀缺的资源正在转移：清晰的需求、可靠的反馈、评审注意力、测试环境、发布能力和跨团队决策。

如果这些能力没有同步升级，AI生成得越快，等待队列、返工和上线风险就越大。

企业下一阶段的竞争，不是谁生成的代码更多，而是谁能把AI产生的变化，更快、更稳地转化为生产环境中的业务结果。

我们正在开源构建 AI Native ITSM：

https://github.com/heidsoft/itsm

说明：“10倍”来自OpenAI特定内部产品实验的时间估算，不代表所有企业采用AI后的普遍结果。

参考资料：

OpenAI，Harness engineering: leveraging Codex in an agent-first world：https://openai.com/index/harness-engineering/

Google Cloud，Announcing the 2025 DORA Report：https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

DORA，Impact of Generative AI in Software Development：https://dora.dev/research/ai/gen-ai-report/

---

本文由 JOTO AI 智库整理。

原始来源：授权原文