AI 编程普及后，Uber 为什么开始给开发者设预算上限？

2026年8月1日阅读约 2 分钟

导语

当 AI 编程工具在企业内部快速普及时，最初的问题通常是“有多少人愿意用”。但 Uber 的最新实践表明，下一阶段的问题会变成：这些工具到底带来了多少净收益，以及企业是否还能负担它们背后的计算账单。

据 InfoQ 中文整理，Uber 在推进“零增长技术栈”（Zero Growth Stack）的同时，也开始对内部 AI 开发工具设置更严格的成本治理规则。这不是简单的削减开支，而是一次从“鼓励采用”转向“衡量产出”的管理变化。

基础设施先做减法。 Uber 的 Zero Growth Stack 试图将容量增长与业务增长解耦，通过自动化运行时优化减少对物理硬件扩张的依赖。
Go 运行时成为重点优化对象。 Uber 发现静态 GC 参数难以适配内存占用差异巨大的服务，于是开发 GOGCTunner，依据 cgroup 内存限制和实时对象使用情况动态调整 GOGC。
优化效果已经可观。 该方案已在 30 个关键任务服务中回收约 70,000 个 CPU 核心，但同时也引入了需要持续平衡堆大小与内存阈值的控制循环。
AI 编程进入高普及阶段。 Uber 内部 92% 工程师每月使用相关 Agent，31% 新代码由 AI 编写，Autocover 每月生成超过 5,000 个单元测试。
成本压力迅速显现。 自 2024 年以来，AI 相关成本增长六倍；到 2026 年初，单个开发者月度成本已达到 2,000 美元。Uber 因此将每位开发者的 AI 使用额度限制在 1,500 美元以内。

Uber 的案例提醒企业：AI 编程不是“接入模型”就结束的项目，而是一套会持续消耗预算、影响代码库质量，并改变基础设施负载的系统工程。

更关键的是，AI 产出不能只看代码行数或测试数量。Uber 正在转向更细粒度的指标，例如比较 AI 代码和人工代码上线后的热修复频率，形成“净代码质量比”；同时也尝试用“每个功能的计算效率”衡量 AI 生成代码、自动测试和后续维护带来的真实开销。

这意味着，企业采用 AI 编程工具的重点正在变化：从追求覆盖率、使用率，转向追求可审计的质量收益和可持续的成本结构。对工程管理者来说，AI 的价值不应只体现在“写得更快”，还必须证明它没有以更高的云成本、更复杂的测试冗余或更多线上修复为代价。