核心数据

-58%：零售行业企业正在积极部署AI（Accelerate 2026大会数据）
-400万：OpenAI Codex每周活跃用户数（OpenAI官方，2026年5月）
-3.9%：微软Word当前文档处理市场份额（6sense数据）
-9.6%：谷歌文档同类市场份额（6sense数据）

一、工具很强，但工具从来不是瓶颈

OpenAI刚被Gartner评为企业编码Agent的领导者，Codex已经400万人每周在用。Dell宣布把Codex带到企业本地部署环境。Claude Code、Cursor、Windsurf这些工具迭代速度极快，每个月都有实质性改进。

工具侧的能力毋庸置疑。但问题在于，这些工具解决的是"写代码"这个环节的效率。而企业软件交付的瓶颈，从来不只是写代码。

一个功能从想法到上线，要经历需求评审、技术方案、编码、代码审查、测试、部署审批、灰度发布、线上验证。编码可能只占整个周期的20%-30%。你把这30%提速两倍，整体也只快了不到20%。

这不是AI工具的问题，这是流程的问题。

二、历史在重演

作者举了一个很生动的比喻：你去救助中心想领养一只陪伴犬，他们却让你带一只猎豹回家，只因为它跑得更快。

这跟当下很多企业的做法如出一辙。过去二十年，软件行业经历过好几轮"提速运动"：

敏捷转型——很多人变成了只追求Sprint速度的机器，产品方向一塌糊涂。

DevOps——口号喊了十年，很多团队连自动部署都没搞定。

平台工程——成了基础设施团队的自嗨，业务团队该等还是等。

每一轮都是"这次不一样"，每一轮的核心问题都没变：你到底在追求速度，还是在追求反馈？

速度本身没有价值。频繁获取用户反馈、快速调整方向，才是敏捷的精髓。DORA模型里那些"精英绩效"团队，交付速度快不是目的，高频高质量反馈才是。

三、先修路，再跑车

InfoQ那篇文章里有一个真实案例：一个医疗企业的软件团队，原来半年发布一次版本，测试周期两周，发现问题再加两周，循环往复。后来通过梳理价值流、引入可执行规范、砍掉官僚审批，做到了每三小时一个可部署版本，两周交付了一个API，签下了一份250万美元的合同。

他们用了AI吗？这个案例发生在AI编程工具大规模普及之前。提速靠的是流程优化，不是换工具。

这就引出了一个关键问题：如果团队连持续交付的基础能力都不具备，引入AI编程工具的效果会怎样？大概率是，开发者用AI快速生成了大量代码，然后堵在代码审查、测试、部署审批这些环节。代码产出更快了，但交付速度没变，反而因为代码量增加加重了下游负担。

四、正确的打开方式

那AI编程工具到底怎么用才对？几个值得关注的思路：

缩小团队。Brooks定律说过，往一个已经延误的项目加人只会让它更慢。AI让3-4人的小团队具备了过去8-10人团队的生产力，沟通成本大幅降低。与其用AI让大团队更快，不如用AI让小团队成为可能。

提升探索效率。与其更快地开发原有功能，不如用AI快速搭建原型，验证那些过去不敢尝试的想法。全球化布局、新业务方向、技术可行性验证——这些才是AI真正的杠杆点。

先把流水线打通。代码提交到生产部署的路径，有没有自动化测试？有没有一键部署？有没有可观测性？如果这些基础没做好，AI生成的代码越多，下游越堵。

InfoQ上周还有一场对谈，小红书和快手的AI Coding实践者也说了类似的观点：AI Coding已经进入大规模落地阶段，但企业交付效率的提升，需要Agent能力、组织架构和研发体系的同步重构。

数据来源：InfoQ《人工智能无法加速软件交付》(2026)、OpenAI官方博客(2026.5.22)、Accelerate 2026大会、6sense市场份额数据