AI 成本暴涨 6 倍，单个开发者月均支出达 $2,000。Uber 紧急设限：每位开发者每月 AI 使用额度不超过 $1,500，并引入"净代码质量比"衡量 AI 代码的真实价值。
Uber 的"零增长技术栈"（Zero Growth Stack）试图回答一个根本问题：当业务规模持续扩张，基础设施能不能不跟着线性膨胀？答案是一套系统性的动态控制方案——将容量增长与业务需求增长解耦，用自动化运行时优化和严格的 AI 生命周期管理，减少物理硬件占用。
传统做法是"业务涨，机器就加"。Uber 想换一种玩法。
业务需求增长 → 预估容量 → 采购硬件 → 部署上线。周期长、浪费多、响应慢。
业务需求增长 → 动态系统控制 → 释放存量潜力 → 仅在必要时增量。核心是"先优化，再扩容"。
这一战略的核心支柱，是对 Go 运行时性能进行系统性优化。Uber 发现，静态垃圾回收（GC）调优无法解决内存占用差异巨大的服务问题——这些服务的内存占用范围从 100MB 到 1GB 不等。静态配置在此场景下，要么过度保守，要么风险过高。
注：零增长并非"不增长"，而是通过动态手段让容量曲线尽量平缓，避免阶梯式跳跃扩张。
Uber 开发的 GOGCTunner 是一个动态 Go 运行时调优库，它直接集成 cgroup 内存限制，并监控实时对象使用情况，自动调整 GOGC 值——这个参数决定了相对于堆增长速度而言，垃圾回收周期触发的频率。
简单说：让 GC 不再"一刀切"，而是为每个服务实时适配。
注：堆大小保持在实时对象大小的 1.25 倍，同时严格控制在 70% 内存使用率阈值以内，避免 OOM（内存溢出）事件。这组参数是在数千次生产测试中收敛的结果。
但自动化也带来了新挑战：一个静态配置被替换为一个控制循环，它必须在堆大小与内存阈值之间持续博弈。任何动态系统都需要精确的边界条件——Uber 用生产数据反复校准了这组参数，才让 GOGCTunner 在 30 个关键服务中安全回收了 70,000 个 CPU 核心。
Uber 将生成式 AI 集成到软件开发生命周期的每个环节。架构分为四层：平台层（Michelangelo AI 模型网关）、上下文层（MCP Gateway 注入内部源代码）、专用层（Minion 和 Shepherd 等后台 Agent），以及审查层（uReview 和 Code Inbox）。
这不是实验性项目——这是生产级基础设施。
效果立竿见影：92% 的工程师每月都会使用这些 Agent，31% 的新代码由 AI 编写，Autocover 每月生成超过 5,000 个单元测试。但快速采用也带来了显著的经济压力。
面对 AI 成本增长 6 倍的压力，Uber 的应对不是"一刀切禁止"，而是建立了一套精细化的成本治理框架。
核心动作只有两个：设上限，换尺子。
第一把尺子：硬性限额。每位开发者的 AI 使用额度被限制在 $1,500/月，超出部分需单独审批。这不仅仅是成本控制——它迫使团队思考：每一美元的 AI 支出，换来了多少工程产出？
第二把尺子：净代码质量比。Uber 不再仅依赖"单位劳动收入 vs AI 计算支出"来评估效率，而是引入了一个更诚实的指标：比较 AI 编写代码与人工编写代码在上线后出现热修复的频率。如果 AI 代码的热修复率显著高于人工代码，那么"效率提升"的数字就要打折扣。
此外，Uber 还在推动衡量"每个功能的计算效率"（compute efficiency per feature），帮助工程负责人判断 AI 生成代码所带来的额外开销——尤其是在考虑 Autocover 等工具生成的大量冗余测试之后——是否符合长期基础设施可持续发展的目标。
答案或许不复杂：Uber 是一家在"规模效率"上反复迭代了十多年的公司。从早年用 Go 重构核心系统，到如今用 AI 辅助开发，它始终在"用更少的资源做更多的事"这条路上。
但这一次，事情有些不同。AI 带来的效率提升太直接、太显著了，以至于采用率跑在了成本意识前面。92% 的工程师参与率、31% 的 AI 代码占比——这些数字背后是巨大的 Token 消耗和基础设施负载。
AI 的"效率红利"和"成本黑洞"是一体两面。
Uber 的应对提供了一个值得关注的样本：它没有否定 AI 的价值，而是试图建立一套让价值可量化、让成本可控制的治理框架。净代码质量比这个指标，本质上是在问一个所有工程团队最终都要面对的问题——AI 写的代码，到底帮了多少忙，又添了多少乱？
AI 开发效率的"免费午餐"已经结束。下一阶段，工程团队的竞争力不再取决于谁用了更多 AI，而是谁能在效率与成本之间找到可持续的平衡点。
Uber 的经验表明：AI 治理不是"要不要用"的问题，而是"如何用好、如何算清账"的问题。建议团队提前建立成本可见性，并设计适合自己的"净代码质量"衡量方式。