AI编码提速十倍，企业上线为何反而变慢？关键在编码之外的交付瓶颈与相应破局思路。核心内容：1. 企业整体交付与AI编码提速并非同一回事2. AI让新瓶颈显现，而最慢环节控制着企业交付速度3. 交付效率受阻的核心转为滞后的评审与模糊的需求

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

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

到了下午，测试环境已经排队，同时还有8个Pull Request等候评审。

运维在三天后表示，本周发布窗口已经关闭；此时安全团队才着手检查权限，业务仍未完成需求确认。

管理层看到，过去需要一个星期完成的代码，如今一天就可以生成。

业务端看到的却是需求并未更早上线，协调、等待和返工甚至有所增加。

企业要交付的是一项业务能力，它必须经历生产观测、变更审批、安全检查、测试验证、架构评审与需求确认。AI所优化的仅是软件交付链条里的编码环节，因此二者并不矛盾。

01

编码实验是“10倍”的首要语境，企业交付并未获得相同承诺

在2026年，OpenAI公布了一项以Agent为先的软件工程实验。团队从空仓库出发，应用逻辑、测试、CI、文档及可观测性代码均由Codex生成；其估算显示，特定内部产品所耗时间约为传统手写代码的十分之一。

“所有企业的软件上线速度都会提高10倍”，不能由这个颇具启发性的结果直接推导出来。

编码速度 ≠ 需求交付速度

业务产生结果在最后，可以发布居中，开发完成只是起点，三者并不等同

速度的支撑条件还包括持续清理、自动化测试、架构边界和仓库知识，并不只有模型。OpenAI的实践也指出，环境设计、意图表达与反馈回路建设，应成为工程师新的工作重心。

02

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

假设一项需求原本要用10天交付：

需求确认：2天

设计与编码：3天

评审与测试：2天

安全与变更审批：2天

等待发布窗口：1天

总周期原为10天时，即便AI把其中3天的编码缩到几个小时，也不会自然只剩1天。代码会更早进入测试和评审，但后续处理能力保持不变，最终增长的是队列。

整体交付时间可能因等待确认而变长，因为每项工作都在等别人处理。若团队依据“开发更快”同时开启更多需求，系统中的在制品还会进一步增加。

AI解决了编码瓶颈
同时会让下一个瓶颈更加明显

03

首个瓶颈：业务需求尚未说明白

编码提速后，模糊需求带来的代价会进一步放大。

现在，AI能在几个小时内产出一个“看起来完整”的版本，业务往往见到页面后才发现，异常流程、数据范围和审批规则尚未讨论。过去开发人员实现功能要用几天，边界条件可能在这一过程中逐步显现。

结果并非少写代码，而是代码更早、更快地进入返工。

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

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

分别界定禁止流程、异常流程与正常流程；

牵涉哪些角色、应用、数据与权限；

通过哪些验收场景证明需求已经完成。

明确的需求可以被AI迅速转为代码，模糊的需求也可能被它迅速转为大批错误代码。

04

第二个瓶颈：代码评审速度追不上代码生成

资深工程师的注意力并不会随代码产出一起增加。过去一个开发人员每天提交一两个小变更，如今却能让多个Agent同时执行不同任务。

评审者不仅需要检查语法，还必须判断：

需求有没有被正确理解；

此次修改是否破坏现有架构与数据契约；

是否把已有能力重复实现；

异常、并发、幂等与回滚机制是否完整；

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

评审者面对包含大量自动生成代码和几十个文件的一次提交，往往只能检查表面问题。合并代码的速度虽然提升，风险却转移到了生产环境和测试环节。

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

05

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

测试需求会随着代码生成能力增强而上升，但共享测试环境、手工回归、固定测试窗口和少数测试人员，仍是很多企业所依赖的方式。

测试人员只能优先验证主流程，因为他们没有时间理解大量新代码；其他版本会在一个版本占用环境时等待，而多个需求并行测试又会造成环境数据互相污染。

进入AI时代，测试能力至少需要同步升级：

为每项变更提供可重复创建的隔离环境；

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

修复缺陷时，必须补充能够复现问题的回归测试；

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

Agent每次修改后都应能快速调用测试，使其成为反馈系统，而非代码完成后才进入的阶段。

06

第四个瓶颈：排到最后的依然是权限、合规和安全

数据库、外部API和企业工具能被AI迅速接入，但未经审核的依赖、敏感信息记录以及无意扩大的权限范围，也会因此更容易出现。

把安全检查留到上线前一天，会使安全团队的待处理队列随着代码增加而变长。问题到此时才被发现，还要退回开发阶段，返工范围自然更大。

安全必须进入生成过程：

隔离执行环境与最小工具权限，是Agent的默认配置；

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

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

审批对象与代码差异及版本绑定，发生变更后自动再次验证。

把重复规则做成开发过程中的自动门禁，才是安全左移；它不等于让安全团队提前开会。

07

第五个瓶颈：企业仍采用固定发布窗口

即便代码提前完成，也要等到发布窗口，因为很多企业统一发布的频率是一周或两周一次。多个变更因此被装入同一版本，回滚难度与测试范围都会扩大。

发布机制保持原样而AI产出提高时，企业很容易出现以下反常状态：

代码越来越早完成

等待发布的变更越来越多

每次上线反而越来越危险

让AI生成更多代码却继续等候“大版本列车”，无法解决问题；企业真正缺少的是持续交付能力，使变更保持小批量，能够独立验证、灰度上线并快速回退。

08

DORA发现AI只会放大系统表现，并不会修复系统

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

软件交付稳定性的下降仍与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

AI交付控制面应由CMDB与ITSM共同构成

进入AI开发阶段，ITSM应覆盖更早期的变更生命周期，而传统做法往往等到上线审批时才让它出现。

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

CMDB：从代码出发，定位其对应的业务服务、接口、数据库、微服务与应用。

变更流程：测试、审批和发布采用何种策略，由影响范围与风险自动决定。

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

事件闭环：变更与生产告警自动建立关联，以支持复盘、回滚及定位。

由此，AI产出会成为带有运行反馈、证据、风险和上下文的可交付变更，而非等待人工搬运的一堆代码。

结语

编码因AI而从稀缺能力转为高速能力，企业稀缺资源也随之变成跨团队决策、发布能力、测试环境、评审注意力、可靠反馈与清晰需求。

等待队列、返工与上线风险会随AI生成速度一同扩大，除非这些能力也同步完成升级。

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

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

https://github.com/heidsoft/itsm

说明：OpenAI在特定内部产品实验中估算出了“10倍”，这一结果不能视为所有企业采用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/

登录查看剩余 70% 内容