AI一天修完过去几周的Bug，为什么你的版本还是发不出去？

Cisco把缺陷修复提速10—15倍，也把一个问题摆到台前：代码快了，交付未必会跟着快。

周一早上，AI已经把十几个缺陷补丁生成好了。研发说代码能跑，测试说环境没排上，评审人面对一排PR，只能先挑风险最大的看。

代码快了。版本没发出去。

最近在复盘内部的AI提效实践，也对照看了Cisco与OpenAI公开的案例。两边放在一起，我越来越确定一件事：编码从几周压到几小时后，研发瓶颈会换地方。

过去卡在“谁来写、要写多久”。现在更容易卡在需求、上下文、测试、评审和发布责任。

写得快是个人效率，发得稳才是团队效率。

01｜95%的AI代码采纳率，说明了什么？

图1：95%+说明AI代码被大量采纳；另外三组数字对应构建、缺陷和工程工时。

Cisco案例披露，95%以上的新AI功能由Codex编写。这里可以理解为AI代码采纳率很高，但它不是“Cisco全部代码的95%”。

我更关心另外三组结果：Codex分析15个以上互联仓库后，构建时间下降约20%，每月节省1500小时以上工程工时；在C/C++缺陷修复场景中，原来数周的人工工作缩短到数小时，解决吞吐提高10—15倍；React 18到19的多UI迁移，也从数周压到了数天。[OpenAI：Cisco与Codex企业工程案例](https://openai.com/zh-Hans-CN/index/cisco/)

这些任务都能形成闭环：读仓库、改代码、跑命令、看结果，再根据失败继续修。AI处理的已经不是一次代码补全，而是一段完整工作。

02｜代码快了，版本为什么没快？

图2：编码时间被压缩后，等待会转移到需求、评审、环境和验收。

常见的误判，是把个人编码速度当成团队交付速度。编码只影响交付链路中的一段。

代码产量上去后，PR队列可能更长；测试环境还是原来的数量；自动化用例不稳定；需求里一句“兼容旧版本”，直到验收时也没人说清版本范围。AI没有制造这些问题，只是让它们更早暴露。

DORA在2025年的研究中把AI称为组织能力的“放大器”。研发基础扎实，AI会放大优势；流程、数据和平台薄弱，短板也会被放大。[DORA 2025 AI辅助软件开发报告](https://dora.dev/research/2025/dora-report/)

所以，工具使用率上升，不代表版本会更快上线。

03｜Cisco做对了哪一步？

图3：AI要接入上下文、工具、反馈和人工评审，才能形成可交付变更。

Cisco没有把Codex停留在个人桌面上。它被接入生产工程流程，可以读取多仓库和C/C++代码库，通过CLI执行“编译—测试—修复”，同时受原有评审、安全和治理规则约束。[OpenAI：Cisco与Codex企业工程案例](https://openai.com/zh-Hans-CN/index/cisco/)

Splunk团队还会让Codex先写计划，再按计划执行。评审人因此能看到它准备改什么、怎么验证、哪些风险还没覆盖。

这件事很朴素，却直接影响信任。人没有亲手写每一行代码，就更需要过程和证据。

要把AI接入研发流程，至少要准备好代码与依赖上下文、可执行的构建测试工具、权限和回滚边界，以及人工验收规则。缺一项，后面都可能变成返工。

代码可以由AI完成，发布责任不能交给AI。

04｜人没退出，工作内容变了

Cisco的工程师把更多时间放在设计和验证上。这与内部AI提效实践里看到的变化很接近：重复修改在减少，任务拆解、上下文准备和结果验收变多了。

开发要把架构知识写清楚，质量团队要把经验变成可执行的验收规则，安全和平台团队要给出最小权限与回滚路径。技术负责人仍要对最终风险负责。

这也是很多同事不安的原因。工作没有凭空消失，只是从“亲手做”变成了“定义清楚、检查到位、出了问题能收回来”。

05｜为什么有的团队提效15倍，有的反而更慢？

Cisco的数字来自OpenAI与客户共同发布的案例，不是受控实验。文章没有公布完整样本量、人工评审成本、线上缺陷率和回滚率。

METR做过另一项实验：16名熟悉大型开源仓库的资深开发者处理246个真实任务，使用早期2025年AI工具的一组平均多花了19%的时间。研究团队也明确提醒，这个结果只适用于当时的工具、任务和样本。[METR开发者生产力实验](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

两个结果并不冲突。Cisco让智能体进入了边界清楚、能够自动验证的工作流；METR测的是另一代工具和另一类任务。AI是否提效，要看任务能不能拆清、上下文是否完整、工具能否调用、结果能否验证。

条件不齐，AI生成得越快，人工评审和返工可能越多。

06｜怎么验证AI有没有提效？

图4：把吞吐、稳定性和人工成本放在一起看，才知道有没有净收益。

不要数AI写了多少行代码。看版本有没有更快、更稳地到达生产。

DORA目前用变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率衡量软件交付。我还会加上评审耗时和大幅返工率。[DORA软件交付绩效指标](https://dora.dev/guides/dora-metrics/)

试点不用铺太大。选一个高频、费时、结果能自动验证的场景，按四周跑一遍：第一周记录基线，第二周接入闭环，第三周稳定运行，第四周比较结果。

流程也不必复杂：

最后只看几项：变更前置时间、缺陷吞吐、评审耗时、变更失败率和返工率。只要有一项明显恶化，就回到流程里找新的堵点。

内部AI提效实践也应该从这样的小闭环开始。数据好，再扩；数据不好，先改流程。